-
v0.8.3
Stablereleased this
2026-08-09 20:53:43 -05:00 | 97 commits to main since this releasecreate_eventandlist_eventsdescribed the same all-day event two different
ways. Found by running A9 against the live account.Fixed
-
An all-day
endis reported the same way by every tool. The same event,
in two responses:create_event → end: 2026-08-10T23:59:59.999999-05:00 (inclusive last day) list_events → end: 2026-08-11T00:00:00-05:00 (exclusive boundary)build_veventnormalises an all-day end to the exclusive next-dayDATE, but
create_eventbuilt its reply from the arguments it was handed rather than
from the document it had just written, so it echoed the input convention while
every read reported the stored one. Nothing in either response said which was
in hand.The round trip is what made it a footgun rather than a cosmetic difference:
take an end from a response, shorten it to a date, hand it back as the last
day, and the event grows by one — on every edit, silently.create_eventnow parses back the document it wrote, through the same
parse_singlethat reads. Not a patch to the arithmetic: one code path, so
the two cannot drift apart again. Responses are exclusive everywhere, and
handing a reportedendstraight back is now exact.
Changed
-
create_event's description says a timed event must carry a length.end
andduration_minutesare both optional in the schema — because which one
you send is a choice — but omitting both is an error, and nothing said so up
front. It now does, and tells the model to ask rather than invent a duration. -
It also states that responses report
endexclusively, and to pass the
value back verbatim rather than shortening it to a date.
Testing
The fake now makes a created event readable afterwards, which is what lets a
test compare whatcreatesaid against what a later read reports. That
comparison was impossible to express before, which is why three releases shipped
with the two disagreeing. Reverting the fix fails three tests.Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads
-