dot-iu-cutter v0.2 — BR-6 Impact on P0-2 Manifest Design

document_path: knowledge/dev/laws/dieu44-trien-khai/v0.2-planning/dot-iu-cutter-v0.2-br-6-impact-on-p0-2-manifest-design-2026-05-16.md
revision: r1
date: 2026-05-16
author: Agent (Claude Code CLI, Opus 4.7 1M)
phase: v0.2 — BR-6 absorption (PLANNING/ANALYSIS ONLY)
mutation_performed: false
ddl_written: false
manifest_design_started: false
status: PENDING_GPT_REVIEW

Companion to dot-iu-cutter-v0.2-br-6-split-merge-td-analysis-2026-05-16.md. P0-2 scope = cutter_governance.manifest_envelope (v0.2-D-1) + cutter_governance.manifest_unit_block (v0.2-D-2), per scope-backlog §2.

§1 — Framing: what the manifest IS under BR-6

A manifest is the proposal + grouping surface where a topology change (first cut, or a later SPLIT/MERGE) is expressed and reviewed before it is enacted. It is not the execution engine. BR-6's consequence for P0-2:

The manifest schema must be able to represent a split/merge proposal losslessly (so review and later P1 execution have everything they need).
The manifest schema must not embed split/merge execution machinery (edge redistribution, lifecycle hooks, alias writers) — that is P1 and currently unauthorized.

The risk BR-6 guards against: if manifest_unit_block is designed only for first-cut (no span partition identity, no pre-image/post-image role, no successor linkage), then P0-2 must be re-cut when the P1 split/merge pipeline lands — exactly the rework the closeout review and scope-backlog §5/§6 ordered us to avoid.

§2 — Impact on `manifest_envelope`

An envelope is one topology-change proposal grouping its constituent blocks.

Must include now (to avoid rework):

envelope identity (envelope_id uuid PK)
source_doc_ref (which source document / parent unit the proposal derives from)
operation_kind — at minimum {first_cut, split, merge} (application-layer enum in this phase; PG CHECK deferred). Without this, a split/merge proposal is indistinguishable from a first cut and BR-6 cannot be expressed at all.
status — proposal lifecycle ({draft, under_review, accepted, rejected, superseded}); application-layer enum
escalation_ref — soft reference to decision_backlog_entry (review/escalation hook; the review_decision table itself is P0-6, deferred)
cut_change_set_ref — soft uuid reference to cutter_governance.cut_change_set (no PG FK now); records which change-set will enact this envelope at P1
audit columns: created_by, created_at, rationale

Must NOT overbuild now:

no FK to cut_change_set / verify_result (soft uuid only; CUT/VERIFY unauthorized)
no execution-state columns (no "edges_redistributed", "lifecycle_written" flags)
no PG CHECK / trigger enforcing the enum or the review gate (Phase-β/P1)
no manifest→alias FK (see §4)

§3 — Impact on `manifest_unit_block`

A block is one constituent unit of the proposal. Per scope-backlog §2 v0.2-D-2: composite identity (envelope_id, unit_local_id), FK to manifest_envelope, may reference decision_backlog_entry, JSONB fields per X-3 schemas.

Must include now (BR-6-driven, to avoid rework):

composite identity (envelope_id, unit_local_id); FK to manifest_envelope (in-schema FK is fine — both in cutter_governance)
source_span — mandatory; a split partitions a parent span into non-overlapping gap-free child spans, a merge unions spans. Without this column BR-6 is unrepresentable.
block_role — {origin, result} (or pre_image / post_image): is this block an input being superseded or an output being born? This is the single most important BR-6 column — it is what makes a row a split/merge participant rather than a plain cut piece. Application-layer enum now.
target_unit_id — soft uuid reference to public.tac_logical_unit.id (no cross-schema PG FK in this phase, consistent with the alias-design §7 / Phase α soft-ref precedent): for origin blocks, the existing unit being superseded; for result blocks, NULL until enacted at P1.
proposed_canonical_address (text, nullable) — the address a result block will be coined with; NULL for origin. Never written back to the live SSOT by the manifest.
proposed_authority (text, nullable) — snapshot per the authority-inheritance GOV decision (BR-6 analysis GOV-2).
render_order (int / numeric) — ordering field present now; the recompute algorithm is P1.
payload_summary / candidate_edges / report_summary JSONB (per scope-backlog X-3) — candidate_edges is where edge-redistribution intent is captured without building edge tables now.

Must NOT overbuild now:

no universal_edges redistribution tables — capture intent in candidate_edges JSONB; the actual edge re-distribution executor is P1
no birth_registry / lifecycle_log writer columns or triggers — event-backed at P1
no PG CHECK on block_role / FK to tac_logical_unit (soft ref only)
no successor-chain materialized columns beyond the soft target_unit_id + alias trail
no hierarchy re-parenting engine (only the structural grouping via envelope)

§4 — Does the alias table need manifest integration?

Recommendation: NO hard integration now. Rationale (from the Phase α alias design §3/§6/§10 and BR-6 analysis row 8):

cutter_governance.canonical_address_alias is live but empty; alias writes are P1 and unauthorized.
The alias table already references units via soft target_unit_id; its resolution path is independent of the manifest by design (alias-design §4 resolution order).
Coupling manifest → alias with a FK now would (a) require alias writes to test, which are forbidden, and (b) freeze a linkage before the GOV-3 decision.
Carry as INVARIANT instead: when a split/merge envelope is enacted at P1, it MUST emit the corresponding previous_canonical / redirect alias rows. The manifest only needs to record the proposed canonical change (proposed_canonical_address on result blocks + the superseded origin block's existing canonical) — that is sufficient for P1 to derive the alias rows. No schema coupling required.

§5 — Do split/merge operations need new tables now, or can they be event-backed later?

No new tables beyond manifest_envelope + manifest_unit_block are needed now.

The proposal/grouping layer = the two P0-2 tables (with the BR-6 columns in §2/§3).
The execution of a split/merge is event-backed and lands at P1: it is realized as a cut_change_set (+ cut_change_set_affected_row) verified by verify_result (all v0.1-live, empty), with birth_registry / lifecycle_log / alias rows written by P1 pipeline logic.
Therefore: P0-2 ships the static representation; P1 ships the executor. The only forward-compat requirement is that the two manifest tables can fully describe a split/merge so P1 needs no schema change to enact one (operation_kind, block_role, source_span, soft refs, candidate_edges JSONB).

§6 — Minimum Viable P0-2 Design Constraints (recommended)

These are the constraints BR-6 absorption recommends carrying into P0-2 design. They are recommendations pending GPT review, not a frozen design:

manifest_envelope.operation_kind ∈ {first_cut, split, merge} (app-layer enum).
manifest_unit_block.block_role ∈ {origin, result} (app-layer enum) — mandatory.
manifest_unit_block.source_span present and mandatory.
render_order column present (recompute logic = P1).
All cross-schema references are soft uuid (no PG FK to tac_logical_unit, cut_change_set, verify_result, canonical_address_alias in this phase).
In-schema FK only: manifest_unit_block.envelope_id → manifest_envelope.
No PG CHECK, no trigger, no DEFAULT data; tables created empty (Phase-α discipline).
Edge-redistribution and report intent captured in JSONB (candidate_edges, payload_summary, report_summary) — no edge tables.
No manifest→alias coupling; alias emission is a P1 execution invariant.
Rollback posture: DROP TABLE on empty tables (v0.1 cutter_governance precedent).
Three GOV decisions must be ratified before P0-2 DDL is frozen (not before design starts): address-coining rule (GOV-1), authority inheritance (GOV-2), manifest↔alias linkage policy (GOV-3).

§7 — Hard Boundaries

no_DDL_written: TRUE
no_manifest_design_started: TRUE   (this is impact analysis, not design)
no_mutation: TRUE
no_migration: TRUE
no_production_touch: TRUE
BR_6_self_closed: FALSE
output_form: br_6_impact_on_p0_2_analysis_only

End of BR-6 impact on P0-2 manifest design.