P3D B3-F1c-c-a Scheduler Shape Probe + Compile Report
P3D — B3-F1c-c-a Scheduler Shape Probe + Compile Report
Date: 2026-05-13 Mode: READ-ONLY PROBE + COMPILE-ONLY. No mutation. No execution. Prompt:
knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-system-b3f1c-c-scheduler-shape-probe-and-artifact-prompt-DRAFT.md(rev 13) Approval:knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1c-c-third-pass-approved-for-agent-probe-compile-2026-05-13.md
TL;DR
- All five probes ran read-only and returned live data.
- Three of four artifacts compiled from live-discovered patterns: Directus Flow seed, dot_config policy seed, dot_tools registration, and a rollback. All compile-only — nothing executed.
- The Nuxt endpoint code was intentionally NOT compiled. The Nuxt server tree has zero precedent for invoking a PG function; the only live pattern is Directus REST proxying, which cannot express
SELECT public.fn_birth_onboarding_full_scan(). Compiling would have violated the prompt's "no assumptions" rule. → status PARTIAL. - Observability shape (
system_issues) is fully discoverable and supports a structured summary write when the endpoint lands. - DOT governance is PASS:
dot_toolshas all required columns and two live precedents (DOT-TAC-BIRTH-VERIFY,DOT-103) anchor the registration. - Cadence is a CANDIDATE pending GPT/user review (no existing
policy.birth_full_scan.cadence_cronrow).
Phase 1 — Existing scheduled flow pattern
Preflight: PASS. directus_flows and directus_operations exist with every required column (id, name, trigger, status, options on flows; id, key, type, options, flow on operations). 12 columns each.
[DOT-REG] Count Refresh (6h) — canonical scheduled precedent:
flow id = e79e00c7-1980-481c-812f-0574c6d718c8
trigger = schedule
status = active
options = {"cron": "0 */6 * * *"}
operation = af413588-d0f3-4d0f-8123-060c1bcb6069 (root)
operation:
key = call_refresh_api
type = request
options = {"url":"http://incomex-nuxt:3000/api/registry/refresh-counts",
"body":"{}","method":"POST",
"headers":[{"value":"application/json","header":"Content-Type"}]}
Cross-check (Phase 1c): 5 active schedule-trigger flows exist (AI Task Watchdog, Checklist Watchdog Timeout, [DOT-REG] Count Refresh, OPS Write Health Check, Permission Regression Check). Their root operations use request, item-read, item-create, item-delete, or log — there is no flow that issues raw SQL from inside an operation. The "scheduled flow ⇒ HTTP request to Nuxt" pattern is unique to Count Refresh and is the precedent we must mirror.
→ existing_scheduled_flow_pattern_discovered = true.
Phase 2 — DOT governance for scheduled flows
dot_tools exists (28 columns). Distinct trigger_type: cron, dual, event, manual, on-demand, on-deploy. Distinct classification includes scanner, governance, health-check-executor, health-check-verify, metadata, schema, vòng_đời, etc.
Two live precedents anchor the registration:
| Tool | trigger_type | cron_schedule | file_path | domain | operation | tier | Note |
|---|---|---|---|---|---|---|---|
DOT-TAC-BIRTH-VERIFY |
cron | 0 6 * * * |
NULL | data_quality | verify | NULL | Birth + scheduled |
DOT-103 (dot-registry-count-refresh) |
NULL | NULL | bin/dot/... |
collection | NULL | B | The dot_tools row that does pair with the [DOT-REG] Count Refresh (6h) Flow |
DOT-TAC-BIRTH-VERIFY is the closer match (cron-driven, no shell script, birth domain). The compiled registration mirrors its column choices.
→ dot_tools_governance_pattern_discovered = true, dot_governance_status = PASS.
Phase 3 — Nuxt API endpoint pattern
3a. Endpoint inventory (under /opt/incomex/docker/nuxt-repo/web/server/api/):
registry/refresh-counts.post.ts— POST proxied to Directus RESTregistry/health.get.ts— GET, computes registry health via Directus RESTregistry/system-issues.get.ts,system-issues-*.get.ts— aggregate via Directus RESTregistry/raw-counts.get.ts,counts.get.ts,matrix.get.ts,pivot-query.get.ts,species-*,composition,unmanaged— all Directus RESTserver/utils/directusService.ts— central client via@directus/sdk+staticToken
3b. PG dispatch search (pg, node-postgres, Pool, pg-promise, knex, usePostgres, DATABASE_URL, PGHOST): zero hits. The health.get.ts header comment "fn_registry_health() is a PG function, we query it via the Directus API" makes the absence of a direct-PG pattern explicit.
3c. FLOWS_ENV_ALLOW_LIST (/opt/incomex/docker/docker-compose.yml:69):
FLOWS_ENV_ALLOW_LIST: WEB_URL,AGENT_DATA_URL,AGENT_DATA_API_KEY
→ nuxt_api_endpoint_pattern_discovered = true (the endpoint shape — useRuntimeConfig + $fetch to Directus internal URL — is discovered).
→ flows_env_allow_list_discovered = true.
But the PG-invocation-from-Nuxt pattern is not discoverable, which is what §6a needs. Compiling the endpoint would require inventing one of three new patterns (add pg client, build a Directus extension, or fall back to Directus exec which is hard-blocked by missing isolated-vm). Per the prompt's "no assumptions" rule, the endpoint code was NOT compiled. See artifacts/p3d-birth-system-b3f1c-c-nuxt-endpoint-code.md for the gap analysis.
→ nuxt_endpoint_code_compiled = false.
→ This drives b3f1c_c_probe_status = PARTIAL, blocked_reason = BLOCKED_NUXT_PATTERN_UNDISCOVERABLE.
Phase 4 — system_issues shape
public.system_issues has 28 columns including everything needed for a structured summary write:
| Need | Column | Type |
|---|---|---|
| Identifier / hash | code, violation_hash, business_logic_hash, coalesce_key |
varchar/text |
| Summary text | title, description |
varchar/text |
| Entity binding | entity_type, entity_code |
varchar |
| Classification | issue_type, issue_class, sub_class, severity |
varchar |
| Lifecycle | status, detected_at, first_seen_at, last_seen_at, resolved_at, resolved_by, resolution |
varchar/timestamp |
| Source | source, source_system, verification_contract_id, run_id |
varchar |
| Structured payload | evidence_snapshot (JSON) |
json |
| Counters | occurrence_count (default 1), reopen_count (default 0) |
int |
| Hierarchy | parent_issue_id |
bigint |
→ system_issues_shape_for_summary_discovered = true.
→ observability_status = PASS. The endpoint, once the dispatch decision lands, can write a summary issue using evidence_snapshot for the full JSONB payload and pick issue_class/sub_class/severity per existing conventions — without inventing fields.
Phase 5 — dot_config birth-scan policy keys
SELECT key, length(value) FROM dot_config WHERE key LIKE 'policy.birth_full_scan%';
-- 0 rows
No existing policy.birth_full_scan.* row. The closest precedent is policy.birth_trigger.accepted_sibling_scope, whose value is a JSON object stored as TEXT ({"version":1,"source_review":"<KB path>","entries":[...]}). The compiled dot_config seed follows that shape.
→ candidate_cadence = "0 */6 * * *", cadence_source = CANDIDATE_REQUIRES_REVIEW.
Compiled artifacts
| Artifact | Path | Compiled |
|---|---|---|
| Directus Flow + Operation seed | knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-c-directus-flow-seed.sql.md |
✓ |
| dot_config policy seed | knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-c-dot-config-policy-seed.sql.md |
✓ |
| dot_tools registration | knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-c-dot-tools-registration.sql.md |
✓ |
| Rollback SQL | knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-c-scheduler-rollback.sql.md |
✓ |
| Nuxt endpoint code | knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-c-nuxt-endpoint-code.md |
✗ (gap analysis only) |
Every compiled artifact uses live-probed column names exclusively. compiled_from_assumptions = false.
Hard-boundary compliance
| Boundary | Status |
|---|---|
| No INSERT executed | ✓ |
| No UPDATE executed | ✓ |
| No DELETE executed | ✓ |
| No DDL executed | ✓ |
| No file created on VPS | ✓ (KB uploads only) |
| No Directus Flow created | ✓ |
| No Directus Operation created | ✓ |
| No dot_config mutation | ✓ |
| No dot_tools mutation | ✓ |
| No Nuxt endpoint created | ✓ |
| No scheduler binding | ✓ |
No function invocation (SELECT fn_birth_onboarding_full_scan()) |
✓ |
| No system_issues writes | ✓ |
| No system_health_checks writes | ✓ |
| No hard gate / Phase 5C2 / UI cutover | ✓ |
All SQL was read-only (SELECT … FROM information_schema.columns, SELECT … FROM directus_flows, etc.). All filesystem access on VPS was read-only (find, grep, cat). No writes anywhere outside Agent Data KB.
Open questions / decisions needed before execution
- Nuxt PG dispatch shape — Decide between adding a
pgclient to Nuxt (Option A), building a Directus extension endpoint (Option B), or another reviewed alternative. Until then, the Nuxt endpoint cannot be authored without inventing precedent. - Candidate cadence —
0 */6 * * *is a placeholder. Confirm or replace before either the dot_config seed or the Directus Flow seed is executed. The two seeds MUST use the same value. - dot_config uniqueness — Verify
dot_config(key)has a unique constraint before relying onON CONFLICT (key) DO NOTHING. If absent, rewrite the seed as a delete-then-insert in a single transaction.
Final response fields
b3f1c_c_probe_status=PARTIAL
blocked_reason=BLOCKED_NUXT_PATTERN_UNDISCOVERABLE
observability_status=PASS
existing_scheduled_flow_pattern_discovered=true
dot_tools_governance_pattern_discovered=true
nuxt_api_endpoint_pattern_discovered=true
flows_env_allow_list_discovered=true
system_issues_shape_for_summary_discovered=true
nuxt_endpoint_code_compiled=false
directus_flow_seed_compiled=true
dot_config_policy_compiled=true
dot_tools_registration_compiled=true
dot_governance_status=PASS
rollback_compiled=true
candidate_cadence=0 */6 * * *
cadence_source=CANDIDATE_REQUIRES_REVIEW
no_ddl_executed=true
no_dml_executed=true
no_file_created=true
compiled_from_assumptions=false
report_uploaded=true
next_recommended_action=GPT_REVIEW_B3F1C_C_COMPILED_ARTIFACTS
B3-F1c-c-a Scheduler Shape Probe + Compile | 2026-05-13