03 - Options Analysis

O5 Release / Live-Production Planning · doc 3 of 6 · 2026-05-21 Gate G3 — evaluate the five candidate next moves after O4.

0. Evaluation axes

Each option is scored on: safety (distance from production mutation), value (progress toward live-production readiness), effort, reversibility, and prerequisites.

OPT-1 — Release / tag local only, no deploy

What: create a local annotated git tag at 6625f76 (e.g. v0.6.0-O4-live-dryrun) on the developer repo. No push (no remote exists), no deploy, no runtime change.

Axis	Assessment
Safety	Maximum — touches only local git metadata
Value	Low — a naming anchor; the KB ruling already pins 6625f76 as the canonical O4 HEAD
Effort	Low (medium gate at most)
Reversibility	Trivial (git tag -d)
Prereq	None

Verdict: harmless hygiene. Useful but not sufficient as the next macro on its own — it does not move the programme toward live-production. Best folded into a larger macro, not run alone.

OPT-2 — Deploy v0.6 to Contabo, kill-switch OFF

What: place the v0.6 orchestrator code (HEAD 6625f76) onto Contabo — updating /opt/incomex/dot/iu-cutter from v0.4 to v0.6 (it is vendored in the /opt/incomex/dot repo) — with execution_enabled = False unchanged. No service, no restart, no mutation.

Axis	Assessment
Safety	High — with the kill-switch OFF, Mode.LIVE is structurally refused; the deployed code physically cannot mutate production
Value	High — this is the gating prerequisite (GAP-1) for every later step
Effort	High — must be a GPT-reviewed command-review package (the established Contabo pattern), not an ad-hoc copy
Reversibility	High — code-only; revert = restore the v0.4 tree / git revert in the dot repo
Prereq	OPT-1 advisable first (tag the exact deployed commit); a deploy command-review package

Verdict: necessary and safe. It is the unavoidable first concrete step. Must travel as a reviewed package with identity guards + pre-state SHA + abort-on-drift, mirroring dot-iu-cutter-v0.4-connenv-exec.sh.

OPT-3 — One more non-mutating live dry-run after deploy

What: after OPT-2, run the orchestrator on Contabo in Mode.DRYRUN against live read-only facts — reproducing the O4 run (SG1 pause → resume → SG2 pause → resume → closeout → idempotent resume) and proving the deployed artifact behaves identically to the developer-host O4 run.

Axis	Assessment
Safety	High — Mode.DRYRUN + context_pack_readonly + BEGIN READ ONLY/ROLLBACK; pre/post counts must stay identical
Value	High — proves deploy parity; converts "code copied" into "code verified in the real runtime"
Effort	Medium-high
Reversibility	N/A — read-only, nothing to revert
Prereq	OPT-2 done; context_pack_readonly reachable (already proven in O3/O4)

Verdict: essential deploy-validation gate. Cheap insurance that the Contabo runtime (Python, env, DB reachability) matches the developer host before anyone discusses flipping the kill-switch.

OPT-4 — First orchestrator-managed production run on a harmless document

What: the genuine production-mutation event — flip execution_enabled = True for one scoped run, obtain SG_1 + SG_2 sovereign approvals, and run all 11 phases with real mutation on a small, harmless, new document (≤ ~20 candidates; not the Constitution, not a signature-critical document). This is the original automation-design macro_O4.

Axis	Assessment
Safety	Lowest of the five — this is production mutation
Value	Highest — first real proof of the one-command automatic cut
Effort	xhigh (per O4 ruling xhigh_if)
Reversibility	Bounded: GPG backup + idempotency + rollback runbook — but a real DB write nonetheless
Prereq	OPT-2 and OPT-3 done; GAP-3..8 all closed; a standalone GPT architectural ruling

Verdict: correct eventual target, but must NOT be the next macro. It requires its own sovereign architectural ruling and all of GAP-3..8 closed first. Sequencing it before OPT-2/OPT-3 would be reckless.

OPT-5 — Defer production live run until real crypto / signing

What: perform no live cut at all until StubSigning is replaced by a real (HSM/KMS-backed) SigningProvider — the design's macro_O6.

Axis	Assessment
Safety	Maximum — no live mutation until crypto hardened
Value	Mixed — the automation design (DQ_2, §6) explicitly states real crypto is deferred to O6 and is NOT blocking O1..O5; StubSigning is the ratified v0.6 provider
Effort	xhigh (the crypto migration itself)
Reversibility	N/A
Prereq	A sovereign architectural ruling on crypto

Verdict: over-constrains if applied to all live runs — it would contradict the ratified design. Sound, however, as a scoped rule: defer live cuts of signature-critical / externally-relied-upon documents until real crypto, while allowing a harmless first live cut under StubSigning. Adopt OPT-5 as a policy constraint on document selection, not as the next macro.

4. Comparative summary

Option	Safety	Value	Effort	As next macro?
OPT-1 release/tag local	★★★★★	★☆☆☆☆	low	fold into O6
OPT-2 deploy, kill-switch off	★★★★☆	★★★★☆	high	YES — O6 core
OPT-3 post-deploy live dry-run	★★★★☆	★★★★☆	med-high	YES — O7 core
OPT-4 first live production cut	★★☆☆☆	★★★★★	xhigh	NO — later (O8), separate ruling
OPT-5 defer until real crypto	★★★★★	★★★☆☆	xhigh	NO — adopt as a policy rule

5. G3 result

G3_option_analysis: PASS
recommended_combination:
  next:        OPT-1 (folded) + OPT-2   → macro O6
  then:        OPT-3                    → macro O7
  later:       OPT-4                    → macro O8 (xhigh, separate sovereign ruling)
  policy_rule: OPT-5 scoped to signature-critical documents only
high_gates:  OPT-1, OPT-2, OPT-3   (and O5 planning itself)
xhigh_gates: OPT-4 (execution_enabled flip / live mutation), real crypto, deploy-architecture change