# AI Meeting Notes

## Objective

Turn a transcript into notes, decisions, and follow-ups the organiser reviews.

A reviewable draft of structured meeting notes — summary, decisions, owners, and follow-up items — generated from an existing transcript and linked back to it.

## 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. Find where transcripts already arrive in the app and treat the transcript as the only input. Do not add recording, upload, or speaker diarization here; if no transcript exists, this feature has nothing to run on.
2. Run the analysis through the app's existing background-job system and show the meeting in a clearly labelled processing state. A long transcript will outlive a web request and a queued job is the only honest way to represent the wait.
3. Produce a draft that the organiser reads, edits, and publishes. Do not create tasks, assign owners, or notify anyone until a person has approved the draft, because a confidently wrong assignment costs more than the note saves.
4. Attach a transcript position or timestamp to every decision and follow-up so a reader can check the claim against what was actually said, and make that link the primary way disputes get settled.
5. Set a token ceiling, a wall-clock timeout, and a retry limit per meeting. When a ceiling is reached, keep whatever was produced, mark the notes as covering only part of the meeting, and say where the coverage stopped.

## 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

- A transcript mixes firm commitments with musing and hypotheticals. Anything recorded as a decision or an action must be traceable to explicit language; suggestions and speculation belong in the summary, not the follow-up list.
- Diarization is often wrong or missing, leaving unlabelled or merged speakers. When the speaker behind a commitment is uncertain, leave the owner unset and mark it for the organiser rather than guessing.
- An item whose supporting timestamp cannot be located must be shown as unsourced, not silently presented alongside items that do link back.
- Assigning a follow-up to the wrong person is the failure that destroys trust in the feature. Only offer owners who were actually present, and never match a name to a user account on a partial or ambiguous string.
- Transcripts arrive truncated, full of crosstalk, or switching between languages mid-meeting. Detect these conditions up front, state them on the draft, and do not present degraded output as if it were complete.
- A refusal, a timeout, or output that does not parse into the expected structure must leave the meeting in a failed state with a retry, not an empty set of notes that reads as a meeting where nothing happened.
- The transcript may contain material the account has not agreed to send to a model provider. Make the provider boundary explicit in settings, and let an account turn the feature off entirely without breaking the meeting record.
- When the model is unavailable the meeting page must still show the raw transcript and its participants, with the notes section marked unavailable rather than the whole page erroring.

## 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

- [ ] Notes are generated from an existing transcript in a background job, with a visible processing state.
- [ ] Every decision and follow-up either links to a transcript position or is marked unsourced.
- [ ] No task is created and no notification is sent until the organiser approves the draft.
- [ ] Owners are drawn only from confirmed participants, and an uncertain owner is left unset.
- [ ] Truncated, noisy, or multilingual transcripts produce output labelled with those limitations.
- [ ] Token, time, and retry ceilings are enforced per meeting and a partial result is retained rather than discarded.
- [ ] With the model unavailable, the meeting and its transcript remain viewable.
- [ ] 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.