feat: renumber lib reference into 4-pillar anatomy

Renumber the 15 reference docs into pillar groups (recipe -> anatomy):
- 01 Build Recipe (entry), 02 Composition Root
- domains: 10 Layering Rules
- contract: 20 Spec-First Routing, 21 CRUD Template, 22 Auth Integration
- interfaces/infra: 30 Infra Adapters
- UI: 40 UI: Auto-Rendered Admin & Custom Pages (new; @aetoskia packages,
  client template, x- catalog via react-openapi MCP module)
- pipelines: 50 Pipeline Scaffold, 51 Worker & Progress, 52 Human-in-the-Loop
- delivery/meta: 90 Drone Pipelines, 91 Versioning & Changelog,
  92 Genericity Matrix, 93 Library Registry, 94 Repository Inventory

MCP module names are unchanged (NN_ prefix stripped); all cross-references
(wiki, templates, hooks, registry) updated; lib index rewritten pillar-first;
build recipe bootstraps the client template. Bundle + HTML sites regenerated.

standards/src/lib/01_build_recipe.md

@@ -6,6 +6,11 @@ The ordered, deterministic checklist for generating a new application of the
 standard shape. Every step is fixed; only the resource model (step 2), the
 codegen pass (step 3), and the pipeline family (step 8) need app-specific work.
 
+The reference pages behind this recipe are organized as an anatomy: the
+domains layer, the OpenAPI contract that drives routing *and* the admin UI,
+the interfaces/infra seam, the auto-rendered UI client, and an optional
+pipelines layer — see the [Standards Reference](index.md) index.
+
 This page is served by the `standards` MCP as `docs://modules/build_recipe`. The
 `start_app` prompt on that server collects the two axes and hands off here; pull
 exact files with `get_app_component`.
@@ -21,6 +26,14 @@ cp -r <docs>/standards/src/templates/app apps/<your-app>
 cd apps/<your-app>
 ```
 
+Pair it with the React client template when a UI is needed (auto-rendered
+admin from the spec — see [40 – UI](40_ui_admin.md)):
+
+```bash
+cp -r <docs>/standards/src/templates/client apps/<your-app>-client
+cd apps/<your-app>-client && npm install
+```
+
 Install the internal libraries — editable local checkouts (preferred in
 development) or the private index (CI / fresh machines). Credentials are
 environment-only; never commit them.
@@ -194,4 +207,4 @@ Rules of the road:
 
 ## Related
 
-- [02 – Layering Rules](02_layering_rules.md) · [05 – CRUD Template](05_crud_template.md) · [06 – Pipeline Scaffold](06_pipeline_scaffold.md) · [12 – Genericity Matrix](12_genericity_matrix.md)
+- [10 – Layering Rules](10_layering_rules.md) · [21 – CRUD Template](21_crud_template.md) · [22 – Auth Integration](22_auth_integration.md) · [40 – UI](40_ui_admin.md) · [50 – Pipeline Scaffold](50_pipeline_scaffold.md) · [92 – Genericity Matrix](92_genericity_matrix.md)

standards/src/lib/40_ui_admin.md

@@ -0,0 +1,86 @@
+# UI: Auto-Rendered Admin & Custom Pages
+
+## Summary
+
+The UI axis of an Aetos app is a **published React client**, not code written
+per application. Two npm packages carry the whole surface:
+
+| Package | Role |
+|---|---|
+| `@aetoskia/react-openapi` | Renders a complete admin panel (CRUD tables, forms, filters, sorting, pagination, uploads) **from the app's `openapi.yaml`** — zero UI code. |
+| `@aetoskia/react-auth` | Auth contexts and pages (login/register/me) wired to the auth-server, plus the axios client with token handling. |
+
+Both publish to the private registry `https://npm.aetoskia.com`. The server
+spec is the single source of truth: the same `openapi.yaml` that drives
+`openapi-first` routing drives the admin UI, through **x- extension fields**
+(see below).
+
+---
+
+## Scaffold
+
+```bash
+cp -r <docs>/standards/src/templates/client apps/<your-app>-client
+cd apps/<your-app>-client
+npm install          # deps come from npm.aetoskia.com via .npmrc
+npm run dev
+```
+
+The client template is a Vite + MUI app with:
+
+- `src/openapi-config.ts` — points the renderer at the app's spec and the
+  auth-server's spec;
+- `.env.example` — `VITE_API_BASE_URL` (app API) and `VITE_AUTH_BASE_URL`
+  (auth-server);
+- a `Home` page that auto-lists every resource the spec declares, and a
+  `Header`/`Footer`/theme scaffold.
+
+Custom pages are ordinary React routes layered on top; the auto-rendered admin
+is available per resource at `#/resource/<name>`.
+
+---
+
+## x- extensions: how the spec steers the UI
+
+The admin renderer reads a catalog of OpenAPI extension fields (`x-resource`,
+`x-list-columns`, `x-display-format`, `x-label`, `x-order`, `x-hidden`,
+`x-sortable`, `x-filterable`, `x-autocomplete`, `x-fk`, `x-ui-type`,
+`x-upload`, `x-sse`, `x-profile`, and the auth wiring `x-server-url` /
+`x-login-path` / `x-me-path` / …) declared on schemas and properties.
+
+**The catalog is canonical in the react-openapi source, not in this doc.**
+Read it from the MCP bundle:
+
+```
+docs://modules/react-openapi        # module: specExtensions — the full catalog
+```
+
+The app's own spec carries the per-resource values; the catalog explains what
+each field does. The template's `openapi.yaml` shows the convention on the
+example `Item` and `Job` schemas.
+
+---
+
+## Golden rules
+
+1. **The spec owns the UI.** Add a resource or rename a column in
+   `openapi.yaml`; the admin follows. Never fork the renderer per app.
+2. **Custom pages for workflows, auto-render for CRUD.** Anything that is
+   "list / create / edit / delete an entity" is a spec concern; anything that
+   is a bespoke workflow is a React page.
+3. **Auth is consumed, never re-implemented.** `@aetoskia/react-auth` holds
+   tokens and calls the auth-server endpoints declared by the x- wiring; pages
+   read the context.
+4. **Publish, don't vendor.** UI shared across apps belongs in
+   `@aetoskia/react-openapi` or `@aetoskia/react-auth` (SemVer, tag-triggered
+   npm release), not copy-pasted into app trees.
+
+---
+
+## Notes
+
+- The server template ships authless by default (see
+  [22 – Auth Integration](22_auth_integration.md)); the client template pairs
+  with it and degrades to "no login" until a security scheme is declared.
+- `react/vet` is the full-stack reference implementation: spec with x-
+  extensions, server, and the consuming client in one tree.

standards/src/lib/90_drone_pipelines.md

@@ -28,7 +28,7 @@ For internal libraries. The file contains **two pipelines**:
    - `check-version` — **guard**: fail unless `$DRONE_TAG` equals the version in
      `pyproject.toml`; then read `name` / `version` and query
      `$PIP_REPO_URL/simple/<package>/`; if that version already exists, exit
-     `78` and skip the whole build (see [11 – Versioning & Changelog](11_versioning_and_changelog.md)).
+     `78` and skip the whole build (see [91 – Versioning & Changelog](91_versioning_and_changelog.md)).
    - `quality-gate` — install the package with its `[dev]` extras from the
      private index, then `black --check`, `ruff check`, `mypy`, `pydoclint`,
      `pytest`.
@@ -57,7 +57,7 @@ triggered on `tag`:
 - `fetch-tags` — resolve the latest tag into `LATEST_TAG.txt`; fail if there
   are no tags.
 - `check-version` — **guard**: fail unless `$DRONE_TAG` equals the repo-root
-  `VERSION` file (see [11 – Versioning & Changelog](11_versioning_and_changelog.md)).
+  `VERSION` file (see [91 – Versioning & Changelog](91_versioning_and_changelog.md)).
 - `check-remote-image` — if `aetos/<app>:<tag>` already exists locally, exit
   `78` and skip the build.
 - `quality-gate` — install from `requirements.txt` and run
@@ -92,7 +92,7 @@ Placeholders to fill in per repo:
   index and the running container against duplicate publishes.
 - Do not drop the tag↔version guard. A package needs its `pyproject.toml`
   version to equal the tag; a service needs a root `VERSION` file that equals
-  the tag. See [11 – Versioning & Changelog](11_versioning_and_changelog.md).
+  the tag. See [91 – Versioning & Changelog](91_versioning_and_changelog.md).
 - Do not rename the pipelines; tooling and runbooks key off
   `build-and-publish-pypi` and `build-and-deploy-service`.
 
@@ -100,4 +100,4 @@ Placeholders to fill in per repo:
 
 ## Related
 
-- [01 – Build Recipe](01_build_recipe.md) · [09 – Infra Adapters](09_infra_adaptors.md) · [11 – Versioning & Changelog](11_versioning_and_changelog.md) · [13 – Library Registry](13_library_registry.md)
+- [01 – Build Recipe](01_build_recipe.md) · [30 – Infra Adapters](30_infra_adaptors.md) · [91 – Versioning & Changelog](91_versioning_and_changelog.md) · [93 – Library Registry](93_library_registry.md)

standards/src/lib/91_versioning_and_changelog.md

@@ -9,7 +9,7 @@ The **version file is the source of truth**, the **git tag must equal it**, and
 a Drone guard enforces that equality before anything is published. Releases are
 cut manually; a tag is what triggers the pipeline.
 
-This page pairs with [10 – Drone Pipelines](10_drone_pipelines.md): the version
+This page pairs with [90 – Drone Pipelines](90_drone_pipelines.md): the version
 and tag contract is exactly what those two CI shapes consume.
 
 ---
@@ -178,4 +178,4 @@ Drone guard turns that silent no-op into a hard failure.
 
 ## Related
 
-- [10 – Drone Pipelines](10_drone_pipelines.md) · [15 – Repository Inventory](15_repository_inventory.md) · [01 – Build Recipe](01_build_recipe.md) · [13 – Library Registry](13_library_registry.md)
+- [90 – Drone Pipelines](90_drone_pipelines.md) · [94 – Repository Inventory](94_repository_inventory.md) · [01 – Build Recipe](01_build_recipe.md) · [93 – Library Registry](93_library_registry.md)

standards/src/lib/94_repository_inventory.md

@@ -5,8 +5,8 @@
 The canonical list of Aetos repositories covered by the CI and versioning
 standards, with the artifact each one produces, its version source, and its
 Drone shape. Every entry maps to the contract in
-[11 – Versioning & Changelog](11_versioning_and_changelog.md) and the two CI
-files in [10 – Drone Pipelines](10_drone_pipelines.md).
+[91 – Versioning & Changelog](91_versioning_and_changelog.md) and the two CI
+files in [90 – Drone Pipelines](90_drone_pipelines.md).
 
 The same data is published machine-readably as the `registry://repos` MCP
 resource (and the `list_repos` tool), sourced from `standards/src/repos.json`.
@@ -68,4 +68,4 @@ merged, and the tag is created on the merged commit.
 
 ## Related
 
-- [10 – Drone Pipelines](10_drone_pipelines.md) · [11 – Versioning & Changelog](11_versioning_and_changelog.md) · [13 – Library Registry](13_library_registry.md)
+- [90 – Drone Pipelines](90_drone_pipelines.md) · [91 – Versioning & Changelog](91_versioning_and_changelog.md) · [93 – Library Registry](93_library_registry.md)

standards/src/lib/index.md

@@ -3,26 +3,56 @@
 The reference half of the Standards description: the enforceable rules,
 patterns, and the internal library catalog that agents consult while coding.
 
-- **Build Recipe** — the ordered, agentic checklist for a new app.
+The reference is organized as an **anatomy** — one entry checklist and four
+pillars describing what an application is made of, plus delivery/meta pages
+and an optional pipelines layer.
+
+## Anatomy
+
+- **Build Recipe** — the ordered, agentic checklist for a new app; the entry
+  point that walks the whole anatomy.
+
+## Pillar 1 — Domains
+
 - **Layering Rules** — the strict request → domain → repository layering and
   the rules that enforce it.
+
+## Pillar 2 — OpenAPI Spec (the contract)
+
 - **Composition Root** — a single composition point wiring the whole app.
 - **Spec-First Routing** — the OpenAPI contract as the routing source of truth.
 - **CRUD Template** — the standardized generic resource endpoint scaffold.
+- **Auth Integration** — consuming the shared auth-server service (spec-driven,
+  no auth code).
+
+## Pillar 3 — Interfaces & Infra
+
+- **Infra Adapters** — how infrastructure connects without leaking into domain.
+
+## Pillar 4 — UI
+
+- **UI: Auto-Rendered Admin & Custom Pages** — the `@aetoskia/react-openapi`
+  admin rendered from the spec's x- extensions, and `@aetoskia/react-auth`
+  for auth pages; the client template scaffold.
+
+## Pipelines (optional layer)
+
 - **Pipeline Scaffold** — the deterministic pipeline skeleton for multi-stage
   jobs.
 - **Worker & Progress** — queued work, progress reporting, and visibility.
 - **Human-in-the-Loop** — guardrails and approvals inside automations.
-- **Infra Adapters** — how infrastructure connects without leaking into domain.
-- **Drone Pipelines** — the two CI shapes: a PyPI package or a Docker deployment.
-- **Versioning & Changelog** — SemVer, the tag↔version contract, and the release
-  changelog.
+
+## Delivery & Meta
+
+- **Drone Pipelines** — the two CI shapes: a PyPI/npm package or a Docker
+  deployment.
+- **Versioning & Changelog** — SemVer, the tag↔version contract, and the
+  release changelog.
 - **Repository Inventory** — every covered repo, its type, version source, and
   Drone shape.
-- **Genericity Matrix** — what is library-backed, template-provided, or authored.
-- **Auth Integration** — consuming the shared auth-server service (spec-driven,
-  no auth code).
+- **Genericity Matrix** — what is library-backed, template-provided, or
+  authored.
 - **Library Registry** — the catalog of internal libraries behind all of it.
 
 Read the **Wiki** for the philosophy and rationale; these pages are the
-reference that mirrors the `standards` MCP bundle.
+reference that mirrors the `standards` MCP bundle.