GPT Roadmap — Pause IU, Fix DOT-119 First

Date: 2026-05-05 Reviewer/Coordinator: GPT-5.5 Thinking / Incomex Hội đồng AI Purpose: Near-term roadmap after discovering DOT-119 is stale relative to fn_birth_registry_auto v2.

Decision

Pause IU Pack 2B / File 18 execution. Fix DOT-119 first under Điều 20 process.

Reason: DOT-119 is a core birth tool. If it remains stale, future agents may run it and clobber the installed fn_birth_registry_auto v2 synthetic fallback currently used by ~70k birth records. Recording a TD alone is too weak for a known high-risk tool.

Roadmap from current point

Stage 0 — Freeze unsafe paths

Status: immediate.

• Do not execute file 18 yet.
• Do not run DOT-119.
• Do not create IU rows.
• Do not create trg_birth_information_unit yet.
• Keep file 16 and 17 superseded.
• Treat file 16b rev2 and Agent birth-code report as current evidence.

Stage 1 — DOT-119 design first, per Điều 20

New design file to create:

knowledge/dev/laws/dieu44-trien-khai/design/18a-dot119-metadata-driven-no-clobber-redesign.md

Goal: redesign DOT-119 as a future-proof, metadata-driven birth-trigger setup tool.

Required design model: 3-tier architecture

1. Tier 1 — Birth identity metadata

   • DOT-119 must not hardcode collection-specific code columns.
   • It should read a birth identity policy from metadata.
   • Candidate storage to compare:
     • fields on collection_registry;
     • dot_config JSON mapping;
     • new birth_identity_registry table;
     • existing species/registry mechanism if suitable.
   • Minimum strategy values:
     • column — use declared column such as code, law_code, measurement_id;
     • synthetic_id — use table::id via existing v2 fallback;
     • subordinate — no separate birth trigger, child/version rows;
     • disabled/excluded — explicitly no birth trigger.

2. Tier 2 — Generic trigger installer

   • DOT-119 only creates/verifies/drops birth triggers.
   • It never embeds or replaces fn_birth_registry_auto.
   • It must be idempotent.
   • It must have dry-run.
   • It must validate table/column/function/trigger state.
   • It must STOP if metadata missing or inconsistent.

3. Tier 3 — Master function governance

   • fn_birth_registry_auto is governed separately, not by DOT-119.
   • A separate tool/migration should manage function changes if needed.
   • DOT-119 must include a no-clobber self-check: if script contains CREATE OR REPLACE FUNCTION fn_birth_registry_auto, FAIL.
   • It must verify installed function has expected v2 synthetic fallback before using synthetic strategies.

Stage 2 — Opus critique, not code

Opus should produce the design and include its own critique:

• Is metadata storage best in collection_registry, dot_config, or a new registry?
• What is the lowest-risk path that solves future collections, not only IU?
• How to migrate existing 30 triggers into metadata without breaking current behavior?
• How to protect current 75k birth_registry rows?
• How to test DOT-119 without replacing the master function?

No code changes yet.

Stage 3 — GPT/User review and choose design

After file 18a is uploaded:

• GPT/User reviews.
• Decide metadata endpoint.
• Decide whether to repair DOT-119 now in one runtime pack or split into:
  1. metadata seeding;
  2. script refactor;
  3. smoke tests;
  4. IU trigger setup.

Stage 4 — DOT-119 repair execution pack

Only after design PASS:

Create execution pack, likely:

knowledge/dev/laws/dieu44-trien-khai/design/18b-dot119-repair-execution-pack.md

Scope:

• Update DOT-119 script.
• Preserve installed fn_birth_registry_auto v2.
• Add no-clobber self-check.
• Add metadata-driven strategy selection.
• Add dry-run and idempotency tests.
• Do not create IU rows.
• Do not execute Pack 2B.

Stage 5 — DOT-119 repair runtime

Only after execution pack PASS and User approve:

• Run repair via Claude Code.
• Verify DOT-119 does not modify fn_birth_registry_auto.
• Verify existing birth triggers unaffected.
• Verify dry-run for existing known collections.
• Verify dry-run for information_unit synthetic strategy.
• Upload report.

Stage 6 — IU birth trigger via repaired DOT-119

After DOT-119 repair PASS:

• Update/replace file 18 if needed.
• Use repaired DOT-119 to create trg_birth_information_unit.
• Expected entity_code: information_unit::<uuid>.
• Test with rollback row if approved.
• Report and hard stop.

Stage 7 — Resume IU Pack 2B

Only after IU birth trigger PASS:

• Re-open Pack 2B CRUD pilot design/execution.
• No vector/outbox until CRUD + birth path pass.
• No production/minimum use until QT/backfill/governance requirements are met.

Directive to Opus/Ocus

Do not execute file 18.

Create file 18a:

knowledge/dev/laws/dieu44-trien-khai/design/18a-dot119-metadata-driven-no-clobber-redesign.md

Required inputs:

• knowledge/dev/laws/dieu44-trien-khai/reports/existing-birth-code-column-patterns-report.md
• knowledge/current-state/reports/s145-m2-dot119-birth-triggers-report
• knowledge/current-state/reports/s160-unified-system-report.md
• knowledge/ops/processes/birth-process-v1.md
• knowledge/dev/laws/law-04-birth-process.md
• knowledge/dev/laws/dieu20-thiet-ke-truoc-trien-khai.md
• file 16b rev2
• file 18 rev1

File 18a must:

1. State why TD-only is not enough.
2. Present the 3-tier DOT-119 redesign.
3. Compare metadata storage options.
4. Propose strategy values and behavior.
5. Provide migration plan for current triggers.
6. Define no-clobber and dry-run requirements.
7. Define tests and rollback.
8. Explain how IU will be handled after DOT-119 is repaired.
9. Include Opus critique / alternatives.
10. End with decision request, no execution.

Hard boundaries:

• no code changes;
• no DOT-119 execution;
• no function edits;
• no IU trigger;
• no IU rows;
• no Pack 2B.

Summary

Current priority is not IU trigger. Current priority is making the birth-trigger tool safe and future-proof. Then IU becomes a normal metadata-driven use case of the repaired tool.