M4b review of tasks 16 to 18; tip T32

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-09-24 12:22:24 -07:00
co-authored by Claude Opus 5.5
parent a43d9979c8
commit bfbdccb99d
2 changed files with 20 additions and 0 deletions
+1
View File
@@ -66,6 +66,7 @@ How it is used:
| T29 | Check a skeleton's comments, not only its code. Print every `todo!()` beside its signature and read each pair before hand-over. Filling the bodies from your own code proves the split can pass; it cannot show that a comment sits on the wrong function. Edit comments by function, never by "the next comment after this name". And tell the implementer to stop and quote a comment that does not fit. | M4a task 14, second session: `post`'s comment was `now_ms`'s text, put there by a script; Ornith saw the contradiction and deliberated over it until the turn ran out. M4a task 16: a comment naming the function it replaced made the task's own `grep` fail; and a given test copied into the plan before `cargo fmt` came back reformatted. Run the task's checks, and `cargo fmt`, on the end state before hand-over. |
| T30 | Every behaviour a task writes must be reachable by that task's own tests. When a function's effect shows only after a later task (here: a refusal's reason, which only task 15 could send), give a unit test in the first task, or write that function in the later one. And never let one name mean two things in a comment: say which `reason`. | M4b task 14 dropped a refusal's reason, reading `Refused -> Ended::Refused { by, reason }` as the `DenyReason` in scope; its tests passed, and task 15's caught it, in a file task 15 could not touch. |
| T31 | In a spec, for every post or message the harness sends, name who can read it and whether that reader can act on it. Walk each kind of sender through each kind of channel (the owner, an allowed non-approver, a stranger; direct, group, channel). | M4b: an approval asked by a non-approver in a direct message went into that direct message, where no approver could see it. Every test passed, because the tests used the spec's cases; the device check with a second account found it (review finding 1, fixed by tasks 17 and 18). |
| T32 | A given test must not assert the order of two things that run on their own threads. Check the order where it is decided (here, the sort in the catch-up parser), and compare what the threads deliver as a set. Before hand-over, stress each test with concurrency under load (`yes > /dev/null` beside a loop of 60 runs). | M4a's `serve_restart` expected two caught-up sessions' turns to reach `loopd` in order. They run on separate threads, and under load 1 run in 60 failed. M4b task 18's session hit it, proved it happens without its change, and reported it instead of editing the test. |
## What worked and should be kept
+19
View File
@@ -648,3 +648,22 @@ right.
**The run.** Task 15's first session stopped on finding 4. After the listed fix, task 15 finished
on its first session.
### M4b, tasks 16 to 18 — reviewed 2026-09-24 by the design model (Claude)
Accepted. Findings 1 and 2 of the review above are closed in code; finding 1 still needs the check
on the owner's server, with the second account sending a direct message. The three commits carry
the trailer. The given tests are identical to the plan. The code in `crates/` is byte-identical to
the reference. `make gate` gives `gate: ok` with 854 tests, the count the plan gave.
Tasks 16 and 17 passed the gate on their first run. Task 18 needed six runs, and none of the
failures was in its own code. Once, `serve_restart`'s
`a_restart_reports_the_cut_off_turn_and_catches_up` (a given test from M4a) failed with the two
caught-up turns in the wrong order. The session handled it well: it did not edit the given test,
and it did not change code outside the task. It showed the failure also happens without its
change (40 of 40 and 30 of 30 runs under load), and reported it in the log row.
The fault was the design model's, in M4a. Those two posts are two sessions, whose turns run on
their own threads, so the order they reach `loopd` is up to the scheduler: under load, 1 run in 60
failed. `mm_json.rs` already checks the order of catch-up, so the test now compares the two turns
as a set (a43d997; 100 of 100 runs under load; tip T32).