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↗, 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.