feat(loop): track loop progress in durable chat tasks, not PROGRESS.md

[cuongtranba]

What

An autonomous loop's plan now lives in event-sourced per-chat task state, read and written through the mcp__kanna__task_* tools, instead of a markdown tracking file. A loop no longer creates, reads, or writes PROGRESS.md.

Why this could not be a prompt change

The loop /clears main on every wake. That nulls the session token — so the next turn is a brand-new CLI session whose own task list is empty and TaskList returns nothing — and it tripped the client reducer's wipe on context_cleared. Three more blockers stacked on top:

• worker subagents write to subagent_entry_appended on the run, never the parent chat's transcript;
• the PTY driver passes no --tools, so it had no native Task tools at all;
• the card only folded the loaded transcript page, so a long loop's task_create scrolled out of the window.

Underneath all four: there was no server-side task state whatsoever.

How

• Durable store — src/shared/chat-tasks/** (types, pure scheduler, projection, compaction, native mirror, seed, tracking-file import) on a new chat-tasks event log, folded into StoreState and the snapshot. Survives /clear, restart, and the tail window.
• mcp__kanna__task_* — create/update/list/get/note/claim/settle/integrate, registered wherever a chatId is present, so a worker subagent's writes land on the parent chat and PTY gets a working surface.
• Native CLI Task calls are mirrored, not blocked, under an n: id namespace beside Kanna-minted k:. On context_cleared native tasks are marked stale, not deleted — the CLI really did forget them, but deleting loses visible history.
• Both loop prompts, both invariant lists, setup_loop, the wake prompt and the Progress card move onto tasks. The wake now carries a rendered <loop-state> snapshot. setup_loop seeds from a tasks argument or chunk_hint, and imports an existing tracking file once.
• One unified footer card — TaskProgressSection merged into LoopProgressSection; titled "Progress" when armed, "Tasks" otherwise.

Bugs found and fixed along the way

1. The claim was not actually atomic. EventStore.append applies state after the disk write, so two concurrent claims could both read stale state and take the same task. Fixed with decideChatTaskEvents, which runs the read-decide-append inside the per-chat write chain. Verified the regression test catches it — reverting the fix makes both workers get the same task id.
2. An unconditional await I added to appendMessage — the hottest write path — destabilised a timing test. Now conditional on there being events to append.
3. Pre-existing: resume_loop dropped parallelism, silently demoting a resumed parallel loop to serial.

Removed

claim_tracking_task / complete_tracking_task / integrate_tracking_tasks, shared/loop-task-queue.ts, the loop-tracking registry / sync / io adapters, and the file-based reconcile and skeleton. query_tracking_file, append_tracking_row and replace_tracking_section stay for the non-loop durable-document use CLAUDE.md documents.

Net −2300 lines.

Budgets

• deps-bundles re-baselined 85 → 83 (TaskQueueToolDeps and its adapters deleted; ChatTaskToolDeps added).
• max-params lowered 12 → 11 in both eslint.config.js and ESLINT_LIMIT_PINS — removing getLoopTracking took deriveChatSnapshot to 11, and lint:limits requires the ceiling stay tight.

Verification

bun run check, bun run test (8260 pass, 0 fail), lint:comments, lint:usestate, lint:limits, check:arch, bunx ast-grep test, check:commits — all green locally.

Follow-up needed

c3x is not installed in this environment and a c3-seal cannot be computed by hand, so the ADR (adr-20260918-loop-tasks-replace-tracking-file, referenced in CLAUDE.md and the skill) and the .c3/ component bindings for the new modules still need a c3x add adr + c3x repair pass. The deleted loop-task-queue.ts binding was removed from the unsealed code-map.yaml / eval/c3-210.yaml.