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
This commit is contained in:
Krzysztof Rudnicki 2026-11-01 22:05:40 +01:00
parent 99f4e171e3
commit 1bfacdf51f
17 changed files with 17 additions and 17 deletions

View File

@ -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, are withheld. Everything above `## Model and client` is its system prompt,
minus section 1. `python3 -m leetcode_coach.eval_local`: acceptance run. 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: Both REPL paths run `phase.PhaseGate` on every block kuhy sends:

View File

@ -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 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 must survive, how much space), not code or an operation name; then, for
every hint rung kuhy saw, which requirement that hint handed over. 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` per toolbox entry the solution relied on, generated from `toolbox.json`
(front = its properties, back = its name), in ONE Bash call: (front = its properties, back = its name), in ONE Bash call:
```bash ```bash

View File

@ -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", Schema: ``{"problems": {"<slug>": {"design_rule", "entries", "also_accepted",
"key_requirements", "postmortem_points"}}}``, one entry per cluster problem. "key_requirements", "postmortem_points"}}}``, one entry per cluster problem.

View File

@ -1,6 +1,6 @@
"""`leetcode due`, `leetcode --cluster <name>` and `leetcode --retest <slug>`. """`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): everything from the session logs):
* ``due`` lists the cold re-tests that are due (+3 and +10 days after a solve). * ``due`` lists the cold re-tests that are due (+3 and +10 days after a solve).

View File

@ -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 -- 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 its name or any alias, e.g. "XOR", "^", "hash map" -- hands over step 3 of the

View File

@ -1,6 +1,6 @@
"""The req-before-code phase gate, run by the REPL on both paths. """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 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 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 accepted when the checker passes it or cannot judge it (fail open); after the

View File

@ -1,6 +1,6 @@
"""Cluster progress and the cold re-test schedule, derived from the session logs. """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 JSONL session logs (``<YYYY-MM-DD>-<slug>.jsonl``, decision 8) are the only
record, so progress survives anything that survives the logs. record, so progress survives anything that survives the logs.

View File

@ -1,6 +1,6 @@
"""Judge kuhy's requirement list, and ambiguous code, on a cheap model. """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 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, 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. and when neither answers the gate fails OPEN: ``unverified``, kuhy continues.

View File

@ -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, One JSONL file per problem and day,
``~/.local/share/leetcode-coach/sessions/<YYYY-MM-DD>-<slug>.jsonl`` (the ``~/.local/share/leetcode-coach/sessions/<YYYY-MM-DD>-<slug>.jsonl`` (the

View File

@ -1,6 +1,6 @@
"""The spec's scripted session, run the same way over either transport. """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 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 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 node, a simulated Accepted passes step 4 within one poll, the post-mortem is

View File

@ -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 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, rule and the post-mortem points are what the grader's feedback is built from,

View File

@ -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, 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 a real subprocess per turn) and a fake Ollama on a localhost port, with

View File

@ -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 -- Walks the import closure of every ``leetcode_coach.relay`` module by AST --
through ``leetcode_coach`` and ``leetcode_guard`` alike, ``TYPE_CHECKING`` through ``leetcode_coach`` and ``leetcode_guard`` alike, ``TYPE_CHECKING``

View File

@ -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 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 real HTTP API on port 0, with the guard's paths redirected (so the data dir

View File

@ -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 + 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 SSE) and polls ``requests/{rid}/result``; the relay streams the requests and

View File

@ -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": [...]}], Schema: ``{"entries": [{"name", "aliases": [...], "properties": [...]}],
"properties": {"<prop>": "<one-line meaning>"}}``. Every entry property is a "properties": {"<prop>": "<one-line meaning>"}}``. Every entry property is a

View File

@ -1,6 +1,6 @@
"""Toolbox entries as post-mortem cards, and the one way to grow the toolbox. """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 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 "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 ``toolbox``: the card builder derives a note's guid from (slug, front), so one