space-architect 3.0.0 → 4.0.0

data/lib/space_src/cli/clone.rb

@@ -2,7 +2,6 @@
 
 require "pastel"
 require "dry/monads"
-require "space_src/cli"
 require "space_src/cli/options"
 require "space_src/cloner"
 

data/lib/space_src/cli/config.rb

@@ -2,7 +2,6 @@
 
 require "pastel"
 require "yaml"
-require "space_src/cli"
 require "space_src/ui/mode"
 require "space_src/cli/options"
 

data/lib/space_src/cli/daemon.rb

@@ -3,7 +3,6 @@
 require "pastel"
 require "fileutils"
 require "dry/monads"
-require "space_src/cli"
 require "space_src/ui/mode"
 require "space_src/cli/options"
 require "space_src/launchd/agent"

data/lib/space_src/cli/org.rb

@@ -2,7 +2,6 @@
 
 require "pastel"
 require "dry/monads"
-require "space_src/cli"
 require "space_src/ui/mode"
 require "space_src/cli/options"
 

data/lib/space_src/cli/repo.rb

@@ -2,7 +2,6 @@
 
 require "pastel"
 require "dry/monads"
-require "space_src/cli"
 require "space_src/ui/mode"
 require "space_src/cli/options"
 

data/lib/space_src/cli/shell.rb

@@ -1,6 +1,5 @@
 # frozen_string_literal: true
 
-require "space_src/cli"
 require "space_src/shell_integration"
 
 module Space::Src

data/lib/space_src/cli/status.rb

@@ -1,7 +1,6 @@
 # frozen_string_literal: true
 
 require "pastel"
-require "space_src/cli"
 require "space_src/ui/mode"
 require "space_src/cli/options"
 

data/lib/space_src/cli/sync.rb

@@ -1,7 +1,6 @@
 # frozen_string_literal: true
 
 require "dry/monads"
-require "space_src/cli"
 require "space_src/cli/repo"  # for Repo::Helpers.parse_ref
 require "space_src/cli/options"
 require "space_src/ui/mode"

data/lib/space_src/cli.rb

@@ -1,7 +1,6 @@
 # frozen_string_literal: true
 
 require "dry/cli"
-require "space_src"
 require "space_src/migration"
 
 module Space::Src

data/skill/architect/SKILL.md

@@ -121,8 +121,11 @@ loop.
   gate (test/lint/typecheck/build commands) from docs or CI config.
 - Once per environment: `claude --version` and confirm the builder model
   resolves (`echo ok | claude -p --model <builder-model> --max-turns 1`;
-  details in `dispatch.md`). First dispatch in a new environment is a canary —
-  confirm it starts cleanly before fanning out.
+  details in `dispatch.md`). Past that one-time check, every foreground dispatch
+  self-verifies — it prints a liveness line naming the streamed model and
+  confirming the run log is growing (a WARN line instead if the streamed model
+  disagrees with the pin or the log isn't growing) — so no lone lane needs
+  launching-and-watching before the fan-out.
 - Read `architecture/ARCHITECT.md` (the cross-iteration table of contents),
   `architecture/BRIEF.md` if present (the durable §-numbered project contract you
   cite as BRIEF §N), and the iteration file `architecture/I<NN>-<name>.md` for any
@@ -245,9 +248,17 @@ contract, self-contained:
   task.
 - **Lane plan** — split the iteration into 1–4 parallel lanes, each declaring
   its **target repo + file-touch set, checked for overlap**: name the repo
-  (`repos/<repo>`) and every file each lane may touch. Lanes in *different*
-  repos are inherently disjoint; same-repo lanes with any file overlap run as
-  one. Each lane gets its own objective, output format, and boundaries. Most
+  (`repos/<repo>`) and every file each lane may touch. The machine-readable
+  declaration lives in a fenced ` ```lanes ` block in the Specification — one
+  entry per lane (`name`, `repo`, `touch` globs) — the single frozen source of
+  truth `architect freeze` records into `space.yaml` and `architect provision`
+  materializes. The touch-set now lives *with* the frozen spec by design: it
+  closes the drift where a `worktree add --touch` flag could diverge from the
+  spec's intent. The scaffold ships a commented ` ```lanes ` stub in the
+  Specification (see `templates/iteration.md.erb`) — uncomment it. Lanes in
+  *different* repos are inherently disjoint; same-repo lanes with any file
+  overlap run as one. Each lane gets its own objective, output format, and
+  boundaries. Most
   iterations are one lane — fan out only when the work is genuinely parallel (a
   cross-repo project often is). Two first-class patterns — runnable recipes in `dispatch.md`: **parallel +
   fast-follow** (disjoint lanes integrate first; a fast-follow lane off
@@ -293,13 +304,24 @@ once a frozen section changed afterward.
 
 ### 5. Dispatch (one fresh `claude -p` per lane, worktree-isolated)
 
-Per the mechanics in `dispatch.md`:
-
-- **1 lane** → dispatch in the target repo's checkout (`repos/<repo>`).
-- **2–4 lanes** → `architect worktree add <repo> <iteration> <lane>
-  [--base <repo-base>]` per lane (creates `build/<id>-<lane>/wt` off the target
-  repo's base commit — a repo commit, distinct from the freeze, which is a
-  space commit — and records it in `space.yaml`).
+Per the mechanics in `dispatch.md`. The lane lifecycle is **declare → freeze →
+provision → write prompts → dispatch** — every lane gets a worktree; there is no
+dispatch-in-the-checkout path:
+
+- **Declare** — at spec time, each lane is one entry in the Specification's
+  fenced ` ```lanes ` block (§4): `name`, `repo`, `touch` globs.
+- **Freeze** — `architect freeze` parses that block and records each lane
+  (name, repo, touch_set) into `space.yaml`.
+- **Provision** — `architect provision <iteration>` materializes every declared
+  lane's worktree + `lane/<id>-<lane>` branch in one shot, each off the resolved
+  base (`--base` override, else `project/<slug>` when it exists, else the repo's
+  default branch — a repo commit, distinct from the freeze, which is a space
+  commit) and recorded in `space.yaml`; it is idempotent, and `--lane <name>`
+  provisions a single lane. The manual `architect worktree add` it wraps stays
+  registered as an internal primitive for edge cases — not a step you run.
+- `dispatch`, `integrate`, and `gate` auto-materialize a lane whose worktree is
+  missing from its frozen declaration, so a lane you didn't pre-provision can't
+  dead-end the flow.
 
 Assemble each lane's lane-prompt (the template in `dispatch.md` + this lane's
 section of the Specification + the frozen Acceptance Criteria) and write it to
@@ -363,9 +385,9 @@ it (never hand-resolve). A cross-repo project yields one `project/<slug>` branch
 per touched repo. `main` is never touched per-iteration — `--teardown` deletes
 only the per-lane `lane/<iteration>-<lane>` branches and worktrees, never the
 project branch. Update the iteration index in `architecture/ARCHITECT.md`
-(recording the `project/<slug>` branch), remove the worktrees (`architect
-integrate … --teardown`, or `architect worktree remove <iteration> <lane>`), and
-commit the space.
+(recording the `project/<slug>` branch), remove the provisioned worktrees
+(`architect integrate … --teardown`, or `architect worktree remove <iteration>
+<lane>`), and commit the space.
 
 **Run the frozen gates cold** — `architect gate <iteration>` runs the frozen
 gate commands against the integration tree and streams raw output (a runner, not

data/skill/architect/dispatch.md

@@ -27,12 +27,15 @@ pattern match), so the post-flight `git log` is what the loop actually trusts.
 If a lane committed, treat the worktree as tampered: reset and re-dispatch.
 
 **Preflight (once per environment):** run `claude --version`, and confirm the
-builder model resolves with a one-shot canary
+builder model resolves with a one-shot
 (`echo ok | claude -p --model <builder-model> --max-turns 1`). No API key —
 the builder runs on your Claude plan — but note headless `claude -p` draws on
 the Agent SDK credit pool (separate from interactive usage since June 15 2026;
-see `docs/DESIGN.md` §4). On the first real dispatch in a new environment, launch
-ONE canary lane and confirm it starts cleanly before fanning anything out.
+see `docs/DESIGN.md` §4). Past that one-time check, no dispatch needs a manual
+start-check: every foreground dispatch self-verifies. Shortly after launch it
+prints a liveness line to stderr naming the streamed model and confirming the
+run log is growing — or a WARN line instead when the streamed model disagrees
+with the pinned `<builder-model>` or the log isn't growing.
 
 ## Canonical dispatch — `architect dispatch <iteration> <lane>`
 
@@ -49,23 +52,30 @@ Write the lane's prompt to `build/<id>-<lane>/prompt.md` first (never pass a
 big prompt as a shell argument — shells mangle quotes), then:
 
 ```bash
-# single-lane iteration — run from the space root
+# single-lane iteration — run from the space root; dispatch runs in the lane's
+# provisioned worktree (materialized on demand from the frozen declaration)
 architect dispatch <iteration> <lane>
 ```
 
-For multi-lane iterations, create worktrees first (one per lane), then dispatch
-each lane from its worktree:
+For multi-lane iterations, materialize every declared lane in one shot with
+`architect provision`, then dispatch each lane from its worktree:
 
 ```bash
-# per lane:
-architect worktree add <repo> <iteration> <lane> [--base <repo-base>]
-architect dispatch <iteration> <lane>
+architect provision <iteration>          # all declared lanes: worktree + lane/<id>-<lane> branch
+architect dispatch <iteration> lane-a    # own background Bash call each
+architect dispatch <iteration> lane-b
 ```
 
-`architect worktree add` creates `build/<id>-<lane>/wt` off the target repo's
-base commit (a repo commit — distinct from the freeze, which is a space
-commit), adds it with a `lane/<iteration>-<lane>` branch, and records it in
-`space.yaml`.
+`architect provision` reads the frozen lane declarations from `space.yaml` and,
+per lane, creates `build/<id>-<lane>/wt` off the resolved base (`--base`
+override, else `project/<slug>` when it exists, else the repo's default branch —
+a repo commit, distinct from the freeze, which is a space commit), adds it with a
+`lane/<iteration>-<lane>` branch, and records it in `space.yaml`. It is
+idempotent (`--lane <name>` provisions a single lane), and wraps the
+`architect worktree add` primitive — still registered for edge cases, not a step
+in the flow. `dispatch`, `integrate`, and `gate` also lazily materialize a lane
+whose worktree is missing from its frozen declaration, so the flow can't
+dead-end on a missing worktree.
 
 Issue each dispatch as its **own background Bash tool call** — one call per
 lane. Never use a shell `&` loop. A `for … & done` launcher is a *launcher*
@@ -157,10 +167,12 @@ integrate without conflict.
    fast-follow lane's `--touch` set and exclude them from every parallel lane's
    touch-set — so the parallel set is disjoint by construction.
 
-2. **Create worktrees and dispatch the parallel lanes** (off the repo base):
+2. **Provision and dispatch the parallel lanes** (off the repo base). Provision
+   only the parallel lanes by name — leave the fast-follow lane unmaterialized
+   until step 4, so it can root at the integrated tip:
    ```bash
-   architect worktree add <repo> <iteration> lane-a
-   architect worktree add <repo> <iteration> lane-b
+   architect provision <iteration> --lane lane-a
+   architect provision <iteration> --lane lane-b
    architect dispatch <iteration> lane-a   # own background Bash call each
    architect dispatch <iteration> lane-b
    ```
@@ -172,11 +184,11 @@ integrate without conflict.
    architect gate <iteration>
    ```
 
-4. **Create the fast-follow lane off the integrated tip.** `--base` accepts any
-   git ref — passing `project/<slug>` roots the new worktree at the merged tip
-   (the keystone move):
+4. **Provision the fast-follow lane off the integrated tip.** `--base` accepts
+   any git ref — passing `project/<slug>` roots the new worktree at the merged
+   tip (the keystone move); `--lane ff` provisions just that lane:
    ```bash
-   architect worktree add <repo> <iteration> ff --base project/<slug>
+   architect provision <iteration> --lane ff --base project/<slug>
    architect dispatch <iteration> ff
    ```
 

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: space-architect
 version: !ruby/object:Gem::Version
-  version: 3.0.0
+  version: 4.0.0
 platform: ruby
 authors:
 - Eric Jacobs
@@ -272,6 +272,7 @@ files:
 - lib/space_core/cli/helpers.rb
 - lib/space_core/cli/init.rb
 - lib/space_core/cli/list.rb
+- lib/space_core/cli/loop_status.rb
 - lib/space_core/cli/new.rb
 - lib/space_core/cli/pack.rb
 - lib/space_core/cli/path.rb