GPT Review — DOT-119 P1a Schema Tool Inspection + P1 Decision

Date: 2026-05-05 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed:

• knowledge/dev/laws/dieu44-trien-khai/reports/dot119-repair-p1a-schema-tool-inspection-report.md
• Opus summary in conversation

Verdict

P1a PASS. Agent did the right read-only inspection.

Agent correctly inspected DOT-074, DOT-063, DOT-067, DOT-068 and did not mutate anything.

Key findings accepted

1. DOT-074 is not suitable for this narrow field-add

   • Hardcoded to a known collection_registry field list.
   • Would require source edit.
   • Re-running would also re-run unrelated permissions and meta_catalog PATCH side effects.
   • Reject for P1.

2. DOT-063 is the cleanest field-add path

   • Generic spec-driven field add.
   • Uses Directus REST API.
   • Idempotent skip existing fields.
   • No function/trigger risk.
   • No meta_catalog/permission side effects.

3. DOT-067 is read-only verification

   • Useful for pre/post diff, not for mutation.

4. DOT-068 irrelevant

   • Hardcoded to agent_views.

5. No schema tools here can clobber fn_birth_registry_auto

   • DOT-119 remains the function-clobber risk; this is P2 scope.

Important correction to Opus proposal

Opus correctly noticed a key issue:

DOT-063 via Directus REST can add fields and Directus metadata, but it likely does not create PG-level CHECK constraints / NOT NULL / DEFAULT exactly as 18a intended.

Therefore GPT does not accept “DOT-063 only” as complete P1.

GPT P1 decision

Use a hybrid path:

P1 Step A — Add fields through DOT-063

Use DOT-063 dot-schema-apply with a spec JSON for the 3 fields. This ensures Directus field registration and avoids manual directus_fields insert.

P1 Step B — Seed metadata

Use exact seed SQL derived from P0 mapping:

• 25 column
• 3 legacy_id_single_colon
• 1 synthetic_id (information_unit)
• 1 subordinate (unit_version)
• 60 disabled plus 3 additional explicit disabled:
  • v_registry_counts
  • v_registry_summary
  • birth_registry
• remaining rows stay unclassified.

The 3 additional disabled classifications are approved.

P1 Step C — Add PG enforcement after seed

After all rows have values, run narrow raw PG DDL to enforce:

• default birth_code_strategy = 'unclassified'
• default birth_identity_source = 'unclassified'
• birth_code_strategy NOT NULL
• birth_identity_source NOT NULL
• CHECK enum for birth_code_strategy
• CHECK enum for birth_identity_source

This raw DDL is acceptable as a supplement because DOT-063 covers Directus registration but not PG constraints. It must be in transaction and verified.

Recommended constraint names:

• collection_registry_birth_code_strategy_check
• collection_registry_birth_identity_source_check

birth_code_column remains nullable.

Decisions on P1a open items

A — DDL channel

Hybrid DOT-063 + narrow raw PG enforcement.

Use DOT-063 for field creation. Use raw PG DDL only for constraints/defaults/NOT NULL that DOT-063 cannot express.

B — Views

v_registry_counts and v_registry_summary → disabled.

Rationale: views are not born entities and cannot have birth triggers.

C — birth_registry itself

birth_registry → disabled.

Rationale: no self-birth trigger; avoids recursion/governance confusion.

D — Other 76 unclassified

Only the 3 rows above are reclassified to disabled. All remaining unclassified rows stay unclassified.

E — Directus fields

DOT-063 should create/register the fields. Verify directus_fields. If absent despite DOT-063, STOP/report; do not manual insert.

Directive to Opus/Ocus

Do not dispatch P1 yet.

Patch/create the P1 prompt according to the hybrid decision above:

knowledge/dev/laws/dieu44-trien-khai/prompts/18b-p1-dot119-metadata-ddl-and-seed-prompt.md

P1 prompt must include:

1. Read controlling docs:

   • 18a rev4
   • 18b rev3
   • P0 report
   • P1a report
   • this GPT review

2. Baseline checks:

   • 3 fields absent;
   • fn hash equals P0 baseline 1f729b3571a74963089bb3ef388217f3;
   • trigger count = 30;
   • birth_registry count = 75,450.

3. DOT-063 field creation:

   • write exact spec JSON;
   • include choices for all strategy/source values;
   • run DOT-063 --dry-run first;
   • run DOT-063 live only after dry-run output is sane;
   • verify via information_schema.columns and directus_fields.

4. Seed metadata:

   • exact SQL from P0 mapping, no placeholders;
   • include the approved reclassifications:
     • v_registry_counts → disabled
     • v_registry_summary → disabled
     • birth_registry → disabled
   • keep all other unclassified rows unclassified;
   • print update counts and distribution.

5. PG enforcement DDL after seed:

   • transaction;
   • set defaults;
   • set NOT NULL for strategy/source;
   • add CHECK constraints;
   • verify constraints in pg_constraint;
   • verify no rows violate enum/default expectations.

6. Safety checks:

   • fn hash unchanged;
   • trigger count unchanged;
   • birth_registry count unchanged;
   • no DOT-119 execution;
   • no function edits;
   • no IU trigger/rows.

7. Report path:

   • knowledge/dev/laws/dieu44-trien-khai/reports/dot119-repair-p1-metadata-ddl-seed-report.md

8. HARD STOP after report.

Current state

P1a is accepted. P1 should be drafted as hybrid DOT-063 + raw PG enforcement after seed, then reviewed before dispatch.