GPT Review — B3-F1c Revised Artifacts — BLOCKED: Schema Join + JSON Dependency Handling — 2026-05-13

Scope reviewed

Reviewed Opus revision deliverables:

• knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-full-scan-function.sql.md
• knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-full-scan-rollback.sql.md
• knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-full-scan-scheduler.sql.md
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-revision-directive-report.md

Related blocker review:

• knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1c-a-full-scan-compiled-artifacts-blocked-2026-05-13.md

Verdict

Status: BLOCKED_REVISION_REQUIRED

Opus addressed the previous 6 blocking issues materially, but GPT found two additional execution-blocking issues in the revised function artifact. B3-F1c-b execution remains disallowed.

Previous fixes accepted

The following previous blockers are accepted as fixed:

1. COMMENT ON FUNCTION removed from executable artifact.
2. Dependency-failure behavior added before collection scan.
3. public schema declared as reviewed deployment target.
4. Rollback narrowed to function-only.
5. Scheduler binding split to future phase.
6. Observability options documented for future scheduler design.

New blocking issue 1 — pg_class trigger join is not schema-locked

The revised function's trg_eval CTE uses:

LEFT JOIN pg_class c ON c.relname = r2.collection_name
LEFT JOIN pg_namespace n ON n.oid = c.relnamespace AND n.nspname = 'public'
LEFT JOIN pg_trigger t ON t.tgrelid = c.oid ...

Because pg_class is joined by relname before schema filtering, a relation with the same name in a non-public schema could still join to pg_trigger through c.oid, while n is merely NULL. This can create false trigger detections or duplicate trigger rows when the system scales to multiple schemas or extension-owned objects.

Required correction:

• Lock the pg_class join to the reviewed deployment schema directly, for example:

LEFT JOIN pg_class c
  ON c.relname = r2.collection_name
 AND c.relnamespace = 'public'::regnamespace
LEFT JOIN pg_trigger t
  ON t.tgrelid = c.oid
 AND NOT t.tgisinternal
 AND t.tgenabled <> 'D'

or equivalent schema-qualified resolution.

The same principle applies anywhere the function resolves a table by name from catalog metadata: relation lookup must be schema-qualified as public, not relname-only.

New blocking issue 2 — malformed sibling policy JSON can raise instead of returning dependency_fail

The function reads policy via:

SELECT NULLIF(value, '')::jsonb
INTO v_policy_raw
FROM public.dot_config
WHERE key = 'policy.birth_trigger.accepted_sibling_scope';

If the dot_config.value is malformed JSON, this cast can raise an exception before the function returns its intended status='dependency_fail' JSONB. For a full-scan automation function, policy corruption should be reported as scanner dependency failure, not an uncaught function error.

Required correction:

• Add safe JSON parsing behavior around sibling policy loading.
• If parse fails, return JSONB with:

{
  "status": "dependency_fail",
  "dependency_failures": ["SIBLING_POLICY_MALFORMED_JSON: ..."]
}

• Do not proceed to collection scan.
• Do not emit misleading per-collection gaps.

Possible implementation:

• Use a small inner BEGIN ... EXCEPTION WHEN OTHERS THEN ... END; block only around JSON parse, setting v_dep_failures rather than raising.
• This is acceptable because the dependency failure is returned explicitly.

Additional recommended hardening — duplicate sibling policy key

If dot_config can contain duplicate keys, SELECT ... INTO without STRICT may silently take one row. Prior B3-F0a verified exactly one policy row at materialization time, but full-scan should remain safe against future drift.

Recommended correction:

• Count rows for policy.birth_trigger.accepted_sibling_scope.
• If count = 0 → dependency_fail.
• If count > 1 → dependency_fail SIBLING_POLICY_DUPLICATE_KEY.
• If count = 1 → parse that one value.

This can be treated as required if no unique constraint exists on dot_config.key.

Accepted rollback/scheduler direction

The function-only rollback direction is accepted in principle:

• Drops only public.fn_birth_onboarding_full_scan().
• Does not touch Directus Flow/Operation.
• Does not touch B3-F1b, B3-A, dot_config policy, system_issues, or system_health_checks.

The scheduler decision document direction is accepted in principle:

• Directus Flow + Nuxt endpoint is split to future design.
• Scheduler binding remains disallowed.
• Observability remains unresolved and must be designed before B3-F can be marked complete.

Required next step

Opus should revise only the B3-F1c function artifact and report. Rollback/scheduler artifacts may remain unchanged unless the function name/scope changes.

Required deliverables:

1. Revised function artifact:
   • knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-full-scan-function.sql.md
2. Update or append revision report:
   • knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-revision-directive-report.md

Required fixes:

• pg_class/trigger relation lookup schema-locked to public.
• malformed JSON policy returns dependency_fail, not uncaught exception.
• duplicate policy key check if dot_config.key uniqueness is not guaranteed.

Governance status

b3f1c_revised_artifact_review_status=BLOCKED_REVISION_REQUIRED
b3f1c_b_function_execution_allowed=false
b3f1c_scheduler_binding_allowed=false
b3f_complete_allowed=false
phase5c2_migration_allowed=false
next_recommended_action=OPUS_REVISE_B3F1C_FUNCTION_ARTIFACT_FOR_SCHEMA_LOCK_AND_SAFE_JSON_PARSE