菜单
How to verify Massing web/viewer UI changes given that the dev-preview geometry loader stalls. Invoke when you changed apps/web and need to prove it works. Covers typecheck/lint/vitest/build, the tools-panel force-build technique, and honest flagging of flows you couldn't exercise.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Reason like a master builder — one mind holding an entire built-asset project from raw land through design, construction, handover, operations, and disposition, anywhere in the world. Use whenever the user touches real estate development, construction, or the built environment: site feasibility, highest-and-best-use, entitlements/zoning/planning permission, building-code compliance in any jurisdiction, structural/MEP/envelope questions, delivery-method selection, estimating, scheduling, procurement, construction administration (RFIs, submittals, change orders, pay apps), BIM/IFC/ISO 19650 workflows, development pro formas, JV waterfalls, construction-loan mechanics, cap rates, IRR, or underwriting. Trigger even when the user names only a slice (e.g. "what wind load applies in Miami", "draft an RFI", "does this deal pencil") — the point is reasoning about that slice inside the whole project. Also trigger for any request to build, price, phase, or evaluate a project in an unfamiliar place.
How to monitor and fix security issues in Massing — CodeQL alerts, dependency audits, secret scanning, and ReDoS/XXE fixes. Invoke after a push (standing directive) or when doing a hardening pass. Emphasises that a green CodeQL *run* != zero alerts.
Drive a Massing BIM/AEC project from an AI agent over MCP — read a project's status, records, CDE, KPI and model-quality checks; run standards-compliance, schedule-risk, embodied-carbon, permit- readiness and drawing-QA analyses; author the IFC model with GUID-stable recipes; and draft RFIs. Use when the user asks to inspect, analyse, or author a Massing project through Claude.
How to run and add Python tests in the Massing API/data services. Invoke when writing or running backend tests, or debugging a CI test-gate failure. Covers the run_tests.py runner, the manifest guard, per-test env isolation, DB-lock cleanup, and the two idioms (DB-backed vs engine/IFC).
The Massing release discipline — how to ship a verified, CI-green version-numbered release direct to main. Invoke whenever finishing a shippable change (feature, fix, doc). Covers version bump (both files), CHANGELOG/roadmap notes, the ruff/lint CI gotchas, tag, push, and CI/CodeQL verification.
| name | verify-frontend |
| description | How to verify Massing web/viewer UI changes given that the dev-preview geometry loader stalls. Invoke when you changed apps/web and need to prove it works. Covers typecheck/lint/vitest/build, the tools-panel force-build technique, and honest flagging of flows you couldn't exercise. |
The dev-preview geometry loader stalls at "preparing geometry" for all model sizes, which blocks loadProjectModel and therefore buildPanels (the panel-tree model browser). But buildToolsPanel (the rail tools) can be forced. Verify what you can; flag what you can't.
cd apps/web && export PATH="/c/Program Files/nodejs:$PATH"
npm run typecheck && npm run lint # eslint pinned to 9.39.5; Node 20 (Node 18 breaks build)
npx vitest run <path/if/covered>
npm run build # strongest compile check; ~1 min
The preview server is on :5173. In the running preview (via the browser tools), navigate to a project with a source IFC, then:
window.dispatchEvent(new CustomEvent('aec:persona', { detail: 'all' })); // forces buildToolsPanel + buildClashPanel
// then read #panel-tools — the tool-group sections, buttons, inputs all render even though geometry stalled
This verifies: new rail tools/buttons/inputs, the ribbon tabs, the Library palette, the node-canvas launcher, the KEYS shortcut layer (dispatch KeyboardEvents), the Ask/analytical boxes. Exercise handlers by .click()ing buttons and reading the result-overlay / DOM.
panel-tree UI (the Project-Browser spine) — buildPanels never runs behind the stall. Verify its DOM-construction logic by reproducing it in the console instead, and say so.read_network_requests that the URL/payload is correct; the backend itself is covered by CI. (Restarting :8093 is the user's call.)State exactly what was verified live vs. by typecheck/build vs. not exercised. Never claim an interactive viewer flow "verified" if the stall prevented it.
See memory: tools-panel-verify-technique, web-build-needs-node-20, web-eslint-node-pin, dev-api-port.