# AI Tone Adjustment

## Objective

Shift text toward a professional, friendly, direct, confident, or empathetic register.

A tone selector over a text selection that proposes a re-registered version with the facts and the request unchanged.

## 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. Offer a short closed list of tones and no free-text option. Each tone must have a written definition in the prompt so the same choice produces a consistent register across the app.
2. Hold the substance fixed. The request being made, the answer being given, the facts, and the figures must survive the shift unchanged; only phrasing, register, and hedging may move.
3. Show the adjusted text next to the original and require an explicit accept before it replaces anything. Tone is subjective, so the user must be the one who decides the result is better.
4. Let a workspace mark passages as locked — regulated disclosures, legal notices, standard clauses — and pass those through untouched, excluding them from the adjustable range entirely.
5. Restructuring for clarity or length belongs to AI Text Rewriting and error detection belongs to AI Grammar and Clarity Review. This feature owns register only; reuse the selection, preview, and accept mechanism the rewrite feature already provides.

## 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 friendlier version of a refusal is still a refusal. The concrete facts and the actual request must be present in the output, and a result that has dropped either must be rejected rather than shown.
- Tone instructions push models toward caricature: stereotyped register, performative warmth, or stacked exclamation. Constrain the output to plain professional prose and reject theatrical results.
- Locked regulated or legal wording must come through byte-for-byte. Verify it after generation, because a prompt instruction alone is not a guarantee.
- Nothing may be replaced without a preview. Tone changes look small in a diff and large to a recipient, so the user must see both versions before committing.
- Making bad news sound positive is the characteristic failure of this feature. A message conveying a delay, a rejection, or a problem must still read as one after an empathetic or confident adjustment.
- Applying two tones in succession compounds drift away from the original. Always adjust from the stored original rather than from the previous adjustment.
- A refusal, a timeout, or output that comes back truncated must leave the original text in place and say so plainly.
- With the model unavailable the tone control is disabled with a reason and the editor is otherwise unaffected.

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

- [ ] Tones come from a closed, documented list with consistent definitions.
- [ ] Facts, figures, and the underlying request are preserved and verified against the source.
- [ ] Passages marked locked are returned unchanged and confirmed unchanged after generation.
- [ ] No adjusted text replaces the original without a side-by-side preview and an explicit accept.
- [ ] A message carrying bad news still reads as such after adjustment.
- [ ] Successive adjustments start from the stored original, not the previous output.
- [ ] Model failure leaves the text untouched.
- [ ] 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.