GPT Review — P10B-1B D32 Package Generation Prompt v0.1

Date: 2026-04-29

Verdict

Good direction, but patch before dispatch.

The prompt now properly splits package-generation from execution and includes anti-hardcode guardrails. However, several lines can still cause Agent to guess or self-correct during execution.

Accepted

• Read-only scope.
• Package-only, no execute.
• Explicit hardcode audit.
• Use of P10B-1A-HASH evidence.
• STOP before execution.

Required patches

P1 — Clarify hardcode rule: logic vs generated data

The prompt says generated SQL must not contain hardcoded unit references, but insert-candidate.sql will necessarily contain concrete D32 addresses because it is a data artifact.

Patch wording:

• Hardcoded D32-specific lists are forbidden in generation logic/scripts.
• Generated SQL may contain D32 data values if they are derived from candidate/evidence input.
• Hardcode audit should check helper scripts and generation logic, not the generated SQL data payload.
• If generated SQL has D32 values, report their source mapping to candidate rows.

P2 — Collision check must be schema-adaptive; do not use slug unless discovered

The prompt uses:

SELECT count(*) FROM tac_publication WHERE slug LIKE ...

This may fail if slug is not a real column. P10A package used doc_code/version after schema discovery.

Patch:

• First query actual columns and UNIQUE/business keys on tac_publication and tac_logical_unit.
• Use discovered keys for collision:
  • likely doc_code='DIEU-32' + version='v1.1' for publication if columns exist;
  • canonical_address LIKE 'D38-DIEU32-%' for LU if column exists.
• If safe business key cannot be discovered, STOP.

P3 — Trigger function query may be invalid

The prompt uses pg_get_functiondef(tgfoid). tgfoid is an oid, but safer pattern is join pg_proc p ON p.oid=t.tgfoid then pg_get_functiondef(p.oid).

Patch query:

SELECT t.tgname, t.tgrelid::regclass, t.tgenabled,
       p.proname, p.proowner::regrole, p.prosecdef,
       pg_get_functiondef(p.oid) AS function_def
FROM pg_trigger t
JOIN pg_proc p ON p.oid = t.tgfoid
WHERE t.tgrelid IN (
  'public.tac_logical_unit'::regclass,
  'public.tac_unit_version'::regclass,
  'public.tac_publication_member'::regclass,
  'public.tac_publication'::regclass
)
AND NOT t.tgisinternal;

P4 — Do not assert execution role before discovery

The prompt says:

Execution role: directus (only role with INSERT on tac_*)

This was true in prior evidence but must be rechecked. Patch:

• State: candidate expected execution role: directus, to be verified from information_schema.role_table_grants.
• P10B-1B is read-only and should report whether directus remains valid for P10B-1C.

P5 — Source/candidate input must be a structured file or explicitly parsed table

The prompt says iterate over candidate units from report, but reports are human markdown and error-prone.

Patch:

• Agent should construct candidate-units.json from the accepted 23 rows and include SHA256 of this JSON.
• This JSON becomes the data input for SQL generation.
• Hardcode audit must ensure scripts iterate over JSON array, not manual key lists.

Directive to Opus 4.6

Patch P10B-1B prompt v0.1 → v0.2 with P1–P5 above.

After patch:

• If no new scope is added, mark GPT AUTHORIZED — execute immediately.
• Dispatch Agent.
• Agent must upload package report and STOP.

Status

• P10B-1B v0.1: needs patch.
• Next: v0.2 patched prompt, then Agent read-only package generation.