Skip to content

feat: authenticated CLI modes and calendar management - #1

Merged
ribaricplusplus merged 1 commit into
mainfrom
feat/auth-modes-calendar
Nov 3, 2026
Merged

ribaricplusplus merged 1 commit into
mainfrom
feat/auth-modes-calendar

Conversation

@ribaricplusplus

Copy link
Copy Markdown
Contributor

Summary

  • Add two authenticated modes backed by distinct configurable Entra public-client apps, isolated token caches, verified grants and explicit switching.
  • Keep existing read-only mail operations and their raw JSON success contracts compatible.
  • Add capability-aware help and guarded calendar list/view/get/create/update/delete, conditional mutations, attendee notification approval and readback verification.
  • Package agent guidance and setup instructions; increment CLI version to 0.2.0. No organization-specific app IDs or credentials in source.

Verification

  • 38 tests passed in the candidate and installed checkout, including real localhost HTTP contracts, opaque MSAL cache import, failed-login rollback, legacy JSON compatibility and parallel unchanged-cache reads.
  • Typecheck (including supplemental source/test strict check), build and diff checks passed.
  • Package archive inspected: only runtime JS, metadata, documentation and license.
  • Authorized live Microsoft verification: both modes used their distinct app IDs and the expected account; read-only mode hid/rejected calendar mutations and existing mail reads worked.
  • Authorized live calendar smoke: created one attendee-free timed event, independently read it, changed title/time/location, independently read it again, deleted it and independently verified HTTP 404. Final window audit found zero test-event leftovers.

Deliberate boundaries

  • Mail remains read-only in both modes. No email-send, invitation or RSVP command.
  • Calendar creation is timed-event-only; all-day/recurrence creation and Google/Outlook automatic synchronization are not included.
  • Read-write app eligibility is tenant-controlled; setup supports Assignment required: No.
  • Token caches are owner-only files, not an OS sandbox or encrypted secret store. Explicit authentication/refresh races fail closed; ordinary reads reuse unchanged caches.

@ribaricplusplus
ribaricplusplus merged commit 1a218a8 into main Nov 3, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant