Incomex AI Portal
KB-6E2F

GPT Approach Note — Pack 23 Simplified Draft/Approve Model

6 min read Revision 1
gpt-reviewpack-23approachassembly-firstdraft-approvepg-nativesimplification

GPT Approach Note — Pack 23 Simplified Draft/Approve Model

Date: 2026-05-06
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Context: User requests a balanced, maintainable approach rather than overbuilding a GitHub clone.

Verdict

The user is right. We should not clone GitHub. We should implement the business capability:

AI/Agent can open a slice, draft a replacement, sign/comment naturally, and another AI/User can approve it. The system applies the approved draft automatically.

This is closer to a draft/approve/publish workflow than a full Git/PR platform.

Balanced approach

Use proven industry patterns, but only the minimum that solves the workflow:

  • CMS editorial workflow: draft → review → published.
  • Database transaction + optimistic concurrency.
  • Append-only audit log / comments.
  • Approval gate.
  • Publish/merge creates official version.

Avoid implementing:

  • full branch model;
  • full Git diff engine;
  • three-way merge;
  • complicated threaded review UI;
  • external Git sync;
  • code-host clone.

Simplified model

1. Current official content

unit_version remains the official merged/published history.

2. Draft replacement

Create a separate table such as:

unit_edit_draft or unit_proposal

It stores:

  • target IU;
  • base version id/hash/seq;
  • replacement body;
  • optional replacement title;
  • author/agent;
  • timestamp;
  • status: draft/submitted/approved/rejected/applied/superseded;
  • reason/metadata.

This is not a Git branch. It is a draft replacement waiting for approval.

3. Comments

Add:

unit_edit_comment or unit_proposal_comment

It stores:

  • draft/proposal id;
  • author_ref;
  • author_type: user/agent/system;
  • comment body;
  • comment kind: general/review/change_request/approval/system;
  • created_at;
  • optional resolved state.

This satisfies “Agents cứ vào comment tự nhiên, để lại tên + time”.

4. Approve/apply

A canonical function applies the approved draft:

  • lock target IU;
  • verify base version still current;
  • if stale, return stale_base and ask for rebase/new draft;
  • compute content hash;
  • insert new unit_version with next version_seq;
  • update IU anchors;
  • mark draft applied;
  • verify invariants;
  • return result.

5. Convenience wrapper

For current Opus/GPT single-agent speed:

fn_iu_edit(...) can create draft + immediately apply when policy is auto_apply.

For protected IUs, it creates draft and waits for approval.

To avoid overengineering, use simpler names:

  • unit_edit_draft instead of unit_proposal, or keep unit_proposal but define it as “draft replacement”, not Git branch.
  • fn_iu_draft_edit
  • fn_iu_comment_edit
  • fn_iu_apply_edit
  • fn_iu_edit wrapper

If Opus prefers existing unit_proposal naming, acceptable, but wording should be simplified:

proposal = draft replacement / change request, not full PR clone.

Design decisions

D1 — Separate draft table remains correct

Do not put drafts into unit_version. Runtime evidence says version_seq is NOT NULL + UNIQUE per unit. Keeping drafts separate avoids version-number ambiguity and keeps official history clean.

D2 — Comments remain separate

Do not put comments in one review_note field. Need natural multi-agent discussion history.

D3 — No full merge engine in Phase 1

If the base is stale, return stale_base. The next Agent can draft again from current content. This is acceptable and standard for v1.

D4 — System must be easy for Agents

Agent interface should be simple:

  1. plan / read current;
  2. draft_edit with replacement body;
  3. comment if needed;
  4. apply_edit or approve.

Agents should not manually handle birth, anchors, version_seq, marker, or direct table writes.

Directive to Opus

Before patching 23-P3 further, adjust the approach:

  • Do not frame this as “building GitHub”.
  • Frame it as “PG-native draft/approve/apply workflow inspired by Git/CMS”.
  • Keep unit_version as official versions.
  • Keep a separate draft/proposal table.
  • Keep a separate comment table.
  • Keep comments append-only with author/time.
  • Keep Phase 1 simple: replacement-body draft, approve/apply, stale-base detection, no three-way merge.

Required patch to 23-P3 design

Patch:

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

Rev2 should say:

  1. The architecture is Draft/Approve/Apply, not full GitHub clone.
  2. unit_proposal may be renamed or described as unit_edit_draft.
  3. Add unit_proposal_comment / unit_edit_comment table as previously directed.
  4. Replace “merge” wording where useful with “apply approved draft”; keep “merge” as technical synonym if needed.
  5. Phase 1 has no branch/three-way merge/diff engine.
  6. Stale base = return stale_base; user/Agent creates new draft from current.
  7. fn_iu_edit wrapper may auto-apply only when policy permits.
  8. Protected IUs require explicit approval/comment before apply.

Summary

The correct Assembly-first path is not a GitHub clone. It is a PG-native editorial workflow: draft, comment, approve/apply, official version. It gives Agents a natural way to edit quickly while preserving review, authorship, timestamps, and immutable history.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-approach-note-pack23-simplified-draft-approve-model-2026-05-06.md