10 — Carry-forward to implementation

This documentation package defines the operating model. The actual implementation of the MARK harness and the dot_iu_cut_from_manifest DOT command is the next series of micro-cycles. This doc lists what still needs to be built, in dependency order.

1. Implementation backlog (in dependency order)

1.1 MARK harness (cutter_agent/mark.py)

A small Python module the fresh Agent can call, OR a self-contained script the Agent generates.

purpose:           drive the 12-step procedure in 02-agent-mark-instructions.md
inputs:            user request (article_labels[] + sources + optional doc_code)
outputs:           manifest.json + mark_report.md + coverage_proof.json + determinism_digest.md
no DB writes:      structural guarantee — module imports stdlib + httpx only;
                   raises if any psycopg/sqlalchemy import is detected
side effects:      file writes to --out-dir; KB upload via configured client
estimated effort:  1-2 days of authoring + tests

Authoring sub-tasks:

• Article boundary detector (regex_label_match + manual_anchor fallback).
• Normalization functions (whitespace_collapse_v1).
• Piece segmenter with local_piece_id generator.
• Axis-A/B/C field populator.
• Reconstruction comparator (byte-equal).
• Canonical-JSON serializer.
• STOP-message emitter with self-check.
• ≥10 unit tests (round-trip on the existing constitution snapshot + 2 invented synthetic docs).

1.2 Migration: register dot_iu_cut_from_manifest

-- sql/iu-core/037_dot_iu_cut_from_manifest_register.sql
INSERT INTO dot_iu_command_catalog (command_name, description, governance_lane)
VALUES (
  'dot_iu_cut_from_manifest',
  'CUT a previously-approved cut_manifest into durable IU rows; atomic transaction; rollback plan emitted.',
  'DOT-991'
);

Plus a rollback file that DELETEs the row. Mig 037 is data-only, no DDL — same shape as mig 034 from 40000x (register-only). D9 conformance: dot_iu_command_catalog row count 26 → 27 (R280 expected_27).

1.3 Migration: register the verifier dot_iu_verify_cut

Same pattern. Governance lane DOT-992. Row count 27 → 28.

1.4 CUT executor (cutter_agent/cut_from_manifest.py)

Implements the contract in 05-dot-cut-from-approved-manifest-contract.md.

guards G1..G7 (no-connect): _g1_approval, _g23_digests, _g7_backup
guards G4..G6 (connect):     _g4_principal, _g5_vocab, _g6_cut_once
sql_executor:                builds the pieces_json per article and calls fn_iu_compose
sql_allowlist:               defence-in-depth; refuses any statement outside the
                             {fn_iu_compose, iu_metadata_tag INSERT, iu_sql_link INSERT,
                              dot_iu_command_run INSERT} set
audit:                       dot_iu_command_run row before COMMIT
estimated effort:            3-5 days authoring + tests + R1-style command-review

Authoring sub-tasks:

• --apply / --reconstruct / --verify flag handling.
• Guard implementations (G1..G7).
• Approval KB resolver (calls the KB client; verifies digest match).
• fn_iu_compose call builder.
• Audit row insertion.
• Rollback plan emitter.
• Exit-code mapping per 05 §9.
• Unit tests for each guard (refuse path) + integration test against a sandbox DB.

1.5 VERIFY executor (cutter_agent/verify_cut.py)

Implements V1..V8 (see 01 §5.3). Read-only. Emits verify_report.md + updates the manifest's verify_record.

1.6 Rollback executor (cutter_agent/cut_rollback.py)

Consumes rollback_plan.json; calls fn_iu_piece_retire / fn_iu_piece_supersede in reverse order. Forward-compensation only — no DELETE.

1.7 Optional: MARK CLI wrapper

python -m cutter_agent.mark \
  --request-file <user_request.txt> \
  --out-dir <scratch-dir> \
  --doc-code <optional override>

So an operator can invoke MARK as a single command instead of a free-form Agent prompt. Nice-to-have, not required for the operational flow.

2. Channel constitution (recap from 70000x)

• IU-core writes (DDL and the privileged DML targeting iu_core.* gates or iu_piece_* tables owned by workflow_admin) run as workflow_admin via the pg_hba local all all trust line:

  cat <sql> | ssh contabo "docker exec -i postgres psql -U workflow_admin -d directus -v ON_ERROR_STOP=1"
  

• Read-only verifications can use directus (less privileged, network-friendly).

• The DB inside the postgres container is directus (not incomex_workflow; the memory drift was caught at 40000x — [[feedback-channel-memory-drifts-verify-live]]).

3. Acceptance gates for the next macro

Before dot_iu_cut_from_manifest ships to live:

• MARK harness implemented + ≥10 unit tests PASS.
• Codex MARK test (per 09-test-plan-…) PASSes for at least 3 articles (e.g., Điều 37, 38, 39).
• Mig 037 (catalog register) authored, reviewed, applied as workflow_admin, SSOT bumped 26→27, pinning tests bumped.
• CUT executor implemented + R1-style command-review package.
• CUT dry-run (no --apply) emits identical SQL across two runs (determinism).
• One real article (e.g., Điều 37 from a real source) cut to production with V1..V8 all GREEN.
• Rollback executor exercised at least once on a test piece (BEGIN/ROLLBACK or actor-scoped retire on a throwaway article).

4. Out-of-scope for this 80000x macro (intentionally deferred)

• Building the MARK harness (this macro is docs-only).
• Building the CUT executor.
• Migrations 037 / 038.
• Real CUT against Điều 37/38/39.
• Linking Codex (or any other Agent) into the CLI invocation pipeline.
• Auto-MARK on inbox events (fn_iu_auto_instantiate_from_event for mark requests).
• Nuxt UI that lets users click "MARK Điều 37" from a browser.
• Vector indexing of newly cut pieces (vector_sync_enabled remains false).

These are listed so future-me does not accidentally pull them into 80000x scope. Each is a separate macro.

5. Open questions for the operator

Recorded so they get an explicit decision later, not silently inferred:

1. doc_code registry. Where is the canonical list of doc_code prefixes? Today LUAT-XYZ-2024, ICX-CONST, etc. are ad-hoc. Suggest adding a small table iu_core_doc_code_registry with prefix, description, owner. Deferred.

2. Approval authority registry. 04 §5 proposes iu_core_approval_authority. Operator decides whether to build it now or rely on the standing operator.

3. Vector indexing trigger. When (if ever) should iu_core.vector_sync_enabled flip true for the new cut pieces? Carry-forward from 25000x onwards.

4. MARK source freshness window. Default ≤ 24 h between source fetch and approval. Operator may want a shorter window for live-amended laws.

5. Multi-article CUT atomicity. Should one CUT command always cut all approved articles in one TX, or one TX per article? Current contract: one TX per --manifest (which may hold multiple articles).

6. References

• 70000x final readiness: knowledge/dev/laws/dieu44-trien-khai/v0.6-iu-core-70000x-full-test-readiness-six-user-flows-open-goal/09-final-readiness-matrix.md
• Six-flow runner: ops/iu-core-six-flow-test-readiness/
• v0.5 MARK command-review precedent: knowledge/dev/laws/dieu44-trien-khai/v0.5-constitution-snapshot-source-mark-dryrun-entrypoint-code-authoring/
• v0.5 CUT command-review precedent: knowledge/dev/laws/dieu44-trien-khai/v0.5-first-controlled-cut-approval-package/
• Channel: [[feedback-pg-hba-local-trust-unblocks-role-channel]]
• Idempotency: [[feedback-idempotency-key-for-event-driven-compose]]
• Compose mechanism: [[feedback-compose-iu-id-branch-is-instance-mechanism]]