P3D — B3-F1c-e dot-dot-health Reuse Viability Probe Report

Date: 2026-05-13 Author: Opus (Agent read-only probe) Mode: READ-ONLY PROBE — no mutation, no execution, no function invocation Prompt: knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-system-b3f1c-e-dot-dot-health-reuse-viability-probe-prompt-DRAFT.md rev 2 GPT approval: knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1c-e-dot-dot-health-probe-prompt-approved-2026-05-13.md

---

Executive summary

Viability: REUSE_WITH_WRAPPER_FUNCTION.

The generic dispatch_function path in dot-dot-health v2.0.0 cannot directly call public.fn_birth_onboarding_full_scan() because of a signature mismatch (executor expects (jsonb) → boolean; our function is () → jsonb). However the entire dispatch + scheduling + jurisdiction + logging chain is otherwise intact and reusable: a thin SQL wrapper function fn_xxx(p_cfg jsonb) RETURNS boolean that internally calls fn_birth_onboarding_full_scan() and folds the JSONB result down to pass/fail will satisfy the executor contract, after which a single row in system_health_checks (executor_type='function', jurisdiction='NRM-LAW-35-V5P2') wires the check in.

No new Agent Data endpoint, Directus Flow, or DOT is required. system_health_checks is the right surface, but the wrapper is unavoidable because of the contract gap; an alternative EXTEND_DOT_DOT_HEALTH_EXECUTOR (e.g. accept jsonb-returning functions and evaluate critical_count) would avoid the wrapper but requires editing the script and is broader-blast-radius than the wrapper.

This probe performed no INSERT/UPDATE/DELETE, no DDL, no file write, and did not invoke fn_birth_onboarding_full_scan() or any other function.

---

Phase 0 — Execution context + paths

Item	Result
Hostname	vmi3080463 (VPS)
dot-dot-health path	/opt/incomex/dot/bin/dot-dot-health (single candidate, 555 lines)
PG access	docker exec postgres psql -U directus -d directus (SELECT 1 → 1)

dot_dot_health_path_discovered = true pg_access_discovered = true

---

Phase 1 — dot-dot-health function executor (actual code)

Located in /opt/incomex/dot/bin/dot-dot-health lines 382–404:

dispatch_function() {
  local executor_ref="$1"
  local cfg="$2"
  local exists
  exists="$(run_pg_rw "SELECT 1 FROM pg_proc p JOIN pg_namespace n ON p.pronamespace=n.oid WHERE p.proname='${executor_ref}' AND n.nspname='public' LIMIT 1")"
  if [[ "$exists" != "1" ]]; then
    echo "function '${executor_ref}' không tồn tại (pg_proc)"
    return 1
  fi
  local cfg_sql="${cfg//\'/\'\'}"
  local result
  result="$(run_pg_rw "SELECT ${executor_ref}('${cfg_sql}'::jsonb)::text")"
  if [[ "$result" == "t" || "$result" == "true" ]]; then
    echo "${executor_ref}(${cfg}) -> TRUE"
    return 0
  fi
  if [[ "$result" == "f" || "$result" == "false" ]]; then
    echo "${executor_ref}(${cfg}) -> FALSE"
    return 1
  fi
  echo "${executor_ref}(${cfg}) non-boolean: '${result}'"
  return 1
}

PG helpers (lines 102–115):

run_pg_rw() {
  PGPASSWORD="$PG_PASSWORD_RW" ... psql ... -U "$PG_USER_RW" -d "$PG_DB_MAIN" -tAXq -v ON_ERROR_STOP=1 <<< "$1"
}

run_pg_ro_db() {
  ... PGOPTIONS='-c default_transaction_read_only=on -c statement_timeout=30s' ...
}

Main loop (lines 473–476):

case "$etype" in
  builtin)  summary="$(dispatch_builtin  "$eref" "$tcfg")" ; rc=$? ;;
  sql)      summary="$(dispatch_sql      "$eref" "$tcfg")" ; rc=$? ;;
  function) summary="$(dispatch_function "$eref" "$tcfg")" ; rc=$? ;;

Aspect	Value
Call signature	SELECT <executor_ref>('<threshold_config>'::jsonb)::text
Required function signature	(jsonb) RETURNS boolean (or anything castable to 't'/'f'/'true'/'false')
PG helper used	run_pg_rw (RW role + default RW tx)
PG mode	RW — function may perform writes
Pass/fail eval	text result must equal t / true to pass; f / false to fail; anything else is reported "non-boolean" and treated as fail (rc=1)
Existence check	Pre-flight pg_proc lookup for public.<executor_ref>

function_executor_signature = (jsonb) RETURNS boolean (text-cast equality with 't'/'true'/'f'/'false') function_executor_rw_or_ro = RW

---

Phase 2 — Schema discovery (3 tables)

2a. public.system_health_checks (13 columns)

column	type	nullable
code	text	NO
name	text	NO
jurisdiction	text	NO
check_kind	text	NO
executor_type	text	NO
executor_ref	text	NO
threshold_config	jsonb	NO
severity_on_fail	text	NO
auto_fix_action	text	YES
is_active	boolean	NO
order_index	integer	NO
description	text	YES
_dot_origin	text	NO

system_health_checks_schema_mapped = true

2b. public.dot_tools (28 columns — relevant subset)

id, status, sort, user_created, date_created, user_updated, date_updated, code, name, name_en, description, classification, owner, script_path, token_type, category, usage_count, _dot_origin, tier, domain, operation, paired_dot, trigger_type, cron_schedule, file_path, last_executed, coverage_status, extra_metadata

dot_tools_schema_mapped = true

2c. public.directus_flows (12 columns)

id, name, icon, color, description, status, trigger, accountability, options, operation, date_created, user_created

directus_flows_schema_mapped = true

---

Phase 3 — Function-type checks (using confirmed columns)

SELECT code, name, executor_type, executor_ref, severity_on_fail, is_active, jurisdiction
FROM system_health_checks
WHERE executor_type = 'function';

Result: 0 rows.

Aggregate: 30 total checks, 29 active. All currently builtin or sql — the function executor branch is implemented but unused. We would be the first consumer.

function_type_checks_count = 0

---

Phase 4 — Scheduling discovery

Crontab (root)

0 3 * * * . /opt/incomex/scripts/cron-env.sh && export DIRECTUS_ADMIN_EMAIL DIRECTUS_ADMIN_PASSWORD \
        && /opt/incomex/dot/bin/dot-dot-health --local >> /var/log/incomex/dot-health.log 2>&1

• Cadence: daily at 03:00 (VPS local time).
• Anomaly (not blocking, but noted): crontab passes --local, which is not a recognized argument in current parse_args (only --help, --dry-run, --verbose, --only-check). With set -e semantics elsewhere the script would exit 2 USAGE. Worth a separate investigation (out-of-scope for this probe).

Systemd timers / /etc/cron.d

No dot/health matches in systemctl list-timers or /etc/cron.d/* (no override).

directus_flows (health-related)

name	trigger	status
[DOT] Agent Data Health Check	webhook	active
OPS Write Health Check	schedule	active

Neither targets dot-dot-health directly.

dot_tools registry entry

code	name	trigger_type	cron_schedule	file_path
DOT-HEALTH-DOT	dot-dot-health	cron	(empty)	bin/dot/dot-dot-health.ts

• dot_tools.file_path shows bin/dot/dot-dot-health.ts but the on-disk executable is a Bash script at /opt/incomex/dot/bin/dot-dot-health (no .ts). Registry drift — noted, out-of-scope.
• cron_schedule is empty in dot_tools even though the actual crontab schedule exists.

dot_dot_health_scheduled = true dot_dot_health_schedule_mechanism = CRON

---

Phase 5 — Jurisdiction handling

dot-dot-health line 35:

JURISDICTION="NRM-LAW-35-V5P2"
readonly JURISDICTION

parse_args (lines 165–183) only accepts --help/-h, --dry-run, --verbose, --only-check[=]. No --jurisdiction flag. No env-var override. Precheck (line 196) hard-fails if ${JURISDICTION} is not present in normative_registry.

Implication: any new health check row must be inserted with jurisdiction = 'NRM-LAW-35-V5P2' to be picked up.

jurisdiction_mode = HARDCODED

---

Phase 6 — Overlap scan

dot_tools matches

code	name
DOT-118	dot-birth-backfill
DOT-119	dot-birth-trigger-setup
DOT-133	dot-schema-birth-registry-ensure
DOT_BIRTH_BACKFILL	dot-birth-backfill
DOT_BIRTH_TRIGGER_SETUP	dot-birth-trigger-setup
DOT_SCHEMA_BIRTH_REGISTRY_ENSURE	dot-schema-birth-registry-ensure
DOT-TAC-BIRTH-GATE	TAC Birth Gate (event)
DOT-TAC-BIRTH-VERIFY	TAC Birth Verify (cron)

None dispatch fn_birth_onboarding_full_scan() — all are setup/backfill/gate tooling. Onboarding-full-scan dispatch is not covered by an existing DOT.

system_health_checks matches

0 rows matched %birth%, %onboard%, or %birth_onboarding%.

overlap_found = false (no pre-existing dispatch row or DOT to collide with).

---

Phase 7 — Signature compatibility

fn_birth_onboarding_full_scan confirmed via pg_proc:

SELECT pg_get_function_arguments(p.oid), pg_get_function_result(p.oid)
FROM pg_proc p JOIN pg_namespace n ON p.pronamespace=n.oid
WHERE n.nspname='public' AND p.proname='fn_birth_onboarding_full_scan';
-- args=<empty>  rettype=jsonb

Aspect	Executor expects	fn_birth_onboarding_full_scan	Compatible?
Args	exactly one jsonb (passed as '…'::jsonb)	zero args	No
Return type	text-cast equality with t/true/f/false (effectively boolean)	jsonb	No
Pass/fail eval	boolean::text	JSONB with critical_count (per design)	No (needs folding)
PG mode	RW (run_pg_rw)	RW (writes system_issues per design)	Yes
Jurisdiction	hardcoded NRM-LAW-35-V5P2	function is jurisdiction-agnostic	Yes (set the row's jurisdiction accordingly)
Existence check	pg_proc.proname = '<executor_ref>' in public	exists in public	Yes

signature_compatible = false wrapper_needed = true

Wrapper sketch (description only — NOT compiled, NOT created)

A wrapper would need:

-- DESCRIPTIVE SKETCH ONLY — NOT EXECUTED
public.fn_birth_onboarding_health_check(p_cfg jsonb) RETURNS boolean
  body: SELECT (public.fn_birth_onboarding_full_scan() -> 'critical_count')::int = 0

…with p_cfg accepted but ignored (or used for a threshold override). Exact wrapper design / threshold semantics deferred to subsequent design phase.

---

Phase 8 — Viability decision

viability_decision = REUSE_WITH_WRAPPER_FUNCTION

Rationale:

• REUSE_DOT_DOT_HEALTH_INSERT_ROW (pure-INSERT, no code change): blocked by (jsonb) RETURNS boolean contract gap.
• REUSE_WITH_WRAPPER_FUNCTION (this report's recommendation): one wrapper SQL function + one system_health_checks INSERT. Smallest change. Reuses dispatch, scheduling (existing 03:00 cron), jurisdiction precheck, logging (fn_log_issue), severity/threshold semantics.
• EXTEND_DOT_DOT_HEALTH_EXECUTOR (script edit to accept jsonb-returning fns + evaluate critical_count): viable but broader blast radius (script change touches all health checks).
• DOT_DOT_HEALTH_NOT_VIABLE_CONTINUE_AGENT_DATA_BRIDGE: not justified — only the contract gap is in the way, and it is closable by a wrapper.

---

Anomalies observed (out-of-scope, recorded for follow-up)

1. Cron uses --local, a flag parse_args does not accept (current rev). Likely vestigial; investigate separately.
2. dot_tools.DOT-HEALTH-DOT.file_path = bin/dot/dot-dot-health.ts but on-disk file is bin/dot-dot-health (Bash, no .ts). Registry drift.
3. dot_tools.DOT-HEALTH-DOT.cron_schedule is empty despite a daily crontab being installed.
4. Two DOT_BIRTH_* code namespaces co-exist in dot_tools (uppercase-underscore + DOT-NNN variants) — likely legacy duplication.

None of these block reuse; documenting for hygiene.

---

Hard-boundary attestation

Boundary	Adhered?
No INSERT / UPDATE / DELETE	✔
No DDL	✔
No file modification	✔
No function invocation	✔ — fn_birth_onboarding_full_scan() was NOT called; only pg_get_function_arguments/pg_get_function_result were queried
No wrapper compilation	✔ — wrapper is a textual sketch only
No scheduler creation	✔
No Directus Flow creation	✔
No Agent Data endpoint creation	✔
No system_health_checks mutation	✔
No dot_tools mutation	✔
No B3-F completion declaration	✔
No Phase 5C2 work	✔
Secrets redacted	✔ — no credentials reproduced (PG_PASSWORD_*, DIRECTUS_ADMIN_PASSWORD referenced only by variable name)

---

Final fields

b3f1c_e_probe_status=PASS
blocked_reason=none
dot_dot_health_path_discovered=true
pg_access_discovered=true
dot_tools_schema_mapped=true
system_health_checks_schema_mapped=true
directus_flows_schema_mapped=true
function_executor_signature=public.<executor_ref>(jsonb) RETURNS boolean (text-cast equality with 't'/'true'/'f'/'false')
function_executor_rw_or_ro=RW
function_type_checks_count=0
dot_dot_health_scheduled=true
dot_dot_health_schedule_mechanism=CRON
jurisdiction_mode=HARDCODED
overlap_found=false
signature_compatible=false
wrapper_needed=true
viability_decision=REUSE_WITH_WRAPPER_FUNCTION
secrets_redacted=true
compiled_from_assumptions=false
no_mutation_performed=true
report_uploaded=true
next_recommended_action=GPT_REVIEW_B3F1C_E_PROBE_RESULTS

B3-F1c-e dot-dot-health Reuse Viability Probe Report | 2026-05-13 | READ-ONLY