GPT Directive to Opus — P3D IU Text-as-Code Requirements First Pass
GPT Directive to Opus — P3D IU Text-as-Code Requirements First Pass
Date: 2026-05-10 Issuer: GPT-5.5 Thinking / Incomex Hội đồng AI Receiver: Opus new session Workstream: P3D_INFORMATION_UNIT_TEXT_AS_CODE_RESUME Mode: REQUIREMENTS/SPEC FIRST — no implementation
0. Executive instruction
Opus, do not start by coding, creating vector tables, creating parent-child tables, modifying Nuxt, or re-opening event_outbox UI. Your first job is to produce a strong requirements/spec document and implementation roadmap for the Information Unit / Text-as-Code subsystem.
The User’s strategic goal: build an industry-grade text-as-code foundation as infrastructure for later laws, processes, knowledge, agent context, traceability, testing, build/render, vectors, metadata enrichment, and event emission.
GPT is directing. Opus executes the analysis/spec drafting. Claude Code/Codex may later be dispatched for fast inspection or implementation, but not in this first requirements pass.
1. Required reading — narrow scope, no wandering
Read these documents first:
knowledge/dev/laws/dieu44-trien-khai/handoffs/handoff-p3d-information-unit-text-as-code-resume-after-nuxt-notification-2026-05-10.md
knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-information-unit-text-as-code-resume-requirements-prompt.md
knowledge/dev/laws/dieu44-trien-khai/design/04-information-unit-profile-schema.md
knowledge/dev/laws/dieu44-trien-khai/design/22-p3-iu-creation-gateway-scope.md
knowledge/dev/laws/dieu38-trien-khai/P5-schema-draft-v0-2.md
knowledge/dev/laws/dieu38-trien-khai/tham-khao/p7a-segmentation-reference-76-units.md
registries/meta_catalog/CAT-130
knowledge/dev/laws/dieu44-trien-khai/design/23-p3d4c0x-universal-event-outbox-notification-architecture.md
knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-p3d4c2x-filter-pass-and-iu-filter-deferred-2026-05-10.md
Read the uploaded file if available in your session:
THIẾU - Miếng thông tin .docx
Key message from the user note: text-as-code is a bundle of established IT techniques. Current system already has unitization, identity, versioning, schema validation, registries, graph foundation, health checks, tooling, migration, and review governance. Missing/weak items include Git-like diff/patch/merge/revert/blame, PR workflow, test coverage per unit, dependency impact analysis, build/render pipeline, package/module system, typed relationship contract, semantic linting, merge/conflict resolution, and release/version bundles.
2. Hard boundaries
Do not perform:
- DB mutation.
- schema DDL.
- trigger/function/index/permission change.
- vector table/chunk table creation.
- parent-child table creation.
- Nuxt code.
- table_registry mutation.
- event_outbox permission/filter change.
- production deploy/restart.
- IU UI creation.
This pass is requirements and roadmap only.
3. Deliverables
Create exactly these two KB documents:
knowledge/dev/laws/dieu44-trien-khai/requirements/p3d-information-unit-text-as-code-requirements-spec.md
knowledge/dev/laws/dieu44-trien-khai/reports/p3d-information-unit-text-as-code-requirements-first-pass-report.md
4. Required spec structure
The requirements/spec must include:
A. Strategic purpose
Information Unit is the canonical text-as-code substrate for laws, designs, processes, prompts, reports, tests, agent context packs, release artifacts, knowledge, and metadata. It is not a one-off document note system, vector-only feature, or UI board.
B. Current foundation already present
Evidence-backed summary of: unitization, stable identity/canonical_address, unit_version/lifecycle, schema validation/gates, registries/catalogs, universal_edges/context graph, health checks, DOT/tools/migration packs, governance review workflow, Đ38 segmentation examples.
C. Missing or weak industry text-as-code capabilities
Define requirements for: Git-like diff/patch/hunks, merge/conflict, revert/rollback/blame, PR/change-request workflow, test coverage per unit, dependency impact analysis, build/render pipeline, package/module system, typed relationship contract, semantic linting, release/version bundle, metadata enrichment, vector boundary/versioning, IU event emission.
D. Canonical IU contract
Minimum concepts:
unit_id
canonical_address
unit_type
unit_domain / specialty
owner
lifecycle_status
current_version_id
content/body
content_hash
source/provenance
created_by / updated_by / reviewed_by
created_at / updated_at / reviewed_at
metadata profile
Definition: a unit boundary is the smallest governed text object that can be independently addressed, versioned, diffed, reviewed, traced, vectorized, tested, and assembled.
E. Version/diff/patch requirements
Define version identity, lineage, diff A→B, patch hunk, apply patch, merge conflict, revert, blame/change attribution, version bundle. Acceptance criteria only; no table design yet.
F. Parent-child / containment requirements
Define parent unit, child unit, ordered children, containment edge, cycle prevention, assembly rule, inheritance boundaries. Child has its own identity. Parent build/render includes children but does not destroy child boundaries. Vector must remain per unit/version.
G. Vector boundary requirements
Non-negotiable rule:
One vector chunk belongs to exactly one Information Unit version.
No vector chunk may contain content from two different units.
Future vector metadata should include unit_id, unit_version_id/version_seq, canonical_address, chunk_seq, source_text_range inside the unit only, chunk_hash, embedding_model, embedding_model_version, embedding_created_at, vector_sync_status. Vectorization must be reproducible and auditable.
H. Multi-axis traceability and typed edges
Define typed relationship needs: CONTAINS, PARENT_OF, CHILD_OF, GOVERNS, IMPLEMENTS, TESTS, DERIVED_FROM, DEPENDS_ON, SUPERSEDES, VECTOR_OF, ENRICHES_METADATA, BUILDS_TO, EMITS_EVENT, COVERS, AFFECTS. universal_edges exists, but this pass only defines relationship contract and acceptance criteria.
I. Metadata enrichment requirements
Define extracted topics, entities, laws referenced, domain/specialty, owner suggestions, dependencies, lifecycle hints, confidence score, source/model/time, human review status, reversibility, change log. Enrichment must not silently overwrite authoritative metadata.
J. Testing and semantic linting
Define future checks: unit boundary valid; required metadata present; child cycle absent; vector chunk does not cross boundary; edge direction valid; law/design/process contradiction flagged; process approval step present where required; unit has tests or explicit exemption; release bundle coverage complete.
K. Build/render/release requirements
Define complete document, process document, traceability matrix, agent context pack, release bundle, notification/event pack. Built artifacts must preserve provenance and version identity.
L. IU event emission requirements
Define future governed events:
event_domain='information_unit'
event_subject_table='information_unit' or governed equivalent
canonical_address='information_unit://<id-or-code>'
event_type='iu.created' | 'iu.updated' | 'iu.reviewed' | 'iu.vectorized' | 'iu.enriched' | 'iu.built' | 'iu.released'
This is why event_outbox can later show filter “Thông tin”.
M. Pack roadmap
Propose packs in this order:
- IU Canonical Unit Contract Pack.
- IU Parent-Child / Containment Contract Pack.
- IU Multi-Axis Traceability / Typed Edge Pack.
- IU Diff/Patch/Merge/Revert Pack.
- IU Test Coverage + Semantic Lint Pack.
- IU Build/Render/Release Bundle Pack.
- IU Vector Boundary Pack.
- IU Metadata Enrichment Pack.
- IU Event Emission Pack.
- IU Assembly by Specialty Pack.
- IU UI/Filter follow-up under Điều 28 only after data/events exist.
For each pack include purpose, inputs, outputs, non-goals, risks, acceptance criteria, suggested executor.
Suggested executor convention: Opus for architecture/spec/prompt/review design; Claude Code/Codex for fast DB/source inspection, implementation, tests, reports under explicit prompt; GPT for council review, zero-trust validation, final directive.
N. Open questions / evidence gaps
List unresolved issues clearly. Do not invent answers where KB evidence is absent.
5. Search budget
Allowed targeted searches only:
information_unit canonical_address unit_version lifecycle_status fn_iu_create fn_iu_apply_edit_draft
Điều 38 text as code schema unit publication metadata segmentation
universal_edges Điều 43 context graph typed edge
P3D event_outbox information_unit event_domain
Do not explore unrelated Nuxt, UI, Hermes, notification board, or generic docs.
6. Final response expected from Opus
Return only:
- Path of requirements/spec created.
- Path of first-pass report created.
- 10-bullet executive summary.
- Pack roadmap summary.
- Confirmation that no DB/Nuxt/vector/UI implementation was performed.
- Open questions requiring GPT/User decision.
7. Reminder
The goal is not one feature. The goal is to create the foundation that lets Incomex treat text like code: versioned, diffable, reviewable, testable, traceable, buildable, releasable, searchable, vectorizable, and governable.