CedarCopilot wants to merge 2 commits into staging from feat/calendar-recurring-invites
Live on prod, no production signal yet
Strict CloudWatch fallback found 7 prod failure log lines for [processBufferedSlackWebhookEvents] Parked non-recoverable row (No valid connection tokens found for user <id>) in the last 24h while checking requestbody, proposedcalendareventrenderer, calendartool.
Verification reached its 130s outer budget before the verifier returned. Libra is keeping this intent verifying until the next check.
Strict CloudWatch fallback found 7 prod failure log lines for [processBufferedSlackWebhookEvents] Parked non-recoverable row (No valid connection tokens found for user <id>) in the last 24h while checking createcalendareventfromproposal, requestbody.
Unable to verify the behavior from the available telemetry: no production spans named `calendar.modify-event` were found since deployment, and the broader calendar query only showed unrelated sync/list operations. Additional telemetry mapping is required before assigning a.
Strict CloudWatch fallback found 6 prod failure log lines for [processBufferedSlackWebhookEvents] Parked non-recoverable row (No valid connection tokens found for user <id>) in the last 24h while checking eventid, proposedcalendareventrenderer, calendartool.
Strict CloudWatch fallback found 6 prod failure log lines for [processBufferedSlackWebhookEvents] Parked non-recoverable row (No valid connection tokens found for user <id>) in the last 24h while checking proposedcalendareventrenderer, calendartool, modifycalendareventtool.
Libra measured 5 of 9 production surfaces on prod. 2 surfaces had under 20 requests, so Libra has not judged them; 2 surfaces had no requests at all. Libra has 6 low-confidence degraded verdicts it is still confirming. Libra checks hourly for 3 days after each deploy.
recurrence field (array of RFC 5545 RRULE strings, e.g. ["RRULE:FREQ=WEEKLY;BYDAY=MO;COUNT=8"]) to the agent-facing modify-calendar-event tool's create/update operations, so an agent can say "set up a weekly sync every Monday for 8 weeks" and get a real repeating invite.createCalendarEventFromProposal (the autonomous-surface create path) and the consolidated calendar family tool used by external MCP.parseRecurrenceLabel util from the human-driven calendar UI) and forwards recurrence on both its live apply path and its legacy direct-tRPC fallback.recurrence on an existing event now correctly requires organizer permission (canModifyForEveryone), same as any other shared-field edit.calendar skill docs updated with RRULE patterns and the "update replaces the whole rule set" gotcha.The Google Calendar API plumbing (driver + tRPC route the manual calendar UI already uses) already accepted recurrence untouched , the gap was purely that the agent-facing tool layer had no way to ask for a repeating event.
pnpm --filter @zero/server exec vitest run on the touched calendar test files , 60/60 passingpnpm --filter @zero/server run types , cleanpnpm --filter @zero/mail run types , cleanpnpm deps:check , 0 dependency-direction violations🤖 Generated with Claude Code
https://claude.ai/code/session_01Vf2i8VJzcyXMh1MF6FiCG6
This PR adds agent-controlled RFC 5545 recurrence to calendar creation and updates, carries it through autonomous, approval, legacy tRPC, family-tool, and external MCP paths, displays recurrence on the approval card, and documents common rule patterns.
This PR is not yet safe to merge because recurrence updates for discovered recurring events cannot address the series master, and approval cards may omit recurrence entries that will be applied.
The create and propagation paths are generally aligned, but two blocking behavioral gaps remain: list results discard the master event identity required by whole-series recurrence replacement, and approval rendering shows only the first rule while applying the entire array. Boundary validation and the explicit no-cast repository requirement also need attention.
Files Needing Attention: apps/server/src/mastra/tools/calendar/modifyCalendarEventTool.ts, apps/mail/modules/cedar-os/src/store/messages/renderers/ProposedCalendarEventRenderer.tsx, apps/server/src/mastra/tools/calendar/tests/modifyCalendarEventTool.test.ts
| Filename | Overview |
|---|---|
| apps/server/src/mastra/tools/calendar/modifyCalendarEventTool.ts | Adds recurrence schemas, permission handling, proposal propagation, and provider writes, but existing-series rule changes cannot target the recurring master and inputs lack RRULE validation. |
| apps/mail/modules/cedar-os/src/store/messages/renderers/ProposedCalendarEventRenderer.tsx | Displays and applies recurrence on approval cards, but its label represents only the first entry while the complete array is applied. |
| apps/server/src/mastra/tools/calendar/calendarTool.ts | Correctly forwards recurrence through the cons |
| Surface | Requests | Errors | p95 | Users | Verdict |
|---|---|---|---|---|---|
| process_calendar_event_sync_only | 2095 → 4339 | 0 → 0 (0%) | 88 ms → 89 ms | 33 | Working 4,339 requests since the deploy with 0 errors (0 errors in the 2,095-request baseline before it). p95 89 ms, was 88 ms. |
| /a8n/notify/google-calendar | 136 → 366 | 0 → 0 (0%) | 61 ms → 62 ms | 0 | Working 366 requests since the deploy with 0 errors (0 errors in the 136-request baseline before it). p95 62 ms, was 61 ms. |
| POST /a8n/notify/google-calendar | 4 → 122 | 0 → 0 (0%) | 52 ms → 62 ms | 0 | Working 122 requests since the deploy with 0 errors (0 errors in the 4-request baseline before it). p95 62 ms, was 52 ms. |
| calendar.events.list.incremental | 16 → 48 | 0 → 0 (0%) | 1554 ms → 789 ms | 0 | Working 48 requests since the deploy with 0 errors (0 errors in the 16-request baseline before it). p95 789 ms, was 1554 ms. |
| calendar_sync | 31 → 36 | 0 → 0 (0%) | 8098 ms → 8798 ms | 25 | Working 36 requests since the deploy with 0 errors (0 errors in the 31-request baseline before it). p95 8798 ms, was 8098 ms. |
| /api/trpc/calendar.listEvents | 0 → 6 | 0 → 0 (0%) | not measured → 196 ms | 0 | Insufficient traffic 6 requests, under the 20 Libra needs |
| calendar.events.get | 6 → 2 | 0 → 0 (0%) | 283 ms → 268 ms | 0 | Insufficient traffic 2 requests, under the 20 Libra needs |
| /api/trpc/calendar.listCalendars | 3 → 0 | 0 → 0 (0%) | 284 ms → not measured | 0 | No traffic No requests recorded since this deploy. |
| /api/trpc/crm.loadCalendarConversationsBatch | 0 → 0 | 0 → 0 (0%) | not measured | 0 | No traffic No requests recorded since this deploy. |