Record emsha and the M2 split; add dependency-vetting lesson

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-17 12:27:52 -07:00
parent 362f962803
commit eb1b7d2da2
2 changed files with 3 additions and 0 deletions
@@ -34,6 +34,7 @@ How it is used:
 | T5 | A reference implementation proves the tests can pass. It does not prove they are complete: reference and tests share the author's blind spots. Probe the finished work from outside with inputs the tests do not contain. | Findings 2 and 3 were in the reference too. Both were found by probing, not by the gate. |
 | T6 | Do not tell the implementer how to lay out what a formatter controls. | M1 finding 7. |
 | T7 | A follow-up task works well as: what the reviewer observed, which part was the task's fault, a failing test to copy in, and the new rules. | Tasks 08 and 09 each passed the gate on the first run, and 09 handled six forms its self-test did not contain. |
+| T8 | Vet a dependency by testing it against an independent implementation before naming it in a spec, whoever wrote it. Include the boundary cases of its algorithm. | The owner's `emsha` 1.0.3 passed its own tests and hashed every message of length 63 mod 64 wrongly. A 90-case differential run against `sha256sum` found it in minutes. Same shape as T5: an author's tests share the author's blind spots. |

 ## What worked and should be kept