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

api/ios-profile.ts

@@ -16,7 +16,19 @@ import { randomUUID, randomBytes } from 'node:crypto';
 //
 // See docs/mobile-dav-provisioning.md §3 for the payload keys and where they come from.
 
-const TTL_MS = 5 * 60_000;
+/*
+  How long a provisioning link lives.
+
+  Five minutes until 2026-08-27, which assumed the person minting the link is the person clicking it —
+  true for a button in the UI, false for every other way this gets used. Handing a URL to someone who then
+  has to pick up a phone, open Safari and type it took longer than that every single time, and the failure
+  is indistinguishable from a broken profile: the link 404s and iOS says "Invalid Profile", which sends you
+  looking at the plist rather than at the clock. That cost most of an evening.
+
+  Thirty minutes, still single-use. The link embeds a live password, so this is a real trade — but the
+  binding constraint is that it is claimed ONCE and then gone, not that the window is narrow.
+*/
+const TTL_MS = 30 * 60_000;
 // A restart clears everything anyway; this is only a guard against a script hammering the mint endpoint.
 const MAX_PENDING = 32;
 
@@ -41,6 +53,21 @@ type ProfileParams = {
   principalUrl: string;
   /** What the user sees as the account name in Settings. */
   accountName: string;
+  /**
+   * Which accounts this profile creates. Both, unless something is wrong.
+   *
+   * ── Why this had to exist ──
+   *
+   * The comment below says one profile carrying both payloads sidesteps iOS folding CardDAV into an
+   * existing CalDAV account with the same server and username. On iOS 26.6 it does not: installing the
+   * two-payload profile produced ONE account offering Calendars and Reminders, with no Contacts toggle
+   * anywhere and 460 cards that the phone never once requested. Verified from the server side — the
+   * principal advertises `addressbook-home-set`, `/1/contacts/` is typed as an addressbook, and nothing
+   * had ever asked for it.
+   *
+   * So CardDAV gets its own profile, with its own PayloadIdentifier, which iOS has nothing to merge into.
+   */
+  kinds?: ('CalDAV' | 'CardDAV')[];
 };
 
 // One profile, both payloads. This is not a convenience: iOS keys accounts by server+username, so adding
@@ -48,10 +75,11 @@ type ProfileParams = {
 // silently never appear. A single profile creates both accounts outright and sidesteps it. Detail in
 // docs/mobile-dav-provisioning.md §1.6, which cost an evening to learn.
 function buildPlist(params: ProfileParams): string {
-  const { host, port, username, password, principalUrl, accountName } = params;
+  const { host, port, username, password, principalUrl, accountName, kinds = ['CalDAV', 'CardDAV'] } = params;
   // Stable per host, so re-running setup REPLACES the profile instead of stacking a second account, and
   // two Officer instances on one phone do not overwrite each other.
-  const identifier = `dev.officer.dav.${host.replace(/[^a-zA-Z0-9]+/g, '-')}`;
+  const suffix = kinds.length === 1 ? `.${kinds[0]!.toLowerCase()}` : '';
+  const identifier = `dev.officer.dav.${host.replace(/[^a-zA-Z0-9]+/g, '-')}${suffix}`;
   const e = escapeXml;
 
   const account = (kind: 'CalDAV' | 'CardDAV', label: string) => `    <dict>
@@ -80,12 +108,12 @@ function buildPlist(params: ProfileParams): string {
   <key>PayloadDisplayName</key><string>${e(accountName)} — Calendar &amp; Contacts</string>
   <key>PayloadDescription</key><string>Adds your Officer calendars and address book to this device.</string>
   <key>PayloadOrganization</key><string>Officer</string>
-  <key>PayloadScope</key><string>User</string>
+  <!-- PayloadScope is deliberately absent: Apple documents it for macOS only, and iOS rejected this
+       profile outright with "Invalid Profile" while it was present. Removed 2026-08-27. -->
   <key>PayloadRemovalDisallowed</key><false/>
   <key>PayloadContent</key>
   <array>
-${account('CalDAV', 'Officer Calendar')}
-${account('CardDAV', 'Officer Contacts')}
+${kinds.map((k) => account(k, k === 'CalDAV' ? 'Officer Calendar' : 'Officer Contacts')).join('\n')}
   </array>
 </dict>
 </plist>
@@ -183,7 +211,18 @@ export async function stashIosProfile(params: ProfileParams, publicUrl: string):
 export function claimIosProfile(token: string): Uint8Array | null {
   sweep();
   const entry = pending.get(token);
-  if (!entry) return null;
+  if (!entry) {
+    // SAID OUT LOUD, because the alternative is silence at the only moment it matters.
+    //
+    // A miss means expired, already used, or never existed, and the caller cannot be told which — telling
+    // them would confirm a token once existed. But WE need to know: the response is a 404, iOS renders
+    // that as "Invalid Profile", and the person reading it goes and inspects the plist. Nothing in the log
+    // said a phone had even asked. One line here is the difference between "the link expired" and an
+    // evening spent validating XML that was correct the whole time.
+    console.warn(`[dav] ios profile claim MISSED (expired, already used, or never minted) — ${pending.size} pending`);
+    return null;
+  }
   pending.delete(token);
+  console.log(`[dav] ios profile claimed — ${pending.size} still pending`);
   return entry.body;
 }