Cut non-essential prose from docs and comments, and require the same of every future change

README loses the competitor comparison, the personas and the repeated philosophy; the
five near-identical E2E command blocks become a table plus one command, and the file
map a clause per entry. AGENTS.md keeps every decision but drops the narrative around
them. todo.md's completed items collapse to their task line — git holds the rest.

Comments lose restatement, README duplication and history ("used to", "originally",
dated notes). AGENTS.md gains a Prose discipline section making this a standing pass on
every change rather than a one-off cleanup.

src/compose.test.ts now expects 6 documented E2E run commands, not 10, since the README
states the command once instead of per suite.

examples/plugins/admin/README.md

@@ -1,27 +1,22 @@
 # Admin — the system-administration plugin
 
-The Users / Groups / OAuth2-clients screens for running Plainpages itself. These used to be
-built into the core; they now ship as a **drop-in example plugin** so a fresh clone has no admin GUI
-until you opt in. Copy this folder into `plugins/` (it keeps the id and mount path `admin`, so the
-screens live at `/admin/*`) and restart:
+The Users / Groups / OAuth2-clients screens for running Plainpages itself, shipped as a **drop-in
+example plugin** so a fresh clone has no admin GUI until you opt in. Copy this folder into `plugins/`
+(it keeps the id and mount path `admin`, so the screens live at `/admin/*`) and restart:
 
 ```bash
 cp -r examples/plugins/admin plugins/admin
 docker compose up -d
 ```
 
-The bootstrap grants the seeded `admin@plainpages.local` every permission this plugin declares, so the
-section appears in the menu and the screens work immediately.
+The bootstrap grants the seeded `admin@plainpages.local` every permission this plugin declares, so
+the section appears in the menu and the screens work immediately. An older copy already in
+`plugins/` is yours — the host never updates it — so re-copy after a pull; a stale one stops the boot
+with a message naming it ([README → Upgrading](../../../README.md#upgrading)).
 
-> **Already have `plugins/admin` from an earlier version?** Re-copy it. Your copy is yours — the host
-> never updates it — and this plugin's permissions changed on 2026-08-05 (`admin` → `users:`/`groups:`/
-> `oauth2-clients:` × `read`/`write`). A stale copy stops the boot with a message naming it; see
-> [README → Upgrading](../../../README.md#upgrading).
-
-Every string it renders comes from its own catalogs (`i18n/en-US.ts`, `i18n/sv-SE.ts`) — the nav
-labels included, which are catalog keys in `admin-shared.ts`. Each pure view-model builder takes an
-optional `t`; the handlers pass `ctx.t`, and the default is the plugin's own English so a unit test
-reads in words rather than keys. (README → [Languages](../../../README.md#languages-i18n).)
+Every string it renders comes from its own catalogs (`i18n/en-US.ts`, `i18n/sv-SE.ts`), the nav
+labels included. Each pure view-model builder takes an optional `t` defaulting to the plugin's own
+English, so a unit test reads in words rather than keys.
 
 ## What it demonstrates — a *system* plugin
 
@@ -35,15 +30,14 @@ stack**, so they use the privileged **`ctx.system`** surface the host exposes to
 - **`ctx.system.revoke(sub)`** — the optional instant-revoke hook: a deactivate/delete or a
   user's permission change kills that subject's live tokens at once instead of waiting out the JWT TTL.
 
-`ctx.system` is populated only when the host wired those services (the dev stack wires Kratos + Keto,
-and Hydra when configured). Where a capability is absent the screen degrades to a themed 503 rather
-than crashing — see `admin-shared.ts`. Everything else is an ordinary plugin: folder-discovered,
-gated per route by its screen's `<resource>:<action>` permission, rendering the core building blocks
-in `views/`.
+`ctx.system` is populated only when the host wired those services. Where a capability is absent the
+screen degrades to a themed 503 rather than crashing. Everything else is an ordinary plugin:
+folder-discovered, gated per route by its screen's `<resource>:<action>` permission, rendering the
+core building blocks in `views/`.
 
-Each screen is its own resource — `users`, `groups`, `oauth2-clients` — and each splits into `:read`
-and `:write`, so a helpdesk account can be given `users:read` alone. The nav is filtered by the same
-permissions: holding none of the three hides the Admin section entirely.
+Each screen is its own resource — `users`, `groups`, `oauth2-clients` — split into `:read` and
+`:write`, so a helpdesk account can be given `users:read` alone. Holding none of the six hides the
+Admin section entirely.
 
 There is **no Permissions screen**. Permission names are declared in plugin code, not created in a
 GUI, so the host's catalog (`ctx.declaredPermissions`) is the fixed list — and holding one is a

examples/plugins/admin/admin-grants.test.ts

@@ -46,9 +46,9 @@ test("buildPermissionPicker ticks what is held and carries each declaration's de
   assert.equal(picker.inheritedNote, undefined); // nothing is group-held here
 });
 
-// The failure this prevents: a permission held through a group used to render unticked, so the page
-// said "not held" about a grant that reaches the JWT — and unticking it wrote nothing, which read as
-// a successful revoke. Inherited rows are ticked, disabled, and never posted.
+// An inherited permission rendered unticked would say "not held" about a grant that reaches the JWT,
+// and unticking it writes nothing, reading as a successful revoke. So inherited rows are ticked,
+// disabled, and never posted.
 test("buildPermissionPicker distinguishes a direct grant from one inherited through a group", () => {
   const picker = buildPermissionPicker({ action: "/x", declared, direct: ["users:write"], effective: ["users:read", "users:write"] });
   assert.deepEqual(picker.choices.map((c) => [c.name, c.checked, c.inherited]), [

examples/plugins/admin/admin-shared.ts

@@ -1,14 +1,12 @@
-// Shared plumbing for the admin example plugin: the section nav fragment, the admin-only gate, the
-// CSRF-guarded form reader, the destructive-confirm model builder, and small RouteResult helpers
-// (themed not-found / capability-unavailable). Ported from the former built-in admin screens;
-// everything imports the host only through the #plugin-api barrel.
+// Shared plumbing for the admin example plugin: the section nav fragment, the screen gate, the
+// CSRF-guarded form reader, the destructive-confirm model builder, and small RouteResult helpers.
+// Everything imports the host only through the #plugin-api barrel.
 
 import { can, CSRF_FIELD, englishTranslator, GuardError, type NavNode, readFormBody, type RequestContext, requireSession, type RouteResult, type Translate, type User } from "#plugin-api";
 import enUS from "./i18n/en-US.ts";
 
-// This plugin's English (its catalog, then the host's — the screens reuse core words like Cancel and
-// Search), for a view model built outside a request: its unit tests. At runtime the handlers pass
-// ctx.t, which reads this catalog in the visitor's locale first, then the host's.
+// This plugin's English — its catalog, then the host's — for a view model built outside a request,
+// i.e. its unit tests. At runtime the handlers pass ctx.t instead.
 export const ADMIN_EN: Translate = englishTranslator(enUS);
 
 export const ADMIN_USERS_BASE = "/admin/users";
@@ -28,11 +26,9 @@ export function permissionName(resource: AdminResource, action: AdminAction): st
   return `${resource}:${action}`;
 }
 
-// This plugin's mapping from method to action: every screen reads on GET/HEAD and mutates on POST.
-// The manifest's route table and the in-handler guard both go through it rather than each spelling
-// the permission out, so they cannot drift into gating on different names. Deliberately local — as
-// a general mechanism it would make authorization a function of the transport verb, and a route
-// table should answer "what does this need?" on its own (AGENTS.md).
+// Every screen reads on GET/HEAD and mutates on POST. The route table and the in-handler guard both
+// go through this rather than each spelling the permission out, so they cannot drift. Deliberately
+// local: generalised, it would make authorization a function of the transport verb (AGENTS.md).
 export function actionForMethod(method: string): AdminAction {
   const verb = method.toUpperCase();
   return verb === "GET" || verb === "HEAD" ? "read" : "write";
@@ -54,13 +50,10 @@ export const ADMIN_NAV: NavNode = {
 };
 
 // The screen gate: a signed-in user holding this request's `<resource>:<action>`. Each route already
-// declares the same permission, so the host enforces it before the handler runs; this is
-// defence-in-depth and what a direct unit test relies on. Returns the (non-null) user for the
-// handler to thread on. GuardError → /login or 403.
-// `action` defaults to the method's, and is passed explicitly by a *write-intent GET* — a create form
-// or a delete-confirm page, whose only purpose is to start a write. Those refuse a reader honestly
-// instead of rendering a form whose submit would 403; the route table declares the same override, so
-// the two still cannot disagree.
+// declares the same permission, so this is defence-in-depth and what a direct unit test relies on.
+// `action` defaults to the method's, and is passed explicitly by a *write-intent GET* — a create
+// form or a delete-confirm page — which refuses a reader rather than rendering a form whose submit
+// would 403. The route table declares the same override, so the two cannot disagree.
 export function requirePermission(ctx: RequestContext, resource: AdminResource, action?: AdminAction): User {
   const user = requireSession(ctx); // anonymous → GuardError → /login (return_to kept)
   const permission = permissionName(resource, action ?? actionForMethod(ctx.req.method ?? "GET"));

examples/plugins/admin/admin-users.ts

@@ -1,8 +1,7 @@
 // Users admin screen: list Kratos identities (filter/sort/paginate) +
-// create/edit/deactivate/delete/trigger-recovery. Writes go only to Kratos via the admin client
-// (README "stateless"). Pure builders turn identities + the request URL into building-block view
-// models; below them are thin per-route handlers (keyed on ctx.params) over a shared `withUser` gate
-// — admin-only, CSRF-guarded, each returning a RouteResult (a view, or a redirect after a write — PRG).
+// create/edit/deactivate/delete/trigger-recovery. Pure builders turn identities + the request URL
+// into building-block view models; below them are thin per-route handlers keyed on ctx.params, over
+// a shared `withUser` gate.
 
 import { can, type Identity, type KetoClient, type KratosAdmin, KratosError, paginate, parseListQuery, type RecoveryCode, type RequestContext, type RouteHandler, type RouteResult, type Translate, type User } from "#plugin-api";
 import { applyGrants, buildPermissionPicker, effectivePermissions, grantDiff, heldPermissions, type PermissionPicker, PERMISSIONS_FIELD, userSubject } from "./admin-grants.ts";

examples/plugins/admin/plugin.ts

@@ -1,10 +1,8 @@
-// Admin example plugin: the Users / Groups / OAuth2-clients screens for running the system.
-// These used to ship inside the core; they were extracted here so a fresh clone has no built-in admin
-// GUI. Copy this folder to plugins/admin (then restart) to enable it — see README → Quick start.
+// Admin example plugin: the Users / Groups / OAuth2-clients screens for running the system. Copy
+// this folder to plugins/admin (then restart) to enable it — see README → Quick start.
 //
-// It is a *system* plugin: its handlers reach the host's Ory admin clients (Kratos/Keto/Hydra) and the
-// instant-revoke hook via ctx.system, which the host populates when those services are wired (the dev
-// stack wires all of them). Where a capability is absent the screen degrades to a themed 503.
+// It is a *system* plugin: its handlers reach the host's Ory admin clients and the instant-revoke
+// hook via ctx.system. Where a capability is absent the screen degrades to a themed 503.
 
 import { definePlugin, type HttpMethod, type Route, type RouteHandler } from "#plugin-api";
 import { clientsCreate, clientsDeleteConfirm, clientsDelete, clientsDetail, clientsList, clientsNewForm } from "./admin-clients.ts";