GPT Review — 23-P3 rev3 + Text-as-Code Foundation Directive

Date: 2026-05-06
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/design/23-p3-iu-proposal-merge-implementation-design.md rev3
Additional user material: uploaded note THIẾU - Miếng thông tin.docx

Verdict

23-P3 rev3 is accepted as the edit workflow design, but rev4 is required before execution planning.

Rev3 correctly applies the eight requested patches and the PG-native editorial workflow is now technically coherent:

• draft → comment → apply → official version;
• comments append-only;
• unit_version remains official history;
• functions use SECURITY DEFINER policy;
• validation rules are explicit;
• no manual UPDATE as normal path;
• gateway markers limited to actual IU/UV writers.

However, the User explicitly asked to protect the broader Text-as-Code foundation: parent/child, multi-axis composition, metadata evolution, and future IT-standard layers such as impact analysis, build/render, test coverage, semantic lint, and release bundles.

Rev3 mentions some of these but not strongly enough as architectural guardrails. Add rev4 before execution so Pack 23 does not become only an edit workflow pack and forget the 10–20-floor foundation.

Accepted rev3 points

1. Editorial workflow framing is correct.
2. unit_edit_draft / unit_edit_comment naming is correct.
3. fn_iu_edit as wrapper is correct.
4. Gateway allow-list with only fn_iu_create and fn_iu_apply_edit_draft is correct if wrapper delegates writes.
5. UV lifecycle convention is correctly deferred to preflight.
6. Review note persisted as comment is correct.
7. Comments on stale/applied/withdrawn drafts are allowed; this is good for audit.
8. P3A gateway allow-list first is the right next execution step after rev4.

Required rev4 patches

P1 — Add a Text-as-Code Foundation Map section

Add a section near the end:

§13. Text-as-Code Foundation Map

It must distinguish:

Already present / usable now:

• unitization: information_unit;
• stable identity: canonical_address, birth/registry infrastructure;
• official versioning: unit_version;
• canonical create: fn_iu_create;
• wrong-door gateway: IU/UV trigger guard;
• registry/catalog foundation;
• graph foundation: universal_edges;
• governance workflow: GPT/User/Opus/Agent review reports;
• draft/comment/apply design from Pack 23.

Being added by Pack 23:

• editable draft layer;
• comment/audit layer;
• apply-to-official-version function;
• parent/child order primitive;
• policy hook for auto_apply / require_review.

Explicitly deferred, but design must not block:

• diff/patch display;
• 3-way merge;
• impact analysis;
• typed edge vocabulary;
• test coverage map;
• semantic lint;
• build/render pipeline;
• package/module system;
• release bundle;
• vector outbox/search integration;
• role separation.

This reflects the User’s uploaded note about which Text-as-Code components exist and which are missing.

P2 — Strengthen parent/child semantics

Rev3 says parent/child uses parent_or_container_ref + sort_order, but add the key semantic rule:

• parent/child is structural containment only;
• editing a child creates a new child version;
• parent does not automatically get a new version when a child changes;
• parent render is a build/view operation that assembles current child versions;
• if later we need immutable parent release snapshots, that belongs to release/bundle layer, not Phase 1 parent/child.

This prevents future confusion that every child edit must rewrite the parent.

P3 — Strengthen multi-axis traceability semantics

Add explicit model:

• document axis: parent document → child sections;
• workflow axis: process → steps;
• domain/professional axis: law → design → procedure → code → test → report;
• release/render axis: selected slices → built artifact.

State clearly:

• document/workflow axes use structural containment;
• domain axis uses universal_edges typed relations;
• release/render axis is not implemented yet;
• edge types should remain UPPERCASE to match runtime convention.

P4 — Add metadata evolution guardrails

Add rules:

• hot-path fields should be real columns or indexed expressions, not hidden JSONB forever;
• experimental/evolving metadata may live in JSONB;
• new metadata keys should later be governed by dot_config/schema registry;
• no function should hardcode a closed profile-field list unless that list is discovered from governance metadata;
• content_profile GIN index is deferred until it becomes a query axis.

P5 — Add Agent interface principle

Add a short section:

§14. Agent UX / Natural Operation Principle

State that Agents should only need these simple operations:

• create/read current IU;
• create draft;
• comment draft;
• apply draft;
• list draft history/comments;
• render/assemble later.

Agents must not handle:

• version_seq;
• anchor updates;
• content_hash;
• gateway marker;
• birth registry;
• direct table writes.

This is the “AI cứ vào sửa tự nhiên” requirement.

P6 — Add future pack linkage

Add a future roadmap section after the phase plan:

• P3A gateway allow-list;
• P3B schema;
• P3C functions;
• P3D first real edit pilot;
• P3E parent/child render pilot;
• P4 Multi-Axis Traceability Pack;
• P5 Build/Render/Release Bundle Pack;
• P6 Semantic Lint / Impact Analysis Pack.

Only P3A–P3D are near-term. Others are foundation hooks, not immediate execution.

P7 — Update risk table

Add risks:

• overusing JSONB without governance;
• parent/child confused with domain traceability;
• release snapshots not modeled yet;
• comments growing without retention;
• no impact analysis yet;
• no semantic lint/test coverage map yet.

Mark all as deferred, not blockers for Phase 1.

Directive to Opus

Patch rev4:

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

Apply P1–P7. Keep the editorial workflow design unchanged. Do not open implementation yet. Do not create execution prompt yet.

After rev4

If rev4 only adds these foundation sections without changing the execution design, GPT/User can approve P3A execution design next:

• P3A Gateway allow-list patch design/prompt.

Hard boundaries

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

Summary

Rev3 is good for the immediate edit workflow. Rev4 should make the broader Text-as-Code foundation explicit so the system can grow from editable slices to parent/child rendering, domain traceability, impact analysis, semantic lint, and release bundles without redesigning the core.