Implementation Package DOT v0.1 — Feasibility Plan (2026-06-09)
Implementation Package DOT v0.1 — Feasibility Plan
Date: 2026-06-09 · Status:
PLAN_DRAFT_READY· Production mutation: NO Author: Claude Code (T1) · Nature: independent feasibility plan, grounded in actual current state Central folder:knowledge/dev/laws/tool-kiem-thu/· This doc:planning/implementation-package-dot-v0-1-feasibility-plan-2026-06-09.mdDecision authority: User / GPT / Codex. This document is planning only — it does not implement, install, mutate production, write the new law, or claim a final decision.
0. One-paragraph summary
The FIX7 review loop is blocked by one repeating failure: T1 claims an executable/checkable artifact in prose, Codex tries to run it, the executable is missing or not runnable, and the review burns a round. This is the exact disease Constitution Article 14 (NT14) names. The system already owns almost every building block needed to stop this class of failure machine-side — it does not need a new parallel "Safety Kit." The right move is a small, subordinate verifier family ("Implementation Package DOT v0.1") that consumes Đ38 Text-as-Code, Điều 23 DOT Scanning, and Đ43 Context Pack, copies the P11E readiness contract verbatim, and is modeled on the already-runnable dot-iu-cutter Python dry-run verifier. Every implementation package must emit a machine-readable package_manifest.json; a small Python gate resolves each declared artifact, runs each declared command, recomputes its sha256, binds every prose claim to real executable evidence, and returns a fail-closed verdict using P11E's checker_run_status semantics. External engines (OPA/Conftest, Squawk) are deferred until the manifest schema is frozen, and remain engines — never authority. Existing framework status: PARTIAL (contracts + templates exist; the package-manifest envelope + the generic "run-the-declared-evidence" runner are missing).
1. What was inspected (actual current state)
All findings below were read this session from the live KB (agent-data MCP, which is the SSOT for knowledge/dev/…) and the local macOS filesystem (/Users/nmhuyen). No production object was touched.
1.1 Foundations confirmed to exist (with real paths)
| Foundation | Real location | What it is | Reuse role |
|---|---|---|---|
| Constitution v4.6.3 (rev 44) | knowledge/dev/laws/constitution.md |
Article 14 / NT14 = executable-evidence principle. Council note: NT14 forces "câu chữ → schema → query → trigger → executor → verify". | Authority source (the why) |
| Điều 23 DOT Scanning v2.x (frozen) | knowledge/dev/architecture/dot-scanning-system.md |
Tam quyền phân lập: LÀM (Builder, never self-certifies) / KIỂM TRA (Inspector = DOT) / GIÁM SÁT (Supervisor). Rule: "Không có DOT = không deploy." Findings sink = system_issues. |
Authority source + deploy gate to register into |
| Đ35 DOT Governance v5.2 FINAL | knowledge/dev/laws/dieu35-dot-governance-law.md |
Paired-DOT precedent; dot_registry, dot_config, ops-code; CAT-006 dot_tools (309 rows). |
Registry to consume |
| Đ38 Text-as-Code | knowledge/dev/laws/dieu38-trien-khai/ (HOW-TO-READ entrypoint, P5/P5b schema, P6 checker/DOT, P11E checker-proof, P9-G6 dry-run) |
Defines text/code/checkable-artifact principles + checker taxonomy + readiness contract. | Authority source + design patterns |
| Đ43 Context Pack v1.2 FINAL rev 6 | knowledge/dev/laws/dieu43-system-context-law.md + scripts knowledge/dev/dot/dot-context-pack-build.sh (rev 11) & dot-context-pack-verify.sh (rev 5) |
Active context / project_map / laws_index / dot_registry / red_zones. The two .sh are a real paired build+verify DOT with sha256 checksums + hardcode-ban; VPS mirror /opt/incomex/dot/bin/. |
Evidence/context source + script template |
| dot-iu-cutter dry-run verifier | KB knowledge/dev/laws/dieu44-trien-khai/… + local /Users/nmhuyen/iu-cutter-build/repo/iu-cutter/cutter_agent/dryrun.py |
A real, runnable, stdlib-only, import-isolated Python verifier: snapshot rehash precheck before parse, fail-closed ("BLOCKED is always preferred over a guessed PASS"), 21/21 selftest with module_sha256. |
Gold-standard verifier template (already embodies Article 14) |
| FIX7 pain point | knowledge/dev/reports/architecture/codex-fix7-blueprint-recheck-8-…/06-constitution14-executable-check-recheck.md (+ recheck-7) |
Verdict CONSTITUTION_14_EXECUTABLE_CHECK_FAIL. |
Pilot target / failure corpus |
1.2 The exact failure class to catch (verbatim from recheck-8 doc 06)
The verdict was CONSTITUTION_14_EXECUTABLE_CHECK_FAIL. Codex's reasons, quoted:
- "Declared invocation exits 2 because the
.pyartifact does not exist." - "Selftest covers 22 narrow unit assertions, not the production seal path."
- "Claimed computed scenarios for duplicate authority/package divergence are prose-only; they do not appear in the executable test."
- "Active extractor, duplicate-marker handling, envelope roster closure, all aggregate digests, and detached-seal computation are absent."
- "The test for self-revision merely inserts an N8 self-edge; it does not parse and reject a real seal/envelope revision input."
Closing line: "This leaves the exact 'law reads well but code fails' gap NT14 forbids." These five reasons are the v0.1 acceptance corpus: a useful tool must mechanically detect every one of them.
1.3 Local toolchain (macOS /Users/nmhuyen, inspected command -v)
| Present | Absent (install path) |
|---|---|
python3, pip3, node, npm, jq, docker, git, go, trivy (already installed), shasum, brew (Homebrew 5.1.14), python pyyaml |
opa, conftest, squawk, gpg, yq, cargo, sha256sum (use shasum -a 256), python jsonschema, pydantic |
- The KB folder
knowledge/dev/laws/lives in the agent-data MCP, not on local disk (/Users/nmhuyen/knowledge/devexists but has nolaws/and no.git). The central folder is therefore realized in the KB, which is what User/GPT/Codex/T1 actually read. - MVP install footprint is tiny: only
pip install jsonschemaon top of what is present. OPA/Conftest/Squawk are installable viabrew/go install/prebuilt binary/dockerwhen their phases arrive.
2. Question A — Does a reusable implementation-conformance framework already exist?
Answer: PARTIAL.
What exists (reuse, do not rebuild):
- Authority + gate: Đ23 three-separation + "no DOT = no deploy" +
system_issuessink (Builder never self-certifies — the exact principle FIX7 violated). - Registry: Đ35
dot_registry/dot_config/ paired-DOT convention; CAT-006dot_tools. - Checker design: P6 taxonomy (BIRTH / PRE-ENACT / INVARIANT / DRIFT / PROJECTION), severities (BLOCK / ERROR / WARN / INFO), logger
fn_tac_log_checker_issue, naming{TYPE}-{DOMAIN}-{SEQ}. - The anti-FIX7 logic, already designed: P11E readiness contract + dual dimension
checker_run_status ∈ {ran_clean | ran_with_drift | not_ready | error_running}+ the 4-case truth table. This is precisely the instrument that separates "didn't run / can't run" from "ran and passed" — the conflation at the heart of FIX7. (P11E is design-only; runtime deferred.) - Runnable verifier template:
dot-iu-cutterdryrun.py— stdlib-only, import-isolated, sha256 precheck, fail-closed, real selftest. Article 14 in code form. - Paired build/verify script template: Đ43
dot-context-pack-build.sh/dot-context-pack-verify.sh(sha256, hardcode-ban, fail-closed). - Package/evidence example: P9-G6 migration dry-run package.
What is missing (the actual v0.1 build):
- A package-level manifest envelope (
package_manifest.json) + a profile schema that every implementation dossier must emit. - A generic Article-14 runner that, given a manifest, resolves each declared artifact, executes each declared command (captures exit code + stdout/stderr + sha256), binds every prose claim to real executable evidence, and checks scope / duplicate-authority / path-alias.
- A thin policy layer (later: OPA/Conftest) over the manifest JSON.
- A SQL safety hook (later: Squawk) for SQL-bearing packages.
- The DOT registration row + pilot profile (e.g.
fix7_foundation.yaml).
So: the contracts and templates exist; the package-manifest envelope + the "run the declared evidence and bind it to the claims" runner, packaged as a new DOT family, do not. That is a focused assembly job, not a from-scratch system.
3. Question B — How the new work fits the existing foundation (role map)
For every component, exactly one of: authority source / verifier-executor / evidence builder / report-only.
| Item | Role | Action |
|---|---|---|
| Đ38 Text-as-Code | authority source | Consume — the package IS a Text-as-Code artifact; do not redefine. |
| Điều 23 DOT | authority source + deploy gate | Consume + register into — the verifier is a DOT (Inspector); inherits "no DOT = no deploy"; sinks to system_issues. |
| Đ43 Context Pack | evidence / context source | Consume — verifier reads active context to resolve "what is the approved SSOT" for duplicate-authority + scope checks. |
| P11E / checker-proof | design pattern / contract | Reuse verbatim — checker_run_status 4-case truth table + readiness contract. |
| P9-G6 / dry-run | evidence builder (example) | Reuse as template for the package/evidence shape. |
| Implementation Package DOT v0.1 | verifier / executor | New but subordinate — consumes all the above; emits findings, never approves. |
| OPA / Conftest | verifier / executor (engine) | Engine only — declarative policy over the manifest JSON; not authority. |
| Squawk | verifier / executor (engine) | Engine only — SQL lint; advisory, not sole BLOCK; not authority. |
| Python verifier | verifier / executor (core) | New core, modeled on dryrun.py; runs declared commands, hashes artifacts. |
The single rule: authority stays in the approved laws/designs/profiles; tools only execute and report. This keeps One SSOT per responsibility (§4.6 / §6.H).
4. Question C — Which external tools are worth using now
| Tool | Verdict | Why / what it replaces / install / risk / kept subordinate |
|---|---|---|
Python jsonschema |
USE_NOW | Validates package_manifest.json + profile against the schemas. Replaces hand-rolled, drift-prone validation and a "deep Markdown parser." Install: pip install jsonschema. Risk: low. Subordinate: schema cites law_ref; it validates shape, it is not the law. |
| Bash | USE_NOW | Paired *-build.sh / *-verify.sh wrapper that matches the Đ43 dot-context-pack-*.sh house convention. Already present. Subordinate by construction (a DOT runner). |
shasum -a 256 |
USE_NOW | sha256 evidence binding — the same primitive already used by P10B hash reports and dryrun.py/module_sha256. Present. |
| Python (stdlib) verifier | USE_NOW | The core gate, cloned in spirit from dryrun.py (stdlib-only, import-isolated, fail-closed). No new dependency beyond jsonschema. |
| OPA / Conftest | DEFER → Phase 5 | High value as declarative manifest policy, but adds a second policy language; not needed to catch the FIX7 class (the 8 checks fit in Python). Add after the manifest schema is frozen. Install: brew install opa conftest. Risk if rushed: rego becomes a parallel authority → mitigation: generate/structure rego from the schema, each rule carries law_ref. |
| Squawk | DEFER → Phase 6 | Only relevant when a package carries SQL/migrations (FIX7 packages do). Install: prebuilt binary / npm / docker (cargo absent). Risk: misses system-specific SQL risk → keep advisory (WARN/INFO), pair with PG-native Đ33/Đ23 DOT-PG-01. |
| Trivy | DEFER / REJECT for v0.1 | Already installed, but it is a vuln/IaC/secret scanner — a different axis (supply-chain security), not implementation-package conformance. Out of scope for v0.1; optional later "security profile." |
| GPG | DEFER | Cryptographic signing of seals. Existing practice already uses sha256 + MCP revision + authorship as compensating controls (the FIX7 detached-seal work shows GPG-less sealing is the current norm). Not needed for v0.1. |
| Git hooks / CI | DEFER | The central store is the KB (MCP), and knowledge/dev is not even a git repo, so a git pre-commit hook has nothing to hook v0.1. Revisit at production-grade. |
| Docker sandbox | DEFER | Valuable when executing package-supplied code. v0.1 runs read-only/selftest commands the package declares; add sandboxing when packages ship runnable code. Docker is present, so this is cheap to add later. |
USE_NOW set is intentionally tiny: python3 + jsonschema + shasum + Bash. Everything else is deferred to keep v0.1 simple and install-light.
5. Question D — The simplest usable v0.1
A package emits package_manifest.json; a Python gate constitution14_verifier.py does the following, fail-closed, and a self-test proves the verifier itself satisfies Article 14.
implementation package / construction dossier
→ package_manifest.json (validated by package_manifest.schema.json)
→ profile.yaml (e.g. fix7_foundation.yaml, validated by profile.schema.yaml)
→ constitution14_verifier.py reads manifest + resolves artifacts + RUNS commands + binds claims
→ verdict.json + report.md (per-check checker_run_status + overall PASS/BLOCK)
The eight checks (each maps to a named failure in the corpus):
| # | Check | Catches | Maps to |
|---|---|---|---|
| 1 | Artifact exists — every artifact_path resolves on disk/KB |
missing executable artifact | recheck-8 #1 |
| 2 | Command runs — execute declared command, capture exit code; exit != expected_exit ⇒ BLOCK |
non-runnable command, "exits 2" | recheck-8 #1 |
| 3 | Hash binding — recompute sha256 of each artifact at verify-time; mismatch ⇒ BLOCK |
false PASS / stale evidence | iu-cutter rehash precheck |
| 4 | Selftest maps to production path — declared selftest must exercise the declared load-bearing operations, not only narrow units |
fake selftest, "22 narrow assertions" | recheck-8 #2, #4 |
| 5 | Claim ↔ evidence binding — every prose claim references ≥1 evidence with a real artifact+command; prose-only ⇒ BLOCK |
"computed scenarios are prose-only" | recheck-8 #3 |
| 6 | Negative-test reality — declared negative tests must parse-and-reject a real input, not a toy self-edge (flagged by an asserts_rejects field that names a concrete rejected input) |
toy negative tests | recheck-8 #5 |
| 7 | Scope allow/deny — declared touched paths/objects ⊆ profile allowlist; forbidden scope ⇒ BLOCK | forbidden scope | task §6.D |
| 8 | Duplicate-authority + path-alias — exactly one SSOT authority per responsibility; document_id exact-match (reject . .. // % homoglyph aliases) |
duplicate authority, path alias | FIX7 fix7 blockers C/D |
Verdict semantics (P11E, reused verbatim): each check returns checker_run_status ∈ {ran_clean, ran_with_drift, not_ready, error_running}. An incomplete or unrunnable manifest can NEVER read as PASS — missing required input ⇒ not_ready (INFO), source-of-truth present but command fails ⇒ error_running/ERROR, declared+ran+clean ⇒ ran_clean, declared+ran+violation ⇒ ran_with_drift/BLOCK. Overall verdict is BLOCK if any check is BLOCK or any required check is not_ready.
The machine reads JSON/YAML only (no deep Markdown parser); the agent may still author Markdown narrative, but the load-bearing claims must also appear as structured manifest entries.
6. Question E — What must NOT be built in v0.1
Explicitly out of scope (defer):
- Full CI / git-hook integration
- GPG signatures
- A complete dry-run framework (reuse P9-G6 shape; do not re-architect it)
- Plugin framework
- Dashboard / UI
- A deep Markdown parser (machine reads JSON/YAML; that is the whole point)
- Broad migration automation
- Production-apply integration
- OPA/Conftest (Phase 5), Squawk (Phase 6), Docker sandbox execution, Trivy security profile
- Live PG
system_issueswrite — v0.1 emits a file report; wire the PG sink at production-grade.
7. Question F — Proposed roadmap
(Adopts the suggested phases with findings-based revisions.)
| Phase | Deliverable | Notes |
|---|---|---|
| 0 — Inventory & gap confirmation | Largely done by this document. | PARTIAL confirmed; corpus = recheck-8 five failures. |
| 1 — Central folder/index | tool-kiem-thu/README.md + 00-index.md (+ subfolders) |
Created this session (see §10). |
| 2 — Implementation Package DOT spec | implementation-package-dot/README.md declaring entrypoint + precedence (consumes Đ23/Đ38/Đ43, sits below P6/P11E) |
Uses the HOW-TO-READ precedence pattern so it does not fork authority. |
| 3 — Manifest + profile schema | package_manifest.schema.json + profile.schema.yaml |
Reuse P11E CheckerOutput + checker_run_status; required[] fields enforce fail-closed. |
| 4 — Minimal Python verifier | constitution14_verifier.py + its own selftest |
Modeled on dryrun.py; jsonschema; shasum; the 8 checks; file report. |
| 5 — OPA/Conftest policy | policies/*.rego (common, blocked_scope, evidence, no_duplicate_authority) |
Only after schema frozen; each rule cites law_ref. |
| 6 — Squawk SQL-lint | tools/run_squawk.sh hook |
For SQL-bearing packages; advisory WARN/INFO. |
| 7 — FIX7 pilot profile | profiles/fix7_foundation.yaml + run verifier on the FIX7 package |
Must reproduce detection of all five recheck-8 failures. |
| 8 — Codex review of tool + its own evidence | Codex runs the verifier's declared commands | The tool must pass the same Article-14 bar it enforces. |
| 9 — Return to FIX7 blueprint/package | FIX7 package re-submitted through the verifier | Closes the loop the manual review could not. |
8. Question G — Effort estimates (ranges)
| Scope | Estimate | Contents |
|---|---|---|
| Minimal planning amendment (smallest legal hook) | 0.5–1 day | The Điều 23 Appendix stub (§9) — design text only, no code. |
| MVP usable for FIX7 | 2–4 days | Phases 2–4 + Phase 7 pilot; Python-only; catches the 8-class; reproduces recheck-8 detection. |
| Reusable v0.1 | 1–2 weeks | + Phase 5 (Conftest) + Phase 6 (Squawk) + profile generalization + selftest hardening + DOT registration row. |
| Production-grade | 3–6 weeks | + live system_issues/fn_tac_log_checker_issue sink + dot_registry registration + Docker sandbox exec + GPG/CI + multi-profile + Codex-sealed release. |
Ranges, not single numbers, because Phase-7 pilot findings (how messy the real FIX7 package is) will dominate MVP time, and Conftest/Squawk install + rule authoring dominate the v0.1 tail.
9. Question H — Smallest law/amendment needed (proposal only — NOT written here)
Three candidate placements were considered:
- Điều 23 Appendix — Implementation Package DOT (recommended)
- Đ38/Đ23 Bridge — Text-as-Code Executable Evidence Gate
- Điều 14B — Executable Evidence Gate (constitution-level)
Recommendation: Điều 23 Appendix — "Implementation Package DOT," plus a one-paragraph NT14 operationalization pointer in the constitution that references the appendix.
Why this avoids overlap (One SSOT per responsibility):
- Đ38 already owns Text-as-Code → we consume it, we do not redefine it.
- Đ43 already owns active context → we consume it.
- Đ23 already owns the DOT gate + "no DOT = no deploy" +
system_issues→ the verifier is a DOT, so it belongs in Đ23's house as an appendix, not a new law. One appendix, one new row in the DOT family — zero new authority surface. - A standalone Điều 14B is heavier (constitution-level amendment process) and redundant: NT14 already exists as principle; what is missing is the operational gate, and a gate is a DOT, which is Đ23's domain. So keep the principle in the constitution (a pointer paragraph) and put the mechanism in the Đ23 appendix.
Defer writing the actual amendment text until the v0.1 spec (Phase 2) and the FIX7 pilot (Phase 7) prove the gate's shape.
10. Question I — Risks and mitigations
| # | Risk | Mitigation |
|---|---|---|
| 1 | New tool becomes a parallel authority | Register as a DOT under Đ23 (Inspector role); sink to system_issues; declare precedence below P6/P11E via a HOW-TO-READ-style entrypoint; the tool emits findings, never approves (tam quyền). |
| 2 | OPA rules diverge from Text-as-Code/DOT law | Defer OPA to Phase 5; when added, structure rego from the manifest schema and put law_ref on every rule; policies are tests of the law, not the law. |
| 3 | Agent-generated manifest is incomplete | jsonschema required[] + P11E not_ready vs ran_clean distinction ⇒ an incomplete manifest is structurally incapable of reading PASS; coverage check requires declared load-bearing ops present. |
| 4 | Python verifier grows too large | Cap scope to the 8-class; stdlib-only core (like dryrun.py); push declarative rules to schema/Conftest; gate the verifier on its own selftest. |
| 5 | Squawk misses system-specific SQL risk | Squawk is an advisory engine (WARN/INFO), never the sole BLOCK; system-specific risk stays in PG-native Đ33/Đ23 DOT-PG-01 checks. |
| 6 | False PASS because evidence is not bound to artifact hash | Mandatory verify-time sha256 recompute for every claim→evidence→artifact; mismatch ⇒ BLOCK (the iu-cutter snapshot-rehash precheck pattern). |
| 7 | Toolchain install fragility | MVP needs only python3 + stdlib + jsonschema (pip) + shasum (present). OPA/Squawk deferred, version+sha pinned, with a docker fallback (docker present). |
| 8 | Documents scattered, hard for the user to read | Enforce the single folder knowledge/dev/laws/tool-kiem-thu/ with README.md + 00-index.md; this plan + checkpoint live there; KB is SSOT, optional local mirror. |
11. Suggested v0.1 directory shape (revised after inspection)
implementation-package-dot/ # the tool itself (location TBD: KB doc-tree + VPS dot/bin mirror, matching Đ43 pattern)
README.md # Phase 2 spec: entrypoint + precedence (consumes Đ23/Đ38/Đ43)
schema/
package_manifest.schema.json # Phase 3
profile.schema.yaml # Phase 3
profiles/
fix7_foundation.yaml # Phase 7 pilot
policies/ # Phase 5 (DEFER)
common.rego blocked_scope.rego evidence.rego no_duplicate_authority.rego
tools/
constitution14_verifier.py # Phase 4 — core, modeled on dryrun.py
run_opa.sh # Phase 5 (DEFER)
run_squawk.sh # Phase 6 (DEFER)
dot_implementation_package_verify.sh # paired-DOT wrapper (Đ43 convention)
examples/
fix7_package_manifest.example.json
reports/ # verdict.json + report.md outputs
Open placement question: the existing house convention puts runnable DOTs at vps:/opt/incomex/dot/bin/ mirrored to KB knowledge/dev/dot/. v0.1 code should likely follow that (KB doc-tree for review + dot/bin mirror for execution), with all planning/design docs staying under knowledge/dev/laws/tool-kiem-thu/. Confirm with User/GPT before Phase 4.
12. Final status block
Final status: PLAN_DRAFT_READY
Production mutation: NO
Central folder/index: CREATED (KB) — tool-kiem-thu/{README.md, 00-index.md, planning/, checkpoints/}
Existing framework: PARTIAL (contracts + templates exist; package-manifest envelope + generic
run-the-declared-evidence runner are missing)
Recommended approach: Subordinate "Implementation Package DOT v0.1" — a Python Article-14 gate over a
package_manifest.json, consuming Đ38/Đ23/Đ43, reusing P11E checker_run_status,
modeled on dot-iu-cutter dryrun.py. OPA/Squawk deferred as engines.
External tools: USE_NOW = python3 + jsonschema + shasum + Bash
DEFER = OPA/Conftest (P5), Squawk (P6), GPG, git hooks/CI, Docker sandbox, Trivy
REJECT(v0.1) = Trivy as a conformance gate (different axis)
Law/amendment: Điều 23 Appendix — Implementation Package DOT (+ NT14 pointer). NOT written yet.
Report path: knowledge/dev/laws/tool-kiem-thu/planning/implementation-package-dot-v0-1-feasibility-plan-2026-06-09.md
Checkpoint path: knowledge/dev/laws/tool-kiem-thu/checkpoints/checkpoint-implementation-package-dot-v0-1-feasibility-plan-2026-06-09.md
13. Key open questions (for User / GPT / Codex / T1)
- Placement of runnable code — KB
knowledge/dev/dot/+vps:/opt/incomex/dot/bin/mirror (Đ43 pattern), or elsewhere? (§11) - Law hook — accept the Điều 23 Appendix recommendation, or prefer a standalone Điều 14B? (§9)
- Manifest authorship — does T1 hand-author
package_manifest.json, or is it generated from the construction dossier? (affects risk #3) - Conftest now or later — is the Phase-5 deferral acceptable, or should declarative policy land in the MVP?
- Pilot scope — run the FIX7 pilot against the current recheck-8 package as-is, or against a re-authored package that already emits a manifest?
system_issuessink — keep v0.1 file-report-only, or wire the live PG sink earlier?
End of feasibility plan. Planning only — no implementation, no install, no production mutation, no law authored, no FIX7 recheck resumed.