GPT Review — B3-F1c-e dot-dot-health Reuse Probe Prompt — PATCH REQUIRED BEFORE AGENT — 2026-05-13

Scope reviewed

Reviewed Opus B3-F1c-e deliverables:

• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-system-b3f1c-e-dot-dot-health-reuse-viability-probe-prompt-DRAFT.md revision 1
• knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-system-b3f1c-e-dot-dot-health-reuse-viability-design.md revision 1
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-e-dot-dot-health-reuse-viability-design-report.md revision 1

Related review:

• knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1c-d-dot-dot-health-discovery-pause-bridge-2026-05-13.md

Verdict

Status: PATCH_REQUIRED_BEFORE_AGENT_PROBE

The direction is correct: pause the Agent Data bridge and probe dot-dot-health reuse first. However, the prompt still contains schema/path assumptions that can cause incorrect or brittle probe behavior. Do not dispatch Agent yet.

Accepted high-level direction

Accepted:

• B3-F1c-d Agent Data bridge remains paused.
• dot-dot-health reuse must be checked before creating new scheduler/endpoint/DOT.
• Probe is read-only and no function invocation is allowed.
• Viability decision categories are appropriate.

Blocking issue 1 — dot_tools query uses assumed column names

Prompt Phase 4/6 queries:

SELECT tool_name, trigger_type, cron_schedule, status FROM dot_tools ...
SELECT tool_name, trigger_type, cron_schedule, classification, domain, operation, status FROM dot_tools ...

But the live dot_tools schema discovered earlier has code, name, name_en, etc. There is no guarantee that tool_name exists. A read-only probe should not fail because it assumes an old/wrong column name.

Required patch:

• Add schema-first probe for dot_tools:
  • table existence;
  • column list via information_schema.columns;
  • query using confirmed columns only.
• Prefer code and name if present; otherwise map semantically from discovered columns.
• If required semantics cannot be mapped, return BLOCKED_DOT_TOOLS_SCHEMA_UNMAPPED.
• Do not use tool_name as a fixed column.

Blocking issue 2 — Directus Flow query assumes exact schema without preflight

Prompt Phase 4 queries directus_flows(name, trigger, status, options) directly. This is likely correct, but the zero-trust pattern used in B3-F1c-c required directus table/column preflight first.

Required patch:

• Add preflight:
  • verify directus_flows exists;
  • verify required columns exist;
  • if mismatch, return BLOCKED_DIRECTUS_FLOW_SCHEMA_MISMATCH.

Blocking issue 3 — hardcoded PostgreSQL container / DB access path

Prompt uses:

docker exec postgres psql -U directus -d directus ...

This has been used in prior reviewed tasks, but the current prompt is intended as a reusable zero-trust probe. At minimum it must be documented as a reviewed known candidate path and verified before use.

Required patch:

• Add PG access discovery/verification phase:
  • discover/confirm PostgreSQL container/service or approved psql path;
  • verify psql connection with a harmless SELECT 1;
  • if unavailable, return BLOCKED_PG_ACCESS_UNDISCOVERABLE.
• Do not assume container name postgres without checking.

Blocking issue 4 — script path /opt/incomex/dot/bin/dot-dot-health is treated too strongly as truth

Prompt uses candidate comment but then all phases directly read /opt/incomex/dot/bin/dot-dot-health.

Required patch:

• Phase 0 must assign a discovered script path variable.
• All later phases must use <DISCOVERED_DOT_DOT_HEALTH_PATH>.
• If multiple candidates exist, report all and block with BLOCKED_MULTIPLE_DOT_DOT_HEALTH_CANDIDATES unless one canonical path can be justified.

Blocking issue 5 — grep snippets may miss the real dispatch block

Phase 1 command:

grep -n -A 30 'function' ... | grep -A 30 'dispatch\|executor\|case.*function'

This may miss the actual code due to piping context loss. If grep misses, Agent may under-report.

Required patch:

• Instruct Agent to read enough surrounding script context to locate:
  • case dispatch on executor type;
  • function dispatch helper;
  • run_pg_rw / run_pg_ro_db used in that helper;
  • exact SQL call for function executor.
• Grep may be used as locator, but final answer must quote the actual dispatch block or line ranges.

Blocking issue 6 — scheduling probe should include dot_tools and known runner paths without assuming columns

Prompt scheduling probes need to check:

• cron/systemd/Directus Flow;
• dot_tools rows;
• possible host runner scripts.

But all DB-side scheduling overlap should be schema-first and not name-column hardcoded.

Required patch:

• Use dot_tools schema mapping before schedule query.
• Report whether dot-dot-health has a dot_tools row and whether it has a cron/trigger_type/cron_schedule equivalent.

Blocking issue 7 — jurisdiction handling needs actual invocation options, not just grep

Prompt greps jurisdiction, but should determine whether script supports --jurisdiction, env var, positional arg, or hardcoded constant.

Required patch:

• Parse usage/help or top-level argument handling if present.
• Read relevant lines, not just grep head.
• Return:
  • jurisdiction_mode=HARDCODED|CLI_ARG|ENV_VAR|DB_DRIVEN|UNKNOWN.

Blocking issue 8 — overlap scan should include system_health_checks schema-first

system_health_checks columns were known from B3-F1c-a, but zero-trust prompt should still query schema before assuming columns.

Required patch:

• Add system_health_checks table/column preflight.
• Then query function checks and overlap using discovered confirmed columns.
• If schema insufficient, return BLOCKED_SYSTEM_HEALTH_CHECKS_SCHEMA_UNMAPPED.

Required final fields to add

Add:

pg_access_discovered=true|false
dot_dot_health_path_discovered=true|false
dot_tools_schema_mapped=true|false
system_health_checks_schema_mapped=true|false
directus_flows_schema_mapped=true|false
jurisdiction_mode=HARDCODED|CLI_ARG|ENV_VAR|DB_DRIVEN|UNKNOWN
blocked_reason=<none|BLOCKED_PG_ACCESS_UNDISCOVERABLE|BLOCKED_DOT_TOOLS_SCHEMA_UNMAPPED|BLOCKED_SYSTEM_HEALTH_CHECKS_SCHEMA_UNMAPPED|BLOCKED_DIRECTUS_FLOW_SCHEMA_MISMATCH|BLOCKED_MULTIPLE_DOT_DOT_HEALTH_CANDIDATES|BLOCKED_NEEDS_DESIGN>
compiled_from_assumptions=false

Required Opus response

Patch prompt/design/report and return:

b3f1c_e_probe_prompt_patch_status=PASS|PARTIAL|BLOCKED
pg_access_discovery_added=true|false
dot_dot_health_path_variable_added=true|false
dot_tools_schema_first_added=true|false
system_health_checks_schema_first_added=true|false
directus_flows_schema_preflight_added=true|false
grep_locator_not_source_of_truth=true|false
jurisdiction_mode_field_added=true|false
blocked_reason_fields_added=true|false
compiled_from_assumptions_field_added=true|false
agent_probe_allowed=false_until_gpt_review
new_dot_creation_allowed=false
b3f_complete_allowed=false
phase5c2_migration_allowed=false
next_recommended_action=GPT_REVIEW_PATCHED_B3F1C_E_PROBE_PROMPT

Governance status

b3f1c_e_probe_prompt_review_status=PATCH_REQUIRED_BEFORE_AGENT_PROBE
agent_probe_allowed=false
new_dot_creation_allowed=false
directus_flow_creation_allowed=false
agent_data_endpoint_creation_allowed=false
system_health_checks_mutation_allowed=false
b3f_complete_allowed=false
phase5c2_migration_allowed=false
next_recommended_action=OPUS_PATCH_B3F1C_E_PROBE_PROMPT