## The agents' front door, and an admin page that shows how the site is run

**Most of the work on this site is done by agents, and each one was reading the whole
repository to learn it.** The session that wrote this release read the README, twelve briefs,
six release notes, the twins of five pages, a vault and its vocabulary, ten script headers, the
tests and the pipeline before it touched anything, and the sessions before it did the same.
There is now a folder written for the next one. `CLAUDE.md` at the root carries the ten rules
that are not optional and the mechanics in one screen; `.claude/onboarding/` is the reading
order by task, a map of every document, page family, script, test and register, the Agent
Behaviour Policy condensed to one file, where the site is and what is next, and the recipes
for a page, a vault, a release, a Lab edition and a brief. `.claude/briefs/` holds eight tasks
cut from the graph brief and the research queue, each naming the files it touches;
`.claude/commands/` holds the prompts for the common jobs; `.claude/work/` holds one file per
branch in flight. The brief behind it is in `docs/briefs/`.

**Rules of engagement for agents working in parallel.** Two and three sessions have been
working at once on branches that merge into `dev` since v1.11.0, and the git log records
what that cost: a branch that restamped every page before it could merge because both sides
had cut a release, and today two branches on the same base commit with nothing telling either
what the other was doing. The rules say what conflicts and what to do about it: claim a scope
in a file per branch; cut the release only as the last commit before merge, after merging
`dev` in; regenerate a generated file rather than hand-merge it; make an every-page edit a
small commit merged the same day; never rewrite an append-only record; declare a vault push
you could not make; one owner per surface at a time. `dev` is the live site, so a merge is a
deploy, and the rules say that too.

**[Admin](admin.html), and the docs linked from every page.** The direction, the architecture
and the reviews lived in the repository and nothing on the site pointed at them. A new page in
the *More* menu, linked as *Admin* beside *Versions* in every footer, is the index behind the
site: the records it keeps and where each is kept, every document under `docs/` with a link
into the repository, the agents' front door, the tooling with what runs in CI, and how a change
ships. Two tests keep it honest: every document under `docs/` must be linked from the page,
and every footer that links *Versions* must link *Admin*. The scaffolder carries the link into
new pages. The repository's README and the how-the-website-works document, written at v1.0.0,
now point at the front door, and the latter carries an addendum naming what was added since.

**This release sits on v1.17.0**, which a sibling branch cut and merged while this one was
in flight: the library wider and readable, and the page for what is next. Both branches had
claimed 1.17.0, which is the case the rules of engagement above were written for, and this one
followed them: `dev` merged in first, the pages taken from it, the footer link re-applied, the
generated files regenerated rather than merged, and the release re-cut last.

**Not done.** The docs are linked into the repository, not served from the site; serving them
would mean generating them into `site/` with twins and a sitemap entry, and nothing here
depends on it. Nothing enforces that the onboarding folder stays current beyond the two tests
above and the rule that a change to anything it describes changes it in the same commit. And
the how-the-website-works document still describes the v1.0.0 site in its body; bringing it up
to date is one of the eight task briefs, not this release.