diff --git a/data/outstanding-issues-snapshot.json b/data/outstanding-issues-snapshot.json
index 7e579749ee..7b3712365c 100644
--- a/data/outstanding-issues-snapshot.json
+++ b/data/outstanding-issues-snapshot.json
@@ -2,7 +2,7 @@
   "version": "outstanding-issues-snapshot-v1",
   "ledger_revision": {
     "sha": "707b965965a9b843c13deb6b5c9ddd158fe2631d",
-    "committed_at": "2026-08-25T17:45:01+00:00"
+    "committed_at": "2026-08-25T17:45:01Z"
   },
   "counts": {
     "open": 91,
@@ -10,7 +10,7 @@
     "p2": 57,
     "p3": 33,
     "queued": 9,
-    "pending": 7,
+    "pending": 10,
     "resolved": 412
   },
   "queue": [
@@ -966,17 +966,35 @@
       "summary": "Component metrics stay in :root, not @theme — record the rule where reviewers read it, because bots keep re-raising it",
       "created_at": "2026-08-26"
     },
+    {
+      "request_id": "970bbb8b-4dbe-4e27-97a4-80142db94d7d",
+      "action": "add",
+      "summary": "Ward Flow: six agreed enhancements not yet assigned to a phase",
+      "created_at": "2026-08-26"
+    },
     {
       "request_id": "b85ad821-4c9b-4925-b86b-2d5767052b20",
       "action": "add",
       "summary": "Scope the component-metric rule: keep one-consumer values local; use :root only for shared off-scale CSS custom properties, not @theme",
       "created_at": "2026-08-26"
     },
+    {
+      "request_id": "cfa44b9c-3d68-4030-b1e3-3d8f182ca3d4",
+      "action": "add",
+      "summary": "Ward Flow's bed-release state model is unvalidated by any ward clinician",
+      "created_at": "2026-08-26"
+    },
     {
       "request_id": "d2a6122a-4fcd-4429-92a7-6004fa19eb24",
       "action": "add",
       "summary": "Docstring coverage on the answer-source changes sits at 62.5% against CodeRabbit's 80% advisory threshold",
       "created_at": "2026-08-25"
+    },
+    {
+      "request_id": "ecabc51d-034a-4a68-91cd-280214aac6bf",
+      "action": "add",
+      "summary": "Ward Flow Phase 5: bed availability becomes real - discharge lifecycle, egress board, predicted capacity, freshness everywhere",
+      "created_at": "2026-08-26"
     }
   ]
 }
diff --git a/data/repo-awareness-snapshot.json b/data/repo-awareness-snapshot.json
index fa2481f60e..ade3508593 100644
--- a/data/repo-awareness-snapshot.json
+++ b/data/repo-awareness-snapshot.json
@@ -1,8 +1,8 @@
 {
   "version": "repo-awareness-snapshot-v1",
   "captured_revision": {
-    "sha": "bf415957c82a3e03ef9c740b24e88832fe84a984",
-    "committed_at": "2026-08-26T11:16:25+08:00"
+    "sha": "6cd6ba816d2eef8a4642529701ed7d7656c09510",
+    "committed_at": "2026-08-26T10:14:41+08:00"
   },
   "routes": {
     "modes": [
@@ -2952,6 +2952,11 @@
         "section": "superpowers",
         "catalogued": false
       },
+      {
+        "path": "docs/superpowers/plans/2026-08-26-ward-flow-phase-5-bed-availability.md",
+        "section": "superpowers",
+        "catalogued": false
+      },
       {
         "path": "docs/superpowers/plans/2026-08-26-ward-flow-sidebar-house-pattern.md",
         "section": "superpowers",
@@ -3237,6 +3242,11 @@
         "section": "superpowers",
         "catalogued": false
       },
+      {
+        "path": "docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md",
+        "section": "superpowers",
+        "catalogued": false
+      },
       {
         "path": "docs/testing.md",
         "section": "root",
@@ -3532,11 +3542,26 @@
         "section": "ward-flow-phase-3-workspace",
         "catalogued": false
       },
+      {
+        "path": "docs/ward-flow-phase-5-handover.md",
+        "section": "root",
+        "catalogued": false
+      },
+      {
+        "path": "docs/ward-flow-phase-5-kickoff-prompt.md",
+        "section": "root",
+        "catalogued": false
+      },
       {
         "path": "docs/ward-flow-phase-handoff.md",
         "section": "root",
         "catalogued": false
       },
+      {
+        "path": "docs/ward-flow-roadmap.md",
+        "section": "root",
+        "catalogued": false
+      },
       {
         "path": "docs/ward-management-context.md",
         "section": "root",
@@ -3625,9 +3650,9 @@
       }
     ],
     "counts": {
-      "documents": 436,
+      "documents": 441,
       "catalogued": 102,
-      "uncatalogued": 334,
+      "uncatalogued": 339,
       "sections": 18
     }
   },
diff --git a/docs/outstanding-issues-inbox/970bbb8b-4dbe-4e27-97a4-80142db94d7d.json b/docs/outstanding-issues-inbox/970bbb8b-4dbe-4e27-97a4-80142db94d7d.json
new file mode 100644
index 0000000000..57974d507d
--- /dev/null
+++ b/docs/outstanding-issues-inbox/970bbb8b-4dbe-4e27-97a4-80142db94d7d.json
@@ -0,0 +1,14 @@
+{
+  "version": 2,
+  "id": "970bbb8b-4dbe-4e27-97a4-80142db94d7d",
+  "createdOn": "2026-08-26",
+  "action": "add",
+  "payload": {
+    "pri": "P3",
+    "type": "rec",
+    "summary": "Ward Flow: six agreed enhancements not yet assigned to a phase",
+    "detail": "Ward prediction track record; 'why not here' across the whole state for one patient; a sixty-second self-driving guided tour; out-of-area ledger; 'waiting since' promoted in the priority queue; named moments on the demo clock. All accepted by the product owner 2026-08-26 and described in docs/ward-flow-roadmap.md.",
+    "source": "Product-owner direction, 2026-08-26",
+    "issueUlid": "01M0XVHQ3D875H6TZWM5JT85YW"
+  }
+}
diff --git a/docs/outstanding-issues-inbox/cfa44b9c-3d68-4030-b1e3-3d8f182ca3d4.json b/docs/outstanding-issues-inbox/cfa44b9c-3d68-4030-b1e3-3d8f182ca3d4.json
new file mode 100644
index 0000000000..cf667489fe
--- /dev/null
+++ b/docs/outstanding-issues-inbox/cfa44b9c-3d68-4030-b1e3-3d8f182ca3d4.json
@@ -0,0 +1,14 @@
+{
+  "version": 2,
+  "id": "cfa44b9c-3d68-4030-b1e3-3d8f182ca3d4",
+  "createdOn": "2026-08-26",
+  "action": "add",
+  "payload": {
+    "pri": "P2",
+    "type": "issue",
+    "summary": "Ward Flow's bed-release state model is unvalidated by any ward clinician",
+    "detail": "predicted -> confirmed -> blocked -> released is a software model of how a bed comes free. A bed may be confirmed and blocked simultaneously in reality, and 'predicted' may compress several states a charge nurse would separate. Cheap to change while synthetic; recorded in the Phase 5 spec as D14 and as the assumption most likely to be wrong. Check before Phase 7 builds on it.",
+    "source": "Ward Flow Phase 5 design, 2026-08-26",
+    "issueUlid": "01M0XVHNB49GPWT3G522RG4YDC"
+  }
+}
diff --git a/docs/outstanding-issues-inbox/ecabc51d-034a-4a68-91cd-280214aac6bf.json b/docs/outstanding-issues-inbox/ecabc51d-034a-4a68-91cd-280214aac6bf.json
new file mode 100644
index 0000000000..b4b0ddf494
--- /dev/null
+++ b/docs/outstanding-issues-inbox/ecabc51d-034a-4a68-91cd-280214aac6bf.json
@@ -0,0 +1,14 @@
+{
+  "version": 2,
+  "id": "ecabc51d-034a-4a68-91cd-280214aac6bf",
+  "createdOn": "2026-08-26",
+  "action": "add",
+  "payload": {
+    "pri": "P2",
+    "type": "task",
+    "summary": "Ward Flow Phase 5: bed availability becomes real - discharge lifecycle, egress board, predicted capacity, freshness everywhere",
+    "detail": "Binding spec: docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md. Extends Phase 4's existing BedRelease concept rather than starting over. Settled direction and decisions: docs/ward-flow-roadmap.md.",
+    "source": "Product-owner direction, 2026-08-26",
+    "issueUlid": "01M0XVHM5H48HF8WJ52BHSR72A"
+  }
+}
diff --git a/docs/superpowers/plans/2026-08-26-ward-flow-phase-5-bed-availability.md b/docs/superpowers/plans/2026-08-26-ward-flow-phase-5-bed-availability.md
new file mode 100644
index 0000000000..3696d3b35c
--- /dev/null
+++ b/docs/superpowers/plans/2026-08-26-ward-flow-phase-5-bed-availability.md
@@ -0,0 +1,865 @@
+# Ward Flow Phase 5 — Bed availability becomes real
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development
+> (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use
+> checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** wards record when their beds are actually coming free, and the coordinator's capacity
+figure becomes a number that can be planned against for the rest of today.
+
+**Architecture:** extend the `BedRelease` concept Phase 4 already built — it has a unit, an expected
+time, a confidence, a blocker chosen from a fixed list, and a ward-only flag event — with a state
+machine, a sibling `LeaveBed` type, band derivations over today, and a discharge board that renders
+them. Every number stays a pure derivation from `WardFlowState`; no screen computes its own version.
+
+**Tech Stack:** TypeScript 6 strict, React 19, Next.js 16 App Router, CSS modules with `@theme`
+tokens, Vitest (`tests/**/*.test.ts`, `tests/**/*.dom.test.tsx`), Playwright (`tests/ui-ward-*.spec.ts`,
+project `chromium-mockups`).
+
+**Spec:** `docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md`
+**Direction and settled decisions:** `docs/ward-flow-roadmap.md`
+
+## Global Constraints
+
+Every task's requirements implicitly include all of these.
+
+- **Never invent a legal figure.** No figure or requirement from the Mental Health Act may be cited,
+  paraphrased or inferred anywhere in code, copy, comment, test or fixture.
+- **Synthetic data only.** No name, date of birth, medical record number, address, diagnosis,
+  narrative history or treatment. **Sex is the only permitted patient attribute**, and per spec D11
+  neither `BedRelease` nor `LeaveBed` may carry even that. Free text counts as data.
+- **Neither `BedRelease` nor `LeaveBed` may gain a field describing the departing or absent patient.**
+  `tests/ward-flow-reducer.test.ts`'s bed-release privacy suite asserts this against the type's own
+  field set. Do not weaken it; extend it.
+- **`confirmedBy` is a role, never a person** — a unit or service label such as
+  `"NUM RPH Adult Secure"`. Never a personal name.
+- **Blockers are chosen, never typed.** Every blocker value comes from `BED_RELEASE_BLOCKERS`.
+- **Local and offline checks only.** Never run `verify:release`, `eval:*`, `check:supabase-project`,
+  `test:live`, or anything touching OpenAI, Supabase, hosted CI or a live database.
+- **Read counts, never exit codes.** `node scripts/run-playwright.mjs` exits `0` on test failure and
+  on lock refusal alike. Quote the `N passed` line. On `DATABASE_HEAVY_RUN_ADMISSION_BUSY` or an
+  `EPERM … owner.json` stack trace the command did not run — retry, do not treat as a pass.
+- **Every `<button>` must do something** — a handler, a submit inside a form, or navigation.
+  `eslint-rules/require-button-wiring.mjs` fails the build otherwise. Never blanket-disable it.
+- **Design tokens, not hex.** Production tap targets are `min-h-12` / `3rem`; never "fix" them down.
+- **Ward Flow is a sandbox.** No new link may point anywhere in the clinical application. The
+  developer hub (`/mockups/development`) is the only way out.
+- **"Tonight" ends at 22:00**, expressed once as a named constant, never as a repeated literal.
+
+## File structure
+
+| File                                                              | Responsibility                                                                                                                                |
+| ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
+| `src/components/ward-management/ward-model.ts`                    | `BedRelease` gains `state`; `confidence` narrows; `blocker` becomes state-dependent. New `LeaveBed`. New `BedReleaseState`, `LeaveBed` types. |
+| `src/components/ward-management/ward-change-reasons.ts`           | `BED_RELEASE_BLOCKERS` gains three operational entries.                                                                                       |
+| `src/components/ward-management/ward-movements.ts`                | `bedReleases` fixture migrated to states and seeded across every state (D13); new `leaveBeds` fixture.                                        |
+| `src/components/ward-management/ward-bed-availability.ts`         | **New.** Pure derivations: band bucketing, the five-figure breakdown, the excluded count. One responsibility, no React.                       |
+| `src/components/ward-management/ward-flow-events.ts`              | Four new events plus their `EVENT_ROLE` entries.                                                                                              |
+| `src/components/ward-management/ward-flow-reducer.ts`             | The transitions, their role and state guards, and their `Rejection`s. `WardFlowState` gains `leaveBeds` and `refreshRequests`.                |
+| `src/components/ward-management/ward-freshness.tsx`               | **New.** One shared freshness stamp used by every board.                                                                                      |
+| `src/components/ward-management/ward-freshness.module.css`        | **New.** Its styles.                                                                                                                          |
+| `src/components/ward-management/discharges/discharge-board.tsx`   | **New.** The discharge and egress board.                                                                                                      |
+| `src/components/ward-management/discharges/discharges.module.css` | **New.** Its styles, including the phone card layout.                                                                                         |
+| `src/app/mockups/ward-flow/discharges/page.tsx`                   | **New.** Its route.                                                                                                                           |
+| `src/components/ward-management/ward-nav.ts`                      | The board's nav entry.                                                                                                                        |
+| `src/components/ward-management/ward/ward-screen.tsx`             | The lifecycle controls, leave beds, and the refresh-requested mark.                                                                           |
+| `src/components/ward-management/ward-management-modes.tsx`        | The capacity board's five figures and the coordinator's refresh-request control.                                                              |
+
+---
+
+## Task 1: The model, the blockers, and the fixtures
+
+**Files:**
+
+- Modify: `src/components/ward-management/ward-model.ts`
+- Modify: `src/components/ward-management/ward-change-reasons.ts`
+- Modify: `src/components/ward-management/ward-movements.ts`
+- Test: `tests/ward-bed-availability-model.test.ts` (create)
+
+**Interfaces:**
+
+- Consumes: nothing — this is the first task.
+- Produces: `BedReleaseState`, the narrowed `BedReleaseConfidence`, the widened
+  `BED_RELEASE_BLOCKERS`, `LeaveBed`, and the `bedReleases` / `leaveBeds` fixtures. Every later task
+  depends on these exact names.
+
+**Why this is serial and first.** Every other task reads these types. Running it alongside anything
+else produces conflicts in the same three files for no gain.
+
+- [ ] **Step 1: Write the failing test**
+
+Create `tests/ward-bed-availability-model.test.ts`:
+
+```ts
+import { describe, expect, it } from "vitest";
+
+import { BED_RELEASE_BLOCKERS } from "@/components/ward-management/ward-change-reasons";
+import {
+  BED_RELEASE_CONFIDENCE_LEVELS,
+  BED_RELEASE_STATES,
+  type BedRelease,
+  type LeaveBed,
+} from "@/components/ward-management/ward-model";
+import { bedReleases, leaveBeds } from "@/components/ward-management/ward-movements";
+
+describe("bed release model", () => {
+  it("has four lifecycle states in the order a bed moves through them", () => {
+    expect(BED_RELEASE_STATES).toEqual(["predicted", "confirmed", "blocked", "released"]);
+  });
+
+  it("no longer treats 'confirmed' as a confidence, because it is a state", () => {
+    expect(BED_RELEASE_CONFIDENCE_LEVELS).toEqual(["likely", "possible"]);
+  });
+
+  it("offers seven blockers, all of them about the bed and none about a person", () => {
+    expect(BED_RELEASE_BLOCKERS).toEqual([
+      "Awaiting clean",
+      "Awaiting pharmacy",
+      "Awaiting placement confirmation",
+      "Awaiting service coordination",
+      "Awaiting accommodation",
+      "Awaiting transport",
+      "Awaiting receiving-service acceptance",
+    ]);
+  });
+
+  /**
+   * The privacy rule is structural, not a matter of fixture hygiene: a future field named
+   * `patientId` would pass a content check and fail this one.
+   */
+  it("gives neither a bed release nor a leave bed any field describing a person", () => {
+    const releaseFields = Object.keys(bedReleases[0]).sort();
+    expect(releaseFields).toEqual(
+      ["blocker", "confidence", "confirmedAt", "confirmedBy", "expectedAt", "id", "state", "unitId"].sort(),
+    );
+    const leaveFields = Object.keys(leaveBeds[0]).sort();
+    expect(leaveFields).toEqual(["confirmedAt", "confirmedBy", "expectedReturn", "id", "unitId", "usable"].sort());
+  });
+
+  /** D13: the board must open on its worst case, not its best. */
+  it("seeds releases in every state, at least two of them blocked", () => {
+    const byState = (state: BedRelease["state"]) => bedReleases.filter((r) => r.state === state);
+    expect(byState("predicted").length).toBeGreaterThanOrEqual(1);
+    expect(byState("confirmed").length).toBeGreaterThanOrEqual(1);
+    expect(byState("blocked").length).toBeGreaterThanOrEqual(2);
+    expect(byState("released").length).toBeGreaterThanOrEqual(1);
+  });
+
+  it("seeds at least one leave bed the ward says cannot be filled", () => {
+    expect(leaveBeds.some((bed: LeaveBed) => bed.usable === false)).toBe(true);
+  });
+
+  /** D3: a blocker belongs to the blocked state and to no other. */
+  it("carries a blocker exactly when blocked, and a confidence exactly when predicted", () => {
+    for (const release of bedReleases) {
+      expect(release.blocker === null).toBe(release.state !== "blocked");
+      expect(release.confidence === null).toBe(release.state !== "predicted");
+      if (release.blocker !== null) {
+        expect(BED_RELEASE_BLOCKERS).toContain(release.blocker);
+      }
+    }
+  });
+});
+```
+
+- [ ] **Step 2: Run the test and watch it fail**
+
+```bash
+npx vitest run tests/ward-bed-availability-model.test.ts --project node --reporter dot
+```
+
+Expected: fails at import — `BED_RELEASE_STATES` and `leaveBeds` do not exist.
+
+- [ ] **Step 3: Add the states and the leave bed to `ward-model.ts`**
+
+Replace the `BED_RELEASE_CONFIDENCE_LEVELS` block and the `BedRelease` type with:
+
+```ts
+/**
+ * A bed release's lifecycle, in the order a bed moves through it. Hand-listed (never derived) for
+ * the same reason `DECLINE_REASONS` is: a UI picker needs a runtime list, not just a type.
+ */
+export const BED_RELEASE_STATES = ["predicted", "confirmed", "blocked", "released"] as const;
+export type BedReleaseState = (typeof BED_RELEASE_STATES)[number];
+
+/**
+ * Narrowed from `confirmed | likely | possible` (Phase 5, spec D1). "Confirmed" was doing two jobs
+ * at once — a position in the lifecycle and a degree of belief — and the lifecycle now owns it.
+ * A confirmed release has no confidence, because it is not a belief any more.
+ */
+export const BED_RELEASE_CONFIDENCE_LEVELS = ["likely", "possible"] as const;
+export type BedReleaseConfidence = (typeof BED_RELEASE_CONFIDENCE_LEVELS)[number];
+
+/**
+ * A bed release carries **nothing whatsoever about the departing patient** — no identifier, no
+ * timing that could identify them, no reason relating to them, and (spec D11) not even sex, the
+ * one otherwise-permitted patient attribute. Every field below is about the BED or the confirming
+ * WARD. `tests/ward-flow-reducer.test.ts` and `tests/ward-bed-availability-model.test.ts` both
+ * assert this structurally against the type's own field set, not against fixture content.
+ */
+export type BedRelease = {
+  id: string;
+  unitId: string;
+  state: BedReleaseState;
+  expectedAt: Instant;
+  /** Non-null only while `state` is `"predicted"`. */
+  confidence: BedReleaseConfidence | null;
+  /** Non-null only while `state` is `"blocked"`. Always a `BedReleaseBlocker`. */
+  blocker: string | null;
+  confirmedAt: Instant;
+  /** A role — a unit or service label. Never a personal name. */
+  confirmedBy: string;
+};
+
+/**
+ * A bed occupied by someone on approved leave. It may or may not be fillable while they are away,
+ * and a coordinator needs to see which — so it is its own count and is **never** merged into
+ * `available` (spec D4). Carries nothing about the person on leave: no identifier, no reason, no
+ * destination.
+ */
+export type LeaveBed = {
+  id: string;
+  unitId: string;
+  /** The ward's statement that this bed can be filled while its occupant is away. */
+  usable: boolean;
+  expectedReturn: Instant;
+  confirmedAt: Instant;
+  /** A role. Never a personal name. */
+  confirmedBy: string;
+};
+```
+
+- [ ] **Step 4: Widen the blocker list**
+
+In `ward-change-reasons.ts`, extend `BED_RELEASE_BLOCKERS` to exactly:
+
+```ts
+export const BED_RELEASE_BLOCKERS = [
+  "Awaiting clean",
+  "Awaiting pharmacy",
+  "Awaiting placement confirmation",
+  "Awaiting service coordination",
+  // Phase 5 (spec D3). Operational facts about the bed, chosen for the "ready but cannot leave"
+  // case. Deliberately NOT added: guardianship, financial arrangements, family availability — each
+  // describes the person rather than the bed, and so follows "Pending case review outcome" out of
+  // this list. Adding one is a recorded product decision, never an implementer's convenience.
+  "Awaiting accommodation",
+  "Awaiting transport",
+  "Awaiting receiving-service acceptance",
+] as const;
+```
+
+- [ ] **Step 5: Migrate and extend the fixtures**
+
+In `ward-movements.ts`, rewrite every entry of `bedReleases` to the new shape, and add `leaveBeds`
+below it. Migration rule: an entry whose old `confidence` was `"confirmed"` becomes
+`state: "confirmed", confidence: null`; any other becomes `state: "predicted"` keeping its
+confidence. Every old free-text `blocker` maps to the nearest `BED_RELEASE_BLOCKERS` value
+(`"Bed clean pending"` → `"Awaiting clean"`), and becomes `null` unless the entry is `blocked`.
+
+Then add entries so the seeded set satisfies D13 — at least one `predicted`, one `confirmed`, **two
+`blocked`**, one `released`. Use `WR-0NN` ids continuing the existing sequence, real unit ids from
+`ward-sites.ts`, `NOW_ANCHOR`-relative times, and `confirmedBy` role labels in the existing
+`"NUM <Unit Name>"` form. Two examples to follow exactly:
+
+```ts
+  {
+    id: "WR-007",
+    unitId: "fsh-adult-secure",
+    state: "blocked",
+    expectedAt: NOW_ANCHOR + 120,
+    confidence: null,
+    blocker: "Awaiting accommodation",
+    confirmedAt: NOW_ANCHOR - 35,
+    confirmedBy: "NUM FSH Adult Secure",
+  },
+  {
+    id: "WR-008",
+    unitId: "arm-adult-open",
+    state: "released",
+    expectedAt: NOW_ANCHOR - 15,
+    confidence: null,
+    blocker: null,
+    confirmedAt: NOW_ANCHOR - 15,
+    confirmedBy: "NUM ARM Adult Open",
+  },
+```
+
+And the new fixture:
+
+```ts
+/**
+ * Beds held by someone on approved leave. Never merged into availability (spec D4) — a usable
+ * leave bed is its own figure. Carries nothing about the person on leave.
+ */
+export const leaveBeds: LeaveBed[] = [
+  {
+    id: "WL-001",
+    unitId: "rph-adult-secure",
+    usable: true,
+    expectedReturn: NOW_ANCHOR + 300,
+    confirmedAt: NOW_ANCHOR - 60,
+    confirmedBy: "NUM RPH Adult Secure",
+  },
+  {
+    id: "WL-002",
+    unitId: "scgh-older-adult",
+    usable: false,
+    expectedReturn: NOW_ANCHOR + 180,
+    confirmedAt: NOW_ANCHOR - 25,
+    confirmedBy: "NUM SCGH Older Adult",
+  },
+];
+```
+
+- [ ] **Step 6: Run the test and watch it pass**
+
+```bash
+npx vitest run tests/ward-bed-availability-model.test.ts --project node --reporter dot
+```
+
+Expected: `Tests  6 passed (6)`. Read the count, not the exit code.
+
+- [ ] **Step 7: Mutation-test the privacy assertion**
+
+Temporarily add `sex: "Female",` to the first `bedReleases` entry and to the `BedRelease` type, and
+re-run. The structural field-set test **must** fail. If it passes, the test is checking nothing and
+must be fixed before proceeding. Revert the mutation afterwards and re-run to confirm green.
+
+- [ ] **Step 8: Run the whole ward suite, because this changed shared types**
+
+```bash
+npx vitest run tests/ward-*.test.ts tests/ward-*.dom.test.tsx --reporter dot
+```
+
+Expect failures in files that read `confidence: "confirmed"` or an untyped `blocker` — fix each by
+migrating it to the new shape, never by loosening a type. Quote the final `Test Files` and `Tests`
+lines.
+
+- [ ] **Step 9: Commit**
+
+```bash
+git add src/components/ward-management/ward-model.ts src/components/ward-management/ward-change-reasons.ts src/components/ward-management/ward-movements.ts tests/
+git commit -m "Give a bed release a lifecycle, and a leave bed its own type"
+```
+
+---
+
+## Task 2: The derivations
+
+**Files:**
+
+- Create: `src/components/ward-management/ward-bed-availability.ts`
+- Test: `tests/ward-bed-availability.test.ts` (create)
+
+**Interfaces:**
+
+- Consumes: `BedRelease`, `BedReleaseState`, `LeaveBed`, `Instant` from Task 1.
+- Produces:
+  - `export const EVENING_SHIFT_END_MINUTES = 22 * 60;`
+  - `export const RELEASE_BANDS = ["now", "by-midday", "by-1600", "tonight"] as const;`
+  - `export type ReleaseBand = (typeof RELEASE_BANDS)[number];`
+  - `export function releaseBand(release: BedRelease, now: Instant): ReleaseBand | "beyond-today"`
+  - `export type CapacityBreakdown = { availableNow: number; confirmedToday: number; predictedToday: number; held: number; leaveUsable: number; excludedBeyondToday: number }`
+  - `export function capacityBreakdown(unit: Unit, releases: BedRelease[], leave: LeaveBed[], now: Instant): CapacityBreakdown`
+
+**Interpretation of `Instant`.** `Instant` is `number` (`ward-clock.ts`), minutes from the scenario
+anchor. Bands are computed from the **time of day** the instant falls on, not from an offset — read
+`formatInstant` in `ward-clock.ts` and reuse whatever it uses to get hours and minutes. Do not
+reimplement clock arithmetic in this file.
+
+- [ ] **Step 1: Write the failing test**
+
+Create `tests/ward-bed-availability.test.ts`:
+
+```ts
+import { describe, expect, it } from "vitest";
+
+import {
+  capacityBreakdown,
+  EVENING_SHIFT_END_MINUTES,
+  releaseBand,
+} from "@/components/ward-management/ward-bed-availability";
+import type { BedRelease, LeaveBed } from "@/components/ward-management/ward-model";
+import { NOW_ANCHOR, allUnits } from "@/components/ward-management/ward-sites";
+
+const unit = allUnits[0];
+
+function release(overrides: Partial<BedRelease>): BedRelease {
+  return {
+    id: "WR-T01",
+    unitId: unit.id,
+    state: "predicted",
+    expectedAt: NOW_ANCHOR + 60,
+    confidence: "likely",
+    blocker: null,
+    confirmedAt: NOW_ANCHOR,
+    confirmedBy: "NUM Test Unit",
+    ...overrides,
+  };
+}
+
+function leave(overrides: Partial<LeaveBed>): LeaveBed {
+  return {
+    id: "WL-T01",
+    unitId: unit.id,
+    usable: true,
+    expectedReturn: NOW_ANCHOR + 300,
+    confirmedAt: NOW_ANCHOR,
+    confirmedBy: "NUM Test Unit",
+    ...overrides,
+  };
+}
+
+describe("release bands", () => {
+  it("ends the evening shift at 22:00, expressed once", () => {
+    expect(EVENING_SHIFT_END_MINUTES).toBe(1320);
+  });
+
+  it("puts an already-released bed in 'now' whatever its expected time said", () => {
+    expect(releaseBand(release({ state: "released", expectedAt: NOW_ANCHOR + 600 }), NOW_ANCHOR)).toBe("now");
+  });
+
+  it("excludes anything expected after the evening shift ends", () => {
+    // 1440 minutes is a full day past the anchor, so it lands beyond tonight whatever hour the
+    // anchor sits at.
+    expect(releaseBand(release({ expectedAt: NOW_ANCHOR + 1440 }), NOW_ANCHOR)).toBe("beyond-today");
+  });
+});
+
+describe("capacity breakdown", () => {
+  it("never adds a predicted or confirmed bed into availableNow", () => {
+    const bare = capacityBreakdown(unit, [], [], NOW_ANCHOR);
+    const loaded = capacityBreakdown(
+      unit,
+      [release({ state: "predicted" }), release({ id: "WR-T02", state: "confirmed", confidence: null })],
+      [],
+      NOW_ANCHOR,
+    );
+    expect(loaded.availableNow).toBe(bare.availableNow);
+    expect(loaded.predictedToday).toBe(1);
+    expect(loaded.confirmedToday).toBe(1);
+  });
+
+  it("never merges a usable leave bed into availableNow either", () => {
+    const bare = capacityBreakdown(unit, [], [], NOW_ANCHOR);
+    const withLeave = capacityBreakdown(unit, [], [leave({ usable: true })], NOW_ANCHOR);
+    expect(withLeave.availableNow).toBe(bare.availableNow);
+    expect(withLeave.leaveUsable).toBe(1);
+  });
+
+  it("counts an unusable leave bed in neither figure", () => {
+    const result = capacityBreakdown(unit, [], [leave({ usable: false })], NOW_ANCHOR);
+    expect(result.leaveUsable).toBe(0);
+  });
+
+  it("reports what it excluded rather than dropping it silently", () => {
+    const result = capacityBreakdown(unit, [release({ expectedAt: NOW_ANCHOR + 1440 })], [], NOW_ANCHOR);
+    expect(result.predictedToday).toBe(0);
+    expect(result.excludedBeyondToday).toBe(1);
+  });
+
+  it("ignores releases and leave beds belonging to another unit", () => {
+    const result = capacityBreakdown(
+      unit,
+      [release({ unitId: "not-this-unit" })],
+      [leave({ unitId: "not-this-unit" })],
+      NOW_ANCHOR,
+    );
+    expect(result.predictedToday).toBe(0);
+    expect(result.leaveUsable).toBe(0);
+  });
+});
+```
+
+- [ ] **Step 2: Run the test and watch it fail**
+
+```bash
+npx vitest run tests/ward-bed-availability.test.ts --project node --reporter dot
+```
+
+Expected: fails at import — the module does not exist.
+
+- [ ] **Step 3: Write the module**
+
+Create `src/components/ward-management/ward-bed-availability.ts`. `availableNow` and `held` keep
+**exactly** the meanings `unitCapacity` gives them today — copy those two lines from
+`unitCapacity` in `ward-derivations.ts` rather than inventing new arithmetic, so the one number a
+coordinator acts on cannot drift.
+
+```ts
+/**
+ * Every figure the capacity board shows, derived in one place so no screen computes its own
+ * version. Phase 5, spec D5 and D6.
+ *
+ * The rule this file exists to enforce: **nothing predicted, confirmed-but-unreleased, or on leave
+ * is ever added into `availableNow`.** A coordinator must be able to point at that number and say
+ * "that is a bed I can fill this minute", and it must never have been softened by an expectation.
+ */
+```
+
+Implement the six figures per the test. `excludedBeyondToday` counts this unit's non-`released`
+releases whose band is `"beyond-today"`.
+
+- [ ] **Step 4: Run the test and watch it pass**
+
+```bash
+npx vitest run tests/ward-bed-availability.test.ts --project node --reporter dot
+```
+
+Expected: `Tests  8 passed (8)`.
+
+- [ ] **Step 5: Mutation-test the two load-bearing assertions**
+
+Mutate `availableNow` to add `predictedToday`. The "never adds a predicted or confirmed bed" test
+must fail. Then mutate `excludedBeyondToday` to return `0` always; the exclusion test must fail.
+Revert both, re-run, confirm green. Report any mutation that survived rather than reshaping the test.
+
+- [ ] **Step 6: Commit**
+
+```bash
+git add src/components/ward-management/ward-bed-availability.ts tests/ward-bed-availability.test.ts
+git commit -m "Derive the five capacity figures in one place, and count what they exclude"
+```
+
+---
+
+## Task 3: The transitions
+
+**Files:**
+
+- Modify: `src/components/ward-management/ward-flow-events.ts`
+- Modify: `src/components/ward-management/ward-flow-reducer.ts`
+- Test: `tests/ward-bed-release-lifecycle.test.ts` (create)
+
+**Interfaces:**
+
+- Consumes: `BedRelease`, `BedReleaseState`, `LeaveBed`, `BedReleaseBlocker` from Task 1.
+- Produces: events `CONFIRM_BED_RELEASE`, `BLOCK_BED_RELEASE`, `RELEASE_BED`,
+  `RECORD_LEAVE_BED`, `END_LEAVE_BED`, `REQUEST_CAPACITY_REFRESH`; `WardFlowState` gains
+  `leaveBeds: LeaveBed[]` and `refreshRequests: { unitId: string; at: Instant; byRole: string }[]`.
+
+**Read first:** the existing `FLAG_BED_RELEASE` case in `ward-flow-reducer.ts`, the `reject(state,
+event, reason)` helper at line ~96, and the `EVENT_ROLE` table in `ward-flow-events.ts`. Follow all
+three exactly; a new transition that refuses differently from every existing one is a defect even if
+it works.
+
+- [ ] **Step 1: Write the failing test**
+
+Create `tests/ward-bed-release-lifecycle.test.ts`. Cover, one `it` each:
+
+1. A ward confirms a `predicted` release → its state is `confirmed` and its `confidence` is `null`.
+2. A ward blocks a release with a blocker from the list → state `blocked`, blocker recorded.
+3. A ward blocks with no blocker → **rejected**, `state.rejections` grows by one, the release is
+   unchanged.
+4. A ward releases a `confirmed` release → state `released`, and that unit's `availableNow` (via
+   `capacityBreakdown`) is one higher than before.
+5. A **coordinator** attempting each of `CONFIRM_BED_RELEASE`, `BLOCK_BED_RELEASE`, `RELEASE_BED`
+   → rejected, three rejections, no state change. (Spec D2.)
+6. A ward whose `actingUnitId` does not match the release's `unitId` → rejected. (Same claim-not-proof
+   discipline as `FLAG_BED_RELEASE`.)
+7. `RECORD_LEAVE_BED` adds a leave bed; `END_LEAVE_BED` removes it.
+8. A coordinator's `REQUEST_CAPACITY_REFRESH` is **accepted** — it is the one thing a coordinator may
+   do — and changes no bed figure at all: `capacityBreakdown` before and after are deeply equal.
+
+Build state with `seedWardFlowState()` from `ward-flow-reducer.ts` and drive it through
+`wardFlowReducer`, the way `tests/ward-flow-reducer.test.ts` already does. Copy that file's setup
+rather than inventing another.
+
+- [ ] **Step 2: Run the test and watch it fail**
+
+```bash
+npx vitest run tests/ward-bed-release-lifecycle.test.ts --project node --reporter dot
+```
+
+Expected: fails — the event types do not exist.
+
+- [ ] **Step 3: Add the events and their role entries**
+
+In `ward-flow-events.ts`, add six variants to `WardFlowEvent`. Each of the five ward events carries
+`role`, `now`, `releaseId` (or `leaveBedId` / `unitId`), and `actingUnitId`. `BLOCK_BED_RELEASE`
+additionally carries `blocker: BedReleaseBlocker`. Then extend `EVENT_ROLE`:
+
+```ts
+  CONFIRM_BED_RELEASE: ["ward"],
+  BLOCK_BED_RELEASE: ["ward"],
+  RELEASE_BED: ["ward"],
+  RECORD_LEAVE_BED: ["ward"],
+  END_LEAVE_BED: ["ward"],
+  // The one thing a coordinator may do to a ward's bed data. It changes no number: it marks that
+  // somebody asked. Spec D12.
+  REQUEST_CAPACITY_REFRESH: ["coordinator"],
+```
+
+Adding an event without an `EVENT_ROLE` entry is a compile error, which is the point.
+
+- [ ] **Step 4: Add `leaveBeds` and `refreshRequests` to the state and seed them**
+
+In `ward-flow-reducer.ts`, extend `WardFlowState` and `seedWardFlowState()`:
+`leaveBeds: structuredClone(leaveBeds)` and `refreshRequests: []`.
+
+- [ ] **Step 5: Implement the six cases**
+
+Each ward case: find the release, refuse via `reject(...)` with a specific reason when it is missing,
+when `actingUnitId !== release.unitId`, or when the transition is invalid from the current state.
+Legal transitions and nothing else:
+
+- `predicted → confirmed | blocked`
+- `confirmed → released | blocked`
+- `blocked → confirmed | released`
+- `released →` nothing. It is terminal.
+
+`BLOCK_BED_RELEASE` sets `confidence: null` and the given blocker. `CONFIRM_BED_RELEASE` and
+`RELEASE_BED` set `blocker: null` and `confidence: null`.
+
+- [ ] **Step 6: Run the test and watch it pass**
+
+```bash
+npx vitest run tests/ward-bed-release-lifecycle.test.ts --project node --reporter dot
+```
+
+Expected: `Tests  8 passed (8)`.
+
+- [ ] **Step 7: Mutation-test the role gate**
+
+Change `CONFIRM_BED_RELEASE` in `EVENT_ROLE` to `["ward", "coordinator"]`. Test 5 must fail. Revert,
+re-run green. A role gate that cannot fail is the most expensive kind of passing test here.
+
+- [ ] **Step 8: Commit**
+
+```bash
+git add src/components/ward-management/ward-flow-events.ts src/components/ward-management/ward-flow-reducer.ts tests/ward-bed-release-lifecycle.test.ts
+git commit -m "A ward moves its own beds through the lifecycle; a coordinator may only ask"
+```
+
+---
+
+## Task 4: The freshness stamp
+
+**Files:**
+
+- Create: `src/components/ward-management/ward-freshness.tsx`
+- Create: `src/components/ward-management/ward-freshness.module.css`
+- Test: `tests/ward-freshness.dom.test.tsx` (create)
+
+**Interfaces:**
+
+- Consumes: `Instant`, and `formatInstant` from `ward-clock.ts`.
+- Produces: `export function WardFreshness({ confirmedAt, confirmedByRole, now }: { confirmedAt?: Instant | null; confirmedByRole?: string | null; now: Instant })`
+
+Three renderings, and no fourth:
+
+| Input                                    | Renders                              |
+| ---------------------------------------- | ------------------------------------ |
+| both `confirmedAt` and `confirmedByRole` | `Confirmed 10:22 · RPH Adult Secure` |
+| neither                                  | `Never confirmed`                    |
+| `confirmedAt` absent, `now` given        | `As at 10:42`                        |
+
+- [ ] **Step 1: Write the failing test**
+
+```tsx
+import { render, screen } from "@testing-library/react";
+import { describe, expect, it } from "vitest";
+
+import { WardFreshness } from "@/components/ward-management/ward-freshness";
+import { NOW_ANCHOR } from "@/components/ward-management/ward-sites";
+
+describe("freshness stamp", () => {
+  it("names the time and the confirming role", () => {
+    render(<WardFreshness confirmedAt={NOW_ANCHOR - 20} confirmedByRole="RPH Adult Secure" now={NOW_ANCHOR} />);
+    expect(screen.getByText(/Confirmed/)).toHaveTextContent("RPH Adult Secure");
+  });
+
+  it("says 'Never confirmed' rather than showing a blank or a dash", () => {
+    render(<WardFreshness now={NOW_ANCHOR} />);
+    expect(screen.getByText("Never confirmed")).toBeTruthy();
+    expect(screen.queryByText("—")).toBeNull();
+  });
+
+  it("falls back to the time it was computed when there is nothing to confirm", () => {
+    render(<WardFreshness confirmedByRole={null} confirmedAt={null} now={NOW_ANCHOR} />);
+    expect(screen.getByText(/^(Never confirmed|As at )/)).toBeTruthy();
+  });
+});
+```
+
+- [ ] **Step 2: Run it and watch it fail**
+
+```bash
+npx vitest run tests/ward-freshness.dom.test.tsx --reporter dot
+```
+
+- [ ] **Step 3: Write the component and its styles**
+
+Muted small text, tokens only, no hex. Follow `ward-role-switcher.module.css`'s self-contained-token
+convention: declare every `--ward-*` this file uses on its own root class.
+
+- [ ] **Step 4: Run it and watch it pass, then commit**
+
+```bash
+npx vitest run tests/ward-freshness.dom.test.tsx --reporter dot
+git add src/components/ward-management/ward-freshness.tsx src/components/ward-management/ward-freshness.module.css tests/ward-freshness.dom.test.tsx
+git commit -m "One freshness stamp, so every board can say how old it is"
+```
+
+---
+
+## Task 5: The ward's controls
+
+**Files:**
+
+- Modify: `src/components/ward-management/ward/ward-screen.tsx`
+- Modify: `src/components/ward-management/ward/ward.module.css`
+- Test: `tests/ward-screen.dom.test.tsx` (extend)
+
+**Interfaces:** consumes Task 1's types, Task 3's events, Task 4's `WardFreshness`.
+
+The existing flagging panel already collects confidence and blocker and dispatches
+`FLAG_BED_RELEASE`. Extend the same panel; do not add a second one.
+
+- [ ] **Step 1: Write the failing tests** — extend `tests/ward-screen.dom.test.tsx` with four cases:
+      confirming a predicted release updates the row; blocking asks for a reason and refuses without
+      one; releasing removes it from the pending list; and a refresh request raised by a coordinator
+      appears on this ward's screen as a visible mark naming the time and the requesting role.
+- [ ] **Step 2: Run and watch them fail.**
+      `npx vitest run tests/ward-screen.dom.test.tsx --reporter dot`
+- [ ] **Step 3: Add the controls.** Each release row gets Confirm / Blocked / Released, each a real
+      `<button>` with a real handler. Blocking opens the existing blocker `<select>`. Add a small
+      leave-bed form: unit implied, `usable` a checkbox, expected return a time. Render
+      `<WardFreshness>` beside the unit's capacity.
+- [ ] **Step 4: Run and watch them pass.**
+- [ ] **Step 5: Commit.** `git commit -m "The ward moves its own beds, and sees when it was asked to refresh"`
+
+---
+
+## Task 6: The discharge and egress board
+
+**Files:**
+
+- Create: `src/components/ward-management/discharges/discharge-board.tsx`
+- Create: `src/components/ward-management/discharges/discharges.module.css`
+- Create: `src/app/mockups/ward-flow/discharges/page.tsx`
+- Modify: `src/components/ward-management/ward-nav.ts`
+- Test: `tests/ward-discharge-board.dom.test.tsx` (create)
+
+**Interfaces:** consumes Task 1's types, Task 2's `capacityBreakdown` / `releaseBand`, Task 4's
+`WardFreshness`.
+
+Group order is **Blocked, Confirmed, Predicted, Released today** — blocked first because those are
+the rows somebody must act on. Within a group, order by band. The excluded-beyond-today count sits
+at the foot of the board and is **stated even when it is zero**.
+
+Copy the route and screen shape from `src/components/ward-management/handover/handover-page.tsx` and
+its route file — same shell, same `<ClinicalRail />`, same `<main id="main-content">`, same
+governance banner.
+
+- [ ] **Step 1: Write the failing test** — assert the four group headings in that order; that a
+      blocked row names its blocker; that the excluded count renders with the text `0` when nothing
+      is excluded; and that every row carries a freshness stamp.
+- [ ] **Step 2: Run and watch it fail.**
+- [ ] **Step 3: Build the board, the styles and the route.** Add
+      `{ id: "discharges", href: "/mockups/ward-flow/discharges", label: "Discharges", group: "board" }`
+      to `WARD_NAV`, and an icon to `WARD_NAV_ICONS` in `ward-nav-icons.ts` (use `LogOut`).
+- [ ] **Step 4: Run the nav contract test**, which enumerates routes from the filesystem both ways:
+      `npx vitest run tests/ward-nav.test.ts --project node --reporter dot`
+- [ ] **Step 5: Add the phone card layout.** Below `40rem` the board is cards, not a squeezed table
+      — one card per release, blocker and band prominent. Follow
+      `src/components/ward-management/search/search.module.css`'s `.tableScroll` / `.table` pattern
+      for anything that stays tabular.
+- [ ] **Step 6: Commit.** `git commit -m "A board for the beds on their way out, blocked ones first"`
+
+---
+
+## Task 7: The capacity headline and the coordinator's one action
+
+**Files:**
+
+- Modify: `src/components/ward-management/ward-management-modes.tsx`
+- Modify: `src/components/ward-management/ward-management-modes.module.css`
+- Modify: `src/components/ward-management/ward-derivations.ts`
+- Test: `tests/ward-capacity-view.dom.test.tsx` (extend)
+
+**Interfaces:** consumes Task 2's `capacityBreakdown`, Task 3's `REQUEST_CAPACITY_REFRESH`, Task 4's
+`WardFreshness`.
+
+**This task changes existing rendered behaviour** — the only one in the phase that does.
+`unitCapacity().potential` is a raw count of every release regardless of state or timing, and it is
+replaced by the breakdown. Say so in the commit message and in a comment where it happens.
+
+- [ ] **Step 1: Write the failing tests** — the headline renders five separate figures and never a
+      sum; `Available now` is unchanged by adding a predicted release; the coordinator's refresh
+      control is a real button that dispatches `REQUEST_CAPACITY_REFRESH`; and the excluded count
+      appears when a release falls beyond tonight.
+- [ ] **Step 2: Run and watch them fail.**
+- [ ] **Step 3: Replace the headline and add the control.** Five figures as five separate cards:
+      `Available now · Confirmed today · Predicted today · Held · Leave (usable)`. Deprecate
+      `unitCapacity().potential` in favour of `capacityBreakdown`, leaving a comment at the old call
+      site naming this task.
+- [ ] **Step 4: Run and watch them pass.**
+- [ ] **Step 5: Commit.** `git commit -m "Capacity becomes five numbers, and none of them is a guess added to a fact"`
+
+---
+
+## Task 8: Verification sweep
+
+**Files:** `tests/ui-ward-discharges.spec.ts` (create), plus `playwright.config.ts` if the spec
+pattern needs the new file name — check `mockupSpecPattern` and `testMatch` before assuming.
+
+- [ ] **Step 1: Write one Chromium journey.** A ward flags a release, confirms it, blocks it with a
+      reason, then releases it — and the coordinator's capacity board reflects each change **without
+      a reload**. Tag it `@mockup`. Model it on
+      `tests/ui-ward-roles.spec.ts`'s "a ward confirming zero allocatable beds updates its own
+      screen, then the coordinator" journey, which already proves this pattern works.
+- [ ] **Step 2: Run the ward journeys.**
+
+```bash
+node scripts/run-playwright.mjs tests/ui-ward-management.spec.ts tests/ui-ward-coordinator.spec.ts tests/ui-ward-roles.spec.ts tests/ui-ward-discharges.spec.ts --project=chromium-mockups
+```
+
+Retry on `DATABASE_HEAVY_RUN_ADMISSION_BUSY` or `EPERM … owner.json`. Quote the `N passed` line.
+
+- [ ] **Step 3: Capture and LOOK AT screenshots** at 390px, 820px and 1440px: the discharge board,
+      the capacity board, and the ward screen. Every defect found in the Phase 4 sweep was invisible
+      to structural checks and visible in a screenshot. Report what you see; do not assume.
+- [ ] **Step 4: Run the full local gates once.**
+
+```bash
+npx vitest run tests/ward-*.test.ts tests/ward-*.dom.test.tsx --reporter dot
+npm run typecheck
+npm run lint
+npm run format
+```
+
+- [ ] **Step 5: Commit the format result and push once**, with every commit assembled first. Pushing
+      mid-run cancels the checks already running and restarts them.
+
+---
+
+## Self-review
+
+**Spec coverage.** D1 → Task 1. D2 → Task 3. D3 → Tasks 1 and 3. D4 → Tasks 1, 2, 5. D5 → Task 2.
+D6 → Tasks 2 and 7. D7 → Tasks 4, 5, 6, 7. D8 → Task 1 (`confirmedBy` role labels) and the global
+constraints. D9 → Task 6. D10 → Task 5. D11 → Task 1's structural privacy test. D12 → Tasks 3, 5, 7.
+D13 → Task 1's fixtures. D14 is a recorded risk with no code, correctly.
+
+**Placeholders.** None: every code step carries the actual content, and every "follow the existing
+pattern" instruction names the exact file to copy from.
+
+**Type consistency.** `BedReleaseState`, `BedRelease.state`, `BedRelease.blocker: string | null`,
+`LeaveBed.usable`, `capacityBreakdown`, `releaseBand`, `EVENING_SHIFT_END_MINUTES`, `WardFreshness`
+are used with identical names and shapes in every task that mentions them.
+
+**One known gap, stated rather than hidden.** Tasks 5, 6 and 7 specify their tests by description
+rather than as literal code, because their assertions depend on markup that exists in files this
+plan does not reproduce. Each names the exact file to model on and the exact behaviour to assert.
+An implementer who cannot write the test from that should stop and ask rather than guess.
+
+## Parallelism
+
+Task 1 is serial and first. Then Tasks 2, 3 and 4 may run concurrently — different files, no shared
+edits. Then Tasks 5, 6 and 7 may run concurrently. Task 8 is serial and last.
+
+Each implementer runs **only** its own focused Vitest file. The repository permits two focused test
+leases at once and serialises everything heavier across every worktree on the machine, so agents that
+each run the full suite will queue behind each other and lose the parallelism the fan-out bought.
+Full suite, lint, format, typecheck, build and Playwright run **once**, in Task 8.
diff --git a/docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md b/docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md
new file mode 100644
index 0000000000..426f09107e
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md
@@ -0,0 +1,300 @@
+# Ward Flow Phase 5 — Bed availability becomes real
+
+**Status:** design, approved in chat 2026-08-26. Implementation plan follows separately.
+
+**One sentence:** wards say when beds are actually coming free, and the coordinator's capacity
+figure becomes a number that can be planned against rather than a snapshot of the present moment.
+
+---
+
+## Why this phase, and why first
+
+Ward Flow models one direction. Beds fill; nothing in the system ever releases one on a schedule.
+The capacity board answers "how many beds exist right now", which is not the question a bed
+coordinator asks. The question is "will there be a bed tonight", and that is a discharge question,
+not an admission question.
+
+The phase order after this one changed on 2026-08-26: the morning state-of-the-state page moves
+from Phase 8 to **Phase 6**, ahead of the community front door. It is built entirely from the
+numbers this phase produces, it is small, and it is the artefact that can be put in front of
+colleagues. Finding out whether any of this is right is worth more than the next feature.
+
+Every other item on the Phase 6–8 list — the morning page, escalation tiers, the closest-suitable-
+bed measure, the retrospective — needs a trustworthy availability number underneath it. Building
+any of those first means building them twice: once against guesses, then again once the guesses are
+replaced. So this phase has no headline screen and is still the one that has to come first.
+
+## What already exists (do not rebuild it)
+
+Phase 4 built more of this than the Phase 5 discussion credited, and the plan must extend it rather
+than introduce a parallel concept:
+
+- **`BedRelease`** (`ward-model.ts`) — `{ id, unitId, expectedAt, confidence, blocker, confirmedAt,
+confirmedBy }`. Its doc comment records the privacy rule as non-negotiable: every field is about
+  the bed or the confirming ward, never about a person. `tests/ward-flow-reducer.test.ts` asserts
+  this **structurally against the type's own field set**, not merely against fixture content.
+- **`BED_RELEASE_CONFIDENCE_LEVELS`** — `confirmed | likely | possible`.
+- **`BED_RELEASE_BLOCKERS`** — `Awaiting clean | Awaiting pharmacy | Awaiting placement
+confirmation | Awaiting service coordination`, chosen from a list and never typed. The list's own
+  doc comment records that "Pending case review outcome" was deliberately excluded because it reads
+  as being about the patient's case rather than about the bed.
+- **`FLAG_BED_RELEASE`**, ward-only in `EVENT_ROLE`, with the acting-unit claim checked against the
+  target unit.
+- **A flagging panel on the ward screen** already collecting confidence and blocker.
+- **`unitCapacity().potential`** — a raw count of that unit's releases, rendered as a column.
+
+## Scope
+
+**In:**
+
+1. A lifecycle for a bed release, replacing the current single-shot flag.
+2. Leave beds, as a distinct thing from an empty bed.
+3. A discharge and egress board.
+4. Predicted capacity for today, expressed in time bands.
+5. A freshness signal on every screen.
+
+**Out, and deliberately so:** the community front door, geography and distance, the morning
+state-of-the-state page, escalation tiers, the retrospective view, notifications, cohort and
+bed-type matching, the navigation regrouping, the network diagram rework. Those are Phases 6–8.
+
+---
+
+## Decisions
+
+### D1 — A bed release has a lifecycle, and `confidence` stops doing two jobs
+
+Add `state: "predicted" | "confirmed" | "blocked" | "released"` to `BedRelease`.
+
+`confidence` currently carries `confirmed | likely | possible`, which conflates a _lifecycle
+position_ ("the ward has confirmed this is happening") with a _degree of belief_ ("we think it is
+likely"). Narrow it to `likely | possible`, and make it meaningful only while `state` is
+`predicted`. A confirmed release has no confidence: it is not a belief any more.
+
+Migration is mechanical: any existing release whose `confidence` is `confirmed` becomes
+`state: "confirmed"` with `confidence: null`.
+
+- `predicted` — the ward expects this bed to come free today. Carries `confidence` and `expectedAt`.
+- `confirmed` — the ward has confirmed it is happening today. No `confidence`.
+- `blocked` — the bed would be free but something operational is holding it. Carries a `blocker`.
+- `released` — terminal. The bed is now empty and counts as available.
+
+### D2 — Only the ward moves a release; the coordinator is read-only
+
+`FLAG_BED_RELEASE` is already ward-only. The three new transitions (`CONFIRM_BED_RELEASE`,
+`BLOCK_BED_RELEASE`, `RELEASE_BED`) are ward-only too, with the same acting-unit claim check.
+
+A coordinator attempting any of them produces a `Rejection` — the codebase's existing first-class
+refusal type, already surfaced on the coordinator screen rather than swallowed. The coordinator can
+see every release and can escalate about one; they cannot change it. This is the point: the ward
+owns its own beds, and a hub that lets a central coordinator edit a ward's bed state is a hub wards
+will stop trusting.
+
+### D3 — `blocker` becomes state-dependent and typed
+
+Today `blocker` is `string` and always present. Tighten to `BedReleaseBlocker | null`: required when
+`state` is `blocked`, and `null` in every other state. The reducer refuses a `blocked` transition
+with no blocker, and refuses a blocker on any other state.
+
+Extend `BED_RELEASE_BLOCKERS` with three additions that are operational rather than clinical:
+
+- `Awaiting accommodation`
+- `Awaiting transport`
+- `Awaiting receiving-service acceptance`
+
+**Deliberately excluded: anything describing a person's own circumstances.** Guardianship,
+financial arrangements and family availability are all real blockers in practice and all describe
+the patient rather than the bed, so they follow "Pending case review outcome" out of the list. If
+the product owner wants any of them, it is a one-line addition and a recorded decision — not
+something an implementer adds because it seemed useful.
+
+### D4 — A leave bed is not an empty bed
+
+Add `LeaveBed`: `{ id, unitId, usable, expectedReturn, confirmedAt, confirmedBy }`.
+
+A patient on approved leave occupies a bed that may or may not be fillable while they are away, and
+a coordinator needs to see which. `usable: true` means the ward says it can be filled; `usable:
+false` means it cannot. Like `BedRelease`, it carries nothing about the person on leave — not an
+identifier, not a reason, not a destination.
+
+**A usable leave bed is never merged into `available`.** It is its own count, rendered as its own
+figure. Merging it would inflate the one number the whole hub depends on.
+
+### D5 — The horizon is today, in four bands
+
+`expectedAt` stays an instant. Bands are derived from it relative to the demo clock:
+
+- **Now** — already released.
+- **By midday**
+- **By 1600**
+- **Tonight** — up to the end of the evening shift, taken as **22:00**.
+
+**Why 22:00 and not midnight.** Midnight is a calendar boundary; nobody hands over at midnight. The
+band has to end where the working day ends, or "beds tonight" means something different to the
+person reading it than to the ward that entered it. 22:00 is this prototype's choice, recorded here
+so it can be changed in one place, and it is a synthetic convenience rather than a claim about how
+any real service runs its shifts.
+
+Anything expected beyond tonight is **excluded from every count and the board says how many were
+excluded**. Silent truncation reads as "we counted everything" when we did not, and a bed
+coordinator who discovers a hidden bucket stops trusting the visible ones.
+
+Beyond roughly 24 hours a psychiatric discharge prediction is a guess wearing a number's clothes.
+The horizon is a deliberate refusal, not a limitation to be lifted later.
+
+### D6 — Predicted beds are never added to available
+
+The capacity headline becomes five separate figures, never a sum:
+
+> **Available now 25 · Confirmed today 9 · Predicted today 6 · Held 14 · Leave (usable) 3**
+
+`Available now` keeps its current meaning exactly. Nothing predicted or confirmed-but-not-yet-
+released is permitted to change it. The render policy is explicit: a coordinator must be able to
+point at one number and say "that is a bed I can fill this minute", and that number must never have
+been softened by an expectation.
+
+`unitCapacity().potential` — today a raw count of every release regardless of state or timing — is
+replaced by this breakdown. It is the one existing behaviour this phase changes rather than extends,
+and the plan must say so where it does.
+
+### D7 — Every screen states when its data was last true
+
+One shared freshness component, rendered on every Ward Flow board:
+
+- Where a confirming role exists: **"Confirmed 10:22 · RPH Adult Secure"**.
+- Where nothing has ever been confirmed: **"Never confirmed"** — never a blank, never a dash.
+- Where the screen shows derived rather than confirmed data: **"As at 10:42"**, the clock time it
+  was computed.
+
+Today only the capacity board carries freshness. A board that looks authoritative and cannot say how
+old it is invites the reader to assume it is current, and every other board in Ward Flow currently
+does exactly that.
+
+### D8 — An owner is a role, never a person
+
+`confirmedBy` is tightened from `string` to a role identifier — a unit or a named service, never an
+individual. This is the general rule for the whole hub (agreed for Phases 5–8): accountability
+attaches to a role, which survives a shift change without reassignment and keeps staff names out of
+the system entirely.
+
+### D9 — The discharge and egress board
+
+New route: `/mockups/ward-flow/discharges`, reached from the sidebar's Boards group and from the
+capacity board's own figures.
+
+Grouped by state in the order a coordinator scans them — **Blocked** first (these are the ones
+somebody must act on), then **Confirmed**, then **Predicted**, then **Released today**. Within a
+group, ordered by expected band.
+
+Each row: unit, health service, expected band, blocker where there is one, confirming role, and its
+freshness stamp. A count of releases excluded for falling beyond tonight sits at the foot of the
+board, stated even when it is zero.
+
+**On a phone this board is cards, not a squeezed table** — one card per release, the blocker and the
+band as the two prominent facts. Ward Flow's tables are right at a desk and wrong in a corridor, and
+this is the first board built after that was noticed.
+
+### D10 — The ward screen owns the transitions
+
+The ward screen's existing flagging panel gains the rest of the lifecycle: confirm a predicted
+release, mark one blocked with a reason from the fixed list, mark one released, and record a leave
+bed with its usability. Every control is a real control with a real handler — no advisory buttons.
+
+The coordinator screen renders the same data read-only, with an escalation path but no edit path.
+
+### D11 — No new fact about any person, anywhere
+
+`BedRelease` and `LeaveBed` both stay free of anything describing the departing or absent patient.
+Specifically, **neither carries sex**, even though sex is the one permitted patient attribute and
+carrying it would let the sex-mix column update on a predicted release.
+
+The trade is deliberate: sex mix updates only when occupancy actually changes, which is already
+modelled. Adding sex to a bed release for arithmetic convenience would break the structural privacy
+test Phase 4 wrote against the type's own field set, and that test is worth more than a column that
+refreshes an hour earlier.
+
+### D12 — A coordinator may ask a ward to refresh, and may do nothing else
+
+A coordinator can mark a unit's bed count as **refresh requested**. The ward sees that mark on its
+own screen, next to its own capacity, with the time it was asked and by which role.
+
+Nothing leaves the sandbox and no message is sent. This is the most common real interaction in bed
+management — the phone call that says "is that still right?" — and modelling it as a visible mark
+rather than a message makes the hub useful before notifications exist (Phase 8), without acquiring
+any of notification's governance weight.
+
+It remains the only thing a coordinator can do to a ward's bed data, and it changes no number. D2
+still holds: the ward owns its beds.
+
+### D13 — The seeded scenario opens on its worst case, not its best
+
+The default scenario seeds bed releases across **every** state, including at least two `blocked`
+ones and at least one leave bed marked unusable. A discharge board that opens empty demonstrates
+nothing, and a board that opens with everything confirmed demonstrates the wrong thing — the
+screen's whole purpose is the awkward cases.
+
+### D14 — The four states are the prototype's model, and are not yet clinically validated
+
+`predicted → confirmed → blocked → released` is a software model of how a bed comes free. It has
+not been checked against how a ward charge nurse actually thinks, and it may be a tidy version of
+something messier — a bed can be simultaneously confirmed and blocked in reality, and "predicted"
+may compress several distinct real states.
+
+It is built as specified because a working model beats an unbuilt one, and because the model is
+cheap to change while it is synthetic. **This is recorded as the single most valuable thing to check
+with a ward clinician**, not as a defect. If it turns out to be wrong, the states change; nothing
+else in this phase depends on there being exactly four.
+
+---
+
+## Data flow
+
+A ward flags a release → it enters state `predicted` with a confidence and an expected time → the
+ward later confirms, blocks, or releases it → every state change re-derives that unit's capacity
+breakdown → the coordinator's capacity board, the new discharge board and the priority queue all
+read the same derivation. No screen computes its own version of the number.
+
+Leave beds follow the same path with a two-state life: recorded, then ended on return.
+
+## Failure behaviour
+
+Consistent with the rest of Ward Flow, every failure degrades toward saying less rather than
+guessing more:
+
+- A release with no valid state, an unknown blocker, or an expected time outside today is **not
+  counted and is reported as excluded**, never quietly dropped.
+- A refused transition produces a visible `Rejection`, never a silent no-op.
+- A unit with no confirmed capacity reads **"Never confirmed"**, never zero. Zero is a claim.
+- If the derivation cannot produce a breakdown, the board shows `Available now` alone and states
+  that the prediction is unavailable — the conservative figure survives; the optimistic one does not.
+
+## Verification
+
+- Unit tests for the lifecycle, the role gate, the band derivation and the exclusion count — each
+  mutation-tested, with the surviving mutation reported rather than the test reshaped.
+- Extension of the existing structural privacy test to `LeaveBed` and to the new fields.
+- A contract test that no screen sums a predicted figure into `Available now`.
+- A Chromium journey: a ward flags, confirms and blocks a release, and the coordinator's board
+  reflects each change without a reload.
+- A phone-width check that the discharge board renders as cards and does not overflow.
+- Screenshots at 390px, 820px and 1440px, looked at rather than assumed. Every defect found in the
+  Phase 4 sweep was invisible to structural checks.
+
+## Success criteria
+
+1. A coordinator can answer "how many beds will exist tonight" from one screen.
+2. No predicted bed has ever been counted as an available one.
+3. A ward can record everything it knows about its own beds in under a minute.
+4. Every board says how old its data is.
+5. Not one new fact about any patient has entered the system.
+
+## Risks
+
+- **The prediction is only as good as the ward's habit of updating it.** No software fixes that; the
+  design's answer is to make the ward screen fast and to make staleness visible everywhere rather
+  than to nag.
+- **Replacing `potential` changes an existing rendered figure.** It is the one behavioural change in
+  this phase and must be called out where it happens, not folded in silently.
+- **The state model is unvalidated (D14).** A ward clinician has not yet checked it, and it is the
+  assumption most likely to be wrong.
+- **The four bands are a synthetic convenience.** They are the prototype's choice, not a clinical
+  standard, and the board should not imply otherwise.
diff --git a/docs/ward-flow-complete-ledger.md b/docs/ward-flow-complete-ledger.md
index 7e0b3cb7d0..4c26696e33 100644
--- a/docs/ward-flow-complete-ledger.md
+++ b/docs/ward-flow-complete-ledger.md
@@ -1,7 +1,8 @@
-# Ward Flow — the complete ledger, Phases 1 to 3
+# Ward Flow — the complete ledger, Phases 1 to 5
 
-The single cross-session record of everything built on branch `codex/ward-management-design`,
-assembled 2026-08-21 and refreshed 2026-08-22 after the branch was pushed. Ward Flow has run across many chat sessions on
+The single cross-session record of everything built. Assembled 2026-08-21 on branch
+`codex/ward-management-design`, refreshed 2026-08-22, and extended on 2026-08-26 with Phase 4, the
+sandbox and sidebar work, and the Phase 5 design. Ward Flow has run across many chat sessions on
 several different tools, and no single conversation holds the whole picture. This file does.
 
 **It is a map, not a replacement.** Each phase's own ledger holds the detail; this file records
@@ -223,20 +224,107 @@ The practice that follows: mutation-test every test, print the edited line back
 before trusting the run, re-run every subagent's gates independently, and read counts rather than
 the word "passed".
 
+## 5b. Phase 4 — specialist boards (2026-08-25)
+
+Branch `claude/ward-flow-phase-4-spec`, PR #2373. Eleven of twelve planned items delivered; item
+twelve, a statutory clock board, was deliberately **held** because building it requires stating
+figures from the Mental Health Act, and no agent may state, paraphrase or infer one.
+
+Delivered: the handover board, the escalation board, patient search, the role switcher that walks
+one movement through all four roles without a reload, the demo clock and scenario reset, capacity
+columns for sex mix / specialling / authorisation, bed releases with a fixed blocker list, the
+change audit, and the effectiveness numbers with the third measure explicitly dropped and said so
+on the page.
+
+Two of the phase's own claims were **corrected in the spec after the fact**, both wrong in the same
+direction — a measurement taken from a function that truncates its input. The eligible-ward
+distribution is `{0:2, 4:11, 5:6, 6:3, 11:1, 12:9, 14:9}` over 337 eligible pairs, with WF-009 and
+WF-308 stranded. A subagent's test contradicted the original figure and was right.
+
+Binding spec: `docs/superpowers/specs/2026-08-25-ward-flow-phase-4-specialist-boards-design.md`.
+Plan: `docs/superpowers/plans/2026-08-25-ward-flow-phase-4-specialist-boards.md`. Note that
+Prettier never converges on that plan file — two `--write` passes leave thirty lines differing — so
+a format guard on it is expected to need `SKIP_FORMAT_GUARD=1`, and that is documented rather than
+worked around.
+
+## 5c. The sandbox move and the sidebar (2026-08-26)
+
+**Ward Flow became a genuine sandbox.** It now lives at `/mockups/ward-flow`, behind the
+administrator-only developer gate, following the pattern Caring Contacts and Care Plan already use.
+Nine links out of it into the clinical application were removed — and then a tenth, the logo, which
+pointed at the site root and which no amount of source reading had caught. It was found by looking
+at a screenshot. The header also read "Clinical KB / Source-backed clinical search" on every board
+of a prototype that does no searching and is not source-backed; it now reads "Ward Flow / Synthetic
+patient-flow prototype". `tests/ward-nav.test.ts` guards both, and its forbidden-exit list includes
+`/` for exactly this reason.
+
+**The sidebar was rebuilt to the repository's house pattern.** Before this it had one state:
+`ward-management.module.css` held four media queries, of which two were `prefers-reduced-motion` and
+`forced-colors` and two named `.workspaceGrid` and `.patientWorkspace`. Not one touched the rail, so
+a 390px phone rendered the full 4.5rem desktop icon column — 18% of the viewport — on every screen,
+through 38 test files and 428 passing tests, because nothing was structurally wrong.
+
+It now has the three shapes `ClinicalSidebar.tsx` uses: a drawer below 40rem, the icon rail from
+40rem, and an optional 17rem labelled panel from 64rem whose collapsed state persists per browser.
+Nine of the ten Ward Flow shells are a bare rail-plus-main grid with **no header row at all**, so
+unlike the clinical application there was nowhere for a drawer trigger to live — the sidebar brings
+its own fixed phone bar, which is also the first phone chrome those nine screens have ever had.
+
+The eight mode views moved out of eight hand-written link blocks into `WARD_VIEWS` in `ward-nav.ts`.
+A labelled panel cannot read a rail's icon-only JSX, and copying them would have re-created the
+two-lists-drifting defect (D8/D9) that file exists to prevent.
+
+**Three lessons from that day, recorded because they cost real time:**
+
+1. A phone-contract check passed with the very rule it guarded deleted, because its assertion
+   substring also matched a qualified selector further down the same stylesheet. Found by mutation,
+   not by reading.
+2. Two sessions worked the identical task in one worktree folder: a merge with conflicts, and an
+   edit to a test that broke it in a way only a browser run could find. **One session per folder,
+   and no two sessions aimed at the same pull request.**
+3. `node scripts/run-playwright.mjs` exits `0` when tests fail and when it refuses to run at all.
+   Read the `N passed` line; never the exit code.
+
+## 5d. Phase 5 — designed 2026-08-26, not yet built
+
+Direction settled across one long conversation: Ward Flow becomes a bed-flow hub covering the whole
+pipe, from the community mental health team's decision to admit through to discharge — not the
+ED-to-ward segment it models today.
+
+Sixteen decisions are recorded in `docs/ward-flow-roadmap.md`, which is the durable statement of
+direction and should not be re-litigated without instruction. Phase 5 itself is bed availability and
+nothing else: a lifecycle for a bed release, leave beds, a discharge board, predicted capacity for
+today in four bands ending at 22:00, and a freshness stamp on every screen.
+
+Binding spec: `docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md`.
+Plan: `docs/superpowers/plans/2026-08-26-ward-flow-phase-5-bed-availability.md`.
+Cold-start handover: `docs/ward-flow-phase-5-handover.md`.
+
+**The assumption most likely to be wrong**, recorded as spec D14: predicted, confirmed, blocked,
+released is a software model of how a bed comes free, and no ward clinician has checked it. A bed
+may be confirmed and blocked simultaneously in reality. It is cheap to change while synthetic.
+
 ## 8. Where everything is
 
-| Need                                    | File                                                                         |
-| --------------------------------------- | ---------------------------------------------------------------------------- |
-| Project orientation, Phases 1–3         | `docs/ward-flow-context.md`                                                  |
-| **Phase 3 state and how to resume**     | `docs/ward-flow-phase-3-handover.md`                                         |
-| Phase 3 execution record, every ruling  | `docs/ward-flow-phase-3-ledger.md`                                           |
-| Phase 3 briefs, reports, reviews        | `docs/ward-flow-phase-3-workspace/`                                          |
-| Phase 3 binding authority               | `docs/superpowers/specs/2026-08-19-ward-flow-phase-3-role-screens-design.md` |
-| Phase 3 plan, 12 tasks                  | `docs/superpowers/plans/2026-08-19-ward-flow-phase-3-role-screens.md`        |
-| Phase 1 handoff                         | `docs/ward-flow-phase-handoff.md`                                            |
-| Phase 2 kickoff                         | `docs/ward-flow-phase-2-kickoff.md`                                          |
-| Design decisions across ward management | `docs/ward-management-decisions.md`                                          |
-| Route and mode map                      | `docs/ward-management-mode-map.md`                                           |
+| Need                                    | File                                                                              |
+| --------------------------------------- | --------------------------------------------------------------------------------- |
+| Project orientation, Phases 1–3         | `docs/ward-flow-context.md`                                                       |
+| **Phase 3 state and how to resume**     | `docs/ward-flow-phase-3-handover.md`                                              |
+| Phase 3 execution record, every ruling  | `docs/ward-flow-phase-3-ledger.md`                                                |
+| Phase 3 briefs, reports, reviews        | `docs/ward-flow-phase-3-workspace/`                                               |
+| Phase 3 binding authority               | `docs/superpowers/specs/2026-08-19-ward-flow-phase-3-role-screens-design.md`      |
+| Phase 3 plan, 12 tasks                  | `docs/superpowers/plans/2026-08-19-ward-flow-phase-3-role-screens.md`             |
+| Phase 1 handoff                         | `docs/ward-flow-phase-handoff.md`                                                 |
+| Phase 2 kickoff                         | `docs/ward-flow-phase-2-kickoff.md`                                               |
+| Phase 4 binding authority               | `docs/superpowers/specs/2026-08-25-ward-flow-phase-4-specialist-boards-design.md` |
+| Phase 4 plan, 11 delivered + 1 held     | `docs/superpowers/plans/2026-08-25-ward-flow-phase-4-specialist-boards.md`        |
+| Sandbox and sidebar plan                | `docs/superpowers/plans/2026-08-26-ward-flow-sidebar-house-pattern.md`            |
+| **Direction and settled decisions**     | `docs/ward-flow-roadmap.md`                                                       |
+| **Phase 5 binding authority**           | `docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md`  |
+| **Phase 5 plan, 8 tasks**               | `docs/superpowers/plans/2026-08-26-ward-flow-phase-5-bed-availability.md`         |
+| **Phase 5 cold-start handover**         | `docs/ward-flow-phase-5-handover.md`                                              |
+| Design decisions across ward management | `docs/ward-management-decisions.md`                                               |
+| Route and mode map                      | `docs/ward-management-mode-map.md`                                                |
 
 The live superpowers workspace is `.superpowers/sdd/2026-08-19-ward-flow-phase-3-role-screens/`
 and is **gitignored** — a continuing session appends there, and refreshes
diff --git a/docs/ward-flow-phase-5-handover.md b/docs/ward-flow-phase-5-handover.md
new file mode 100644
index 0000000000..2399237b1b
--- /dev/null
+++ b/docs/ward-flow-phase-5-handover.md
@@ -0,0 +1,160 @@
+# Ward Flow Phase 5 — cold-start handover
+
+**Written 2026-08-26 for a session that has no prior context.** Read this file first, then the two
+it points at. You should not need the conversation that produced it.
+
+---
+
+## 1. Read in this order
+
+| Order | File                                                                                                      | Why                                                                                                    |
+| ----- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
+| 1     | this file                                                                                                 | orientation, traps, and how to start                                                                   |
+| 2     | `docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md`                          | **binding authority.** Fourteen numbered decisions. Where anything disagrees with anything, this wins. |
+| 3     | `docs/superpowers/plans/2026-08-26-ward-flow-phase-5-bed-availability.md`                                 | the eight-task implementation plan, with code                                                          |
+| 4     | `docs/ward-flow-roadmap.md`                                                                               | settled direction and the sixteen product decisions. Do not re-litigate these.                         |
+| 5     | `docs/ward-flow-kickoff` see `docs/ward-flow-phase-5-kickoff-prompt.md` for the paste-ready first message | the prompt this session was started from                                                               |
+| 6     | `docs/ward-flow-complete-ledger.md`                                                                       | the whole project's history, Phases 1 to 5                                                             |
+
+Everything else is optional. `docs/ward-flow-context.md` has the original problem statement if you
+want the why.
+
+## 2. What this is, in three sentences
+
+Ward Flow is a synthetic, offline prototype of a psychiatric bed-flow hub for Western Australia,
+built for a practising psychiatrist in Perth. It coordinates a patient from the community mental
+health team's decision to admit, through the emergency department, to an inpatient bed — and, from
+Phase 5 onward, back out again through discharge. It is **not** clinical decision support, it holds
+**no** real data, and it is reachable only through the administrator-gated developer hub.
+
+## 3. Non-negotiable constraints
+
+These come from the product owner directly and override anything else you read.
+
+- **Never invent a legal figure.** Never cite, paraphrase or infer any figure or requirement from
+  the Mental Health Act — not in code, copy, comment, test or fixture. If one is needed, stop and
+  ask. This is why the statutory clock board is unbuilt.
+- **Synthetic data only.** No name, date of birth, medical record number, address, diagnosis,
+  narrative history or treatment. **Sex is the only permitted patient attribute**, and even that is
+  excluded from bed releases and leave beds by spec D11. Free text counts as data.
+- **Local and offline checks only.** Never run `verify:release`, any `eval:*` script,
+  `check:supabase-project`, `test:live`, or anything touching OpenAI, Supabase, hosted CI or a live
+  database.
+- **Never force-push, `git reset --hard`, or discard either side of a diverged branch.** Never
+  `git checkout --` a file with uncommitted changes without backing it up first.
+- **Never delete a worktree** without being asked. A `git` refusal to remove one means stop, not
+  retry with `--force`.
+- **Do not kill background processes without inventorying them first.**
+
+## 4. Where things stand
+
+**Built and merged into the prototype:** Phases 1–3 (the movement model, the coordinator screen,
+the four role screens), Phase 4 (handover, escalation, patient search, the role switcher, the demo
+clock, capacity columns, bed releases, the change audit, effectiveness numbers).
+
+**Built on 2026-08-26 and pushed to PR #2373 on branch `claude/ward-flow-phase-4-spec`:** the
+sandbox move to `/mockups/ward-flow`, and a complete sidebar rebuild — a phone drawer below 40rem,
+the icon rail from 40rem, an optional 17rem labelled panel from 64rem whose state persists. That PR
+also carries the Phase 5 spec, the plan, the roadmap, and three outstanding-work inbox requests.
+
+**Designed but not built:** Phase 5, which this handover is for.
+
+**Deliberately unbuilt:** the statutory clock board (needs real legal figures from the product
+owner), and redirects for old Ward Flow addresses (the owner chose to leave them broken).
+
+## 5. What Phase 5 is
+
+Bed availability becomes a number you can plan against. Nothing else.
+
+1. A bed release gains a lifecycle: `predicted → confirmed → blocked → released`. Only a ward may
+   move it. A coordinator may look, and may mark a ward's count as refresh-requested — that is the
+   only thing a coordinator can do to a ward's bed data, and it changes no number.
+2. Leave beds become their own type, never merged into availability.
+3. A discharge and egress board, blocked rows first because those are the ones somebody must act on.
+4. Predicted capacity for **today only**, in four bands, with "tonight" ending at **22:00**.
+5. A freshness stamp on every board — today only the capacity board has one.
+
+**The single most important rule in the phase:** nothing predicted, confirmed-but-unreleased, or on
+leave is ever added into "available now". A coordinator must be able to point at one number and say
+"that is a bed I can fill this minute".
+
+**Important:** Phase 4 already built the `BedRelease` type, its fixed blocker list, its ward-only
+flag event, and the ward's flagging panel. Phase 5 **extends** these. Do not build a parallel
+concept.
+
+## 6. How to start
+
+Take a fresh worktree and branch off latest `main` — do **not** continue on
+`claude/ward-flow-phase-4-spec`, which is a different piece of work with its own open PR. The
+repository has a `newtask` skill for exactly this.
+
+Then work the plan with **subagent-driven development**, shaped around this repository's real
+bottleneck:
+
+- **Task 1 is serial and first.** Everything reads its types.
+- **Then fan out:** Tasks 2, 3 and 4 concurrently, then 5, 6 and 7 concurrently.
+- **Each implementer runs only its own focused test file.** The repository allows two focused test
+  leases at a time and serialises everything heavier across every worktree on the machine.
+- **Run the expensive gates once, in Task 8** — full suite, typecheck, lint, format, browser,
+  screenshots. Running them after every task is what makes this slow.
+- **Assemble every commit before the first push.** A push mid-run cancels the checks already running
+  and restarts them.
+
+## 7. Traps that have actually cost time here
+
+Every one of these has bitten this project. They are not hypothetical.
+
+1. **`node scripts/run-playwright.mjs` exits `0` when tests fail.** It also exits `0` when it
+   refuses to run at all. Read the `N passed` line; never the exit code. The same is true of some
+   wrapper scripts.
+2. **`DATABASE_HEAVY_RUN_ADMISSION_BUSY` and `EPERM … owner.json` mean the command did not run.**
+   Another worktree on this machine holds the shared lock. Retry after ~45 seconds; never report it
+   as a pass, and never conclude the check is broken.
+3. **Green tests are not proof the screen is right.** Four separate defects — the prototype wearing
+   the host application's name, a logo linking out of the sandbox, a phone board crushing its own
+   table, a sidebar duplicating its own title — passed every structural check and were found only by
+   looking at a screenshot. **Take screenshots at 390px, 820px and 1440px, and look at them.**
+4. **Mutation-test every new test.** One phone-contract check passed with the exact rule it guarded
+   deleted, because its assertion substring also matched a different selector further down the file.
+5. **Do not run two sessions in the same worktree folder, or two sessions aimed at the same PR.**
+   On 2026-08-26 that produced a merge with conflicts and an edit to a test that broke it in a way
+   only a browser run could find.
+6. **Prettier never converges on the Phase 4 plan file.** Two `--write` passes leave thirty lines
+   differing. If a format guard blocks a push solely on that file, `SKIP_FORMAT_GUARD=1` is the
+   documented route; never `--no-verify` on the push itself.
+7. **Writing files through a shell heredoc has failed repeatedly in this repo.** Use the editor
+   tools, or write a script file and run it.
+8. **Python's default text-mode write turns the whole file CRLF on Windows.** The repository is LF.
+   Open with `newline=""`.
+
+## 8. The first five things to do
+
+1. Read the spec (file 2 above) end to end. It is the binding authority and it is short.
+2. Create a fresh worktree and branch off latest `main`.
+3. Run `npx vitest run tests/ward-*.test.ts tests/ward-*.dom.test.tsx --reporter dot` and record the
+   baseline counts before changing anything, so a later failure can be attributed.
+4. Execute Task 1 of the plan. It is serial, it is the foundation, and its structural privacy test
+   is the one that keeps the whole prototype honest.
+5. Report the counts — not exit codes — before moving on.
+
+## 9. Open questions for the product owner
+
+None blocking. Two worth raising when convenient:
+
+1. **The four-state model is unvalidated.** `predicted → confirmed → blocked → released` is a
+   software model of how a bed comes free, and no ward clinician has checked it. A bed may be
+   confirmed and blocked at once in reality. Recorded as spec D14 and as an outstanding-work item.
+   It is cheap to change while everything is synthetic, and it should be checked before Phase 7
+   builds on top of it.
+2. **Guardianship, financial arrangements and family availability are excluded from the blocker
+   list**, because each describes the person rather than the bed. They are real and common blockers
+   in practice. Adding any of them is a one-line change and a recorded product decision.
+
+## 10. What comes after
+
+Phase 6 is the morning state-of-the-state page — one fixed printable page, five figures, identical
+everywhere. It was promoted ahead of the community work deliberately: it is small, it is built
+entirely from Phase 5's numbers, and it is the artefact that can be put in front of colleagues.
+Finding out whether any of this is right is worth more than the next feature.
+
+Phases 7 to 9 and six further agreed enhancements are listed in `docs/ward-flow-roadmap.md`.
diff --git a/docs/ward-flow-phase-5-kickoff-prompt.md b/docs/ward-flow-phase-5-kickoff-prompt.md
new file mode 100644
index 0000000000..99b1f45afc
--- /dev/null
+++ b/docs/ward-flow-phase-5-kickoff-prompt.md
@@ -0,0 +1,111 @@
+# Ward Flow Phase 5 — kickoff prompt
+
+Paste the block below into a fresh session as its first message. It is deliberately self-sufficient:
+the constraints are stated inline rather than only referenced, so they bind even before the linked
+documents are read.
+
+---
+
+```
+Start Ward Flow Phase 5. This is a fresh session with no prior context — everything you need is
+written down.
+
+READ THESE FIRST, IN THIS ORDER:
+
+1. docs/ward-flow-phase-5-handover.md — cold-start orientation, and the eight traps that have
+   already cost this project real time. Read it before touching anything.
+2. docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md — the BINDING
+   AUTHORITY. Fourteen numbered decisions. Where anything disagrees with anything else, this wins.
+3. docs/superpowers/plans/2026-08-26-ward-flow-phase-5-bed-availability.md — the eight-task
+   implementation plan, with the actual code to write.
+4. docs/ward-flow-roadmap.md — sixteen settled product decisions and the phase order. These were
+   agreed with the product owner. Do not re-litigate them; if one seems wrong, say so and ask.
+5. docs/ward-flow-complete-ledger.md — the project's history, Phases 1 to 5, if you need the why.
+
+WHAT YOU ARE BUILDING
+
+Ward Flow is a synthetic, offline prototype of a psychiatric bed-flow hub for Western Australia,
+built for a practising psychiatrist in Perth. It is not clinical decision support, it holds no real
+data, and it is reachable only through the administrator-gated developer hub at /mockups/ward-flow.
+
+Phase 5 makes bed availability real, and nothing else. A bed release gains a lifecycle
+(predicted → confirmed → blocked → released) that only a ward may move; leave beds become their own
+type; a discharge and egress board is added; capacity becomes five separate figures for today in
+four bands ending at 22:00; and every board gains a freshness stamp.
+
+The single most important rule in the phase: nothing predicted, confirmed-but-unreleased, or on
+leave is ever added into "available now". A coordinator must be able to point at one number and say
+"that is a bed I can fill this minute".
+
+Phase 4 already built the BedRelease type, its fixed blocker list, its ward-only flag event, and the
+ward's flagging panel. Phase 5 EXTENDS these. Do not build a parallel concept.
+
+NON-NEGOTIABLE CONSTRAINTS
+
+- Never invent a legal figure. Never cite, paraphrase or infer any figure or requirement from the
+  Mental Health Act — not in code, copy, comment, test or fixture. If one is needed, stop and ask.
+- Synthetic data only. No name, date of birth, medical record number, address, diagnosis, narrative
+  history or treatment. Sex is the only permitted patient attribute, and even that is excluded from
+  bed releases and leave beds by spec D11. Free text counts as data.
+- Local and offline checks only. Never run verify:release, any eval script, check:supabase-project,
+  test:live, or anything touching OpenAI, Supabase, hosted CI or a live database.
+- Never force-push, git reset --hard, or discard either side of a diverged branch. Never
+  git checkout -- a file with uncommitted changes without backing it up first.
+- Never delete a worktree unasked. A git refusal to remove one means stop, not retry with --force.
+- Do not kill background processes without inventorying them first.
+
+HOW TO WORK
+
+Take a fresh worktree and branch off latest main. Do NOT continue on
+claude/ward-flow-phase-4-spec — that is a different piece of work with its own open PR.
+
+Then use subagent-driven development, shaped around this repository's real bottleneck, which is a
+machine-wide lock on heavyweight checks rather than thinking time:
+
+- Task 1 is serial and first. Every other task reads its types.
+- Then fan out: Tasks 2, 3 and 4 concurrently, then Tasks 5, 6 and 7 concurrently.
+- Each implementer runs ONLY its own focused test file. The repository allows two focused test
+  leases at a time and serialises everything heavier across every worktree on the machine.
+- Run the expensive gates once, in Task 8 — full suite, typecheck, lint, format, browser,
+  screenshots.
+- Assemble every commit before the first push. A push mid-run cancels the checks already running.
+
+THE TRAPS THAT HAVE ACTUALLY BITTEN THIS PROJECT
+
+- node scripts/run-playwright.mjs exits 0 when tests FAIL and when it refuses to run at all. Read
+  the "N passed" line. Never the exit code.
+- DATABASE_HEAVY_RUN_ADMISSION_BUSY, and an EPERM ... owner.json stack trace, both mean the command
+  did not run. Another worktree holds the shared lock. Retry after about 45 seconds. Never report
+  either as a pass.
+- Green tests are not proof the screen is right. Four separate defects this month passed every
+  structural check and were found only by looking at a screenshot. Capture at 390px, 820px and
+  1440px, and actually look.
+- Mutation-test every new test. One check passed with the exact rule it guarded deleted.
+- Writing files through a shell heredoc has failed repeatedly here. Use the editor tools, or write
+  a script file and run it.
+- Python's default text-mode write turns the whole file CRLF on Windows; this repository is LF.
+  Open with newline="".
+
+DO THIS FIRST
+
+1. Read the handover and the spec end to end.
+2. Create the fresh worktree and branch off latest main.
+3. Run the ward baseline and record the counts before changing anything:
+   npx vitest run tests/ward-*.test.ts tests/ward-*.dom.test.tsx --reporter dot
+4. Execute Task 1 of the plan.
+5. Report counts and quoted output lines — never bare exit codes — before moving on.
+
+HOW TO TALK TO ME
+
+I am a psychiatrist, not a software engineer. Lead with the answer. Tell me what to do as numbered
+steps, or say "nothing for you to do". Plain English sentences, no jargon, no file paths unless
+they change my decision. Say plainly when something is broken, risky or uncertain, and say when you
+have not checked something rather than presenting a guess as a fact.
+
+ONE THING WORTH RAISING EARLY
+
+The four bed states — predicted, confirmed, blocked, released — are a software model of how a bed
+comes free. No ward clinician has checked them, a bed may be confirmed and blocked at once in
+reality, and it is recorded as spec D14 and as the assumption most likely to be wrong. Build as
+specified, but flag it to me again when Phase 5 is done and before Phase 6 builds on top of it.
+```
diff --git a/docs/ward-flow-roadmap.md b/docs/ward-flow-roadmap.md
new file mode 100644
index 0000000000..c5e93b35d4
--- /dev/null
+++ b/docs/ward-flow-roadmap.md
@@ -0,0 +1,172 @@
+# Ward Flow roadmap and settled decisions
+
+**What this file is for.** Ward Flow's direction was settled across a long conversation on
+2026-08-26. Conversations end; this file does not. Anything here has been decided by the product
+owner and should not be re-litigated by a later session without being told to. Where a decision
+was a refusal, the reason is recorded with it, because a refusal with no reason attached gets
+reversed by the next person who finds it inconvenient.
+
+Companion documents: `docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md`
+is the binding spec for the next phase. `docs/ward-flow-phase-handoff.md` carries the state of work
+in flight. `docs/ward-management-decisions.md` holds the earlier Phase 1–3 rulings.
+
+---
+
+## What Ward Flow is
+
+A patient bed-flow hub coordinating psychiatric bed flow across Western Australia, from the
+community mental health team's decision to admit, through the emergency department, to the ward —
+and back out again through discharge.
+
+It is a **synthetic, offline prototype**, and its real output is a clear shared understanding of
+what such a system would have to do. It is not clinical decision support and is not connected to any
+real service.
+
+**Primary user: the statewide coordinator.** They are the only role that sees the whole picture, and
+that view is the hub's entire value. But the ward, the emergency department, the community team and
+the transport officer each need a real screen to contribute what only they know — a hub fed by
+nobody is a wall chart.
+
+## Standing constraints
+
+These predate this roadmap and override anything in it:
+
+- **Never invent a legal figure.** No figure or requirement from the Mental Health Act may be cited,
+  paraphrased or inferred. If one is needed, ask the product owner.
+- **Synthetic data only.** No name, date of birth, medical record number, address, diagnosis,
+  narrative history or treatment. **Sex is the only permitted patient attribute.** Free text counts.
+- **Local and offline checks only.** Nothing touching OpenAI, Supabase, hosted CI or a live database.
+- **The prototype is a sandbox.** It is reachable only through the developer hub, and the developer
+  hub is the only link out of it.
+
+## Decisions settled 2026-08-26
+
+**Scope of the hub**
+
+1. The pipeline starts at the **community mental health team's decision to admit**, not at the
+   emergency department. Most patients are formed in the community; the ED is a waypoint, not an
+   origin. This is also the only version that could ever support community-to-ward without an ED.
+2. The pipeline ends at **discharge**. Bed flow is a two-sided equation and only one side was built.
+3. **Any front door** — community team, crisis service, police, ambulance, or transfer from another
+   hospital. Same stages, different entry.
+4. **Predictive community demand is out.** "This team requests a bed today" is concrete. "This team
+   thinks someone might deteriorate" is a different product.
+
+**Patients and privacy**
+
+5. Cohort is expressed as a **requirement on the request** ("this request needs an adolescent bed"),
+   never as a fact stored about a person. The word never attaches to a patient.
+6. Neither a bed release nor a leave bed records **sex**, even though sex is the one permitted
+   attribute and recording it would let the sex-mix column refresh sooner. Phase 4 wrote a
+   structural privacy test against the type's own field set; that test is worth more than the column.
+7. A community referral carries seven operational facts and **no reason for admission**: requesting
+   team, urgency, kind of bed needed, where the person is now, where home is, transport needed, and
+   whether they arrive via an ED or directly.
+
+**Accountability and communication**
+
+8. An **owner is always a role**, never a person — "Royal Perth emergency department", "Bunbury
+   ward". It matches handover, survives shift changes with no reassignment, and keeps staff names
+   out of the system. Accountability comes from the role carrying a visible clock.
+9. **Notifications are in-app plus a simulated outbound log** showing exactly what would be sent,
+   with nothing ever sending. Content limited to the movement identifier and what needs doing.
+10. **Escalation tiers are declared by a human**, never triggered automatically by a threshold. The
+    indicator numbers shown alongside are synthetic and labelled as such. A system that declares a
+    statewide surge on an invented number is a system that gets quoted back at you in a meeting.
+
+**Geography and data**
+
+11. **Distance is travel-time bands plus kilometres** — under an hour, one to three hours, three
+    hours or more, air transport only. "Three hours from home" is a fact a clinician can weigh;
+    "247 km" is not, and "regional" says nothing about whether family can visit.
+12. **Sites stay synthetic.** Real WA town names may be used for geography and distance only. A
+    prototype that quietly asserts wrong facts about a real hospital is unrecoverable; swapping a
+    synthetic site table for a real one later is a day's work.
+
+**Presentation**
+
+13. The morning **state-of-the-state page is fixed and not configurable** — one printable page, the
+    same five figures everywhere. The moment two services can arrange it differently they quote
+    different numbers at each other, which was the one thing the page existed to prevent.
+14. **The network diagram stays.** It orients people and makes the prototype navigable. It earns its
+    place by becoming functional: clickable navigation, line weight by flow, an overlay showing which
+    sites can take the selected patient, roughly geographic layout, a time control, and country
+    sites on it at all.
+15. **Old Ward Flow links stay broken.** Nothing was bookmarked; every redirect kept alive is a route
+    somebody has to maintain forever.
+
+**Still unbuilt, deliberately**
+
+16. The **statutory clock board** is not built and will not be until the product owner supplies the
+    legal figures. Not a version with blanks — blanks invite someone to fill them in from memory.
+
+## Phase order
+
+**Phase 5 — Bed availability becomes real.** Ward discharge flagging and confirmation, the discharge
+and egress board, predicted capacity for today in four bands, a freshness signal on every screen,
+and the coordinator's one permitted action: marking a ward's count as refresh-requested. Nothing
+else. Full spec:
+`docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md`.
+
+Everything below needs trustworthy availability numbers underneath it, which is why this phase has
+no headline screen and still has to come first.
+
+**Phase 6 — The morning page.** Promoted from Phase 8 on 2026-08-26. Built entirely from Phase 5's
+numbers, small, and the artefact that can be put in front of colleagues. Finding out whether any of
+this is right is worth more than the next feature.
+
+**Phase 7 — The front door.** Community referral tracking, intake from crisis services, police,
+ambulance and inter-hospital transfers, cohort and bed-type matching, and the role data-entry
+screens each contributor needs.
+
+**Phase 8 — Distance and the state.** Geography as a cost, the country and remote pathway, air
+transport, closest-suitable-bed, the network diagram rework, and the out-of-area ledger.
+
+**Phase 9 — Daily use and trust.** Waiting-time equity, ownership clocks, escalation tiers, the
+retrospective view, handover continuity, notifications, and the navigation regrouping.
+
+## Additional items agreed 2026-08-26
+
+Each of these was proposed and accepted; none is yet assigned to a phase.
+
+1. **Ward prediction track record.** Show how often each ward's predicted discharges actually
+   happened. It is a ward-level statistic with no patient data in it, and it is the difference
+   between a prediction a coordinator plans against and one they discount. It also gives wards a
+   reason to keep the board accurate that no amount of nagging will.
+2. **"Why not here?" across the whole state.** For one patient, every unit and the single reason it
+   cannot take them. "There are no beds" is not what an escalation conversation needs; a list of
+   specific obstacles is.
+3. **A sixty-second guided tour.** Self-driving: a patient waiting, a coordinator finding a bed, a
+   ward confirming, the board updating. For a prototype whose real output is shared understanding,
+   this is likely the highest value per hour of anything on this page — it means handing someone a
+   link instead of narrating over their shoulder.
+4. **Out-of-area ledger.** How many people are currently in a bed far from home, and for how long.
+   The equity measure with teeth. Needs Phase 8's distance work.
+5. **"Waiting since" at the front of the priority queue.** The queue ranks by urgency, which is
+   right, but length of wait carries the moral weight and is currently secondary.
+6. **Named moments on the demo clock.** "Friday 4pm, everything jammed" is a scenario worth opening
+   in front of colleagues. The scenario switcher exists; this is mostly naming.
+
+## The assumption most likely to be wrong
+
+`predicted → confirmed → blocked → released` is a software model of how a bed comes free. No ward
+clinician has checked it. A bed may be confirmed and blocked at the same time in reality, and
+"predicted" may compress several distinct states a charge nurse would separate.
+
+It is built as specified because a working model beats an unbuilt one and this one is cheap to
+change while everything is synthetic. **Checking it with a ward clinician is the single most
+valuable validation available**, and it should happen before Phase 7 builds more on top of it.
+
+## Working practice
+
+- **One session per worktree folder, and no two sessions aimed at the same pull request.** On
+  2026-08-26 two sessions worked the identical task in one folder: a merge with conflicts, and an
+  edit to a test that broke it in a way only a browser run could find. Roughly forty minutes lost
+  for nothing.
+- Separate branches in separate folders are safe for files, but the heavyweight-check lock is
+  machine-wide, so concurrent sessions still queue behind each other. That is a slowdown, not a
+  hazard.
+- Phase work runs as subagent-driven development shaped around that lock: the data-model change
+  serial and first, then a genuine fan-out across file-disjoint tasks, each agent running only
+  focused tests, with the expensive checks — full suite, lint, format, browser, screenshots — run
+  once at the end rather than after every task.
diff --git a/src/components/ward-management/ward-management-modes.module.css b/src/components/ward-management/ward-management-modes.module.css
index e9bcfebb8b..e5f54b88b1 100644
--- a/src/components/ward-management/ward-management-modes.module.css
+++ b/src/components/ward-management/ward-management-modes.module.css
@@ -64,6 +64,25 @@
   padding: 0 var(--ward-space-20);
 }
 
+/*
+ * The expanded sidebar panel names the prototype at the top of the screen already, so the header
+ * stops saying it a second time six inches to the right. The panel is a preceding sibling of this
+ * header inside the shell grid, which is what makes this expressible in CSS at all — neither
+ * component knows about the other.
+ *
+ * **The 64rem guard is load-bearing, not tidiness.** The panel is MOUNTED whenever the stored
+ * preference is expanded, at every width; below 64rem it is merely `display: none`. Without this
+ * media query the selector still matched that hidden aside on a tablet, so a user who had expanded
+ * the sidebar on a desktop and later opened the same browser at 820px saw the icon rail with the
+ * header brand suppressed — and nothing on screen named the prototype at all. Found in review on
+ * PR #2384; pinned by `tests/ward-sidebar-phone-contract.test.ts`.
+ */
+@media (min-width: 64rem) {
+  :global(aside[aria-label="Ward Flow sidebar"]) ~ .modeHeader .modeBrand {
+    display: none;
+  }
+}
+
 .modeIdentity {
   display: flex;
   min-width: 0;
@@ -854,10 +873,6 @@
     display: none;
   }
 
-  .modeIdentity span:first-child {
-    display: none;
-  }
-
   .pageGrid {
     grid-template-columns: 1fr;
   }
@@ -884,6 +899,10 @@
     padding-top: var(--spacing-ward-phone-bar);
   }
 
+  .modeIdentity .modeBrand {
+    display: none;
+  }
+
   .modeHeader {
     position: sticky;
     top: var(--spacing-ward-phone-bar);
diff --git a/src/components/ward-management/ward-management-modes.tsx b/src/components/ward-management/ward-management-modes.tsx
index 92b4873ba2..27a8b23251 100644
--- a/src/components/ward-management/ward-management-modes.tsx
+++ b/src/components/ward-management/ward-management-modes.tsx
@@ -137,7 +137,10 @@ function ModeHeader({
             does no searching and is not source-backed. Found by looking at a screenshot — every
             measurement run against this codebase missed it, because nothing was structurally
             wrong with it. */}
-        <span>
+        {/* Hidden by CSS whenever the labelled sidebar panel is open, because that panel already
+            carries this exact name and tagline — seen side by side in one eyeline on a
+            screenshot, which is the only place a duplicate like this shows up. */}
+        <span className={styles.modeBrand}>
           <strong>Ward Flow</strong>
           <small>Synthetic patient-flow prototype</small>
         </span>
diff --git a/src/components/ward-management/ward-management-navigation.tsx b/src/components/ward-management/ward-management-navigation.tsx
index e73dcca58a..5feb5ad4ec 100644
--- a/src/components/ward-management/ward-management-navigation.tsx
+++ b/src/components/ward-management/ward-management-navigation.tsx
@@ -11,7 +11,7 @@ import shellStyles from "./ward-management.module.css";
 import sidebarStyles from "./ward-sidebar.module.css";
 import { WardDemoControls } from "./ward-demo-controls";
 import { WardRoleSwitcher } from "./ward-role-switcher";
-import { WardSidebarContent } from "./ward-sidebar-content";
+import { WardSidebarContent, WardSidebarFooter, WardSidebarNav } from "./ward-sidebar-content";
 import { WARD_NAV_ICONS, WARD_VIEW_ICONS } from "./ward-nav-icons";
 import { WARD_DEVELOPER_HUB_HREF, WARD_NAV, WARD_VIEWS, type WardMode, type WardNavItem } from "./ward-nav";
 import { useWardSidebarCollapsed } from "./use-ward-sidebar-collapsed";
@@ -103,8 +103,9 @@ export function ClinicalRail({ activeMode }: { activeMode?: WardMode } = {}) {
       {!collapsed ? (
         <aside className={sidebarStyles.panel} aria-label="Ward Flow sidebar">
           <div className={sidebarStyles.panelScroll}>
-            <WardSidebarContent activeMode={activeMode} onCollapse={() => setCollapsed(true)} />
+            <WardSidebarNav activeMode={activeMode} onCollapse={() => setCollapsed(true)} />
           </div>
+          <WardSidebarFooter />
         </aside>
       ) : null}
 
@@ -163,33 +164,40 @@ function WardIconRail({
         <PanelLeftOpen aria-hidden="true" className={shellStyles.railExpandIcon} />
       </button>
       <div className={shellStyles.railRule} aria-hidden="true" />
-      <WardModeNavigation active={activeMode} />
-      <div className={shellStyles.railRule} aria-hidden="true" />
-      {/*
-       * "Ward Flow role screens" holds the one non-arbitrary role entry point (Officer); the
-       * nested group holds the two that name one arbitrary synthetic instance rather than a
-       * section of the app (D10) and says so in its own aria-label. Coordinator is deliberately
-       * absent from both — it is the "Command" view one group up.
-       */}
-      <div className={shellStyles.railGroup} role="group" aria-label="Ward Flow role screens">
-        {WARD_NAV.filter((item) => item.group === "role" && !item.exampleOnly).map((item) => (
-          <WardNavLink key={item.id} item={item} />
-        ))}
-        <div
-          className={shellStyles.railGroup}
-          role="group"
-          aria-label="Example ward and emergency department — one arbitrary synthetic instance each, not a section of the app"
-        >
-          {WARD_NAV.filter((item) => item.group === "role" && item.exampleOnly).map((item) => (
+      {/* Scrolls, so the pinned bottom block below can never be pushed off the screen. Fourteen
+          icons plus rules overflow a 900px-tall viewport, and this rail's overflow has already
+          cost one silent defect: the bottom block overlapped the last links and swallowed their
+          clicks while every link stayed in the DOM and every unit test stayed green. Same
+          treatment, same reason, as `collapsed-sidebar-scroll-region` in the clinical sidebar. */}
+      <div className={shellStyles.railScroll} data-testid="ward-rail-scroll-region">
+        <WardModeNavigation active={activeMode} />
+        <div className={shellStyles.railRule} aria-hidden="true" />
+        {/*
+         * "Ward Flow role screens" holds the one non-arbitrary role entry point (Officer); the
+         * nested group holds the two that name one arbitrary synthetic instance rather than a
+         * section of the app (D10) and says so in its own aria-label. Coordinator is deliberately
+         * absent from both — it is the "Command" view one group up.
+         */}
+        <div className={shellStyles.railGroup} role="group" aria-label="Ward Flow role screens">
+          {WARD_NAV.filter((item) => item.group === "role" && !item.exampleOnly).map((item) => (
+            <WardNavLink key={item.id} item={item} />
+          ))}
+          <div
+            className={shellStyles.railGroup}
+            role="group"
+            aria-label="Example ward and emergency department — one arbitrary synthetic instance each, not a section of the app"
+          >
+            {WARD_NAV.filter((item) => item.group === "role" && item.exampleOnly).map((item) => (
+              <WardNavLink key={item.id} item={item} />
+            ))}
+          </div>
+        </div>
+        <div className={shellStyles.railRule} aria-hidden="true" />
+        <div className={shellStyles.railGroup} role="group" aria-label="Ward Flow specialist boards">
+          {WARD_NAV.filter((item) => item.group === "board").map((item) => (
             <WardNavLink key={item.id} item={item} />
           ))}
         </div>
-      </div>
-      <div className={shellStyles.railRule} aria-hidden="true" />
-      <div className={shellStyles.railGroup} role="group" aria-label="Ward Flow specialist boards">
-        {WARD_NAV.filter((item) => item.group === "board").map((item) => (
-          <WardNavLink key={item.id} item={item} />
-        ))}
       </div>
       <div className={shellStyles.railBottom}>
         {/* The role switcher is the one control the proof journey (spec section 14) uses to move
diff --git a/src/components/ward-management/ward-management.module.css b/src/components/ward-management/ward-management.module.css
index 680cf43b96..2d78972ed8 100644
--- a/src/components/ward-management/ward-management.module.css
+++ b/src/components/ward-management/ward-management.module.css
@@ -203,6 +203,30 @@
   background: var(--ward-border);
 }
 
+/*
+ * The rail's scrollable middle. Fourteen 3rem icons plus their rules overflow a 900px-tall
+ * viewport, and this rail's overflow is not a theoretical problem: an earlier version pushed
+ * `.railBottom` over the last nav links, which then swallowed their clicks while every link
+ * stayed in the DOM and keyboard-reachable, so the entire unit suite passed and one Chromium
+ * journey timed out. Scrolling here keeps the pinned bottom block reachable at any height.
+ */
+.railScroll {
+  display: flex;
+  width: 100%;
+  min-height: 0;
+  flex: 1;
+  flex-direction: column;
+  align-items: center;
+  gap: var(--ward-space-6);
+  overflow-y: auto;
+  overscroll-behavior: contain;
+  scrollbar-width: none;
+}
+
+.railScroll::-webkit-scrollbar {
+  display: none;
+}
+
 .railNav,
 .railBottom {
   display: grid;
diff --git a/src/components/ward-management/ward-sidebar-content.tsx b/src/components/ward-management/ward-sidebar-content.tsx
index 5d6baa87c6..ee1097f299 100644
--- a/src/components/ward-management/ward-sidebar-content.tsx
+++ b/src/components/ward-management/ward-sidebar-content.tsx
@@ -19,7 +19,26 @@ import styles from "./ward-sidebar.module.css";
  * point: the icon rail, this panel and this drawer all read `ward-nav.ts`, so a destination
  * added in one place appears in all three or in none.
  */
-export function WardSidebarContent({
+export function WardSidebarContent(props: {
+  activeMode?: WardMode;
+  showBrandRow?: boolean;
+  onCollapse?: () => void;
+  onNavigate?: () => void;
+}) {
+  return (
+    <>
+      <WardSidebarNav {...props} />
+      <WardSidebarFooter onNavigate={props.onNavigate} />
+    </>
+  );
+}
+
+/**
+ * The navigation half. Split from the footer so the desktop panel can scroll this and pin that:
+ * on a 900px-tall screen the footer's role switcher and demo clock fell below the fold, which the
+ * icon rail had never let happen because it pinned its own bottom block.
+ */
+export function WardSidebarNav({
   activeMode,
   showBrandRow = true,
   onCollapse,
@@ -88,25 +107,32 @@ export function WardSidebarContent({
         items={WARD_NAV.filter((item) => item.group === "board")}
         onNavigate={onNavigate}
       />
+    </>
+  );
+}
 
-      <div className={styles.footer}>
-        {/* The role switcher and the demo clock are mounted here exactly as the rail mounts them
-            — same components, same behaviour. The clock is not a destination and never navigates;
-            it sits below the rule with every real link above it, as it does in the rail. */}
-        <div className={styles.footerControls}>
-          <WardRoleSwitcher />
-          <WardDemoControls />
-          <span className={styles.guest} aria-label="Guest workspace">
-            G
-          </span>
-        </div>
-        {/* The single way out of the sandbox. */}
-        <Link href={WARD_DEVELOPER_HUB_HREF} className={styles.link} onClick={onNavigate}>
-          <LayoutGrid aria-hidden="true" />
-          <span className={styles.linkLabel}>Back to the developer hub</span>
-        </Link>
+/**
+ * The footer: the two live controls the rail also carries, plus the one way out of the sandbox.
+ * Pinned to the bottom of the desktop panel, scrolled with everything else in the drawer.
+ */
+export function WardSidebarFooter({ onNavigate }: { onNavigate?: () => void }) {
+  return (
+    <div className={styles.footer}>
+      {/* The role switcher and the demo clock are mounted here exactly as the rail mounts them —
+          same components, same behaviour. The clock is not a destination and never navigates. */}
+      <div className={styles.footerControls}>
+        <WardRoleSwitcher />
+        <WardDemoControls />
+        <span className={styles.guest} aria-label="Guest workspace">
+          G
+        </span>
       </div>
-    </>
+      {/* The single way out of the sandbox. */}
+      <Link href={WARD_DEVELOPER_HUB_HREF} className={styles.link} onClick={onNavigate}>
+        <LayoutGrid aria-hidden="true" />
+        <span className={styles.linkLabel}>Back to the developer hub</span>
+      </Link>
+    </div>
   );
 }
 
diff --git a/src/components/ward-management/ward-sidebar.module.css b/src/components/ward-management/ward-sidebar.module.css
index 85e97bf981..814e25168c 100644
--- a/src/components/ward-management/ward-sidebar.module.css
+++ b/src/components/ward-management/ward-sidebar.module.css
@@ -222,6 +222,12 @@
   background: var(--ward-border);
 }
 
+/*
+ * Pinned to the bottom of the panel rather than scrolled with the links above it: on a 900px-tall
+ * screen the role switcher and the demo clock sat below the fold, which is a regression against
+ * the icon rail, where the same two controls have always been pinned. The drawer scrolls the
+ * whole body instead, which is right for a phone.
+ */
 .footer {
   display: grid;
   flex-shrink: 0;
diff --git a/tests/ui-ward-management.spec.ts b/tests/ui-ward-management.spec.ts
index d957cf022e..d27531e0c7 100644
--- a/tests/ui-ward-management.spec.ts
+++ b/tests/ui-ward-management.spec.ts
@@ -174,6 +174,29 @@ test.describe("@mockup Ward Flow command view", () => {
     await expectNoRegionGridOverflow(page);
   });
 
+  test("keeps the header brand visible at tablet width when the remembered panel is hidden", async ({ page }) => {
+    await page.setViewportSize({ width: 820, height: 900 });
+    await page.addInitScript(() => {
+      window.localStorage.setItem("ward-flow-sidebar-collapsed", "0");
+    });
+    await page.goto("/mockups/ward-flow/queue", { waitUntil: "domcontentloaded" });
+
+    const header = page.locator("header").filter({ has: page.getByRole("heading", { name: "Priority queue" }) });
+    const sidebar = page.getByRole("complementary", { name: "Ward Flow sidebar", includeHidden: true });
+    await expect(sidebar).toBeAttached({ timeout: 15_000 });
+    await expect(sidebar).toBeHidden();
+    await expect(header.getByText("Ward Flow", { exact: true })).toBeVisible();
+  });
+
+  test("uses its fixed bar as the sole Ward Flow brand on phone", async ({ page }) => {
+    await page.setViewportSize({ width: 320, height: 820 });
+    await page.goto("/mockups/ward-flow/queue", { waitUntil: "domcontentloaded" });
+
+    const header = page.locator("header").filter({ has: page.getByRole("heading", { name: "Priority queue" }) });
+    await expect(page.getByRole("link", { name: "Ward Flow", exact: true })).toBeVisible({ timeout: 15_000 });
+    await expect(header.getByText("Ward Flow", { exact: true })).toBeHidden();
+  });
+
   test("retains its operating structure in dark, forced-colours, and print modes", async ({ page }) => {
     await page.setViewportSize({ width: 1280, height: 900 });
     await page.emulateMedia({ colorScheme: "dark" });
diff --git a/tests/ward-sidebar-phone-contract.test.ts b/tests/ward-sidebar-phone-contract.test.ts
index 5acfeedfdc..cb02b9c136 100644
--- a/tests/ward-sidebar-phone-contract.test.ts
+++ b/tests/ward-sidebar-phone-contract.test.ts
@@ -80,6 +80,26 @@ describe("Ward Flow sidebar — phone contract", () => {
     expect(missing, `shell(s) whose content would sit under the fixed phone bar: ${missing.join(", ")}`).toEqual([]);
   });
 
+  /**
+   * Found in review, not by any check that existed at the time. The expanded panel is mounted at
+   * every width and only hidden by CSS below 64rem, so a selector that keys off its presence must
+   * be guarded by the same breakpoint — otherwise a tablet user with the expanded preference
+   * stored sees the icon rail AND loses the header brand, leaving nothing on screen naming the
+   * prototype.
+   */
+  it("suppresses the header brand only where the panel is actually visible", () => {
+    const modes = readModule("ward-management-modes.module.css");
+    const rule = ':global(aside[aria-label="Ward Flow sidebar"]) ~ .modeHeader .modeBrand';
+    expect(modes).toContain(rule);
+    const before = modes.slice(0, modes.indexOf(rule));
+    const lastMediaOpen = before.lastIndexOf("@media");
+    expect(lastMediaOpen, "the brand-hiding rule sits outside any media query").toBeGreaterThan(-1);
+    expect(before.slice(lastMediaOpen)).toContain("min-width: 64rem");
+    // Non-vacuity: the guard must not have been satisfied by an unrelated earlier media query that
+    // was already closed before the rule.
+    expect(before.slice(lastMediaOpen).split("}").length).toBeLessThan(4);
+  });
+
   it("pushes each shell's own sticky header below the phone bar rather than under it", () => {
     // The two shells that have a sticky header of their own. Anything else has no header at all,
     // which is why the sidebar brings its own bar.