# Errata Submission User Flow

Source-of-truth specification of the `errata-submission` user flow for `agentic-spec.com`. The flow lets a reader report an error in the book; submission is delegated to the user's default email client rather than transmitted by the site itself.

## Flow

### 1. Reader visits the `errata-submission` web page

A single, named page is the entry point for every errata report. The book's back-matter and any "report an error" prompt elsewhere point at this one URL.

**Rationale.** A single named entry keeps the surface the book has to expose stable and small — one URL the print and digital editions can reference for the life of the title. It also lets all errata-related behavior (navigation, form, submission) live in one place rather than spread across per-chapter pages.

### 2. The page displays the book's table of contents as an always-visible tree

Chapters, sections within each chapter, and subsections within each section render as a tree the user can navigate at any time. The tree is the primary content of the page and remains visible throughout the flow.

**Rationale — TOC, not a per-chapter button.** A per-chapter "report errata in this chapter" button would mean every chapter (and every back-matter listing of chapters) carries its own errata link, multiplying the surfaces the book has to expose and keep in sync as the book is reprinted or revised. A single TOC-driven entry point keeps that responsibility on the site: the book points to one URL, and the site owns navigation to a specific location. The TOC also helps readers who recognize an error but are not sure which chapter, section, or subsection it belongs to — they can browse the structure of the book rather than guess from a list of buttons.

### 3. Reader selects the chapter / section / subsection where the erratum is

The selection becomes the location of the report. The user can drill to whichever level fits the erratum — a chapter-level point stops at the chapter, a paragraph-level point drills into a subsection.

**Rationale.** Forcing the user to pick a location before writing the report (a) gives every report a structurally consistent location field rather than free-text wording like "in chapter X around the part about Y", (b) lets the site key the form's pre-composed email to a canonical location, and (c) lets the user self-correct by re-selecting in the TOC before they start typing, rather than discovering a wrong location after they have written the explanation.

### 4. The form appears with the selected location displayed

The selected location is shown at the top of the form for confirmation, but it is not editable from the form itself — to change it, the user returns to the TOC and re-selects. The form has two fields:

- **Explanation of the error** — required, multi-line text.
- **Proposed correction** — optional, multi-line text.

**Rationale — location not editable from the form.** The TOC selection is the single way the location is established. Allowing edits inside the form would create two independent location-entry paths (TOC click and form text field) that could disagree, and would invite free-text locations ("see the footnote near figure 3") that the canonical TOC selection is meant to avoid. The roundtrip back to the TOC is cheap — one click — and the user has not yet written anything, so there is nothing to lose.

**Rationale — explanation required, proposed correction optional.** The explanation answers the only question the report has to answer: what is wrong. Without it the report has no content. The proposed correction is helpful when the user is confident enough to suggest one, but many valid reports come from readers who can identify a problem without knowing how to repair it — a missing definition, a contradictory claim, a broken cross-reference. Making the correction required would suppress those reports.

### 5. Reader clicks Submit

Submit opens the user's default email client with a pre-composed email:

- **To.** `errata@agentic-spec.com`
- **Subject.** `Erratum: [chapter] / [section] / [subsection]` — with the chapter, section, and subsection filled from the TOC selection. Trailing levels that were not selected are omitted from the subject.
- **Body.** Well-structured plain text containing the location (chapter / section / subsection), the explanation, and — if the user provided one — the proposed correction. Labels appear on their own lines so the email is readable in any mail client.

The site MUST NOT transmit the message or any of its contents over the network. The `mailto:` handoff is the entire submission mechanism.

**Rationale — delegated to the user's email client, not POST-ed to a server.** A server endpoint would mean the site has to (a) accept and store reader input, (b) defend that endpoint against spam, abuse, and attempts to plant PII or harmful content in a public-facing system, (c) operate a mail-sending pipeline with deliverability, retries, and bounce handling, and (d) carry a data-retention surface (errata reports as user-submitted content). Routing through the user's own email client produces the same outcome — a structured email arrives at the errata mailbox — while leaving sending, sender identity, and any retained record entirely on the user's side. The site itself remains a static page with no input-handling responsibilities.

### 6. The user reviews the composed email in their client and sends it themselves

The site has no further role. It does not see the message contents and does not retain the submission.

**Rationale.** The user's review step is a free benefit of the `mailto:` design: the user sees exactly what is about to be sent and can edit, add context, or cancel before it leaves their machine. The site's non-retention follows directly from the delegated-submission design and removes any privacy or data-handling responsibility from the site operator.