t1k:cocos:playable:modularize

Auto-generated

🔒 Auto-generated from The1Studio/theonekit-cocos@0.0.0 — edit the source kit, not this page.

Field	Value
Module	playable
Version	2.14.4
Effort	high
Tools	—

Keywords: cpm-package, modularize, playablelabs

How to invoke

/t1k:cocos:playable:modularize
[phase0|structure-audit|reuse-scan|refactor|contribute] [<project-root>] [--apply] [--continue] [--implement] [--force-manual-queue] [--attended]

---

t1k-cocos-playable-modularize

Main goal: refactor/reuse/modularize the PROJECT itself — grade its structure, use the CPM library lookup to find tested @playablelabs/* packages that replace embedded source, and migrate the project to consume them. Contributing novel code back is a smaller, optional follow-on. Documentation-only orchestration — this file describes a 4-phase pipeline; there is no runtime skill-spawning. Each sub-skill runs standalone or in sequence.

When to invoke

• Establish or verify the architecture target before anything else → Phase 0 (docs/system-design.md).
• Grade a project’s layout against the canonical playable-ad structure → structure-audit.
• Look up the CPM library for existing tested packages that duplicate local code + suggest install → reuse-scan.
• Produce an ordered plan to migrate embedded framework source → CPM packages → refactor.
• (Optional) Separate a novel local subsystem into a real @playablelabs/<name> package → contribute.
• Run the whole thing end-to-end → the four in order (audit → reuse → refactor → optionally contribute).
• Run it hands-off → a bare t1k-cocos-playable-modularize <project-root> (Mode A: every phase, zero questions, ends on the reports + docs + plan + reports/IMPLEMENT.md), then --implement (Mode B) in a fresh session to execute the plan. See § “Unattended”.

Pipeline

#	Sub-skill	Pillar	Output
0	t1k-cocos-base-system-design + t1k-cocos-base-architecture-patterns (Phase 0)	— design baseline	probe-design-doc.cjs runs first — does the doc describe THIS project at all? Then docs/system-design.md authored --state as-is or audited for drift — from the project’s template, or system-design’s verbatim vendored blank if the project ships none. Everything below is graded against it. Plus the architecture-audit JSON (SOLID/pattern/enabling-extraction findings) that feeds pillar C.
1	t1k-cocos-playable-modularize-structure-audit	A — structural conformance	Per-rule CONFORMANT / DRIFT / MISSING vs the vendored blueprint.md + a normalization plan.
2	t1k-cocos-playable-modularize-reuse-scan	B — reuse	Per-subsystem REUSE / EXTEND / KEEP / CONTRIBUTE via two-source library lookup (knowledge MCP + CPM registry). It NAMES the package to install; pillar C’s Tier 1.5 performs the install with install-package.cjs, so a REUSE verdict now reaches an executable step instead of stopping at a suggestion.
2.5	t1k-cocos-playable-preproduction (refactor mode) — runs automatically in Mode A	— design target	docs/system-design.md rewritten --state to-be: the modules this system should have. Inputs are the as-is doc + the architecture audit + the reuse verdicts — not a spec. Module slicing only; the WP costing pass is skipped unless a number was asked for. This is the phase that makes pillar C a diff instead of a violation list.
3	t1k-cocos-playable-modularize-refactor	C — project-first	Ordered project refactor plan: outdated-package upgrades → folder-norm → INSTALL missing packages (Tier 1.5) → REUSE swaps → SOLID/pattern refactor + enabling extractions → MECHANIC SLICE the design doc’s modules into vertical folders (Tier 2.6) → second REUSE pass → embedded-submodule→CPM migration → tag CONTRIBUTE. No package splitting. Two tiers delegate rather than reimplement: Tier 2.6 → t1k-cocos-playable-mechanic-split (invoked --mechanics-from docs/design-manifest.json, so boundaries come from the design doc and never from a coupling audit re-run there) and Tier 3 → t1k-cocos-playable-submodule-to-package.
4	t1k-cocos-playable-modularize-contribute	D — contribute (optional)	ADD a novel subsystem as a new @playablelabs/<name> package, or UPDATE an existing package with a local fix/extension (+ version bump). Plain readable TS; dev decides publish (manual/AI). Never publishes.

Dependencies — which phases actually need the design doc, and which merely read better with it:

Phase	Needs docs/system-design.md?	Why
0	produces it	—
1 structure-audit	No — not a gate	Grades folders against the pinned blueprint. It never reads the doc’s content; its R9 rule only checks the file exists. Runs standalone on a project with no doc.
2 reuse-scan	No — not a gate	Grades local subsystems against upstream packages. Independent of the project’s own architecture target.
2.5 preproduction (refactor mode)	Consumes it — and rewrites it	Reads the as-is doc as its baseline and emits the to-be target over it. Also needs the architecture audit (what is wrong) and 2’s report (what a package will delete).
3 refactor	Yes — ENFORCED precondition	Tier 2.5 is graded against the doc’s § Code Structure Rules. Planning without it measures against nothing. plan-refactor.cjs --design-probe now withholds Tiers 2.5/2.6/2.75 (blockers[], per-step blockedBy) until the probe verdict is ok. Also needs 1+2’s reports, and 2.5’s manifest for designState.
4 contribute	No — needs 3 landed, except UPDATE mode unblocking a Tier 2 EXTEND unit (decision-policy § Rule 1)	ADD extracts from an already-healthy project. UPDATE ports an existing local improvement into the package’s upstream source repo, so it may run mid-walk.

The architecture audit (Phase 0’s second output) has the same hard dependency as 3, for the same reason. Run Phase 0 first regardless — it is cheap, it is the only phase that can author the baseline, and 3 is the phase the whole pipeline exists to reach. But do not report 1 or 2 as blocked on it: they are not, and treating them as blocked is what makes operators skip the pipeline entirely on a repo with no doc. Full ordering + gates live in each sub-skill body.

”The doc exists” is not “the doc is ours” — probe before planning

The single highest-risk state this pipeline can be in is a docs/system-design.md inherited verbatim from another project — typically PlayableAdsTemplate’s own doc, committed at the repo’s initial commit and never rewritten. It defeats every other check here by construction: pillar 1’s R9 rule only asks whether the file EXISTS, pillars 1 and 2 never read its content at all, and generate-manifest refuses it for a missing state: — a failure that surfaces downstream only as the generic designState: null. Nothing anywhere asked whose project the doc was about.

Phase 0 therefore starts with a probe, and its verdict gates the design-dependent tiers:

node <system-design>/scripts/probe-design-doc.cjs docs/system-design.md <repo-root> > reports/design-probe.json
# exit 0 = ok · 1 = repair required (absent | template-verbatim | template-unfilled |
#                                    foreign | non-canonical | indeterminate)

A non-ok verdict means repair the doc to describe this project, then re-probe — it is never “note it and continue”. The verdict names its own repair; foreign and non-canonical are repaired by authoring the as-is doc from the code (system-design Step 0a, or migrate-design-doc.cjs for a doc that is merely off-template).

Phase 0 ends on the SECOND probe, not the first. Re-run it after the repair and require ok; that re-run is the only part of the step that can fail, and re-planning against the pre-repair design-probe.json reproduces the defect with a repair step in the transcript to make it look handled. In Mode A this is automatic for every repairable verdict — which is all of them except indeterminate, whose identity check has no input to repair from (references/decision-policy.md rule 9).

What the gate does and does not withhold. Pass reports/design-probe.json to plan-refactor.cjs --design-probe; while the verdict is not ok it emits blockers[] and marks every Tier 2.5/2.6/2.75 step blockedBy. Tiers 0/1/2/3/4 stay free, the report still prints in full, and the exit code stays 0. That scoping is deliberate: version bumps, folder normalization and import repoints are graded by no design doc, and a gate that refuses the whole pipeline on a legacy repo is one operators route around — after which it protects nothing.

Phase 0 is the baseline; phase 2.5 is the target. They are two tenses of one artifact, and running only the first is the pipeline’s default failure: pillar C then plans against designState: null — neither toward a documented target nor away from a documented baseline. The audits tell you what is wrong; only 2.5 decides what modules this system has. Skipping it does not produce a smaller refactor, it produces one whose boundaries land wherever the split test happened to cut.

Phase 0 is a service call, not step zero

t1k-cocos-base-system-design owns the design artifact and is invoked by whichever entry point needs it — which is not always this pipeline, and not always at the start. Where you enter depends on what you are holding:

You arrive with	Entry point	Doc state on arrival → departure
From scratch — a spec, no code	preproduction (it calls system-design to author --state to-be)	none → to-be → converged when built
Existing doc to check	architecture-patterns audit	converged → drift is the finding
Old code, refactor — this pipeline’s main case	Phase 0 = system-design authors --state as-is; pillars 1–2; then Phase 2.5 = preproduction (refactor mode) revises it to --state to-be; then pillars 3–4	as-is → revised to-be → converged on land
Old code → new gameplay	system-design for as-is, then preproduction for the upgrade	as-is → to-be (retained + new modules) → converged

Lifecycle semantics — what each state means and what verify checks in it — live in t1k-cocos-base-architecture-patterns. This table states entry points only; two tables describing one thing is the duplication this design removes.

The manifest is the machine-readable half. Phase 0’s doc is generated into docs/design-manifest.json, and pillars 2 and 3 read it (--manifest) so module boundaries come from the design rather than from folder shape. Without it they fall back to readdir and label the report discovery: "readdir-fallback" — valid, but a guess.

Library source — two options, neither mandatory alone: the knowledge-retrieval MCP (doc_search, hybrid lexical+vector discovery) and the Cocos Package Manager at https://cpm.playablelabs.ai/ (web UI, CLI, or the editor extension’s list-packages — authoritative on package names and versions). Prefer both: MCP to discover, CPM to confirm. One available → degraded but valid; both unavailable → stop rather than report a false “nothing found”. See references/shared-cpm-facts.md § Library discovery.

Run the MCP half ONCE, at pipeline level, and share it. Invoke t1k-cocos-base-knowledge-sweep before Phase 0 and carry its prior-art table into the briefs for 0, 3 and 4 — do not leave pillar 2 as the only step that ever queries the corpus. Phase 0 needs it to know which documented modules already exist upstream; pillar 3 needs it so a Tier 2.5 extraction is not performed on code a swap will delete; pillar 4 needs it so nothing is contributed that already ships.

How it is carried: these are AI-driven phases, so the table travels in the invoking prompt/brief — there is no --prior-art flag, and none of the pillar scripts accept one. Pillar 1 is excluded on purpose: scan-structure.cjs is a deterministic folder scan with no judgment step, so there is nothing for a prior-art table to inform. Pillar 2 runs its own per-subsystem doc_search and needs no hand-off.

The sweep must be Cocos-scoped: most corpus members are Unity/.NET (59.4% as of 2026-08-28) and their C# members outrank the real Cocos hits on Cocos questions — the SSOT is the sweep skill reference t1k-cocos-base-knowledge-sweep/references/doc-search-contract.md.

Why reuse and architecture interleave: reuse swaps run before the quality refactor (never refactor code a swap will delete), but a god-class with no seam cannot be swapped until SRP splits it out — an enabling extraction. So pillar C runs reuse → architecture → reuse again over the newly exposed seams. See t1k-cocos-base-architecture-patterns § Enabling extraction.

Shared contract (stated ONCE here; children reference, never restate)

All four sub-skills obey the SAME operating contract. Read it once, then apply per phase:

• Report-only by default. A bare run reads the project and emits a markdown report + a machine JSON artifact. It NEVER mutates the project.
• --apply mutates — and only after the AskUserQuestion decision gate. See references/shared-cli-contract.md for the exact flag semantics, the decision-gate options, and the report/exit format.
• The orchestrator’s own bare run is UNATTENDED (Mode A), and --implement is the unattended execution pass (Mode B). Both ask nothing and resolve every fork through references/decision-policy.md — a named rule if one applies, decide-and-record (rule 0) if none does — and record the resolution either way; only a genuine verification failure hard-stops. Sub-skills invoked standalone keep their gates, and --apply / --continue are unchanged. Contract: shared-cli-contract.md § “Unattended modes”.
• Errors over silent fallbacks. An absent input report or unreadable project is a clear surfaced error — never a false “nothing found”. For library lookup specifically: one discovery source down → fall back to the other and label the report (discovery: cpm-only / mcp-only); both down → error out. reuse-scan must never report “0 packages” because a source was unavailable.
• One unit at a time for anything risky. Migration and .meta-adjacent changes run on a git branch, one migration unit per --apply, each behind its own gate.

CPM ground facts (SSOT for all children)

Composition is plain import. register(ctx) does NOT exist in this framework — do not design or assume a DI seam. The install SSOT is the playableSync array in the Cocos project’s package.json; the @playablelabs scope resolves via .npmrc against the CPM registry (https://cpm.playablelabs.ai/), reachable manually or by CLI. All code the skill reads/writes is plain, readable TypeScript. Full facts (package-manager handler set, registry) live in references/shared-cpm-facts.md. Where AnimalHunter (the guinea pig) actually keeps things: references/shared-project-map.md.

References

• references/end-to-end-runbook.md — start here to actually run this. Operator guide: Phase 0 → audits → one plan → tier-by-tier apply → contribute, with per-phase gates and the three failure modes that bite in practice. Its § “Phase 5 — apply, tier by tier” is the loop --continue walks; § “After the report — what to do next” below names the invocation that reaches it.
• references/shared-cli-contract.md — report-only default, --apply semantics, AskUserQuestion gate, report + exit-code format. Every sub-skill’s CLI section links here.
• references/decision-policy.md — the rules that replace the human gates in Mode A/B. Every fork the unattended modes resolve without asking, each with its rejected alternative; the four measured errors that motivated them; the conditional exemption from rules/ask-before-deciding.md; and what is a hard-stop instead.
• references/unattended-implement.md — Mode B’s procedure. The walk, the editor probe, the pre-verify table, git-per-unit rollback, the eight hard-stop conditions (four of them run through a revert/retry-once/skip-or-stop failure policy first), and the reports/IMPLEMENT.md + reports/implement-state.json contract.
• references/shared-cpm-facts.md — playableSync install SSOT, @playablelabs scope + registry, real package-manager handlers, “plain readable TS”, “no register(ctx)”.
• t1k-cocos-base-knowledge-sweep — the pipeline-level Cocos-scoped prior-art sweep; owns the doc_search contract that pillar B (and now 0/3/4) consume.
• t1k-cocos-playable-preproduction — the Phase 2.5 producer. Owns top-down module slicing in both archetypes; this pipeline invokes it in refactor mode (as-is doc + audits in, to-be doc out) and never restates its procedure.
• references/shared-project-map.md — canonical vs AnimalHunter layout; embedded PLAGameFoundation/PlayableParamterTool vs packages/@playablelabs/.

Gotchas

• Folder-grading is layout-only. structure-audit grades folders, never verifies that declared packages are actually imported — that consumption check belongs to reuse-scan/refactor.
• Never move or delete a .meta silently. .meta files carry Cocos asset UUIDs; moving/deleting one re-points every scene/prefab reference. Quarantine-to-report only, behind a gate.
• Code work is scoped to assets/scripts. reuse-scan/refactor/contribute analyze and modularize the project’s own scripts; structure-audit still grades the whole assets/ folder layout. Everything is plain, readable TypeScript.
• Tier 2.5 is the only step that rewrites source logic. Every other tier changes layout and import paths only. Tier 2.5 restructures the project’s own code under assets/scripts per rules/code-quality-cocos.md, driven by the architecture-audit findings — never package source, and never a transform the findings don’t authorize. Tier 2.6 is the other tier that touches assets/scripts, and it RELOCATES rather than rewrites: 2.5 changes what the code says, 2.6 changes where it lives.
• The design doc decides module boundaries — including the ones Tier 2.6 executes. mechanic-split can derive mechanics from a coupling matrix when run standalone, and inside this pipeline it must not: two module maps decided by different methods is not redundancy, it is a contradiction nobody adjudicates. That is why Tier 2.6 always passes --mechanics-from, and why 2.6 sits in the design-blocked set — with a foreign doc it would move this project’s files into another game’s boundaries.
• Architecture doctrine is NOT owned by this family. docs/system-design.md is the SSOT. These skills grade against it and never restate it — a second copy drifts, and the copy is the one people read.
• Skipping Phase 0 degrades pillar 3, not pillars 1 and 2. Be precise about this, because the vague version (“Phase 0 gates everything”) gets the pipeline abandoned on legacy repos. Pillars 1 and 2 produce fully valid reports with no design doc. What breaks is the architecture audit — it has no project-specific target — so Tiers 2.5/2.75 never populate and a legacy project’s structural debt migrates into packages untouched. The plan JSON says so: designDoc and archAudit.
• designState: null in the plan means no design phase ran. It is not a neutral field. to-be says the plan moves toward a documented target; as-is says it moves away from a documented baseline; null says neither, and a plan built against nothing still looks entirely reasonable — ordered tiers, real evidence, plausible steps. That is why it needs stating rather than noticing. The fix is Phase 2.5, not a re-read of the plan.
• designDoc: "unchecked" is not "absent". unchecked means no --design-doc was passed, so the plan makes no claim either way; absent means the path was checked and nothing was there. Reading the first as the second invents a finding about the project (rules/negative-result-scope.md).
• Autonomy is not permission to improvise a mechanical check away. Mode A/B ask nothing because every fork they resolve either has a written rule with a mechanical check behind it, or goes through rule 0’s decide-and-record protocol — restate the goal, pick the option a mechanical check backs, apply, then run the SAME per-unit verification any other unit gets. What is never permitted is skipping that verification, or resolving a fork without leaving a chose/rejected/rationale trail in autoDecisions and the commit body — a resolution with no evidence that a decision was made is the failure this design is built to prevent, whether or not a named rule covered the fork.
• A zero count is not a verdict, and an absent count is not a zero. “REUSE x: repoint imports” over a file with zero TS importers is a silent no-op — the real work is a component re-point or an orphan delete, neither of which is an import change. And a subsystem whose importers nobody counted is not one with none (rules/negative-result-scope.md). Run verify-reachability.cjs first and decide on the pair (verdict, transitivelyReachable) — verdict: LIVE is one hop, so a component attached only to a prefab nothing nests or loads is LIVE and genuinely dead. UNKNOWN or transitivelyReachable: null means stop, not proceed: undeterminable is not permission.
• A shared description is not a shared mechanism. Before swapping an editor-attached component for a package one, prove the required component, the properties it mutates, and what it listens to all match. The measured false positive compiled clean and broke layout at runtime — invisible to every gate in this pipeline.
• Never fall back to file-based UUID rewriting when the editor is unavailable. Hard-stop instead. The fallback fails clean: the run reports success and the corruption surfaces later, in the editor, with nothing pointing back at the step that caused it.
• query_by_asset covers the OPEN scene only. Unopened prefabs and every other scene still need the file-based check. The two are complementary; running one and calling the question answered leaves a whole class of reference unexamined.
• Never treat “the file is there” as “the design doc is ours.” A doc inherited from another project is the one failure state that looks healthy to every check in this pipeline except the probe. Run probe-design-doc.cjs, act on a non-ok verdict by REPAIRING the doc, and never continue to Tier 2.5 on foreign / template-* / non-canonical because the findings underneath happen to look right — they are graded against another game’s architecture.

After the report — what to do next

A report is not a terminus. Every report-only run of this pipeline ends by naming the concrete next invocation — otherwise the operator is left holding a plan artifact with no stated disposition, and the apply path that already exists is reachable only by someone who already knew its name.

You just finished	Next action
Phase 0 (t1k-cocos-base-system-design)	t1k-cocos-playable-modularize-structure-audit <project-root>
Pillar A structure-audit	t1k-cocos-playable-modularize-reuse-scan <project-root>
Pillar B reuse-scan	t1k-cocos-base-architecture-patterns audit, then t1k-cocos-playable-modularize-refactor <project-root> --audit <structure-audit.json> --reuse <reuse-scan.json> --arch <architecture-audit.json>
Pillar C refactor — plan report	t1k-cocos-playable-modularize-refactor <project-root> --apply — the Phase-5 tier walk, one gated unit at a time. Procedure: references/end-to-end-runbook.md § “Phase 5 — apply, tier by tier”.
Phase 5 landed	t1k-cocos-playable-modularize-contribute <project-root> — only if something was tagged CONTRIBUTE or EXTEND (the usual case is neither; then go to the runbook’s § Wrap-up).
Mid-walk: a Tier 2 unit blocked on localahead-reuse-becomes-extend	t1k-cocos-playable-modularize-contribute <project-root> --mode update — release the package, then resume the walk at that unit. Runs before Phase 5 lands, per Rule 1.
Mode A bare run (unattended design pass)	t1k-cocos-playable-modularize <project-root> --implement — stated in the reply AND written into reports/IMPLEMENT.md. Clear the session first if you want to; the handoff is self-contained.
Mode B --implement — finished	t1k-cocos-playable-modularize-contribute <project-root> if anything was tagged CONTRIBUTE/EXTEND, else the runbook’s § Wrap-up. Also suggest (not invoke) t1k-cocos-base-doc-pass <src-dir> — see note below.
Mode B --implement — hard-stopped	The literal resume command from reports/implement-state.json → resume.command, after the stated blocker is cleared. Never re-plan mid-migration: order is positional and a re-plan renumbers the units.
Full-pipeline run (all four pillars in one invocation)	Whichever the run itself blocked on — name the one that applies, never both. A non-ok designDoc verdict or a non-empty blockers[] → repair the design doc per blockers[].repair (t1k-cocos-base-system-design <project-root> --state as-is for foreign/absent), re-probe, then the arch audit, then re-plan. Otherwise → the pillar C row’s --apply walk.

A finished --implement walk suggests a doc pass — it never invokes one. #325 — the walk just created new module seams and new public surface (extracted classes, rewritten imports, upgraded packages) that has no TSDoc yet, and that is exactly the moment t1k-cocos-base-doc-pass earns its keep: annotation coverage is cheapest to raise on code nobody has re-touched since the refactor landed, before it drifts further from what the code now does. State this in the final report as a suggestion (t1k-cocos-base-doc-pass <src-dir> — see its own argument-hint), not an automatic follow-on call: --implement never chains a second skill invocation on its own authority, and the operator decides whether this run is the moment to spend on documentation.

A full-pipeline run emits a combined report too. reports/modularize-<date>-<slug>.md, alongside — never instead of — the four per-pillar JSON artifacts, which downstream phases still consume by name. It obeys the same closing obligation as any pillar report, and its ## Next action comes from the row above rather than being composed ad hoc; a hand-written one is why a combined run could previously finish with no stated disposition at all.

In Mode A step 4b’s second obligation is discharged by the handoff, not by a question. The next action is still restated in the reply and still written into the artifact; reports/IMPLEMENT.md is what replaces the AskUserQuestion. That substitution is the only part of step 4b the unattended exemption touches — a Mode A run that ends without naming --implement has still not completed the phase.

Naming the next action is step 4b, and step 4b fires on every run — report-only included. The table above is the lookup; references/shared-cli-contract.md § “Step 4b” is the obligation: restate the next action in the reply, then open an AskUserQuestion (next-phase / apply-this / review-first). A run that writes the report and ends the turn silently has not completed the phase — the operator is left with a file and no decision, and the apply path that already exists stays reachable only by someone who already knew its name.

Put the line in the artifact, not only here. The emitted markdown must close with its own next-action line so the report is self-describing to someone who reads it later without having run it. That obligation is contract-level for all four pillars — references/shared-cli-contract.md § “Report + exit format” — and the concrete plan-report instance is t1k-cocos-playable-modularize-refactor/references/report-format.md § “Next action”.

--continue — attended report → apply, one invocation

--continue chains the report straight into the Phase-5 tier walk, so the operator does not re-invoke a different sub-skill by name for every tier. It automates the re-invocation and nothing else.

It is attended, never unattended. Every gate in references/shared-cli-contract.md fires unchanged:

• --continue implies --apply for the walk. Report-only remains the default; the flag is the explicit opt-in to mutate, and a bare run still never touches the project.
• Gates are not weakened, batched, or pre-answered. Each unit stops at its own AskUserQuestion. High-blast-radius steps — Tier 2.5 extractions, any .meta move, Tier 3 submodule→CPM — still require proceed-one-unit; --continue may never convert one into a bulk proceed.
• abort at any gate ends the run. It does not fall through to the next unit or the next tier.
• A failed verification stops the walk. Per-unit verification is unchanged (tsc, verify-imports.cjs --scenes, and the editor scene-ref confirmation where the tier demands it); it is not skippable because a walk is in progress.
• Tier order is never reordered or skipped, and there is no mid-walk re-planning — a finding that surfaces during the walk is recorded and re-planned in a fresh pass (plan-refactor.cjs runs once).
• The post-apply change + status report is still REQUIRED, exactly as for a manual apply (report-format.md § 2). A --continue run that mutates and leaves no record is a contract violation.

Unattended — when it is safe, and exactly why

Unattended operation is safe here to precisely the degree the checks are scripts rather than improvisation. That is the whole condition, and it is worth stating why, because this skill used to say there was deliberately no unattended mode at all — on the grounds that the two failure modes the runbook documents (Tier 2.5 breaking scene refs invisibly; Tier 2.5 without Tier 2.75 being a net loss) are caught by a human at a gate and not by tsc.

Half of that reasoning survives and half does not. A measured run (2026-08-20) got 4 of 5 Tier 1–2 steps wrong as written. The human answered four gate questions and took the recommended option three times, and the gate caught none of the four. Every one was caught by a mechanical check instead. So the gate supplied latency; verification supplied the safety.

The correct conclusion is therefore not “remove the gates” but “replace human gates with mechanized ones”:

Failure the gate was there to catch	What actually catches it
Tier 2.5 breaks scene refs tsc cannot see	editor probe + query_by_asset / query_has_script + the file-based scene check, per unit
Tier 2.5 without Tier 2.75	dependsOn in the plan — the seam re-scan is a unit, not a habit
”repoint imports” over a file nobody imports	verify-reachability.cjs — attachment, prefab nesting, resources.load(), and transitivelyReachable for whether any of those leads to a root
a swap justified by description similarity	mechanism-equivalence proof, or the verdict is retracted
normalizing a deliberate deviation	the declared-deviation check → report-only

Two modes follow from that, and both keep report-only as the default for assets/:

Mode	Invocation	What it does
A — design	t1k-cocos-playable-modularize <project-root>	Every phase including 3.5, zero questions. Emits every existing artifact plus reports/IMPLEMENT.md. Mutates nothing under assets/.
B — execute	t1k-cocos-playable-modularize <project-root> --implement	Walks the plan’s unattended.walkOrder in a session with no prior context: probe → pre-verify → apply → verify → git commit → record state, per unit.
B+ — execute incl. manual queue	t1k-cocos-playable-modularize <project-root> --implement --force-manual-queue	As Mode B, but a manualQueue unit is attempted rather than hard-stopping the walk (hard-stop trigger 6). Verification is unchanged. Tier 0 design-doc-blocked rows are still never attempted.

Three things this does not change, on purpose:

• --apply and --continue are untouched. --continue remains the attended walk, gate for gate. Nothing here repurposes it, and --attended restores the old bare-run behaviour for anyone who wants the questions back.
• The blocks still block. A blockedBy step, a Tier 0 BLOCKED row, an unreachable editor on an open unit — none of these are relaxed by autonomy. They route to the manual queue or hard-stop.
• Nothing goes unrecorded. Every auto-decision carries the alternative it rejected; every unit carries a commit naming its plan unit; every stop carries a state file and a literal resume command.

A fork no NAMED rule covers is resolved and recorded (decision-policy rule 0’s decide-and-record protocol), not escalated — only a genuine verification failure still hard-stops. Rules: references/decision-policy.md — including the stated, conditional exemption from rules/ask-before-deciding.md. Procedure: references/unattended-implement.md.

Phase 3.5 now runs by itself

This is the change that makes Mode A actually finish. The pipeline used to stop at a state: as-is design doc and ask a human to confirm the target modules, which is why a real run had to be hand-driven from there on. Mode A auto-selects the target module table (decision-policy rule 7 — start from as-is, remove what a REUSE/EXTEND deletes, split where a finding names a boundary, add one module per exposed seam, defer the rest explicitly, never invent a module no input names), authors the to-be doc, regenerates the manifest, and re-plans until designState: to-be.

Note the asymmetry with the design-doc probe, which is deliberate: which modules the target has is a decision with documented inputs, so it can be made mechanically. Whether the doc describes this project at all has no such input — so that verdict still blocks.

The handoff

Mode A ends by writing reports/IMPLEMENT.md — self-contained, absolute paths throughout, and readable by a session that has never seen this one. It carries the plan path, the branch, the ordered unit list with editorState per unit, the per-unit verification commands, the commit convention, the hard-stop list, the manual queue (Tier 0 blocked steps and everything else needing a human), and the exact resume command. Its tables are generated from the plan JSON, never hand-written — a hand-written manual queue is how a blocked step goes missing and reads as handled.

Then clear the session. t1k-cocos-playable-modularize <project-root> --implement is a complete brief on its own; reports/implement-state.json is what makes a re-run resume at the first unlanded unit rather than at the beginning.