GPT Review — Birth B3 rev2 Direction OK; Not Approved: Onboarding Gate Needs PG-Native Contract Hardening

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

• knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-system-b3-trigger-design-and-governance-decisions.md rev2
• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-system-b3-trigger-implementation-prompt-DRAFT.md rev2
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3-trigger-design-report.md rev2

Verdict

B3 rev2 direction is correct but NOT approved for Agent dispatch.

The Collection Onboarding Gate is the right concept and is required to avoid hardcode-by-process. However, rev2 turns the gate into executable DDL too early while still relying on hardcoded column names and incomplete governance storage design.

The user’s principle is binding:

Hạ tầng tự mở rộng. No hardcode, no hardcode trá hình, no list-as-truth.

What is accepted

1. Adding Collection Onboarding Gate is mandatory.
2. 4-stage enforcement is the right direction:
   • audit;
   • issue creation;
   • soft gate;
   • hard gate.
3. SPECIES_MAPPING_ONBOARDING_QUEUE is required.
4. 3-set matching is correct in principle:
   • approved target set;
   • live BIRTH_REQUIRED set;
   • live species-mapped set.
5. PG-first / PG-native / PG-driven remains correct.
6. External tools remain out of scope.

Blocking issues

1. Gate executable is too hardcoded

The prompt’s fn_collection_onboarding_gate() sample uses direct columns:

NEW.collection_name
NEW.governance_role
system_health_checks.check_type / target_entity / status / details / checked_at
system_issues.category / severity / entity_ref / description / status
species_collection_map.collection_name

Even though the prompt later says these are semantic hints, the function body is presented as executable-looking PL/pgSQL. This is hardcode trá hình.

Required: gate implementation prompt must first resolve concept/table/column map and then generate compiled function body from resolved names. No direct raw column names in executable function template.

2. Coverage policy storage is missing

The design says gate checks coverage_status, coverage_scope_status, exemption reason, review owner, etc. But it does not define where these values live.

Current prompt code only checks:

physical table exists
species mapping exists
birth trigger exists

That is not enough. It does not enforce the governance decision that every collection must have trigger OR exemption OR deferred status.

Required: define PG-native policy storage before gate implementation. Options must be evaluated:

collection_registry columns
coverage policy JSONB in collection_registry / meta_catalog
separate birth_coverage_policy registry table

No DDL approved yet, but the contract must say where the gate reads policy from.

3. CREATE OR REPLACE FUNCTION is unsafe in production-write prompt

CREATE OR REPLACE FUNCTION fn_collection_onboarding_gate() may silently overwrite an existing function.

Required: function creation must be conflict-aware:

if function absent → create candidate
if function exists and exact definition/version matches → OK
if function exists and differs → BLOCKED_EXISTING_CONFLICT

Do not overwrite silently.

4. B3-A and B3-F are mixed too much

Trigger install for current approved collections and onboarding-gate infrastructure are different risk classes.

Recommended split:

B3-A = trigger install design for approved current target set
B3-F = onboarding gate design + later implementation prompt

They may be sequenced together later, but prompt should not merge them until policy storage and function conflict handling are mature.

5. Approved policy source is still vague

Prompt says:

approved_target_policy_source = classification report

But the classification report is evidence, not durable policy. A future-safe system needs a PG-native approved policy source or an explicit GPT/User-approved artifact with version/hash.

Required: add approved_policy_artifact_id / policy_version / policy_hash concept for execution prompts, or design PG policy storage.

6. Trigger naming is still convention-based

trg_birth_<collection> is a convention. The system must verify trigger by function binding, event timing, and target table, not only name.

Required verification:

trigger exists
trigger event = INSERT
trigger timing = AFTER
trigger function = resolved fn_birth_registry_auto oid
trigger table = resolved table

7. Rollback deletes issues by timestamp/category

Prompt suggests deleting system_issues and system_health_checks by category + timestamp. This is not exact-key enough.

Required: capture exact inserted issue/check IDs via RETURNING, then rollback exact IDs only.

8. Future collection coverage should not rely only on trigger on collection_registry

An onboarding gate trigger is good, but not sufficient by itself. Need a scheduled/health-check query too, because:

• collections may pre-exist;
• policy fields may be patched outside the trigger path;
• trigger may fail or be disabled;
• physical table may be created after registry row.

Required: design both:

row-level onboarding gate
periodic birth_coverage_gap_check health check

Required next action

Patch B3 rev2 → rev3.

Open:

P3D_BIRTH_B3_REV3_SELF_EXPANDING_INFRA_NO_HARDCODE

Mode:

DESIGN PATCH + PROMPT SPLIT ONLY — no execution

Status

b3_rev2_direction=ACCEPTED
b3_rev2_prompt=NOT_APPROVED_FOR_DISPATCH
reason=onboarding_gate_missing_policy_storage_and_contains_executable_hardcode
agent_dispatch_allowed=false
phase5c2_migration_allowed=false
external_tool_install_allowed=false
next_action=OPUS_PATCH_B3_REV3_SELF_EXPANDING_INFRA_NO_HARDCODE