RS-TKT-0A · 02 laws-new LEGO Requirements for TKT
RS-TKT-0A · 02 — laws-new LEGO Requirements for TKT
Lane: RS-TKT-0A · Date: 2026-06-21
Gate: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 runtime mutations (KB writes only)
Authority: NON_AUTHORITY · may_gate=false · decision_effect=NONE
This document states what laws-new requires of a Tool-Kiem-Thu (TKT) support checker, grounded verbatim in the laws-new SSOT (matrix-refactor-implementation-plan.md, matrix-refactor-quick-rules.md, matrix-stamp-governance-addendum.md), the problem statements (de-bai-cai-tien.md, new-iu/…), and the pilot (lego-pilot-slice-0-*).
0. The new workspace boundary (verbatim, tool-kiem-thu-lego/index.md)
This folder does not authorize runtime mutation, production execution, registration, Owner/scope/APR/register_dot creation, semantic Text-as-Code PASS, or production PASS.
REGISTRATION_HOLDremains active unless a later authorized decision explicitly changes it.
Every requirement below is subordinate to that boundary.
1. The ten requirements laws-new imposes on TKT
R-TKT-1 — Small checker blocks, not a whole-system scanner
laws-new Lego Protocol (verbatim, de-bai-cai-tien.md §VI): "Một việc lớn không được triển khai như một macro khổng lồ. Nó phải được tách thành nhiều miếng nhỏ." Quick-rules S11: the checker reads exactly one candidate packet bound by candidate_id + packet_hash — "KHÔNG scan toàn hệ, KHÔNG tự đoán/ráp artifact rời rạc."
→ TKT requirement: one checker block = one concern, reads one packet. No mega-checker that "understands the whole system."
R-TKT-2 — 100% communication through explicit IO Contracts
Verbatim (§VI.3, hard rule): "các ô/miếng không giao tiếp bằng hiểu ngầm hoặc đọc lén trạng thái nội bộ của nhau. Mọi giao tiếp giữa các miếng phải qua IO Contract tối thiểu." The minimal contract (io_contract.v0.1) declares cell_id · accepts · returns · checks{bad_input_min_classes:8, any_fail_open:false} · rollback · owner_scope.
→ TKT requirement: every checker block declares input contract / output contract / dependencies explicitly; no hidden coupling between blocks.
R-TKT-3 — No mega-registry / no mega-graph / no mega-birth pipeline (anti-island)
New IU §9 anti-island hard rules (verbatim, "Vi phạm bất kỳ dòng nào = quay về Phương án A (bị từ chối)"): "Không registry riêng … Không birth riêng … Không KG riêng … Không governance riêng. Dùng One-Roof." Anti-bloat (§VI.7): "Làm được bằng 1 DOT nhỏ + 1 stamp nhỏ + metadata hiện có → KHÔNG tạo registry mới."
→ TKT requirement: TKT must not create its own object registry, its own graph, or its own birth pipeline. The old TKT-OBJ-* registry is therefore REUSE_WITH_CHANGE→route to one-roof, never re-created.
R-TKT-4 — Staging-friendly (runs in the disposable workshop)
Staging IO contract (verbatim): "Staging is a disposable workshop, not a second production path … nothing it does ever writes production birth_registry, certifies, canonicalizes, mints identity, or touches the KG." Canonical loop: "mở ô tạm → lắp thử → kiểm nhanh → sai thì xóa → đúng thì promote."
→ TKT requirement: TKT must be able to run against a candidate in the temp store and produce a candidate verdict on a disposable surface, touching no canonical state.
R-TKT-5 — Rollback-friendly (delete-fast bounded)
Quick-rules S14: "Mọi workspace/candidate phải có TTL + cleanup fail-safe: chỉ xóa draft/expired/quarantined; KHÔNG xóa đang checking/promote_ok-chưa-consumed/approved." Pilot: delete-fast = "the entire staging surface as ONE disposal unit." → TKT requirement: a TKT run and its evidence must be disposable as one unit, with no canonical residue after delete-fast (provable, not asserted).
R-TKT-6 — Verdict-only / non-mutating
Stamp addendum: the promote-checker is verdict-only; PROMOTE_OK/PROMOTE_BLOCKED is a verdict/state, not a stamp; it "does not sign birth, does not write canonical, does not close BIRTH_STAMP/PROMOTE_STAMP." Those belong to the separate Atomic Promote Contract.
→ TKT requirement: TKT emits a verdict; it never performs the promote, never mutates production, never closes stamps. (Mirrors the old base pack's decision_effect=NONE.)
R-TKT-7 — Review-lane / pre-Codex friendly
Review pipeline (verbatim, New IU §11): "Tất cả phase non-authorizing; qua cổng GPT → Codex → Owner." Discipline (New IU §0): "Documentary ≠ live proof · Engineering PASS ≠ Authority PASS · Registered ≠ executed ≠ live · KB admission ≠ runtime registration · DRAFT ≠ enacted · Default = HOLD." → TKT requirement: TKT output is a packet that flows Claude→GPT→Codex→Owner, carries non-authorizing banners, lists blockers as OPEN, and catches the defects Codex would catch before Codex (an approval accelerator, not an approver).
R-TKT-8 — No authority overclaim
One-roof (quick-rules R20, verbatim): "Không tạo thiết kế governance mới — One-Roof là trần duy nhất." New IU §14: the Owner "quyết authority/scope nhưng KHÔNG được waive technical PASS/evidence cho một pilot/implementation chạm runtime."
→ TKT requirement: a TKT PASS grants no seal, gate, or decision power; it cannot clear REGISTRATION_HOLD, set CAN_PROCEED=YES, or create Owner/scope/APR/register_dot. KB admission ≠ runtime registration.
R-TKT-9 — No semantic PASS without IU
The Text-as-Code engine is DEFER; the canonical subject identity a semantic check needs lives in the New IU thin Subject Contract (still in design). Old base pack enforces this as probe P10 (asserting SEMANTIC_TEXT_AS_CODE_PASS with no IU inputs → fail-closed).
→ TKT requirement: TKT may not emit a semantic Text-as-Code PASS or IU-traceability PASS; those stay L4–L6 (future). A semantic PASS on absent IU inputs is itself a fail-closed condition.
R-TKT-10 — NVSZ raw-evidence separation
New IU + base pack: raw run evidence is kept out of the vector KB; the KB stores "summary + hash + pointer + regeneration command — never raw transcripts." Vector/Qdrant is GATED until verified.
→ TKT requirement: TKT run evidence uses the NVSZ split — raw logs in a no-vector root (owner/operator-designated), only summary+hash+pointer+regen in the KB. (Detailed in 05.)
2. Mapping table — requirement → laws-new source → checker consequence
| Req | laws-new source (binding) | Consequence for TKT design |
|---|---|---|
| R-TKT-1 small blocks | §VI Lego Protocol; S11 | 04 blocks are single-concern, one-packet |
| R-TKT-2 explicit IO | §VI.3; io_contract.v0.1 |
every 04 block declares input/output/deps |
| R-TKT-3 no mega-X | New IU §9; §VI.7 | no new TKT registry/graph/birth |
| R-TKT-4 staging | staging IO contract | TKT runs on candidate in temp store |
| R-TKT-5 rollback | S14; delete-fast | run+evidence disposable as one unit |
| R-TKT-6 verdict-only | stamp addendum F4 | TKT never promotes/mutates/closes stamps |
| R-TKT-7 pre-Codex | New IU §11, §0 | 06 profile = Codex-defect catcher |
| R-TKT-8 no overclaim | R20; New IU §14 | authority firewall (TKT-L3) |
| R-TKT-9 no semantic PASS | TaC DEFER; P10 | L4–L6 boundary held |
| R-TKT-10 NVSZ | new-iu; base pack | 05 run-evidence packet |
3. Compatibility verdict
The old base pack already satisfies R-TKT-1, R-TKT-2 (partly), R-TKT-6, R-TKT-8, R-TKT-9, R-TKT-10 in concept. The gaps laws-new adds are: explicit per-block IO Contract framing (R-TKT-2 full), staging/delete-fast binding (R-TKT-4/5), and the pre-Codex RS profile (R-TKT-7). These gaps are the substance of 03–07.
No requirement here authorizes building. They define the target shape a future, separately-authorized build must meet. REGISTRATION_HOLD stays active.