dot-iu-cutter v0.5 — Post-Enactment Closeout · Automation-Orchestrator Next Brief

doc 4 of 6 · 2026-05-20 · post-enactment closeout

phase               : G4 — brief for the next automation-orchestrator macro
outcome             : BRIEF_DRAFTED  (xhigh design required; not implemented here)
production_mutation : NONE this phase

1. Why this brief is xhigh-only, not high

Multiple sovereign PASS rulings (M2 / M4-FF / Phase 7) flag the one-command automation orchestrator as xhigh-required:

M2_write_VERIFY_PASS_ruling   : "xhigh_needed_for: automation orchestrator architecture"
M4_FF_PASS_ruling             : "M5_automation_orchestrator: effort xhigh_recommended"
Phase_7_PASS_ruling           : "xhigh_only_if: one-command automation orchestrator
                                 architecture is opened"

Do not open implementation of this in a high-effort macro. This document is a brief for the next xhigh macro — not the design itself.

2. The single-command goal

The end-state desired by the user:

one_command_E2E :
  input  : a single source document (e.g., next law file)
  effect : produce a Constitution-CUT-equivalent ratified state with
           CUT → VERIFY → leg-B → write-VERIFY → lifecycle enactment all
           recorded under proper governance, in one operator command.
  output : machine-readable receipt JSON with all governance IDs,
           backup sha256, fingerprint pins, and a STOP/route decision

3. What the v0.5 pipeline currently looks like — to be folded in

manual_pipeline_today (60 ICX-CONST trial):
  step_1  : source snapshot                 (cutter_agent.snapshot)
  step_2  : MARK dry-run                    (cutter_agent.mark)
  step_3  : cutplan dry-run                 (cutter_agent.cutplan)
  step_4  : canonical leg-A CUT             (prod_iu_adapter_canonical + cutprod_canonical,
                                             SIDECAR-staged execution; autocommit=False)
  step_5  : read-only VERIFY                (ad-hoc SQL probes; no Python writer)
  step_6  : leg-B governed recording        (ledger_v2_canonical_cut, SIDECAR runner)
  step_7  : write-VERIFY DOT-992            (ledger_v2_canonical_verify, SIDECAR runner;
                                             StubSigning per D-4)
  step_8  : M4 commit/merge                 (git operations; manual)
  step_9  : M4-FF main merge                (git operations; manual)
  step_10 : M3a lifecycle DDL apply         (SQL Bundles A..E via sidecar; sovereign)
  step_11 : Phase 7 lifecycle enactment     (SQL TX calling fn_iu_enact x 60;
                                             cutter_exec role; sovereign)
sidecar_pattern_root_cause :
  - laptop repo (v0.5 code) ≠ contabo /opt/incomex/dot (v0.4 baseline)
  - psycopg2 autocommit semantics required attempt-1 → patch → attempt-2 pattern
  - any orchestrator must either deploy v0.5 to contabo first OR continue
    sidecar-staging until the deploy gate is opened

4. Architectural questions the next xhigh macro MUST answer

These are design questions; this brief surfaces them. The next macro decides them.

DQ_1_writer_locus:
  question : where does the orchestrator live?
  options  :
    - on laptop (current sidecar model)
    - on contabo as a daemon
    - as a one-shot CLI within /opt/incomex/dot after the v0.5 deploy
  bearing_on_other_decisions :
    - if contabo: deploy gate (Family B DDL) must open first
    - if laptop: must persist sidecar pattern long-term

DQ_2_signing_lane_evolution:
  question : when does StubSigning become real crypto?
  options  :
    - never for ICX (constitution stays Stub-signed retroactively)
    - swap forward for next document (next CUT uses real signing)
    - replay all v0.5 ratifications with real signing
  bearing :
    - real signing replacement is forbidden in current ruling without design
      approval — this is a sovereign architectural call

DQ_3_lifecycle_loop_completeness:
  question : do supersede/retire transitions need real implementations?
  current  : fn_iu_enact returns 'transition_not_yet_implemented' for those
  options  :
    - keep stubs until the first supersede/retire is needed (lazy)
    - implement both now before any orchestrator launches (eager)
  bearing  :
    - if next document supersedes ICX-CONST anchors, must be implemented first

DQ_4_governance_role_topology:
  question : which role does the orchestrator hold? one or many?
  options  :
    - one orchestrator role with cross-lane privileges (simpler; weaker SoD)
    - sequential role-switching across cutter_exec / cutter_verify
      (current pattern; orchestrator must manage role rotation)
  bearing  :
    - SoD between executor and verifier signing must remain enforced

DQ_5_backup_and_rollback_atomicity:
  question : does the orchestrator take ONE pg dump per command,
             or one per dangerous step?
  current  : Phase 7 took a single pre-enact dump (sha256-pinned)
  options  :
    - single dump per command (simplest)
    - dump per dangerous transaction (most recoverable)
    - dump + restore-test gate before commit (safest, slowest)

DQ_6_review_decision_creation_policy:
  question : how does the orchestrator create / discover review_decision IDs?
  current  : Phase 7 created a NEW review_decision distinct from CUT approval;
             leg-B reused the CUT approval as decision_id
  options  :
    - one review_decision per macro step
    - one review_decision per command (single approval gate)
    - one review_decision per pipeline-run with sub-events keyed by lineage

DQ_7_idempotency_and_retry:
  question : how to handle a partial-failure rerun?
  current  : idempotency_key on leg-B; advisory_xact_lock per IU in fn_iu_enact;
             no orchestrator-level idempotency
  options  :
    - orchestrator persists a runbook UUID; resumes from last successful step
    - orchestrator forces full restart on any failure
    - orchestrator surfaces partial state and requires sovereign-routed retry

DQ_8_dry_run_separation:
  question : does the orchestrator support a true full-pipeline dry-run?
  current  : fn_iu_enact has p_dry_run; CUT has its own dry-run; VERIFY is
             implicitly dry-run; ratification/merge are real-only
  options  :
    - end-to-end "plan only" mode (no DB writes, no git writes)
    - separate dry-run-everywhere flag with strict no-mutation guarantee

DQ_9_STOP_route_back_policy:
  question : where does the orchestrator stop and route to sovereign?
  current  : every macro routes back at completion
  options  :
    - stop at end of pipeline (one approval at start)
    - stop between every step (status quo, slowest)
    - stop only on failure or at sovereign-marked checkpoints

DQ_10_observability_persistence:
  question : where do orchestrator receipts persist?
  options  :
    - KB only (current pattern)
    - KB + cutter_governance.orchestrator_run table (new)
    - KB + filesystem JSON sidecar per run

5. Inputs the next xhigh macro must read first

mandatory_reads:
  - reviews/dot-iu-cutter-v0.5-phase7-enactment-pass-gpt-ruling-2026-05-20.md
  - reviews/dot-iu-cutter-v0.5-write-verify-dot992-pass-gpt-ruling-2026-05-20.md
  - reviews/dot-iu-cutter-v0.5-legB-governed-recording-pass-gpt-ruling-2026-05-20.md
  - reviews/dot-iu-cutter-v0.5-main-fast-forward-merge-pass-gpt-ruling-2026-05-20.md
  - v0.5-post-enactment-closeout-release-readiness/ (this whole folder)
  - v0.5-lifecycle-enactment-implementation-authoring/ (M3a authoring)
  - v0.5-lifecycle-enactment-execution-m3a-retry/      (M3a runtime evidence)
  - v0.5-lifecycle-phase7-enactment-execution-rerun/    (Phase 7 runtime)
helpful_reads:
  - reviews/dot-iu-cutter-v0.4-dot-lane-overlap-prevention-gpt-mandate-2026-05-17.md
  - reviews/dot-iu-cutter-v0.4-scale-automation-nonhardcode-gpt-mandate-2026-05-17.md

6. Effort + scope guardrails for next macro

effort        : xhigh
forbidden_in_first_xhigh_design_macro:
  - any production mutation
  - any DDL execution
  - any commit/push/tag/deploy
  - any actual Phase 7-like enactment
  - any StubSigning → real-crypto replacement
allowed_in_first_xhigh_design_macro:
  - read-only PG probes
  - read-only repo inspection
  - reading the full KB SSOT chain
  - writing a design package + DQ rulings request
  - producing 5–10 KB closure docs in
    knowledge/dev/laws/dieu44-trien-khai/v0.6-automation-orchestrator-design/
expected_output_artefacts:
  - DQ_1..DQ_10 ruling-request matrix
  - end-state architecture diagram (textual)
  - chosen-option per DQ (recommended + alternatives)
  - implementation phase ladder
  - rollback / kill-switch design
  - test plan (unit + integration + ratification)
stop_at_end_of_design : true (route back to GPT/User for ruling)

7. STOP

Brief delivered. Next xhigh macro must consume this and the SSOT chain before designing the orchestrator. No implementation here. Proceed to doc 05 (remaining risk + backlog).