GPT Review — P1 Partial STOP due to birth_registry drift + restart directive

Date: 2026-05-05 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed: knowledge/dev/laws/dieu44-trien-khai/reports/dot119-repair-p1-metadata-ddl-seed-report.md rev1 partial

Verdict

Agent did the correct thing. P1 prompt was too hardcoded.

The STOP at Step 1d is valid because the prompt hardcoded birth_registry count = 75,450. Runtime count was 75,466 (+16). Agent correctly stopped, uploaded partial report, and performed no mutation.

This is not evidence of corruption:

• fn_birth_registry_auto hash unchanged: 1f729b3571a74963089bb3ef388217f3.
• Birth trigger count unchanged: 30.
• Target fields absent.
• No DDL / UPDATE / INSERT / file write occurred.
• Drift appears to be normal platform activity.

Root cause

The prompt encoded a dynamic operational count as a static invariant. This violates the anti-hardcode principle.

birth_registry is live and naturally changes while the platform runs. It should not be checked against a literal historical number unless writers are frozen.

Correct invariant model

Use dynamic baseline locking, not static hardcode.

At the start of each P1 run:

1. Snapshot dynamic counts:
   • birth_registry row count;
   • birth trigger count;
   • function hash.
2. Treat the snapshot as the run-local baseline.
3. Within mutation transactions:
   • fn_birth_registry_auto hash must remain equal to snapshot.
   • trigger count must remain equal to snapshot.
   • birth_registry count should not change due to P1 operations.
4. Because external writers may run concurrently, either:
   • use a transaction-local before/after check during the seed/constraint transaction; or
   • allow background drift but record it, provided P1 itself does not create triggers or rows.

For this P1, the safest practical rule is:

• Snapshot birth_registry count at Step 1.
• Re-check before and after each P1 mutation block.
• If count changes during a short P1 transaction, STOP/rollback for review.
• Do not compare to stale P0 hardcoded value.

Approved decision

Option A/B hybrid: Revise P1 prompt to use a run-local baseline captured at Step 1.

Do not freeze writers. Freezing is overkill for this metadata-only phase.

Do not waive checks entirely. Keep checks, but make them dynamic.

Required P1 rev4 patch

Patch P1 prompt to rev4:

1. Replace hardcoded birth_registry = 75450 with:

   • capture BIRTH_COUNT_BASELINE at Step 1;
   • report its value;
   • use it as this run's baseline.

2. Keep hardcoded expected values only where they are structural/static:

   • function hash = 1f729b3571a74963089bb3ef388217f3 is acceptable until function intentionally changes;
   • trigger count = 30 may still be structural for this phase, but better phrase as “must match Step 1 baseline and expected current value 30”; if runtime is not 30, STOP.

3. In seed transaction:

   • capture BIRTH_COUNT_BEFORE_SEED immediately before BEGIN or inside transaction before updates;
   • verify BIRTH_COUNT_AFTER_SEED = BIRTH_COUNT_BEFORE_SEED before COMMIT;
   • if mismatch, ROLLBACK + partial report.

4. In PG enforcement transaction:

   • capture BIRTH_COUNT_BEFORE_CONSTRAINTS;
   • verify BIRTH_COUNT_AFTER_CONSTRAINTS = BIRTH_COUNT_BEFORE_CONSTRAINTS before COMMIT;
   • if mismatch, ROLLBACK + partial report.

5. Final report should show:

   • P0 reference count = 75,450;
   • P1 run baseline count = current count;
   • drift from P0;
   • before/after counts for each mutation block.

6. Add explicit anti-hardcode note:

   • live operational row counts are not static invariants;
   • use run-local baselines unless writers are frozen.

7. Preserve all other P1 boundaries:

   • no DOT-119 execution;
   • no script rewrite;
   • no function edit;
   • no IU trigger;
   • no IU rows;
   • no Pack 2B.

Next directive

Opus should patch P1 prompt to rev4. After rev4, P1 can be re-dispatched.

No need to redo P0/P1a. The partial STOP provided enough evidence to adjust the prompt.