KB-26A2

Handoff S188 → Next — P10B In Progress

11 min read Revision 1
handoffs188p10bd28tacmvpnext-session

Handoff S188 → Next — P10B In Progress

Date: 2026-04-29
Context: TAC / Text-as-Code MVP validation
Current phase: P10B — multi-document validation
VPS: source of truth for code/runtime execution. KB is source of truth for promoted artifacts and reports.


1. One-sentence summary

We are validating the TAC pipeline: split legal/design documents into logical units → insert into PostgreSQL TAC tables → render back into normal human-readable markdown → prove 0 content drift.


2. User expectation / operating model

The User does not want to review technical internals. GPT/Opus must approve technical intermediate steps. User wants final visible result: a normal readable document reconstructed from ordered pieces.

Operating model:

  • User: sets direction and reviews visible outcome.
  • GPT: final technical gate / constitutional reviewer.
  • Opus: drafts prompts, reviews Agent reports, proposes next action.
  • Agent/Codex/Claude Code: executes on VPS or correct environment.

Important: do not ask User to choose technical risk. GPT/Opus decide and direct.


3. Constitutional / law constraints that mattered in S188

Use these as hard checks before every prompt:

  1. Zero Trust: if not certainly right, it is wrong.
  2. No hardcode: no manual section arrays, no Roman numeral case-dispatch, no section-specific renderer fallback.
  3. No /tmp cross-machine SSOT: /tmp is local workspace only.
  4. KB/repo SSOT for handoff artifacts: any artifact needed by another step or another machine must be promoted to KB or repo with manifest + read-back verification.
  5. VPS is SSOT for code/runtime execution: DB/Docker/Postgres work must run on VPS or include explicit machine identity guard.
  6. No direct manual SQL mutation of kb_documents: upload KB files through Agent Data / KB API only.
  7. No DDL / broad migration during P10B: only pilot inserts into TAC tables when authorized.
  8. Birth-gate compliance proof required before insert: do not merely list triggers; prove candidate data satisfies blocking gates.

Relevant Red Zone evidence: Đ43 context-pack Red Zones include no case-dispatch per section and no manual INSERT/UPDATE into kb_documents.


4. Key documents to read first in next session

Handoff / roadmap

  • knowledge/dev/laws/dieu38-trien-khai/tham-khao/handoff-s187-p10a-complete.md
  • knowledge/dev/laws/dieu38-trien-khai/tham-khao/s188-startup-prompt.md
  • This handoff: knowledge/dev/laws/dieu38-trien-khai/tham-khao/handoff-s188-p10b-in-progress.md

Decisions from GPT during S188

  • knowledge/dev/reports/gpt-decision-p10b-cross-machine-fail-option-b-2026-04-29.md
  • knowledge/dev/reports/gpt-decision-p10b-machine-routing-problem-option-b-regenerate-promote-vps-2026-04-29.md
  • knowledge/dev/reports/gpt-review-p10b-2b-fix-regen-promote-prompt-2026-04-29.md

P10B / D28 reports

  • knowledge/dev/laws/dieu38-trien-khai/reports/p10b-2a-d28-hash-r2-evidence-2026-04-29.md
  • knowledge/dev/laws/dieu38-trien-khai/reports/p10b-2b-d28-insert-package-2026-04-29.md
  • knowledge/dev/laws/dieu38-trien-khai/reports/p10b-2b-fix-d28-regen-2026-04-29.md
  • knowledge/dev/laws/dieu38-trien-khai/reports/p10b-2c-pf-d28-sql-inspection-2026-04-29.md
  • knowledge/dev/laws/dieu38-trien-khai/reports/p10b-2c-d28-execute-report-2026-04-29.md

Canonical D28 input already promoted

  • knowledge/dev/laws/dieu38-trien-khai/data/p10b-d28-candidate-units-r2.json

5. Completed status

P10A — Điều 35

PASS. 36 units inserted/rendered. Clean human-readable render achieved with 0 content drift except whitespace-only in earlier phase.

Key result: one large document round-tripped successfully.

P10B-1 — Điều 32

PASS. 23 units inserted/rendered. Final diff identical, 0 content drift.

Publication:

  • doc_code: DIEU-32
  • version: v1.1
  • pub_id: 6e08315c-7c70-470a-8a6a-32d7e2ae1b94
  • rows: 1 publication + 23 LU + 23 UV + 23 PM

P10B-2 — Điều 28

In progress. Segmentation/hash evidence PASS with 27 units.

Important state:

  • Source SHA: fa5ed5c1f6a6ab70f69f48e0bd3a2e4d822eb6b672a1c2b2313edd23f3277d7b
  • Candidate JSON SHA: e47775e33cc752656468edb287cca7b58539804678443b6c1b1dd03b165de8ad
  • Expected rows: 1 publication + 27 LU + 27 UV + 27 PM = 82

D28 first execute failed safely due to missing description column in UV INSERT. Auto-rollback preserved DB baseline. Fix path identified and partial package regenerated, but cross-machine /tmp routing caused repeated failures.


6. Critical lessons from S188

6.1 Hardcode vigilance

Agent once used hardcoded unit-key lists during hash extraction. Result was correct but pattern was wrong. Future prompts must explicitly require dynamic parsing or JSON-driven iteration.

6.2 Package PASS is not execute-ready

A package can be generated and still miss a birth-gate requirement. D28 failed on BG-UV-02 because description was missing in UV INSERT.

Permanent fix: every package generation must include a birth-gate compliance matrix.

6.3 Cross-machine failure is systemic

Failures repeated because prompts relied on /tmp paths across Mac/VPS boundaries. New rule:

Any artifact needed by a later step or another machine must be promoted to KB or repo SSOT with manifest + read-back verification.

6.4 Machine-specific prompts need Gate 0

If a step must run on VPS, prompt must start with Machine Identity Guard:

hostname -f || hostname
uname -a
docker context ls || true
docker ps --format "{{.Names}}" | grep postgres
docker exec postgres psql -U directus -d directus -tAc "SELECT current_database() || '/' || current_user;"

STOP if local Docker postgres is not accessible or DB identity is not directus/directus.


7. Current exact next step

Do not run PF-R2 or execute yet.

Next step is to run:

P10B-2B-FIX-REGEN-PROMOTE — Regenerate D28 FIX Package on VPS + Promote to KB

Purpose:

  1. Run on VPS only.
  2. Fetch canonical D28 candidate JSON and source from KB.
  3. Regenerate D28 fixed SQL package with description column.
  4. Build birth-gate compliance matrix.
  5. Upload all package artifacts to KB folder:

knowledge/dev/laws/dieu38-trien-khai/data/p10b-d28-fix-package/

  1. Create manifest.json with SHA, bytes, package_origin.
  2. Read back every uploaded file and verify exact match.
  3. STOP. No PF, no execute.

The last prompt drafted by Opus is good but must include two mandatory patches from GPT:

Patch P1 — KB API only

Add:

Upload files to KB using Agent Data / KB API only. Do not INSERT/UPDATE directly into kb_documents. Do not use SQL against KB tables.

Patch P2 — stronger Gate 0

Add:

hostname -f || hostname
uname -a
docker context ls || true
docker exec postgres psql -U directus -d directus -tAc "SELECT current_database() || '/' || current_user;"

PASS only if local Docker postgres accessible and DB identity is directus/directus. If uncertain, STOP.

Recommended manifest addition:

"package_origin": {
  "machine_hostname": "...",
  "working_dir": "/tmp/p10b-2b-fix-vps",
  "gate0_db_identity": "directus/directus"
}

8. Roadmap after REGEN-PROMOTE PASS

Step 1 — Patch PF-R2 to fetch from KB manifest

PF-R2 must no longer read /tmp/p10b-2b-fix. It must:

  1. Fetch manifest.json from KB package folder.
  2. Fetch all files listed in manifest.
  3. Verify SHA/length.
  4. Inspect package:
    • insert count = 1+27+27+27;
    • UV INSERT includes description;
    • dollar-quoting safe;
    • transaction structure safe;
    • no destructive SQL;
    • render/verify self-scoped.
  5. STOP.

Step 2 — Execute D28 R2 only after PF-R2 PASS

Execute prompt should:

  1. Fetch package from KB or use PF-verified local workdir.
  2. Fresh DB preflight: DB identity, schema, triggers, collision 0, backup/baseline counts.
  3. Create run-file by uncommenting -- COMMIT; only.
  4. Execute once with ON_ERROR_STOP=1.
  5. Verify row counts: pub=1, LU=27, UV=27, PM=27.
  6. Verify lifecycle: publication proposed, UV draft, review unreviewed.
  7. Render clean markdown.
  8. Diff with original; target 0 content drift.
  9. Upload deliverables + execute report.
  10. STOP.

Step 3 — P10B closeout

After D28 PASS:

Summarize three-document validation:

  • D35: large law, 36 units;
  • D32: small law, 23 units;
  • D28: Roman numeral + SQL/tables/footer, 27 units.

Confirm TAC MVP multi-document validation PASS if all show 0 content drift.

Step 4 — P10D design note (after P10B closeout)

Write product design note only, no implementation:

  • /knowledge/laws route reused;
  • left tree view, right reader;
  • clean reader mode by default;
  • permission-controlled unit-boundary overlay toggle for admins/reviewers;
  • debug mode optional;
  • auto numbering / reorder / split / merge architecture;
  • stable ID vs structural position vs human-facing numbering;
  • scale-ready label/relationship architecture: labels and parent-child relation labels may grow 5–10x over time;
  • object final layer = its own database enriched over time.

Step 5 — After User gives production requirements

Only after User supplies production requirements, design production-grade /knowledge/laws page and admin workflow. Current P10A/P10B are MVP/sample validation, not final production product.


9. What not to do next

  • Do not ask User to SSH manually.
  • Do not run PF-R2 from /tmp files.
  • Do not execute D28 before REGEN-PROMOTE and PF-R2 PASS.
  • Do not combine PF + execute after the recent BG-UV-02 failure.
  • Do not rebuild JSON from markdown reports.
  • Do not use direct SQL against KB documents.
  • Do not add schema/vocab like colophon during P10B.

10. Startup prompt for next session

Use this exact instruction to resume:

Read knowledge/dev/laws/dieu38-trien-khai/tham-khao/handoff-s188-p10b-in-progress.md. We are in P10B, D28 still in progress. Do not execute D28 yet. First patch and dispatch P10B-2B-FIX-REGEN-PROMOTE with mandatory KB API upload and strengthened Gate 0. After PASS, patch PF-R2 to fetch from KB manifest.


Handoff S188 → Next | TAC MVP / P10B in progress | 2026-04-29