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

These editorial tests apply to public artefacts. Private Garden captures may preserve noise,
unfinished interests and material whose future relevance is unclear; they do not need to fit the
site's thesis or demonstrate a future output.

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.

## Public Journal 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.
- 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.

## Private project boundary

- Garden and Vault records remain outside this repository, with no symlinks or build imports.
- Private material enters public content only after explicit approval for the specific material and review of the proposed public piece.
- Garden capture checks live in the separate Garden project's `docs/review-checklist.md`.

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

## Technical

- Next.js app routes, raw routes, and `llms.txt` remain coherent.
- Journal means articles and notes. The Knowledge Garden remains internal.
- 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 Garden files.
- `npm run build` succeeds after substantial code, route or content-structure changes, or when explicitly requested. Small changes use proportionate checks without a build, server restart or browser automation unless requested.

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