# Personal Data Export

## Objective

Give a user everything you hold about them, safely.

A subject-access-request flow that gathers one person's data from every table and file store, packages it, and delivers it to a verified requester.

## 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. Enumerate every place personal data lives for a single user — profile, content, comments, activity, sessions, billing, support messages, uploaded files — and assemble the export from that list, not from whatever a list view happens to show.
2. Verify identity before generating and again before releasing the file. Re-authenticate, and require the account's second factor if one is enabled.
3. Generate asynchronously and notify the user when it is ready. A complete export can take minutes and must not run in a web request.
4. Package machine-readable structured data alongside a plain human-readable index that explains what each file contains.
5. Deliver via a single-use, short-lived, unguessable link, and delete the generated archive when it expires.
6. Do NOT include other people's data. Shared threads, workspace records, and messages the user received contain third parties — include the requester's contributions and redact the rest, and never include another user's email or personal fields.

## 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 export archive is itself a breach vector: it is the most concentrated copy of a person's data you will ever produce. Encrypt at rest, expire fast, and never email it as an attachment.
- Jointly owned workspace data belongs to the workspace, not the individual. Decide and document what a member gets versus what an owner gets.
- Do not email the download link to an address the requester changed minutes earlier — check for a recent email change and require confirmation.
- Rate-limit requests. Repeated export generation is an easy denial-of-service and an easy way to leave copies lying around.
- Derived and inferred data counts too: computed scores, segments, and internal tags about the person belong in the export.
- Very large accounts need chunked archives or streaming; a single multi-gigabyte file will fail on download.
- Log that an export was requested, generated, and downloaded, including by whom — but do not log its contents.

## 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 export covers every store holding the requester's personal data, per a documented data map.
- [ ] Identity is verified before generation and before download.
- [ ] Generation is asynchronous and the user is notified on completion.
- [ ] The archive contains structured data plus a readable explanation of its contents.
- [ ] Download links are single-use, expiring, and unguessable, and the archive is deleted on expiry.
- [ ] No third party's personal data appears in the export.
- [ ] Export requests are rate-limited and audit-logged.
- [ ] 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.