KB-4C94

dot-iu-cutter v0.2 — Scope Backlog (2026-05-15)

15 min read Revision 1
dieu44-trien-khaidot-iu-cutterv0.2scope-backlogplanning-onlyno-execution2026-05-15

dot-iu-cutter v0.2 — Scope Backlog

document_path: knowledge/dev/laws/dieu44-trien-khai/planning/dot-iu-cutter-v0.2-scope-backlog-2026-05-15.md
revision: r1
date: 2026-05-15
author: Agent (Claude Code CLI, Opus 4.7 1M)
sovereign: User / anh Huyên
verifier: GPT (Đ32 HIGH-risk path)
secondary: Opus
phase: v0.2 scope backlog — PLANNING/BACKLOG ONLY (no design, no DDL, no execution)
predecessor: v0.1 production execution (success, GPT-ratified 2026-05-15)

§1 — Purpose

Enumerate the P0 items deferred out of v0.1 (because they lacked HB-05 dry-run evidence) and the mandatory findings + process that v0.2 must absorb. This file is a backlog snapshot, NOT a design document and NOT a v0.2 plan. It produces no DDL, no SQL, no schema commitment, no execution.


§2 — Deferred Items (carried over from v0.1)

deferred_items:
  - id:   v0.2-D-1
    name: manifest_envelope
    p0_id: P0-2
    target_schema: cutter_governance
    object_kind: table
    deferral_reason: not present in HB-05 dry-run DDL artefact; no 26/26 PASS evidence
    risk_class: standard

  - id:   v0.2-D-2
    name: manifest_unit_block
    p0_id: P0-2
    target_schema: cutter_governance
    object_kind: table
    deferral_reason: same as v0.2-D-1; jointly designed with manifest_envelope
    risk_class: standard
    notes: composite identity (envelope_id, unit_local_id); FK to manifest_envelope; references decision_backlog_entry; expected JSONB fields (payload_summary, candidate_edges, report_summary) per X-3 JSON-schemas

  - id:   v0.2-D-3
    name: review_decision
    p0_id: P0-6
    target_schema: cutter_governance
    object_kind: table
    deferral_reason: not in HB-05 dry-run DDL artefact
    risk_class: standard
    notes: enum {PASS, FAIL, NEEDS_HUMAN}; reviewer_independence rule application-layer in v0.1 era; prior_review_decision_id self-FK; escalation_ref → decision_backlog_entry

  - id:   v0.2-D-4
    name: canonical_address reconciliation on tac.tac_logical_unit
    p0_id: P0-1
    target_schema: public (existing) / tac (per X-1)
    object_kind: column family + alias table
    deferral_reason: a single text column public.tac_logical_unit.canonical_address ALREADY EXISTS pre-migration; cannot blindly add; reconciliation required (see §3 finding F-2)
    risk_class: standard_with_HIGH_attention_due_to_pre_existing_column
    notes: P0-1 also calls for canonical_address_alias table; alias lifecycle (active/retired)

  - id:   v0.2-D-5
    name: decision_backlog_history
    p0_id: P0-5
    target_schema: cutter_governance
    object_kind: table
    deferral_reason: P0-5 remainder; not in HB-05 artefact
    risk_class: standard
    notes: append-only history of decision_backlog_entry transitions

  - id:   v0.2-D-6
    name: decision_backlog_dependency
    p0_id: P0-5
    target_schema: cutter_governance
    object_kind: table
    deferral_reason: P0-5 remainder; not in HB-05 artefact
    risk_class: standard
    notes: edges between decision_backlog_entry rows

  - id:   v0.2-D-7
    name: decision_backlog_sweep_log
    p0_id: P0-5
    target_schema: cutter_governance
    object_kind: table
    deferral_reason: P0-5 remainder; not in HB-05 artefact (note: prior planning text referred to "sweep_log"; user-confirmed canonical name for v0.2 backlog = decision_backlog_sweep_log)
    risk_class: standard
    notes: periodic sweep operation log against the backlog

total_deferred_items: 7
deferred_items_with_dry_run_evidence: 0 (all 7 are net-new for v0.2)
deferred_items_touching_existing_production_tables: 1 (v0.2-D-4 reconciles against existing public.tac_logical_unit.canonical_address)
deferred_items_touching_only_new_schemas: 6 (D-1, D-2, D-3, D-5, D-6, D-7 — all within cutter_governance)

§3 — Mandatory v0.2 Findings (must be absorbed by v0.2 design)

F-1 — PG-16 relname vs older tablename (verification tooling)

description:
  PostgreSQL 16's pg_stat_user_tables uses column `relname` (PG ≤ 9 used `tablename`).
  v0.1 command-review package §2.9 used the older `tablename` token; the actual verification query had to be re-run with `relname`. Information_schema cross-check (`SELECT count(*) FROM information_schema.tables ...`) is the version-portable form.
v0.2_implication:
  - all v0.2 verification queries against pg_stat_user_tables MUST use `relname`
  - prefer information_schema queries where portability matters
  - command-review package template (if reused) MUST be updated before C-09b authoring in v0.2
acceptance_signal:
  - v0.2 command-review package §V-b query reads `relname`
  - cross-check query uses information_schema

F-2 — Pre-existing public.tac_logical_unit.canonical_address column

description:
  A single `text` column named `canonical_address` already exists on `public.tac_logical_unit` and predates this initiative.
  It is referenced by pre-existing production code:
    - function: public.fn_event_unread (SELECTs canonical_address)
    - trigger code: tests `IF COALESCE(NEW.canonical_address, '') = '' THEN` (also references v_iu.canonical_address)
  Evidence: /opt/incomex/backups/dieu44_exec_2026-05-15/directus_schema_pre_20260515T141429Z.sql
v0.2_implication_for_P0_1:
  - v0.2 P0-1 ("canonical_address field family") CANNOT blindly add a column named canonical_address — it ALREADY EXISTS
  - reconciliation analysis (v0.2-D-4) required BEFORE any DDL is authored:
      a. inventory all current readers/writers of public.tac_logical_unit.canonical_address
      b. determine whether the existing column is semantically compatible with the P0-1 design (authority, uniqueness scope, alias lifecycle)
      c. choose a reconciliation strategy: EXTEND the existing column with additional canonical_address_* fields | RENAME the existing column with a deprecation window | REUSE the existing column unchanged and add the field family around it
      d. update P0-1 design document to reflect chosen strategy
      e. document the legacy column's history (origin, original purpose) in the v0.2 design and HB equivalent
risk_signal:
  - HIGH attention even though P0-1 is otherwise standard risk; the pre-existing column makes a naive ADD COLUMN unsafe
  - any v0.2 P0-1 dry-run must include scenarios that exercise the legacy reader/writer paths
acceptance_signal:
  - reconciliation analysis document exists and is GPT-reviewed BEFORE P0-1 DDL authoring
  - v0.2 P0-1 dry-run includes a scenario covering interaction with public.fn_event_unread and the existing trigger

§4 — Required v0.2 Process

required_v0_2_process:
  step_0_scope_freeze:
    - v0.2 scope = the 7 deferred items in §2 (no scope expansion beyond §2 without explicit Đ32 sign-off)
    - any addition (e.g., introducing CUT/VERIFY runtime, application code wiring, new tables outside §2) belongs to a SEPARATE version (v0.3+) and a SEPARATE backlog

  step_1_design_master_revision:
    - revise migration-design master file for the deferred items
    - resolve cross-cutting items that v0.1 deferred or treated as v0.1-acceptable:
        - PEF-03 (PG-constraint dual-signature enforcement) — decision: defer further or land
        - PEF-04 (cryptographic signing scheme) — decision: defer or land
        - PEF-05 (per-source_kind canonicalization extensions) — decision: defer or land
        - PEF-09 (DOT-pair separate execution context) — decision: defer or land
    - explicitly absorb F-1 and F-2 findings from §3

  step_2_canonical_address_reconciliation_analysis:
    - separate document; produced BEFORE any P0-1 DDL is authored
    - inputs: pre-existing schema snapshot, all callers of public.tac_logical_unit.canonical_address, P0-1 design intent
    - output: chosen strategy (extend|rename|reuse) with justification + impact on dependent code

  step_3_dry_run_evidence_cycle (HB-05-equivalent for v0.2):
    - design dry-run DDL artefact for v0.2 (new sql file with new sha256)
    - build new dry-run env (or extend pg-dry-run-hb05-2026-05-15 with v0.2 layer — decision to be made)
    - author scenario matrix covering all 7 items + F-2 legacy-reader-writer scenarios
    - acceptance threshold: 100% PASS (same discipline as HB-05 26/26)

  step_4_blocker_closure_pass:
    - for each net-new risk surface introduced by v0.2, raise a blocker (HB-equivalent), close it, document evidence
    - new HB-05-equivalent rollback dry-run closure
    - GPT review of each closure

  step_5_final_readiness_review:
    - new final-readiness report + rerun for v0.2 (analogous to v0.1 final-readiness/* files)
    - GPT review

  step_6_command_review_package:
    - new production command-review package for v0.2 (analogous to v0.1 execution/* command-review file)
    - DDL source: NEW (frozen v0.2 sql with NEW sha256, NOT the v0.1 artefact)
    - command plan: fresh backup, snapshots, preflight gates, single-transaction migration, verification, rollback, failure-stop
    - GPT review

  step_7_explicit_production_execution_prompt:
    - separate User prompt; references the v0.2 command-review by path
    - Agent does NOT self-advance from step_6 to step_7

  step_8_production_execution:
    - new fresh production-bound backup taken < 60 min before C-08
    - apply v0.2 DDL in single transaction
    - verify
    - report

  step_9_GPT_ratification_of_v0_2_execution_report:
    - mirrors the v0.1 ratification pattern

agent_self_advance_at_any_step: PROHIBITED
each_step_terminates_at_GPT_review_or_explicit_prompt: TRUE

§5 — Split/Merge Metadata Propagation TD Reference

td_reference: knowledge/dev/laws/dieu44-trien-khai/backlog/td-p1-split-merge-metadata-propagation-gap-2026-05-15.md
relevance_to_v0_2:
  - manifest_envelope / manifest_unit_block (v0.2-D-1, v0.2-D-2) are the primary surface where split/merge metadata propagation governance shows up
  - v0.2 design MUST read this TD before authoring P0-2 DDL
  - if the TD has not yet been authored at v0.2 design start, it must be authored first (it is a prerequisite, not a follow-up)
status_at_handoff_time: NOT_VERIFIED_BY_AGENT (Agent has not opened this file in this session; treat as a known reference path; resolve at v0.2 design start)

recommended_v0_2_order:
  - phase_1_analysis:
      task: canonical_address reconciliation analysis (v0.2-D-4)
      gate_to_advance: GPT review PASS; reconciliation strategy chosen
      reason: this is the only item touching a PRE-EXISTING production table — it is the highest-risk single change in v0.2 and MUST be resolved before any DDL is authored

  - phase_2_p0_2_dry_run:
      task: manifest_envelope + manifest_unit_block dry-run (v0.2-D-1 + v0.2-D-2)
      gate_to_advance: scenario matrix 100% PASS + GPT review
      reason: P0-2 is the largest net-new surface; jointly designed; depends on split/merge TD §5

  - phase_3_p0_6_dry_run:
      task: review_decision dry-run (v0.2-D-3)
      gate_to_advance: scenario matrix 100% PASS + GPT review
      reason: depends on manifest_envelope existing (Phase 2 must close first)

  - phase_4_p0_5_remainder_dry_run:
      task: decision_backlog_history + decision_backlog_dependency + decision_backlog_sweep_log (v0.2-D-5 + v0.2-D-6 + v0.2-D-7)
      gate_to_advance: scenario matrix 100% PASS + GPT review
      reason: P0-5 remainder; lower risk; can be jointly designed with one dry-run cycle

  - phase_5_command_review:
      task: produce v0.2 production command-review package (analog of v0.1 §)
      gate_to_advance: GPT PASS

  - phase_6_production_execution_only_after_explicit_approval:
      task: production execution of v0.2 DDL
      gate_to_advance: separate explicit User prompt + Đ32 + G-4 Custodian
      reason: matches v0.1 discipline — never self-advance into production

phase_dependencies:
  phase_1 → phase_2 → phase_3 → phase_4 → phase_5 → phase_6

intra_phase_parallelism:
  - phases can be authored in parallel within their dry-run if the dependency rule is honored
  - phase 1 must complete before phase 2 (P0-2 may interact with canonical_address)
  - phases 3 and 4 may overlap once phase 2 closes

§7 — What This File Does NOT Do

this_file_does_NOT:
  - write any SQL or DDL
  - author any migration script
  - mutate production
  - run any dry-run
  - rebuild the dry-run env
  - tear down any environment
  - design any v0.2 schema
  - authorize any v0.2 execution
  - replace the v0.2 design master or risk review that must follow
  - claim v0.2 scope is closed — this is a snapshot, not a decision

§8 — Cross-References

v0_1_handoff_status:
  knowledge/dev/laws/dieu44-trien-khai/execution/dot-iu-cutter-v0.1-production-handoff-status-2026-05-15.md
v0_1_production_execution_report:
  knowledge/dev/laws/dieu44-trien-khai/execution/dot-iu-cutter-v0.1-production-execution-report-2026-05-15.md
v0_1_command_review:
  knowledge/dev/laws/dieu44-trien-khai/execution/dot-iu-cutter-v0.1-p0-production-command-review-package-2026-05-15.md
v0_1_final_readiness_rerun:
  knowledge/dev/laws/dieu44-trien-khai/final-readiness/dot-iu-cutter-v0.1-p0-final-execution-readiness-rerun-2026-05-15.md
v0_1_hb_05_closure:
  knowledge/dev/laws/dieu44-trien-khai/blocker-closure/dot-iu-cutter-v0.1-hb-05-rollback-dry-run-closure-2026-05-15.md
v0_1_blocker_register:
  knowledge/dev/laws/dieu44-trien-khai/final-readiness/dot-iu-cutter-v0.1-p0-final-readiness-blocker-register-2026-05-15.md
split_merge_metadata_td:
  knowledge/dev/laws/dieu44-trien-khai/backlog/td-p1-split-merge-metadata-propagation-gap-2026-05-15.md
pre_migration_schema_evidence (for F-2):
  /opt/incomex/backups/dieu44_exec_2026-05-15/directus_schema_pre_20260515T141429Z.sql  sha256 638307fd62d4b1aa087ce7f70f42112c4c6185a2e44d8144a1d859029515668a

§9 — Hard Boundaries

no_production_modification_in_this_backlog: TRUE
no_DDL_or_SQL_in_this_backlog: TRUE
no_design_in_this_backlog: TRUE
no_v0_2_execution_authorized_by_this_backlog: TRUE
no_CUT_or_VERIFY_authorized: TRUE
no_dry_run_env_teardown_authorized: TRUE
output_form: scope_backlog_documentation_only
agent_self_advance_from_this_backlog_to_v0_2_design: PROHIBITED

End of v0.2 scope backlog.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/planning/dot-iu-cutter-v0.2-scope-backlog-2026-05-15.md