Incomex AI Portal
KB-5131

GPT Review — 23-P2 Inspection Results + Handoff to Opus

10 min read Revision 1
gpt-reviewpack-23p2-resultshandoffopus-directivetext-as-code

GPT Review — 23-P2 Inspection Results + Handoff to Opus

Date: 2026-05-06
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/reports/23-p2-iu-edit-merge-runtime-inspection-report.md rev1

Verdict

23-P2 PASS. Inspection COMPLETE.

Agent executed correctly: 33/33 queries passed, READ-ONLY boundaries honored. No supplemental Agent run is needed before Opus reviews.

Handoff context for new Opus session

We are no longer working on Pack 22. Pack 22 is COMPLETE and closed:

  • fn_iu_create canonical create works.
  • fn_iu_create_plan exists.
  • IU Gateway is enforced.
  • Direct INSERT/UPDATE to information_unit / unit_version are blocked.
  • README guidance exists.

We are now in Pack 23 — Information Unit text-as-code edit/merge model.

User’s long-term requirement:

  • Miếng thông tin must follow standard IT/text-as-code practices.
  • Multiple AI/Agents should be able to propose edits to the same IU without overwriting each other.
  • There must be proposal / review / merge semantics like Git/PR.
  • Design must scale and allow metadata evolution.
  • Composition has multiple axes:
    • document assembly: document → sections;
    • workflow assembly: process → steps;
    • domain traceability: law → design → procedure → code → test → report.
  • Do not collapse all axes into parent/child.

Files Opus must read first

Read these exact files. Do not search randomly before reading them:

  1. knowledge/dev/laws/dieu44-trien-khai/design/23-p1-iu-text-as-code-edit-merge-design.md
  2. knowledge/dev/laws/dieu44-trien-khai/reports/23-p2-iu-edit-merge-runtime-inspection-report.md
  3. knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-23-p1-design-rev2-and-23-p2-inspection-directive-2026-05-06.md
  4. knowledge/dev/laws/dieu44-trien-khai/reports/22-pack-closure-iu-native-create-and-gateway.md
  5. knowledge/dev/laws/dieu44-trien-khai/readme/iu-create-gateway-readme.md

Optional only if needed:

  • knowledge/dev/laws/dieu44-trien-khai/design/07-iu0-index-and-core.md
  • knowledge/dev/laws/dieu44-trien-khai/design/07c-iu0-protection-slice-pilot-open.md

Accepted 23-P2 facts

Runtime shape

  • information_unit: 15 columns.
  • unit_version: 9 columns.
  • IU count = 5; UV count = 5.
  • All UV rows have version_seq=1.
  • All current IUs are pilot/test rows.
  • No production IU edits/merges yet.

UV constraints

  • unit_version.version_seq is NOT NULL.
  • unit_version has UNIQUE(unit_id, version_seq).
  • unit_version.lifecycle_status exists.
  • Missing on UV: review_state, base_version_ref, review_actor, merged_at.

Functions

Existing:

  • fn_iu_create
  • fn_iu_create_plan
  • fn_iu_verify_invariants
  • fn_content_hash
  • fn_iu_gateway_write_guard

Missing:

  • no IU edit function;
  • no IU merge function;
  • no IU proposal function;
  • no IU version helper beyond create.

Gateway

  • Gateway is currently exact match:
    • marker key = app.canonical_writer
    • marker value = fn_iu_create
  • Allow-list is not implemented.
  • Before adding any second canonical writer (fn_iu_propose_edit, fn_iu_merge_edit, fn_iu_edit), gateway must be patched to allow-list.

Parent / child / multi-axis

  • All parent_or_container_ref values are currently NULL.
  • No sort/order column on IU.
  • identity_profile currently shallow: string keys only.
  • identity_profile has GIN index; content_profile does not.
  • universal_edges is rich: 25 columns, metadata/provenance JSONB, valid_time, weight.
  • Active edge types are UPPERCASE: USES, BELONGS_TO, CONTAINS.
  • Prompt queries 6.5/6.6 used lowercase filters and returned 0; this is a prompt caveat, not missing data.

GPT decision after inspection

Choose Model C/D, not Model A/B for Phase 1 implementation.

Why not Model A/B now?

Model A/B stores proposed edits in unit_version.

Problems:

  • version_seq is NOT NULL and unique per unit.
  • Model A burns sequence numbers for rejected proposals.
  • Model B would require making version_seq nullable or partial unique constraints.
  • fn_iu_verify_invariants currently needs to stay simple and stable around merged/current version.
  • Pack 23 should not destabilize the verified Pack 22 create/gateway path.

Preferred model

Model D hybrid: separate unit_proposal table for review/proposals; merge creates a real unit_version row.

Operationally:

  • Proposal table = PR/change request/branch tip.
  • unit_version = merged commit history only.
  • fn_iu_propose_edit writes proposal, not UV.
  • fn_iu_merge_edit validates proposal, computes next version_seq, inserts UV, updates IU anchors.
  • fn_iu_edit wrapper = propose + merge only when policy allows auto-merge.

This is standard, scalable, and avoids version_seq ambiguity.

GPT decisions for near-term design

  1. Gateway marker: use explicit allow-list, not prefix.

    • Add config like iu_create.gateway.allowed_marker_values = fn_iu_create,fn_iu_propose_edit,fn_iu_merge_edit,fn_iu_edit.
    • Patch guard to test membership.

  2. Proposal model: separate proposal table for Phase 1.

    • Name candidate: unit_proposal.
    • It may mirror UV fields but must include base/current references and review state.

  3. unit_version remains merged-truth-only.

    • Do not store rejected/proposed branch tips in unit_version in Phase 1.

  4. Parent/child ordering: do not choose blindly.

    • For immediate conversion pilot, JSONB sort_order may be used.
    • For long-term render hot path, core column or edge metadata must be designed.
    • Opus should recommend one in Pack 23-P3 design, with migration path.

  5. Multi-axis traceability: use universal_edges, not parent/child.

    • Domain axis is typed relation graph: LAW → DESIGN → PROCEDURE → CODE → TEST → REPORT.
    • Parent/child is only structural containment for documents/workflows.

Directive to Opus: next deliverable

Create a design pack, not execution prompt:

knowledge/dev/laws/dieu44-trien-khai/design/23-p3-iu-proposal-merge-implementation-design.md

Do not implement runtime yet.

Required sections

§1. Current runtime truth

Summarize 23-P2 evidence:

  • current schema;
  • version_seq constraints;
  • missing proposal funcs;
  • gateway exact-match;
  • edge/multi-axis facts;
  • greenfield state.

§2. Accepted model

Design Model D hybrid:

  • unit_proposal table for proposed edits;
  • unit_version only for merged commits;
  • merge creates UV and updates IU HEAD/anchors;
  • wrapper supports immediate single-Agent UX.

Include why A/B are rejected for Phase 1.

§3. Proposed unit_proposal schema

Design fields at conceptual level:

  • id uuid
  • unit_id uuid
  • canonical_address text or resolved FK only;
  • base_version_ref uuid
  • base_version_seq int
  • base_content_hash text
  • proposed_title text or title delta strategy;
  • proposed_body text
  • proposed_content_hash text
  • proposal_status text (draft/proposed/merged/rejected/superseded)
  • proposed_by text, proposed_at timestamptz
  • reviewed_by text, reviewed_at timestamptz, review_note text
  • reason text
  • metadata jsonb

Also propose indexes/constraints but mark as design only.

§4. Function set

Design:

  • fn_iu_propose_edit_plan(...)
  • fn_iu_propose_edit(...)
  • fn_iu_merge_edit(...)
  • fn_iu_reject_edit(...) (can be Phase 2 if needed)
  • fn_iu_edit(...) wrapper

Define responsibilities and return JSON statuses.

§5. Merge algorithm

Must include:

  • lock strategy on IU/canonical address;
  • base version check;
  • conflict classification if HEAD changed since proposal base;
  • no-change detection;
  • next version_seq = max(version_seq)+1 under lock;
  • insert unit_version;
  • update information_unit.version_anchor_ref / content_anchor_ref;
  • mark proposal merged;
  • invariant verify;
  • rollback on fail.

§6. Gateway allow-list patch design

Design patch to fn_iu_gateway_write_guard:

  • preserve current create path;
  • read allowed values from dot_config;
  • exact membership, not prefix;
  • failure message still points to README;
  • rollback/cleanup plan for enforcement patch.

§7. Parent/child + ordering decision

Recommend a Phase 1 ordering primitive:

  • JSONB identity_profile.sort_order; or
  • core column; or
  • universal_edges.metadata.order.

Make recommendation with scale/migration rationale.

§8. Multi-axis traceability design hook

State explicitly:

  • document/workflow containment uses parent/child;
  • domain traceability uses universal_edges typed relations;
  • edge types are UPPERCASE in runtime;
  • future relation vocab should include GOVERNS, IMPLEMENTS, TESTS, DERIVED_FROM, DEPENDS_ON, SUPERSEDES, etc.

No implementation yet.

§9. Phase plan

Recommend split into execution packs:

  • P3A: gateway allow-list patch;
  • P3B: create unit_proposal schema + helper plan/propose functions;
  • P3C: merge function + wrapper + tests;
  • P3D: first real IU parent/child conversion pilot.

Or propose a different split, but justify.

§10. Risks / open decisions

At least:

  • DDL scope for unit_proposal;
  • whether title lives in IU identity_profile or UV/content;
  • sort_order primitive;
  • review policy source;
  • no 3-way merge in Phase 1;
  • no vector update yet;
  • no role separation yet.

Hard boundaries

  • No DDL/DML.
  • No runtime mutation.
  • No function/trigger changes.
  • No vector mutation.
  • No cleanup.
  • No Pack 2C.

Expected Opus response

Opus should create the design pack at the path above and stop for GPT/User review.

Do not write execution prompt yet.

Summary

Pack 23 should now move from inspection to design of a separate proposal/merge model. The goal is to keep unit_version as clean merged history and introduce unit_proposal as the Git-like PR layer. This protects scale, multi-agent editing, and future text-as-code workflows while still allowing a Phase 1 fn_iu_edit wrapper for fast single-agent use.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-23-p2-inspection-results-handoff-to-opus-2026-05-06.md