GPT Review — 23-P1 Design rev2 and 23-P2 Inspection Directive

Date: 2026-05-06
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/design/23-p1-iu-text-as-code-edit-merge-design.md rev2

Verdict

23-P1 design rev2 PASS.

Opus applied the 8 requested corrections and preserved the important phased principle:

Design for long-term text-as-code proposal/merge, implement Phase 1 minimum usable workflow.

No further design patch is needed before P2 inspection.

Accepted decisions

1. Core model: proposal/merge, not direct overwrite.
2. Phase 1 UX: fn_iu_edit may be a convenience wrapper over propose + merge.
3. Marker: explicit allow-list, not prefix fn_iu_%.
4. Version semantics: compare proposal-consuming version_seq vs merge-only version_seq after runtime inspection.
5. Parent/child: needed now; Phase 1 may use JSONB sort_order but keep migration path to core column/edge metadata.
6. Policy hook: auto-merge only when policy permits.
7. Next step: read-only runtime inspection, not implementation.

Minor caution for next phase

During 23-P2 inspection, pay special attention to these two risks:

• If unit_version.version_seq is NOT NULL + unique per unit, proposed UV as branch tip may require either sequence-consuming semantics or separate proposal table.
• If fn_iu_verify_invariants treats multiple UVs as invalid, unit_version = proposal may not be viable without changing invariant semantics.

Next step: create 23-P2 read-only inspection prompt

Opus should now create a compact read-only inspection prompt at:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p2-iu-edit-merge-runtime-inspection-prompt.md

Report path:

knowledge/dev/laws/dieu44-trien-khai/reports/23-p2-iu-edit-merge-runtime-inspection-report.md

Do not dispatch after writing; return for GPT/User review.

Required 23-P2 inspection scope

§1. Table schema and constraints

Inspect:

• information_unit columns, defaults, nullability, constraints, indexes;
• unit_version columns, defaults, nullability, constraints, indexes;
• version_seq nullability and uniqueness;
• anchor columns on IU: version_anchor_ref, content_anchor_ref, any current/version fields;
• whether unit_version.lifecycle_status, base_version_ref, review/audit columns exist.

§2. Current functions / behavior

Inspect source/metadata of:

• fn_iu_create;
• fn_iu_create_plan;
• fn_iu_verify_invariants;
• fn_content_hash;
• fn_iu_gateway_write_guard;
• any functions like %edit%, %merge%, %version%.

Questions:

• How does create assign version_seq?
• Which fields does invariant verify inspect?
• Does invariant tolerate multiple UV rows?
• Does gateway use exact marker or allow-list already?

§3. Existing data shape

Read-only counts/sample:

• IU count;
• UV count;
• UV per IU distribution;
• version_seq distribution;
• lifecycle/status fields if any;
• current pilot rows from Pack 22/P3.

No mutation.

§4. Parent/child/order evidence

Inspect:

• parent_or_container_ref use;
• identity_profile keys present in pilot IUs;
• any sort/order fields;
• universal_edges columns and whether edge metadata can store order;
• existing CONTAINS/BELONGS_TO style edge types if any.

§5. Proposal model feasibility decision

Agent must classify feasibility of:

A. unit_version carries proposed versions and consumes version_seq.
B. unit_version carries proposed versions but version_seq assigned only on merge.
C. Separate proposal table; merge creates real unit_version.
D. Hybrid.

For each, report blockers/risks.

§6. Gateway allow-list patch feasibility

Inspect:

• current dot_config keys;
• current guard source exact check;
• safest way to add iu_create.gateway.allowed_marker_values;
• whether guard can be patched to allow-list without breaking current create.

No patch yet.

§7. Recommended Pack 23-P3 plan

Based on evidence, recommend one next path:

• execution pack for minimal schema/function patch; or
• additional design if blockers found.

Prompt hardening requirements

• READ-ONLY only.
• No DDL/DML.
• No function/trigger changes.
• No vector mutation.
• No cleanup.
• Use ON_ERROR_STOP=1.
• Capture query errors and mark report PARTIAL if any core query fails.
• Scale-safe sampling if counts grow unexpectedly.

Expected Opus response

Create the P2 inspection prompt and stop.

Summary

Design rev2 is accepted. We now need runtime evidence to decide whether proposals can live in unit_version or require a separate proposal object. This is the last evidence step before planning implementation.