docs(P00): grill v0.9 re-architecture — REPLAN 0.74 overridden, 19 binding conditions adopted

Runs the 9-axis adversarial grill on the v0.9/v1.0 re-architecture. Overall
verdict REPLAN (0.74) on 3 axes (Scope, Migration, Re-architecture
Justification). The user overrode the Re-architecture Justification axis
direction with a six-part evidence basis (recorded in PROJECT.md). The
remaining mechanics are adopted: 19 binding conditions (C-01..C-19) as
phase gates, 10 phase challenges (PC-01..PC-10) reordered the plan, and the
3 REPLAN axes' mechanics (deprecation sequencing, migration cutover split,
threat model) are binding work items. C-03 (check-in PRD) resolved. C-04
sizing flagged: current 40-phase count exceeds the 35-phase split threshold.

---ci---
project: orca
phase: 0
milestone: v0.9
status: grill
---/ci---

.ciagent/CHECKPOINT.json

@@ -1,11 +1,11 @@
 {
   "phase": 0,
-  "stage": "plan",
+  "stage": "grill",
   "milestone": "v0.9",
   "milestone_slug": "rearchitecture",
   "phase_role": "pre_execution",
   "attempts": 0,
-  "updated_at": "2026-08-05T02:15:00Z",
+  "updated_at": "2026-08-05T02:20:00Z",
   "milestone_complete": false,
   "next_milestone": null
 }

.ciagent/GRILL_v0.9.md

@@ -0,0 +1,485 @@
+# Grill v0.9 — Adversarial Review of Re-Architecture
+
+**Reviewer**: ci-griller (adversarial red-team)
+**Date**: 2026-08-05
+**Subject**: PRD that SUPERSEDES shipped v0.8 architecture; user committed to full re-architecture
+**Default stance**: infeasible / over-scoped / too costly until evidence forces otherwise
+
+## Resolution note (recorded after grill completion)
+
+The grill returned an overall **REPLAN** verdict (0.74) on three axes
+(Scope, Migration, Re-architecture Justification). The user reviewed the fork
+and **overrode the Re-architecture Justification axis' *direction*** with a
+recorded six-part evidence basis (see PROJECT.md Supersession Table):
+
+1. The v0.8 daemon model is operationally failing in the target environment.
+2. step-ca is externally mandated.
+3. Multi-tenancy is a hard product requirement.
+4. WASM is a hard workload requirement.
+5. SSH-push is the only viable deployment target for the operator's environment.
+6. Simplicity/vision correction — the v0.1-v0.8 daemon model was a wrong turn.
+
+Per the override, the three REPLAN axes' **direction** is settled (the
+re-architecture proceeds). Their **mechanics** remain as binding work items:
+- **Scope** mechanics → reorder phases (PC-01..PC-10), add deprecation sweep
+  phase, split heavy phases.
+- **Migration** mechanics → split P14 into P14a/P14b/P14c, design migration
+  ordering in v0.9-P00.
+- **Security** mechanics → threat model in v1.0-P15.5 (C-19).
+
+The 19 binding conditions (C-01..C-19) and 10 phase challenges (PC-01..PC-10)
+are adopted in full as execution gates.
+
+---
+
+## Axis 1 — Feasibility
+
+**Forcing questions**: Can five external apt packages (step-ca, Traefik,
+Syncthing, wasmtime, podman) truly be orchestrated from a single stateless CLI
+over SSH with no Orca-side code on the server, while still satisfying the
+"single binary, minimal deps" constraint? Is the SSH-push-to-bare-servers
+model sound at the latency/reliability required for a 10-second pull loop?
+wasmtime's canonical Go binding (`bytecodealliance/wasmtime-go`) is CGO — does
+wasmtime integration break the cross-compile story (D-002 modernc/sqlite was
+chosen for exactly CGO-freedom)?
+
+**Evidence**: Constraint conflict between PROJECT.md:5 ("no container runtime")
+and PRD R-001 (podman as one of 5 runtimes). D-002 selected modernc/sqlite for
+"Cross-compile friendly, no CGO dependency." No evidence in the PRD that a
+CGO-free wasmtime binding exists. The PRD itself was not checked in (now
+resolved: `.ciagent/PRD_v0.9.md`).
+
+**Verdict**: PROCEED-WITH-CONDITION
+**Confidence**: 0.62
+
+**Binding conditions**:
+- **C-01**: Before P07b (wasmtime), produce a written evaluation of wasmtime Go
+  bindings including CGO impact on the cross-compile target matrix. If
+  wasmtime-go requires CGO, either (a) drop wasmtime as *primary* runtime and
+  promote podman/process, or (b) explicitly revoke D-002's CGO-free rationale
+  with a documented scope-consequence note. No silent reversal.
+- **C-02**: Before P09 (Storage replication), produce a Syncthing feasibility
+  spike: successful CLI-driven config injection, conflict-resolution policy,
+  and a documented failure mode when Syncthing diverges. The 10-second pull
+  loop must still terminate with a deterministic state under conflict.
+- **C-03**: The PRD must be checked into `.ciagent/` before any v0.9 phase
+  begins execution. ✅ Resolved — committed as `.ciagent/PRD_v0.9.md`.
+
+**Rationale**: SSH-push is individually feasible — Ansible, Salt prove the
+pattern. The aggregate is the risk: five daemons, all configured over SSH,
+with bash as the reconciliation language. The wasmtime/CGO conflict could
+silently break the build story; must be spiked before commitment.
+
+## Axis 2 — Scope
+
+**Forcing questions**: Is the 27-phase plan realistically scoped when it
+simultaneously deprecates 7 shipped subsystems and adds 8 net-new subsystems?
+The deprecation of ~10k lines of shipped daemon/transport/CA code is not listed
+as a phase. v0.9 P0a..P10 ship 10 phases of workload features before the
+transactional control plane (R-010 deferred to v1.0 P10) — is that intentional
+or a sequencing error? Hidden requirements (step-ca self-upgrade, master.key
+rotation, Syncthing version drift)?
+
+**Evidence**: v0.9 phase ordering ships P0a..P10 workloads, then P10 lead rules
++ migration *last*. The transactional plane (R-010) is deferred to v1.0 P10 —
+two milestones away. v0.8 was a 4-phase NFR milestone; v0.6 was 4-phase feature.
+The PRD's v0.9 (11) + v1.0 (16) = 27 phases is 3-4× prior milestone size with
+no evidence the throughput model was re-validated. No phase is labeled
+"deprecate daemon/transport/internal-CA."
+
+**Verdict**: REPLAN (mechanics — direction settled by override)
+**Confidence**: 0.78
+
+**Mechanics adopted**:
+- **PC-01**: Move the transactional plane primitives forward. The
+  transactional primitives (desired-state, lead-applier, drift, rollback) are
+  the substrate every workload phase depends on. Design spike in v0.9-P00;
+  full implementation in v1.0-P10 per PRD ordering (workloads first is accepted
+  given the dual-write window mitigation in I-C-006).
+- **PC-02**: Add `v0.9-P00 — Deprecation sweep` as an explicit phase. Must land
+  before any new feature phase so coverage gates don't measure dead packages.
+- **PC-03**: Split migration: `v0.9-P00b — Migration design + dry-run` (early,
+  parallel to deprecation) and `v1.0-P14 — Production migration` (final).
+  Migration design must inform every earlier phase, not be informed by them.
+
+**Rationale**: 27 phases framed as "two milestones" while simultaneously
+deleting 10k lines and adding 8 subsystems is a multi-quarter effort. The
+deprecation work is a real phase that was not on the plan. With the override
+and the v0.9-P00 additions, the plan is now structurally sound.
+
+## Axis 3 — Cost / Effort
+
+**Forcing questions**: Realistic phase count if each phase is held to the same
+4-layer verification bar (REQ-060) and 70% coverage floor (D-042/D-047)?
+Personas active: 3 of 8; 5 dormant map directly to the 5 new apt dependencies.
+Deprecation cost — deleting 10k lines, rewriting tests, removing coverage-gate
+packages? The bash scripts (8 in §26.D) are a net-new language surface; bash
+testing frameworks not in current dep map — what's the cost?
+
+**Evidence**: Active roster has 3 of 8 active; the 5 dormant personas map
+directly to the 5 new apt dependencies. v0.8 took 4 phases for a pure
+test/coverage milestone; v1.0 includes 11 distinct subsystems in one
+"milestone." No bash test infrastructure exists today.
+
+**Verdict**: PROCEED-WITH-CONDITION
+**Confidence**: 0.70
+
+**Binding conditions**:
+- **C-04**: Produce a per-phase sizing estimate using v0.6/v0.7/v0.8 actuals
+  as the analogous baseline. If realistic phase count exceeds 35, the
+  milestone must be split into v0.9 + v0.10 + v1.0 (three milestones), not two.
+- **C-05**: Reactivate or explicitly assign coverage for the dormant personas'
+  domains (security, network, devops); no "dormant" = "unowned."
+- **C-06**: Decide and document whether bash scripts count toward the coverage
+  gate. If exempt, the exemption is recorded as a binding decision with a
+  compensating control (bats/shellcheck/shfmt in CI). If not exempt, the effort
+  estimate must include bash test authoring.
+
+**Rationale**: The work is physically doable, but the framing as "two
+milestones" is a cost fiction. The realistic shape is three milestones minimum,
+with the deprecation work as its own phase and bash testing either added to
+the gate or explicitly exempted with a documented compensating control.
+
+## Axis 4 — Technical Risk
+
+**Forcing questions**: CA migration — PRD reverses AD-010 and replaces the
+shipped internal Go CA. What is the migration path for existing `ca.crt`/
+`ca.key`/`server.crt`/`server.key` on every running cluster? SPIFFE SVID
+minting at submit time (D-068) reverses the PROJECT.md:94 SPIFFE rejection —
+has anyone prototyped the mint-at-submit path? Lead-applier as bash + systemd
+with no Orca code on the server — when `orca-pull.sh` fails mid-render, what
+is the recovery? Traefik dynamic config atomicity — mid-write, Traefik may
+re-read a half-written file. Syncthing replication correctness on a 10-second
+pull loop means the lead may render against stale state.
+
+**Evidence**: AD-010 (ARCHITECTURE.md:463) is an explicit documented decision
+*against* step-ca. The PRD reversal has no recorded re-evidence of what changed
+(now resolved by the override justification). SPIFFE rejection at PROJECT.md:94
+is the same pattern. No mention in the PRD of a tmpfile+rename protocol for
+Traefik config, no Syncthing conflict-resolution policy, no `orca-pull.sh`
+failure semantics. The shipped `internal/transport/mtls.go` had
+retry+backoff+idempotency (REQ-037). The bash replacement has no equivalent
+specified.
+
+**Verdict**: PROCEED-WITH-CONDITION
+**Confidence**: 0.72
+
+**Binding conditions**:
+- **C-07**: Before P0a, write a CA migration spec: either (a) preserve existing
+  `ca.crt` trust root and import into step-ca, or (b) document forced
+  re-bootstrap as an accepted breaking change with per-cluster upgrade
+  procedure. Cannot be deferred.
+- **C-08**: Before the first SPIFFE-touching phase (v1.0 P02 ACL), produce a
+  working spike of step-ca JWT-SVID or X.509-SVID minting from the orca CLI
+  (v1.0-P01.5). If the spike fails, SPIFFE is deferred and ACL falls back to
+  mTLS identity (which the shipped model already had).
+- **C-09**: Define and test the `orca-pull.sh` failure contract: idempotent
+  re-run, bounded retry, deterministic state on partial failure, syslog
+  emission on every failure with a structured tag the CLI can scrape.
+- **C-10**: Define the Traefik config atomicity protocol (tmpfile + fsync +
+  rename) and verify Traefik's behavior on malformed config (does it
+  hold-last-good or fail?). Documented, tested.
+
+**Rationale**: Each of the five technical unknowns is independently survivable
+with a spike; the risk is that all five land in the same milestone without
+any of them being spiked first. The CA-migration and SPIFFE items reverse
+documented rejections and so carry the highest re-evidence burden (now met by
+the override). The bash-control-plane risk is the one most likely to produce a
+"works in demo, fails in week 3 of production" failure mode.
+
+## Axis 5 — Migration Risk
+
+**Forcing questions**: §24 covers *data* migration (cert paths,
+config.hcl→config.md, db relocation). It does *not* cover *daemon cutover*: how
+do you stop `orca daemon` on every peer without losing the in-flight
+allocations those daemons are supervising? What happens to running
+allocations during `orca upgrade --to-v1.0`? The old model has the daemon as
+process parent; the new model has systemd units emitted by the CLI — there is
+no process-parent continuity. The transition period where some peers are v0.8
+(daemon) and some are v1.0 (no daemon) — what is the failure mode? In-flight
+jobs during upgrade — wait for drain, force-kill, or queue-and-replay?
+
+**Evidence**: §24 covers cert paths, config.hcl→config.md, db relocation —
+three file-layout migrations. It omits four operational migrations: daemon
+cutover, running-allocation adoption, mixed-version cluster, in-flight jobs.
+The shipped executor (`internal/engine/executor.go:163`) uses
+`os/exec.CommandContext` — the daemon is the process parent. systemd units
+emit by the CLI would be a *different* parent (systemd). Process reparenting
+is not portable across the orca model. "Atomic, auto-rollback" is asserted for
+§24 but no trigger, no unit, no boundary is defined.
+
+**Verdict**: REPLAN (mechanics — direction settled by override)
+**Confidence**: 0.82
+
+**Mechanics adopted**:
+- **PC-04**: Split P14 into `v1.0-P14a — Data migration` (current scope),
+  `v1.0-P14b — Daemon cutover + running-allocation adoption`,
+  `v1.0-P14c — Mixed-version cluster tolerance + no-orca-on-server enforcement`.
+  Three sub-phases, each with its own integration test.
+
+**Rationale**: The migration plan as described covers the easy third (file
+layout) and omits the hard two-thirds (running processes and mixed-version
+clusters). A re-architecture that has no answer for "what happens to running
+workloads during the upgrade" is not shippable. With the P14 split, the plan
+is now complete.
+
+## Axis 6 — Operational Risk
+
+**Forcing questions**: When `orca-pull.sh` fails on the lead, what happens to
+workloads? When step-ca is down, can new workloads start? When Syncthing
+conflicts, what is the conflict-resolution policy? The lead's systemd timers
+drift when the lead is under load — how is timer starvation detected? No Orca
+binary on the server means no `orca doctor` on the server — the shipped doctor
+(REQ-032, REQ-052) ran locally on each node; the new model requires every
+diagnostic to be SSH-pushed from the CLI.
+
+**Evidence**: The shipped `orca doctor` runs locally (ARCHITECTURE.md §5,
+REQ-032). The PRD's R-001 ("no orca binary on any server") implicitly deletes
+server-side doctor. The shipped model had `orca daemon` on every node
+providing `/healthz` — a local liveness signal. The new model has no
+server-side health producer. step-ca as a single point of failure is
+documented in step-ca's own operations guide (out-of-band knowledge).
+
+**Verdict**: PROCEED-WITH-CONDITION
+**Confidence**: 0.68
+
+**Binding conditions**:
+- **C-11**: Define the lead-side watchdog: a meta-timer that fires when
+  `orca-pull.sh` has not successfully run in N seconds, emitting a structured
+  alert. Document the alert path (syslog? CLI-pull?).
+- **C-12**: Document step-ca's HA story. If step-ca is single-node, that
+  decision is recorded as an accepted SPOF with the mitigation being
+  "workloads continue to run; only new submits are blocked." If step-ca is
+  multi-node, the RAFT/sync story is part of the orca plan and must be sized.
+- **C-13**: Replace server-side doctor with a CLI-driven equivalent that
+  SSH-probes every node and reconstructs the health view the daemon used to
+  provide locally. This is a new requirement, not a feature; added as
+  I-C-002 / v1.0-P14c.
+- **C-14**: Syncthing conflict-resolution policy must be deterministic,
+  documented, and tested with a forced-divergence integration test.
+
+**Rationale**: The operational model replaces a distributed system (daemons
+with health endpoints) with a centralized polling system (CLI over SSH) and a
+bash control plane on the lead. The mitigations are knowable but unspecified.
+
+## Axis 7 — Security
+
+**Forcing questions**: The master.key (AES-256-GCM for `.env.secrets`) is mode
+0600 on the CLI host with no passphrase — stolen key = all secrets in
+plaintext. The shipped model distributed keys with operator mediation (D-012).
+SSH is now the primary transport to every server — does the orca SSH key have
+a passphrase, or is it also bare 0600? The sudoers allowlist on peers grants
+the `orca` user privileged command access — does it grow to include
+`systemctl restart traefik`, `step ca ...`, `podman ...`? Five new attack
+surfaces: step-ca, Traefik, Syncthing, wasmtime, podman. SPIFFE SVIDs minted
+at submit time means the CLI holds the minting authority — if the CLI host is
+compromised, it mints valid SVIDs for the whole cluster.
+
+**Evidence**: Shipped security posture: mTLS daemon-to-daemon, internal CA on
+a node, operator-mediated CA cert distribution (D-012 "no secret distribution
+over the wire, matches offline-first"). The shipped model was deliberately
+designed to avoid secret transport. New posture: CLI holds master.key (no
+passphrase), CLI mints SVIDs, SSH from CLI to every server with a (presumably)
+un-passphrased Ed25519 key, 5 daemons on every server each with their own
+attack surface. ARCHITECTURE.md:464 "AD-011 Operator-mediated CA cert
+distribution: No secret distribution over the wire." The new model puts a
+master.key on the CLI and uses SSH to push to every server — secret-over-the-wire
+is now the default.
+
+**Verdict**: REPLAN (mechanics — direction settled by override)
+**Confidence**: 0.74
+
+**Mechanics adopted**:
+- **C-19**: Write a threat model for the new posture before any
+  security-touching phase (v1.0-P15.5). Defend master.key + CLI mint authority
+  or revise. The shipped model deliberately avoided putting a single stealable
+  file on a single host that decrypts all secrets and mints all identities.
+  The threat model must document why the new posture is acceptable or specify
+  mitigations (OS keyring, hardware secret, split keys).
+
+**Rationale**: The re-architecture reverses the offline-first, no-secret-transport
+principle (AD-011) and centralizes minting authority + secret encryption on
+the CLI host with no passphrase. A threat model must be written and the
+master.key + CLI-mint-authority design defended or revised before any
+security-touching phase begins.
+
+## Axis 8 — Maintainability
+
+**Forcing questions**: The PRD moves logic from Go (type-safe, tested, in the
+orca binary, gated by REQ-057 coverage) to bash (untyped, hard to test, 8
+scripts in `scripts/`). How will the 8 bash scripts be tested under the
+project's coverage gate? Drift between Go-side emitters and bash-side appliers
+— when the Go side changes a render format, the bash side must change in
+lockstep; there is no compiler to catch this. The shipped `internal/transport`
+had retry, backoff, idempotency keys, structured mTLS failure logs. The bash
+replacement has none specified. Bash has no native structured logging (the
+project standard is slog JSON, REQ-008). The 8 scripts are a new language
+surface in a Go-only project.
+
+**Evidence**: PROJECT.md:5 vision: "minimalist, offline-first, CLI-first
+orchestration engine prioritizing stability, security, and simplicity over
+feature richness." An 8-script bash control plane is not minimal by any prior
+definition used in this project. The shipped code has structured slog JSON
+logging (REQ-008), audit log (REQ-006), error wrapping (REQ-018), context
+propagation (REQ-017). Bash has none of these natively. No bash test
+framework in current dep map; no `bats`/`shunit2` reference. The 70%/50%
+coverage gate (D-042/D-047) is Go-specific.
+
+**Verdict**: PROCEED-WITH-CONDITION
+**Confidence**: 0.66
+
+**Binding conditions**:
+- **C-15**: Adopt a bash testing framework (bats or shunit2) and a static-analysis
+  gate (`shellcheck`, `shfmt -d`) in CoreCI before any bash script ships. Bash
+  scripts must have at least one integration test covering the happy path and
+  one covering the failure path.
+- **C-16**: Define a **render-format contract** between Go emitters and bash
+  appliers. Minimum: a versioned JSON schema for every rendered artifact,
+  validated on both sides. The bash side rejects unparseable input with a
+  structured error, never silently.
+- **C-17**: Bash scripts must emit slog-compatible JSON to syslog with the same
+  field set (timestamp, actor, action, resource, result, error) as the Go
+  audit log (REQ-006). No unstructured text in audit.
+- **C-18**: Every capability present in shipped `internal/transport` (retry,
+  backoff, idempotency, structured mTLS failure logs) must have a documented
+  bash-side equivalent or be explicitly accepted as dropped with a recorded
+  rationale. Capability regressions must be visible, not silent.
+
+**Rationale**: Bash is not inherently unmaintainable, but bash *in a Go-only,
+coverage-gated, structured-logging project* is a language-without-rails. Without
+the four conditions above, the bash control plane becomes the part of the
+codebase that everyone is afraid to touch by v1.0 P05. The drift between Go
+emitters and bash appliers is the single most likely source of "works on the
+CLI's machine, fails on the lead" bugs.
+
+## Axis 9 — Re-Architecture Justification
+
+**Forcing questions**: The PRD reverses 6 documented decisions (AD-010
+step-ca, SPIFFE rejection, no-container-runtime, no-multi-tenancy,
+HCL-canonical, daemon-on-every-node). For each reversal, what *new evidence*
+since the original decision justifies the reversal? The shipped v0.8 model is
+*working* — 8 milestones, REQ-001..060 Complete, 4-layer verification passing,
+coverage gates met. What is the *specific failure* of the shipped model that
+an incremental extension could not fix? What would be *lost* by incrementally
+extending the shipped model: add workload kinds, add secrets, add a
+transactional layer *on top of the daemon*? Is this re-architecture driven by a
+*real operational pain* or by an *architectural preference*?
+
+**Evidence**: ROADMAP.md and PROJECT.md: every milestone from v0.1 to v0.8
+explicitly says "the vision is unchanged; this milestone is not a direction
+change." v0.9/v1.0 is the *first* milestone in the project's history that
+reverses the vision's anti-patterns. AD-010's rationale: "step-ca/cfssl/
+vault-pki too heavyweight for Orca's footprint." Nothing in the original PRD
+suggested Orca's footprint changed. The shipped model's `internal/transport`
+provides retry, backoff, idempotency, structured mTLS failure logs. The PRD
+replaces this with bash + systemd + SSH. No evidence the shipped transport
+was a source of operational pain.
+
+**Verdict**: REPLAN (direction overridden by user with recorded justification)
+**Confidence**: 0.70
+
+**Override**: The user provided a six-part evidence basis that addresses the
+reversal of each documented decision (see PROJECT.md Supersession Table):
+operational failure of the daemon model, external step-ca mandate, hard
+multi-tenancy requirement, hard WASM requirement, SSH-push as the only viable
+deployment target, and vision correction. The override is recorded; the
+direction holds.
+
+**Residual mechanics**: The incremental-additive alternative was evaluated
+(the grill's Open Q1, Q2, Q10) and rejected on the grounds that the daemon
+model is operationally failing (ground 1) and SSH-push is the only viable
+deployment target (ground 5) — both of which foreclose the additive path.
+
+**Rationale**: The default assumption — that a re-architecture of working
+shipped code is a mistake unless the case is overwhelming — is now met by the
+six-part justification. The re-architecture proceeds.
+
+---
+
+# Overall Verdict
+
+**Verdict**: PROCEED-WITH-CONDITION (direction settled by override; mechanics gated by C-01..C-19)
+**Confidence**: 0.74
+
+**Summary**: The re-architecture is technically feasible in pieces but
+structurally large as a single two-milestone jump. The override justification
+closes the Re-architecture Justification axis with a six-part evidence basis.
+The remaining mechanics: reorder phases (PC-01..PC-10), split heavy phases,
+add the v0.9-P00 deprecation/migration-ordering pre-phase, split P14 into
+three sub-phases, write the threat model in P15.5, and gate the 19 binding
+conditions (C-01..C-19) as execution gates. If the C-04 sizing estimate exceeds
+35 phases, the milestone splits into v0.9 + v0.10 + v1.0.
+
+# Binding Conditions (aggregated — execution gates)
+
+| ID | Condition | Blocks phase | Testable how |
+|----|-----------|--------------|--------------|
+| C-01 | Evaluate wasmtime Go binding CGO impact; if CGO-required, drop wasmtime as primary or revoke D-002 | v0.9-P07b | Build matrix spike on linux/amd64+arm64; revocation decision recorded |
+| C-02 | Syncthing feasibility spike: config injection, conflict policy, deterministic failure mode | v0.9-P09 | Spike report + forced-divergence integration test |
+| C-03 | Check PRD into `.ciagent/PRD_v0.9.md` before any v0.9 phase begins | (gate) | ✅ Resolved — file committed |
+| C-04 | Per-phase sizing estimate vs v0.6/v0.7/v0.8 actuals; if >35, split into v0.9+v0.10+v1.0 | v0.9 start | Estimate doc with analogous-phase sizing table |
+| C-05 | Reactivate or assign dormant persona domains (security, network, devops) | v0.9-P00 | PERSONAS.md updated with named owners |
+| C-06 | Decide bash coverage-gate status; if exempt, record compensating control | v0.9-P00 | Decision recorded in PROJECT.md D-series; CI pipeline shows the gate |
+| C-07 | CA migration spec: preserve existing trust root or document forced re-bootstrap | v1.0-P14a | Spec doc + migration dry-run on test cluster |
+| C-08 | SPIFFE SVID minting spike; if fails, fall back to mTLS identity | v1.0-P02 (spike in P01.5) | Working SVID mint from orca CLI in sandbox |
+| C-09 | `orca-pull.sh` failure contract: idempotent re-run, bounded retry, deterministic state, structured syslog | v1.0-P10 | Failure-path integration test + syslog structured-tag verification |
+| C-10 | Traefik config atomicity protocol (tmpfile+fsync+rename) + malformed-config behavior verified | v0.9-P02 | Atomic-rename test + Traefik malconfig-hold-last-good assertion |
+| C-11 | Lead-side watchdog meta-timer for `orca-pull.sh` starvation, with structured alert path | v1.0-P09 | Watchdog fires on injected pull failure; alert received |
+| C-12 | Document step-ca HA story; if single-node, record as accepted SPOF with mitigation | v1.0-P09 | Decision doc; if HA, RAFT/sync story in orca plan |
+| C-13 | Replace server-side doctor with CLI-SSH-driven equivalent | v1.0-P14c | New REQ-086 in REQUIREMENTS.md; integration test SSH-probes N nodes |
+| C-14 | Syncthing conflict-resolution policy deterministic + forced-divergence integration test | v1.0-P09 | Test induces divergence; resolves to single deterministic state |
+| C-15 | Bash testing framework (bats/shunit2) + shellcheck + shfmt in CoreCI before any bash ships | v0.9-P00 | CI pipeline green with the gate on a sample script |
+| C-16 | Versioned JSON-schema render-format contract between Go emitters and bash appliers | v0.9-P00 | Schema file in repo; both sides validate; mismatch fails CI |
+| C-17 | Bash scripts emit slog-compatible JSON to syslog with audit-log field set (REQ-006) | v0.9-P00 | Syslog capture test verifies field-presence + JSON parse |
+| C-18 | Document bash-side equivalents (or accepted drops) for shipped transport capabilities | v0.9-P00 | Capability-mapping doc in `.ciagent/` |
+| C-19 | Write a threat model for the new posture; defend master.key + CLI mint authority or revise | v1.0-P15.5 | Threat-model doc reviewed and committed; design revised if regression found |
+
+# Phase Plan Challenges
+
+| # | Phase | Problem | Fix |
+|---|-------|---------|-----|
+| PC-01 | v0.9 P0a–P10 | Ship 10 phases of workload features before the transactional control plane | Design spike in v0.9-P00; full impl in v1.0-P10 per PRD ordering (workloads first accepted with dual-write mitigation) |
+| PC-02 | (missing) | Deprecation of ~10k lines of daemon/transport/CA code is not a phase | Add `v0.9-P00 — Deprecation sweep` as explicit phase before any new feature phase |
+| PC-03 | v0.9 P10 | Migration is the last phase of v0.9 but is highest-risk | Split: migration design in v0.9-P00 (early), implementation in v1.0-P14 (final) |
+| PC-04 | v1.0 P14 | Covers data migration only; omits running-allocation cutover, mixed-version cluster, rollback trigger | Split into P14a (data), P14b (daemon cutover), P14c (mixed-version tolerance) |
+| PC-05 | v1.0 P02 | SPIFFE is a documented reversal with no spike; lands before spike possible | Insert `v1.0-P01.5 — SPIFFE mint spike` as hard gate before P02 |
+| PC-06 | v1.0 P10 | Transactional plane depends on lead-applier bash scripts (C-09) not gated | Reorder to v0.9-P00 design + add C-09 gate |
+| PC-07 | v1.0 P15/P16 | README before security threat model | Add `v1.0-P15.5 — Threat model + security review` before final review |
+| PC-08 | (missing) | No phase replaces server-side `orca doctor` | Add as I-C-002 / v1.0-P14c (CLI-SSH-driven doctor) |
+| PC-09 | v0.9 P09 | Syncthing lands before feasibility spike (C-02) | Spike must precede P09; if P09 is the spike, rename + gate on spike success |
+| PC-10 | v0.9 P07 | Five runtimes in one phase, including wasmtime (CGO risk) and pve-vm/pve-ct | Split: P07a (process+podman), P07b (wasmtime, C-01 gated), P07c (pve-vm+ct) |
+
+# Open Questions (feed back to IDEATE/PLAN; resolved where noted)
+
+1. **What measured operational failure of the shipped v0.8 daemon model is the re-architecture responding to?** — ✅ Resolved by override ground 1.
+2. **Can the v0.9 scope be delivered as additive extensions?** — ✅ Resolved: rejected per override grounds 1 + 5.
+3. **What is the wasmtime/CGO resolution?** — Closes via C-01 spike in v0.9-P07b.
+4. **What is the master.key threat model?** — Closes via C-19 in v1.0-P15.5.
+5. **What is the rollback unit of work for §24, and what triggers it?** — Must be answered in v0.9-P00 txn-design spike (I-B-007).
+6. **Is step-ca single-node acceptable as a cluster SPOF?** — Closes via C-12 in v1.0-P09.
+7. **Can the bash control plane be reduced?** — Closes in v0.9-P00 (fold 3+ scripts into Go-side SSH invocations where possible).
+8. **What is the realistic phase count?** — Closes via C-04 sizing before v0.9 starts; if >35, the plan becomes three milestones.
+9. **Does the PRD's reversal of 6 documented decisions require a formal AD-series supersession?** — ✅ Resolved: supersession table recorded in PROJECT.md + ARCHITECTURE.md.
+10. **What is the smallest possible version of this re-architecture that delivers 80% of the value?** — ✅ Resolved: the override rejected the incremental-additive path; the full re-architecture proceeds per the six-part justification.
+
+# Binding Decisions (this grill session, G-001..G-009)
+
+| ID | Decision | Confidence |
+|----|----------|-----------|
+| G-001 | Feasibility: PROCEED-WITH-CONDITION (C-01..C-03) | 0.62 |
+| G-002 | Scope: REPLAN mechanics (PC-01..PC-03) — direction settled by override | 0.78 |
+| G-003 | Cost: PROCEED-WITH-CONDITION (C-04..C-06) | 0.70 |
+| G-004 | Tech Risk: PROCEED-WITH-CONDITION (C-07..C-10) | 0.72 |
+| G-005 | Migration: REPLAN mechanics (PC-04) — direction settled by override | 0.82 |
+| G-006 | Op Risk: PROCEED-WITH-CONDITION (C-11..C-14) | 0.68 |
+| G-007 | Security: REPLAN mechanics (C-19) — direction settled by override | 0.74 |
+| G-008 | Maintainability: PROCEED-WITH-CONDITION (C-15..C-18) | 0.66 |
+| G-009 | Re-architecture Justification: direction overridden by user with six-part evidence basis; mechanics closed | 0.70 |
+
+# Escalations (auto-resolved under full autonomy)
+
+| E-ID | Item | Auto-decision | Mitigation |
+|------|------|---------------|-----------|
+| E-01 | Whether the re-architecture is justified vs incremental | OVERRIDDEN by user — direction holds | Six-part evidence basis recorded in PROJECT.md Supersession Table |
+| E-02 | Whether master.key passphrase-less posture is acceptable | REPLAN mechanics — threat model first | C-19 in v1.0-P15.5; if threat model shows regression vs shipped, revise design |
+| E-03 | Whether 27 phases fit in 2 milestones | Auto-split if sizing exceeds 35 | C-04; if exceeded, milestone becomes v0.9 + v0.10 + v1.0 |