P3D — B3-F1c-c Nuxt Endpoint — NOT COMPILED

Date: 2026-05-13 Mode: COMPILE-ONLY. Endpoint code intentionally NOT compiled. Reason: BLOCKED_NUXT_PATTERN_UNDISCOVERABLE — no live precedent for invoking a PG function from a Nuxt server endpoint. compiled_from_assumptions: false (refused to compile from assumptions)

---

What was probed (Phase 3)

Scanned every file under /opt/incomex/docker/nuxt-repo/web/server/:

• find … -name "*.ts" -o -name "*.js"
• grep -rl -E "(pg|postgres|usePool|usePg|Pool\\(|new Pool|node-postgres|DATABASE_URL|PGHOST|pg-promise|knex)"
• grep -rl "executeSql|raw[(]|fn_|public\\.fn"
• grep -rln "fn_birth|fn_registry_health|birth_onboard"
• Read server/utils/directusService.ts, server/api/registry/refresh-counts.post.ts, server/api/registry/health.get.ts, server/api/registry/system-issues.get.ts, server/api/registry/raw-counts.get.ts

Discovered pattern

Every Nuxt server endpoint without exception uses:

1. useRuntimeConfig() to read directusInternalUrl + directusServiceToken.
2. $fetch (or @directus/sdk with staticToken) against the Directus REST API.
3. No direct PostgreSQL client (pg, node-postgres, pg-pool, pg-promise, knex, usePostgres, getPool) anywhere in the server tree.

The closest analog is server/api/registry/health.get.ts, whose own header comment makes the gap explicit:

"Since fn_registry_health() is a PG function, we query it via the Directus API"

…and then sidesteps the PG call entirely by reconstructing the metric from Directus collections + meta_catalog aggregates.

Why this matters

The B3-F1c-c-a prompt §6a requires the endpoint to call SELECT public.fn_birth_onboarding_full_scan(). That is a single PG function invocation that returns a JSONB blob; there is no equivalent surface on Directus REST. Three options exist, none of them with a live precedent:

Option	New pattern	Risk
(A) Add a pg Pool client to Nuxt and connect to postgres:5432	New dep + new DB credential surface	Auth + connection pooling unspecified
(B) Build a Directus Extension custom endpoint that proxies the fn call	Extension framework unused in this repo	Extension build/deploy pipeline untested
(C) Have the Directus Flow run an exec operation directly	Directus 11.5.1 lacks isolated-vm (per project memory) → unavailable	Hard-blocked

Per the prompt's hard rule "Do not compile from assumptions" and "Use the EXACT PG connection pattern discovered in Phase 3", I refuse to author endpoint code under any of the three options. A reviewed decision on which dispatch shape to adopt must precede compilation.

---

What CAN be safely stated about the endpoint shape

If/when option (A), (B), or a different dispatch is approved, the rest of the endpoint shape is unambiguous and derivable from the live refresh-counts.post.ts precedent:

// SHAPE ONLY — DISPATCH MECHANISM TO PG IS UNDECIDED.
// This is illustrative, NOT a compiled artifact.

export default defineEventHandler(async (event) => {
  const config = useRuntimeConfig();
  const directusUrl  = config.directusInternalUrl || config.public?.directusUrl;
  const serviceToken = config.directusServiceToken || process.env.NUXT_DIRECTUS_SERVICE_TOKEN;

  // 1. Read dot_config.policy.birth_full_scan.enabled via Directus REST.
  //    Matches the precedent of reading config via `/items/<collection>`.
  const cfg = await $fetch<any>(`${directusUrl}/items/dot_config`, {
    headers: { Authorization: `Bearer ${serviceToken}` },
    params: { 'filter[key][_eq]': 'policy.birth_full_scan.enabled', limit: 1 },
  });
  const enabled = JSON.parse(cfg?.data?.[0]?.value || '{}')?.value === true;
  if (!enabled) return { status: 'disabled' };

  // 2. <<< DISPATCH TO PG fn_birth_onboarding_full_scan() — PATTERN UNDISCOVERED >>>
  //    REQUIRES: GPT/user-approved dispatch shape (option A / B / other).

  // 3. Parse JSONB result.
  // 4. If status='complete'|'dependency_fail', write a summary row to public.system_issues
  //    using the live shape probed in Phase 4 (severity, issue_class, sub_class, evidence_snapshot,
  //    coalesce_key, source, source_system). NO field is hardcoded outside the live schema.
  // 5. Return the JSONB to the caller.
});

The fields available on system_issues for the summary write (Phase 4 probe) are documented in the consolidated report. They support the spec's "structured summary" requirement (evidence_snapshot is JSON; issue_class / sub_class are free-form varchar; coalesce_key exists for idempotency).

B3-F1c-c Scheduler Artifacts | NOT COMPILED — AWAITING DISPATCH DECISION | 2026-05-13