RS-TKT-0A · 08 — Final Survey Report for GPT/Codex Review

Lane: RS-TKT-0A — Tool-Kiem-Thu LEGO Survey & Conversion Plan Date: 2026-06-21 Gate: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 runtime mutations (KB design-doc writes only) Authority: NON_AUTHORITY · may_gate=false · decision_effect=NONE FINAL VERDICT: RS_TKT_0A_READY_FOR_GPT_REVIEW

1. Executive summary

The old Tool-Kiem-Thu estate (433 KB documents) contains one high-value, already-decoupled asset — the tkt-base-structural-evidence-governance-pack-2026-06-11 base layer — surrounded by old-runtime machinery (v0.1-DOT, B4′/Phase-2 sandbox MVP, FIX7 N-node seal, DOT daily-scan) that should be retired or deferred. The base layer maps almost 1:1 onto a laws-new LEGO Tool-Kiem-Thu Base: a small set of single-concern support-checker bricks that verify a packet's structure (L0), reconstruction (L1), fail-closed behaviour (L2), and governance consistency (L3) — and explicitly nothing more. Semantic Text-as-Code (L5), IU traceability (L4), and release/bundle (L6) stay deferred because their inputs (a checker-consumable IU graph, a committed semantic oracle) do not yet exist; building a PASS on absent inputs is the exact fail-open the base layer exists to prevent.

On top of Base, an RS pre-Codex profile encodes the defect classes Codex actually caught on the RS5A chain (file-set completeness, gate/HOLD integrity, lifecycle 3-axis, total Q-order, G02a/b/c mutual-exclusion, 84/86 counts, codex-packet cross-agreement). It is an approval accelerator, not an approver: a clean TKT result is engineering PASS only and grants no authority, clears no HOLD, and binds no reviewer.

This is a plan, not a tool. No runtime was built; no production/registry/PG was mutated; REGISTRATION_HOLD remains active.

2. Files read (evidence base)

Full read: old TKT base pack (scope, output policy, 7 checker policies, 2 limitation docs, manifest.json, exit_codes.json, commands.sh, RERUN.sh, HASH_MANIFEST.txt, packet_tree.sha256, examples), 4 base reports, v0.1 authority + offline-MVP contracts, Article-14 5-lens spec; P6-checker-dot-design-v0-2 + 3 GPT reviews; NVSZ policy + manifest raw_evidence + dry-run + root requirements; laws-new 3 SSOT files + README + de-bai-cai-tien + new-iu pair + lego-pilot pair + new workspace index (verbatim); RS5A-patch3 & patch4 index/topics/decision/codex-packet; RS5B index/topics; 5 RS5A-chain Codex reviews. Summary read: ~48 TKT checkpoints, ~120 FIX7/recheck-9 packets, F0–F5/FX reuse packets, older RS1–RS4 reviews. Full inventory + paths: see 00.

3. Files produced (this lane)

00-survey-source-inventory-2026-06-21.md
01-old-tool-kiem-thu-reuse-gap-map-2026-06-21.md
02-laws-new-lego-requirements-for-tkt-2026-06-21.md
03-tkt-base-l0-l3-conversion-plan-2026-06-21.md
04-tkt-checker-block-catalog-draft-2026-06-21.md
05-nvsz-run-evidence-packet-assessment-2026-06-21.md
06-rs5a-rs5b-pre-codex-profile-draft-2026-06-21.md
07-conversion-roadmap-and-stop-states-2026-06-21.md
08-final-survey-report-for-gpt-codex-review-2026-06-21.md (this file) (+ additive index.md deliverables pointer.)

4. Reuse / gap summary (full table in `01`)

REUSE: base level model (L0–L3, cumulative cap); 7 checker policies; authority firewall (F1–F9); report-vs-file audit; fail-closed probes (P1–P10 + detector-correctness rule); packet skeleton (commands.sh/RERUN.sh/exit_codes.json/HASH_MANIFEST/packet_tree); NVSZ model + escrow schema.
REUSE_WITH_CHANGE: P6 checker-row schema + severity (drop DOT runtime); object-ID policy (route to one-roof, no new registry); Article-14 5-lens (keep advisory); packet skeleton (re-target to laws-new candidate packet).
RETIRE: v0.1-DOT surfaces/counts; FIX7 N-node seal artifacts; DOT daily-scan/healer/PG-gate runtime; dated process checkpoints.
DEFER: L4–L6; B4′/Phase-2/B7 sandbox execution substrate; runtime execution verifier; FIX7 approval-lane pattern (revive at Phase 4).
NEW_NEEDED: RS pre-Codex profile; staging/delete-fast binding; bad-input catalog merge (P1–P10 ∪ BAD-1..15).

5. Conversion approach (the through-line)

Lift the base layer → cast it as LEGO bricks with explicit IO contracts (02/04) → keep it verdict-only / NON_AUTHORITY → layer the RS pre-Codex profile for RS-series packets → keep raw evidence out of the vector KB via NVSZ → phase the rollout (07) so every runtime-touching step is separately authorized and REGISTRATION_HOLD is never weakened.

6. Recommended immediate next step

GPT review of this package, then Codex review. If accepted, open Phase 1 (TKT Base design package) — design-only, still under REGISTRATION_HOLD. Do not begin Phase 2 (a runnable inspector) until the Owner explicitly authorizes an execution surface; until then Phase 2 stops at HOLD_NO_EXEC_SURFACE.

7. Explicit boundaries (restated)

Scope L0–L3 (Base) + RS pre-Codex profile. L4–L6 out of scope.
No runtime / no production / no registration mutation performed. KB writes are design docs under tool-kiem-thu-lego/ only.
No authority overclaim: no seal, no gate, no register_dot/Owner/scope/APR creation, no clearing of REGISTRATION_HOLD, no CAN_PROCEED=YES.
NVSZ/no-vector: raw evidence separated from vector KB; root undesignated (owner/operator-only); KB holds summary+hash+pointer+regen only.
No semantic Text-as-Code PASS, no IU traceability PASS, no release/bundle PASS, no implementation PASS, no production PASS.

8. Self-check (Codex-style adversarial mindset)

8a. The ten-point discipline

Did not trust reports — found actual governed files. ✅ Five read-only passes over list_documents/get_document_for_rewrite; paths in 00.
Fresh-reconstructed from KB, not local prose. ✅ Counts via pagination to next_offset=null; quotes are verbatim from files.
Did not trust the harness. ✅ Counts labelled "listed"; truncation noted (MCB-4); two NVSZ taxonomies surfaced (MCB-2).
Checked whether the plan can be broken by bad input. ✅ Each 04/06 block has an explicit bad-input row and a failure code.
Checked whether invalid input could still produce PASS/digest/seal/cert. ✅ Detector-correctness rule (token emitted only if exit==0) carried into every block; L2 fail-closed + P10 retained.
If invalid input can produce PASS-like output → fail-open, reject. ✅ Stated as a rejection criterion in 04/06; aggregate verdict is advisory and any BLOCKER FAIL ⇒ not-ready.
Distinguished engineering PASS from authority PASS. ✅ 03 §5 + 06 profile note.
Distinguished design PASS from implementation PASS. ✅ 03 §5; Phase 1 (design) vs Phase 2 (runnable) in 07.
Distinguished TKT Base PASS from semantic Text-as-Code PASS. ✅ L5 deferred; P10 guard kept.
Verified REGISTRATION_HOLD remains active. ✅ Gate line on every deliverable; cross-phase invariant #1.

8b. The eight adversarial questions (issue → fail-closed correction)

#	Question	Verdict	Correction baked in
Q1	Can a bad package still get TKT PASS?	NO	L0–L3 cumulative cap + L2 probes + detector-correctness rule; any BLOCKER FAIL caps `level_reached`
Q2	Can missing evidence still produce a PASS-like report?	NO	report-vs-file audit recomputes every cited hash/PASS/pointer; missing raw/hash/regen ⇒ FAIL (escrow exit 2/3/4)
Q3	Can a checker block overclaim semantic correctness?	NO	L5/L4/L6 forbidden tokens; P10 fail-closes a semantic-PASS-without-IU claim; `out_of_scope` field mandatory
Q4	Can a summary pointer replace raw evidence?	NO	`05`: KB summary holds pointer+hash+regen to raw evidence; raw evidence still required, hashed, regenerable; summary-without-evidence ⇒ FAIL
Q5	Can an old object registry become a mega-registry?	NO	`01`/`02`: object-ID policy routes to one-roof; creating a new TKT registry violates anti-island rule and is RETIRE/REUSE_WITH_CHANGE only
Q6	Can a checker become a hidden production gate?	NO	`may_gate=false`, `decision_effect=NONE` on every block; aggregate verdict is advisory; Phase 5/6 stop-states `REJECT_HIDDEN_GATE`/`REJECT_AUTO_FIX`
Q7	Can a runtime execution verifier be smuggled into Base L0–L3?	NO	execution verifier is Phase 4, gated on a Call Contract + sandbox; Base is read/report; `07` keeps them separate
Q8	Can `REGISTRATION_HOLD` be weakened by wording?	NO	`TKT-RS-GATE-001/002` grep for the literal HOLD + `CAN_PROCEED = NO` and flag any `=YES`/HOLD-clearing phrase; cross-phase invariant #1

Self-check result: PASS (engineering/design self-check only). No fail-open path found in the plan; remaining risks are open items, not fail-opens (see §9). This is not an authority, implementation, runtime, or production PASS, and does not clear REGISTRATION_HOLD.

9. Risks

R1 (MCB-1): RS5B defect classes are self-reported (no Codex review yet) → 06 RS5B rows are DRAFT until Codex reviews RS5B.
R2 (MCB-2): two NVSZ exit taxonomies → pinned escrow taxonomy; owner/Codex to confirm.
R3 (MCB-3): ledger filename inconsistency → accept-either-and-warn; reconcile at approval.
R4 (MCB-5): NON_VECTOR_ROOT undesignated → Phases 3+ blocked on owner/operator designation; never invent.
R5: scope-creep pressure to fold L4–L6 or a runtime verifier into Base → held by 07 phase separation + stop-states.
R6: the base pack is dated 2026-06-11; confirm it is still the current reusable layer before Phase 1 build.

10. Open questions (for GPT/Codex/Owner)

Confirm the laws-new SSOT set (3 matrix-refactor files) is current and binding for TKT (MCB-6).
Confirm the canonical NVSZ exit taxonomy (escrow vs root-provisioning) (MCB-2).
Owner: will/when the NON_VECTOR_ROOT be designated (MCB-5)?
Should the RS pre-Codex profile (06) be a standalone brick set or folded into TKT-L3? (Recommend standalone, per LEGO.)
Is the FIX7 approval-lane pattern revived at Phase 4, or retired entirely?

11. Final verdict

RS_TKT_0A_READY_FOR_GPT_REVIEW — a complete survey and conversion plan exists and is ready for GPT → Codex → Owner review. This does not authorize implementation; Phase 1 may open only after review acceptance, and any runtime-touching phase requires a separate Owner authorization. REGISTRATION_HOLD remains active; REGISTRATION_CAN_PROCEED = NO; 0 runtime/production/registration mutations were performed.