# Scratchpad — Calendar Sync Enterprise Migration and Microsoft Profile Explicit Bindings

- Plan slug: `calendar-sync-enterprise-migration-and-microsoft-profile-explicit-bindings`
- Created: `2026-03-09`

## What This Is

Follow-on implementation notes for moving calendar sync to EE-only ownership and finishing the Microsoft profile explicit-binding cleanup.

## Decisions

- (2026-03-09) Calendar sync moves to EE end to end, including integration settings, user-profile calendar settings, OAuth callbacks, runtime services, webhook maintenance, and subscriber execution.
- (2026-03-09) Shared Microsoft profile storage remains shared infrastructure; this plan does not create a second EE-only Microsoft credential model.
- (2026-03-09) CE Microsoft profile UX should describe and bind only MSP SSO.
- (2026-03-09) EE Microsoft profile UX should expose MSP SSO plus email, calendar, and Teams consumers.
- (2026-03-09) Explicit consumer bindings are the source of truth; legacy compatibility/default-consumer wording should be removed from the target design.
- (2026-03-09) CE keeps only stub or wrapper entrypoints where route or import boundaries require them, following the existing Entra and Teams EE patterns.
- (2026-03-09) The Entra and Teams CE-stub plus EE-delegation pattern is the precedent for calendar route wrappers: stable shared URL, `501` JSON in CE, dynamic EE delegation in enterprise.
- (2026-03-09) Canonical unavailable copy for calendar HTTP stubs should be `Calendar sync is only available in Enterprise Edition.` so CE fails clearly before any token exchange, provider write, or sync side effect.
- (2026-03-09) One edition-aware consumer matrix should drive both UI visibility and action-layer enforcement: CE shows only `msp_sso`; EE shows `msp_sso`, `email`, `calendar`, and `teams`.

## Discoveries / Constraints

- (2026-03-09) `packages/integrations/src/components/settings/integrations/IntegrationsSettingsPage.tsx` currently renders Calendar as a shared category and renders `MicrosoftIntegrationSettings` directly under `Providers`.
- (2026-03-09) `server/src/components/settings/profile/UserProfile.tsx` currently renders a `Calendar` tab through `CalendarIntegrationsSettings`, so the EE move has to include profile settings, not just admin settings.
- (2026-03-09) Shared calendar callback routes currently live at `server/src/app/api/auth/google/calendar/callback/route.ts` and `server/src/app/api/auth/microsoft/calendar/callback/route.ts`.
- (2026-03-09) Shared calendar runtime code exists in both `server/src/services/calendar/*` and `packages/integrations/src/services/calendar/*`, so the extraction needs an ownership pass across settings, service exports, adapters, and maintenance jobs.
- (2026-03-09) `packages/integrations/src/actions/integrations/microsoftActions.ts` still contains legacy compatibility semantics such as `LEGACY_MICROSOFT_PROFILE_CONSUMERS`, compatibility backfill logic, default-profile copy, and fallback-based consumer resolution.
- (2026-03-09) `MicrosoftIntegrationSettings.tsx` still contains the legacy Microsoft consumers pane and default-compatibility copy even though the binding table and binding actions already exist.
- (2026-03-09) The current binding table is shared at `server/migrations/20260307143000_create_microsoft_profile_consumer_bindings.cjs`, and Teams already depends on `selected_profile_id` plus binding-aware resolution.
- (2026-03-09) There are no screenshots checked into `ee/docs` for this plan folder or nearby migration docs, so the documentation cleanup for Calendar ownership is entirely text and runbook based.
- (2026-03-09) Calendar public entry routes also include `server/src/app/api/calendar/webhooks/google/route.ts` and `server/src/app/api/calendar/webhooks/microsoft/route.ts`, so webhook maintenance has to follow the same CE stub or EE delegator rule as OAuth callbacks.
- (2026-03-09) Shared auth/runtime precedent already exists for Microsoft consumers:
  - `packages/auth/src/lib/sso/mspSsoResolution.ts`
  - `packages/auth/src/lib/sso/teamsMicrosoftProviderResolution.ts`
  - `ee/server/src/lib/auth/teamsMicrosoftProviderResolution.ts`
- (2026-03-09) Existing doc-contract precedent lives at `server/src/test/unit/docs/teamsEnterpriseOnlyMigrationPlan.contract.test.ts`, which is the right pattern for validating this plan folder as it evolves.
- (2026-03-09) `packages/integrations/src/actions/calendarActions.ts` was converted into an edition-gated EE delegator layer. Shared action entrypoints no longer import `CalendarProviderService`, `CalendarSyncService`, `CalendarWebhookMaintenanceService`, or calendar adapters directly.
- (2026-03-09) The new EE action implementation currently lives at `packages/ee/src/lib/actions/integrations/calendarActions.ts`. It centralizes provider CRUD, manual sync, conflict resolution, sync status reads, and manual Microsoft webhook renewal behind the `@enterprise` alias boundary.
- (2026-03-09) `server/src/lib/actions/calendarActions.ts` now exists as a stable server-side re-export of `@alga-psa/integrations/actions/calendarActions`, which keeps existing server imports/tests working while the shared package owns only the delegator boundary.
- (2026-03-09) The initial action-delegator slice completed the CE CRUD-entrypoint cutover (`F074`); later slices then moved subscriber registration and the concrete EE runtime service tree so the live calendar runtime no longer depends on shared `server/src/services/calendar/*`.
- (2026-03-09) `server/src/lib/eventBus/subscribers/calendarSyncSubscriber.ts` is now a CE no-op plus EE delegator. The concrete schedule-entry subscriber moved to `packages/ee/src/lib/eventBus/subscribers/calendarSyncSubscriber.ts`, so CE startup no longer loads `CalendarSyncService` or `CalendarProviderService` through subscriber registration.
- (2026-03-09) Because callbacks, webhooks, maintenance jobs, action entrypoints, subscriber registration, and the concrete EE service tree now all terminate under EE-owned modules, shared calendar sync services/adapters no longer have a live CE runtime entrypoint and EE no longer executes through shared `server/src/services/calendar/*` entrypoints.
- (2026-03-09) `server/src/test/integration/calendar/scheduleAutoSync.integration.test.ts` still depends on a local PostgreSQL test instance at port `5438`; targeted validation for the subscriber slice therefore uses deterministic unit tests (`calendarSyncSubscriber.delegator.test.ts` and `calendarSyncSubscriber.ee.test.ts`) instead of the DB-backed integration suite in this environment.
- (2026-03-09) The concrete EE calendar runtime now lives under `packages/ee/src/lib/services/calendar/*`. EE callbacks, webhook routes, maintenance jobs, subscriber registration, and action entrypoints all import that package-owned service tree through `@enterprise/lib/services/calendar/*`.
- (2026-03-09) The EE runtime ownership contract now explicitly covers:
  - webhook renewal and maintenance jobs through `packages/ee/src/lib/jobs/handlers/calendarWebhookMaintenanceHandler.ts` and `packages/ee/src/lib/services/calendar/CalendarWebhookMaintenanceService.ts`
  - provider secret handling through `packages/ee/src/lib/services/calendar/CalendarProviderService.ts`
  - adapter selection and provider-type branching through `packages/ee/src/lib/services/calendar/CalendarSyncService.ts` and `packages/ee/src/lib/services/calendar/CalendarWebhookProcessor.ts`
  - background schedule-entry subscriber execution through `packages/ee/src/lib/eventBus/subscribers/calendarSyncSubscriber.ts`

## Commands / Runbooks

- (2026-03-09) Scaffold plan:
  - `python3 /Users/roberisaacs/.codex/skills/alga-plan/scripts/scaffold_plan.py "Calendar Sync Enterprise Migration and Microsoft Profile Explicit Bindings" --slug calendar-sync-enterprise-migration-and-microsoft-profile-explicit-bindings`
- (2026-03-09) Validate plan:
  - `python3 /Users/roberisaacs/.codex/skills/alga-plan/scripts/validate_plan.py ee/docs/plans/2026-03-09-calendar-sync-enterprise-migration-and-microsoft-profile-explicit-bindings`
- (2026-03-09) Useful discovery queries:
  - `rg -n "CalendarIntegrationsSettings|CalendarSyncService|CalendarProviderService|microsoft_profile_consumer_bindings|LEGACY_MICROSOFT_PROFILE_CONSUMERS|MicrosoftIntegrationSettings" packages server ee`
  - `rg -n "api/auth/.*/calendar/callback|teams|msp_sso" server packages ee`
- (2026-03-09) Focused validation suites expected for this migration:
  - settings/profile visibility tests for CE versus EE calendar entrypoints
  - calendar callback and webhook wrapper tests for unavailable versus delegated behavior
  - Microsoft profile UI contract tests for CE-only MSP SSO versus EE consumer visibility
  - Microsoft binding action tests for edition visibility, tenant scoping, archive guards, and fallback removal
  - ownership/package-boundary tests for shared wrapper imports versus EE runtime modules
  - migration/documentation contract tests for shared binding schema and this plan folder
- (2026-03-09) Latest validator result:
  - `python3 /Users/roberisaacs/.codex/skills/alga-plan/scripts/validate_plan.py ee/docs/plans/2026-03-09-calendar-sync-enterprise-migration-and-microsoft-profile-explicit-bindings`
  - Result: valid (`216` features, `432` tests)
- (2026-03-09) Focused implementation checks for the calendar visibility slice:
  - `pnpm vitest run --coverage.enabled=false src/test/unit/components/integrations/IntegrationsSettingsPage.calendar.test.tsx src/test/unit/components/profile/UserProfile.calendar.contract.test.ts ../packages/integrations/src/lib/calendarAvailability.test.ts`
  - `pnpm vitest run --coverage.enabled=false src/test/unit/components/integrations/IntegrationsSettingsPage.teams.test.tsx`
  - `pnpm exec tsc -p tsconfig.json --noEmit --pretty false`
- (2026-03-09) Focused implementation checks for the calendar callback delegator slice:
  - `pnpm vitest run --coverage.enabled=false src/test/unit/api/calendarCallbackRoutes.delegator.test.ts`
  - `pnpm exec tsc -p tsconfig.json --noEmit --pretty false`
- (2026-03-09) Focused implementation checks for the calendar webhook delegator slice:
  - `pnpm vitest run --coverage.enabled=false src/test/unit/api/calendarWebhookRoutes.delegator.test.ts src/test/unit/api/calendarCallbackRoutes.delegator.test.ts`
  - `pnpm exec tsc -p tsconfig.json --noEmit --pretty false`
- (2026-03-09) Focused implementation checks for the calendar maintenance delegator slice:
  - `pnpm vitest run --coverage.enabled=false src/test/unit/api/calendarCallbackRoutes.delegator.test.ts src/test/unit/api/calendarWebhookRoutes.delegator.test.ts src/test/unit/jobs/calendarWebhookMaintenanceHandler.delegator.test.ts`
  - `pnpm exec tsc -p tsconfig.json --noEmit --pretty false`
- (2026-03-09) Focused implementation checks for the calendar action delegator slice:
  - `pnpm vitest run --coverage.enabled=false src/test/unit/calendar/calendarActions.ee.contract.test.ts src/test/unit/calendar/calendarActions.sync.test.ts`
  - `pnpm exec tsc -p tsconfig.json --noEmit --pretty false`
- (2026-03-09) Focused implementation checks for the calendar subscriber delegator slice:
  - `pnpm vitest run --coverage.enabled=false src/test/unit/calendar/calendarSyncSubscriber.delegator.test.ts src/test/unit/calendar/calendarSyncSubscriber.ee.test.ts`
  - `pnpm exec tsc -p tsconfig.json --noEmit --pretty false`
- (2026-03-09) Focused implementation checks for the EE runtime ownership slice:
  - `pnpm vitest run --coverage.enabled=false src/test/unit/calendar/calendarActions.ceBoundary.test.ts src/test/unit/calendar/calendarActions.ee.contract.test.ts src/test/unit/calendar/calendarActions.sync.test.ts src/test/unit/calendar/calendarSyncSubscriber.delegator.test.ts src/test/unit/calendar/calendarSyncSubscriber.ee.test.ts src/test/unit/calendar/calendarRuntimeOwnership.contract.test.ts src/test/unit/api/calendarCallbackRoutes.delegator.test.ts src/test/unit/api/calendarWebhookRoutes.delegator.test.ts src/test/unit/jobs/calendarWebhookMaintenanceHandler.delegator.test.ts`
  - `pnpm exec tsc -p tsconfig.json --noEmit --pretty false`

## Links / References

- Prior Microsoft profile and Teams plan:
  - `ee/docs/plans/2026-03-07-microsoft-teams-integration-v1/`
- Prior Teams EE-boundary follow-on plan:
  - `ee/docs/plans/2026-03-08-microsoft-teams-enterprise-only-migration/`
- Current shared settings composition:
  - `packages/integrations/src/components/settings/integrations/IntegrationsSettingsPage.tsx`
- Current shared Microsoft profile UI:
  - `packages/integrations/src/components/settings/integrations/MicrosoftIntegrationSettings.tsx`
- Current shared Microsoft actions:
  - `packages/integrations/src/actions/integrations/microsoftActions.ts`
- Current shared profile page:
  - `server/src/components/settings/profile/UserProfile.tsx`
- Current shared calendar callback routes:
  - `server/src/app/api/auth/google/calendar/callback/route.ts`
  - `server/src/app/api/auth/microsoft/calendar/callback/route.ts`
- Current EE-owned calendar entrypoints after the first two migration slices:
  - `packages/integrations/src/components/settings/integrations/CalendarEnterpriseIntegrationSettings.tsx`
  - `@enterprise/components/settings/profile/CalendarProfileSettings`
  - `ee/server/src/app/api/auth/google/calendar/callback/route.ts`
  - `ee/server/src/app/api/auth/microsoft/calendar/callback/route.ts`
- Current shared calendar webhook routes:
  - `server/src/app/api/calendar/webhooks/google/route.ts`
  - `server/src/app/api/calendar/webhooks/microsoft/route.ts`
- Current shared Teams/Entra EE-boundary precedent:
  - `server/src/app/api/teams/_ceStub.ts`
  - `server/src/app/api/teams/_eeDelegator.ts`
  - `server/src/app/api/integrations/entra/_ceStub.ts`
  - `server/src/test/unit/api/teamsRoutes.delegator.test.ts`
  - `server/src/test/unit/api/entraRoutes.delegator.test.ts`

## Open Questions

- (2026-03-09) If Outlook inbound email remains CE-supported long term, decide whether its explicit Microsoft binding should stay EE-only in provider UI or move to a consumer-owned CE surface later. The current plan assumes the Microsoft profile page itself shows only MSP SSO in CE.

## Calendar EE Move Inventory

- Settings composition:
  - `packages/integrations/src/components/settings/integrations/IntegrationsSettingsPage.tsx`
  - `packages/integrations/src/components/calendar/CalendarIntegrationsSettings.tsx`
  - `packages/integrations/src/components/calendar/index.ts`
- User profile surface:
  - `server/src/components/settings/profile/UserProfile.tsx`
- Shared route wrappers that must become CE stubs or EE delegators:
  - `server/src/app/api/auth/google/calendar/callback/route.ts`
  - `server/src/app/api/auth/microsoft/calendar/callback/route.ts`
  - `server/src/app/api/calendar/webhooks/google/route.ts`
  - `server/src/app/api/calendar/webhooks/microsoft/route.ts`
- Calendar callback delegator helpers and EE-owned route files added for the second migration slice:
  - `server/src/app/api/auth/calendar/_ceStub.ts`
  - `server/src/app/api/auth/calendar/_eeDelegator.ts`
  - `packages/ee/src/app/api/auth/google/calendar/callback/route.ts`
  - `packages/ee/src/app/api/auth/microsoft/calendar/callback/route.ts`
  - `ee/server/src/app/api/auth/google/calendar/callback/route.ts`
  - `ee/server/src/app/api/auth/microsoft/calendar/callback/route.ts`
- Calendar webhook delegator helpers and EE-owned route files added for the third migration slice:
  - `server/src/app/api/calendar/_ceStub.ts`
  - `server/src/app/api/calendar/_eeDelegator.ts`
  - `packages/ee/src/app/api/calendar/webhooks/google/route.ts`
  - `packages/ee/src/app/api/calendar/webhooks/microsoft/route.ts`
  - `ee/server/src/app/api/calendar/webhooks/google/route.ts`
  - `ee/server/src/app/api/calendar/webhooks/microsoft/route.ts`
- Calendar maintenance handler boundary added for the fourth migration slice:
  - `server/src/lib/jobs/handlers/calendarWebhookMaintenanceHandler.ts`
  - `packages/ee/src/lib/jobs/handlers/calendarWebhookMaintenanceHandler.ts`
- Calendar UI visibility and EE-entry helpers added for the first migration slice:
  - `packages/integrations/src/lib/calendarAvailability.ts`
  - `packages/integrations/src/components/settings/integrations/CalendarEnterpriseIntegrationSettings.tsx`
  - `packages/ee/src/components/settings/integrations/CalendarIntegrationsSettings.tsx`
  - `ee/server/src/components/settings/integrations/CalendarIntegrationsSettings.tsx`
  - `packages/ee/src/components/settings/profile/CalendarProfileSettings.tsx`
  - `ee/server/src/components/settings/profile/CalendarProfileSettings.tsx`
- Shared runtime code that still owns live calendar behavior after the action delegator slice:
  - `packages/integrations/src/services/calendar/CalendarProviderService.ts`
  - `packages/integrations/src/services/calendar/CalendarSyncService.ts`
  - `packages/integrations/src/services/calendar/CalendarWebhookProcessor.ts`
  - `packages/integrations/src/services/calendar/CalendarWebhookMaintenanceService.ts`
  - `packages/integrations/src/services/calendar/providers/GoogleCalendarAdapter.ts`
  - `packages/integrations/src/services/calendar/providers/MicrosoftCalendarAdapter.ts`
  - `packages/integrations/src/services/calendar/providers/base/BaseCalendarAdapter.ts`
- Shared action boundary files added for the fifth migration slice:
  - `packages/integrations/src/actions/calendarActions.ts`
  - `packages/ee/src/lib/actions/integrations/calendarActions.ts`
  - `server/src/lib/actions/calendarActions.ts`
- Shared subscriber boundary files added for the sixth migration slice:
  - `server/src/lib/eventBus/subscribers/calendarSyncSubscriber.ts`
  - `packages/ee/src/lib/eventBus/subscribers/calendarSyncSubscriber.ts`
- EE-owned concrete runtime modules added for the seventh migration slice:
  - `packages/ee/src/lib/services/calendar/CalendarProviderService.ts`
  - `packages/ee/src/lib/services/calendar/CalendarSyncService.ts`
  - `packages/ee/src/lib/services/calendar/CalendarWebhookMaintenanceService.ts`
  - `packages/ee/src/lib/services/calendar/CalendarWebhookProcessor.ts`
  - `packages/ee/src/lib/services/calendar/providers/GoogleCalendarAdapter.ts`
  - `packages/ee/src/lib/services/calendar/providers/MicrosoftCalendarAdapter.ts`
  - `packages/ee/src/lib/services/calendar/providers/base/BaseCalendarAdapter.ts`
  - `packages/ee/src/lib/services/CalendarProviderService.ts`
  - `packages/ee/src/lib/services/CalendarSyncService.ts`
- Server runtime ownership hotspots that must stop executing in CE:
  - `server/src/lib/eventBus/subscribers/calendarSyncSubscriber.ts`
  - `server/src/lib/jobs/handlers/calendarWebhookMaintenanceHandler.ts`
  - `server/src/services/CalendarProviderService.ts`
  - `server/src/services/CalendarSyncService.ts`
  - `server/src/services/calendar/CalendarProviderService.ts`
  - `server/src/services/calendar/CalendarSyncService.ts`
  - `server/src/services/calendar/CalendarWebhookMaintenanceService.ts`
  - `server/src/services/calendar/CalendarWebhookProcessor.ts`
- Existing tests that should evolve with the EE cutover:
  - `server/src/test/integration/calendar/manualSync.integration.test.ts`
  - `server/src/test/integration/calendar/scheduleAutoSync.integration.test.ts`
  - `server/src/test/integration/calendar/webhookProcessing.integration.test.ts`
  - `server/src/test/unit/calendar/calendarActions.sync.test.ts`
  - `server/src/test/unit/api/calendarCallbackRoutes.delegator.test.ts`
  - `server/src/test/unit/api/calendarWebhookRoutes.delegator.test.ts`
  - `server/src/test/unit/jobs/calendarWebhookMaintenanceHandler.delegator.test.ts`

## Microsoft Binding Cleanup Inventory

- Shared UI and contracts:
  - `packages/integrations/src/components/settings/integrations/MicrosoftIntegrationSettings.tsx`
  - `packages/integrations/src/components/settings/integrations/MicrosoftIntegrationSettings.contract.test.tsx`
- Shared action and helper layer:
  - `packages/integrations/src/actions/integrations/microsoftActions.ts`
  - `packages/integrations/src/actions/integrations/microsoftActions.test.ts`
  - `packages/integrations/src/actions/integrations/mspSsoDomainActions.ts`
- Shared auth/runtime consumers that must stay binding-driven:
  - `packages/auth/src/lib/sso/mspSsoResolution.ts`
  - `packages/auth/src/lib/sso/teamsMicrosoftProviderResolution.ts`
  - `server/src/app/api/auth/msp/sso/discover/route.ts`
  - `server/src/app/api/auth/msp/sso/resolve/route.ts`
  - `ee/server/src/lib/auth/teamsMicrosoftProviderResolution.ts`
- Shared schema and migration coverage:
  - `server/migrations/20260307143000_create_microsoft_profile_consumer_bindings.cjs`
  - `server/src/test/unit/migrations/microsoftConsumerBindingsMigration.test.ts`

## Unsupported Edge States / Manual Cleanup

- Tenants with an active Microsoft calendar provider but no explicit `calendar` binding should be backfilled or rebound during migration; the steady-state runtime should not silently fall back to `is_default`.
- Tenants with archived Microsoft profiles still bound to active consumers should hit archive/delete guards until the binding is reassigned or cleared.
- If Outlook email temporarily retains fallback behavior, that fallback must stay isolated and documented as migration-only cleanup work instead of appearing in CE provider UX.

## Review Checklists

- CE review checklist:
  - No Calendar category remains visible in `Settings -> Integrations`.
  - No Calendar tab remains visible in `Profile`.
  - Calendar callback and webhook URLs fail clearly with enterprise-only behavior instead of partially executing.
  - Microsoft profile UI shows only MSP SSO-oriented copy and one binding control.
- EE review checklist:
  - Calendar settings remain fully configurable from `Settings -> Integrations -> Calendar`.
  - Profile `Calendar` tab remains functional.
  - Calendar callback and webhook URLs delegate to EE implementations and preserve current success/error behavior.
  - Microsoft profile UI shows MSP SSO, Email, Calendar, and Teams consumer controls.
- Regression checklist:
  - Teams EE cleanup remains intact; no shared Teams runtime is reintroduced.
  - MSP SSO discovery and resolve flows still use shared Microsoft profile infrastructure.
  - Email binding strategy is explicit and not left to compatibility-default assumptions.
  - Archive/delete guards still block profiles that remain actively bound.
  - Shared wrappers do not import EE files via raw filesystem-relative paths.
- Final acceptance checklist:
  - CE has no live calendar UI or runtime behavior.
  - EE retains complete calendar settings, profile, callback, webhook, and runtime behavior.
  - Microsoft consumer selection is binding-driven and edition-aware.
  - The legacy Microsoft consumers pane and default-compatibility wording are gone.

## Working Log

- (2026-03-09) Strengthened the PRD with explicit continuation references to the 2026-03-07 Microsoft/Teams plan and the 2026-03-08 Teams EE-only migration plan.
- (2026-03-09) Added calendar and Microsoft edition-contract matrices, CE stub/EE delegation rules, stable route commitments, intentional deletions, and a final acceptance matrix.
- (2026-03-09) Expanded the scratchpad with file inventories, focused validation suites, unsupported-edge-state notes, and CE/EE/regression review checklists so the migration can proceed without reopening scope discovery.
- (2026-03-09) Implemented the first calendar UI ownership slice:
  - added `calendarAvailability.ts` as the shared edition-aware source for Calendar category/tab visibility and fallback resolution,
  - moved settings Calendar rendering behind `CalendarEnterpriseIntegrationSettings`,
  - moved profile Calendar rendering behind `@enterprise/components/settings/profile/CalendarProfileSettings`,
  - removed CE Calendar discovery from settings navigation and profile tabs while preserving EE deep-link behavior.
- (2026-03-09) Updated the CE `packages/ee` Calendar settings/profile stubs to return explicit enterprise-only messaging when those wrappers are imported directly, while keeping the normal CE navigation surfaces hidden.
- (2026-03-09) Added focused tests for CE/EE Calendar visibility:
  - helper tests for category/tab resolution,
  - `IntegrationsSettingsPage.calendar.test.tsx` for CE hiding and EE visibility/provider copy,
  - `UserProfile.calendar.contract.test.ts` for the profile EE wrapper boundary.
- (2026-03-09) Implemented the calendar OAuth callback ownership slice:
  - moved the live Google and Microsoft calendar callback handlers to `ee/server/src/app/api/auth/.../calendar/callback/route.ts`,
  - replaced the shared callback files with CE stubs plus EE delegators,
  - added `packages/ee` callback stubs so CE builds remain import-safe,
  - kept the public callback URLs stable while removing live callback imports from shared route wrappers.
- (2026-03-09) Added `calendarCallbackRoutes.delegator.test.ts` to verify:
  - CE returns enterprise-only payloads,
  - EE delegates the original `Request` object to the EE route handlers,
  - shared callback wrappers no longer import `CalendarProviderService`, adapters, or OAuth-state logic directly.
- (2026-03-09) Updated the written migration artifacts to treat Calendar as an EE-owned surface consistently:
  - no checked-in screenshots needed refresh,
  - the PRD/checklists describe Calendar as EE-only,
  - the runbook references now point to the EE-owned settings/profile/callback entrypoints instead of a shared Calendar surface.
- (2026-03-09) Implemented the calendar webhook route ownership slice:
  - moved the live Google and Microsoft webhook handlers to `ee/server/src/app/api/calendar/webhooks/.../route.ts`,
  - replaced the shared webhook route files with CE stubs plus EE delegators,
  - added `packages/ee` webhook stubs so CE builds remain import-safe,
  - kept the public webhook URLs stable while removing shared re-exports of live webhook handlers.
- (2026-03-09) Extended the route-contract tests to verify:
  - CE webhook routes fail clearly with enterprise-only responses,
  - EE webhook routes delegate GET/POST/OPTIONS to EE handlers,
  - callback tests still cover CE unavailable behavior, EE delegation, and malformed callback input through the EE implementations.
- (2026-03-09) Confirmed middleware/auth handling has no calendar-callback-specific CE feature wiring:
  - callback URLs still flow through the generic `/api/auth/*` boundary,
  - webhook URLs remain explicitly unauthenticated for stable external delivery,
  - the shared route files no longer advertise live calendar webhook codepaths as CE-owned behavior.
- (2026-03-09) Moved the calendar webhook maintenance job entrypoint behind an edition-safe wrapper:
  - shared `server/src/lib/jobs/handlers/calendarWebhookMaintenanceHandler.ts` now no-ops in CE and lazy-loads the EE implementation,
  - live maintenance logic now resides in `packages/ee/src/lib/jobs/handlers/calendarWebhookMaintenanceHandler.ts`,
  - focused tests verify CE no-op behavior, EE delegation, and removal of direct maintenance-service imports from the shared handler wrapper.
- (2026-03-09) The route runbook references now cover the full current EE ownership chain for calendar network entrypoints:
  - callback wrappers delegate to `ee/server/src/app/api/auth/.../calendar/callback/route.ts`,
  - webhook wrappers delegate to `ee/server/src/app/api/calendar/webhooks/.../route.ts`,
  - maintenance job entrypoints delegate through `server/src/lib/jobs/handlers/calendarWebhookMaintenanceHandler.ts` into `packages/ee/src/lib/jobs/handlers/calendarWebhookMaintenanceHandler.ts`.
- (2026-03-09) Confirmed the Calendar settings UI boundary remains stable:
  - `IntegrationsSettingsPage.tsx` renders `CalendarEnterpriseIntegrationSettings`,
  - `CalendarEnterpriseIntegrationSettings.tsx` dynamically imports `@enterprise/components/settings/integrations/CalendarIntegrationsSettings`,
  - the shared settings composition no longer imports the concrete Calendar UI directly.
- (2026-03-09) Implemented the Microsoft explicit-binding UI and action cleanup slice:
  - added `packages/integrations/src/lib/microsoftConsumerVisibility.ts` as the edition-aware source of truth for which Microsoft consumers are visible in CE vs EE,
  - rewrote `packages/integrations/src/components/settings/integrations/MicrosoftIntegrationSettings.tsx` to remove the legacy consumers pane, render one explicit binding row per visible consumer, and make CE copy MSP-SSO-only while EE copy covers MSP SSO, email, calendar, and Teams,
  - updated `packages/integrations/src/actions/integrations/microsoftActions.ts` so CE rejects EE-only consumer binding writes, status payloads expose edition-appropriate redirect/scope metadata, and `resolveMicrosoftProfileForConsumer()` no longer falls back to the default profile when no explicit binding exists,
  - kept the legacy binding backfill helper in place for migration-safe rows, so the remaining fallback/backfill cleanup items stay open even though active resolution now uses binding rows.
- (2026-03-09) Added focused Microsoft validation coverage:
  - `packages/integrations/src/lib/microsoftConsumerVisibility.test.ts` covers CE/EE consumer visibility contracts,
  - `packages/integrations/src/actions/integrations/microsoftConsumerBindings.test.ts` covers CE write rejection, EE reassignment, archive/permission guards, and Teams explicit-binding resolution,
  - `packages/integrations/src/actions/integrations/microsoftActions.test.ts` covers CE vs EE Microsoft status metadata shaping,
  - `packages/integrations/src/components/settings/integrations/MicrosoftIntegrationSettings.contract.test.tsx` covers the new explicit-binding UI, CE/EE copy differences, archived-profile filtering, and removal of the legacy compatibility pane/codepath.
- (2026-03-09) Microsoft slice validation commands:
  - `cd server && pnpm vitest run --config vitest.config.ts ../packages/integrations/src/lib/microsoftConsumerVisibility.test.ts ../packages/integrations/src/actions/integrations/microsoftConsumerBindings.test.ts ../packages/integrations/src/actions/integrations/microsoftActions.test.ts ../packages/integrations/src/components/settings/integrations/MicrosoftIntegrationSettings.contract.test.tsx ../src/test/unit/components/integrations/TeamsIntegrationSettings.contract.test.tsx`
  - `cd server && pnpm exec tsc -p tsconfig.json --noEmit --pretty false`
- (2026-03-09) Tightened the binding UX contract so the placeholder option remains a no-op rather than an implicit clear:
  - `MicrosoftIntegrationSettings.contract.test.tsx` now asserts that selecting the empty option does not issue a binding write,
  - this keeps the current product rule explicit: bindings can be reassigned from this surface, but not silently cleared.
- (2026-03-09) Teams rebinding now invalidates stale Teams install state from the Microsoft binding action itself:
  - `setMicrosoftConsumerBinding()` updates `teams_integrations.selected_profile_id` when the Teams consumer is rebound,
  - active/installing Teams records are pushed back to `install_pending` and their package metadata, bot/app IDs, and last error are cleared,
  - the focused binding test also asserts unrelated Microsoft consumer bindings remain unchanged during that rebinding.
- (2026-03-09) Email and calendar rebinding remain on the “prompt reconnection” path in the Microsoft settings UI:
  - the consumer descriptors now carry explicit reconnect warnings for Outlook email and Microsoft calendar,
  - `MicrosoftIntegrationSettings.contract.test.tsx` asserts those rebind toasts mention re-authorization so the operator-facing reconnection contract stays covered.
- (2026-03-09) Replaced the blanket Microsoft compatibility binding backfill with migration-scoped explicit binding materialization:
  - `packages/integrations/src/actions/integrations/microsoftActions.ts` no longer exports `resolveMicrosoftProfileForCompatibility` and no longer invents `email/calendar/msp_sso` bindings from the default profile on every read,
  - the action layer now materializes explicit binding rows only when legacy state proves a tenant needs them:
    - `msp_sso` from active `msp_sso_tenant_login_domains`,
    - `email` from existing `email_providers` rows with `provider_type = 'microsoft'`,
    - `calendar` from existing `calendar_providers` rows with `provider_type = 'microsoft'`,
  - `listMicrosoftConsumerBindings()` now returns visible consumers with `profileId: null` when no explicit binding or migration signal exists, and `resolveMicrosoftProfileForConsumer()` returns `null` in the same case instead of falling back to the default profile.
- (2026-03-09) Updated the focused Microsoft action tests to lock in the new migration-scoped binding behavior:
  - `microsoftConsumerBindings.test.ts` now covers migration-triggered MSP SSO/email/calendar backfill signals plus the no-legacy-signal path where all migrated consumers remain explicitly unbound,
  - `microsoftActions.test.ts` now seeds login-domain/email/calendar legacy state only when asserting migrated consumer visibility, and verifies the public integrations action indexes expose the binding-driven API surface without the removed compatibility export.
- (2026-03-09) Remaining Microsoft runtime gap after this slice:
  - active MSP SSO, Outlook email, and Microsoft calendar runtime credential readers still consume mirrored tenant secrets in their own packages/routes,
  - the binding table now drives the shared Microsoft settings/action layer and migration materialization logic, but the next slice still has to cut those runtime credential lookups over to explicit binding resolution.
- (2026-03-09) Cut the remaining Microsoft runtime consumer resolution paths over to explicit bindings for email, calendar, and Teams:
  - added `packages/integrations/src/lib/microsoftConsumerProfileResolution.ts` as the shared binding-aware runtime resolver for `msp_sso`, `email`, `calendar`, and `teams`,
  - the resolver now materializes migration-safe `msp_sso`, `email`, and `calendar` bindings only from concrete legacy usage signals (`msp_sso_tenant_login_domains`, `email_providers`, `calendar_providers`) while failing closed for unsupported/no-signal cases,
  - `packages/integrations/src/actions/email-actions/oauthActions.ts`, `server/src/app/api/auth/microsoft/callback/route.ts`, and `server/src/services/email/providers/MicrosoftGraphAdapter.ts` now resolve Microsoft email credentials from the bound profile instead of tenant/env fallbacks,
  - `packages/ee/src/lib/actions/integrations/calendarActions.ts`, `ee/server/src/app/api/auth/microsoft/calendar/callback/route.ts`, and `packages/ee/src/lib/services/calendar/providers/MicrosoftCalendarAdapter.ts` now resolve Microsoft calendar credentials from the bound profile instead of tenant/env fallbacks,
  - replaced the leftover `packages/ee/src/lib/auth/teamsMicrosoftProviderResolution.ts` stub with the real binding-aware Teams resolver so the shared Teams runtime wrapper no longer collapses to `not_configured`.
- (2026-03-09) Added focused runtime-resolution coverage for this slice:
  - `packages/integrations/src/lib/microsoftConsumerProfileResolution.test.ts` covers email binding resolution, calendar migration backfill, and invalid-profile failure modes,
  - `server/src/test/unit/microsoft/microsoftConsumerRuntimeResolution.contract.test.ts` asserts the active email/calendar OAuth and token-refresh callers import the shared resolver and no longer reach for direct Microsoft env/tenant secrets,
  - `packages/auth/src/lib/sso/teamsMicrosoftProviderResolution.test.ts` now passes against the real `packages/ee` Teams resolver instead of the old stub.
- (2026-03-09) Runtime-resolution validation commands:
  - `cd server && pnpm vitest run --config vitest.config.ts ../packages/integrations/src/lib/microsoftConsumerProfileResolution.test.ts src/test/unit/microsoft/microsoftConsumerRuntimeResolution.contract.test.ts ../packages/auth/src/lib/sso/teamsMicrosoftProviderResolution.test.ts src/test/unit/lib/teams/teamsRuntimeOwnership.contract.test.ts ../packages/integrations/src/actions/integrations/microsoftConsumerBindings.test.ts`
  - `cd server && pnpm exec tsc -p tsconfig.json --noEmit --pretty false`
- (2026-03-09) Cut the remaining MSP SSO Microsoft auth runtime off the legacy default-profile/tenant-secret path:
  - `packages/auth/src/lib/sso/mspSsoResolution.ts` now checks Azure AD tenant readiness through `resolveMicrosoftConsumerProfileConfig(tenant, 'msp_sso')` instead of direct `microsoft_client_*` tenant secrets,
  - `packages/auth/src/lib/nextAuthOptions.ts` now hydrates request-scoped Azure AD OAuth credentials from the bound `msp_sso` Microsoft profile when the resolver cookie selects a tenant source,
  - this leaves Google on its existing tenant/app secret path, but removes the last active Microsoft runtime consumer-resolution path that still bypassed explicit bindings.
- (2026-03-09) Added MSP SSO runtime regression coverage for the binding cutover:
  - `packages/integrations/src/lib/microsoftConsumerProfileResolution.test.ts` now covers `msp_sso` binding backfill from active login domains plus the fail-closed path once no binding signal remains,
  - `packages/auth/src/lib/sso/mspSsoResolution.test.ts` now exercises Azure AD tenant readiness through the shared binding resolver rather than direct Microsoft tenant secret reads,
  - `packages/auth/src/lib/nextAuthOptions.mspContract.test.ts` and `server/src/test/unit/microsoft/microsoftConsumerRuntimeResolution.contract.test.ts` now assert the shared auth runtime imports the binding-aware Microsoft resolver instead of direct tenant-secret lookups.
- (2026-03-09) MSP SSO binding-runtime validation commands:
  - `cd server && pnpm vitest run --config vitest.config.ts ../packages/auth/src/lib/sso/mspSsoResolution.test.ts ../packages/auth/src/lib/nextAuthOptions.mspContract.test.ts ../packages/integrations/src/lib/microsoftConsumerProfileResolution.test.ts src/test/unit/microsoft/microsoftConsumerRuntimeResolution.contract.test.ts`
  - `cd server && pnpm exec tsc -p tsconfig.json --noEmit --pretty false`
- (2026-03-09) Reduced the Microsoft `is_default` flag back to profile-management metadata instead of a consumer-routing hint:
  - `packages/integrations/src/lib/microsoftConsumerProfileResolution.ts` now chooses migration backfill targets by matching the mirrored legacy Microsoft credentials to an active profile, or by using the only active profile when that choice is unambiguous,
  - `packages/integrations/src/actions/integrations/microsoftActions.ts` now reuses that candidate-selection helper for consumer binding materialization, so missing binding rows no longer attach to whichever profile happens to be marked default,
  - the binding UI still lets admins manage a default profile for profile CRUD and legacy secret mirroring, but the per-consumer binding rows no longer label a selected profile as the routing default.
- (2026-03-09) Added focused default-profile cleanup coverage:
  - `packages/integrations/src/actions/integrations/microsoftActions.test.ts` now proves enterprise email binding backfill follows the mirrored legacy Microsoft credentials instead of the `is_default` flag and fails closed when no unique routing candidate remains,
  - `packages/integrations/src/components/settings/integrations/MicrosoftIntegrationSettings.contract.test.tsx` now asserts binding summaries stop rendering `(default profile)` as part of consumer routing copy.
- (2026-03-09) Default-profile cleanup validation commands:
  - `cd server && pnpm vitest run --config vitest.config.ts ../packages/integrations/src/actions/integrations/microsoftActions.test.ts ../packages/integrations/src/components/settings/integrations/MicrosoftIntegrationSettings.contract.test.tsx ../packages/integrations/src/lib/microsoftConsumerProfileResolution.test.ts ../packages/auth/src/lib/sso/mspSsoResolution.test.ts ../packages/auth/src/lib/nextAuthOptions.mspContract.test.ts src/test/unit/microsoft/microsoftConsumerRuntimeResolution.contract.test.ts`
  - `cd server && pnpm exec tsc -p tsconfig.json --noEmit --pretty false`
- (2026-03-09) Removed the last compatibility-default language from the shared Microsoft schema comments:
  - `server/migrations/20260307120000_create_microsoft_profiles.cjs` now states that `is_default` is profile-management metadata only,
  - `server/migrations/20260307143000_create_microsoft_profile_consumer_bindings.cjs` now states that each consumer chooses a profile through an explicit binding row,
  - `server/src/test/unit/microsoft/microsoftConsumerSchema.contract.test.ts` locks in that wording so future migration edits do not reintroduce default-profile routing language.
- (2026-03-09) Default-profile cleanup follow-up:
  - `packages/integrations/src/actions/integrations/microsoftActions.test.ts` now pins the CE status contract to `NEXT_PUBLIC_EDITION=community` so the MSP SSO-only assertions remain deterministic regardless of the outer test environment.
- (2026-03-09) Closed the remaining migration-coverage and artifact-contract gaps:
  - added `server/src/test/unit/calendar/calendarMigrationOwnership.contract.test.ts` to lock in the fresh-install boundary where CE keeps shared Microsoft binding schema but omits EE calendar table-creation migrations, while EE adds the calendar migration set and concrete runtime entrypoints,
  - added `server/src/test/unit/docs/calendarMicrosoftMigrationPlan.contract.test.ts` to keep the dated plan folder self-contained, cross-referenced, and aligned on CE/EE contracts, validation runbooks, and review/regression checklists,
  - expanded `packages/integrations/src/actions/integrations/microsoftConsumerBindings.test.ts` so migration coverage now explicitly includes tenants with no Microsoft profiles, one active profile and no binding rows, active calendar-provider alignment, and archived-profile fail-closed behavior.
- (2026-03-09) Final broad validation command for the remaining calendar and Microsoft plan items:
  - `cd server && pnpm exec vitest run --coverage.enabled=false ../packages/integrations/src/lib/calendarAvailability.test.ts src/test/unit/components/integrations/IntegrationsSettingsPage.calendar.test.tsx src/test/unit/components/profile/UserProfile.calendar.contract.test.ts src/test/unit/api/calendarCallbackRoutes.delegator.test.ts src/test/unit/api/calendarWebhookRoutes.delegator.test.ts src/test/unit/jobs/calendarWebhookMaintenanceHandler.delegator.test.ts src/test/unit/calendar/calendarActions.ceBoundary.test.ts src/test/unit/calendar/calendarActions.ee.contract.test.ts src/test/unit/calendar/calendarActions.sync.test.ts src/test/unit/calendar/calendarSyncSubscriber.delegator.test.ts src/test/unit/calendar/calendarSyncSubscriber.ee.test.ts src/test/unit/calendar/calendarRuntimeOwnership.contract.test.ts src/test/unit/calendar/calendarMigrationOwnership.contract.test.ts ../packages/integrations/src/actions/integrations/microsoftConsumerBindings.test.ts ../packages/integrations/src/actions/integrations/microsoftActions.test.ts ../packages/integrations/src/lib/microsoftConsumerProfileResolution.test.ts src/test/unit/microsoft/microsoftConsumerRuntimeResolution.contract.test.ts src/test/unit/microsoft/microsoftConsumerSchema.contract.test.ts src/test/unit/docs/calendarMicrosoftMigrationPlan.contract.test.ts`
  - `cd server && pnpm exec tsc -p tsconfig.json --noEmit --pretty false`
  - `python3 /Users/roberisaacs/.codex/skills/alga-plan/scripts/validate_plan.py ee/docs/plans/2026-03-09-calendar-sync-enterprise-migration-and-microsoft-profile-explicit-bindings`
- (2026-03-09) Added the remaining migration-regression coverage for fresh installs, existing calendar rows, and explicit-binding edge cases:
  - `server/src/test/unit/calendar/calendarActions.ceBoundary.test.ts` now proves fresh/community installs still fail closed for both provider listing and direct sync attempts even when a calendar provider id is supplied,
  - `server/src/test/unit/calendar/calendarActions.ee.contract.test.ts` and `server/src/test/unit/calendar/calendarActions.sync.test.ts` now lock in that fresh enterprise installs and existing provider rows continue through the EE-owned action/service path,
  - `packages/integrations/src/actions/integrations/microsoftConsumerBindings.test.ts` now covers tenants with no Microsoft profiles, a single default profile plus legacy calendar usage, archived-profile binding guards, and invalid cross-tenant binding attempts,
  - `packages/integrations/src/lib/microsoftConsumerProfileResolution.test.ts` keeps the archived/missing-credential runtime failure path explicit.
- (2026-03-09) Added cleanup contracts for the last remaining unchecked migration items:
  - `server/src/test/unit/calendar/calendarRuntimeOwnership.contract.test.ts` now ties the shared Microsoft binding-schema wording to the EE-owned calendar runtime tree,
  - `server/src/test/unit/components/integrations/IntegrationsSettingsPage.calendar.test.tsx` now carries the explicit replacement coverage for the old CE-calendar-visible expectations.
- (2026-03-09) Migration-regression validation commands for the final unchecked calendar/binding items:
  - `cd server && pnpm vitest run --config vitest.config.ts ../packages/integrations/src/actions/integrations/microsoftConsumerBindings.test.ts ../packages/integrations/src/lib/microsoftConsumerProfileResolution.test.ts src/test/unit/calendar/calendarActions.ceBoundary.test.ts src/test/unit/calendar/calendarActions.ee.contract.test.ts src/test/unit/calendar/calendarActions.sync.test.ts src/test/unit/calendar/calendarRuntimeOwnership.contract.test.ts src/test/unit/components/integrations/IntegrationsSettingsPage.calendar.test.tsx`
  - `cd server && pnpm exec tsc -p tsconfig.json --noEmit --pretty false`
- (2026-03-09) Added a dedicated plan-contract test for the migration artifacts themselves:
  - `server/src/test/unit/docs/calendarSyncEnterpriseMigrationPlan.contract.test.ts` now locks the shared entrypoint/helper rules, calendar and Microsoft inventories, compatibility deletions, stable route commitments, CE-stub/EE-delegation documentation, the Microsoft CE/EE surface matrix, and the final acceptance matrix directly against the PRD and scratchpad.
- (2026-03-09) Plan-contract validation commands:
  - `cd server && pnpm vitest run --config vitest.config.ts src/test/unit/docs/calendarSyncEnterpriseMigrationPlan.contract.test.ts`
  - `cd server && pnpm exec tsc -p tsconfig.json --noEmit --pretty false`