## Behaviour policies as vaults: Lab 07, a directory of nine, the renderer versioned once

This release merges a branch that ran alongside v1.11.0 and v1.12.0. Everything below
landed on that branch; the notes of the two releases it sits on stand as written.

**Lab 07 — the first behaviour-policy vault, built rather than drawn.**
[What you are actually buying](lab-vault-delivered.html): an Agent Behaviour Policy delivered
as a vault, for the deployment shape this site is maintained from. Eight files from three
inputs — the published, measured grant, the starting mandate, the vocabulary pinned at
abp.sgit.ai v0.3.0 — of which the mandate is the only file a person writes. Everything else
(`AGENT-BEHAVIOUR-POLICY.md`, `GRANT.md`, `DELTA.md`, `LICENCE-TO-OPERATE.md`, `README.md`,
`data/delta.json`, `data/validity.json`, the history) is derived by
`scripts/site/build-abp-vault.mjs`, which recomputes the delta with abp.delta/v1 semantics
and refuses to write if it cannot reproduce the record the model site published. `AGENTS.md`
and `SKILL.md` are the generic files handed to the agent, each saying in its own words that it
is a rule in prose and bounds nothing. `LICENCE-TO-OPERATE.md` adopts the organisation /
instrument / licensee referent; *mandate to operate* is retired. A grant check written from
inside the shape — eleven of fifteen rows seen present in ordinary work, none absent — is in
the vault's history. Also: a review brief in `docs/briefs/` reading the Design Studio
storefront concepts against the workflow that sells a behaviour policy.

**A directory of behaviour-policy vaults, one per application.** A new section under Live
demos, [abp-vaults.html](abp-vaults.html), reads like a connector directory: a tile per
target application with a glyph, a blurb, the four counts and a live chip. Nine vaults are
available — every deployment shape the model site publishes, each fetched, built, checked
row for row against the published delta and pushed as its own vault with a public read key
— and four applications are listed as *asked for, not built* because their grant is not
published yet. Each vault has a page (`abp-vault-<slug>.html`) generated from one catalogue,
`site/vaults/index.json`, by `scripts/site/build-abp-pages.mjs`; the page components and CSS
live once in `scripts/site/abp/`. The pages read the encrypted vault directly in the browser
with sgit.ai's house reader, copied in as its brief asks, and fall back to the copy under
`site/vaults/` with a visible status chip. Four altitudes of the same bytes: the card (four
counts, no score), the tables, the vault's own app in a sandboxed frame served over
postMessage, and the live file list.

**The vault app, for whoever was handed the vault.** It opens on *Start here*: what this is,
badges with the counts, three next steps, an inline map of the four objects and their route
to the agent, and the whole policy on one screen as *here is what we want you to do* beside
*here is what we do not*, each line with what enforces it. *What is this?* is a primer for a
reader who does not know what an ABP is. *Give it to your agent* offers the same files three
ways: copy-and-paste blocks, a zip built by the generator, and a PDF rendered from the app.
*Mandate — correct it* recomputes the delta as rows move and exports the corrected
`mandate.json`. The host HUD is minimal; the *no score* badge became an answer to the
question a new reader has. Builds are idempotent and the zip is checked by CI.

**Vaults in vaults: the application vault is data.** The renderer moved out of every
application vault into one app vault (`fl3i7lu4`, public read key), versioned once. Each
application vault carries a hundred-line loader as its `index.html` — the same bytes in all
nine — which fetches the renderer over a sub-vault link when the host resolves one, directly
from the app vault with its public key otherwise, or from a static copy beside the vault, and
boots it against the vault's own files, naming the route it took in its top bar. A buyer's
private vault works the same way with no code copied into it. The design and the two open asks
to the platform are in `docs/briefs/architecture__vaults-in-vaults-for-behaviour-policies.md`.

**The link itself, written.** The first cut of the vaults-in-vaults shape shipped without the
sub-vault link because its format was not published; opened in the vault host, an application
vault showed no `app/` folder, no `.vault/`, and the loader's error screen (the host blocks a
runtime fetch from the app sandbox, so only the link route works there). The format is in the
host's own unminified source, and the generator now writes both files: `app.link.json`, a dumb
pointer with no key in it, and `.vault/owner/ro-links.json`, the owner record carrying the app
vault's public read key and its named-ref id, so the child opens read-only and silently on any
device that has the parent. Both derivations are deterministic, so rebuilds stay byte-identical.
Verified with the host's library code run outside the browser: the record opens `fl3i7lu4` at
its v3 head. The brief records the format. Also fixed: the vault `dist/` folders — the zip and
the PDF a buyer downloads — were caught by the repository's global `dist/` ignore and never
reached the deployed tree, which is what failed the first CI run of this release.

CI now checks every vault's derivation and the generated pages. Vault `ruj286tr` is at its
fifth commit, the eight new vaults at their third, the app vault at its third.
