Opus Handoff — B3-F1c Full-Scan Revision — 2026-05-13
HANDOFF FOR OPUS — P3D Birth System Completion / B3-F1c Full-Scan Revision
Date: 2026-05-13
Recipient: Opus
Mainline: P3D_BIRTH_SYSTEM_COMPLETION_PACK
Language: Vietnamese preferred
Mode: PG-first, PG-native, PG-driven, no hardcode, no hardcode trá hình, self-expanding infrastructure
0. Why this handoff exists
Opus previous session ran out of context before implementing GPT's latest directive.
This handoff is intended to let Opus continue immediately and seamlessly.
Current task: revise B3-F1c full-scan artifacts after GPT blocked the compiled artifacts.
Do not go back to older B3-F1b/B3-F1c assumptions. The latest source of truth is the GPT review:
knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1c-a-full-scan-compiled-artifacts-blocked-2026-05-13.md
1. Constitutional / operating principles
These are non-negotiable:
PG-first
PG-native
PG-driven
No hardcode
No hardcode trá hình
No list-as-truth
No snapshot counts as gates
Hạ tầng tự mở rộng
Nếu không chắc đúng thì coi là sai
If any design/prompt needs live facts, use Agent for a quick read-only probe instead of assuming.
For PG functions/triggers/schedulers:
Two-pass rule:
1. Shape probe / compile artifact only.
2. GPT reviews compiled SQL/artifacts.
3. User approval.
4. Agent executes reviewed SQL only.
No Agent may derive and execute new PL/pgSQL in the same run.
2. Current system status
Completed / accepted
B3-A is COMPLETE.
B3-F0 dry-run after policy materialization is PASS.
B3-F0a materialized sibling policy into dot_config:
key = policy.birth_trigger.accepted_sibling_scope
B3-F1b soft gate is LIVE in PG and accepted:
knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1b-soft-gate-execution-pass-2026-05-13.md
Installed objects:
public.fn_b3f1_log_collection_onboarding_gap(text,text,text,text)
public.fn_collection_onboarding_soft_gate()
public.trg_collection_onboarding_soft_gate ON public.collection_registry
B3-F1b catches collection_registry INSERT/UPDATE on these policy-relevant columns:
governance_role
coverage_status
coverage_scope_status
coverage_exemption_reason
coverage_review_owner
B3-F1b is only a soft gate. It does not block writes.
Caveat still open
B3-F1b does not catch all direct PG DDL drift, for example:
rogue trigger creation on another table
physical table create/drop without registry mutation
species mapping changes without registry mutation
birth trigger disable/drop without registry mutation
function/policy changes without registry mutation
Therefore B3-F1c / B3-HC full-scan automation is required before declaring B3-F fully automatic.
3. B3-F1c-a latest Agent result
Agent ran B3-F1c-a shape probe + compile.
Report:
knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-full-scan-shape-probe-and-compile-report.md
Artifacts produced:
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
Agent result was PARTIAL, which is acceptable for the probe because scheduler binding is not ready.
Accepted probe facts:
pg_cron_installed=false
pg_cron_available=false
directus_flows_scheduler_exists=true
system_health_checks_shape_sufficient=false
existing_helper_present=true
existing_gate_present=true
full_scan_function_conflict=false
no_ddl_executed=true
no_pg_mutation_performed=true
recommended_scheduling=DIRECTUS_FLOW
Interpretation:
- pg_cron path is closed in this environment.
- Directus Flow is the only proven live automatic scheduler vehicle.
system_health_checksis a check-definition registry, not a run-results table.- Full-scan function can be installed later, but scheduler binding requires a separate design with Nuxt endpoint / Directus Flow.
4. Latest GPT verdict on B3-F1c-a artifacts
GPT reviewed the B3-F1c-a artifacts and blocked them:
b3f1c_a_artifact_review_status=BLOCKED_REVISION_REQUIRED
b3f1c_b_function_execution_allowed=false
b3f1c_scheduler_binding_allowed=false
b3f_complete_allowed=false
Review path:
knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1c-a-full-scan-compiled-artifacts-blocked-2026-05-13.md
Do not approve B3-F1c-b execution yet. Do not bind Directus Flow yet. Do not declare B3-F complete.
5. Blocking issues that Opus must fix
Issue 1 — function artifact still contains COMMENT ON FUNCTION
Current function artifact includes:
COMMENT ON FUNCTION public.fn_birth_onboarding_full_scan() IS ...
This is metadata DDL. B3-F1c-b has not been approved for metadata DDL.
Required fix:
Remove COMMENT ON FUNCTION from executable function artifact.
If comments are desired, split into optional metadata artifact requiring separate approval.
Default: remove it.
Issue 2 — dependency failure behavior is not explicit enough
The current function uses strict resolution CTEs, but missing/ambiguous contract/sibling functions can collapse into NULL/skipped arrays and then proceed as normal scan output.
This can cause misleading results, for example:
fn_birth_registry_auto missing/ambiguous
→ contract_oid = NULL
→ many MISSING_ACCEPTED_BIRTH_TRIGGER rows
This is wrong. A scanner infrastructure dependency failure must be a scan-level failure, not silently converted into ordinary collection gaps.
Required fix:
Before scanning collection rows, validate:
1. contract function resolves exactly once as zero-arg trigger function
2. dot_config sibling policy exists and parses
3. sibling policy entries resolve according to strict rules
4. ambiguous sibling function resolution is a scan-level dependency failure
If dependency failure:
return JSONB with status='dependency_fail'
include failing dependency details
optionally log one FULL_SCAN_DEPENDENCY_FAIL issue if safe and deduped
DO NOT emit misleading per-collection MISSING_ACCEPTED_BIRTH_TRIGGER rows caused by missing contract function
Recommended minimal safe path:
Return JSONB dependency_fail without logging any issue if helper/system state is part of the dependency failure.
If Opus proposes logging FULL_SCAN_DEPENDENCY_FAIL, it must show a safe dedup path using the existing helper or another approved issue identity.
Issue 3 — schema public must be explicitly declared as deployment target
The function uses public throughout.
This can be acceptable only if stated as reviewed deployment config, not as runtime schema discovery.
Required fix:
Declare: schema=public is the reviewed deployment target for this artifact.
Or compile using discovered schema as explicit artifact deployment config.
Do not describe the function as fully schema-agnostic if it is schema-qualified to public.
Issue 4 — rollback includes Directus Flow / Operation DML too early
Current rollback artifact includes UPDATE/DELETE public.directus_flows/directus_operations.
But Directus scheduler binding is not approved yet.
Required fix:
Split rollback:
B3-F1c-b function rollback:
DROP ONLY public.fn_birth_onboarding_full_scan()
Future scheduler rollback:
remove only scheduler-created Directus Flow/Operation rows
only after scheduler path is designed/reviewed/executed
Current B3-F1c-b rollback must not include Directus Flow/Operation DML.
Issue 5 — Directus Flow scheduling path requires separate design
Agent correctly found Directus Flow as the only proven automatic scheduler path.
But Directus Flow path requires a Nuxt endpoint companion:
/api/birth/onboarding/full-scan
This endpoint is out-of-SQL and must be designed/reviewed before any scheduler binding.
Required split:
B3-F1c-b = install PG full-scan function only
B3-F1c-c or B3-F1d = design Nuxt endpoint + Directus Flow binding + cadence policy
Do not combine PG function install and Directus Flow scheduler binding.
Issue 6 — run-summary observability must be formally defined
Because system_health_checks is not a run-results table, function return JSONB is reasonable.
But automatic scheduler path must define where that returned summary is persisted/logged:
Directus Flow run log?
Nuxt endpoint application log?
system_issues summary issue?
approved run-history table?
Until durable observability is designed/reviewed, do not claim automatic coverage is complete.
6. Exact directive Opus must now execute
Opus should revise B3-F1c artifacts and split execution path.
Required deliverables
- Revised function artifact:
knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-full-scan-function.sql.md
- Revised rollback artifact for function-only B3-F1c-b:
knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-full-scan-rollback.sql.md
- Revised scheduler decision artifact:
knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-full-scan-scheduler.sql.md
- Revision directive report:
knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-revision-directive-report.md
Required final response fields from Opus
b3f1c_revision_status=PASS|PARTIAL|BLOCKED
function_artifact_status=REVISED|BLOCKED
comment_on_removed=true|false
dependency_failure_behavior_defined=true|false
schema_public_declared_deployment_target=true|false
rollback_function_only=true|false
scheduler_binding_split_to_future=true|false
b3f1c_b_execution_allowed=false_until_gpt_review
b3f1c_scheduler_binding_allowed=false
b3f_complete_allowed=false
phase5c2_migration_allowed=false
next_recommended_action=GPT_REVIEW_B3F1C_REVISED_ARTIFACTS
7. Current governance flags
b3a_status=COMPLETE
b3f0_status=PASS
b3f0a_policy_materialization=PASS
b3f1b_soft_gate=LIVE_PASS
b3f1c_a_probe=PARTIAL_ACCEPTED_AS_EVIDENCE
b3f1c_artifacts=BLOCKED_REVISION_REQUIRED
b3f1c_b_function_execution_allowed=false
b3f1c_scheduler_binding_allowed=false
b3f_complete_allowed=false
b3f2_hard_gate_allowed=false
phase5c2_migration_allowed=false
ui_cutover_allowed=false
external_tool_install_allowed=false
pg_cron_extension_install_allowed=false
8. Important process reminders for Opus
- If unsure about a live fact, ask GPT to dispatch Agent for a quick read-only probe instead of assuming.
- Do not assume
pg_cron, Directus schema, Nuxt endpoint, or scheduler details. - Do not embed sibling collection lists in runtime logic. Sibling scope must come from
dot_config. - Do not hardcode OIDs.
- Do not treat counts like 166, 159, 147, 18 as gates. They are evidence snapshots only.
- Keep B3-F1c-b narrow: PG function install only, after GPT reviews revised function artifact.
- Keep scheduler binding separate: Directus Flow + Nuxt endpoint + cadence policy need separate design/review.
- Do not declare B3-F complete until function + automatic scheduler + durable observability are executed/reviewed.
9. Suggested Opus response shape
Opus should produce a concise result like:
B3-F1c revision complete.
Artifacts updated:
1. artifacts/p3d-birth-system-b3f1c-full-scan-function.sql.md
2. artifacts/p3d-birth-system-b3f1c-full-scan-rollback.sql.md
3. artifacts/p3d-birth-system-b3f1c-full-scan-scheduler.sql.md
4. reports/p3d-birth-system-b3f1c-revision-directive-report.md
b3f1c_revision_status=PASS
function_artifact_status=REVISED
comment_on_removed=true
dependency_failure_behavior_defined=true
schema_public_declared_deployment_target=true
rollback_function_only=true
scheduler_binding_split_to_future=true
b3f1c_b_execution_allowed=false_until_gpt_review
b3f1c_scheduler_binding_allowed=false
b3f_complete_allowed=false
phase5c2_migration_allowed=false
next_recommended_action=GPT_REVIEW_B3F1C_REVISED_ARTIFACTS
10. One-line reminder
Continue P3D Birth System Completion at B3-F1c: B3-F1b soft gate is live; B3-F1c-a probe found Directus Flow as scheduler path but compiled artifacts are blocked. Revise function artifact, rollback, and scheduler split per GPT review before any execution.