space-architect 2.0.2 → 4.0.0

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*
@@ -112,7 +122,9 @@ lanes pass; the CLI does the git mechanics. Canonical path:
 architect integrate <iteration> --lanes <passing-set>   # e.g. --lanes lane-a,lane-b
 architect gate <iteration>                              # integration smoke (raw output; verdict stays yours)
 architect integrate <iteration> --lanes <passing-set> --teardown   # or remove worktrees + lane branches after
-architect land                                          # end of project: prints gh pr create --base main --head project/<slug>
+# end of project: landing is the architect's, not a CLI command — write the PR
+# body to build/land/<repo>-pr-body.md yourself, then present the paste-and-run
+# block (cd, git push -u origin project/<slug>, gh pr create) — see SKILL.md §6
 ```
 
 `architect integrate` commits each named lane on its branch and merges it
@@ -138,8 +150,8 @@ git -C repos/<repo> merge --no-ff lane/<iteration>-<lane>
 <run the gate commands>          # integration smoke after every merge
 architect worktree remove <iteration> <lane>
 git -C repos/<repo> branch -d lane/<iteration>-<lane>
-# at project end:
-architect land                   # prints gh pr create --base main --head project/<slug>
+# at project end there is no CLI step: the architect writes
+# build/land/<repo>-pr-body.md and presents the push + gh pr create block
 ```
 
 ### Parallel + fast-follow
@@ -155,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
    ```
@@ -170,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: 2.0.2
+  version: 4.0.0
 platform: ruby
 authors:
 - Eric Jacobs
@@ -240,6 +240,7 @@ files:
 - exe/src
 - lib/space_architect.rb
 - lib/space_architect/architect_project.rb
+- lib/space_architect/bug_report.rb
 - lib/space_architect/cli.rb
 - lib/space_architect/cli/architect.rb
 - lib/space_architect/cli/research.rb
@@ -271,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
@@ -281,6 +283,7 @@ files:
 - lib/space_core/cli/show.rb
 - lib/space_core/cli/status.rb
 - lib/space_core/cli/use.rb
+- lib/space_core/commands.rb
 - lib/space_core/config.rb
 - lib/space_core/errors.rb
 - lib/space_core/git_client.rb
@@ -288,6 +291,7 @@ files:
 - lib/space_core/oci_builder.rb
 - lib/space_core/oci_packer.rb
 - lib/space_core/oci_runner.rb
+- lib/space_core/paths.rb
 - lib/space_core/repo_reference.rb
 - lib/space_core/repo_resolver.rb
 - lib/space_core/shell_integration.rb