GPT Review — B3-F1c-a Full-Scan Compiled Artifacts — BLOCKED, Revision Required — 2026-05-13

Scope reviewed

Reviewed Opus assessment relayed by user and Agent B3-F1c-a report/artifacts:

• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-full-scan-shape-probe-and-compile-report.md
• 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-scheduler.sql.md
• knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-full-scan-rollback.sql.md

Related governing reviews:

• knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1c-full-scan-automation-design-and-prompt-approved-2026-05-13.md
• knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1b-soft-gate-execution-pass-2026-05-13.md

Verdict

Status: BLOCKED_REVISION_REQUIRED

The B3-F1c-a probe itself is accepted as useful. The compiled function/scheduler/rollback artifacts are not approved for B3-F1c-b execution.

Accepted findings

• pg_cron_installed=false and pg_cron_available=false; pg_cron path is closed for this environment.
• directus_flows_scheduler_exists=true; Directus Flows is the only currently proven automatic scheduling path.
• system_health_checks_shape_sufficient=false for per-run summaries; live shape is a check-definition registry, not a run-results table.
• Existing B3-F1b helper and gate are present.
• fn_birth_onboarding_full_scan has no naming conflict.
• No DDL/DML was executed by B3-F1c-a.

Blocking issue 1 — function artifact still contains COMMENT ON FUNCTION

The compiled function artifact includes:

COMMENT ON FUNCTION public.fn_birth_onboarding_full_scan() IS ...

B3-F1c-b has not been approved for metadata DDL. Prior B3-F1b pattern deliberately removed COMMENT ON from executable artifacts to keep execution scope narrow.

Required correction:

• Remove COMMENT ON FUNCTION from the executable function artifact, or separate it into an optional metadata artifact requiring explicit approval.
• Default: remove it.

Blocking issue 2 — contract/sibling function resolution failures are not surfaced as system-level failures

The function uses strict resolution CTEs, but ambiguity/missing cases collapse into NULL or skipped arrays and then proceed. This can cause misleading per-collection gaps or false compliance instead of surfacing a scanner configuration failure.

Examples:

• fn_birth_registry_auto missing/ambiguous becomes contract_oid=NULL; scan may report many MISSING_ACCEPTED_BIRTH_TRIGGER rows rather than a single scanner dependency failure.
• sibling policy function entries with missing/ambiguous resolution are marked internally, but the full-scan function does not clearly emit/return a policy/function-resolution failure.

Required correction:

• Before scanning rows, validate dependencies explicitly:
  • contract trigger function resolves to exactly one zero-arg trigger function;
  • dot_config sibling policy exists and parses with entries array;
  • each active policy sibling function resolves unambiguously or is explicitly excluded only when there is no live usage;
  • ambiguous sibling function resolution is a scan-level critical failure.
• The function should return JSONB with status='dependency_fail' and/or log a clear FULL_SCAN_DEPENDENCY_FAIL issue if dependencies fail, while still not raising to the scheduler unless explicitly intended.
• Do not silently convert dependency failures into ordinary collection onboarding gaps.

Blocking issue 3 — compiled function contains a hardcoded schema assumption in runtime logic

The function hardcodes public in many places. This may be acceptable if the execution prompt locks the target schema to public, but the artifact should explicitly state this as a reviewed deployment target, not as a scalable runtime discovery mechanism.

Required correction:

• Either keep public as a reviewed deployment constant and document it explicitly in the artifact header and future execution prompt; or compile schema-qualified SQL from live db_schema=DISCOVER and treat it as artifact-local deployment config.
• Do not describe this as fully schema-agnostic.

Blocking issue 4 — directus flow rollback artifact includes unapproved Directus row deletes

Rollback artifact currently includes Directus Flow/Operation UPDATE/DELETE statements even though no Directus scheduler execution path has been approved yet. This broadens rollback scope prematurely.

Required correction:

• Split rollback into two artifacts:
  1. B3-F1c-b function rollback: drop only fn_birth_onboarding_full_scan().
  2. Future Directus scheduler rollback: remove only specifically-created Flow/Operation rows, after scheduler path is designed and approved.
• Current B3-F1c-b function execution rollback must not include Directus Flow/Operation DML.

Blocking issue 5 — scheduler path requires separate design, not just a seed artifact

Agent correctly found Directus Flow is the only proven automatic scheduler path, but the artifact also says a Nuxt endpoint is required. That endpoint is outside SQL and must be designed/reviewed before scheduling can be bound.

Required correction:

• Do not combine B3-F1c-b function installation with Directus Flow scheduling.
• Split:
  • B3-F1c-b: install PG full-scan function only, after artifact correction.
  • B3-F1c-c or B3-F1d: design Nuxt endpoint + Directus Flow binding + cadence policy.

Blocking issue 6 — “system_health_checks = definition registry” decision needs formal acceptance before bypass

The report concludes system_health_checks cannot store per-run summaries. That is likely correct from live shape, but the design should not simply bypass health checks without a formal replacement for run observability.

Required correction:

• Document that run summary is returned via JSONB and gap details are in system_issues.
• For scheduler path, define where the returned JSONB summary is persisted/logged: Directus Flow run log, Nuxt endpoint log, or another approved run-history store.
• B3-F cannot be declared fully automatic until the automatic path has durable observability.

Required next step

Opus should revise B3-F1c into narrower next steps:

B3-F1c-b — PG function install only

• Fix function artifact.
• Remove COMMENT ON.
• Add dependency-failure behavior.
• Use rollback that drops only fn_birth_onboarding_full_scan().
• Draft execution prompt for function install only.

B3-F1c-c / B3-F1d — Scheduler binding

• Design Nuxt endpoint and Directus Flow binding.
• Select cadence as policy/config.
• Define where JSONB summary is persisted.
• Review before any Directus Flow/Operation insert.

Governance status

b3f1c_a_artifact_review_status=BLOCKED_REVISION_REQUIRED
b3f1c_b_function_execution_allowed=false
b3f1c_scheduler_binding_allowed=false
b3f_complete_allowed=false
hard_gate_allowed=false
phase5c2_migration_allowed=false
next_recommended_action=OPUS_REVISE_B3F1C_FUNCTION_ARTIFACT_AND_SPLIT_SCHEDULER_DESIGN