KB-7BC2

GPT Directive to Opus — P3D IU Text-as-Code Requirements First Pass

10 min read Revision 1
directiveopusp3dinformation-unittext-as-coderequirements2026-05-10

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:

  1. DB mutation.
  2. schema DDL.
  3. trigger/function/index/permission change.
  4. vector table/chunk table creation.
  5. parent-child table creation.
  6. Nuxt code.
  7. table_registry mutation.
  8. event_outbox permission/filter change.
  9. production deploy/restart.
  10. 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:

  1. IU Canonical Unit Contract Pack.
  2. IU Parent-Child / Containment Contract Pack.
  3. IU Multi-Axis Traceability / Typed Edge Pack.
  4. IU Diff/Patch/Merge/Revert Pack.
  5. IU Test Coverage + Semantic Lint Pack.
  6. IU Build/Render/Release Bundle Pack.
  7. IU Vector Boundary Pack.
  8. IU Metadata Enrichment Pack.
  9. IU Event Emission Pack.
  10. IU Assembly by Specialty Pack.
  11. 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:

  1. Path of requirements/spec created.
  2. Path of first-pass report created.
  3. 10-bullet executive summary.
  4. Pack roadmap summary.
  5. Confirmation that no DB/Nuxt/vector/UI implementation was performed.
  6. 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.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/directives/gpt-directive-opus-p3d-iu-text-as-code-requirements-first-pass-2026-05-10.md