feat(ifc): preserve unsupported IFC geometry

.agents/plugins/marketplace.json

@@ -0,0 +1,27 @@
+{
+  "name": "pascal",
+  "interface": {
+    "displayName": "Pascal"
+  },
+  "plugins": [
+    {
+      "name": "pascal-agent-skills",
+      "version": "0.1.8",
+      "description": "Create, inspect, validate, and assess furniture layouts with bounded next actions in Pascal through MCP.",
+      "author": {
+        "name": "Pascal",
+        "email": "support@pascal.app",
+        "url": "https://pascal.app"
+      },
+      "source": {
+        "source": "local",
+        "path": "./"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Productivity"
+    }
+  ]
+}

.agents/skills/open-pr/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: open-pr
 description: Open a pull request on pascalorg/editor using the repo's PR template. Use when the user asks to open/create a PR, push and PR, or ship a branch in the editor repo.
+metadata:
+  internal: true
 allowed-tools: Bash(git *) Bash(gh *) Read
 ---
 

.agents/skills/open-pr2/SKILL.md

@@ -0,0 +1,216 @@
+---
+name: open-pr2
+description: Open or update a pull request on pascalorg/editor with a plain-language issue-and-fix description based on the full branch diff. Use only when the user explicitly asks for OpenPR2 or /open-pr2.
+metadata:
+  internal: true
+disable-model-invocation: true
+allowed-tools: Bash(git *) Bash(gh *) Bash(bun *) Read
+---
+
+# OpenPR2
+
+Open or update a pull request against `pascalorg/editor` from the current branch. Keep the repository's PR template, but write the body like one developer explaining the change to another.
+
+## 1. Pre-flight
+
+Inspect the working tree and the whole branch before writing anything:
+
+```bash
+git status
+git branch --show-current
+git log --oneline main..HEAD
+git diff --stat main...HEAD
+git diff --name-status main...HEAD
+```
+
+Read the relevant parts of `git diff main...HEAD`. Do not build the description from the latest commit alone or from conversation memory.
+
+Stop if:
+
+- The current branch is `main`. Ask the user to create a feature branch first.
+- The branch has no commits ahead of `main`.
+- There are uncommitted changes the user has not asked to commit.
+
+For a non-trivial change, run checks that match the affected packages. Prefer focused tests plus:
+
+```bash
+bun run check-types
+bun run build
+```
+
+Do not open a PR when a required check fails. Report the failure instead. Do not claim that a command or manual test passed unless it was run.
+
+## 2. Read the current PR template
+
+Read `.github/pull_request_template.md` every time. Its headings and checklist wording are the source of truth.
+
+Keep the template headings in the same order:
+
+1. `## What does this PR do?`
+2. `## How to test`
+3. `## Screenshots / screen recording`
+4. `## Checklist`
+
+Do not replace them with `Summary`, `Details`, `Validation`, or custom headings unless the template itself changes.
+
+## 3. Write the title
+
+- Keep it under 70 characters when practical.
+- State the result, not the activity. Prefer `fix(editor): keep curved room slabs attached` over `update wall files`.
+- Add a package scope when one package clearly owns the change, such as `core:`, `viewer:`, `editor:`, or `mcp:`.
+- Avoid vague verbs such as `improve`, `enhance`, `update`, or `refactor` when a concrete verb fits.
+
+## 4. Write the body in plain language
+
+### What does this PR do?
+
+The reviewer should understand every changed behavior without opening the diff. Do not compress unrelated fixes into a paragraph or a long bullet.
+
+Give each problem its own short item. Use this exact shape:
+
+```markdown
+- **Short feature or problem name**
+  - Issue: One short sentence describing what was wrong or missing.
+  - Fixed: One short sentence describing the behavior after this PR.
+```
+
+Add one more indented sentence only when the reviewer needs an important constraint, risk, or design decision. Keep it short and do not add labels such as `Details`, `Technical`, or `Implementation`.
+
+Example:
+
+```markdown
+- **Curved triangular rooms**
+  - Issue: Slabs and ceilings kept a straight corner after curving a wall.
+  - Fixed: Both surfaces now rebuild from the curved room boundary.
+
+- **Wall and fence thickness**
+  - Issue: Thickness could only be changed from the settings panel.
+  - Fixed: Each face now has a circular thickness handle in 2D and 3D.
+  - The centerline stays fixed, and the change uses one undo step.
+```
+
+Keep the item title concrete. Start with product behavior, not filenames or function names. Cover every meaningful user-visible fix on the branch. Combine items only when they describe the same problem and the same fix.
+
+Avoid this compressed style:
+
+```text
+This PR fixes curved wall topology, adds thickness handles, improves floor-plan previews, updates roof paint slots, and cleans up roof controls.
+```
+
+Link issues with `Fixes #123` or `Refs #123` when applicable. Never invent an issue number.
+
+### How to test
+
+Write numbered reviewer steps. Put the action on the numbered line and the expected result on a short indented line.
+
+Good:
+
+```text
+1. Create a triangular room and curve one wall.
+   - The slab and ceiling should follow the curved corner with no gap.
+
+2. Drag either wall thickness dot.
+   - The wall should stay centered while its thickness changes.
+```
+
+List automated commands only when they were run. Include pass counts when they are known and useful. Do not turn the section into a dump of every command used during development.
+
+### Screenshots / screen recording
+
+- Preserve any existing media verbatim when updating a PR.
+- For a visual or interactive change, add the supplied media. If none exists, write `Not added yet.`
+- For a non-visual change, write `N/A, no visual change.`
+- Do not claim that a recording exists when it does not.
+
+### Checklist
+
+Copy every checklist line from the current template verbatim.
+
+- Tick an item only when it is true.
+- `bun dev` is checked only after local runtime testing.
+- The code-style item is checked only after the requested style command passes.
+- Documentation is checked when docs were updated or when the item explicitly says it is not applicable. Otherwise leave it unchecked.
+- Confirm the actual base branch before checking the target-branch item.
+
+## 5. Human writing pass
+
+Before submitting, read the title and body once as a reviewer who has not seen the branch.
+
+Rewrite anything that fails these checks:
+
+- Use plain words and short sentences.
+- Say what the change does. Avoid phrases that could describe any PR.
+- Remove filler, hype, sales language, and chatbot phrases.
+- Remove repeated points and details that the diff explains on its own.
+- Avoid jargon unless the repository uses the term and the reviewer needs it.
+- Avoid forced lists, excessive bold text, em dashes, and long parenthetical asides.
+- Prefer active voice.
+- Keep a human rhythm. The body should not read like generated release notes.
+- Make every test step concrete and verifiable.
+
+If the summary sounds too small, add the missing problem or behavior. If it sounds dense, remove implementation trivia before shortening the explanation of the bug.
+
+## 6. Push and find the PR
+
+Push the current branch:
+
+```bash
+git push -u origin HEAD
+```
+
+Check whether it already has a PR:
+
+```bash
+gh pr view --json number,url,title,body 2>/dev/null
+```
+
+### No existing PR
+
+Create one with `gh pr create`. Pass the body through a quoted heredoc so Markdown stays intact:
+
+```bash
+gh pr create --title "<title>" --body "$(cat <<'EOF'
+<body using the current PR template>
+EOF
+)"
+```
+
+### Existing PR
+
+Do not create another PR. Update the current one from the full branch diff.
+
+Before rewriting it:
+
+```bash
+gh pr view --json number,title,body,url
+git log --oneline main..HEAD
+git diff --stat main...HEAD
+```
+
+When rebuilding the body:
+
+- Preserve `Fixes #123` and `Refs #123` lines.
+- Preserve screenshots, recordings, links, and embedded images verbatim unless the user supplied replacements.
+- Preserve the user's checklist state for work that remains true. Never change an unchecked item to checked without evidence.
+- Keep extra reviewer notes that are still relevant.
+- Remove old claims and test steps that no longer match the branch.
+- Leave the title unchanged unless the branch's purpose clearly changed.
+
+Apply the update with `gh pr edit <number> --body ...`. Change the title only when needed.
+
+## 7. Verify and report
+
+Read the PR back after creation or editing:
+
+```bash
+gh pr view --json number,url,title,body,baseRefName,headRefName
+```
+
+Confirm that the title, template sections, base branch, and body were saved correctly.
+
+Return:
+
+- PR URL
+- Title
+- Checks and tests actually run
+- Any unchecked checklist item or missing recording the reviewer should know about

.agents/skills/review-architecture/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: review-architecture
 description: Review a PR against the Pascal architectural rules — package boundaries (core/viewer/editor/nodes), the registry-driven composition model (def.geometry / def.renderer / def.system), legacy-dispatch regressions, the slots + world-scale-UV convention for new nodes/geometry, hook hygiene (useEditor/useScene/useViewer), and selector performance. Use when the user asks to review a PR, audit a branch, or check that changes respect the codebase's architecture.
+metadata:
+  internal: true
 allowed-tools: Bash(git *) Bash(gh *) Read Grep Glob
 ---
 
@@ -24,6 +26,7 @@ Required on every review. Read the remaining pages on demand when the diff touch
 - `wiki/architecture/scene-registry.md`
 - `wiki/architecture/spatial-queries.md`
 - `wiki/architecture/node-schemas.md`
+- `wiki/architecture/inspector-field-limits.md` — no arbitrary `min`/`max` on dimension fields. Read whenever the diff adds or edits `parametrics.ts`, a kind `panel.tsx`, or `<SliderControl>` bounds.
 - `wiki/architecture/events.md`
 - `wiki/architecture/interaction-scope.md` — the interaction state machine + the unified snapping/modifier convention. Read whenever the diff touches a tool, a `move-tool` / `selection` / endpoint / reshape file, `lib/interaction/**`, `lib/snapping-mode.ts`, or `use-interaction-scope`.
 
@@ -120,7 +123,7 @@ If the PR adds or modifies a node kind, check against `wiki/architecture/node-de
 - New state added to `useViewer` must be presentation-only (selection, camera, level mode, display toggles). Editor-only state (active tool, phase, edit mode, paint preview, floorplan state) goes in `useEditor`.
 - **Node code does not import `useScene` directly.** A kind's geometry / system / tool should read and write through `SceneApi` (passed in by the framework) or `GeometryContext`. Direct `useScene.getState()` calls inside `packages/nodes/src/<kind>/` are a smell — they bypass the registry's IoC point and make the code harder to test.
 - **Live drag motion is imperative, not store-driven.** Tools must not call `useLiveTransforms.set(...)` per `grid:move` tick to animate registered parametric kinds — the selector path doesn't reliably re-render and the mesh visibly disappears mid-drag. Use `sceneRegistry.nodes.get(node.id)?.position.set(x, y, z)` instead, and commit once at the end via `useScene.temporal.getState().resume() → updateNode → pause()`. The reference implementation is `MoveRegistryNodeTool`. This is the *only* sanctioned use of imperative mesh transforms by a tool; flag any other location that does the same.
-- **Data-driven drags preview via `useLiveNodeOverrides`, never per-tick `useScene`.** A kind whose geometry is recomputed from data fields (wall `start`/`end`, opening host-cut, endpoint reshape) previews by publishing field patches to `useLiveNodeOverrides` (merged by `getEffectiveWall` / `getEffectiveNode`), writing the scene store **once on commit**. A tool that calls `useScene.updateNodes`/`updateNode` on `grid:move` (or any per-pointer-move tick) is a **blocker** — it swaps the `nodes` map ref and re-renders every `useScene(s => s.nodes)` subscriber app-wide each frame (`markDirty` per tick is fine). Grep tell: `updateNode(s)?(` in an `onGridMove`/`onMove`/`applyPreview` path under `packages/nodes/src/<kind>/`. See `wiki/architecture/tools.md` § "Data-driven live drag".
+- **Data-driven drags preview via `useLiveNodeOverrides`, never per-tick `useScene`.** A kind whose geometry is recomputed from data fields (wall `start`/`end`, opening host-cut, endpoint reshape) previews by publishing field patches to `useLiveNodeOverrides` (merged by `getEffectiveWall` / `getEffectiveNode`), writing the scene store **once on commit**. A tool that calls `useScene.updateNodes`/`updateNode` on `grid:move` (or any per-pointer-move tick) is a **blocker** — it swaps the `nodes` map ref and re-renders every `useScene(s => s.nodes)` subscriber app-wide each frame. `markDirty` per tick is fine **for bounded gestures** (drag marks drain every frame); a `useFrame`/animation loop that marks dirty for as long as something animates is a **blocker** — the scene can then never settle to DIRTY 0. Animations signal rebuilds through their own records (`useInteractive` animations), marking dirty once on completion; see `wiki/architecture/node-definitions.md` § "`geometry` + `system`". Grep tell: `updateNode(s)?(` in an `onGridMove`/`onMove`/`applyPreview` path under `packages/nodes/src/<kind>/`. See `wiki/architecture/tools.md` § "Data-driven live drag".
 
 ### D. Selector performance
 

.claude-plugin/marketplace.json

@@ -0,0 +1,24 @@
+{
+  "$schema": "https://json.schemastore.org/claude-code-marketplace.json",
+  "name": "pascal",
+  "version": "0.1.8",
+  "description": "Public Pascal workflows for MCP-capable agents.",
+  "owner": {
+    "name": "Pascal"
+  },
+  "plugins": [
+    {
+      "name": "pascal-agent-skills",
+      "source": "./skills",
+      "description": "Create, inspect, validate, and assess furniture layouts with bounded next actions in Pascal through MCP.",
+      "author": {
+        "name": "Pascal",
+        "email": "support@pascal.app",
+        "url": "https://pascal.app"
+      },
+      "version": "0.1.8",
+      "category": "productivity",
+      "skills": ["./pascal-3d", "./furniture-fit"]
+    }
+  ]
+}

.codex-plugin/plugin.json

@@ -0,0 +1,37 @@
+{
+  "name": "pascal-agent-skills",
+  "version": "0.1.8",
+  "description": "Create, inspect, validate, and assess furniture layouts with bounded next actions in Pascal through MCP.",
+  "author": {
+    "name": "Pascal",
+    "email": "support@pascal.app",
+    "url": "https://pascal.app"
+  },
+  "homepage": "https://editor.pascal.app/docs/developers/mcp",
+  "repository": "https://github.com/pascalorg/editor",
+  "license": "MIT",
+  "keywords": ["pascal", "3d", "architecture", "mcp", "furniture", "spatial"],
+  "skills": "./skills/",
+  "interface": {
+    "displayName": "Pascal",
+    "shortDescription": "Build 3D scenes and check fit",
+    "longDescription": "Use Pascal's MCP tools to work with editable building scenes, validate and save results, and produce bounded furniture footprint reports with explicit evidence, limitations, and blocker-aware next actions.",
+    "developerName": "Pascal",
+    "category": "Developer Tools",
+    "capabilities": [
+      "Build and edit 3D scenes",
+      "Validate spatial layouts",
+      "Assess furniture footprints"
+    ],
+    "websiteURL": "https://editor.pascal.app/docs/developers/mcp",
+    "privacyPolicyURL": "https://editor.pascal.app/privacy",
+    "termsOfServiceURL": "https://editor.pascal.app/terms",
+    "defaultPrompt": [
+      "Use Pascal to inspect this building project, make the requested bounded edit, validate it, save it, and return the editor URL.",
+      "Check whether this furniture footprint fits in a measured Pascal room, including rotations, collisions, and door access."
+    ],
+    "brandColor": "#171717",
+    "composerIcon": "./assets/pascal-mark.svg",
+    "logo": "./assets/pascal-mark-plate.svg"
+  }
+}

.cursor-plugin/mcp.json

@@ -0,0 +1,16 @@
+{
+  "mcpServers": {
+    "pascal": {
+      "type": "stdio",
+      "command": "pascal",
+      "args": ["mcp", "connect"]
+    },
+    "pascal-hosted": {
+      "type": "http",
+      "url": "https://editor.pascal.app/api/mcp",
+      "headers": {
+        "Authorization": "Bearer ${PASCAL_API_KEY}"
+      }
+    }
+  }
+}