GPT Review — Pack 2A Legal/Tooling Preflight Report

Date: 2026-05-04 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed report: knowledge/dev/laws/dieu44-trien-khai/reports/iu0-pack2a-legal-tooling-preflight-report.md rev 1

Verdict

PASS — agent performed correct read-only discovery.

The report confirms the previous legal blocker was handled correctly: no writes, no DDL, no DOT executed, no Pack 2B/2C opened.

Key finding

There is no tool gap.

Legal tools already exist for the relevant specialties:

• Collection registration: dot-collection-register / DOT_COLLECTION_REGISTER exists, active, paired.
• Collection creation: dot-collection-create / DOT-COL-CREATE exists, but likely not needed because IU PG tables already exist.
• Collection health: dot-collection-health exists.
• Trigger governance: dot-schema-trigger-registry-ensure, dot-trigger-guard, trigger_registry, trigger_guard_exceptions, trigger_guard_alerts exist.
• Birth backfill: dot-birth-backfill exists.
• Admin fallback: admin_fallback_log + approval_requests flow exists, but is not justified because no tool failure has been demonstrated.

Therefore raw SQL is BLOCKED, and the next legal path is DOT-based execution design.

Law / Constitution check

• Đ4: Next write must use DOT/script standard, not direct SQL.
• Đ2: Registry actions must maintain ID, metadata, and automated management path.
• Đ35: DOT tooling is the gateway; if DOT exists, use DOT.
• Đ36: Collection registration is governed; HC-REG confirms unregistered PG tables are critical, but fixing must use collection protocol tooling.
• Đ20 v1.2 / NT15: A new write execution must have design, review, rollback, internal/external evidence, and mini postmortem on failure.
• Hiến pháp NT1/NT9/NT13: Evidence-first, no guessing, PG/runtime discovery already done; next write must still include preflight and stop conditions.
• Đ44: IU roadmap preserved; no CRUD/vector/outbox yet.

Current roadmap position

Pack 2A Legal/Tooling Preflight Discovery is DONE/PASS.

Next is Pack 2A-DOT Execution Design, not immediate dispatch.

Reason: report found the correct tools, but still leaves parameter decisions and operational sequence to design:

• governance_role for information_unit / unit_version;
• storage_role;
• source_kind;
• migration_state;
• Directus exposure yes/no;
• exact tool commands and verify sequence;
• how to handle governed + HC-SCHEMA risk if IU tables lack description columns.

Recommended defaults to evaluate, not blindly execute

• source_kind: likely pg_table, because IU tables already exist as PG public tables.
• migration_state: likely pilot, because IU is not yet minimum production use.
• Directus exposure: NO for this step; use dot-collection-register, not full dot-collection-create, unless design proves Directus exposure is required.
• governance_role: OPEN. Do not default blindly to governed until checking HC-SCHEMA implications, because Đ36 HC-SCHEMA flags governed tables without description as CRITICAL. observed may be safer for pilot/readiness, but this needs evidence from collection_registry conventions and Đ36/Đ29 semantics.
• storage_role: OPEN; derive from live collection_registry values and tool contract.

Directive to Opus/Ocus

Prepare one consolidated design package, not multiple micro-prompts:

knowledge/dev/laws/dieu44-trien-khai/design/12-iu0-pack2a-dot-governance-registration-execution-pack.md

Purpose: DOT-based legal execution design for registering IU tables and trigger governance after preflight PASS.

Required content:

1. Current evidence summary from preflight report.
2. Legal basis: Đ2, Đ4, Đ35, Đ36, Đ20 v1.2/NT15, Đ14, Đ44, relevant Hiến pháp NT1/NT9/NT13.
3. Explicit statement: raw SQL is BLOCKED; admin fallback not justified.
4. Recommended legal path: use dot-collection-register for information_unit and unit_version, then run health/trigger/birth verification tools if appropriate.
5. Parameter decision table:
   • governance_role: options governed vs observed etc.; include HC-SCHEMA/description-column consequence; recommend one.
   • storage_role: derive from live conventions; recommend one.
   • source_kind: likely pg_table; justify.
   • migration_state: likely pilot; justify.
   • Directus exposure: recommend NO in Pack 2A unless evidence says otherwise.
6. Tool command plan:
   • read-only preflight commands before write;
   • exact dot-collection-register command(s) or safe way to derive CLI syntax;
   • verify with collection_registry, birth_registry, meta_catalog, directus_collections, dot-collection-health;
   • trigger governance sequence using dot-schema-trigger-registry-ensure and/or dot-trigger-guard, with no DDL unless tool contract proves it is only registry sync/health.
7. Rollback/compensation:
   • prefer tool-supported unregister/update path if exists;
   • if not, STOP before write and ask for decision; no raw DELETE rollback unless the tool/law allows it.
8. Điều 20 v1.2 requirements:
   • estimated execution cost;
   • internal + external evidence for each write/verify;
   • mini postmortem on STOP/fail/rollback/runtime mismatch.
9. Claude Code final report format.
10. Hard stop: no Pack 2B/2C, no CRUD, no IU production rows, no outbox, no Qdrant/vector, no Directus exposure unless explicitly approved.

Do not dispatch Claude Code yet. Upload file 12 and report back for GPT/User review.

User decision needed after file 12

The only likely semantic decision for User/GPT is governance_role if Opus cannot prove a safe default.

Avoid asking User for low-level values if the design can derive them from law/tool conventions.