GPT Review — P10A-2 D35 Pilot Insert + Render Prompt v0.1

Date: 2026-04-29

Verdict

NOT READY — patch to v0.2 required before execution.

P10A-2 v0.1 is directionally correct and covers the right phases, but it still hardcodes many column names and lifecycle/vocab values that must be generated from actual production schema. Because P10A-2 is the first production insert into TAC core/member tables, this is a blocker under Zero Trust.

Law / constitutional check

No conceptual conflict if patched.

• Hiến pháp / Zero Trust: v0.1 violates the principle by hardcoding insert columns/values not proven in the prompt.
• Điều 38 / LSL-01: aligned in goal: information unit pilot.
• Điều 33 / PostgreSQL SSOT: aligned if insert targets PG and source KB remains reference.
• Gate separation: aligned if no Nuxt/KG/vector/broad migration.
• User visible objective: aligned: original vs reassembled/diff deliverables.

Accepted strengths

1. Correct goal: insert D35 pilot units into PG and render back for User inspection.
2. Preflight phase is present.
3. Candidate final patch phase includes split §8 and clean descriptions.
4. Transaction/rollback intent is present.
5. Deliverables are correctly user-visible.
6. Hard exclusions are mostly correct.

Blocking issues

Blocker 1 — Hardcoded column names in INSERT plan

The prompt hardcodes fields such as:

• doc_code, version, publication_type, name, owner, description, lifecycle_status, risk_tier, publication_profile;
• canonical_address, parent_id, section_type, identity_profile;
• logical_unit_id, version_number, body, content_hash, review_state, provenance, editor;
• publication_id, logical_unit_id, render_order.

These may not match actual production schema. P10A-1 discovered schema, but v0.1 must use that discovery explicitly. The prompt must not embed pseudo-schema as execution SQL.

Blocker 2 — Execution role assumption

PF-1 assumes directus/directus is execution role for insert. P10A-1 explicitly said this role was read-only discovery role and must not be inferred for P10A-2 insert. v0.2 must verify insert privileges or use the proven appropriate role/token path.

Blocker 3 — Lifecycle/vocab value assumptions

The prompt assumes values like:

• publication_type law;
• lifecycle proposed, draft_only, draft;
• review_state unreviewed;
• provenance PROV-AI;
• risk_tier highest.

v0.2 must query actual vocab/config and choose valid values from production.

Blocker 4 — Transaction semantics versus trigger rollback

The prompt says single transaction and rollback on error, but if using psql this is possible only if the generated SQL is valid and all statements are inside BEGIN/COMMIT. If using Directus API, transaction semantics differ. v0.2 must choose one execution path based on actual privileges and define exact rollback.

Blocker 5 — Render recursive query is likely schema-assumptive and order-unsafe

ORDER BY depth, sort_order may not preserve tree preorder. It should order by a path/array if schema supports sort order. Also the query uses parent_id, sort_order, canonical_address, logical_unit_id names that may differ.

Blocker 6 — Existing data collision check missing

Before inserting D35, v0.2 must verify no existing D35 pilot/core rows conflict, using actual unique/business key fields from schema. If any D35 rows exist, STOP or classify exact prior pilot.

Blocker 7 — Delete rollback may violate lifecycle/trigger guards

Rollback SQL assumes DELETE is permitted. Prior trigger guard and lifecycle rules may block delete depending status/config. v0.2 must verify rollback feasibility before insert or define rollback as a later explicit gate if deletion is not safe. For pilot, prefer lifecycle mutable states and a clear rollback path.

Blocker 8 — Full body source for final candidate v3 must be auditable

Candidate reports intentionally use excerpts/hashes. P10A-2 must construct full bodies from source snapshot and verify SHA256 per unit after final patch, especially after §8 split.

Required v0.2 patches

Patch 1 — Replace hardcoded INSERT SQL with schema-driven insert generation

Use actual schema discovered in P10A-1/P10A-2 preflight. Generate an insert-candidate.sql only after:

• reading information_schema.columns;
• mapping candidate fields to actual columns;
• verifying all NOT NULL columns have values/defaults;
• verifying FK and CHECK values;
• verifying triggers/birth gate required fields.

If any required column cannot be mapped, STOP.

Patch 2 — Insert candidate review checkpoint

Add STOP point after generating final candidate v3 and insert-candidate SQL:

• upload candidate v3 summary + SQL SHA;
• optionally include SQL excerpt, not secrets;
• GPT review before execution, unless SQL is generated and executed in same Agent task under strict preflight. Given this is first insert, prefer STOP before execution.

Recommended split:

• P10A-2A: final candidate v3 + insert/render SQL package, read-only/no mutation.
• P10A-2B: execute insert + render after GPT review.

Patch 3 — Verify execution role before mutation

Do not assume directus can insert. Required:

• SELECT current_database(), current_user;
• privilege checks for target tables;
• if using psql, role must be verified to INSERT/SELECT/DELETE as needed;
• if using Directus API, use TAC admin token and accept API rollback limitations explicitly;
• choose one path.

Patch 4 — Query actual vocab/lifecycle values

Use production tables to select valid values. Do not hardcode law, draft_only, unreviewed, etc. If desired value absent, STOP and propose mapping.

Patch 5 — Add collision/idempotency precheck

Before insert, check existing D35 rows using actual unique keys. If any exist:

• exact prior failed pilot → report and stop;
• unknown rows → STOP;
• no blind delete.

Patch 6 — Rollback feasibility precheck

Before insert, verify rollback path is not blocked by lifecycle/trigger constraints. If delete rollback is unsafe, use transaction rollback only and do not COMMIT until render validation is done, or design a non-delete rollback gate.

Patch 7 — Render query must use actual schema and stable tree preorder

Build tree order using a recursive path/array from actual sort/order columns. Do not use ORDER BY depth, sort_order alone.

Patch 8 — Deliverables should be uploaded as KB artifacts but no full SQL secrets/log noise

Deliverables are fine. Also include:

• final candidate v3 JSON SHA;
• insert SQL SHA;
• inserted IDs;
• trigger output;
• row-count proof;
• zero change outside D35 proof.

Suggested next direction

Because this is the first production insert, GPT recommends splitting P10A-2 into two substeps:

P10A-2A — Insert Package Generation, read-only

• Final candidate v3: split §8, clean descriptions, canonical keys if safe.
• Schema-driven mapping to actual columns.
• Generate transaction SQL file but do not execute.
• Generate render query based on actual schema.
• Generate rollback SQL based on actual schema.
• Upload package report and STOP.

P10A-2B — Execute Insert + Render

Only after GPT reviews P10A-2A package.

Directive to Opus 4.6

Patch P10A-2 v0.1 → P10A-2A v0.2 as a read-only package-generation prompt.

Do not dispatch insert execution yet.

The next prompt should:

• perform final candidate v3 patch;
• generate schema-driven insert SQL from actual production schema;
• generate render SQL from actual schema;
• generate rollback SQL from actual schema;
• verify execution role and rollback feasibility via catalog/privilege checks only;
• upload package report;
• STOP.

No production insert until GPT reviews P10A-2A package.

Current state

• P10A-1 discovery: PASS.
• P10A-1B candidate v2: PASS accepted.
• P10A-2 v0.1: not ready.
• Recommended next: P10A-2A read-only insert/render package generation.