Incomex AI Portal
KB-D38C rev 2

P3D — B3-F1c-e dot-dot-health Reuse Viability Probe Prompt (DRAFT — Patched)

10 min read Revision 2
p3dbirth-systemb3f1c-edot-dot-healthreuseprobedraftpatched

P3D — B3-F1c-e dot-dot-health Reuse Viability Probe Prompt (DRAFT — Patched)

Date: 2026-05-13 Mode: READ-ONLY PROBE. No mutation. No execution. No function invocation. Patched: 8 items per GPT review (PG discovery, path variable, schema-first for all tables, grep-as-locator, jurisdiction mode, blocked reasons, assumption attestation)

Mission

Determine whether dot-dot-health v2.0.0 generic executor can dispatch fn_birth_onboarding_full_scan() via a single system_health_checks INSERT — avoiding new endpoints/flows/DOTs.

Hard boundaries

ALLOWED:
  Read dot-dot-health script source (read-only)
  Read-only PG SELECT (schema discovery, privilege checks, row queries)
  Read docker-compose / crontab / systemd (schedule discovery)
  KB writes (report only)

FORBIDDEN:
  Modify any file on VPS
  INSERT/UPDATE/DELETE any PG table
  Function invocation
  Scheduler/Flow/endpoint creation
  Secret exposure (REDACT all credentials)

Phase 0 — Discover execution context + paths

# 0a. Execution context
hostname

# 0b. Discover dot-dot-health script path
# Candidate: /opt/incomex/dot/bin/dot-dot-health — confirm existence
test -f /opt/incomex/dot/bin/dot-dot-health && echo "CANDIDATE_CONFIRMED" || echo "CANDIDATE_NOT_FOUND"
# If not found, search:
find /opt/incomex -name 'dot-dot-health' -type f 2>/dev/null
# If multiple candidates found → BLOCKED_MULTIPLE_DOT_DOT_HEALTH_CANDIDATES
# Assign discovered path as DOT_HEALTH_PATH for all subsequent phases

# 0c. Discover PG access path
# Try known container name, confirm with SELECT 1
docker exec postgres psql -U directus -d directus -c "SELECT 1" 2>/dev/null && echo "PG_ACCESS_OK" || echo "PG_ACCESS_FAIL"
# If fail, discover PG container:
docker ps --filter "ancestor=postgres" --format "{{.Names}}" 2>/dev/null
# Assign discovered PG access as PG_CMD for all subsequent phases
# If no PG access → BLOCKED_PG_ACCESS_UNDISCOVERABLE

# 0d. If running locally (not on VPS), use approved remote execution context
# Do not hardcode SSH aliases

Gate 0: All must succeed: dot-dot-health path confirmed (single candidate), PG access confirmed.

Final fields from Phase 0:
dot_dot_health_path_discovered=true|false
pg_access_discovered=true|false

Phase 1 — dot-dot-health function executor implementation

Do NOT rely on grep alone. Grep is a LOCATOR — Agent must read sufficient script context to understand the dispatch logic.

# Step 1: Locate dispatch block
grep -n 'function\|dispatch\|executor\|case' $DOT_HEALTH_PATH | head -30

# Step 2: Read the actual dispatch block (enough lines for full context)
# Use sed/awk with discovered line numbers to extract the function dispatch section
# Example: sed -n '<start_line>,<end_line>p' $DOT_HEALTH_PATH

# Step 3: Find PG helper used for function dispatch
grep -n 'run_pg_rw\|run_pg_ro\|psql\|read_only\|SET TRANSACTION' $DOT_HEALTH_PATH

Report MUST include:

  • Actual code snippet of the function dispatch block (sufficient lines)
  • Exact call signature: how is executor_ref resolved? What args? What return type expected?
  • Which PG helper is used: run_pg_rw (can write) or run_pg_ro_db (read-only)?
  • How pass/fail is evaluated from function return

Phase 2 — Schema discovery for ALL tables (before ANY row queries)

2a. system_health_checks schema

-- Verify table exists
SELECT count(*) FROM information_schema.tables WHERE table_schema='public' AND table_name='system_health_checks';

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

If table missing or columns insufficient → BLOCKED_SYSTEM_HEALTH_CHECKS_SCHEMA_UNMAPPED.

2b. dot_tools schema

SELECT count(*) FROM information_schema.tables WHERE table_schema='public' AND table_name='dot_tools';

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

Use CONFIRMED column names only in subsequent queries. Do NOT assume tool_name exists — use code or name if those are the actual columns.

If table missing or semantics unmappable → BLOCKED_DOT_TOOLS_SCHEMA_UNMAPPED.

2c. directus_flows schema (if needed for scheduling probe)

SELECT count(*) FROM information_schema.tables WHERE table_schema='public' AND table_name='directus_flows';

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

If needed but missing/mismatch → BLOCKED_DIRECTUS_FLOW_SCHEMA_MISMATCH.

Phase 3 — Existing function-type checks (using confirmed columns)

-- Use CONFIRMED column names from Phase 2a
SELECT <confirmed_code_col>, <confirmed_name_col>, <confirmed_executor_type_col>,
       <confirmed_executor_ref_col>, <confirmed_threshold_config_col>,
       <confirmed_severity_col>, <confirmed_is_active_col>, <confirmed_jurisdiction_col>
FROM system_health_checks
WHERE <confirmed_executor_type_col> = 'function'
ORDER BY <confirmed_code_col>;

Report: count, executor_ref patterns, active checks, jurisdictions used.

Phase 4 — Scheduling discovery

# Crontab
crontab -l 2>/dev/null | grep -i 'dot-dot-health\|dot_health\|dot-health'

# Systemd timers
systemctl list-timers 2>/dev/null | grep -i 'dot\|health'

# Directus Flows (using confirmed columns from Phase 2c)
$PG_CMD -c "SELECT <confirmed_name_col>, <confirmed_trigger_col>, <confirmed_status_col>, <confirmed_options_col>
FROM directus_flows
WHERE <confirmed_name_col> ILIKE '%health%' OR <confirmed_name_col> ILIKE '%dot-dot%'
ORDER BY <confirmed_name_col>"

# dot_tools (using confirmed columns from Phase 2b)
$PG_CMD -c "SELECT <confirmed_columns>
FROM dot_tools
WHERE <confirmed_name_or_code_col> ILIKE '%dot-health%' OR <confirmed_name_or_code_col> ILIKE '%dot-dot%'
ORDER BY <confirmed_name_or_code_col>"

Report: scheduled mechanism (CRON/DIRECTUS_FLOW/SYSTEMD/MANUAL/UNKNOWN), cadence if discoverable.

Phase 5 — Jurisdiction handling

# Read script to determine jurisdiction mode (NOT grep alone — read context)
grep -n 'jurisdiction\|NRM-LAW\|getopts\|\$1\|\$2\|--jurisdiction\|JURISDICTION' $DOT_HEALTH_PATH | head -20

# Then read sufficient context around the jurisdiction assignment

Determine and report:

jurisdiction_mode=HARDCODED|CLI_ARG|ENV_VAR|DB_DRIVEN|UNKNOWN
  • HARDCODED: jurisdiction is a literal string in the script
  • CLI_ARG: script accepts jurisdiction as command-line argument
  • ENV_VAR: jurisdiction read from environment variable
  • DB_DRIVEN: jurisdiction determined from database at runtime
  • UNKNOWN: cannot determine

Phase 6 — Overlap scan (using confirmed columns)

-- Birth/onboarding related tools (use confirmed dot_tools columns)
SELECT <confirmed_columns> FROM dot_tools
WHERE <text_columns> ILIKE '%birth%' OR <text_columns> ILIKE '%onboard%' OR <text_columns> ILIKE '%full.scan%'
ORDER BY <confirmed_pk>;

-- Birth/onboarding health checks (use confirmed system_health_checks columns)
SELECT <confirmed_columns> FROM system_health_checks
WHERE <text_columns> ILIKE '%birth%' OR <text_columns> ILIKE '%onboard%' OR <text_columns> ILIKE '%birth_onboarding%'
ORDER BY <confirmed_pk>;

Report: any overlap found? Describe.

Phase 7 — Signature compatibility analysis

Based on Phase 1 actual dispatch code, assess:

Aspect Executor expects Our function Compatible?
Args ? (from Phase 1) zero args ?
Return type ? (from Phase 1) jsonb ?
Pass/fail eval ? (from Phase 1) JSONB with critical_count ?
PG mode ? (RW/RO from Phase 1) needs RW (writes system_issues) ?

If wrapper needed: describe what signature would match (do NOT compile).

Phase 8 — Viability decision

Return ONE of:

REUSE_DOT_DOT_HEALTH_INSERT_ROW
REUSE_WITH_WRAPPER_FUNCTION
EXTEND_DOT_DOT_HEALTH_EXECUTOR
DOT_DOT_HEALTH_NOT_VIABLE_CONTINUE_AGENT_DATA_BRIDGE
BLOCKED_NEEDS_DESIGN

Report path

knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-e-dot-dot-health-reuse-viability-probe-report.md

Final fields

b3f1c_e_probe_status=PASS|PARTIAL|BLOCKED
blocked_reason=<none|BLOCKED_PG_ACCESS_UNDISCOVERABLE|BLOCKED_MULTIPLE_DOT_DOT_HEALTH_CANDIDATES|BLOCKED_DOT_TOOLS_SCHEMA_UNMAPPED|BLOCKED_SYSTEM_HEALTH_CHECKS_SCHEMA_UNMAPPED|BLOCKED_DIRECTUS_FLOW_SCHEMA_MISMATCH|BLOCKED_NEEDS_DESIGN>
dot_dot_health_path_discovered=true|false
pg_access_discovered=true|false
dot_tools_schema_mapped=true|false
system_health_checks_schema_mapped=true|false
directus_flows_schema_mapped=true|false
function_executor_signature=<exact_signature_discovered>
function_executor_rw_or_ro=RW|RO|UNKNOWN
function_type_checks_count=<number>
dot_dot_health_scheduled=true|false
dot_dot_health_schedule_mechanism=CRON|DIRECTUS_FLOW|SYSTEMD|MANUAL|UNKNOWN
jurisdiction_mode=HARDCODED|CLI_ARG|ENV_VAR|DB_DRIVEN|UNKNOWN
overlap_found=true|false
signature_compatible=true|false
wrapper_needed=true|false
viability_decision=REUSE_DOT_DOT_HEALTH_INSERT_ROW|REUSE_WITH_WRAPPER_FUNCTION|EXTEND_DOT_DOT_HEALTH_EXECUTOR|DOT_DOT_HEALTH_NOT_VIABLE_CONTINUE_AGENT_DATA_BRIDGE|BLOCKED_NEEDS_DESIGN
secrets_redacted=true
compiled_from_assumptions=false
no_mutation_performed=true
next_recommended_action=GPT_REVIEW_B3F1C_E_PROBE_RESULTS

B3-F1c-e dot-dot-health Reuse Viability Probe | DRAFT | Patched | 2026-05-13

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-system-b3f1c-e-dot-dot-health-reuse-viability-probe-prompt-DRAFT.md