error-recovery

Error Recovery Rules

Lesson-Queued Marker Handling

When you see a system-reminder containing [t1k:lesson-queued] entries, you MUST spawn a background sub-agent per entry.

type=lesson → use the /t1k:sync-back skill to draft a PR updating the target skill/fragment in its origin kit repo.
type=skill-bug → use the /t1k:issue skill to file a GitHub issue on the origin kit repo with the bug evidence.
type=mcp-gap → /t1k:issue against the MCP fork repo named in the reminder (e.g., The1Studio/unity-mcp), NOT the kit. Reminder shows → file issue on <repo>. Title: [mcp-gap] <tool>: <one-line gap>.

Invocation pattern (background spawn, brief contents) and failure/writeback handling: skills/t1k-sync-back/references/queue-writeback.md and skills/t1k-issue/references/queue-writeback.md.

Feature-flag scope

autoLessonSync gates the SAME check at both lesson-collector.cjs (write into the queue) and lesson-queue-processor.cjs (the reminder that surfaces [t1k:lesson-queued]) — you cannot see this marker with the feature off. If you ever do, treat it as a bug ([t1k:skill-bug ...]), not as something to act on trustingly.

Kit-Update-Repair Marker Handling

On [t1k:kit-update-repair] (a SessionStart frame from check-kit-update-failures.cjs), spawn TWO background sub-agents — one per install scope (scopes="global,project"). Each agent: re-runs t1k modules update --yes for its OWN scope (global cwd=$HOME, project cwd=<project root>; the runner has no per-scope attribution — each scope re-discovers its own error), reads the remedy table at docs/kit-update-repair.md, attempts the known remedy, verifies by re-running the scope command, and exits fast as a clean no-op when its scope is healthy. Do NOT file an issue — the [t1k:auto-issue] path already queued one; this is repair, not reporting. Inert when autoIssueSubmission: false / dry-run / telemetry-off (the frame can never fire then).