# AI Message Editing

## Objective

Rephrase an earlier message and get the conversation regenerated from there.

In-place editing of a previously sent user message, with the original preserved and the responses below it regenerated.

## 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. Make editing produce a new version of the message rather than overwriting it, and keep every prior version retrievable for audit and undo.
2. On save, invalidate only the responses descending from the edited message and regenerate from that point, leaving earlier turns and unrelated branches untouched.
3. Restrict editing to messages the user authored. Model output is regenerated, not hand-edited, or the transcript stops being a record of what the model said.
4. Re-resolve attachments, retrieved sources, and citations against the edited message, and refuse to carry forward a reference that no longer applies.
5. AI Conversation Branching owns the message graph and navigation between versions. Implement an edit as a fork in that graph rather than as a destructive rewrite, and do not build a second history mechanism.

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

- The original text must survive the edit. Keep every version with its author and timestamp, so an edit can be undone and the record of what was actually asked is not lost.
- Regeneration must invalidate the descendants of the edited message only. Discarding the whole conversation, or leaving stale answers below the edit, both misrepresent the thread.
- If a downstream turn already performed a real action such as sending, purchasing, or writing to another system, editing above it cannot undo that. Warn explicitly and name what already happened.
- Attachments and citations attached to the old text may be irrelevant to the new. Re-resolve them, and drop any whose source has since been deleted rather than rendering a broken reference.
- A conversation someone else is viewing or has a link to must not change silently underneath them. Show that it was edited and when, and decide whether shared links pin the version they were shared at.
- An edit that produces no meaningful change should not trigger a regeneration and a fresh charge.
- Editing while a response below is still generating must cancel that run first rather than racing it.
- Usage and quota accounting must treat the regeneration as a new run, and the counting rule should match the one used by Stop and Regenerate Controls.

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

- [ ] Editing preserves every earlier version of the message with author and timestamp.
- [ ] Only descendants of the edited message are invalidated and regenerated.
- [ ] Model output cannot be edited by hand; only user-authored messages are editable.
- [ ] Downstream tool actions that already occurred are surfaced as a warning and never silently reversed.
- [ ] Attachments and citations are re-resolved, and stale references are dropped rather than shown broken.
- [ ] Shared or concurrently viewed conversations show that an edit occurred rather than changing silently.
- [ ] Edits are implemented as forks in the conversation graph, not destructive rewrites.
- [ ] 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.