# Zoom Meeting Creation

## Objective

Create Zoom meetings from the app with the right host, passcode, and recording rules.

Meeting creation and updates on a connected Zoom account, with host selection, access-controlled join details, and reconciliation.

## Before You Begin

This feature is being added to an application that already exists and already
works. Do not scaffold a new project, and do not assume a blank slate.

Inspect the codebase first and establish:

- The existing application structure and where code of this kind already lives.
- The framework and version in use.
- The existing design system — colours, spacing, typography, and component conventions.
- Existing UI components you can reuse instead of writing new ones.
- The existing database structure, if this feature needs to persist anything.
- The existing authentication and authorization system, if this feature is user-scoped.
- Dependencies already installed, so you don't add a library that duplicates one.
- The existing test setup and conventions.

Only start writing code once you understand the above. If the application
already implements part of this feature, extend it rather than replacing it.

## Implementation Instructions

1. Let the user choose which licensed host a meeting is created under, and validate that the host still holds a license at creation time. A meeting created under an unlicensed or deactivated host will be silently limited or rejected.
2. Treat the join URL and passcode as access credentials. Show them only to the meeting's participants and the record's authorized viewers, keep them out of activity feeds, exported reports, and shared links, and redact them from logs and error reports.
3. Read the account's recording, waiting-room, and authentication policies before sending settings, and never send a value the account forbids. Present what the policy will actually apply rather than what the user selected locally.
4. Store the returned meeting reference and, for a series, the occurrence reference against the app record, so a later update targets exactly the meeting or occurrence intended.
5. Do all creation and update work through the app's existing background-job system, and if Google Calendar Event Creation or Microsoft Outlook Calendar Events is present, let the calendar brief own the calendar entry and this one own only the meeting and its join details.

## UI and UX Requirements

Match the application's existing design system exactly. Reuse its components,
spacing, and typography. This feature should look like it was always there.

## Responsive Requirements

Works on mobile, tablet, and desktop. Touch targets are large enough to hit on a
phone, and nothing overflows horizontally at 320px.

## Accessibility Requirements

- Fully keyboard navigable.
- Correct semantic elements and ARIA roles.
- Visible focus states.
- Meets WCAG AA contrast.
- Dynamic changes are announced to screen readers.
- Respects prefers-reduced-motion.

## Edge Cases

- Creating under the wrong host produces a meeting nobody can start. Verify the selected host's license and status at creation, and when it has lapsed fail with a clear message naming the host rather than falling back to an arbitrary account.
- Join URLs and passcodes leak easily through notifications, exports, and shared record views. Gate them behind the same permission that governs the record, and never include them in an email sent to an address that has not been confirmed as a participant.
- A recurring meeting is a series with occurrences, and editing one is not editing all. Make the scope explicit whenever a user changes a recurring meeting, and store enough reference to target a single occurrence without disturbing the rest.
- Account-level policies on recording, waiting rooms, and authenticated join override anything the app requests. Read the effective policy, disable the controls it forbids, and explain why rather than letting a user set an option that is silently discarded.
- A meeting deleted or rescheduled directly in Zoom leaves the app showing a dead link. Reconcile on the next sync, mark the record as diverged, and offer to recreate or unlink instead of quietly recreating it.
- Tokens expire and an administrator can revoke the app for the whole account. Refresh ahead of expiry, and on revocation disconnect the integration and stop issuing calls rather than retrying rejected requests.
- Zoom enforces per-account rate limits and different limits per endpoint class. Back off with jitter, pace bulk creation, and never retry a validation rejection as though it were a transient failure.
- When Zoom is unavailable the underlying appointment must still be bookable. Save the record, queue the meeting creation, show a pending state on the record, and notify the organizer once the link exists.

## Testing

Exercise the feature end to end in the running application. Cover every edge case
above, then run the existing test suite and confirm nothing regressed.

## Acceptance Criteria

- [ ] The host is selected explicitly and validated as licensed and active at creation time.
- [ ] Join URLs and passcodes are visible only to authorized viewers and are absent from logs and exports.
- [ ] Recurring meetings store both series and occurrence references, and edit scope is explicit.
- [ ] Requested settings are reconciled against account policy before sending, with forbidden options disabled and explained.
- [ ] Meetings changed or deleted in Zoom are detected and flagged on the linked record.
- [ ] A Zoom outage leaves the record saved with the meeting creation queued and visibly pending.
- [ ] The feature matches the existing design system.
- [ ] No existing functionality is broken.

## Adaptation Rules

- Match the existing design system. Do not introduce a new colour palette,
  spacing scale, or component library.
- Reuse existing components and utilities wherever they fit.
- Follow the naming, file layout, and code style already present.
- Do not upgrade, replace, or remove existing dependencies to make this
  feature fit. Adapt the feature to the app, not the app to the feature.
- Do not break existing functionality. If a change is genuinely required in
  existing code, make the smallest one that works and say so.
- If something in these instructions conflicts with how the application is
  built, follow the application and explain the deviation.

## Final Verification

Before you report the work as done:

1. Re-read the acceptance criteria above and check each one against what you
   actually built.
2. Run the application and exercise the feature end to end.
3. Run the existing test suite and confirm you have broken nothing.
4. Check the feature on mobile, tablet, and desktop widths.
5. Check keyboard navigation and focus handling.
6. Summarize what changed: files added, files modified, and anything you
   deliberately did differently because of how this application is built.

If any acceptance criterion is unmet, fix it before reporting completion.