# 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 concern with the systems we think and act through (including
  instruments, orientation, and 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 non-empty article standfirsts are present when adding Markdown entries.
- Status is omitted, `published`, or `draft`; no other value is allowed.
- Published clippings carry source provenance. Image-import stubs remain drafts until reviewed.
- 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.
- Journal means articles and notes. Clippings and quotes remain distinct public collections.
- 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.
- Content asset routes expose supported images only, never Markdown, graph data, or `content/log`.
- `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.

Before handoff, check `content-audit.md` for unresolved items affected by the change. Add anything
that needs author judgement rather than leaving it implicit in a review report.

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