GPT Review — B3-F1c-c Third Pass — PATCH REQUIRED BEFORE AGENT — 2026-05-13

Scope reviewed

Reviewed second-pass patched docs:

• knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-system-b3f1c-c-directus-nuxt-dot-scheduler-design.md revision 15
• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-system-b3f1c-c-scheduler-shape-probe-and-artifact-prompt-DRAFT.md revision 11
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3f1c-c-scheduler-design-report.md revision 6

Previous GPT review:

• knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3f1c-c-patched-docs-second-pass-patch-required-2026-05-13.md

Verdict

Status: PATCH_REQUIRED_BEFORE_AGENT_PROBE

The second-pass patches fixed all prior explicit blockers. However, GPT found a few remaining wording/flow issues that can still become hardcode/list-as-truth or unsafe assumptions at scale. Do not dispatch Agent until Opus patches these.

Accepted fixes from second pass

The following are accepted:

• Unauthorized schema-change mitigation removed.
• Fixed Cấp B classification removed from registry role table and converted to candidate/live-derived taxonomy.
• dot_tools probe changed to schema-first.
• Directus Flow schema preflight added.
• blocked_reason and observability_status added to final fields.
• _dot_origin marked as candidate column/value and must be verified.

Remaining issue 1 — design still contains snapshot count wording

Design architecture diagram says:

→ scans 166+ collection_registry rows

Even with +, this is a snapshot count and can anchor future readers/agents. The full-scan function must scan live registry rows, not a count-coded or count-expected set.

Required patch:

• Replace with:

→ scans live collection_registry rows derived at runtime

or equivalent.

Remaining issue 2 — design endpoint step only mentions status='complete'

Design architecture overview says:

Step 4: If status='complete', write summary to system_issues

But the function can also return status='dependency_fail', and the prompt correctly includes both statuses. The design should match the prompt to avoid future implementers dropping dependency-failure observability.

Required patch:

• Replace with:

Step 4: If status is complete or dependency_fail, write summary only if system_issues shape supports the compiled observability pattern

Remaining issue 3 — Directus preflight says “or equivalents” but later SQL still assumes exact column names

Prompt Phase 1 preflight says required columns are:

id, name, trigger, status, options (or equivalents)
id, key, type, options, flow (or equivalents)

But the subsequent SQL queries still use exact columns. If the preflight maps equivalent columns rather than exact names, those queries may fail. To keep zero-trust behavior clean, prompt should either require exact Directus columns or instruct Agent to adapt queries to discovered equivalent columns.

Required patch, choose one:

1. Directus system tables are treated as Directus schema constants for this environment; exact columns must exist or stop as BLOCKED_DIRECTUS_FLOW_SCHEMA_MISMATCH.
2. Or: if equivalent columns are discovered, all following queries must be adapted to the mapped names.

Recommendation: choose option 1 for Directus system tables, since these are known Directus tables and this is a read-only probe. Remove ambiguous “or equivalents”.

Remaining issue 4 — system_issues summary + Directus Flow log still marked HIGH confidence before shape probe

Report says:

E. Observability | system_issues summary issue + Directus Flow log. No new table. All fields are CANDIDATES requiring live schema validation. | HIGH

Because actual system_issues mapping and Directus Flow log retention/queryability are still unknown, confidence should not be HIGH. This is not a runtime blocker, but it weakens the no-assumption posture.

Required patch:

• Change confidence to MEDIUM or CONDITIONAL.
• State it becomes HIGH only after system_issues shape and Flow logging behavior are probed.

Remaining issue 5 — final report fields should include “compiled_from_assumptions=false”

The prompt has many safeguards, but adding one explicit final attestation helps catch accidental assumption-based compile.

Required patch:

• Add final response field:

compiled_from_assumptions=false

If any artifact is compiled despite an unknown pattern, Agent must mark compiled_from_assumptions=true and status cannot be PASS.

Governance status

b3f1c_c_third_pass_review_status=PATCH_REQUIRED_BEFORE_AGENT_PROBE
agent_probe_allowed=false
scheduler_execution_allowed=false
directus_flow_creation_allowed=false
nuxt_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_C_DOCS_THIRD_PASS