GPT Review — B3-F1c-d Dispatch Bridge Design — PATCH REQUIRED BEFORE AGENT PROBE — 2026-05-13

Scope reviewed

Reviewed Opus B3-F1c-d deliverables:

• knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-system-b3f1c-d-dispatch-bridge-decision-design.md revision 1
• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-system-b3f1c-d-dispatch-bridge-shape-probe-prompt-DRAFT.md revision 1
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-d-dispatch-bridge-decision-design-report.md revision 1

Related context:

• knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1c-c-a-scheduler-probe-compile-partial-accepted-dispatch-blocked-2026-05-13.md

Verdict

Status: PATCH_REQUIRED_BEFORE_AGENT_PROBE

Option C — Agent Data API bridge — is a plausible and likely strongest direction, but the current design/prompt still contains unqualified assumptions and hardcode risks. Do not dispatch Agent yet.

Accepted high-level direction

The following reasoning is accepted at architecture level:

• Nuxt direct PG is not recommended because current Nuxt server tree has no PG client/pattern.
• Directus extension is not recommended without live extension infrastructure proof.
• Agent Data bridge is plausible because Agent Data already has PG connectivity and Directus Flows have AGENT_DATA_URL/AGENT_DATA_API_KEY available.
• Recurring execution must be DOT/registry-governed, not ad-hoc Agent shell.

However, the design must still be zero-trust and probe-first.

Blocking issue 1 — Design states unprobed values as if final

Current design architecture states:

url: {{$env.AGENT_DATA_URL}}/run/birth-onboarding-full-scan
headers: X-API-Key: {{$env.AGENT_DATA_API_KEY}}
body: {} or {run_source: "directus_flow"}
Route: POST /run/birth-onboarding-full-scan
Auth: X-API-Key

These may be correct, but they are not yet proven for Agent Data. They must be marked as CANDIDATE values requiring probe. Otherwise they become hardcode-by-design.

Required patch:

• Mark route path, header name, body shape, and auth method as candidates.
• Require Agent to discover existing Agent Data route/auth conventions first.
• If Agent Data uses a different auth pattern, compile from that live pattern.
• If no route/auth pattern can be safely determined, return BLOCKED_AGENT_DATA_ROUTE_PATTERN_UNDISCOVERABLE.

Blocking issue 2 — Prompt uses SSH wrapper and fixed repo paths without qualification

Prompt uses commands such as:

ssh contabo "grep ... /opt/incomex/docker/agent-data-repo/agent_data/server.py"

This is too concrete for a reusable Agent prompt and may fail if the Agent already runs on VPS or if path names differ.

Required patch:

• Use environment-discovered paths.
• First locate Agent Data repo/server file via read-only discovery.
• Do not hardcode ssh contabo in the prompt unless this is explicitly the execution environment.
• Use "if running locally on VPS, omit ssh" or ask Agent to report execution context.

Blocking issue 3 — Agent Data route pattern probe is too narrow

Prompt only greps server.py. Agent Data may use routers/modules or framework files elsewhere.

Required patch:

• Probe the whole Agent Data app tree for route decorators and auth middleware.
• Discover framework (FastAPI, Flask, etc.) from imports and app creation.
• Locate route files/modules before assuming server.py is the single source.
• If routes are modular and not in server.py, follow discovered imports.

Blocking issue 4 — The design assumes Agent Data can write system_issues

The design says the Agent Data endpoint writes summary to system_issues using discovered schema. But this is not yet proven:

• Agent Data PG role may not have INSERT privileges on system_issues.
• Existing Agent Data code may not write to PG directly except internal document/search operations.
• Summary issue schema convention must remain the B3-F1c-c pattern, not invented again.

Required patch:

• Add read-only privilege probes:
  • has_table_privilege(<agent_data_pg_role>, 'public.system_issues', 'INSERT')
  • role/user actually used by Agent Data PG connection, not assumed directus.
• If INSERT privilege is not present, mark BLOCKED_SYSTEM_ISSUES_WRITE_PRIVILEGE or propose a reviewed alternative; do not assume.
• Endpoint code compile must reuse B3-F1c-c system_issues summary mapping or block if unavailable.

Blocking issue 5 — Function execute privilege assumes directus user

Prompt says:

SELECT has_function_privilege('directus', 'public.fn_birth_onboarding_full_scan()', 'EXECUTE')

But the Agent Data connection user is not yet known. The check must use the discovered Agent Data DB role.

Required patch:

• First discover the PG user/role used by Agent Data connection.
• Then run has_function_privilege(<discovered_role>, 'public.fn_birth_onboarding_full_scan()', 'EXECUTE').
• Also verify the endpoint can call the function without invoking it during probe; do not run the function.

Blocking issue 6 — SELECT public.fn_birth_onboarding_full_scan() appears in endpoint design without safety language

The endpoint will eventually invoke the function, which writes gaps to system_issues through helper. That is DML-affecting. The design must make clear:

• This is future execution only, not part of probe.
• Any manual endpoint test is DML-affecting and requires separate approval.
• Scheduler activation must not run until endpoint + policy + DOT registration are reviewed.

Required patch:

• Add explicit "DML-affecting future call" warning, like prior B3-F1c-c docs.

Blocking issue 7 — Revised Directus Flow seed design says keep same status logic

Design says:

Keep same cron, same flow name, same status logic

Earlier GPT review already warned that status='active' should be reconsidered if endpoint is not deployed/verified. The design must not preserve active by default.

Required patch:

• Future revised flow seed should compile as inactive/draft candidate unless execution plan explicitly approves active creation after endpoint validation.
• If Directus supports only active/inactive, choose inactive as safe default for seed artifact.
• State activation is a separate approval step or a gated execution step after endpoint verification.

Blocking issue 8 — Candidate cadence still carried forward as “same cron”

Design says "same cron". This may imply inheriting the candidate 0 */6 * * * as truth.

Required patch:

• State cadence remains policy/candidate-driven from B3-F1c-c.
• No scheduler seed may execute until cadence is approved and dot_config/directus flow values match.

Blocking issue 9 — dot_config uniqueness probe still hardcodes only constraints

Prompt Phase 5 checks pg_constraint but not unique indexes. A unique index may exist without a pg_constraint entry.

Required patch:

• Probe both constraints and indexes for uniqueness on dot_config(key):
  • pg_constraint
  • pg_index / pg_attribute
• Do not rely on ON CONFLICT(key) until uniqueness is proven.

Blocking issue 10 — Final fields are insufficient for no-hardcode governance

Current final fields omit several critical blockers/attestations.

Required patch: Add final fields:

agent_data_route_pattern_discovered=true|false
agent_data_auth_pattern_discovered=true|false
agent_data_pg_role_discovered=true|false
system_issues_insert_privilege=true|false
revised_flow_default_status=inactive|active|BLOCKED
cadence_source=EXISTING_DOT_CONFIG|CANDIDATE_REQUIRES_REVIEW|BLOCKED
compiled_from_assumptions=false
blocked_reason=<none|BLOCKED_AGENT_DATA_ROUTE_PATTERN_UNDISCOVERABLE|BLOCKED_AGENT_DATA_AUTH_PATTERN_UNDISCOVERABLE|BLOCKED_PG_CONNECTION_PATTERN_UNDISCOVERABLE|BLOCKED_FUNCTION_EXECUTE_PRIVILEGE|BLOCKED_SYSTEM_ISSUES_WRITE_PRIVILEGE|BLOCKED_DOT_CONFIG_UNIQUENESS_UNKNOWN|BLOCKED_CADENCE_UNAPPROVED>

Blocking issue 11 — Report is too confident before probe

Report says:

recommended_option=AGENT_DATA_API_BRIDGE
hardcoded_credentials=false

This is acceptable as recommendation, but should be qualified:

• recommended_option=AGENT_DATA_API_BRIDGE_PENDING_PROBE
• hardcoded_credentials=false_in_design; must be verified in compiled artifacts

Required patch:

• Lower confidence until route/auth/PG-role/privileges are proven.

Required Opus response

Opus should patch design, prompt, and report.

Required final response:

b3f1c_d_dispatch_design_patch_status=PASS|PARTIAL|BLOCKED
agent_data_route_path_marked_candidate=true|false
agent_data_auth_marked_probe_required=true|false
repo_path_discovery_added=true|false
route_tree_probe_expanded=true|false
agent_data_pg_role_discovery_required=true|false
system_issues_insert_privilege_probe_added=true|false
future_function_call_marked_dml_affecting=true|false
revised_flow_inactive_default_required=true|false
cadence_policy_candidate_restated=true|false
dot_config_unique_index_probe_added=true|false
final_fields_strengthened=true|false
agent_probe_allowed=false_until_gpt_review
scheduler_execution_allowed=false
b3f_complete_allowed=false
phase5c2_migration_allowed=false
next_recommended_action=GPT_REVIEW_PATCHED_B3F1C_D_DOCS

Governance status

b3f1c_d_design_review_status=PATCH_REQUIRED_BEFORE_AGENT_PROBE
agent_probe_allowed=false
scheduler_execution_allowed=false
directus_flow_execution_allowed=false
agent_data_endpoint_creation_allowed=false
dot_config_mutation_allowed=false
dot_tools_mutation_allowed=false
b3f_complete_allowed=false
phase5c2_migration_allowed=false
next_recommended_action=OPUS_PATCH_B3F1C_D_DOCS