GPT Review — P10B-1A-HASH PASS and P10B-1B Directive

Date: 2026-04-29

Verdict

P10B-1A-HASH: PASS.

D32 discovery evidence is now sufficient. The source hash, per-unit hashes, coverage, and production vocab verification are complete.

However, the hardcoded extractor risk is real and must be handled before any reusable pipeline step. The hardcoded /tmp/p10b/extract.py may be accepted only as temporary one-off evidence tooling for this read-only hash report. It must not be promoted or reused.

Evidence accepted

• Source SHA256: a42622496fff8c725932a5d310d1e4050e63e41828ba01c1eec4974c045e17f7
• Source size: 5,601 chars / 6,189 bytes / rev 2
• Units: 23 total, all hashed
• Leaf/container handling: 19 leaf + 4 empty structural containers
• Coverage: gaps=0, overlaps=0
• Vocab: 8/8 codes active in production tac_section_type_vocab
• checklist: active, acceptable for first use in D32
• Mutation: none
• Đ41 hygiene: no new persistent tracked files from task

Hardcode risk ruling

Observed hardcoded list in Agent script:

leaf_heading_keys = ['s1','s2_p1', ...]

Ruling:

• This is hardcode.
• It is tolerated only because this was a one-off read-only evidence task.
• It must not be reused in P10B-1B or P10B-2.
• Any future extractor/package/render step must be candidate-driven, not document-key-list-driven.

Answer to Opus questions

1. Is P10B-1A evidence sufficient to approve P10B-1B?

Yes, but with stricter guardrails.

2. Does P10B-1B need GPT review?

Yes.

P10B-1B must be split into a read-only package generation/review step before execution, like P10A-2A/P10A-2B. Do not combine package generation and execution.

3. Hardcode issue: fix now or later?

Fix now in the next prompt. The prompt must explicitly prohibit hardcoded section arrays and require candidate-driven extraction/package generation.

Next directive to Opus 4.6

Prepare P10B-1B-D32 Package Generation v0.1.

Scope:

• READ-ONLY;
• no INSERT/UPDATE/DELETE;
• no DDL;
• no execute insert;
• no Nuxt/KG/vector;
• generate insert/render/rollback/verify package from schema + candidate + hash evidence;
• upload package report;
• STOP for GPT review.

Required guardrails:

1. No hardcoded section arrays.

   • Prohibit source-specific key lists such as ['s1','s2_p1',...].
   • Use candidate table/report as data input.
   • Iterate over candidate units, not manually written section names.

2. Use accepted evidence.

   • Full source SHA must match a42622496fff8c725932a5d310d1e4050e63e41828ba01c1eec4974c045e17f7.
   • Per-unit hashes from P10B-1A-HASH are authoritative.
   • If any mismatch, STOP.

3. Schema-adaptive generation.

   • Query actual columns/defaults/constraints for target tables.
   • Do not hardcode insert columns from memory.
   • Confirm canonical address regex still accepts D38-DIEU32-*.

4. Collision check.

   • Confirm no existing DIEU-32 publication/LU rows.

5. Birth gates/trigger analysis.

   • Catalog trigger status and function sources relevant to INSERT/DELETE rollback.
   • No mutation in package phase.

6. Generate four files only.

   • insert-candidate.sql
   • render.sql
   • rollback.sql
   • verify-counts.sql

7. Report hardcode audit.

   • Explicit section: “Hardcode audit”.
   • State whether any hardcoded D32-specific section list exists.
   • PASS only if none exists in package-generation logic.

8. STOP after upload.

After GPT reviews package, a separate P10B-1C execute/render step can be authorized.

Status

• P10B-1A: COMPLETE / PASS.
• P10B-1A-HASH: PASS.
• Next: P10B-1B-D32 read-only package generation.
• Execution is not authorized yet.