GPT Review — 23-P0 Reconciliation and Next Directive

Date: 2026-05-06
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/reports/23-p0-iu-schema-return-history-reconciliation-report.md

Verdict

23-P0 PASS. Opus correctly identified the resume point.

We should resume the Information Unit / miếng thông tin work at Pack 23: canonical edit path + minimum usable slice workflow.

However, do not jump directly to implementation. The next step should be Pack 23-P1 design, not execution, because edit semantics are more sensitive than create semantics.

Accepted findings

1. Pack 22 supersedes old IU birth blocker

Accepted. Old DOT-119/IU birth-trigger roadmap is no longer the immediate blocker for IU schema work.

Current truth:

• fn_iu_create is canonical create path.
• Gateway is enforced.
• Birth fires automatically.
• Direct IU/UV writes are blocked.

DOT-119 can remain deferred tooling/governance, not the next step.

2. Pilot Round 1 evidence remains valid

Accepted. The old pilot evidence about token savings, slice edit value, boundary concerns, and MUP feasibility remains useful.

3. Gateway now blocks direct edit path

Accepted and important. This is not a bug; it is the expected consequence of gateway enforcement.

If edit is needed, it must go through a canonical function that sets the same marker and verifies invariants.

4. Pack 23 should be new, not patch old 09 directly

Accepted. The landscape changed enough that a new Pack 23 is cleaner. Old 09 should be treated as historical input.

Correction / refinement

Opus says “fn_iu_edit is blocker #1.” This is mostly correct, but define “edit” narrowly for Pack 23:

Pack 23 should implement canonical body/version edit only, not all CRUD.

Do not include delete, profile mutation, edge mutation, move/reparent, vector outbox, or render layer in Pack 23-P1 design. Those remain later packs.

Reason: version editing alone is already enough to resume “miếng thông tin” usefulness.

Key design questions for Pack 23-P1

Before implementation, Opus should design and answer:

1. Does edit create a new unit_version row every time, or no-op if body hash unchanged?
2. What fields may be edited in v1? Recommended: body/title only, maybe actor. Do not edit identity/profile/owner/unit_kind.
3. How to compute version_seq: max(existing)+1 under lock?
4. What lock is needed: advisory lock on canonical_address or row lock on IU?
5. How to update anchors: which exact IU columns point to current version?
6. How to preserve prior version history?
7. How to verify invariants after edit?
8. How to pass gateway guard: set app.canonical_writer='fn_iu_edit' or reuse marker value fn_iu_create?
9. Should gateway allow multiple canonical marker values, or should marker value be generalized from fn_iu_create to iu_canonical_writer?
10. Do current gateway guard and dot_config policy support that without patch?

Important marker issue

Current gateway guard likely checks dot_config:

• marker_key = app.canonical_writer
• marker_value = fn_iu_create

Therefore a future fn_iu_edit cannot simply set marker value fn_iu_edit unless the guard policy is changed to allow it.

Options:

A. fn_iu_edit sets app.canonical_writer='fn_iu_create' to pass current guard. Fast but semantically ugly. B. Patch gateway policy/guard to allow a set/list of marker values such as fn_iu_create,fn_iu_edit. More correct but changes Pack 22 guard. C. Generalize marker value to iu_canonical_writer, and patch both create + guard. Cleaner long-term but more invasive.

This is the first design decision for Pack 23-P1. Do not implement until chosen.

Recommended choice, preliminary

Prefer B: allow-list of canonical writer marker values if feasible with minimal guard patch.

Rationale:

• Keeps marker semantics honest: create uses fn_iu_create, edit uses fn_iu_edit.
• Avoids spoofing problem getting worse; still a speed bump only.
• Extends gateway for future fn_iu_delete without lying.
• Requires patching guard function and dot_config policy, so must be explicitly designed and tested.

If B is too much for Pack 23-P1, use A temporarily but record it as TD. Do not choose silently.

Next step directive to Opus

Create a Pack 23-P1 design note, not an execution prompt.

Path:

knowledge/dev/laws/dieu44-trien-khai/design/23-p1-iu-canonical-edit-design.md

Do not dispatch Agent runtime implementation yet.

Required design structure

§1. Current state / dependencies

Summarize:

• Pack 22 complete;
• gateway enforced;
• direct edits blocked;
• create works;
• birth works;
• vector/outbox deferred.

§2. Scope of Pack 23-P1

In scope:

• body/title edit through canonical function;
• new unit_version row;
• anchor update;
• invariant verify;
• dry-run plan function;
• gateway marker strategy.

Out of scope:

• delete;
• profile mutation;
• edge mutation;
• move/reparent;
• vector outbox;
• render layer;
• Directus UI/adapter;
• role separation;
• detector.

§3. Runtime schema evidence needed

List what P1 design needs to inspect before P2 implementation:

• information_unit columns;
• unit_version columns;
• anchors / current-version columns;
• existing fn_iu_create behavior for version_seq/content_hash;
• gateway guard function source;
• dot_config marker keys;
• constraints/indexes on unit_version;
• invariants function expectations.

§4. Proposed functions

Design:

• public.fn_iu_edit_plan(...) RETURNS jsonb
• public.fn_iu_edit(...) RETURNS jsonb

Recommended minimal signature:

fn_iu_edit(
  p_canonical_address text,
  p_title text DEFAULT NULL,
  p_body text DEFAULT NULL,
  p_actor text DEFAULT NULL,
  p_expected_version_seq integer DEFAULT NULL,
  p_reason text DEFAULT NULL
) RETURNS jsonb

But Opus should verify current schema and may adjust.

§5. Edit semantics

Must specify:

• title-only edit? body-only edit? both?
• unchanged hash = no-op or new version? Recommended: no-op with status='no_change'.
• optimistic concurrency using p_expected_version_seq.
• actor required or default.
• reason/audit handling if schema supports it.

§6. Versioning algorithm

Must define:

• lock strategy;
• find current version;
• compute next version_seq;
• compute hash via existing helper;
• insert new UV;
• update IU anchors;
• verify invariants;
• return JSON.

§7. Gateway marker strategy

Must compare A/B/C above and recommend one.

If B recommended, design dot_config change:

• e.g. iu_create.gateway.allowed_marker_values = fn_iu_create,fn_iu_edit

and guard function patch:

• allow current_setting(marker_key) to match any allowed value.

No runtime patch yet.

§8. Tests for future execution pack

List tests:

• edit existing pilot succeeds;
• no-change returns no_change and creates no UV;
• expected version mismatch blocked;
• direct UV insert/update still blocked;
• direct IU update still blocked;
• create still works after marker policy patch;
• invariants pass;
• history preserved.

§9. Risks / TDs

At least:

• marker allow-list patch risk;
• version_seq race;
• title storage field ambiguity;
• audit/reason field absence;
• no delete yet;
• vector not updated yet.

§10. Recommended next prompt

End with the exact next action:

• either P23-P2 runtime inspection prompt; or
• P23-P2 execution prompt if design evidence is sufficient.

Expected Opus response

Opus should create the design note and stop for GPT/User review.

Hard boundaries

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

Summary

We are back on the miếng thông tin track. Pack 23 should add the missing canonical edit path. The first unresolved design issue is gateway marker semantics: fn_iu_edit needs permission through the guard without lying or weakening the design unnecessarily.