GPT Review — P10 Pilot Cut-and-Render Plan v0.1

Date: 2026-04-29

Verdict

CORRECT DIRECTION, NOT READY — patch to v0.2 required.

P10 v0.1 correctly addresses the User's actual need: see real documents cut into information units and assembled back. However, P10 is the first gate that would insert real data into TAC core/member tables. Therefore it must be stricter than a concept plan.

Law / constitutional check

No conceptual conflict, but v0.1 needs patch before execution planning.

• Hiến pháp / Zero Trust: v0.1 still assumes schema fields and candidate document versions without live verification.
• Điều 38 / LSL-01: aligned: information-unit-first pilot.
• Điều 33 / PostgreSQL SSOT: aligned if PG is the insertion target and old KB remains source/reference only.
• Gate separation: P10 must be a new gate, not automatically authorized by P9.
• User role correction: aligned. GPT handles technical approval; User reviews visible result.

Accepted strengths

1. Correct goal: User-visible outcome, not technical evidence.
2. Correct sequence: select docs → segment → insert → assemble → compare → User review.
3. Correctly avoids broad migration.
4. Correctly separates Nuxt/Pivot implementation as possible sub-gate.
5. Correctly defines rollback intent for pilot-only data.

Required v0.2 patches

Patch 1 — Do not assume actual schema columns

v0.1 uses fields such as title, section_type_code, parent_lu_id, sort_order, body, version_label, type_code. These must be verified against the actual production schema before any SQL/prompt execution.

v0.2 must include a read-only schema discovery step:

• information_schema.columns for all 6 core/member tables;
• foreign keys and NOT NULL fields;
• CHECK constraints / vocab references;
• Directus field API if using Directus.

If actual schema differs, adapt design before insert. No guessing.

Patch 2 — Candidate document paths/versions must be verified

Do not rely on approximate names like “Điều 35 v5.1” unless exact KB paths and current revision are confirmed.

v0.2 must list exact KB paths for 2–3 pilot docs and their current status/revision. If uncertain, use one document first.

Patch 3 — Start with one document first, then expand

Because this is the first production core/member insert, v0.2 should use a two-phase pilot:

• P10A: one small/medium document only;
• P10B: add 2 more docs after P10A PASS.

This reduces cleanup and segmentation risk.

Patch 4 — Segmentation must be reviewed before insert

Add an intermediate artifact:

segmentation-candidate-<doc>.json or markdown table with:

• unit key/entity_code;
• parent key;
• section_type;
• title;
• body excerpt/hash;
• order;
• source line/heading reference;
• proposed insert rows.

GPT reviews segmentation candidate before any production insert. User may inspect a simple outline if desired.

Patch 5 — Use actual allowed lifecycle/type vocab values

v0.1 uses enacted and enactment as if they are always correct for the specific columns. v0.2 must query seed vocab tables first and use actual values.

Patch 6 — Execution role/path must be decided from reality

v0.1 says use tac-admin token and transaction-wrapped SQL. These are different execution paths.

v0.2 must choose and justify one path:

• Directus API with tac-admin token; or
• psql transaction with an approved DB role.

Do not mix them without explaining. If Directus API does not provide transaction semantics, plan rollback/cleanup accordingly.

Patch 7 — Pivot/render output must be a deliverable, not just a query concept

v0.2 must define exact output files:

• original markdown snapshot;
• reassembled markdown from PG;
• diff report;
• tree/outline report;
• row-count report.

User should receive the rendered result, not SQL.

Patch 8 — Cleanup must use a pilot batch marker

Rollback by entity_code LIKE 'D35%' is unsafe. v0.2 needs a deterministic pilot marker, e.g. publication key, batch id, or metadata field that ties all inserted rows to the pilot. Cleanup must delete only rows created by this pilot.

Patch 9 — P9 closeout wording

It is acceptable for GPT to technically close P9 foundation, but do not describe User as approving technical internals. Record: GPT technical approval complete; User-facing validation moves to P10 pilot.

Directive to Opus 4.6

Patch P10 v0.1 → P10 v0.2 with the required changes.

Priority design:

1. Make P10A one-document first.
2. Verify exact source document path/revision.
3. Add schema discovery before insert design.
4. Produce segmentation candidate artifact before execution.
5. Define user-visible output: original vs reassembled markdown + diff.
6. Use actual vocab values from PG.
7. Choose one execution path and rollback strategy.
8. Do not run Agent and do not insert data yet.

Return P10 v0.2 for GPT review.

Current state

• P9 foundation: technically complete by GPT.
• User-visible information-unit pilot: not yet executed.
• P10 v0.1: correct direction, needs patch.