43cb531dc2943f76e9da7b39faf6862e10788692
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  pastilhasandClaude Opus 5
|
43cb531dc2 |
one CRUD, three callers — the browser and the agent stop writing iCalendar
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 |
||
|
pastilhasandClaude Opus 5
|
25c8502c4b |
create an event, newest day first, and a URL you can read
three small things, one of which turned out to be a bug in what shipped an hour ago. CREATE. a POST to /_officer/event, and the SIDECAR builds the file — the browser sends title, when and where. a UID, a DTSTAMP and a UTC timestamp each have exactly one correct form, and that belongs next to the parser that reads them back, not in a react component. it writes the minimum a VEVENT can legally be: no recurrence, no alarms, no attendees. this app cannot show those, and a field the list cannot display is a field that silently disappears on the next edit. times go in as UTC. the alternative is DTSTART;TZID plus a VTIMEZONE block defining that zone's rules, and a subtly wrong VTIMEZONE moves an event by an hour twice a year. UTC needs no definition and every client renders it local. all-day is the other trap: RFC 5545 makes DTEND EXCLUSIVE, so a one-day event on the 29th ends on the 30th — write the 29th and some clients draw nothing at all. the form takes the last day a person means and the builder adds the day. NEWEST DAY ON TOP. a calendar accumulates years, so ascending opened on whatever was imported first and this week was a scroll away. within a day the order stays chronological, because that is what a day is. ?collection=ra-guide, NOT ?collection=%2Fdav%2F1%2Fra-guide%2F. the path is /dav/<userId>/<name>/, so the escaped form spent six characters on slashes to say `ra-guide` and put the owner's user id in a URL people paste at each other. the name is unique within a user, which is all a selector needs, and the full path is recovered from the collections list the screen already loaded. a full path in the param still resolves, because somebody's bookmark has one. AND THE BUG. setProperty replaced a property's first line and left its continuation lines behind. a value over 75 octets is FOLDED onto lines starting with a space — so editing a long summary left the old tail folded onto the new value, and each edit inherited the last one's ending. it only bites on long values, which is why the first round of testing missed it. the fix consumes the whole folded run and folds what it writes; both are now under test, including the accent-near-the-boundary case that a naive slice(0,75) cuts in half. verified live: both event shapes written and read back, escaping round-tripped, and a long summary edited twice with no accumulation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |
||
|
pastilhasandClaude Opus 5
|
a161e2ac5f |
agents can manage the calendar and the address book
the owner's scenario: any chat, "I'm having dinner Saturday with my wife, add that", "cancel it", "add Peter Griffin, this number" — and it happens. reading already worked through the JSON api. writing is the DAV door, and the credential question is what took the thinking: every option meant a NEW secret and then somewhere to keep it — a file, the secret store, one per commander — each a password to distribute, rotate and eventually leak. $OFFICER_AGENT_KEY is already in every agent's environment, already bound to one user, already revoked when the session ends. so the DAV door accepts it as the basic-auth password, and no new secret exists anywhere. it cannot reach another account, and that is structural rather than a check: resolveApiKey says whose the key is and that id becomes X-Remote-User. the URL is never consulted, radicale refuses any other principal, and the username in the header must AGREE with the key rather than select the account. verified — own principal 207/201, another account 403, spoofed username 401. the permission check is isApiRequestAllowed against this plugin's own prefix, so the answer is exactly what the gate would give the same credential at /api/caldav. a second copy of that rule is the copy that stops being updated. DAV methods are mapped to read/write with PROPFIND and REPORT as reads — unmapped they counted as writes and a member with read could not list their own calendar. anything unrecognised defaults to write, which is the safe direction. the skill is written from recipes that were RUN, not recalled: create 201, move 204 (same UID, same href, SEQUENCE bumped), delete 200, contact create and delete, and the json read for lookups. the trap it exists to prevent, found while testing rather than by reading: `date -u -d 'saturday 20:00'` does not convert. -u parses AND prints as UTC, so 8pm becomes 20:00Z, which is 21:00 in lisbon. every event an hour out, nothing errors, and it is invisible until someone is stood up. the two-step through epoch is the only form that works and the skill leads with it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043 |