wstein · Oct 9, 2026 · Oct 9, 2026 · Oct 9, 2026 · Oct 9, 2026 · Oct 9, 2026
diff --git a/docs/content/docs/design/_index.md b/docs/content/docs/design/_index.md
@@ -9,7 +9,7 @@ toc: true
 
 | Status | What | Where |
 | --- | --- | --- |
-| Decided | D1 to D49, D51 and D52 (D50 is reserved, #112) | §3; new decisions are tracked in the issue that needs them (the [M0 Decisions milestone](https://github.com/wstein/workharbor/milestone/1) is closed) |
+| Decided | D1 to D49, D51 to D55 and D57 to D60 (D50 is reserved, #112; D56 is reserved, #309) | §3; new decisions are tracked in the issue that needs them (the [M0 Decisions milestone](https://github.com/wstein/workharbor/milestone/1) is closed) |
 | Implemented | The domain (state machines, Decisions, the aggregate and its guards), the policy table, the SQLite store with redaction at ingest, the service layer and reconciler, hostgit (checkout checks, the repository cache, prepare and push, the editor copy), the runtime and agent contracts with their conformance suites, the Apple Container adapter with the egress proxy sidecar (ports 443 and 80, public addresses only, exec environment through a `0600` env file), the tool store (https only, size cap), the config file (secrets outside every root, an API key only, D40) and `make install` (development only, from independently reviewed clean current local `main`, including unpublished commits), push after approval with follow-up rounds as fast-forwards, the Claude Code adapter (`dontAsk` with an allowlist, or `manual` with host approvals over the stdio control channel), ntfy notifications, `whr version`, the `whr-shim` launcher, and the design-drift test; `whr serve` with the JSON API on a host-only socket, the CLI (D37), the web UI with passkey sign-in and step-up, previews and the usage dashboard, workspaces with named agents and the bundle export, the console with SSH certificates, workflow presets (D47), the setup wizard (D46), the launchd job, the board mirror, devcontainer environments with egress requests, release installs from drafts and the Homebrew tap workflow, and fuzz tests of the untrusted-input parsers | Packages under `internal/` and `cmd/`; what remains for the first dogfood run is the [Dogfood milestone](https://github.com/wstein/workharbor/milestone/5), the rest of release 1 the [R1 Slice](https://github.com/wstein/workharbor/milestone/2) and [R1 Complete](https://github.com/wstein/workharbor/milestone/3) milestones |
 | Spiked | Agent contract (Claude Code, Codex CLI, Antigravity); Apple Container; host cancel with `whr-shim`; approvals over stdio; planted Claude Code config; host reachability; bind mount against volume, and a volume over a bind mount | Issues #1, #2, #10, #7, #68, #69, #40 and #80; the [spike pages](../spikes/_index.md); results in §4.2, §4.4, §5.1 to §5.3, §5.6, §7 |
 | Open spikes | Signing in to the agent inside an environment (D40); what guests reach on the host with `pf` rules | Issues #82, #69 |

diff --git a/docs/content/docs/design/decisions.md b/docs/content/docs/design/decisions.md
diff --git a/docs/content/docs/design/homebrew-bootstrap.md b/docs/content/docs/design/homebrew-bootstrap.md
@@ -7,7 +7,7 @@ toc: true
 
 ## Installing Homebrew from setup (#491)
 
-**Status:** proposed, awaiting the maintainer's decision. **D-row:** to be assigned by the design lane. Nothing is implemented; this page records the options so the human can decide. Claims about Homebrew, the Command Line Tools (CLT) and macOS were not measured on this host and are marked {{< status unverified >}}; sources are Homebrew's [installation page](https://docs.brew.sh/Installation) and [FAQ](https://docs.brew.sh/FAQ).
+**Status:** {{< status decided >}} option C (D59; Werner's decision of 2026-10-09, issue #505), built as `whr setup host --only homebrew` in a4d798c8. The page keeps the options as they were weighed. Claims about Homebrew, the Command Line Tools (CLT) and macOS were not measured on this host and are marked {{< status unverified >}}; sources are Homebrew's [installation page](https://docs.brew.sh/Installation) and [FAQ](https://docs.brew.sh/FAQ).
 
 ### Context
 

diff --git a/docs/content/docs/design/interfaces.md b/docs/content/docs/design/interfaces.md
diff --git a/docs/content/docs/design/pr-flow-landing.md b/docs/content/docs/design/pr-flow-landing.md
@@ -18,7 +18,7 @@ Each item of the issue checklist is marked here as verified (how) or unverified.
 3. **No required approvals.** A solo maintainer cannot approve his own PR. The desk sets commit statuses `review/sonnet` and `review/opus` on the PR head SHA (`POST /repos/{r}/statuses/{sha}`); the evidence goes into a PR comment. This replaces `refs/notes/review` and `TO_LAND.md`.
 4. **A `gate` workflow.** On `pull_request`, read-only, pinned actions, job-level `permissions: {contents: read, statuses: read}` (`statuses` is a documented permission scope, {{< status unverified >}} until a workflow runs). It lists the changed files, derives the class, reads `GET /repos/{r}/commits/{head}/statuses`, and fails unless the required tier is present and its `creator.login` is the human or the desk identity.
 5. **Stacking.** Small independent PRs merged in order, each rebased on the new `main`. A chain of PR bases is optional; the fast lane (#405) maps onto one PR per lane.
-6. **Roles.** The dispatcher opens a draft PR per branch until CLEAR (during the #439 trial the desk opens the PR instead of the dispatcher); the desk sets the statuses and posts the evidence comment; CI-watch reads the checks of the PR; only the desk marks it ready (`gh pr ready`), once all checks are green on the exact head and the required `review/*` status is success; the human merges (or enables auto-merge once the checks are green). Trial (#439, revisit 2026-11-08): after the required CLEAR on the exact head SHA the desk makes the first push of that topic branch (never force) and the PR-owning author may push later commits (see manual), open the draft PR with `Closes #N`, post `review/<tier>` and the evidence comment, have a read-only background helper watch the checks and report once (check name, job URL, first failing test line; monitoring never blocks the desk) and mark the PR ready when they are green and `review/*` is success; carve-out paths still need `review/opus`. Never: merge; push `main` or tags; force-push; change rulesets or repository settings; push without the required CLEAR. Finished work branches are deleted after the merge, `spike/*` never automatically; a PR stays within 10 commits and about 500 lines. Full text, failure report format and cleanup commands: [manual](../manual/sessions-and-agents.md#desk-push-trial-439). Commands and the closing-line policy are in the [manual](../manual/sessions-and-agents.md#pull-request-flow-412).
+6. **Roles.** The dispatcher opens a draft PR per branch until CLEAR (during the #439 trial the desk opens the PR instead of the dispatcher); the desk sets the statuses and posts the evidence comment; CI-watch reads the checks of the PR; only the desk marks it ready (`gh pr ready`), once all checks are green on the exact head and the required `review/*` status is success; the human merges (or enables auto-merge once the checks are green). Trial (#439, revisit 2026-11-08): after the required CLEAR on the exact head SHA the desk makes the first push of that topic branch (never force; later commits may also be pushed by the PR-owning author, see manual), opens the draft PR with `Closes #N`, posts `review/<tier>` and the evidence comment, has a read-only background helper watch the checks and report once (check name, job URL, first failing test line; monitoring never blocks the desk) and marks the PR ready when they are green and `review/*` is success; carve-out paths still need `review/opus`. Never: merge; push `main` or tags; force-push; change rulesets or repository settings; push without the required CLEAR. Finished work branches are deleted after the merge, `spike/*` never automatically; a PR stays within 10 commits and about 500 lines. Full text, failure report format and cleanup commands: [manual](../manual/sessions-and-agents.md#desk-push-trial-439). Commands and the closing-line policy are in the [manual](../manual/sessions-and-agents.md#pull-request-flow-412).
 
 ### Class logic and its single copy
 

diff --git a/docs/content/docs/design/roadmap.md b/docs/content/docs/design/roadmap.md
@@ -135,11 +135,11 @@ A target in the checklist above is a target, not a claim, until its row says *in
 
 ### Releases (D24)
 
-- **When.** The pipeline is built during release 1 and stays dormant; the first release, `v0.1.0`, is cut when the slice demo (issue #28) passes, so the Mac mini runs `whr serve` from a released binary under launchd (issue #38). Until then, a signed prerelease tag `v0.1.0-alpha.N` on a green commit of `main` gives a dogfood build: it is published as a pre-release (never to the tap), and the administrator installs it with `make install-release VERSION=<tag>`, which downloads the release with `gh`, checks `checksums.txt` and the build-provenance attestation (signed by this repository's release workflow) and installs `whr`, `whr-shim` and `whr-proxy` into an admin-owned prefix (default `/opt/whr`). Then one `0.x` release per milestone. `v1.0.0` waits until the JSON API (OpenAPI, D3), the adapter `contract_version` and the database migrations are stable and an upgrade with a backup has been tested.
+- **When.** The pipeline is built during release 1 and stays dormant; the first release, `v0.1.0`, is cut when the slice demo (issue #28) passes, so the Mac mini runs `whr serve` from a released binary under launchd (issue #38). Until then, a signed prerelease tag `v0.1.0-alpha.N` on a green commit of `main` gives a dogfood build: it is published as a pre-release (never to the tap), and the administrator installs it from its release archive: checked against `checksums.txt`, then, when `gh` is installed (an upgrade), checked with `gh attestation verify` against the build-provenance attestation signed by this repository's release workflow (a first install has no `gh` and skips that), unpacked, and `sudo ./install.sh <tag>` installs `whr`, `whr-shim` and `whr-proxy` from that archive, which must match the tag and its line in `checksums.txt`, into a prefix (default `/opt/whr`) that should be admin-owned (warned, not enforced, in the alpha: D58); `make install-release VERSION=<tag>` from a clone checks the checksums and, with `gh`, the attestation. Then one `0.x` release per milestone. `v1.0.0` waits until the JSON API (OpenAPI, D3), the adapter `contract_version` and the database migrations are stable and an upgrade with a backup has been tested.
 - **Version.** The tag is the only source: `git describe` is stamped into the binary with `-ldflags`, built with `-trimpath`; `whr version` prints the version, commit and whether the tree was dirty, and `whr version --json` gives the same as data on stdout with a `schema_version`. Without a tag the version is `v0.0.0-<commits>-g<sha>`, never empty, and a build that was not stamped (plain `go build`) reads it from the Go build info. No version file.
 - **Prepare.** For a release to publish (not a dogfood prerelease), an ordinary commit, which an agent may make: `chore(release): prepare vX.Y.Z` regenerates CHANGELOG.md with git-cliff for that version. CI must pass on it.
 - **Tag.** Only the human, signed and annotated: `git tag -s vX.Y.Z`. A tag ruleset lets only the repository admin create `v*` tags and forbids updating or deleting them.
-- **Build.** A workflow triggered by the tag checks that the tag is annotated and signed by a known key (an SSH key listed in `.github/release-signers`), that the tagged commit is on `main` and that CI passed on it. It then runs GoReleaser (pinned): `darwin/arm64` first, `linux/arm64` and `linux/amd64` for later remote hosts, checksums, an SBOM, a build-provenance attestation and release notes from git-cliff, into a **draft** release. Only that job gets `contents: write` and the attestation permissions.
+- **Build.** A workflow triggered by the tag checks that the tag is annotated and signed by a known key (an SSH key listed in `.github/release-signers`), that the tagged commit is on `main` and that CI passed on it. It then runs GoReleaser (pinned): the host binary `whr` for `darwin/arm64` only (no Intel or Linux host build is released) and the guest binaries `whr-shim` and `whr-proxy` for `linux/arm64`, packed into one archive with `install.sh`, checksums, an SBOM, a build-provenance attestation and release notes from git-cliff, into a **draft** release. Only that job gets `contents: write` and the attestation permissions.
 - **Publish.** The human checks the draft and publishes it. A second workflow, triggered by the publication, updates the Homebrew tap (`brew install wstein/tap/whr`), so the tap never points at a draft; a prerelease does not update it. The workflow checks the assets' checksums and attestations, renders a formula (the macOS `whr` plus the guest binaries as a resource in `libexec/whr`, and the shell completions) and pushes it to `wstein/homebrew-tap` with a deploy key of that repository only, kept in a `homebrew-tap` environment.
 - **macOS distribution.** The tap is the supported install path. Signing and notarizing a downloaded binary need an Apple Developer ID and are deferred until someone other than the developer installs it from a download.
 

diff --git a/docs/content/docs/design/skill-sets.md b/docs/content/docs/design/skill-sets.md
@@ -37,7 +37,7 @@ For Claude, retain `--setting-sources ""`, supervisor-owned `--settings`, `--str
 
 ### Policy composition
 
-Platform enforcement and operator security configuration are authoritative. Reviewed project `AGENTS.md` and local contribution policy govern repository work; selected skill instructions supply workflow defaults under those constraints. A skill set can tighten guidance, but cannot grant a denied action, weaken a required review, select security configuration or override a human approval boundary. Issue text, comments, CI logs and messages from other sessions remain untrusted data. A model following a prompt is not enforcement.
+Platform enforcement and operator security configuration are authoritative. Reviewed project `AGENTS.md` and local contribution policy govern repository work; selected skill instructions supply workflow defaults under those constraints. A skill set can tighten guidance, but cannot grant a denied action, weaken a required review, select security configuration or override a human approval boundary. Issue text, comments, CI logs and messages from other sessions remain untrusted data. A model following a prompt is not enforcement. Outside knowledge bundles, such as OKF (D60), are untrusted text (T1) as well: they reach an agent only through this pinned, reviewed, read-only path, their `verified` or `generated` claims count for nothing, and their `executor` or `attester` resources are never run.
 
 Validate declared project prerequisites before loading. Missing required policy, unresolved packaged references, unsupported client/model bindings or a declared conflict with platform controls fail with an actionable diagnostic. Do not silently omit required instructions, substitute a local `.agents` file or merge package settings. Arbitrary contradictory prose cannot be proven safe by a manifest check: preserve the policy controls regardless of what the package asks, label content by origin and require review of the selected content. crewbook [#2](https://github.com/wstein/crewbook/issues/2) owns its side of this composition contract.