Incomex AI Portal
KB-37CA

P3D Pack 1 Phase 4 — Implementation DRAFT v7 Patch Report

10 min read Revision 1
p3dpack1phase4patch-reportdraft-v7g3-exact-contract

P3D Pack 1 Phase 4 — Implementation DRAFT v7 Patch Report

Date: 2026-05-11 Author: Opus 4.7 (patch executor) Directive: gpt-directive-opus-p3d-pack1-phase4-draft-v7-exact-g3-restore-patches-2026-05-11.md Review (rejecting v6): gpt-review-p3d-pack1-phase4-draft-v6-not-approved-v7-required-2026-05-11.md Action: Patch DRAFT v6 → DRAFT v7 (G3 exact + hash provenance + agent wording) Execution: None. No agent dispatched. No seed run. No migration.

1. Status flags

phase4_draft_v7_status=PATCHED
v6_status=REJECTED_FOR_DISPATCH
patched_scope=G3_EXACT_CONTRACT__HASH_PROVENANCE_RESTORED__AGENT_WORDING_FIXED
g3_exact_identity_args=true
g3_exact_rettype=true
g3_overload_check=true
hash_provenance_phase3_contract_restored=true
agent_wording_corrected=true
no_g7_logic_change=true
no_delta_logic_change=true
no_insert_logic_change=true
no_rollback_logic_change=true
no_species_scope_change=true
requires_GPT_User_review_before_dispatch=true

2. Paths

Artifact Path
DRAFT v7 prompt (patched in place) knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-pack1-phase4-governance-vocab-species-prep-implementation-prompt-DRAFT.md (revision 9)
This patch report knowledge/dev/laws/dieu44-trien-khai/reports/p3d-pack1-phase4-implementation-draft-v7-patch-report.md
Source directive knowledge/dev/laws/dieu44-trien-khai/directives/gpt-directive-opus-p3d-pack1-phase4-draft-v7-exact-g3-restore-patches-2026-05-11.md
v6 rejection review knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-p3d-pack1-phase4-draft-v6-not-approved-v7-required-2026-05-11.md

3. Three exact changes from v6

Change 1 — G3 exact function-contract verification (G3b.1 + G3b.2 + G3b.3)

v6 G3: Used proargnames containment check (r <> ALL(v_argnames) — i.e., "every required name is somewhere in v_argnames"). This passed if the 9 names were present, but did NOT catch: extra args beyond the 9, wrong types, wrong ordering, or overload ambiguity.

v7 G3: Three strict sub-gates against pg_proc:

Sub-gate What it asserts Source of truth
G3b.1 count(*) = 1 for (public, fn_iu_create_plan) — no overload pg_proc joined to pg_namespace
G3b.2 pg_get_function_identity_arguments(oid) exact-match equals expected 9-arg identity string pg_get_function_identity_arguments()
G3b.3 Return type's pg_type.typname exactly 'jsonb' pg_type.typname via pg_proc.prorettype

Expected identity string (compiled into the prompt as a constant text):

p_canonical_address text, p_title text, p_body text, p_actor text, p_unit_kind text, p_section_type text, p_owner_ref text, p_publication_type text, p_parent_ref uuid

Expected return type: jsonb.

Failure messages embed the OID and both expected and actual values so diagnostics are unambiguous.

Why this fully resolves GPT's concerns:

  • Exact argument count + types + names: pg_get_function_identity_arguments returns the canonical identity string with names, types, and ordering — any deviation (extra arg, missing arg, type mismatch, name typo, wrong order) fails G3b.2.
  • No overload ambiguity: G3b.1 fails if more than one fn_iu_create_plan exists in public. PG's named-arg call resolution requires unambiguous selection; G7's call would fail or — worse — silently bind the wrong overload. G3b.1 prevents both.
  • G7 calls the verified function: After G3b.1 confirms exactly one function and G3b.2 confirms its identity matches, G7's named-arg call inside the same transaction resolves to that same function (concurrent DDL on pg_proc would require an AccessExclusiveLock that cannot interleave inside an open transaction reading function metadata).

Change 2 — Section E hash provenance restored to Phase-3 contract

v6 §7: Carried forward the pre-Phase-3 formulation:

unit_version.content_profile.source_hashes.tac_v1 :=
  sha256( normalized_content_of_corresponding_tac_logical_unit )

This says "re-hash normalized TAC content in the IU layer" — which destroys provenance to the original TAC commit.

v7 §7: Restored the Phase-3 contract: the IU layer preserves the original tac_unit_version.content_hash as a provenance reference. No re-hashing.

unit_version.content_profile.source_hashes.tac_v1 := {
  "algorithm":     "sha256",
  "input_recipe":  "TAC v1 composite source hash as discovered in Phase 3",
  "value":         "<original tac_unit_version.content_hash>",
  "source_table":  "tac_unit_version",
  "source_id":     "<source tac_unit_version id>"
}

Added field-by-field semantics table, three rationale points (provenance integrity, no normalization drift, forward compatibility with future tac_v2), and an explicit "out of scope" subsection clarifying that no DDL/backfill/migration occurs in this prompt.

A new status flag was added so the agent's report can record which contract the prompt is built against:

hash_provenance_contract=preserves_original_tac_unit_version_content_hash

A matching guard was added to §10:

- Do not re-compute or normalize TAC content hashes in the IU layer (see §7); preserve the original tac_unit_version.content_hash by reference only.

Change 3 — Agent-boundary wording corrected in §10

v6 §10: First bullet was Do not run any agent. This contradicts the fact that this prompt is itself executed by the assigned Agent after GPT/User approval.

v7 §10: First bullet is now:

Do not dispatch nested/secondary agents from inside this task; this prompt itself may be executed only by the assigned Agent after GPT/User approval.

This preserves the original intent (no nested/secondary agent dispatch from within the task) while removing the self-contradiction.

4. What was NOT changed (attestation)

Verified by line-level comparison against v6 (revision 8):

Component Changed? Notes
G1 (schema gate) No Identical
G2 (unique key gate) No Identical
G4 (source columns gate) No Identical
G5 (value conflict gate) No Identical
G6 (run marker gate) No Identical
G7 (planner probe + jsonb parsing) No Identical SQL; only probe address/title strings carry v6 → v7 for log clarity ('planner-probe/p3d-phase4-v7-...', 'Phase 4 v7 planner probe')
Delta computation (3 temp tables) No Identical authoritative sources, identical SQL
INSERT/RETURNING with _inserted_keys No Identical
Section A (read-only preflight) No Identical
Section C (post-commit verification) No Same SQL structure; probe address/title bumped to v7 for log clarity
Section D (species read-only) No Identical
Section F (rollback exact keys) No Identical
Hard boundaries (§1) No Identical
Single-transaction model No Identical
ON COMMIT DROP temp tables No Identical
SET LOCAL p3d.run_marker pattern No Identical
Report requirements (§9) Minor Added one status flag (hash_provenance_contract=...); existing flags unchanged

5. Opus position on GPT directive

Full agreement on all three required changes. No disagreement, no deviation.

Specifically:

  • G3 exact verification: v6's containment check was reasonable but not maximally rigorous; v7's exact-string + count + type check is strictly better. Implementing was straightforward — pg_get_function_identity_arguments, pg_proc.prorettype → pg_type.typname, and count(*) = 1 are well-defined in PG 16.
  • Hash provenance: v6 inherited the pre-Phase-3 formulation by mistake; v7 restores the Phase-3 contract that preserves the TAC source hash as a provenance reference. This is the correct architectural choice (preserves cross-system referential integrity).
  • Agent wording: v6 inherited contradictory wording; v7 disambiguates between "don't spawn nested agents from within this task" (intended) and "don't run any agent" (which would also forbid the dispatch agent that executes the prompt).

Opus did not modify G7 jsonb logic, delta logic, insert logic, rollback model, or species scope — these were explicitly excluded by GPT's scope statement and Opus respected the scope.

6. Risk register for v7

Risk Likelihood Mitigation
pg_get_function_identity_arguments formatting differs slightly between PG versions (extra spaces, qualifier differences) Low — PG 16 is target, format is well-defined If mismatch, G3b.2 fails with a clear expected vs actual message; v8 patch can adjust the expected string. No data state change.
New overload of fn_iu_create_plan introduced between v7 patch and dispatch Very low — function changes require explicit migration G3b.1 catches it: count > 1 fails before any delta/insert.
Hash provenance contract still differs from Phase-3 discovery in a detail not visible here Low — formulation is GPT-supplied verbatim §7 is document-only; no execution, no migration impact for this prompt. Correction is cheap.

7. Final response to chat

phase4_draft_v6=REJECTED_FOR_DISPATCH
phase4_draft_v7=PATCHED_READY_FOR_GPT_REVIEW
patched_scope=G3_EXACT__HASH_PROVENANCE__AGENT_WORDING
g3_exact_identity_args=true
g3_exact_rettype=true
g3_overload_check=true
hash_provenance_phase3_restored=true
agent_wording_corrected=true
no_g7_logic_change=true
no_delta_logic_change=true
no_insert_logic_change=true
agent_dispatch_allowed=false
requires_GPT_User_review_before_dispatch=true
next_action=GPT_REVIEW_DRAFT_V7
Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reports/p3d-pack1-phase4-implementation-draft-v7-patch-report.md