KB-2116

GPT Review — 23-P3A Edit Draft Approach Note

6 min read Revision 1
gpt-reviewpack-23p3aapproach-passedit-draftassembly-firstopus-directive

GPT Review — 23-P3A Edit Draft Approach Note

Date: 2026-05-06
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/design/23-p3a-iu-edit-draft-approach-note.md rev1

Verdict

Approach accepted. 23-P3A PASS as an approach note.

Opus correctly shifted the design away from a GitHub clone and toward a PG-native CMS/editorial workflow:

create draft → comment → approve/apply → official version.

This satisfies the User's goals: natural Agent editing, low prompt burden, review before official change, audit trail, and scalable path without overbuilding.

Accepted decisions

  1. Use editorial workflow framing, not GitHub clone framing.
  2. Use new domain tables instead of Directus internals.
  3. Use unit_edit_draft and unit_edit_comment naming.
  4. Draft is full replacement body in Phase 1, not patch/diff.
  5. Comments are append-only in Phase 1.
  6. unit_version remains official applied history only.
  7. fn_iu_edit may be convenience wrapper: draft + auto-apply when policy permits.
  8. Gateway allow-list only needs functions that write IU/UV.
  9. Parent/child containment and domain traceability remain separate axes.

GPT accepts Opus's three pushbacks

1. Mark other drafts stale_base, not superseded

Accepted.

Reason: stale_base is more truthful and keeps a future rebase path. In Phase 1, stale drafts are effectively closed because rebase is not implemented, but the status preserves information.

2. sort_order as core column

Accepted with one condition: implement only after execution preflight confirms no hidden runtime constraint issue.

Given current greenfield state, a real column is better than JSONB for render hot path.

3. Split schema and functions

Accepted.

Pack 22 showed this pattern works. Schema first, then inspect/review, then functions.

Required refinements before execution planning

Do not write execution prompt yet. First patch the old 23-P3 design into a coherent rev2 that incorporates the accepted P3A approach.

R1 — Keep one canonical design doc

Patch:

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

into rev2, renaming/framing it as:

23-P3 — IU Edit Draft / Comment / Apply Implementation Design

It should explicitly state that 23-P3A supersedes the older proposal/merge framing.

R2 — Replace proposal/merge terminology where possible

Use:

  • draft instead of proposal;
  • apply instead of merge;
  • official version instead of commit;
  • comment/review instead of PR discussion.

Technical note may mention Git/CMS inspiration, but not as implementation target.

R3 — Include accepted minimal schema

Rev2 must include design-only schema for:

  • unit_edit_draft;
  • unit_edit_comment;
  • information_unit.sort_order.

Use the P3A field list as baseline.

R4 — Include accepted function surface

Rev2 must include:

  • fn_iu_edit_plan(...);
  • fn_iu_create_edit_draft(...);
  • fn_iu_comment_edit_draft(...);
  • fn_iu_apply_edit_draft(...);
  • fn_iu_edit(...) wrapper.

No fn_iu_reject_edit in Phase 1 unless Opus re-justifies. Withdrawal/rejection can be future or simple status update later.

R5 — Clarify gateway markers

For Phase 1 allow-list, use:

  • fn_iu_create;
  • fn_iu_apply_edit_draft;
  • fn_iu_edit only if wrapper itself sets marker / writes IU/UV directly.

If wrapper only calls apply function, allow-list can be:

  • fn_iu_create;
  • fn_iu_apply_edit_draft.

Opus should choose one and state why.

R6 — Title edit handling

Rev2 must state:

  • draft_title nullable;
  • if present, apply updates information_unit.identity_profile.title in the same transaction;
  • if absent, keep current title.

R7 — Stale draft policy

Rev2 must state:

  • applying one draft marks other active drafts for the same IU/base as stale_base;
  • no rebase in Phase 1;
  • stale drafts are history and review material, not deletions.

R8 — Phase plan

Rev2 should split:

  • P3B: schema only (unit_edit_draft, unit_edit_comment, sort_order, relevant dot_config keys if needed);
  • P3C: functions + gateway allow-list if not isolated earlier;
  • P3D: first real IU edit pilot.

Opus may keep P3A gateway allow-list as a separate step if it believes it is safer. State the split clearly.

R9 — Comments as first-class requirement

Rev2 must include that comments are:

  • append-only in Phase 1;
  • author_ref required;
  • author_type required;
  • created_at required;
  • comment_kind required;
  • no edit/delete in Phase 1.

Directive to Opus

Patch the 23-P3 implementation design to rev2 using the accepted P3A approach.

Path:

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

Do not create execution prompt yet.

After rev2, stop for GPT/User review.

Hard boundaries

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

Summary

The approach is now settled: a PG-native editorial draft workflow, not a GitHub clone. Next step is to consolidate the design doc so implementation planning has one clear source of truth.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-23-p3a-edit-draft-approach-note-2026-05-06.md