AI Flow

@@ -13,7 +13,7 @@ Every state-changing command takes `--ai-thread "<your thread name>"`. Every run  ## The flow -The flow is a file, `flows/board.json`: the steps in order (intake, placement, routing, pours, current, thermal, capture, finish), who does each, what the binary offers at each, and the steps that come later (components, libraries, schematic, simulation before the board; moleculize, paste, probe after it). For now the flow starts at parts placement and ends at a delivered, analysed board. `plan` prints it.+The flow is a file, `flows/board.json`: the steps in order (intake, models, placement, routing, pours, current, thermal, nets, 3d, capture, finish), who does each, what the binary offers at each, and the steps that come later (components, libraries, schematic, simulation before the board; moleculize, paste, probe after it). `models` (kicad_model_check) refuses to go on while any footprint lacks its 3D model, so the board renders as it will be built. `nets` (`tour nets`) selects each key net as a whole through the IPC API, pours, tracks, vias and pads together, and frames it with Zoom to Selected Objects, one net at a time on camera. `3d` (`tour 3d`) opens the 3D Viewer and runs the walkthrough by View-menu commands (kicad_3d_view: fit, top, tilt, orbit, zoom, swing, front, bottom, flip), no mouse, with the viewer window as the step's camera. `plan` prints the flow.  1. **`start --board B.kicad_pcb --spec spec.json --engine <you> --prompt-time <UTC of the paste> [--target <box> --remote-board <path on the box>]`**: copies the board into the run and starts the clock at the prompt, not at your first command. Record the paste time honestly. 2. **`plan`**: the stages this board needs and who can take each. Placement is yours (the binary helps: `place pack --wish`, `place check --moves`, `place land --moves`). Routing is the binary's grid router by default; say `take route=ai` if you route yourself. Pours, gate, landing, measurement, both analyses and the finish are the binary's.@@ -28,6 +28,8 @@ The flow is a file, `flows/board.json`: the steps in order (intake, placement, r  One clip per step. `capture open` puts the board on the test box; from then on every `step <name>` stops the previous step's clip and starts this step's own window recording, tagged with the step, and its hint says what that clip should show (the flow file's `record` line: the parts landing for placement, the nets landing for routing, the pours filling for pours, the return to an earlier step when an analysis fails). `deliver` lists the clips. The final video is cut from them, one segment per step, so two engines' videos line up step for step, and the page can show a little clip beside every step's numbers. +Per-step clips stay RAW: the recording, its 10x cut and its motion-only action cut carry no captions, because the final video (and a side-by-side of two runs) draws its own overlays from the ledger. `compose` builds the final 1920x1080 video: each step visit's 10x cut, decimated to motion, with the step chip, the engine and board, and the run and step timers as small hr / min / sec tables in the lower right (Adom faces), narrated by adom-tts from the ledger. No recording may outlive an hour (a hard cap on every recording), `finish` and `deliver` stop the running clip, and every command stops a clip that has run past twice its step's budget: a recorder left running is a mistake, not evidence.+ `capture open` puts the board on screen the same way for every engine (foreground OpenGL on a test box we own, maximised, zoom to fit). `capture start` records the PCB editor window itself through Adom Bridge's window recorder (Windows Graphics Capture, background-capturable: whatever another thread or an updater puts in front of KiCad on a shared box does not reach the take, and nobody at the box is disturbed; the monitor is recorded only when no editor is open), every stage command writes a marker with its timestamp into the manifest, `capture mark <label>` adds yours, `capture stop` pulls the MP4 into the run. The split-screen comparison (gang-takes split mode) aligns the two engines on those markers.  ## The spec

⋯ 1 unchanged line ⋯

⋯ 1 unchanged line ⋯

⋯ 1 unchanged line ⋯

⋯ 1 unchanged line ⋯

@@ -4,7 +4,7 @@ The evidence of a run is its video, and the video is built from the steps, not r  1. **One clip per step.** `step <name>` stops the previous clip and starts this step's own window recording of the editor. The flow file's `record` line says what the clip should show. 2. **The step's code frames the shot.** A landing zooms to fit before it starts; a move lands with the part on screen; a refusal stays in the clip because the refusal is the story.-3. **The binary cuts the sped-up clip and the action cut itself.** The action cut keeps only the frames that changed (near-duplicate frames dropped) with the real elapsed time burned into the corner, so a 27-minute routing landing becomes about two minutes of motion and the viewer still sees how long it really took. The run page and the final video use the action cuts.+3. **The binary cuts the sped-up clip and the action cut itself, both RAW.** The action cut keeps only the frames that changed (near-duplicate frames dropped, each kept frame held a quarter second), with no captions: overlays belong to the final video, so a side-by-side of two runs never paints overlays over overlays. `compose` draws the step chip, the engine and board, and the run and step timers (hr / min / sec tables, lower right, Adom faces) from the ledger onto each segment, and narrates it. 3b. **The sped-up clip.** When a clip stops it is pulled into the run and a 10x version is cut next to it (a 51 s routing landing becomes a 5.1 s clip). Both go into the ledger as artifacts of that step, with their seconds: `{"event":"artifact","step":"routing","kind":"clip","seconds":51.0,"file":...}` and `kind:"clip10x"`. 4. **Every step records what it made.** The routed board, the pours plan, the zone state, the analysis tables, the per-step table: all artifacts in the ledger, so the final cut knows what exists without anyone remembering. 5. **The final video is composed, not edited.** At `deliver` the binary (0.2) reads the artifacts, picks one segment per step (the 10x clips, the analysis cards, the finish line), targets about two minutes, and writes the composition: segment order, each segment's seconds, and the words for that segment.@@ -24,3 +24,7 @@ The final video is 1920 x 1080, 16:9, 30 fps, H.264 (yuv420p) with AAC audio, wh ## Plan usage is per account  The plan-usage snapshots are the provider's per-account numbers. Every AI thread signed in as the same user draws on them, so a run made while other threads were working shows their usage too. The run page says so under the table; read the delta as an upper bound unless the run was the only thread active.++## The clip guard++No recording may outlive an hour: every recording is started with a hard cap. `finish` and `deliver` stop the running clip, and every command stops a clip that has run past twice its step's budget and writes a marker saying so. A recorder left running once recorded nine hours of a static editor; that cannot happen again.

@@ -1,7 +1,7 @@ {   "name": "board",   "title": "The board flow: parts placement to a qualified board",-  "scope": "Starts at parts placement on a board whose schematic, libraries and part choices already exist. Ends when the board is 100 percent routed, DRC-clean, poured, its copper measured, its current and thermal analyses passed, and the AI has delivered the video.",+  "scope": "Starts at the 3D models and parts placement on a board whose schematic, libraries and part choices already exist. Ends when the board is 100 percent routed, DRC-clean, poured, its copper measured, its current and thermal analyses passed, its nets and its 3D view walked through on camera, and the AI has delivered the video.",   "steps": [     {       "name": "intake",@@ -9,6 +9,15 @@       "does": "read the board and the spec, write the spec from the schematic if it is missing, plan",       "record": "nothing on screen yet: the clip is the board opening on the test box (capture open) and the spec being read"     },+    {+      "name": "models",+      "who": "ai",+      "does": "every footprint on the board has its 3D model resolved (kicad_model_check): fetch the vendor STEP, build one, or fix the path, so the board renders as it will be built; a bare footprint in the 3D view is a missing model",+      "binary": [+        "models"+      ],+      "record": "nothing to film: the model check's list and the fixes; the 3D walkthrough later is the proof"+    },     {       "name": "placement",       "who": "ai",@@ -61,6 +70,24 @@       ],       "record": "same: the hot tabs and their copper; when it fails, the return to pours or placement is the clip worth keeping"     },+    {+      "name": "nets",+      "who": "binary",+      "does": "walk the key nets on camera: each loaded, wide or Kelvin net selected as a whole so the editor highlights its pours, tracks, vias and pads together, framed with Zoom to Selection",+      "binary": [+        "tour nets"+      ],+      "record": "the editor with one net lit at a time, framed; the markers say which net"+    },+    {+      "name": "3d",+      "who": "binary",+      "does": "the 3D walkthrough: the viewer opened from the editor, then fit, top, tilt, orbit, zoom in, swing, front, bottom, flip, top, fit, all by menu command, no mouse",+      "binary": [+        "tour 3d"+      ],+      "record": "the 3D Viewer window itself: the board turning, the components up close; full of motion, so the action cut keeps most of it"+    },     {       "name": "capture",       "who": "binary",

@@ -1,7 +1,7 @@ {   "slug": "adom-aiflow",   "type": "app",-  "version": "0.1.10",+  "version": "0.1.11",   "title": "AI Flow",   "description": "Adom's AI Flow: a tool to help the AI follow all of the steps it takes to build a board. One Rust binary with a crate per step (placement helpers, a grid router with Kelvin taps, pours with keepouts, KiCad's DRC gate, live landing through the KiCad Bridge, copper measurement, current and thermal analysis) and a finish line that refuses an unfinished board. Every command answers with hints for the AI; every turn, its thinking time and every rework loop go into run.jsonl, so Claude, Codex and any other engine are compared on the same flow. KiCad today; Altium, Fusion and Adom's own web apps next.",   "summary": "Adom's AI Flow: a tool to help the AI follow all of the steps it takes to build a board. The AI thinks its way from placement through routing, pours, current and thermal analysis to a delivered video; the binary does the fast, deterministic parts of every step, hands back hints, and keeps a ledger of every turn, every return to an earlier step, and the clock from the prompt to done.",

@@ -1,7 +1,7 @@ {   "slug": "adom-aiflow",   "type": "app",-  "version": "0.1.10",+  "version": "0.1.11",   "title": "AI Flow",   "description": "Adom's AI Flow: a tool to help the AI follow all of the steps it takes to build a board. One Rust binary with a crate per step (placement helpers, a grid router with Kelvin taps, pours with keepouts, KiCad's DRC gate, live landing through the KiCad Bridge, copper measurement, current and thermal analysis) and a finish line that refuses an unfinished board. Every command answers with hints for the AI; every turn, its thinking time and every rework loop go into run.jsonl, so Claude, Codex and any other engine are compared on the same flow. KiCad today; Altium, Fusion and Adom's own web apps next.",   "summary": "Adom's AI Flow: a tool to help the AI follow all of the steps it takes to build a board. The AI thinks its way from placement through routing, pours, current and thermal analysis to a delivered video; the binary does the fast, deterministic parts of every step, hands back hints, and keeps a ledger of every turn, every return to an earlier step, and the clock from the prompt to done.",

@@ -13,7 +13,7 @@ Every state-changing command takes `--ai-thread "<your thread name>"`. Every run  ## The flow -The flow is a file, `flows/board.json`: the steps in order (intake, placement, routing, pours, current, thermal, capture, finish), who does each, what the binary offers at each, and the steps that come later (components, libraries, schematic, simulation before the board; moleculize, paste, probe after it). For now the flow starts at parts placement and ends at a delivered, analysed board. `plan` prints it.+The flow is a file, `flows/board.json`: the steps in order (intake, models, placement, routing, pours, current, thermal, nets, 3d, capture, finish), who does each, what the binary offers at each, and the steps that come later (components, libraries, schematic, simulation before the board; moleculize, paste, probe after it). `models` (kicad_model_check) refuses to go on while any footprint lacks its 3D model, so the board renders as it will be built. `nets` (`tour nets`) selects each key net as a whole through the IPC API, pours, tracks, vias and pads together, and frames it with Zoom to Selected Objects, one net at a time on camera. `3d` (`tour 3d`) opens the 3D Viewer and runs the walkthrough by View-menu commands (kicad_3d_view: fit, top, tilt, orbit, zoom, swing, front, bottom, flip), no mouse, with the viewer window as the step's camera. `plan` prints the flow.  1. **`start --board B.kicad_pcb --spec spec.json --engine <you> --prompt-time <UTC of the paste> [--target <box> --remote-board <path on the box>]`**: copies the board into the run and starts the clock at the prompt, not at your first command. Record the paste time honestly. 2. **`plan`**: the stages this board needs and who can take each. Placement is yours (the binary helps: `place pack --wish`, `place check --moves`, `place land --moves`). Routing is the binary's grid router by default; say `take route=ai` if you route yourself. Pours, gate, landing, measurement, both analyses and the finish are the binary's.@@ -28,6 +28,8 @@ The flow is a file, `flows/board.json`: the steps in order (intake, placement, r  One clip per step. `capture open` puts the board on the test box; from then on every `step <name>` stops the previous step's clip and starts this step's own window recording, tagged with the step, and its hint says what that clip should show (the flow file's `record` line: the parts landing for placement, the nets landing for routing, the pours filling for pours, the return to an earlier step when an analysis fails). `deliver` lists the clips. The final video is cut from them, one segment per step, so two engines' videos line up step for step, and the page can show a little clip beside every step's numbers. +Per-step clips stay RAW: the recording, its 10x cut and its motion-only action cut carry no captions, because the final video (and a side-by-side of two runs) draws its own overlays from the ledger. `compose` builds the final 1920x1080 video: each step visit's 10x cut, decimated to motion, with the step chip, the engine and board, and the run and step timers as small hr / min / sec tables in the lower right (Adom faces), narrated by adom-tts from the ledger. No recording may outlive an hour (a hard cap on every recording), `finish` and `deliver` stop the running clip, and every command stops a clip that has run past twice its step's budget: a recorder left running is a mistake, not evidence.+ `capture open` puts the board on screen the same way for every engine (foreground OpenGL on a test box we own, maximised, zoom to fit). `capture start` records the PCB editor window itself through Adom Bridge's window recorder (Windows Graphics Capture, background-capturable: whatever another thread or an updater puts in front of KiCad on a shared box does not reach the take, and nobody at the box is disturbed; the monitor is recorded only when no editor is open), every stage command writes a marker with its timestamp into the manifest, `capture mark <label>` adds yours, `capture stop` pulls the MP4 into the run. The split-screen comparison (gang-takes split mode) aligns the two engines on those markers.  ## The spec