From e9f1073954f19d3bcd64e765386f7d04087e538b Mon Sep 17 00:00:00 2001 From: Jon Chery Date: Wed, 5 Aug 2026 16:01:52 +0000 Subject: [PATCH] =?UTF-8?q?docs(P00):=20grill=20v0.9=20re-architecture=20?= =?UTF-8?q?=E2=80=94=20REPLAN=200.74=20overridden,=2019=20binding=20condit?= =?UTF-8?q?ions=20adopted?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 | 4 +- .ciagent/GRILL_v0.9.md | 485 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 487 insertions(+), 2 deletions(-) create mode 100644 .ciagent/GRILL_v0.9.md diff --git a/.ciagent/CHECKPOINT.json b/.ciagent/CHECKPOINT.json index 57159b8..66bc80a 100644 --- a/.ciagent/CHECKPOINT.json +++ b/.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 } \ No newline at end of file diff --git a/.ciagent/GRILL_v0.9.md b/.ciagent/GRILL_v0.9.md new file mode 100644 index 0000000..04e0c90 --- /dev/null +++ b/.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 | \ No newline at end of file