GPT Review — B3-F1c-d dot-dot-health Discovery — Pause Agent Data Bridge — 2026-05-13

Trigger

User asked whether the proposed new DOT/dispatch bridge might duplicate an existing DOT/hệ thống under Điều 43 / DOT governance. Opus then found dot-dot-health generic executor.

Evidence reviewed

• knowledge/current-state/reports/s178-fix25-dot-health-refactor
• knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1c-d-dot-overlap-check-preliminary-2026-05-13.md
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-full-scan-shape-probe-and-compile-report.md
• knowledge/dev/laws/dieu44-trien-khai/artifacts/p3d-birth-system-b3f1c-c-dot-tools-registration.sql.md

Finding

dot-dot-health is an existing generic, table-driven health-check executor created in S178 Fix25. It reads checks from system_health_checks and dispatches by executor_type including:

builtin
sql
function

Key design facts from S178 Fix25:

• The goal was to remove hardcoded inline checks.
• Adding a new check should be INSERT 1 row, not code change.
• system_health_checks is the definition registry.
• dot-dot-health uses shared env SSOT, PG RW/RO helpers, KB fetch, and generic dispatch.
• Dry-run passed for 15/15 checks.

Implication for B3-F1c

The previous B3-F1c-c/B3-F1c-d direction attempted to create a new scheduler/dispatch bridge:

Directus Flow → Nuxt / Agent Data endpoint → public.fn_birth_onboarding_full_scan()

This may be unnecessary or duplicative if dot-dot-health can already dispatch PG functions from system_health_checks under existing DOT governance.

Therefore, the Agent Data bridge direction must be paused before any Agent dispatch or new DOT creation.

Accepted Opus insight

Opus correctly identified that the simpler and more constitutional path may be:

Add one system_health_checks row for B3-F1c full scan
→ dot-dot-health discovers it
→ existing DOT health infrastructure runs it

This better matches:

• no duplicate DOT;
• PG/DOT registry driven;
• self-expanding infrastructure;
• no new Directus Flow unless needed;
• no new Nuxt or Agent Data endpoint unless needed.

Blocking technical questions before redesign

Three questions must be probed live before choosing this path:

Q1 — Function signature compatibility

S178 Fix25 states function dispatch calls:

fn(cfg::jsonb)::text

But current B3-F1c function is:

public.fn_birth_onboarding_full_scan() returns jsonb

Need to inspect current /opt/incomex/dot/bin/dot-dot-health code to verify exact function dispatch behavior.

Possible outcomes:

• Executor supports zero-arg/jsonb functions already.
• Need a wrapper function such as fn_birth_onboarding_full_scan_hc(cfg jsonb) returns text/jsonb.
• Need to extend dot-dot-health executor, which requires separate design/review.

Q2 — RW/RO execution path

fn_birth_onboarding_full_scan() may write system_issues through the helper path. Need to verify whether executor_type='function' uses RW or RO connection/transaction.

Possible outcomes:

• Uses RW: viable.
• Uses RO/read-only transaction: current function cannot run there without changes.
• Function writes only under certain conditions: must be understood.

Q3 — Scheduling of dot-dot-health

Need to verify whether dot-dot-health itself is automatically scheduled today:

• host cron;
• Directus Flow;
• other DOT runner;
• manual only.

If not scheduled, then B3-F still needs scheduler design, but likely for dot-dot-health runner rather than a new B3-F-specific flow.

Required next step

Do not continue B3-F1c-d Agent Data bridge design until a read-only dot-dot-health viability probe is complete.

Opus should draft a read-only probe prompt:

B3-F1c-e dot-dot-health Reuse Viability Probe

The probe must:

1. Inspect current /opt/incomex/dot/bin/dot-dot-health source read-only.
2. Inspect live system_health_checks rows, especially any executor_type='function' rows.
3. Inspect exact function dispatch implementation.
4. Verify RW/RO path used by function executor.
5. Verify current scheduling mechanism for dot-dot-health.
6. Verify dot-dot-health jurisdiction handling: can it run checks outside NRM-LAW-35-V5P2, or is jurisdiction fixed?
7. Check overlap with existing DOT rows/health checks related to birth/full-scan/registry/onboarding.
8. Return a recommendation:
   • 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

Governance status

b3f1c_d_agent_data_bridge_status=PAUSED_PENDING_DOT_DOT_HEALTH_PROBE
dot_dot_health_reuse_candidate=true
new_dot_creation_allowed=false
directus_flow_creation_allowed=false
agent_data_endpoint_creation_allowed=false
scheduler_execution_allowed=false
b3f_complete_allowed=false
phase5c2_migration_allowed=false
next_recommended_action=OPUS_DRAFT_B3F1C_E_DOT_DOT_HEALTH_REUSE_VIABILITY_PROBE