KB-552D

GPT Directive to Opus — P3D Text-as-Code Step 1 Spec Recovery + Baseline Check

8 min read Revision 1
directiveopusp3dinformation-unittext-as-codespec-recoverybaseline2026-05-10

GPT Directive to Opus — P3D Text-as-Code Step 1: Spec Recovery + Baseline Check

Date: 2026-05-10 Issuer: GPT-5.5 Thinking / Incomex Hội đồng AI Receiver: Opus new/current session Workstream: P3D_INFORMATION_UNIT_TEXT_AS_CODE Mode: SPEC RECOVERY / BASELINE LOCK — no implementation Priority: HIGH

0. Mission

Opus, we now have agreement on the baseline SSOT. Your next task is not implementation. Your first task is to recover or recreate the P3D Information Unit / Text-as-Code requirements spec, using the agreed SSOT so we do not rebuild existing runtime.

Primary goal:

  1. Recover/upload the previously written ~50KB P3D requirements/spec if available.
  2. If recovery is impossible, re-author the spec from the agreed SSOT and evidence paths.
  3. Run or request a tiny runtime checkpoint to lock a few live facts for future agents.
  4. Produce a short report.

Do not dispatch any code implementation pack yet.


1. Mandatory baseline documents to read first

Read these in order:

knowledge/dev/laws/dieu44-trien-khai/ssot/p3d-iu-text-as-code-completed-state-and-remaining-work-2026-05-10.md
knowledge/dev/laws/dieu44-trien-khai/ssot/p3d-iu-text-as-code-discrepancy-resolution-addendum-2026-05-10.md
knowledge/dev/laws/dieu44-trien-khai/ssot/p3d-iu-text-as-code-final-baseline-patch-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/directives/gpt-directive-opus-p3d-iu-text-as-code-requirements-first-pass-2026-05-10.md

If the uploaded user note is available, use it:

THIẾU - Miếng thông tin .docx

2. Current agreed completed baseline — do not rebuild

Treat these as already done unless a live verification explicitly contradicts them:

  1. TAC cut/render proof: 3 publications / 86 units / round-trip 0 drift.
  2. TAC tables + render_order/publication assembly.
  3. Nuxt /knowledge/laws listing/reader.
  4. Pack 2A Description Policy Tiering CLOSED / CORE PASS.
  5. H11a/H11b description-policy split/amend present.
  6. Pack 22 IU create/gateway COMPLETE: fn_iu_create, fn_iu_create_plan, fn_iu_verify_invariants, gateway guard.
  7. P3B-FU invariant generalize PASS.
  8. Pack 23 P3B/P3C edit-save-policy runtime PASS through P3C4: unit_edit_draft, unit_edit_comment, safe edit functions, fn_iu_apply_edit_draft, fn_iu_edit, fn_iu_save, policy require_review.
  9. P3D1/P3D2 IU notification runtime PASS.
  10. Universal event_outbox display published/live/filter PASS.
  11. DOT-119 repair arc COMPLETE; v2 active; no-clobber behavior must be preserved.
  12. P38-XC / IU-0 / UMC design foundation exists.
  13. Đ38 P5 schema design exists.
  14. Đ43 v1.2 FINAL BAN HÀNH context foundation exists.
  15. Đ44 is the governing frame for this workstream.
  16. D28 generated-map infrastructure is completed enough for current registry display.

Hard rule: do not design or implement something that simply rebuilds the above.


3. Known remaining work — roadmap scope

The requirements/spec must cover the remaining work in this order:

  1. Recover/upload or re-author P3D requirements/spec.
  2. Lock completed-state matrix.
  3. Reconcile TAC logical_unit with native IU information_unit.
  4. Finalize IU canonical contract.
  5. Diff / patch / merge / conflict / revert / blame.
  6. PR/proposal workflow and Đ32 binding.
  7. Parent-child / containment.
  8. Typed edges + impact analysis.
  9. IU test coverage.
  10. Semantic lint.
  11. Build/render/release bundles.
  12. Vector boundary implementation/sync proof.
  13. Metadata enrichment governance.
  14. IU event emission into universal event_outbox using event_domain='information_unit'.
  15. UI/filter “Thông tin” only after real IU events exist.
  16. Governance housekeeping: verify/amend 9 S188 OR rules if desired and preserve DOT-119 v2/no-clobber hard boundary.

4. Primary deliverable

Create or restore:

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

Preferred path:

  • If previous 50KB spec can be recovered from old Opus session/context: upload it and mark as RECOVERED_FROM_PREVIOUS_OPUS_SESSION.
  • If not recoverable: re-author from SSOT and mark as REAUTHORED_FROM_VERIFIED_SSOT.

Do not invent evidence. Cite paths.

The spec must clearly separate:

  • already completed runtime;
  • existing design/contract;
  • prompt/pending items;
  • landmines/hard boundaries;
  • remaining implementation packs.

5. Companion report deliverable

Create:

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

Report must include:

phase_status=PASS | PARTIAL | BLOCKED
spec_mode=RECOVERED | REAUTHORED | BLOCKED
spec_path=<path>
ssot_docs_read=<list>
runtime_checkpoint_status=PASS | SKIPPED | BLOCKED
no_implementation_performed=true
open_questions=<list>
next_recommended_pack=<name>

This checkpoint is read-only and must not mutate anything. It is allowed to be delegated to Claude Code/Codex/Agent for speed.

Verify only these facts:

  1. tbl_event_outbox status is published in table_registry.
  2. /knowledge/registries/event_outbox returns live/routed status and DirectusTable/page is not fallback.
  3. DOT-119 installed script is v2/no-clobber; if md5 available, record it.
  4. fn_birth_registry_auto hash is unchanged from the latest known baseline if live query is available.
  5. fn_iu_save, fn_iu_apply_edit_draft, and fn_iu_create exist.

If direct runtime access is unavailable, mark checkpoint as SKIPPED_RUNTIME_ACCESS_UNAVAILABLE and rely on KB evidence. Do not block spec recovery because of missing runtime access.

Suggested agent prompt for checkpoint:

READ-ONLY VERIFY ONLY. No mutation.
Check:
1) table_registry row for tbl_event_outbox: status, page_url, collection.
2) HTTP HEAD/GET /knowledge/registries/event_outbox: status and no fallback text if body check is possible.
3) DOT-119 script path /opt/incomex/dot/bin/dot-birth-trigger-setup: md5/sha and grep count for 'CREATE OR REPLACE FUNCTION fn_birth_registry_auto' must be 0.
4) PostgreSQL hash/source sanity for fn_birth_registry_auto if accessible; do not alter function.
5) PostgreSQL existence of fn_iu_create, fn_iu_apply_edit_draft, fn_iu_save.
Return concise report only. No fixes.

7. Hard boundaries

  • No DB mutation.
  • No DDL.
  • No function/trigger/permission/index changes.
  • No Nuxt code.
  • No Directus table_registry mutation.
  • No event_outbox changes.
  • No vector table implementation.
  • No parent-child implementation.
  • No DOT-119 script execution or rewrite.
  • Do not run old DOT-119 v1.
  • Do not clobber fn_birth_registry_auto v2.
  • Do not direct-write information_unit or unit_version.
  • Do not add “Thông tin” filter yet.

8. Expected final response from Opus

Return only:

  1. Whether the spec was recovered or re-authored.
  2. Requirements/spec path.
  3. Companion report path.
  4. Runtime checkpoint status.
  5. 10-line summary of what the spec locks.
  6. Next recommended action.

9. Decision logic

If spec recovered:

  • GPT reviews recovered spec against SSOT.
  • If aligned, proceed to next pack: P3D_PACK_1_IU_CANONICAL_CONTRACT_AND_TAC_IU_RECONCILIATION.

If spec not recoverable:

  • Re-author spec from SSOT.
  • GPT reviews re-authored spec.
  • Then proceed to Pack 1.

The next implementation pack must not start until this Step 1 is PASS or explicitly waived by User/GPT.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/directives/gpt-directive-opus-p3d-text-as-code-step1-spec-recovery-and-baseline-check-2026-05-10.md