GPT Review S191 — P10D-2A no-code check conclusion plausible but evidence insufficient

Date: 2026-04-30
Phase: TAC MVP / P10D
Verdict: Do not choose D1/D2 yet. P10D-2A conclusion is plausible but report is not sufficient evidence for a code/capability decision.

---

1. Evidence read

Read report:

knowledge/dev/laws/dieu38-trien-khai/reports/p10d-2a-no-nuxt-code-assembly-path-check-2026-04-30.md

---

2. Assessment

The report's high-level conclusion may be correct:

• DirectusTable is likely table-shaped, not document-reader-shaped.
• /docs and /knowledge/[...slug] likely read KB/Agent Data, not TAC Directus collections.
• The missing platform capability may indeed be a reusable “Collection Document Reader.”

However, the report is too short to authorize next architecture work. It does not include the required evidence table, repo paths, line evidence, or concrete inspection outputs requested by the GPT directive.

Because Assembly First requires checking old information carefully, a summary conclusion without file/registry/API evidence is not enough.

---

3. Problems with current P10D-2A report

1. It says 7 no-code paths are infeasible but does not show the exact inspected files/collections/registry records.
2. It does not include the required table:
   • Area inspected
   • Existing mechanism found
   • File/collection/registry evidence
   • Can use without Nuxt code?
   • Notes
3. It does not prove whether table_registry, ui_pages, agent_views, governance_docs, or navigation records/config can or cannot support the official laws view.
4. It does not show line-level evidence for claims such as “template hardcodes 3 categories” or “/docs hardcodes KB API.”
5. It jumps to D1/D2 choice before proving the no-code path failure to the standard required by Assembly First.

---

4. Direction to Opus

Do not ask User/GPT to choose D1/D2 yet.

Opus should complete P10D-2A evidence properly as a read-only repo/registry inspection.

Task name:

P10D-2A-EVIDENCE — Complete No-Nuxt-Code Assembly Path Evidence

Scope:

• Read-only.
• Must run actual repo/DB/API inspections through Agent/SSH or provide exact file/collection evidence if Opus already has it.
• No code edits.
• No Directus mutation.
• No DDL/DML.
• No implementation prompt.

Required evidence:

1. /knowledge/laws template evidence:
   • exact file path;
   • line snippets proving categories/sections are hardcoded or config-driven.
2. governance_docs evidence:
   • fields and category behavior;
   • whether adding a category record would render automatically or not.
3. DirectusTable / table_registry evidence:
   • whether a table config can show TAC data;
   • why it cannot become a document reader without code.
4. /docs evidence:
   • exact files/composables;
   • source endpoint/API;
   • whether source can be configured without code.
5. /knowledge/[...slug] evidence:
   • exact source and rendering path;
   • why it cannot take TAC Directus data by config.
6. navigation/menu/page registry evidence:
   • search results for registry/menu/page config;
   • whether any existing config can add official TAC laws.
7. Directus config/collection evidence:
   • whether any collection/view/config record can define a document-reader section.
8. Final options table A/B/C/D with evidence, not just conclusion.

---

5. Important framing

The likely strategic answer is not D1 page-specific code unless unavoidable.

If no-code config truly fails, the Assembly-First root fix may be a reusable platform capability, such as:

Collection Document Reader — a config-driven reader that maps a Directus collection/tree/body fields to existing DocsTreeView + markdownToHtml.

But even that capability requires a separate design/gate and must not be started from the current short report.

---

6. Boundary

No Nuxt code authorization yet. No D1 or D2 decision yet. Complete evidence first, then choose.