GPT Review — 23-P3 rev4 Existing Implementation Compatibility

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 rev4

Verdict

23-P3 rev4 is strong and directionally accepted. Rev5 required before execution planning.

Rev4 correctly adds the broader Text-as-Code foundation: parent/child, multi-axis composition, metadata evolution, Agent UX, future pack linkage, and risk table.

However, User reminded a critical implementation-governance rule:

We have already implemented part of Information Unit and part of the schema. Do not duplicate, redo, or create a second conflicting system.

Rev4 should add an explicit Existing Runtime / Compatibility / No-Duplicate Layer before any P3A/P3B execution planning.

Accepted rev4 additions

1. Foundation Map is accepted.
2. Parent/child semantics are accepted.
3. Multi-axis 4-track model is accepted.
4. Metadata evolution guardrails are accepted.
5. Agent UX / address-first principle is accepted.
6. Future pack linkage is accepted.
7. Risk table expansion is accepted.

Required rev5 patch

Add a new section:

§15. Existing Implementation Compatibility / No-Duplicate Rule

Required content

15.1 Current implemented assets that must not be duplicated

List at minimum:

• information_unit table;
• unit_version table;
• fn_iu_create;
• fn_iu_create_plan;
• fn_iu_verify_invariants;
• fn_content_hash;
• fn_iu_gateway_write_guard;
• IU/UV gateway triggers;
• birth_registry / birth trigger path;
• collection_registry / dot_config policy keys;
• universal_edges graph foundation;
• current pilot IU/UV rows.

Rule: Pack 23 must extend these, not replace them.

15.2 Execution preflight rule before every DDL/function pack

Before any P3A/P3B/P3C execution prompt, Agent must inspect and STOP if conflicts exist:

• table already exists with same or similar name;
• function already exists with same or conflicting signature;
• column already exists with incompatible type;
• dot_config key already exists with different semantics;
• trigger/function source already patched differently;
• existing constraints/indexes make proposed DDL unsafe.

15.3 No second edit system

Pack 23 must not create a parallel system with different names/semantics if an equivalent existing primitive is found.

If runtime already has equivalent draft/comment/edit tables/functions, Opus must reconcile rather than create new ones.

15.4 Compatibility with Pack 22 gateway

P3A must preserve:

• existing fn_iu_create behavior;
• existing wrong-door blocking;
• README guidance;
• fallback exact marker behavior if allow-list key is missing;
• no half-enforced state on failure.

15.5 Compatibility with current schema conventions

P3B/P3C must discover and follow:

• current unit_version.lifecycle_status convention from fn_iu_create;
• existing naming/casing conventions;
• current role/owner/grant pattern from Pack 22;
• current trigger order conventions (trg_aa_ prefix only where needed);
• current JSONB profile patterns.

15.6 Migration discipline

Because current IU data is greenfield but non-empty:

• do not cleanup pilot rows;
• do not rewrite existing IU/UV rows;
• DDL must be additive only in Phase 1;
• use CREATE, not CREATE OR REPLACE, unless patching an existing function is explicitly the objective;
• if patching, record source hash before/after and rollback path.

15.7 Text-as-Code layer mapping

Explicitly tie this to the uploaded note:

The system already has parts of text-as-code: unitization, identity, versioning, registry, validation, graph foundation, tooling, governance. Pack 23 adds only the missing editorial edit layer and must not duplicate existing identity/version/registry/gateway layers.

Directive to Opus

Patch rev5:

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

Apply §15 exactly as above, adapted to document style.

Do not change the core editorial workflow design unless needed for compatibility wording.

Do not create execution prompt yet.

After rev5

If rev5 only adds the compatibility/no-duplicate section, GPT/User can approve the design and move to P3A execution design/prompt:

• P3A gateway allow-list patch, with strict preflight and rollback.

Hard boundaries

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

Summary

Rev4 has the right long-term foundation. Rev5 must add an explicit no-duplicate/compatibility contract so Pack 23 extends what is already implemented instead of creating conflicting parallel systems.