# AI Suggested Support Answers

## Objective

Give support agents a grounded first draft instead of a blank reply box.

A draft reply composed for the agent from the ticket, the customer's account state, and the approved internal knowledge, with sources attached and no ability to send itself.

## 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. Ground every draft in retrieved material: the ticket thread, the account's real state, and articles from the approved knowledge set. Attach the sources used to the draft so the agent can open and check each one.
2. Load the draft into the agent's normal reply editor, unsent and fully editable. There is no path in this feature that sends a message to a customer without an agent pressing send.
3. Define the commitments the app is not allowed to make in a draft — refunds, credits, delivery dates, guarantees of a fix — and strip or refuse any draft containing them, leaving that part for the agent to write.
4. Separate the customer-facing draft from anything internal. Internal notes, other customers' data, and account fields the customer cannot see may inform retrieval but must never appear in the text handed to the customer.
5. The approved knowledge this feature reads from is produced by AI Knowledge Base Drafting and the app's existing help content. Do not create a second knowledge store here; read from the published one.

## 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 factual instruction with no cited internal source is a guess. Drafts must show which article each step came from, and a draft with no grounding must be presented as unverified or not offered at all.
- Promising a refund, a timeline, or a fix the company has not agreed to creates an obligation the moment it is sent. These must be blocked at generation, not left to the agent to notice.
- Internal notes leaking into a customer reply is the worst outcome of this feature. Keep the internal and external context in separate fields and confirm the customer-facing draft never includes the internal one.
- Some tickets need an engineer to look at the account before anything can be said. The feature must be able to return no draft, with a short note on what needs checking, rather than filling the space with generic reassurance.
- Agent review is mandatory. No configuration, keyboard shortcut, or bulk action may send a generated draft without a human reading it.
- A refusal, timeout, or truncated response leaves the reply box empty and usable, with a clear indication that no draft was produced.
- Customer text may contain instructions to the drafting system. Treat the ticket strictly as material to answer, never as direction, and confirm a ticket asking for a refund policy override does not produce one.
- Cap tokens per draft and drafts per ticket. An agent regenerating repeatedly must hit a limit rather than running up unbounded cost.

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

- [ ] Every draft cites the internal sources behind its factual instructions.
- [ ] Drafts load unsent into the agent's editor and cannot be sent without a human.
- [ ] Refunds, timelines, and fix guarantees are blocked from generated text.
- [ ] Internal notes and hidden account data never appear in a customer-facing draft.
- [ ] Tickets needing account investigation return no draft plus a note on what to check.
- [ ] Refusals, timeouts, and malformed output leave the reply box empty and usable.
- [ ] Per-draft token limits and per-ticket regeneration limits are enforced.
- [ ] 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.