orca/.ciagent/GRILL_v0.9.md

# 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 v0.10-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 v0.10 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 v0.10 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 v0.10-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 `v0.10-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; v0.10 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 (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 (v0.10 P02 ACL), produce a
  working spike of step-ca JWT-SVID or X.509-SVID minting from the orca CLI
  (v0.10-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 `v0.10-P14a — Data migration` (current scope),
  `v0.10-P14b — Daemon cutover + running-allocation adoption`,
  `v0.10-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 / v0.10-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 (v0.10-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 v0.10 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/v0.10 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 | v0.9 start | ✅ RESOLVED — operator decision: keep 2 milestones (v0.9+v0.10), keep all phases (40 total), v1.0 UAT-gated after v0.10 |
| 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 | v0.10-P14a | Spec doc + migration dry-run on test cluster |
| C-08 | SPIFFE SVID minting spike; if fails, fall back to mTLS identity | v0.10-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 | v0.10-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 | v0.10-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 | v0.10-P09 | Decision doc; if HA, RAFT/sync story in orca plan |
| C-13 | Replace server-side doctor with CLI-SSH-driven equivalent | v0.10-P14c | New REQ-086 in REQUIREMENTS.md; integration test SSH-probes N nodes |
| C-14 | Syncthing conflict-resolution policy deterministic + forced-divergence integration test | v0.10-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 | v0.10-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 v0.10-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 v0.10-P14 (final) |
| PC-04 | v0.10 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 | v0.10 P02 | SPIFFE is a documented reversal with no spike; lands before spike possible | Insert `v0.10-P01.5 — SPIFFE mint spike` as hard gate before P02 |
| PC-06 | v0.10 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 | v0.10 P15/P16 | README before security threat model | Add `v0.10-P15.5 — Threat model + security review` before final review |
| PC-08 | (missing) | No phase replaces server-side `orca doctor` | Add as I-C-002 / v0.10-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 v0.10-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 v0.10-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 v0.10-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 | ✅ RESOLVED — operator: keep 2 milestones (v0.9+v0.10), keep all phases, v1.0 UAT-gated |