P3D_INFORMATION_UNIT_TEXT_AS_CODE_RESUME_REQUIREMENTS_PROMPT

Date: 2026-05-10
Author: GPT-5.5 Thinking / Incomex Hội đồng AI
Purpose: Resume Information Unit / Text-as-Code work after Nuxt/event_outbox notification detour by drafting requirements/spec first.
Status: READY_FOR_AGENT_OR_OPUS
Mutation policy: READ-ONLY for DB/Nuxt. KB write allowed only for final requirements/spec/report documents.

0. Context checkpoint

Read first:

knowledge/dev/laws/dieu44-trien-khai/handoffs/handoff-p3d-information-unit-text-as-code-resume-after-nuxt-notification-2026-05-10.md

Notification/Nuxt checkpoint is resolved enough:

D28_generated_map_chain=PASS
Nuxt_public_event_outbox=PASS
event_outbox_global_monitor=PASS
filter_ui_config=PASS
information_filter=DEFERRED_UNTIL_IU_EVENTS_EXIST
IU_specific_notification_board=NOT_DONE

Do not reopen Nuxt/event_outbox work unless there is a concrete blocker to the Information Unit requirements.

1. Mission

Produce a consolidated requirements/spec document for the Information Unit / “miếng thông tin” subsystem as a serious industry-standard text-as-code foundation.

This prompt must not implement schema, vectors, UI, or Nuxt code. The output is requirements and pack roadmap only.

Recommended output path:

knowledge/dev/laws/dieu44-trien-khai/requirements/p3d-information-unit-text-as-code-requirements-spec.md

Also produce a short execution/readiness report at:

knowledge/dev/laws/dieu44-trien-khai/reports/p3d-information-unit-text-as-code-requirements-report.md

2. Required source reading

Read these KB documents before drafting:

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/reviews/gpt-review-p3d4c2x-filter-pass-and-iu-filter-deferred-2026-05-10.md
knowledge/dev/laws/dieu44-trien-khai/reports/p3d4c2x-event-outbox-filter-ui-config-patch-report.md
knowledge/dev/laws/dieu44-trien-khai/reports/p3d4c2w-event-outbox-label-clarify-report.md
knowledge/dev/laws/dieu44-trien-khai/reports/d28-generated-map-refresh-pack-report.md
knowledge/dev/laws/dieu44-trien-khai/reports/p3d4c2u-resume-notification-display-report.md

Search KB for at least:

information_unit text_as_code canonical_address unit_version parent child vector metadata enrichment traceability universal_edges
fn_iu_create fn_iu_apply_edit_draft unit_edit_draft unit_version lifecycle_status
Điều 28 table_registry DirectusTable generated map
Điều 38 text as code unit publication metadata
Điều 43 context graph universal_edges
Điều 44 P3D information unit

If the uploaded user file is available, read it:

THIẾU - Miếng thông tin .docx

If it is unavailable, state that it was not accessible and proceed from KB/handoff evidence only.

3. Non-negotiable guardrails

No DB mutation.
Do not create/alter/drop tables, functions, triggers, indexes, policies, permissions, registry rows, or sample data.
No Nuxt/UI implementation.
Do not change Nuxt code, generated map, DirectusTable templates, deployments, or filters. UI is deferred.
No vector implementation yet.
Do not create vector tables/chunk tables or run vectorization. Define requirements only.
No parent-child table implementation yet.
Define containment/relationship rules only.
No event_outbox permission change.
Do not modify permission #1483 or event_outbox exposure.
Evidence first.
Every architectural decision must cite relevant KB documents/laws/anchors. If evidence is missing, mark as requirement gap rather than pretending it exists.
Constitutional order.
Align with Hiến pháp Hạ tầng, Data Flow & Connectivity Law, Điều 28 generated/template governance, Điều 38 text-as-code direction, Điều 43 graph/context direction, and Điều 44 deployment governance.

4. Requirements sections to produce

The requirements spec must include at least the following sections.

4.1 Scope and purpose

Define what the Information Unit subsystem is and is not.

It is the canonical substrate for laws, designs, processes, reports, prompts, tests, context packs, and other text/governance artifacts.

It is not a one-off UI board, not a vector-only feature, and not a loose document note system.

4.2 IU canonical unit contract

Specify required concepts:

unit boundary
stable identity
canonical_address
entity_code / code where applicable
unit_version
lifecycle_status
owner/domain metadata
source/provenance
content hash / integrity signal
created/updated/reviewed timestamps

Define what makes one “miếng thông tin” indivisible for editing, versioning, vectorization, and traceability.

4.3 Versioning, diff, patch, merge, revert

Define Git-like requirements:

diff A→B
patch hunks
apply patch
merge conflict detection
revert to previous version
blame / change attribution
version bundle

Clarify what already exists in IU/UV and what remains missing.

4.4 Parent-child / containment contract

Define requirements for:

parent unit
child unit
ordered children
containment validity
inheritance boundaries
section/subsection hierarchy
process step hierarchy
law/article/clause hierarchy

Rules:

A child must have its own stable identity.
A child must not disappear into the parent during vectorization.
Parent assembly must be a build/render result, not a destruction of child boundaries.
Need cycle prevention.
Need explicit edge semantics, not ambiguous free-text linkage.

4.5 Vector boundary contract

Define the non-negotiable vector rule:

One vector chunk belongs to exactly one Information Unit version.
No vector chunk may contain content from two different units.

Required metadata on future vector chunks:

unit_id
unit_version_id or version_seq
canonical_address
chunk_seq
chunk_hash
embedding_model
embedding_created_at
vector_sync_status
source_text_range inside the unit boundary

Vectorization must be reproducible, auditable, and version-aware.

4.6 Multi-axis traceability and typed graph

Define typed relationships required for text-as-code:

CONTAINS
PARENT_OF / CHILD_OF
GOVERNS
IMPLEMENTS
TESTS
DERIVED_FROM
DEPENDS_ON
SUPERSEDES
VECTOR_OF
ENRICHES_METADATA
BUILDS_TO
EMITS_EVENT

Clarify how existing universal_edges may be used or extended only after design confirmation.

4.7 Metadata enrichment contract

Define enrichment requirements:

automatic extraction of domain, topic, entities, owners, related laws, dependencies, lifecycle hints
confidence score
source of enrichment
human review status
reversible enrichment
change log

Rules:

Enrichment must not silently overwrite authoritative metadata.
Enrichment must be traceable to agent/model/source/time.
Low-confidence enrichment must remain suggested metadata, not canonical metadata.

4.8 Assembly by specialty / domain

Define assembly requirements:

group by professional domain/chuyên môn
assemble packages/modules
render complete document/process/context pack
preserve unit boundaries
preserve traceability
support public/private API style module boundaries

UI must be deferred until IU contracts and data exist.

4.9 Test and semantic lint requirements

Define requirements for:

unit-level tests
schema/invariant tests
relationship linting
semantic contradiction checks
impact-analysis tests
coverage matrix: which tests cover which IU

Examples:

law says A but design implements B;
process misses approval step;
unit has no owner/domain;
vector chunk crosses unit boundary;
edge direction is invalid;
child relationship forms cycle.

4.10 Build/render/release pipeline

Define requirements for generating:

complete document
process document
traceability matrix
release bundle
agent context pack
notification/event pack

A built artifact must be derived from versioned units and preserve provenance.

4.11 Event emission requirement

Define IU event emission requirements so event_outbox can later filter “Thông tin”.

Future IU create/edit/apply/review/build/vectorize/enrich actions must emit governed events such as:

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'

This is requirements-only. Do not implement triggers now.

4.12 PR / review workflow for text changes

Define text-as-code workflow requirements:

change request
draft proposal
review comments
approval gate
merge/apply
rollback
report

Map current manual workflow:

User → GPT review → Opus design/prompt → Agent execution → report → GPT review

to a future governed PR-like workflow.

4.13 Pack roadmap

Propose implementation sequence, without executing it:

IU Canonical Unit Contract Pack
IU Parent-Child / Containment Contract Pack
IU Multi-Axis Traceability Pack
IU Diff/Patch/Merge/Revert Pack
IU Vector Boundary Pack
IU Metadata Enrichment Pack
IU Event Emission Pack
IU Test/Semantic Lint Pack
IU Build/Render/Release Bundle Pack
IU Assembly by Specialty Pack
UI/Filter follow-up under Điều 28 only after data/events exist

For each pack, include:

purpose
inputs
outputs
non-goals
required evidence
risks
acceptance criteria

5. Acceptance criteria

The final requirements/spec is acceptable only if:

It clearly separates requirements from implementation.
It cites KB evidence for current state and existing anchors.
It explicitly defers Nuxt/UI/vector implementation.
It defines the one-vector-one-unit boundary rule.
It defines parent-child containment without applying schema.
It defines typed traceability requirements.
It defines metadata enrichment as reversible and traceable.
It defines event emission with event_domain='information_unit' as a future requirement.
It proposes a pack roadmap in the correct order.
It lists open questions/gaps where evidence is missing.

6. Expected final answer format

Return:

Path of requirements/spec created.
Path of report created.
Summary of major requirements.
Pack roadmap.
Explicit confirmation that no DB/Nuxt/vector/UI implementation was performed.
Open questions/gaps.

7. One-line intent

Stop solving small UI fragments. Rebuild Information Unit as a governed text-as-code substrate: unit boundary, versioning, diff/patch, parent-child, vector-per-unit, traceability, metadata enrichment, tests, build/render, and event emission.