P3D — B3-F1c-c-a Scheduler Shape Probe + Artifact Compile Prompt (DRAFT)

Date: 2026-05-13 Author: Opus (draft). Requires GPT review before Agent dispatch. Mode: READ-ONLY PROBE + COMPILE-ONLY. No mutation. No execution. Self-contained.

Mission

Probe existing Directus Flow scheduled job patterns, Nuxt API endpoint patterns, and system_issues shape. Then compile scheduler artifacts (Directus Flow seed, Nuxt endpoint code, dot_config policy, dot_tools registration). Store all artifacts in KB. Do NOT execute.

Hard boundaries

ALLOWED:
  READ-ONLY queries against PG catalog, directus_flows, directus_operations, dot_tools, dot_config, system_issues
  READ-ONLY filesystem reads of Nuxt API endpoint files
  KB artifact writes (upload_document)

FORBIDDEN:
  Any INSERT / UPDATE / DELETE on PG
  Any file creation/modification on VPS (Nuxt files, docker-compose, etc.)
  Any Directus Flow creation
  Any Directus Operation creation
  CREATE EXTENSION
  CREATE/ALTER/DROP FUNCTION
  Any scheduler binding
  Any function invocation (SELECT fn_birth_onboarding_full_scan())

Phase 0 — Environment

cd /opt/incomex
source .env

All PG queries via:

docker exec postgres psql -U directus -d directus

All file reads via standard filesystem access on VPS.

Phase 1 — Probe existing scheduled flow pattern

1-preflight. Verify Directus system tables exist and have required columns

-- Verify directus_flows exists and has expected columns
SELECT column_name, data_type
FROM information_schema.columns
WHERE table_schema = 'public'
  AND table_name = 'directus_flows'
ORDER BY ordinal_position;

-- Verify directus_operations exists and has expected columns
SELECT column_name, data_type
FROM information_schema.columns
WHERE table_schema = 'public'
  AND table_name = 'directus_operations'
ORDER BY ordinal_position;

Gate: Both tables must exist. Required columns (exact names, no equivalents):

directus_flows: id, name, trigger, status, options
directus_operations: id, key, type, options, flow

If any table is missing or any required column is absent → STOP. Set b3f1c_c_probe_status=BLOCKED, blocked_reason=BLOCKED_DIRECTUS_FLOW_SCHEMA_MISMATCH. Report which columns are missing and exit. Do not attempt to map alternative column names.

Only proceed to 1a–1c if preflight passes.

1a. Find the [DOT-REG] Count Refresh flow

SELECT id, name, trigger, status, options
FROM directus_flows
WHERE name LIKE '%Count Refresh%'
   OR name LIKE '%DOT-REG%'
ORDER BY name;

1b. Read its operations chain

SELECT o.id, o.key, o.type, o.options, o.position_x, o.position_y, o.flow
FROM directus_operations o
WHERE o.flow IN (
  SELECT id FROM directus_flows
  WHERE name LIKE '%Count Refresh%'
)
ORDER BY o.key;

Report: flow trigger type, cron expression, operation type (request?), HTTP URL, HTTP method, headers, body.

1c. Check other scheduled flows for consistency

SELECT f.name, f.trigger, f.status, f.options,
       o.key AS op_key, o.type AS op_type, o.options AS op_options
FROM directus_flows f
LEFT JOIN directus_operations o ON o.flow = f.id
WHERE f.trigger = 'schedule'
  AND f.status = 'active'
ORDER BY f.name, o.key;

Report: How many scheduled flows exist? Do they all use the same HTTP request pattern? What URLs do they target?

Phase 2 — Probe DOT governance for existing scheduled flows

2a. Verify dot_tools table exists and discover schema

-- Step 1: Check if dot_tools table exists
SELECT count(*) AS dot_tools_exists
FROM information_schema.tables
WHERE table_schema = 'public'
  AND table_name = 'dot_tools';

-- Step 2: If exists, discover full schema
SELECT column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_schema = 'public'
  AND table_name = 'dot_tools'
ORDER BY ordinal_position;

Gate: If dot_tools does not exist → set dot_governance_status=BLOCKED_FOR_DOT_GOVERNANCE_DECISION, report gap, skip to Phase 3. Do NOT let probe crash on a missing table.

2b. Query scheduled-flow-like rows using ONLY columns proven to exist

Using the column names discovered in 2a, construct a SELECT that includes ONLY verified columns. Do NOT use assumed column names like trigger_type, cron_schedule, script_path, executor_ref, classification unless they appear in the schema discovery result.

Look for rows that semantically match scheduled jobs (by name patterns, type columns, or any scheduling-related columns discovered).

-- Example pattern (adapt to actual discovered columns):
-- SELECT <discovered_columns> FROM dot_tools WHERE <discovered_column> LIKE '%schedule%' OR ...

If required semantics (tool name, scheduling type, classification) cannot be mapped to any discovered columns → set dot_governance_status=BLOCKED_FOR_DOT_GOVERNANCE_DECISION. Report which columns exist and which semantics cannot be mapped. Do NOT compile a dot_tools registration artifact that references non-existent columns.

Phase 3 — Probe Nuxt API endpoint patterns

3a. List existing API endpoints

find /opt/incomex/web/server/api/ -name '*.ts' -o -name '*.js' | head -30

3b. Read one example that calls PG or Directus

Look for any endpoint that:

Calls a PG function directly (e.g., pool.query, sql, usePostgres)
Or calls Directus SDK for data operations

Read the file content of 1-2 relevant examples.

Report: How does Nuxt connect to PG? Via Directus SDK? Via direct pg connection? What auth/middleware is used?

3c. Check FLOWS_ENV_ALLOW_LIST

grep -i 'FLOWS_ENV_ALLOW_LIST' /opt/incomex/docker-compose*.yml /opt/incomex/.env 2>/dev/null

Or:

docker exec directus env | grep FLOWS_ENV

Report: What env vars are available to Directus Flow operations?

Phase 4 — Probe system_issues shape for observability

SELECT column_name, data_type, is_nullable, column_default
FROM information_schema.columns
WHERE table_schema = 'public'
  AND table_name = 'system_issues'
ORDER BY ordinal_position;

Report: Does system_issues have a JSONB column for structured details? What columns are available for summary storage?

Phase 5 — Probe dot_config for existing birth scan policy keys

SELECT key, length(value) AS value_length
FROM dot_config
WHERE key LIKE 'policy.birth_full_scan%'
ORDER BY key;

Report: Do any birth full scan policy keys already exist?

Phase 6 — Compile artifacts

Based on probe results, compile the following artifacts. Use EXACT patterns discovered from probes — do not assume URL, auth, or column patterns.

6a. Nuxt API endpoint code

Compile TypeScript for /server/api/birth/onboarding/full-scan.post.ts (or .get.ts based on discovered pattern).

The endpoint must:

Check dot_config['policy.birth_full_scan.enabled'] — if not true, return 200 with {status: 'disabled'}.
Call SELECT public.fn_birth_onboarding_full_scan().
Parse JSONB result.
If status='complete' or status='dependency_fail', compile summary-write logic only if system_issues shape supports a safe structured or text summary pattern. Summary issue type/sub_class/status/severity/entity fields must be derived from live column shape and existing conventions; do not hardcode an unsupported issue schema.
Return JSONB to caller.

Use the EXACT PG connection pattern discovered in Phase 3. Do not assume.

Write to KB:

knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-c-nuxt-endpoint-code.md

6b. Directus Flow + Operation seed SQL

Compile INSERT statements for creating the scheduled flow + HTTP request operation.

Use the EXACT pattern discovered from [DOT-REG] Count Refresh (6h) — same column set, same operation type, same URL pattern.

CRITICAL: If probe Phases 1–1c cannot safely determine a generalizable Directus Flow + Operation pattern from existing live scheduled flows (e.g., all flows have unusual/non-standard structure, or no active scheduled flows exist):

Set directus_flow_seed_compiled=false
Set b3f1c_c_probe_status=PARTIAL or BLOCKED
Set reason=BLOCKED_PATTERN_UNDISCOVERABLE
Do NOT compile a Directus Flow seed from assumptions or documentation
Report the gap and let GPT decide next steps

Cron expression: do not treat 0 */6 * * * as truth. First probe existing policy.birth_full_scan.cadence_cron. If absent, compile 0 */6 * * * only as a proposed reviewed candidate in both dot_config policy seed and Directus Flow seed. Clearly mark it candidate_cadence, and require GPT/user approval before execution.

Write to KB:

knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-c-directus-flow-seed.sql.md

6c. dot_config policy seed

Compile INSERT statements for:

policy.birth_full_scan.enabled = true
policy.birth_full_scan.cadence_cron = CANDIDATE VALUE ONLY. First check probe Phase 5 results: if an existing policy.birth_full_scan.cadence_cron key already exists, use its value. If absent, propose 0 */6 * * * as candidate requiring GPT/user review. Mark candidate_cadence_requires_review=true in the artifact header and in the report. The Directus Flow seed (§6b) must derive its cron from the SAME reviewed candidate — no unsynchronized values.

Write to KB:

knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-c-dot-config-policy-seed.sql.md

6d. dot_tools registration (if applicable)

If dot_tools exists and its shape is sufficient, compile a proposed registration INSERT using discovered column semantics. Existing scheduled-flow registrations are a preferred precedent, but absence of precedent must not silently skip DOT governance. If dot_tools is missing or shape-insufficient, mark the result BLOCKED_FOR_DOT_GOVERNANCE_DECISION rather than compiling an ungoverned scheduler.

Write to KB (if applicable):

knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-c-dot-tools-registration.sql.md

6e. Rollback SQL

Compile rollback that removes ONLY B3-F1c-c artifacts:

DELETE Directus Flow + Operation
DELETE dot_config policy keys
DELETE dot_tools registration (if created)
Note: Nuxt endpoint file removal is manual (filesystem)
MUST NOT touch: fn_birth_onboarding_full_scan, B3-F1b gate/helper/trigger, dot_config sibling policy, system_issues data

Write to KB:

knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-c-scheduler-rollback.sql.md

Phase 7 — Report

Write probe + compile report to KB:

knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-c-scheduler-shape-probe-and-compile-report.md

Report must include:

All probe findings (Phases 1–5)
Compiled artifact list with paths
Any gaps or unresolved questions
Compliance with hard boundaries

Final response fields

b3f1c_c_probe_status=PASS|PARTIAL|BLOCKED
blocked_reason=<none|BLOCKED_PATTERN_UNDISCOVERABLE|BLOCKED_FOR_DOT_GOVERNANCE_DECISION|BLOCKED_FOR_OBSERVABILITY_DECISION|BLOCKED_NUXT_PATTERN_UNDISCOVERABLE|BLOCKED_SCHEMA_MISMATCH|BLOCKED_DIRECTUS_FLOW_SCHEMA_MISMATCH>
observability_status=PASS|PARTIAL|BLOCKED_FOR_OBSERVABILITY_DECISION
existing_scheduled_flow_pattern_discovered=true|false
dot_tools_governance_pattern_discovered=true|false
nuxt_api_endpoint_pattern_discovered=true|false
flows_env_allow_list_discovered=true|false
system_issues_shape_for_summary_discovered=true|false
nuxt_endpoint_code_compiled=true|false
directus_flow_seed_compiled=true|false
dot_config_policy_compiled=true|false
dot_tools_registration_compiled=true|false
dot_governance_status=PASS|BLOCKED_FOR_DOT_GOVERNANCE_DECISION
rollback_compiled=true|false
candidate_cadence=<value_or_none>
cadence_source=EXISTING_DOT_CONFIG|CANDIDATE_REQUIRES_REVIEW|BLOCKED
no_ddl_executed=true|false
no_dml_executed=true|false
no_file_created=true|false
report_uploaded=true|false
compiled_from_assumptions=false
next_recommended_action=GPT_REVIEW_B3F1C_C_COMPILED_ARTIFACTS

CRITICAL: If compiled_from_assumptions=true for ANY artifact, b3f1c_c_probe_status CANNOT be PASS. An artifact compiled from assumptions instead of live-discovered patterns must be marked PARTIAL or BLOCKED with explanation.

What this prompt does NOT do

Does NOT execute any compiled SQL
Does NOT create Directus Flow or Operation
Does NOT create Nuxt endpoint file
Does NOT modify any existing file
Does NOT call fn_birth_onboarding_full_scan()
Does NOT bind any scheduler
Does NOT touch B3-F1b or B3-A artifacts

B3-F1c-c-a Scheduler Shape Probe + Artifact Compile | DRAFT | 2026-05-13