feat(calendar): add 'changed' command to list recently modified events

[sorenisanerd]

Adds gog calendar changed (aliases: recent, modified) which surfaces the N events most recently created or modified, sorted by last-modification time descending. Uses Events.List with UpdatedMin and omits SingleEvents so that recurring series appear as a single master entry rather than exploding into per-instance results. Supports --since (duration/date/RFC3339, default 30d), --max, --all, --cal, --calendars, --show-deleted, --weekday, --location, and --fail-empty flags.

[clawsweeper]

Codex review: needs changes before merge. Reviewed June 23, 2026, 12:36 PM ET / 16:36 UTC.

Summary
The PR adds gog calendar changed with recent and modified aliases, generated command docs, and tests for listing events by last-modification time.

Reproducibility: yes. for the review finding by source inspection: the PR relies on ShowDeleted(false) with UpdatedMin, and the Events.list docs say deleted entries since that time are included regardless of showDeleted. The broader item is a new feature PR rather than a bug report. (developers.google.com)

Review metrics: 3 noteworthy metrics.

• Changed files: 7 files, +535/-1. The branch adds one command implementation, one test file, and generated command documentation.
• New CLI names: 1 command, 2 aliases. Maintainers should explicitly accept the added changed, recent, and modified Calendar surface before merge.
• Proof artifact: 1 terminal screenshot inspected. The PR body shows the new command running against a real calendar, which clears the real behavior proof gate.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦞 diamond lobster ✨ media proof bonus
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

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

Rank-up moves:

• [P2] Filter cancelled events locally unless --show-deleted is set and add regression coverage.
• Confirm maintainer acceptance of the new changed, recent, and modified command surface before landing.

Risk before merge

• [P1] With default flags, gog calendar changed can show cancelled events even though users did not pass --show-deleted.
• [P1] Maintainers still need to accept the new changed, recent, and modified Calendar CLI surface before merge.

Maintainer options:

1. Filter cancelled events before merge (recommended)
   Keep the updatedMin query but drop Status == "cancelled" results unless --show-deleted is true, with tests for both paths.
2. Make deletions visible by design
   If maintainers want this command to behave like a sync feed, update the flag help and generated docs so deleted events are clearly included by default.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
Filter cancelled Calendar events after `UpdatedMin` unless `--show-deleted` is set, and add unit coverage for both default and `--show-deleted` behavior.

Next step before merge

• [P2] There is a narrow source-backed repair: filter cancelled events after the updatedMin query unless --show-deleted is set, then add regression coverage.

Security
Cleared: The diff adds Go Calendar CLI code, generated docs, and tests; it does not change dependencies, CI, credentials, release scripts, or other supply-chain surfaces.

Review findings

• [P2] Filter deleted events after updatedMin — internal/cmd/calendar_changed.go:161

Review details

Best possible solution:

Filter cancelled events locally unless --show-deleted is set, add regression coverage for both default and opt-in behavior, then let maintainers decide whether to accept the new command and aliases.

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

Yes for the review finding by source inspection: the PR relies on ShowDeleted(false) with UpdatedMin, and the Events.list docs say deleted entries since that time are included regardless of showDeleted. The broader item is a new feature PR rather than a bug report. (developers.google.com)

Is this the best way to solve the issue?

No, not yet: the implementation mostly follows existing Calendar selector and output patterns, but it should filter cancelled events locally when --show-deleted is false before this is the maintainable command behavior.

Full review comments:

• [P2] Filter deleted events after updatedMin — internal/cmd/calendar_changed.go:161
  Google Calendar Events.list includes entries deleted since updatedMin regardless of showDeleted, so ShowDeleted(false) here does not keep cancelled events out. With default flags, a recently deleted event can appear in gog calendar changed; filter Status == "cancelled" locally unless --show-deleted is set and add coverage for that case. (developers.google.com)
  Confidence: 0.9

Overall correctness: patch is incorrect
Overall confidence: 0.88

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add status: 🛠️ actively grinding: The PR author has acted after the latest ClawSweeper review and work remains. Sufficient (screenshot): The PR body includes a terminal screenshot showing the new command running against a real calendar with table output sorted by UPDATED descending.
• remove status: ⏳ waiting on author: Current PR status label is status: 🛠️ actively grinding.

Label justifications:

• P2: The PR has a normal-priority correctness issue in a new Calendar CLI feature with limited blast radius.
• merge-risk: 🚨 other: The diff can surface cancelled Calendar events by default because updatedMin deletions bypass the showDeleted=false expectation.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• status: 🛠️ actively grinding: The PR author has acted after the latest ClawSweeper review and work remains. Sufficient (screenshot): The PR body includes a terminal screenshot showing the new command running against a real calendar with table output sorted by UPDATED descending.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes a terminal screenshot showing the new command running against a real calendar with table output sorted by UPDATED descending.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The PR body includes a terminal screenshot showing the new command running against a real calendar with table output sorted by UPDATED descending.

Evidence reviewed

Acceptance criteria:

• [P1] go test ./internal/cmd -run TestCalendarChanged.
• [P1] go test ./internal/cmd.

What I checked:

• Repository policy read: AGENTS.md was read fully; its PR review-mode guidance applies to inspect with gh pr view and gh pr diff without switching branches or editing files. (AGENTS.md:32, 7af5c68d93b3)
• Current main command surface: Current main registers Calendar commands in CalendarCmd and has no existing changed, recent, or modified command, so this PR is not obsolete or duplicated on main. (internal/cmd/calendar.go:3, 7af5c68d93b3)
• PR implementation path: The new fetch path uses Events.List(calendarID).UpdatedMin(since).ShowDeleted(showDeleted).OrderBy("updated") and then returns all collected items without filtering cancelled events. (internal/cmd/calendar_changed.go:157, c84431f53a74)
• Calendar API deletion semantics: Official Events.list documentation says entries deleted since updatedMin are always included regardless of showDeleted, which makes local filtering necessary for a default non-deleted view. (developers.google.com)
• Focused tests present but missing deleted-event coverage: The added tests cover JSON ordering, table output, max limiting, and default updatedMin, but not a cancelled event returned from an updatedMin query while --show-deleted is false. (internal/cmd/calendar_changed_test.go:14, c84431f53a74)
• Real behavior proof inspected: The PR body screenshot was downloaded to scratch and visually inspected; it shows gog calendar changed ... --max 12 producing terminal table output sorted by UPDATED descending. (c84431f53a74)

Likely related people:

• steipete: Blame on internal/cmd/calendar.go and the base event-list helper points to the v0.30.0 release commit that introduced the current Calendar command surface in this checkout. (role: calendar command surface contributor; confidence: high; commits: 48db48b4f61f; files: internal/cmd/calendar.go, internal/cmd/calendar_list.go)
• malob: Recent merged work in feat(calendar): add --event-types filter to calendar events #870 changed adjacent Calendar event filtering paths and tests that the new command builds beside. (role: recent adjacent calendar contributor; confidence: medium; commits: b0bd35e54391, cccc5e1de482; files: internal/cmd/calendar_list.go, internal/cmd/calendar_events_cmds.go, internal/cmd/calendar_events_test.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.

[sorenisanerd]

I think I prefer the current behavior. Cancelling a single instance of a recurring event will show up show up regardless of --show-deleted. A deleted recurring event will only show up if --show-deleted is passed.