feat(calendar): support resource attendees

[titus7490]

Summary

• add ;resource as an attendee modifier for Google Calendar events
• support it consistently in calendar create --attendees, calendar update --attendees, and calendar update --add-attendee
• keep the existing ;optional and ;comment=... attendee modifiers working alongside it
• update generated command docs and focused Calendar tests

Why

Google Calendar represents rooms and equipment as event attendees with resource: true. gog already exposes high-level Calendar create/update commands and attendee modifiers for optional and comment, but callers could not mark an attendee as a Calendar resource without dropping down to raw API calls.

This keeps the high-level CLI useful for generic Workspace room/resource booking while leaving organization-specific room selection, FreeBusy fallback, and acceptance checks outside gogcli.

Compatibility

• Additive syntax only: existing email, email;optional, and email;comment=... inputs keep their behavior.
• No default behavior changes: attendees are only marked as resources when ;resource is present.
• No OAuth scope changes, dependency changes, auth changes, or CODE-specific room aliases/workflows.
• calendar update --add-attendee still preserves existing attendee metadata and skips duplicate emails; use --attendees when replacing the attendee list is intended.

Behavior proof

Dry-run from this branch shows the outgoing Calendar event payload sets resource: true and preserves the other attendee modifiers:

$ ./bin/gog calendar create primary \
  --summary 'Resource attendee dry run' \
  --from 2026-06-26T10:00:00+02:00 \
  --to 2026-06-26T10:30:00+02:00 \
  --attendees 'room@resource.calendar.google.com;resource;optional;comment=Project room' \
  --dry-run --json

{
  "dry_run": true,
  "op": "calendar.create",
  "request": {
    "event": {
      "attendees": [
        {
          "comment": "Project room",
          "email": "room@resource.calendar.google.com",
          "optional": true,
          "resource": true
        }
      ]
    }
  }
}

Live validation was also done outside this PR with a local Workspace room-booking wrapper using the same Calendar resource-attendee contract:

• created a disposable Google Calendar event with a room/resource attendee
• observed the room attendee reach responseStatus: accepted
• deleted the event and verified the event status became cancelled
• created a temporary blocker, then confirmed the booking wrapper returned no_rooms_available for the occupied slot and did not create a second booking
• removed all disposable test events afterward

The local room-selection wrapper is intentionally not included here; this PR only exposes the generic Google Calendar EventAttendee.resource field in the existing attendee syntax.

Tests

• go test -vet=off ./internal/cmd -run 'TestParseAttendee|TestMergeAttendees|TestCalendarUpdateCmd_AddAttendee|TestCalendarUpdateBuildPatchResourceAttendee|TestBuildCalendarCreatePlanResourceAttendee'
• go test -vet=off ./internal/cmd
• make docs-commands
• make build
• git diff --check origin/main...HEAD
• ./bin/gog calendar create primary --summary 'Resource attendee dry run' --from 2026-06-26T10:00:00+02:00 --to 2026-06-26T10:30:00+02:00 --attendees 'room@resource.calendar.google.com;resource;optional;comment=Project room' --dry-run --json
• go test -vet=off ./...

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 26, 2026, 1:14 AM ET / 05:14 UTC.

Summary
The branch adds a ;resource Calendar attendee modifier for create/update/add-attendee, updates command docs and changelog, and adds focused Calendar tests.

Reproducibility: not applicable. as a feature PR. Source inspection shows current main lacks ;resource parsing, and the PR body includes dry-run output showing the new outgoing payload behavior.

Review metrics: none identified.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• none.

Next step before merge

• No ClawSweeper repair lane is needed because no discrete patch defect was found; the remaining action is normal maintainer review and merge gating.

Security
Cleared: The diff is limited to Calendar attendee parsing, generated command docs, tests, and changelog text, with no auth, scope, dependency, workflow, secret, or supply-chain changes.

Review details

Best possible solution:

Land the narrow additive modifier after maintainer review and required CI, keeping room selection and booking policy outside gogcli.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a feature PR. Source inspection shows current main lacks ;resource parsing, and the PR body includes dry-run output showing the new outgoing payload behavior.

Is this the best way to solve the issue?

Yes. Extending the existing attendee modifier parser is the narrowest maintainable path and avoids adding a parallel flag or raw Calendar API escape hatch.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against dafe80460ffe.

Label changes

Label justifications:

• P2: This is a normal-priority user-facing Calendar CLI improvement with limited blast radius and no identified correctness blocker.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body includes copied dry-run CLI JSON output showing the after-change Calendar payload with resource: true, which is sufficient for this payload-building feature.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes copied dry-run CLI JSON output showing the after-change Calendar payload with resource: true, which is sufficient for this payload-building feature.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully, and its PR review-mode instruction to inspect via gh pr view/gh pr diff without changing branches was applied. (AGENTS.md:37, dafe80460ffe)
• Current main lacks resource parsing: The current attendee parser recognizes optional and comment= modifiers but has no resource branch, so the requested syntax is not already implemented on main. (internal/cmd/calendar_attendees.go:80, dafe80460ffe)
• Current add-attendee path strips modifiers: Current main's add-attendee merge path splits raw emails and constructs new attendees with only Email and needsAction, so modifier metadata is not preserved there. (internal/cmd/calendar_attendees.go:33, dafe80460ffe)
• Current create/update use shared parser: Calendar create and attendee replacement both flow through buildAttendees, making the parser the correct narrow implementation point. (internal/cmd/calendar_event_plan.go:381, dafe80460ffe)
• PR implements requested behavior: The PR changes add-attendee merging to use parsed attendee objects and adds the resource modifier branch that sets EventAttendee.Resource. (internal/cmd/calendar_attendees.go:33, 24f662309975)
• Focused coverage added: The PR adds create-plan, update-patch, and add-attendee tests that assert resource attendee fields are carried into Calendar payloads. (internal/cmd/calendar_event_plan_test.go:150, 24f662309975)

Likely related people:

• steipete: git blame attributes the current Calendar attendee helper and command surface to the v0.31.0 release commit, and PR metadata shows follow-up branch commits for changelog credit and the needs-action constant. (role: feature introducer and recent area contributor; confidence: high; commits: da0e8b0dc5df, b3a7cf38c1ff, 24f662309975; files: internal/cmd/calendar_attendees.go, internal/cmd/calendar_edit.go, internal/cmd/calendar_event_plan.go)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[steipete]

Thanks @titus7490! Landed in 52ff465 with resource attendees supported for create and add-attendee updates. Live disposable proof confirmed resource=true after both create and update readback; cleanup succeeded.