-The orchestrator's forward direction is framed as two arcs toward a **full (autonomous) cook orchestrator** — "completed spec → feature built and glued into a real brownfield repo, no manual steps." **Arc 1 (feature delivery)** stacks on FE-843 and ships standalone without the semantic stack. `agent-extension-host` (the dual-mode pi-harness contract) **bases the Arc-1 linear stack** (2026-06-15 decision) — every Arc-1 frontier sits on it — followed by `brunch-detect` (resolve a registry profile id from repo manifest/lockfile evidence at plan time) → `harness-dep-install` (capture the dependency-delta for promotion + classify install/infra failures distinctly from test failures; the install action itself is agent-native) → `app-runtime-probe` (build + boot + exercise the host app — the concrete reachability mechanism) → `integration-oracle` (wire into host + product reachability, via the probe) → `brownfield-promotion` (glue back into the checkout) → `brunch-ship` (one-shot wrapper). A `dogfood-spike` (ln-spike) — run the full chain on one real brunch feature — should precede committing `integration-oracle`, to surface the reachability mechanism, dep-install, orientation depth, and brownfield plan-shape risks cheaply. CLI command surface (kitchen brigade; frontier ids stay descriptive): detect → `brunch prep`, plan → `brunch recipe`, orchestrate → `brunch cook`, verify → `brunch taste`, promote → `brunch plate`, ship → `brunch serve`. The settled grounding decision is **cook-time** (planning stays host-blind per D160-K; the cook agent resolves real paths/wiring by reading the worktree), which softens FE-829's `writes` ownership to *advisory in brownfield only* — greenfield keeps it authoritative. Protecting invariant: **brownfield generalization must not change greenfield-mode behavior; shared contracts fork on `plan.mode`** (the 3 reference fixtures + a greenfield smoke must score identically before/after each frontier). **Arc 2 (full orchestrator)** is an autonomy ladder gated behind the parked semantic/Petri-Phase-3/4 substrate: `interactive-recovery` (halt → coherent question answered in a secondary chat, resumes the run) → `intent-conformance-oracle` (independent behavioral-kernel verification, requisite variety) → `adaptive-replan` (architect amends the plan from execution feedback, recompile + resume). Each rung raises the autonomy ceiling and is independently shippable. Non-additive work (refactors/migrations/debugging) is explicitly a separate `transformation-orchestrator` product line, not folded into either arc. The cook-time grounding decision, the D160-K `writes`-advisory amendment, and the greenfield-protecting invariant need recording in SPEC via ln-sync when the first Arc-1 frontier is scoped. **Agent-host coordination:** the pi harness is a dual-mode (`elicit`/`execute`) agent-extension host (`agent-extension-host`) — cook capabilities are `execute`-mode plugins on a shared, mode-neutral core; this contract is the serialization point with the unpublished pi-harness thread (which owns the core), validated against the existing interview as the `elicit` witness. It logically gates only the dispatch-seam frontiers (`integration-oracle`, Arc-2 `interactive-recovery`/`adaptive-replan`), but is sequenced at the **base of the Arc-1 linear stack** (2026-06-15 decision) — so the whole arc lands on it, deliberately serializing the cook stack behind the pi-harness-thread coordination rather than running the seam-independent infra (`brunch-detect`, `harness-dep-install`, `app-runtime-probe`, `brownfield-promotion`) in parallel ahead of it.
0 commit comments