@fugood/bricks-project 2.25.0-beta.21 → 2.25.0-beta.22

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fugood/bricks-project",
-  "version": "2.25.0-beta.21",
+  "version": "2.25.0-beta.22",
   "main": "index.ts",
   "scripts": {
     "typecheck": "tsc --noEmit",

package/package.json.bak

@@ -1,6 +1,6 @@
 {
   "name": "@fugood/bricks-ctor",
-  "version": "2.25.0-beta.21",
+  "version": "2.25.0-beta.22",
   "main": "index.ts",
   "scripts": {
     "typecheck": "tsc --noEmit",

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, 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.
+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, harness-specific preview tool, 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,7 +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 |
+| [Verification Toolchain](rules/verification-toolchain.md) | Definition of done, compile, preview tool selection, on-device DevTools, Path 1/2/3 decision rule |
 
 ## Quick Reference
 

package/skills/bricks-ctor/rules/architecture-patterns.md

@@ -26,6 +26,8 @@ The primary way to orchestrate multi-step flows. A single event can contain an a
 - Use `dataParams` + `mapping` to pass event data downstream
 - This is the "glue" that wires generators, state, and UI together
 
+Sequential `PROPERTY_BANK` / `PROPERTY_BANK_EXPRESSION` actions in one chain read the data values that existed when the chain started. If a later action needs to read what an earlier action wrote, set `waitAsync: true` on the earlier action.
+
 ### System Actions (Priority 3)
 Built-in commands for direct state and UI changes.
 - **PROPERTY_BANK**: set data value
@@ -67,3 +69,13 @@ Only actual data derivation maps to Data Calculation:
 
 ### Step 4: Wire with Event Action Chains
 Connect the pieces through events on generators and bricks.
+
+## Recipe: user-driven state machine (calculator, form wizard, picker)
+
+A brief like "state vars X, Y, Z; button A updates X from X+Y; button B resets" is a state machine. The shape:
+
+- Each state variable is its own `Data` entity. Displays read it via `linkData(() => data.dFoo)`.
+- Each button's `onPress` is an Event Action Chain. For every state var that changes, append one `PROPERTY_BANK_EXPRESSION` whose `expression` reads the current state and returns the new value.
+- Use `Data Calculation` only for reusable pure derivations referenced as inputs to those expressions.
+
+A 10-button calculator with 4 state vars is ~10 small chains of 1–4 inline expressions. If you find yourself writing a single auto-mode `DataCalculationScript` that consumes all state vars and emits all-new state through mirror `dFooResult` data — or pinging a `dLastInput` field to force an auto calc to re-run — the chain shape was the right answer.

package/skills/bricks-ctor/rules/data-calculation.md

@@ -167,7 +167,7 @@ code: `
 
 ## Triggering Manually
 
-Use `PROPERTY_BANK_COMMAND` system action to trigger a manual calculation:
+Use `PROPERTY_BANK_COMMAND` system action to trigger a manual calculation. `input` references a Data that is a trigger input (`trigger: true`) of the target calc — the system runs the calc(s) that data feeds into. It does NOT reference the DataCalculation itself.
 
 ```typescript
 const triggerCalc: EventAction = {
@@ -176,7 +176,7 @@ const triggerCalc: EventAction = {
     __actionName: 'PROPERTY_BANK_COMMAND',
     parent: 'System',
     dataParams: [
-      { input: () => computeTotalCalc }, // Reference to DataCalculation
+      { input: () => priceData }, // Reference to a trigger Data input of the calc
     ],
   },
 }
@@ -194,9 +194,7 @@ const triggerCalc: EventAction = {
 See [Architecture Patterns](architecture-patterns.md) for the full pattern selection guide.
 
 ### Using Data Calc as an orchestrator
-Scripts that manage state machines, control UI flow, or coordinate multi-step processes belong in Event Action Chains, not here.
-
-**Symptom**: Script has if/else branches deciding "what happens next" or tracks "current step".
+Scripts that manage state machines, control UI flow, or coordinate multi-step processes belong in Event Action Chains. Symptoms: if/else on "what happens next", mirror `dFooResult` outputs that copy back to `dFoo` via `valueChange`, or a `dLastInput` field set-then-cleared to force an auto calc. See the "user-driven state machine" recipe in [Architecture Patterns](architecture-patterns.md).
 
 ### Quick reference
 

package/skills/bricks-ctor/rules/verification-toolchain.md

@@ -7,7 +7,7 @@ Three runtime targets, one decision rule. Verify against the cheapest path that
 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.
+2. **Every Canvas screenshot captured.** A rendered screenshot of every Canvas in the deliverable, captured via the available preview tool (`responseImage: true` when the selected model supports vision) 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 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.
@@ -30,23 +30,30 @@ If any item is unmet, the work is mid-iteration. Say so explicitly to the user;
 
 The default loop. Always available; deterministic; no device wear; safe for side-effecting flows because nothing real fires.
 
-### `bricks-ctor` MCP — `compile`
+`bun update-app` and `bun deploy-app` publish to the BRICKS portal. The local preview reads `.bricks/build/application-config.json` (produced by `compile`) directly.
+
+### Compile tool
 
 Typecheck + compile the project. Gate every iteration on this; everything below assumes a clean compile.
 
 Agent invocation: call the MCP tool `compile` exposed by the `bricks-ctor` MCP server registered for the project. No arguments.
 
-### `bricks-ctor` MCP — `preview`
+### Preview tool
+
+Use the preview implementation exposed by the current harness:
+
+- **CTOR Desktop agent session:** use `preview_invoke`. CTOR Desktop disables the `bricks-ctor` MCP `preview` tool and routes screenshots/automation through the desktop preview pane instead. If the user already opened the simulator pane, `preview_invoke` should reuse it rather than start a separate preview.
+- **Pure `bricks-ctor` project / other agent harness:** use the `bricks-ctor` MCP `preview` tool when `preview_invoke` is not available.
 
-Launches headless Electron, takes a screenshot, optionally runs a named Automation test by id or partial title.
+Both forms are the same verification primitive: launch or reuse Electron preview, take a screenshot, and optionally run a named Automation test by id or partial title. Do not hard-code one tool name into the workflow; choose the available preview tool for the environment.
 
-Arguments:
-- `delay` (ms before screenshot) — default 3000. Increase if Standby Transitions are still in flight.
+Common arguments:
+- `delay` (ms before screenshot) — default is harness-specific: usually 3000 for a fresh/standalone preview; CTOR Desktop may capture immediately when its preview already has a settled latest config. Increase if Standby Transitions are still in flight.
 - `width`, `height` — screenshot dimensions in px.
-- `responseImage: true` — return base64 jpeg as MCP image content (recommended for visual sanity).
+- `responseImage: true` — return the screenshot as image content when the selected model supports vision. If vision is unavailable, save the screenshot and report the path.
 - `testId` or `testTitleLike` — run a project Automation before the screenshot. Use `testTitleLike` for fuzzy matches (case-insensitive partial title).
 
-Returns text log + (if `responseImage`) base64 image content.
+Returns text log + saved screenshot path + image content when supported.
 
 ### `bun preview` (project script)
 
@@ -76,7 +83,7 @@ Trigger types: `launch` (runs on app start), `anytime` (manual), `cron` (schedul
 
 Important: the automation map id must be `'AUTOMATION_MAP_DEFAULT'` (not a generated id) — the preview test runner reads from `automationMap['AUTOMATION_MAP_DEFAULT']?.map`.
 
-Run a single test from the agent: `bricks-ctor` MCP `preview` with `testId` or `testTitleLike`.
+Run a single test from the agent: call the available preview tool (`preview_invoke` in CTOR Desktop, otherwise `bricks-ctor` MCP `preview`) with `testId` or `testTitleLike`.
 
 ## Path 2 — Real device with DevTools enabled
 

package/skills/bricks-design/SKILL.md

@@ -23,7 +23,7 @@ description: >-
   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 (compile/preview MCP, on-device DevTools,
+  Verification toolchain (compile, preview tool selection, on-device DevTools,
   Path 1/2/3) lives in the bricks-ctor skill.
 ---
 

package/skills/bricks-design/references/variations-and-tweaks.md

@@ -57,7 +57,7 @@ Use when variations share most of the Brick tree but differ on a chunk that can'
 - Each variant Subspace imports the shared module and overrides only the variant-specific chunk.
 - Bricks reused by reference, not duplicated.
 
-**Comparison surface:** screenshot per variant via preview MCP, assembled in chat.
+**Comparison surface:** screenshot per variant via the available preview tool, assembled in chat.
 
 **Token cost:** 1 shared module + N small variant Subspaces.
 

package/types/generators/ThermalPrinter.ts

@@ -71,11 +71,11 @@ Default property:
   property?: {
     /* Connect printer on generator initialized */
     init?: boolean | DataLink
-    /* Connection driver */
-    driver?: 'escpos' | 'star' | 'tsc' | DataLink
-    /* The address of the printer */
+    /* Connection driver (`castles` driver: built-in or WiFi printer on Castles Saturn PDA) */
+    driver?: 'escpos' | 'star' | 'tsc' | 'castles' | DataLink
+    /* The address of the printer (For castles driver: `mode=builtin` (Saturn 1000) or `mode=wifi` (Saturn 7000); optional `heatLevel=1-5`, default 3) */
     connectString?: string | DataLink
-    /* The language of the printer (only for EPSON) */
+    /* The language of the printer (only for EPSON and TSC drivers) */
     lang?: 'ANK' | 'CHINESE' | 'TAIWAN' | 'KOREAN' | 'THAI' | 'SOUTHASIA' | DataLink
     /* The timeout of scanning */
     scanTimeout?: number | DataLink
@@ -99,10 +99,12 @@ Default property:
  { type: 'barcode', content: '1234567890', barcodeType: 'CODE128' }  
  { type: 'symbol', content: '1234567890', symbolType: 'QRCODE' }  
  Notes:  
- - `reverse-feed` only works on ESC/POS driver  
+ - `reverse-feed` works on ESC/POS driver and castles driver (line mode only)  
  - `width` and `height` in Star driver is magnification factor  
  - `y` position in ESC/POS is use feed lines to offset  
- - `textFont` only works on TSC driver */
+ - `textFont` only works on TSC driver  
+ - castles driver: `image` requires `height` in line mode  
+ - castles driver: `UPC_A`, `UPC_E`, `ITF` barcode types are not supported */
     payload?:
       | Array<
           | DataLink
@@ -149,7 +151,7 @@ Default property:
             }
         >
       | DataLink
-    /* Raw ASCII commands to print */
+    /* Raw ASCII commands to print (not supported on castles driver) */
     rawCommands?: string | DataLink
   }
   events?: {