None of the 47 existing readings have a token - they all predate it. A
reading read from the database therefore has an EMPTY token, and the
guard was checking `expected_token is not None`, which is TRUE for an
empty string. So the write was conditioned on a token that does not
exist, matched nothing, and **the advice would never have been written
for any of the existing readings**.
Verified against the live database, before the fix:
write with expected_token='' -> 0 (0 = the advice would NEVER be written)
After:
write for a pre-token live reading: 1 (must be 1)
An empty token is now not a usable guard - there is no token to match -
so the write falls through to the gravity check instead. A non-empty
token is still the primary guard.
There is a test for it, with a reading inserted the way the existing
ones are - directly, with no token.
178 tests (up from 177).
hermes
7d9d718b41