Handle Google Calendar working locations

[3mdistal]

Summary

• Sync Google eventType=workingLocation events with native workingLocationProperties, render all-day working locations in a slim translated lane above ordinary all-day events, and keep them non-blocking for availability.
• Preserve continuous multi-day all-day spans while separating the two lanes, with deterministic clipping and row packing covered by pure layout tests.
• Keep working-location date edits explicitly single-day, pin recurring date moves to the visible occurrence, and wait for Google before moving the chip so rejected writes cannot make it disappear.
• Add a focused Home / Office / Other editor in popover and pinned-panel surfaces. Recurring events default to This day only, with an explicit All days option that still targets the visible instance ID.
• Keep Google payloads coherent: labels live in workingLocationProperties; the forbidden generic location field is stripped defensively; office metadata is preserved only while the event remains an office location.
• Record the working-hours API spike outcome: Google Calendar v3 exposes working-location events, but its Settings/discovery surface has no structured working-hours resource. No working-hours settings UI or Find a Time changes are included.

Verification

• pnpm -C templates/calendar test — 38 files, 246 tests passed
• pnpm -C templates/calendar typecheck
• pnpm -C templates/calendar build
• pnpm guard:i18n-catalogs — 16 catalog directories passed
• pnpm exec oxfmt --check <18 modified TypeScript files>
• git diff origin/main --check
• Merging current origin/main completed cleanly; every local gate above passed again after the final merge.

Browser and provider QA

• Verified the working-location lane appears above ordinary all-day events on desktop and at 390px without horizontal overflow.
• Verified a Tuesday-through-Thursday ordinary all-day event remains one continuous span.
• Verified French chip, popover, pinned-panel, and aria-label text (Accueil, Lieu de travail : Accueil) and restored the app to English afterward.
• Created one disposable Home working location, changed it to Office and then Other through the native editor, and received HTTP 200 for both updates.
• Confirmed both action payloads omitted generic location; Google read-back returned native officeLocation / customLocation properties with transparency: transparent.
• Confirmed the chip and pinned heading updated immediately after each save.
• Compared the same July 5–11 week in Agent-Native Calendar and Google Calendar: Google groups adjacent daily records visually, while both apps retain a distinct Wednesday testtest record.
• Verified the working-location date editor exposes one date only, no multi-day end field, and no series-wide date scope; rejected writes remain in place until provider confirmation.
• Deleted all disposable events and confirmed zero QA matches remained. Alice's existing recurring Home series was not mutated.

Successful user story

A hybrid worker can scan where they are working separately from all-day commitments, open a focused translated editor, change one visible day's location without accidentally creating an invalid multi-day status event, and read the same native non-blocking properties back from Google Calendar. Ordinary multi-day all-day events remain a single continuous span below the location lane.

Review and logs

• Task ledger: .task-sweep/calendar-working-location-feedback-ledger.md (local handoff artifact)
• Opus planning: .task-sweep/logs/claude-opus-plan-output-20260709-142915.jsonl
• Opus final complete-diff review: .task-sweep/logs/claude-opus-review-final-output-20260709-161320.jsonl
• Final Opus verdict: VERDICT: NO BLOCKERS
• Fable date-edit review: .task-sweep/logs/claude-fable-5-review-working-location-days-output-20260710-112445.md
• Final Fable verdict: NON-BLOCKING with no blockers

Risks and follow-ups

• A live mutation of Alice's real recurring working-location series was intentionally not performed. Unit/action coverage proves visible-instance IDs and scope: single|all; the UI default was verified read-only on an existing recurring occurrence.
• Weekly per-day location settings and copy-to-all remain deferred until the app has a real event-backed reconciliation action. Google Calendar v3 does not expose working-hours settings as structured provider data.
• Find a Time remains behaviorally unchanged.
• Separate pre-existing follow-up: manually changing create-dialog date inputs can retain the prior date state. It was reproduced outside the working-location edit path and is not introduced by this diff.

[github-actions]

Here's a visual recap of what changed:

Open the full interactive recap

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
34696882	Triggered	Generic High Entropy Secret	c021405	packages/core/src/agent/model-config.spec.ts	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[3mdistal]

I reviewed the GitGuardian finding on packages/core/src/agent/model-config.spec.ts. That file has no diff relative to current main, so the finding is inherited from base history and is not introduced or changed by this PR. No PR-scoped code change is needed.

• Codex AI

[builder-io-integration]

Builder reviewed your changes — looks good ✅

Review Details

Incremental Review Summary

Reviewed PR #1930 after merging with PR #2004 (multi-account support changes). The merge successfully integrated account-context changes across the working-location feature.

Integration verification:

• ✅ All googleCalendar.* function signatures updated to accept account: GoogleAccountSelection parameter
• ✅ Working-location event creation/replacement passes { ownerEmail, accountEmail } context (lines 471, 481, 488, 507)
• ✅ CalendarView resolves account email before creation/update and passes it through mutation payloads (lines 663, 699–702)
• ✅ Account email is preserved through working-location replacement workflow
• ✅ Conflict resolution in CalendarView correctly added account-aware event draft handling (lines 398–423)

What changed in the merge:

• getEvent, createEvent, updateEvent, deleteEvent now all accept account: GoogleAccountSelection parameter
• CalendarView adds account resolution logic before committing event drafts
• Working-location replacement correctly passes account context to both create and delete operations

No new bugs introduced. The merge cleanly integrates account context throughout the working-location flow. The test suite covers the working-location operations (tests added in previous commits), and account context plumbing follows the same pattern across all event mutations.

Risk: standard. Verdict: all functional concerns addressed.

🧪 Browser testing: Skipped — unable to verify in dev environment.