# Review Checklist

Use this before handing work back. Keep the review proportional to the change.

## First question

Does this change make the canonical pages, raw routes, or `llms.txt` harder to reason about? If yes, stop and reconsider.

## Second question: will this artefact persist?

Before reviewing the mechanics, ask whether the thing being added belongs at all:

- Does this clarify something real, or merely increase surface area?
- Is it worth re-reading or returning to?
- Does it couple to a real question, system, or reader, or only to the moment of publishing?
- Can someone else lift the vocabulary, the structure, or the principle and use it elsewhere?
- Does it lower the cost of finding what is already here, or raise it?
- Does it connect to the site's thesis (instruments, orientation, judgement), either directly or obliquely?

If most of these fail, the artefact is more likely to decay than to compound. Reconsider before shipping.

The thesis question allows oblique connection. The archive has pieces that engage the centre only at the edges, and that is fine. The check is against pieces with no relationship to the centre at all.

## Content

- Title, date, tags, and article excerpts are present when adding Markdown entries.
- Slugs follow the existing filename pattern.
- Prose uses British English and avoids generic startup language.
- Claims involving history, people, dates, or technical sequence are accurate.
- Private details have been converted into public-safe principles where needed.
- Voice is consistent with the rest of the piece. Check for drift across earlier revisions, not only the current pass.
- Do not rewrite prose the author wrote. If a change requires editing existing sentences, flag it instead.

## Design

- The change feels calm, restrained, and consistent with the current site.
- Typography, spacing, colour, and link treatment reuse existing patterns.
- Active, hover, focus, and dark-mode states still work.
- Text does not wrap awkwardly on narrow screens.
- No decorative UI has been added to solve a content problem.
- Work pages describe systems and artefacts rather than drifting into a screenshot wall.

## Technical

- Next.js app routes, raw routes, and `llms.txt` remain coherent.
- Markdown content still renders through the existing content pipeline.
- Accessibility semantics are preserved: headings, nav labels, alt text, focus states.
- No unnecessary dependency, abstraction, or new file type was introduced.
- Public docs linked from the colophon exist and return useful plain text.
- `npm run build` succeeds after code, route, or content-structure changes.

## Final pass

The review report should distinguish three kinds of outcomes:

- **Verified.** Things checked that were already correct.
- **Changed.** Mechanical updates the reviewer made directly (slugs, filenames, metadata fields, broken links). These should be small and obvious.
- **Flagged.** Anything requiring author judgement: prose edits, structural changes, claims needing verification, voice drift, possible redundancy, uncertain content.

LLM reviewers do not rewrite prose, restructure pieces, or make editorial calls on the author's behalf. When in doubt, flag rather than fix.

The report should also state what changed and where, mention any build or verification result, and call out remaining uncertainty rather than hiding it.