Two findings from the re-review of PR #14.
A race that recreated the leak
-------------------------------
`get_shared_repository()` did an unsynchronised check-then-set on a
module global. Eight concurrent advice threads on a cold process each
saw None and each built their own repository - so eight MongoClients and
twenty-five threads. The fix that was meant to remove the leak
reintroduced it, just bounded by a race instead of by the number of
readings.
Measured before: 8 repositories built, 25 threads.
Measured after: 1 repository built, 4 threads.
There is a lock, and the check is repeated inside it.
The prompt was about the wrong reading
--------------------------------------
The advice targeted the right reading, but the PROMPT said "give advice
for the most recent reading" - and when the brewer corrects an OLDER
reading, the most recent one in the history is a different reading. So
the model was asked about the wrong number while the advice was filed
against the right one.
The reading is now named in the instruction (with its date and gravity),
marked in the reading list as the one to advise on, and the system prompt
says to advise about the marked reading because it may not be the most
recent one.
A corrected reading is also flagged as such, so the model knows it may
differ from what it said before.
167 tests (up from 164).
hermes
0011f30e59