KB-1B30

GPT Review — B3-F1a Recompiled SQL rev2 — BLOCKED, Revision Required — 2026-05-13

7 min read Revision 1
p3dbirth-systemb3f1acompiled-sqlrev2gpt-reviewblocked2026-05-13

GPT Review — B3-F1a Recompiled SQL rev2 — BLOCKED, Revision Required — 2026-05-13

Scope reviewed

Reviewed Agent B3-F1a recompile report and rev2 SQL artifacts:

  • knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1a-soft-gate-shape-probe-and-sql-artifact-report.md
  • knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1a-soft-gate-compiled-function.sql.md rev2
  • knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1a-soft-gate-compiled-trigger.sql.md rev2
  • knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1a-soft-gate-rollback.sql.md rev2
  • knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1a-soft-gate-full-scan-query.sql.md rev2

Also considered Opus summary relayed by user.

Verdict

Status: BLOCKED_REVISION_REQUIRED

The rev2 recompile fixed most previous blockers, but the compiled SQL is still not approved for B3-F1b execution. Remaining issues are material enough that Opus/Agent must recompile rev3 artifacts.

Accepted improvements

Rev2 correctly fixes these prior blockers:

  1. CREATE OR REPLACE removed from helper/gate function definitions.
  2. Helper renamed to task-specific fn_b3f1_log_collection_onboarding_gap.
  3. Helper accepts severity parameter.
  4. Most gap severities are now gap-specific.
  5. Physical/species/accepted-trigger checks are scoped to BIRTH_REQUIRED ∩ IN_SCOPE.
  6. All 11 intended gap types are represented.
  7. birth_registry recursive-risk check happens before the row returns.
  8. Trigger detection uses separate booleans and tgfoid / tgtype checks instead of MAX(proname).
  9. Sibling policy is read from dot_config and supports multiple entries.
  10. Rollback uses the revised helper name/signature and does not touch B3-A artifacts or sibling policy.

Blocking issue 1 — SIBLING_OUT_OF_SCOPE is scoped too narrowly

Rev2 only checks/logs SIBLING_OUT_OF_SCOPE inside:

coverage_status='BIRTH_REQUIRED' AND coverage_scope_status='IN_SCOPE'

This is incorrect. A sibling birth function outside the PG policy scope is a birth-contract violation regardless of whether the collection is currently BIRTH_REQUIRED, IN_SCOPE, exempt, deferred, future-scope, or otherwise.

Required correction:

  • Detect out-of-scope sibling triggers for any collection_registry row with a physical table, excluding only the special birth_registry recursive-risk path.
  • Keep MISSING_ACCEPTED_BIRTH_TRIGGER scoped to BIRTH_REQUIRED ∩ IN_SCOPE.
  • Keep physical/species/trigger-required coverage scoped to BIRTH_REQUIRED ∩ IN_SCOPE.
  • But SIBLING_OUT_OF_SCOPE must be global to all registry collections with sibling AIR trigger outside policy scope.

The full-scan query has the same defect and must be recompiled.

Blocking issue 2 — executable artifact includes COMMENT DDL not covered by approval boundary

Rev2 function and trigger artifacts include:

COMMENT ON FUNCTION ...
COMMENT ON TRIGGER ...

B3-F1b was authorized only for CREATE FUNCTION + CREATE TRIGGER soft-gate artifacts after GPT review. COMMENT ON is also DDL/metadata mutation and was not included in the execution boundary.

Required correction:

  • Either remove COMMENT ON ... statements from the executable B3-F1b SQL artifacts, or explicitly separate them into an optional metadata DDL artifact requiring separate approval.
  • Default recommendation: remove comments from the executable SQL for B3-F1b to keep execution boundary narrow.

Blocking issue 3 — function OID resolution should constrain trigger-function signature

Rev2 resolves functions by proname only:

WHERE n.nspname='public' AND p.proname='fn_birth_registry_auto'
LIMIT 1

and similarly for sibling policy entries.

Required correction:

  • Resolve only zero-argument trigger functions:
    • p.pronargs = 0
    • p.prorettype = 'pg_catalog.trigger'::regtype
  • If multiple matching functions exist, block/report ambiguity in the artifact logic or use an unambiguous resolver.
  • Apply this to the contract function and sibling functions from policy entries.

Blocking issue 4 — helper silently swallows issue-write failures with no observability

The helper has:

EXCEPTION WHEN OTHERS THEN RETURN;

This preserves soft-gate non-blocking behavior, but it also hides all issue-write failures. Since the only purpose of the soft gate is to log issues, total silent failure reduces the gate to no-op if system_issues insert starts failing.

Required correction direction:

  • The function must still never block writes.
  • But artifacts should add a safe observability path, or explicitly document why silent helper failure is accepted.
  • Preferred safe approach: remove the helper-level catch and rely on the outer gate function EXCEPTION WHEN OTHERS THEN RETURN NEW, or catch only in the outer function. If issue insert fails, the gate will not block but the failure boundary is centralized.
  • If keeping helper catch, add a clear review note that issue-write failure is intentionally swallowed and explain how B3-HC/full-scan detects gate no-op risk later.

Blocking issue 5 — execution prompt for B3-F1b must include in-transaction smoke checks without DML

B3-F1b is not yet drafted, but the compiled artifacts need to support a safe execution prompt. Before approval, Opus should ensure the next B3-F1b prompt will verify:

  • all three artifact names are still absent before CREATE;
  • function definitions installed exactly as reviewed;
  • trigger installed and bound to reviewed function OID;
  • trigger timing/event/row-level and UPDATE columns match reviewed artifact;
  • no DML smoke test is performed unless separately approved.

This does not require changing SQL logic, but must be reflected in the B3-F1b execution prompt later.

No-hardcode assessment

Rev2 is much improved, but hardcode-sensitive areas remain:

  • Contract function name is acceptable as contract identifier, but must resolve unambiguously as a zero-arg trigger function.
  • Sibling scope is PG-policy driven and no collection list is embedded; this is acceptable.
  • Out-of-scope sibling detection must not be limited to BIRTH_REQUIRED ∩ IN_SCOPE, otherwise policy violations outside that subset will be invisible.

Required next step

Opus should revise the compile directive/prompt or instruct Agent to regenerate rev3 artifacts addressing the blockers above.

Governance status

b3f1a_recompiled_sql_review_status=BLOCKED_REVISION_REQUIRED
b3f1b_execution_allowed=false
create_function_allowed=false
create_trigger_allowed=false
pg_mutation_allowed=false
hard_gate_allowed=false
phase5c2_migration_allowed=false
next_recommended_action=OPUS_REVISE_B3F1A_REV3_DIRECTIVE_THEN_AGENT_RECOMPILE
Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1a-recompiled-sql-rev2-blocked-2026-05-13.md