P3D — B3-F1c Scheduler Decision Document Rev2

Mode: DECISION DOCUMENT. No executable SQL. Rev: 2 Date: 2026-05-13 Revision trigger: GPT review Issue 5 — scheduler path requires separate design, not executable artifact bundled with function install. Issue 6 — observability must be formally defined.

Status

scheduler_binding_approved = false
scheduler_design_complete = false
scheduler_execution_allowed = false

This document records the scheduling decision and defers design/execution to a future phase (B3-F1c-c or B3-F1d).

Scheduling path decision

Eliminated paths

Path	Status	Reason
pg_cron	CLOSED	Extension not installed, not available in pg_available_extensions
Manual-only	INSUFFICIENT	Does not meet "hạ tầng tự mở rộng" requirement

Selected path: Directus Flow + Nuxt endpoint

Evidence from probe (B3-F1c-a):

• directus_flows_scheduler_exists=true — 5+ active scheduled flows already running in production.
• Live pattern: Directus Flow (schedule trigger, e.g. every 6h) → chained HTTP Request operation → Nuxt API endpoint → PG function call.
• Examples: DOT-REG Count Refresh, Health Check, Permission Regression — all use this pattern.

Required components (NOT yet designed):

1. Nuxt API endpoint (/api/birth/onboarding/full-scan or similar):

   • Calls SELECT fn_birth_onboarding_full_scan() via PG connection.
   • Receives JSONB return value.
   • Persists/logs the result (see observability below).
   • Returns HTTP response to Directus Flow.

2. Directus Flow (schedule trigger):

   • Trigger type: schedule
   • Cadence: TBD (proposed: every 6h, or daily, or configurable via dot_config).
   • Chained operation: HTTP Request to Nuxt endpoint.

3. Cadence policy:

   • Should be configurable (e.g. dot_config['policy.birth_full_scan.cadence']).
   • Or hardcoded in Directus Flow schedule field (simpler, less flexible).

Observability design requirement (Issue 6)

Function returns JSONB summary. Per-gap details go to system_issues via helper. But for automatic scheduling, the returned summary must be durably persisted somewhere. Options:

Option	Pros	Cons
Nuxt endpoint application log	Simple, no new table	Log rotation, not queryable
Directus Flow run log	Built-in, timestamped	May not preserve JSONB detail
Dedicated system_scan_runs table	Queryable, durable, structured	New table = new registry entry, more governance
system_issues summary issue	Reuses existing infra, dedup via helper	Mixes scan-run summary with individual gaps

Decision required from GPT: Which observability path? Recommendation: dedicated table or system_issues summary issue (both are PG-native, queryable).

Sequence

B3-F1c-b: CREATE FUNCTION fn_birth_onboarding_full_scan() — PG DDL only (current phase)
B3-F1c-c: Design Nuxt endpoint + Directus Flow binding + cadence policy + observability
B3-F1c-d: Execute scheduler binding after design review
After all: B3-F = COMPLETE (function + automatic scheduler + durable observability)

Interim capability

While scheduler is not yet bound, the function can be called manually:

SELECT fn_birth_onboarding_full_scan();

This provides on-demand scanning capability. Not 100% automatic, but the function exists, is tested, and produces correct results.

B3-F1c Scheduler Decision Document Rev2 | 2026-05-13