Coach TODOs shipped: specs as DOCS, residue TODO

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WzxdWWcbzoov1KFZJSFcSs

leetcode_coach/leetcode_coach/DOCS-clients.md

@@ -16,7 +16,7 @@ itself, history intact, on "You've hit your ... limit". With no hooks there,
 are withheld. Everything above `## Model and client` is its system prompt,
 minus section 1. `python3 -m leetcode_coach.eval_local`: acceptance run.
 
-## The req-before-code gate (TODO-coach.md decisions 4-8)
+## The req-before-code gate (DOCS-coach-spec.md decisions 4-8)
 
 Both REPL paths run `phase.PhaseGate` on every block kuhy sends:
 

leetcode_coach/leetcode_coach/SKILL.md

@@ -170,7 +170,7 @@ After the loop is closed, in the same reply:
 1. Ask kuhy for the requirement list as *properties* (what must vanish, what
    must survive, how much space), not code or an operation name; then, for
    every hint rung kuhy saw, which requirement that hint handed over.
-2. Cards are **property -> operation only** (TODO-coach.md decision 11): one
+2. Cards are **property -> operation only** (DOCS-coach-spec.md decision 11): one
    per toolbox entry the solution relied on, generated from `toolbox.json`
    (front = its properties, back = its name), in ONE Bash call:
    ```bash

leetcode_coach/leetcode_coach/answer_key.py

@@ -1,4 +1,4 @@
-"""The grader's answer key (TODO-coach-ui.md decision 5), from ``answer_key.json``.
+"""The grader's answer key (DOCS-coach-ui-spec.md decision 5), from ``answer_key.json``.
 
 Schema: ``{"problems": {"<slug>": {"design_rule", "entries", "also_accepted",
 "key_requirements", "postmortem_points"}}}``, one entry per cluster problem.

leetcode_coach/leetcode_coach/cluster_cli.py

@@ -1,6 +1,6 @@
 """`leetcode due`, `leetcode --cluster <name>` and `leetcode --retest <slug>`.
 
-TODO-coach.md decisions 10 and 12, on top of `progress` (which derives
+DOCS-coach-spec.md decisions 10 and 12, on top of `progress` (which derives
 everything from the session logs):
 
 * ``due`` lists the cold re-tests that are due (+3 and +10 days after a solve).

leetcode_coach/leetcode_coach/leak.py

@@ -1,4 +1,4 @@
-r"""Which toolbox entries a coach reply names (TODO-coach.md decision 7).
+r"""Which toolbox entries a coach reply names (DOCS-coach-spec.md decision 7).
 
 Until kuhy's first code, a reply that names an operation from the toolbox --
 its name or any alias, e.g. "XOR", "^", "hash map" -- hands over step 3 of the

leetcode_coach/leetcode_coach/phase.py

@@ -1,6 +1,6 @@
 """The req-before-code phase gate, run by the REPL on both paths.
 
-TODO-coach.md decisions 4-6: a message starting ``req:`` is kuhy's
+DOCS-coach-spec.md decisions 4-6: a message starting ``req:`` is kuhy's
 requirement list. Until one is accepted, a block that is code is refused
 here, with a one-line reason, and never reaches the coach model. A list is
 accepted when the checker passes it or cannot judge it (fail open); after the

leetcode_coach/leetcode_coach/progress.py

@@ -1,6 +1,6 @@
 """Cluster progress and the cold re-test schedule, derived from the session logs.
 
-TODO-coach.md decisions 10 and 12. Nothing here keeps state of its own: the
+DOCS-coach-spec.md decisions 10 and 12. Nothing here keeps state of its own: the
 JSONL session logs (``<YYYY-MM-DD>-<slug>.jsonl``, decision 8) are the only
 record, so progress survives anything that survives the logs.
 

leetcode_coach/leetcode_coach/req_check.py

@@ -1,6 +1,6 @@
 """Judge kuhy's requirement list, and ambiguous code, on a cheap model.
 
-TODO-coach.md decision 5: a separate ``claude -p --model haiku`` call (the
+DOCS-coach-spec.md decision 5: a separate ``claude -p --model haiku`` call (the
 coaching session stays on sonnet), Ollama through `local_backend` when haiku
 is out of quota, errors or answers something that is not the JSON asked for,
 and when neither answers the gate fails OPEN: ``unverified``, kuhy continues.

leetcode_coach/leetcode_coach/session_log.py

@@ -1,4 +1,4 @@
-"""The coach's per-problem session log (TODO-coach.md decision 8).
+"""The coach's per-problem session log (DOCS-coach-spec.md decision 8).
 
 One JSONL file per problem and day,
 ``~/.local/share/leetcode-coach/sessions/<YYYY-MM-DD>-<slug>.jsonl`` (the

leetcode_coach/leetcode_coach/tests/_relay_flow.py

@@ -1,6 +1,6 @@
 """The spec's scripted session, run the same way over either transport.
 
-TODO-coach-ui.md "Done": start Missing Number, each graded step answers
+DOCS-coach-ui-spec.md "Done": start Missing Number, each graded step answers
 pass/partial/fail with feedback, the next step is blocked until a pass or
 the 3rd try, the chat round-trips, Hint logs a rung, run-code runs on real
 node, a simulated Accepted passes step 4 within one poll, the post-mortem is

leetcode_coach/leetcode_coach/tests/test_answer_key.py

@@ -1,4 +1,4 @@
-"""Tests for the answer key (TODO-coach-ui.md decision 5).
+"""Tests for the answer key (DOCS-coach-ui-spec.md decision 5).
 
 The key is grader-internal: nothing in it is displayed. Even so, the design
 rule and the post-mortem points are what the grader's feedback is built from,

leetcode_coach/leetcode_coach/tests/test_coach_e2e.py

@@ -1,4 +1,4 @@
-"""Scripted end-to-end runs of the req-first coach (TODO-coach.md "Build done").
+"""Scripted end-to-end runs of the req-first coach (DOCS-coach-spec.md "Build done").
 
 The REPL runs in-process against a fake `claude` binary (LEETCODE_CLAUDE_BIN,
 a real subprocess per turn) and a fake Ollama on a localhost port, with

leetcode_coach/leetcode_coach/tests/test_relay_boundary.py

@@ -1,4 +1,4 @@
-"""No relay route reaches the ledger (TODO-coach-ui.md decision 2, contract 4).
+"""No relay route reaches the ledger (DOCS-coach-ui-spec.md decision 2, contract 4).
 
 Walks the import closure of every ``leetcode_coach.relay`` module by AST --
 through ``leetcode_coach`` and ``leetcode_guard`` alike, ``TYPE_CHECKING``

leetcode_coach/leetcode_coach/tests/test_relay_e2e.py

@@ -1,4 +1,4 @@
-"""TODO-coach-ui.md "Done", desktop path: the scripted session over loopback.
+"""DOCS-coach-ui-spec.md "Done", desktop path: the scripted session over loopback.
 
 The flow and its assertions live in ``_relay_flow``; here it runs over the
 real HTTP API on port 0, with the guard's paths redirected (so the data dir

leetcode_coach/leetcode_coach/tests/test_relay_phone_e2e.py

@@ -1,4 +1,4 @@
-"""TODO-coach-ui.md "Done", phone path: the scripted session through RTDB.
+"""DOCS-coach-ui-spec.md "Done", phone path: the scripted session through RTDB.
 
 The phone PUTs ``requests/{rid}/req`` into an in-process fake RTDB (REST +
 SSE) and polls ``requests/{rid}/result``; the relay streams the requests and

leetcode_coach/leetcode_coach/toolbox.py

@@ -1,4 +1,4 @@
-"""The operation toolbox (TODO-coach.md decision 9), read from ``toolbox.json``.
+"""The operation toolbox (DOCS-coach-spec.md decision 9), read from ``toolbox.json``.
 
 Schema: ``{"entries": [{"name", "aliases": [...], "properties": [...]}],
 "properties": {"<prop>": "<one-line meaning>"}}``. Every entry property is a

leetcode_coach/leetcode_coach/toolbox_cards.py

@@ -1,6 +1,6 @@
 """Toolbox entries as post-mortem cards, and the one way to grow the toolbox.
 
-TODO-coach.md decision 11: post-mortem cards are property -> operation only.
+DOCS-coach-spec.md decision 11: post-mortem cards are property -> operation only.
 The front lists an entry's properties, the back is its name, so the card asks
 "which tool has exactly these properties?". All cards share the fixed slug
 ``toolbox``: the card builder derives a note's guid from (slug, front), so one