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: found issues before merge. Reviewed June 26, 2026, 1:15 AM ET / 05:15 UTC.

Summary
The PR adds gog calendar changed, generated command docs, skill docs, tests, and a changelog entry for listing recently modified Calendar events including cancellations.

Reproducibility: not applicable. as a bug reproduction: this is a new Calendar CLI feature PR. The behavior is source-checkable through CalendarChangedCmd, its generated docs, and the added httptest coverage.

Review metrics: 3 noteworthy metrics.

• Changed files: 9 files, +545/-1. The PR adds one command implementation, one test file, generated docs, skill docs, and a changelog edit.
• New CLI surface: 1 command, 0 aliases at latest head. Maintainers should notice that the latest diff no longer matches the PR body's alias claims.
• Release-note section: 1 entry under v0.31.0. v0.31.0 is already released, so the section placement is a merge-relevant metadata defect.

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:

• Move or remove the changelog entry from the already-released v0.31.0 section.
• Update the PR body so it no longer claims removed aliases or --show-deleted.

Risk before merge

• [P1] The changelog entry currently claims this unmerged feature belongs to v0.31.0, which is already released and does not contain the PR head.
• [P1] The PR body is stale relative to the latest head: it still mentions recent/modified aliases and --show-deleted, while the current diff removed those surfaces.
• [P1] Deleted-event visibility is now intentional in the latest code and generated docs, but it is still new Calendar CLI semantics that maintainers should accept before landing.

Maintainer options:

1. Fix release metadata before merge (recommended)
   Move or remove the calendar changed entry from the already-released v0.31.0 section so release history remains accurate.
2. Leave notes to the landing process
   Drop the changelog change from this PR and let the release-owned landing flow add the final note under the correct version.
3. Accept the metadata skew
   Maintainers could intentionally accept the misleading v0.31.0 note, but that would make the published release history harder to trust.

Next step before merge

• [P2] The concrete defect is in release-owned changelog metadata, so a maintainer or release owner should correct it rather than sending this to automated repair.

Security
Cleared: The diff adds Go Calendar CLI code, generated docs, skill docs, changelog text, and tests without changing dependencies, CI, credentials, install scripts, or release automation.

Review findings

• [P2] Move the release note out of v0.31.0 — CHANGELOG.md:7

Review details

Best possible solution:

Land the focused changed-event command only after release-owned metadata is corrected and the PR description matches the final command surface.

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

Not applicable as a bug reproduction: this is a new Calendar CLI feature PR. The behavior is source-checkable through CalendarChangedCmd, its generated docs, and the added httptest coverage.

Is this the best way to solve the issue?

No, not as currently packaged: the command implementation is focused, but the release note is in the wrong shipped section and the PR body should match the latest command surface before merge.

Full review comments:

• [P2] Move the release note out of v0.31.0 — CHANGELOG.md:7
v0.31.0 is already the latest release tag, and this open PR is not contained in that release. Leaving the new calendar changed entry under that section would make the changelog claim the command shipped in a version that does not include it; move it to the unreleased section or leave release notes to the landing process.
  Confidence: 0.92

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 dafe80460ffe.

Label changes

Label changes:

• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (screenshot): The PR body includes an inspected terminal screenshot showing the new command running against a real calendar with changed-event output.
• remove status: 🛠️ actively grinding: Current PR status label is status: ⏳ waiting on author.

Label justifications:

• P2: The PR is a normal-priority Calendar CLI improvement with limited blast radius and one concrete merge-time metadata defect.
• merge-risk: 🚨 other: Merging the PR as-is would put an unshipped command in an already-shipped changelog section, a release-history risk outside the specific merge-risk taxonomy.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (screenshot): The PR body includes an inspected terminal screenshot showing the new command running against a real calendar with changed-event output.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes an inspected terminal screenshot showing the new command running against a real calendar with changed-event output.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The PR body includes an inspected terminal screenshot showing the new command running against a real calendar with changed-event output.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its PR-review guidance applies to use gh pr view and gh pr diff without switching branches or editing files. (AGENTS.md:37, dafe80460ffe)
• Current main lacks the new command: Current main's Calendar command registry has no Changed command, and a source search found no CalendarChangedCmd or gog calendar changed command on main. (internal/cmd/calendar.go:3, dafe80460ffe)
• PR registers the new command: The PR head registers CalendarChangedCmd as gog calendar changed with help text that says it includes deletions. (internal/cmd/calendar.go:23, d7dc5bbf70c3)
• PR fetches changed events explicitly including deletions: The latest implementation calls Events.List with UpdatedMin, ShowDeleted(true), OrderBy("updated"), and then sorts by updated time descending before truncating to --max. (internal/cmd/calendar_changed.go:153, d7dc5bbf70c3)
• PR tests deleted-event behavior: The updated test asserts that the API request sends showDeleted=true and that a cancelled event sorted by the newest updated timestamp appears first. (internal/cmd/calendar_changed_test.go:70, d7dc5bbf70c3)
• Generated docs match latest semantics: The generated command page describes gog calendar changed as listing most recently changed events including deletions and no longer documents --show-deleted. (docs/commands/gog-calendar-changed.md:5, d7dc5bbf70c3)

Likely related people:

• steipete: Blame on the current Calendar command registry and list helper points to the v0.31.0 release commit, and the latest PR head also contains a Calendar refinement commit by this author. (role: recent area contributor; confidence: high; commits: da0e8b0dc5df, d7dc5bbf70c3; files: internal/cmd/calendar.go, internal/cmd/calendar_list.go, internal/cmd/calendar_changed.go)
• malob: A recent merged Calendar event-filtering PR changed adjacent event-listing code and tests beside the new command surface. (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.

[steipete]

Thanks @sorenisanerd! Landed in e022bb9 with the changed-event command narrowed to the documented surface and cancellations included. Live disposable proof covered create, update, and cancelled-event readback; cleanup succeeded.