@fugood/bricks-ctor 2.25.0-beta.47 → 2.25.0-beta.48

package/compile/__tests__/index.test.js

@@ -1,7 +1,14 @@
 jest.mock('../../tools/_shell', () => ({
-  sh: jest.fn(() => Promise.resolve({})),
+  sh: jest.fn(),
 }))
 
+// Mirrors the chainable `sh` result (supports `.nothrow()` like the real helper).
+const shResult = (over = {}) => {
+  const result = Promise.resolve({ exitCode: 0, stdout: '', stderr: '', ...over })
+  result.nothrow = () => result
+  return result
+}
+
 import { mkdir, mkdtemp, readFile, rm, writeFile } from 'node:fs/promises'
 import os from 'node:os'
 import path from 'node:path'
@@ -57,7 +64,8 @@ const commandOf = ([strings, ...values]) =>
 
 describe('checkConfig', () => {
   beforeEach(() => {
-    sh.mockClear()
+    sh.mockReset()
+    sh.mockImplementation(() => shResult())
   })
 
   test('runs doctor after check-config', async () => {
@@ -68,6 +76,20 @@ describe('checkConfig', () => {
       'bricks app doctor --validate-automation .bricks/build/application-config.json',
     ])
   })
+
+  test('skips doctor when the CLI lacks the command', async () => {
+    sh.mockReturnValueOnce(shResult()) // check-config
+    sh.mockReturnValueOnce(shResult({ exitCode: 1, stderr: "error: unknown command 'doctor'" }))
+
+    await expect(checkConfig('config.json')).resolves.toBeUndefined()
+  })
+
+  test('throws when doctor reports config errors', async () => {
+    sh.mockReturnValueOnce(shResult()) // check-config
+    sh.mockReturnValueOnce(shResult({ exitCode: 1, stderr: 'DATA_RACE: conflicting writes' }))
+
+    await expect(checkConfig('config.json')).rejects.toThrow()
+  })
 })
 
 describe('compile animations', () => {

package/compile/index.ts

@@ -1494,6 +1494,11 @@ export const checkConfig = async (configPath: string) => {
   // which catches agent-authored automations that reference deleted bricks.
   await sh`bricks app check-config --validate-automation ${configPath}`
   // Doctor adds semantic lint checks after structural validation. Warnings are
-  // surfaced in the compile log, but only errors fail by default.
-  await sh`bricks app doctor --validate-automation ${configPath}`
+  // surfaced in the compile log, but only errors fail by default. Older published
+  // bricks-cli builds lack `app doctor` — skip rather than fail the compile.
+  const doctor = await sh`bricks app doctor --validate-automation ${configPath}`.nothrow()
+  if (doctor.exitCode !== 0) {
+    if (/unknown command/i.test(doctor.stderr?.toString() ?? '')) return
+    throw new Error(`bricks app doctor failed with exit ${doctor.exitCode}`)
+  }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fugood/bricks-ctor",
-  "version": "2.25.0-beta.47",
+  "version": "2.25.0-beta.48",
   "main": "index.ts",
   "scripts": {
     "typecheck": "tsc --noEmit",
@@ -11,7 +11,7 @@
     "@babel/parser": "7.28.5",
     "@babel/traverse": "7.28.5",
     "@babel/types": "7.28.5",
-    "@fugood/bricks-cli": "^2.25.0-beta.46",
+    "@fugood/bricks-cli": "^2.25.0-beta.48",
     "@huggingface/gguf": "^0.3.2",
     "@iarna/toml": "^3.0.0",
     "@modelcontextprotocol/sdk": "^1.15.0",
@@ -29,5 +29,5 @@
   "peerDependencies": {
     "oxfmt": "^0.36.0"
   },
-  "gitHead": "95f194a3fb6331c0f25a879e55675e3ff331a412"
+  "gitHead": "6403fb9aece6b9ee45a72a963ddc75aec5ae3e04"
 }

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

@@ -122,6 +122,25 @@ Once DevTools is on, ask the user how they want to drive the verification — Ch
 
 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.
 
+### Running real-device Automations from an agent
+
+There is no `bricks devtools automation` subcommand. Use the DevTools runtime helpers exposed inside the app:
+
+```bash
+bricks devtools runtime eval -a <ip> -p 19851 --passcode <pc> "Object.getOwnPropertyNames(automation).sort()" -j
+bricks devtools runtime eval -a <ip> -p 19851 --passcode <pc> "automation.list()" -j
+bricks devtools runtime eval -a <ip> -p 19851 --passcode <pc> "automation.run('<TEST_id>', { updateScreenshot: false })" --await -j
+```
+
+`automation.run()` starts the device-side run and may return `null`; treat that as accepted, not as a pass/fail result. Wait for the run timeout/window, then verify completion through the app's own state and a screenshot. For app state, use live runtime reads such as:
+
+```bash
+bricks devtools runtime eval -a <ip> -p 19851 --passcode <pc> "JSON.stringify({ result: system.data.property('<S_xxxx>', '<resultAlias>')?.value })" -j
+bricks devtools screenshot -a <ip> -p 19851 --passcode <pc> -o /tmp/device-automation.png
+```
+
+In CTOR Desktop sandboxed sessions, keep these as separate simple commands. Avoid multi-line shell scripts, `for` loops, brace expansion, and command substitution around `bricks devtools`; those can stay sandboxed and lose LAN/device access. After `bun update-app` or a device refresh, the DevTools socket may briefly drop, so wait and probe with one screenshot or one `runtime eval` before running the automation.
+
 ### Real-device side-effects warning
 
 Real devices fire real peripherals. Payment terminals charge. MQTT broadcasts on shared topics. BLE advertises to bystanders. Use a **staging** device for verification cycles; never iterate on a production-deployed device unless the user explicitly approves.