Run any Skill in Manus with one click

verify-frontend

Stars114

Forks56

UpdatedJuly 17, 2026 at 16:24

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

ibuilder

ibuilder/massing

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

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.

Verify a Massing frontend change

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.

Always

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

Force the tools rail to build (verifies rail UI live)

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.

What you CAN'T verify live (flag it honestly)

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.
End-to-end calls to NEW API routes against the dev API on :8093 — that server is often a stale process predating your new routes → 404 there even though the client hits the right URL. Confirm via read_network_requests that the URL/payload is correct; the backend itself is covered by CI. (Restarting :8093 is the user's call.)
Anything geometry-coupled (placing an element, section cuts, camera).

Report

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.

More from this repository

same repository

master-builder

ibuilder/massing

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.

2026-07-20114

security-monitoring

ibuilder/massing

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.

2026-07-19114

massing-bim

ibuilder/massing

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.

2026-07-18114

backend-tests

ibuilder/massing

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).

2026-07-17114

ship-release

ibuilder/massing

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.

2026-07-17114

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.

Verify a Massing frontend change

Always

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

Force the tools rail to build (verifies rail UI live)

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

What you CAN'T verify live (flag it honestly)

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.
End-to-end calls to NEW API routes against the dev API on :8093 — that server is often a stale process predating your new routes → 404 there even though the client hits the right URL. Confirm via read_network_requests that the URL/payload is correct; the backend itself is covered by CI. (Restarting :8093 is the user's call.)
Anything geometry-coupled (placing an element, section cuts, camera).

Report

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.