@fugood/bricks-project 2.25.0-beta.13 → 2.25.0-beta.15

package/package.json

@@ -1,13 +1,13 @@
 {
   "name": "@fugood/bricks-project",
-  "version": "2.25.0-beta.13",
+  "version": "2.25.0-beta.15",
   "main": "index.ts",
   "scripts": {
     "typecheck": "tsc --noEmit",
     "build": "bun scripts/build.js"
   },
   "dependencies": {
-    "@fugood/bricks-cli": "^2.25.0-beta.12",
+    "@fugood/bricks-cli": "^2.25.0-beta.15",
     "@huggingface/gguf": "^0.3.2",
     "@iarna/toml": "^3.0.0",
     "@modelcontextprotocol/sdk": "^1.15.0",

package/package.json.bak

@@ -1,13 +1,13 @@
 {
   "name": "@fugood/bricks-ctor",
-  "version": "2.25.0-beta.13",
+  "version": "2.25.0-beta.15",
   "main": "index.ts",
   "scripts": {
     "typecheck": "tsc --noEmit",
     "build": "bun scripts/build.js"
   },
   "dependencies": {
-    "@fugood/bricks-cli": "^2.25.0-beta.12",
+    "@fugood/bricks-cli": "^2.25.0-beta.15",
     "@huggingface/gguf": "^0.3.2",
     "@iarna/toml": "^3.0.0",
     "@modelcontextprotocol/sdk": "^1.15.0",

package/skills/bricks-ctor/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bricks-ctor
-description: Advanced BRICKS configuration knowledge. Covers Standby Transition, Automations (E2E testing), Data Calculation (JS sandbox libraries), Local Sync, Remote Data Bank, Media Flow, and Buttress (remote inference). Triggers on multi-device sync, cloud data, media assets, AI offloading, E2E testing, or canvas transitions.
+description: Advanced BRICKS configuration knowledge. Covers Standby Transition, Automations (E2E testing), Data Calculation (JS sandbox libraries), Local Sync, Remote Data Bank, Media Flow, Buttress (remote inference), and the verification toolchain (compile/preview MCP, on-device DevTools, definition-of-done gate). Triggers on multi-device sync, cloud data, media assets, AI offloading, E2E testing, canvas transitions, or verifying project work before declaring done.
 ---
 
 # BRICKS Ctor - Advanced Features
@@ -20,6 +20,7 @@ This skill covers advanced BRICKS features not in the main project instructions.
 | [Remote Data Bank](rules/remote-data-bank.md) | Cloud data sync and API access |
 | [Media Flow](rules/media-flow.md) | Media asset management |
 | [Buttress](rules/buttress.md) | Remote inference for AI generators |
+| [Verification Toolchain](rules/verification-toolchain.md) | Definition of done, compile/preview MCP, on-device DevTools, Path 1/2/3 decision rule |
 
 ## Quick Reference
 
@@ -30,3 +31,4 @@ This skill covers advanced BRICKS features not in the main project instructions.
 - **AI offloading**: See [Buttress](rules/buttress.md) for GPU server delegation
 - **E2E testing**: See [Automations](rules/automations.md) for test automation
 - **Enter animations**: See [Standby Transition](rules/standby-transition.md) for canvas transitions
+- **Verification before done**: See [Verification Toolchain](rules/verification-toolchain.md) for the definition-of-done gate and Path 1/2/3 decision rule

package/skills/{bricks-design/references → bricks-ctor/rules}/verification-toolchain.md

@@ -4,11 +4,11 @@ Three runtime targets, one decision rule. Verify against the cheapest path that
 
 ## Definition of done — the hard gate
 
-Before the agent is allowed to claim a design is complete, **all** of the following must be true:
+Before the agent is allowed to claim work is complete, **all** of the following must be true:
 
 1. **Compile clean.** Latest source passes `compile` with no errors.
 2. **Every Canvas screenshot captured.** A rendered screenshot of every Canvas in the deliverable, captured via `preview` MCP (`responseImage: true`) at the target hardware resolution and orientation. Canvases gated behind events are reached via Automation runs (`testId` / `testTitleLike` with `brick_press` / `wait_until_canvas_change` cases). Single-Canvas Subspaces still require a captured screenshot.
-3. **Every screenshot reviewed by the agent.** The agent must read each captured screenshot back through the host's image-reading capability — saving the file is not the same as seeing it. The model that designed the Canvas must also have seen the rendered result, or the verification gate has not passed.
+3. **Every screenshot reviewed by the agent.** The agent must read each captured screenshot back through the host's image-reading capability — saving the file is not the same as seeing it. The model that produced the Canvas must also have seen the rendered result, or the verification gate has not passed.
 4. **Reference comparison report.** If the user supplied any reference material (Figma / website / HTML / screenshot / PDF / brand book / competitor), produce a short delta report per Canvas:
    - What matches the reference.
    - What intentionally diverges, and why (deployment constraint, BRICKS-runtime semantic, system commitment).
@@ -60,17 +60,7 @@ Useful flags:
 - `--no-cdp` — disable CDP server (rare; default is to expose it).
 - `--clear-cache` — reset cached state between runs.
 
-### `bricks-cli devtools` against `localhost:19852`
-
-Same CDP commands as the device path; just point them at the local preview.
-
-```
-bricks devtools screenshot -a localhost -p 19852 -o local.png
-bricks devtools brick tree -a localhost -p 19852 -d 5
-bricks devtools input tap 480 270 -a localhost -p 19852
-bricks devtools storage data-bank list -a localhost -p 19852
-bricks devtools runtime eval -a localhost -p 19852 "document.title"
-```
+For ad-hoc CDP inspection against this local preview, connect any CDP client to `localhost:19852` — Chrome DevTools front-end works directly. For an agent-friendly CLI over CDP (screenshot, brick tree/query, input emulation, storage reads, runtime eval, network capture), the `bricks-cli` skill documents the `bricks devtools` command surface — read that skill if it is installed in this workspace. If it is not installed, run `bricks --help` and `bricks devtools --help`; the CLI's own help output is authoritative.
 
 ### Project Automations
 
@@ -100,7 +90,7 @@ Ask the user to:
 
 1. On the device, open **Settings** → advanced settings.
 2. Toggle **Chrome DevTools** on. The device starts a DevTools server on the local network on port `19851` (auto-increments if taken).
-3. Confirm **Enable LAN Discovery** is on (default) so `bricks devtools scan` can find it.
+3. Confirm **Enable LAN Discovery** is on (default) so the device is discoverable.
 4. Note the device passcode if displayed.
 
 Requires BRICKS Foundation **≥ 2.24** for CDP commands.
@@ -110,49 +100,16 @@ Requires BRICKS Foundation **≥ 2.24** for CDP commands.
 | Endpoint | URL shape | Use |
 |---|---|---|
 | Web UI | `http://<ip>:19851` | DevTools landing in a browser |
-| CDP | `devtools://devtools/bundled/inspector.html?ws=<ip>:19851/ws/<passcode>` | Chrome DevTools front-end (or `chrome://inspect`) |
-| MCP | `http://<ip>:19851/mcp` | Bridge to Claude Code via mcporter (below) |
+| CDP | `http://<ip>:19851/devtools-frontend/inspector.html?ws=<ip>:19851/ws/<passcode>` | Chrome DevTools front-end |
+| MCP | `http://<ip>:19851/mcp` | MCP endpoint (Bearer-token auth with passcode) |
 | MCP SSE | `http://<ip>:19851/sse` | Same, SSE transport |
+| Info | `http://<ip>:19851/devtools/info` | Device / server metadata |
 
-### Discover the device
-
-```
-bricks devtools scan
-bricks devtools open <ip>
-bricks devtools open <ip> --info   # show full URLs incl. CDP/MCP/passcode
-```
-
-### CDP commands against the device
+### Driving the device
 
-All `bricks devtools …` commands accept `-a <address> [-p <port>] [--passcode <pc>]`:
-
-```
-bricks devtools screenshot -a <ip> --passcode <pc> -o on-device.png
-bricks devtools brick tree -a <ip> --passcode <pc> -d 5
-bricks devtools brick query "[short-id='abc']" -a <ip> --passcode <pc>
-bricks devtools brick attributes <nodeId> -a <ip> --passcode <pc>
-bricks devtools brick box-model <nodeId> -a <ip> --passcode <pc>
-bricks devtools input tap 540 960 -a <ip> --passcode <pc>
-bricks devtools input type "test user" -a <ip> --passcode <pc>
-bricks devtools input key Enter -a <ip> --passcode <pc>
-bricks devtools storage data-bank list -a <ip> --passcode <pc>
-bricks devtools storage data-bank get <name> <store> -a <ip> --passcode <pc>
-bricks devtools storage system persist -a <ip> --passcode <pc>
-bricks devtools storage generator-cache -a <ip> --passcode <pc>
-bricks devtools network list -a <ip> --passcode <pc>
-bricks devtools network get <requestId> -a <ip> --passcode <pc>
-bricks devtools runtime eval "Object.keys(window)" -a <ip> --passcode <pc>
-```
-
-### Bridge the device into Claude Code via MCP
-
-For interactive agent-driven verification, bridge the device's MCP endpoint as a local STDIO server with mcporter:
-
-```
-npx mcporter --url http://<ip>:19851/mcp --header "Authorization: Bearer <passcode>"
-```
+Once DevTools is on, ask the user how they want to drive the verification — Chrome DevTools front-end, an MCP client they already run, or screenshot export from their own tooling — and follow their lead. Capture every Canvas screenshot through whichever path the user picks; the verification gate is about the evidence, not the tool.
 
-Configure Claude Code (or another MCP client) to spawn that command as an MCP server. The agent can then call the device's MCP tools the same way it calls `bricks-ctor` MCP tools.
+For agent-driven CDP/MCP work against the device (`bricks devtools …` with `-a <ip> --passcode <pc>`, plus bridging the device MCP endpoint into an MCP client), the same `bricks-cli` skill referenced in Path 1 covers the on-device case — read it if installed. If not installed, run `bricks --help` and `bricks devtools --help` for the authoritative command listing.
 
 ### Real-device side-effects warning
 
@@ -160,7 +117,7 @@ Real devices fire real peripherals. Payment terminals charge. MQTT broadcasts on
 
 ## Path 3 — Remote debugging via BRICKS Controller (off-LAN)
 
-Out of scope for the design loop. It exists for ops scenarios where the device is not on the same network. If the user asks for it, point them at the BRICKS Controller documentation rather than attempting it as part of design verification.
+Out of scope for the standard verification loop. It exists for ops scenarios where the device is not on the same network. If the user asks for it, point them at the BRICKS Controller documentation rather than attempting it as part of verification.
 
 ## Decision rule
 
@@ -199,7 +156,7 @@ if user is off-LAN
 - Re-mount test: cause the host to re-bind the Subspace; confirm internal state resets.
 
 ### Generator-driven reactive
-- Path 1: drive the source via `runtime eval` writes to Data; observe Brick re-render.
+- Path 1: drive the source by writing to Data from the runtime (whatever CDP path the user prefers); observe Brick re-render.
 - Throttle / firehose tests: write 100 updates rapidly; confirm the canvas doesn't choke (frame budget intact).
 - Disconnect: simulate source disconnect; confirm UI surfaces stale state, not blank.
 - Threshold transitions: cross every Switch boundary; confirm visual reaction.

package/skills/bricks-design/SKILL.md

@@ -22,9 +22,9 @@ description: >-
   design intent, or non-display deliverables (CLI, server, tooling).
   Encodes architecture truths, performance and complexity guardrails,
   input-translation rules, visual languages library, Direction
-  Advisor for vague briefs, Media Flow protocol for branded work,
-  verification toolchain (Electron preview MCP, on-device CDP,
-  Automations).
+  Advisor for vague briefs, Media Flow protocol for branded work.
+  Verification toolchain (compile/preview MCP, on-device DevTools,
+  Path 1/2/3) lives in the bricks-ctor skill.
 ---
 
 # BRICKS Design
@@ -128,33 +128,21 @@ Ship a one-paragraph trade-off note alongside so the user can pick or blend with
 
 **Definition of done — non-negotiable.** Before declaring a design complete, every one of the following must be true:
 
-1. The latest source compiles cleanly (`compile` MCP).
-2. You have produced a rendered screenshot of **every Canvas** in the deliverable via the `preview` MCP with `responseImage: true`, captured at the target hardware resolution and orientation. Cover every reachable state — Canvases gated behind events get reached by running an Automation (`testId` / `testTitleLike`).
-3. You have **viewed** each of those screenshots back through the host's image-reading capability — not just saved them. The agent that designed the Canvas must also have seen the rendered result.
-4. If the user supplied any reference material (Figma / website / HTML / screenshot / PDF / brand book), you have done a side-by-side visual comparison between each Canvas screenshot and the corresponding reference, and have written a short delta report listing:
+1. The source compiles cleanly.
+2. Every Canvas in the deliverable has a rendered screenshot at the target hardware resolution and orientation. Cover every reachable state — Canvases gated behind events get reached by running an Automation.
+3. The agent has **viewed** each of those screenshots back through the host's image-reading capability — not just saved them. The model that designed the Canvas must also have seen the rendered result.
+4. If the user supplied any reference material (Figma / website / HTML / screenshot / PDF / brand book), a side-by-side visual comparison has been done between each Canvas screenshot and the corresponding reference, with a short delta report listing:
    - What matches.
    - What intentionally diverges, and why (deployment constraint, system commitment, BRICKS-runtime limitation).
    - What unintentionally diverges, and how you will fix it.
-5. The verification path appropriate to the deployment has executed: Path 1 (Electron preview MCP) by default; Path 2 (on-device DevTools) when the deployment depends on real hardware behaviour, or whenever the brief touches payment, identity capture, peripherals, or LocalSync.
+5. The verification path appropriate to the deployment has executed (Path 1 Electron preview by default; Path 2 on-device DevTools when the deployment depends on real hardware, payment, identity capture, peripherals, or LocalSync).
 6. The browser / runtime console is clean — no 404s, no Data-key-undefined warnings, no Generator init failures.
 
 A single hero-Canvas screenshot is **not** done. A "looks roughly like the reference" handwave is **not** done. A claim of done without screenshots in evidence is **not** done. If you have not produced and reviewed a screenshot of every Canvas, you are still mid-iteration and must say so explicitly to the user.
 
-**Default loop — Path 1 (Electron preview, no device):**
+**Self-critique pass before declaring done** — every Canvas scored on 5 dimensions (system commitment / visual hierarchy / craft / functional fit / originality), anti-slop top-10 swept clean, < 8 scores either fixed or surfaced as accepted trade-offs. See [`references/design-critique.md`](references/design-critique.md). Verification proves it runs; critique proves it's good — both required.
 
-1. `bricks-ctor` MCP `compile` — typecheck + compile gate.
-2. `bricks-ctor` MCP `preview` with `responseImage: true` — screenshot + visual sanity. Add `testId` / `testTitleLike` to run a named Automation in the project (`brick_press`, `wait_until_canvas_change`, `assert_property`, `wait_property_update`, `match_screenshot`, ...).
-3. Repeat step 2 for every Canvas. Single-Canvas Subspaces still require a captured + reviewed screenshot.
-4. For sustained dev, `bun preview` exposes CDP at `localhost:19852`; drive it with `bricks devtools …` (screenshot, brick tree/query, input tap/type/key, storage data-bank, runtime eval, network list).
-5. **Self-critique pass before declaring done** — every Canvas scored on 5 dimensions (system commitment / visual hierarchy / craft / functional fit / originality), anti-slop top-10 swept clean, < 8 scores either fixed or surfaced as accepted trade-offs. See [`references/design-critique.md`](references/design-critique.md). Verification proves it runs; critique proves it's good — both required.
-
-**Escalate to Path 2 (device-bound DevTools)** before declaring done if the deployment depends on hardware behaviour the Electron preview cannot reproduce: physical orientation/DPI, real touch hardware, peripherals (camera/BLE/MQTT/NFC/payment/printer/sensors), watchdog cycles on the actual launcher build, LocalSync across multiple devices. **Always** Path 2 when the brief touches payment, identity capture, or peripherals.
-
-Path 2 setup is **manual** and the agent cannot do it: ask the user to open the device's **Settings → advanced → Chrome DevTools** toggle (requires BRICKS Foundation ≥ 2.24). The device starts CDP on `:19851`. Then `bricks devtools scan` / `open` / `screenshot` / `brick …` / `input …` / `storage …` / `runtime eval` work against the device address. The device's MCP endpoint can also be bridged into Claude Code with `npx mcporter --url http://<ip>:19851/mcp --header "Authorization: Bearer <passcode>"`.
-
-Path 3 (Remote Debugging via BRICKS Controller, off-LAN) exists for ops scenarios — out of scope for the design loop.
-
-Full toolchain table, decision rule, and concrete invocations: [`references/verification-toolchain.md`](references/verification-toolchain.md).
+For the toolchain itself — `compile` / `preview` MCP usage, `bun preview` flags, Project Automation cases, on-device DevTools setup, the Path 1/2/3 decision rule, and per-deployment-shape verification checklists — see the `bricks-ctor` skill's `rules/verification-toolchain.md`.
 
 ## Boundaries
 
@@ -181,7 +169,7 @@ Interaction / flow / journey / affordance / feedback / recovery / accessibility
 | Design a presentation / pitch deck / intro / explainer / slideshow (visual rhythm + hero continuity) | [`references/presentation-and-slideshow.md`](references/presentation-and-slideshow.md) |
 | Offer variations / pick what becomes a Data knob | [`references/variations-and-tweaks.md`](references/variations-and-tweaks.md) |
 | Self-critique on the visual dimensions | [`references/design-critique.md`](references/design-critique.md) |
-| Verify a design before shipping | [`references/verification-toolchain.md`](references/verification-toolchain.md) |
+| Verify a design before shipping | `bricks-ctor/rules/verification-toolchain.md` (companion skill) |
 | Propose visual directions for a vague brief | [`references/when-the-brief-is-vague.md`](references/when-the-brief-is-vague.md) |
 | Acquire and bind brand assets | [`references/when-the-brief-is-branded.md`](references/when-the-brief-is-branded.md) |
 | Compose a button so taps land where intended | `bricks-ux/references/pressable-composition.md` (companion skill) |

package/skills/bricks-design/references/design-critique.md

@@ -2,13 +2,13 @@
 
 The Verification gate proves the design *runs*. Critique proves it's *good*. Both are required before declaring done; neither substitutes for the other.
 
-This file gives the agent a structured self-review pass: five scoring dimensions with concrete rubrics, a per-deployment-shape focus chart, and an extended anti-slop top-10 with BRICKS-specific failure modes. Run the pass after the screenshots are captured and viewed (per [`verification-toolchain.md`](verification-toolchain.md)), and before declaring done to the user.
+This file gives the agent a structured self-review pass: five scoring dimensions with concrete rubrics, a per-deployment-shape focus chart, and an extended anti-slop top-10 with BRICKS-specific failure modes. Run the pass after the screenshots are captured and viewed (per `bricks-ctor/rules/verification-toolchain.md`), and before declaring done to the user.
 
 The point isn't to be self-critical for its own sake. The point is to catch the specific failure modes that consistently ship if not actively rooted out.
 
 ## How to run the pass
 
-1. **Verify** — compile clean + screenshot every Canvas + read screenshots back (see `verification-toolchain.md`).
+1. **Verify** — compile clean + screenshot every Canvas + read screenshots back (see `bricks-ctor/rules/verification-toolchain.md`).
 2. **Score** — for each Canvas, rate the five dimensions below 0–10 against the rubrics.
 3. **Anti-slop sweep** — walk the top-10 list; flag every match.
 4. **Fix anything < 8** and any anti-slop matches; re-verify.

package/skills/bricks-design/references/translating-inputs.md

@@ -149,4 +149,4 @@ Score everything against 5-10-2-8 before binding. If the source's brand binaries
 3. **Lift binaries to Media Flow.** Don't translate with embedded data; it pollutes the Subspace.
 4. **Walk per-Canvas.** For each Canvas, translate elements via the table above. Make explicit pressable decisions for every interactive element.
 5. **Wire the state machine.** Event chains for transitions; shared-Brick ids for chrome continuity; Standby for entrances.
-6. **Verify against the actual deployment** (see [`verification-toolchain.md`](verification-toolchain.md)). The translation is done when it runs on the target hardware, not when it looks right in the Electron preview.
+6. **Verify against the actual deployment** (see `bricks-ctor/rules/verification-toolchain.md`). The translation is done when it runs on the target hardware, not when it looks right in the Electron preview.

package/skills/bricks-ux/references/accessibility.md

@@ -156,7 +156,7 @@ Universal-access also covers cognitive accessibility — users who are tired, di
 
 1. **Confirm the audience and conditions** as part of Priority #0. Reduced-motor users? Multilingual? Outdoor sun? Night-shift fatigue? Each shifts which disciplines weight strongest.
 2. **Apply the seven disciplines as a baseline.** Each has a deployment-relative floor; calibrate to the conditions, not to a default.
-3. **Verify at the deployment.** Path 2 (on-device DevTools, see `bricks-design/verification-toolchain.md`) is the only way to confirm contrast under real lighting, touch-target size under real fingers, audio cue volume in real ambient.
+3. **Verify at the deployment.** Path 2 (on-device DevTools, see `bricks-ctor/rules/verification-toolchain.md`) is the only way to confirm contrast under real lighting, touch-target size under real fingers, audio cue volume in real ambient.
 4. **Surface gaps in trade-off notes.** A deployment that opts out of one of the seven (e.g., audio cues skipped because the hardware is muted; reduced motion skipped because the design language IS motion) must say so explicitly in the handoff.
 
 A design that passes visual critique but fails accessibility floors is not done. Accessibility critique runs in parallel.

package/tools/deploy.ts

@@ -3,6 +3,10 @@ import { parseArgs } from 'util'
 import { sh } from './_shell'
 import { buildCommitArgs } from './_git-author'
 
+if (!process.env.BRICKS_RELEASE_SIGN) {
+  process.env.BRICKS_RELEASE_SIGN = 'CTOR'
+}
+
 const cwd = process.cwd()
 
 const exists = async (p: string) => {