Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

verify-frontend

Estrellas114

Forks56

Actualizado17 de julio de 2026 a las 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.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

ibuilder

ibuilder/massing

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas·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.

Más de este repositorio

mismo repositorio

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.