pastilhasandClaude Opus 5
43cb531dc2
the skill told an agent how to hand-write a .ics: escape the commas, fold at 75 octets, CRLF, DTSTAMP is required, and DTEND is the day after. all true, all silent when wrong, and the browser had learned the same lesson separately in its own copy of the code. this makes the sidecar the only thing that knows the format, and gives everyone else fields. WHAT WAS MISSING BEFORE THE SKILL COULD CHANGE. reading was already JSON, and create-event landed this morning. this adds PATCH /_officer/item — change some fields of an event or a card — and POST /_officer/contact. delete already worked. with those the skill has no reason left to mention iCalendar, so it does not. PATCH IS READ-PATCH-PUT, SERVER SIDE. it reads the stored text, replaces only the lines it owns, and puts the whole thing back, so alarms, attendees, RRULEs and every X- property a phone invented survive an edit made from a form that cannot show them. that logic came out of the browser, where it had needed a duplicate of the escaping and folding rules to live; the agent would have been a third copy in bash. the web bundle now contains no iCalendar literals at all. AND LIVE TESTING FOUND THE BUG THAT MATTERS. an event with a TZID is stored with a VTIMEZONE block beside it, and that block has DTSTART lines of its own — the rule for when summer time starts. taking the first DTSTART in the file rewrote the TIMEZONE DEFINITION, left the event where it was, and answered ok. the calendar showed the old time and the file was quietly corrupt. every write is now confined to the first VEVENT or VCARD, and the file that caught it is a test. three more traps handled rather than documented: a patch that reuses an all-day event's stored DTEND must subtract the exclusive day first or the holiday drifts every time the title is edited; moving a timed event must DROP a stale TZID rather than preserve it, because a TZID and a Z together are a contradiction clients resolve by moving the event; and a move bumps SEQUENCE, which is how a phone tells an update from a duplicate. contacts got the create form the calendar had, so both screens now do all four. editing a card sends the other emails and phones back untouched — the form shows the first of each, and sending only that would delete the rest. 47 tests across the writer and the patcher. verified live against a real event carrying an alarm, an attendee, an RRULE and an X- property: all four intact after a rename, a relocation and a move to a different day. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
Calendar
Calendars and contacts on your own machine, synced to your phone over CalDAV and CardDAV.
- Radicale, not a container. A ~2MB Python package, spawned on loopback by this plugin's sidecar. It was a Docker service only because the old app store made everything one.
- Per user. The sync door resolves an app password to one account and tells Radicale that account's id
is the principal;
[rights] type = owner_onlydoes the rest. Every user gets their own calendars and their own contacts, in their own directory, invisible to everyone else. - Phones work. DAVx5, iOS and Thunderbird, including RFC 6764 autodiscovery from a bare domain.
Two screens, one plugin
/calendar and /contacts. They are two places you go rather than two sections of one page, which is why
this is the first plugin to declare screens in its manifest — one sidecar, one permission, one install,
two routes and two dock tiles.
What it claims from the platform, and why
Four paths outside /api, above the account gate:
| Path | Why it cannot sit behind the session |
|---|---|
/dav/* |
DAVx5, iOS and Thunderbird send HTTP Basic on every request and have nowhere to put a JWT |
/dav/provision/*.mobileconfig |
Safari is handed a URL by the phone app and has no credential; the one-shot token in the path IS the authentication |
/.well-known/caldav |
RFC 6764 — probed with a bare domain before the client has any credential |
/.well-known/carddav |
the same, for contacts |
"Above the account gate" is not "open". The sync door demands a scoped DAV app password and resolves it to a user before anything reaches Radicale.
Every one of those is in the platform's RESERVED_ROOT, claimable only by a first-party plugin. A
third-party plugin is confined to /p/<publisher>/ so it can never shadow a core route.
Extracted from the platform on 2026-08-27
It was core from 2026-08-19. What moved: the sidecar, the four routers, the panel apps, the app-password table, and the settings form — which became a modal on the Calendar screen, because a plugin ships panels and cannot contribute a settings section.
Two things deliberately did not change. The table is still dav_app_passwords rather than
caldav_app_passwords: installs already hold real rows, and the platform's prefix convention is not worth
a data migration on a live machine. And the panel names still resolve through the platform's translation
catalogs, so the six locales they had as core screens survive.