From 37aef874fe99157b5fbf925110d6e6301a6e37ea Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Wed, 26 Aug 2026 09:01:00 +0800
Subject: [PATCH 01/12] Spec: Phase 5, bed availability becomes real

The design for the phase that makes the capacity figure plannable: a lifecycle for
a bed release, leave beds as a distinct thing from empty beds, a discharge and
egress board, predicted capacity in four bands within today, and a freshness signal
on every screen.

Records eleven decisions, of which three are refusals worth naming:

- Nothing predicted may ever be added into "available now". A coordinator has to be
  able to point at one number and say that is a bed I can fill this minute.
- Releases expected beyond tonight are excluded AND counted as excluded. Silent
  truncation reads as having counted everything.
- Neither a bed release nor a leave bed carries sex, even though sex is the one
  permitted patient attribute and carrying it would let the sex-mix column refresh
  an hour earlier. Phase 4 wrote a structural privacy test against the type's own
  field set; that test is worth more than the column.

Also corrects the record: Phase 4 already built the bed-release concept, its fixed
blocker list, its ward-only flag event and the ward's flagging panel. This phase
extends that rather than starting over, and the spec says which single existing
behaviour it changes - unitCapacity's raw "potential" count.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 ...rd-flow-phase-5-bed-availability-design.md | 255 ++++++++++++++++++
 1 file changed, 255 insertions(+)
 create mode 100644 docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md

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 000000000..8918a4031
--- /dev/null
+++ b/docs/superpowers/specs/2026-08-26-ward-flow-phase-5-bed-availability-design.md
@@ -0,0 +1,255 @@
+# 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.
+
+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** — the rest of today.
+
+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.
+
+---
+
+## 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 four bands are a synthetic convenience.** They are the prototype's choice, not a clinical
+  standard, and the board should not imply otherwise.

From 1608d3e49b7c2abd473ed0d83eb5a276d52cd915 Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Wed, 26 Aug 2026 09:27:48 +0800
Subject: [PATCH 02/12] Spec: four more Phase 5 decisions, and the morning page
 moves to Phase 6

The coordinator gains exactly one thing it may do to a ward's bed data - mark it
refresh requested, which the ward sees on its own screen. Nothing is sent and no
number changes. It is the phone call that says is that still right, modelled as a
mark rather than a message, so the hub is useful before notifications exist and
without acquiring notification's governance weight.

Tonight now ends at 22:00 rather than midnight, because midnight is a calendar
boundary and nobody hands over at one. Recorded as this prototype's choice in one
place, and named as a synthetic convenience rather than a claim about any real
roster.

The seeded scenario opens on its worst case: releases in every state, at least two
blocked, at least one unusable leave bed. A discharge board that opens empty
demonstrates nothing and one that opens all-confirmed demonstrates the wrong thing.

And the four states are recorded as unvalidated. Predicted, confirmed, blocked,
released is a software model of how a bed comes free; a ward charge nurse has not
checked it, and it may be a tidy version of something messier. Built anyway,
because a working model beats an unbuilt one and this one is cheap to change while
it is synthetic - but named as the single most valuable thing to check with a
clinician, and as the assumption most likely to be wrong.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 ...rd-flow-phase-5-bed-availability-design.md | 47 ++++++++++++++++++-
 1 file changed, 46 insertions(+), 1 deletion(-)

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
index 8918a4031..426f09107 100644
--- 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
@@ -14,6 +14,11 @@ The capacity board answers "how many beds exist right now", which is not the que
 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
@@ -121,7 +126,13 @@ figure. Merging it would inflate the one number the whole hub depends on.
 - **Now** — already released.
 - **By midday**
 - **By 1600**
-- **Tonight** — the rest of today.
+- **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
@@ -201,6 +212,38 @@ modelled. Adding sex to a bed release for arithmetic convenience would break the
 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
@@ -251,5 +294,7 @@ guessing more:
   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.

From b280ace7d48a5a6daddcb2adf52a96a7db851876 Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Wed, 26 Aug 2026 09:46:05 +0800
Subject: [PATCH 03/12] Phase 5 plan, the roadmap, a cold-start handover, and
 the project ledger brought current

Four documents so the next session does not have to reconstruct any of this from a
conversation that has ended.

The plan is eight tasks. Task 1 is serial because every other task reads its types;
then two fan-outs of three; then one verification sweep. Each implementer runs only
its own focused test file - the heavyweight lock is machine-wide, so agents that
each run the full suite queue behind one another and lose the parallelism the
fan-out bought. The expensive gates run once, at the end.

The roadmap records sixteen product decisions settled with the owner today, each
with its reason, because a refusal with no reason attached gets reversed by the next
person who finds it inconvenient. It also records the phase order, including the
morning page moving ahead of the community work: it is small, 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.

The handover is written for a session with no context at all, and it leads with the
traps rather than the architecture - eight of them, every one already paid for.
That a Playwright wrapper exits 0 on failure. That a busy lock is not a pass. That
green tests are not proof the screen is right: four defects this month passed every
structural check and were found by looking at a screenshot.

The complete ledger now runs Phases 1 to 5 rather than 1 to 3, and includes the two
Phase 4 figures that were corrected after the fact.

Three outstanding-work inbox requests queued the merge-safe way: Phase 5 itself, the
unvalidated state model, and the six agreed enhancements not yet assigned a phase.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../970bbb8b-4dbe-4e27-97a4-80142db94d7d.json |  14 +
 .../cfa44b9c-3d68-4030-b1e3-3d8f182ca3d4.json |  14 +
 .../ecabc51d-034a-4a68-91cd-280214aac6bf.json |  14 +
 ...8-26-ward-flow-phase-5-bed-availability.md | 865 ++++++++++++++++++
 docs/ward-flow-complete-ledger.md             | 118 ++-
 docs/ward-flow-phase-5-handover.md            | 159 ++++
 docs/ward-flow-roadmap.md                     | 172 ++++
 7 files changed, 1341 insertions(+), 15 deletions(-)
 create mode 100644 docs/outstanding-issues-inbox/970bbb8b-4dbe-4e27-97a4-80142db94d7d.json
 create mode 100644 docs/outstanding-issues-inbox/cfa44b9c-3d68-4030-b1e3-3d8f182ca3d4.json
 create mode 100644 docs/outstanding-issues-inbox/ecabc51d-034a-4a68-91cd-280214aac6bf.json
 create mode 100644 docs/superpowers/plans/2026-08-26-ward-flow-phase-5-bed-availability.md
 create mode 100644 docs/ward-flow-phase-5-handover.md
 create mode 100644 docs/ward-flow-roadmap.md

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 000000000..57974d507
--- /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 000000000..cf667489f
--- /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 000000000..b4b0ddf49
--- /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 000000000..3696d3b35
--- /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/ward-flow-complete-ledger.md b/docs/ward-flow-complete-ledger.md
index 7e0b3cb7d..4c26696e3 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 000000000..fb62a60ff
--- /dev/null
+++ b/docs/ward-flow-phase-5-handover.md
@@ -0,0 +1,159 @@
+# 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-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-roadmap.md b/docs/ward-flow-roadmap.md
new file mode 100644
index 000000000..c5e93b35d
--- /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.

From 6cd6ba816d2eef8a4642529701ed7d7656c09510 Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Wed, 26 Aug 2026 09:50:28 +0800
Subject: [PATCH 04/12] A paste-ready kickoff prompt for the Phase 5 session

Self-sufficient by design: the constraints are stated inline rather than only
referenced, so they bind before the linked documents have been read. A prompt that
only says which files to read is a prompt whose safety rules are optional.

Carries the reading order, what is being built and what was already built in Phase 4
so nobody rebuilds it, the six non-negotiable constraints, the fan-out shape and why
it is shaped that way, the six traps that have actually bitten this project, the
first five actions, how to talk to the owner, and the one assumption worth raising
again before Phase 6 builds on it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 docs/ward-flow-phase-5-handover.md       |  15 +--
 docs/ward-flow-phase-5-kickoff-prompt.md | 111 +++++++++++++++++++++++
 2 files changed, 119 insertions(+), 7 deletions(-)
 create mode 100644 docs/ward-flow-phase-5-kickoff-prompt.md

diff --git a/docs/ward-flow-phase-5-handover.md b/docs/ward-flow-phase-5-handover.md
index fb62a60ff..2399237b1 100644
--- a/docs/ward-flow-phase-5-handover.md
+++ b/docs/ward-flow-phase-5-handover.md
@@ -7,13 +7,14 @@ 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-complete-ledger.md`                                              | the whole project's history, Phases 1 to 5                                                             |
+| 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.
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 000000000..99b1f45af
--- /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.
+```

From b1648b8996cb80e4d1254115ab739a384707c427 Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Wed, 26 Aug 2026 10:41:58 +0800
Subject: [PATCH 05/12] Carry the three sidebar fixes forward, which the squash
 merge left behind

PR #2373 was squash-merged from an earlier point than the branch reached, so three
fixes stayed on the branch while the sidebar rebuild itself landed. Verified against
main by content rather than by commit reachability - after a squash, every commit
looks unmerged, so only the file contents can answer the question.

Missing from main and restored here:

- The mode header repeated "Ward Flow / Synthetic patient-flow prototype" while the
  labelled panel was open, so the name and tagline appeared twice in one eyeline.
  The header keeps it when the rail is collapsed, because then it is the only place
  the prototype is named.
- The panel footer scrolled with the links above it, so on a 900px-tall screen the
  role switcher, the demo clock and the way out of the sandbox fell below the fold -
  a regression against the icon rail, which has always pinned those same controls.
- The rail overflowed a 900px viewport with fourteen icons and their rules. Its
  middle section now scrolls, so the pinned bottom block stays reachable. This rail's
  overflow has already cost one silent defect, where the bottom block overlapped the
  last links and swallowed their clicks while every link stayed in the DOM.

Deliberately NOT carried forward: my restructuring of the rail tap-target journey.
Another session solved the same problem differently in PR #2376 and its version is
on main and green. Two versions of one test is a fight later for no gain.

Typecheck clean over 5447 files. Ward suites 40 files, 445 passed, 0 failed.
Prettier clean on every changed file.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../ward-management-modes.module.css          | 10 +++
 .../ward-management/ward-management-modes.tsx |  5 +-
 .../ward-management-navigation.tsx            | 60 ++++++++++--------
 .../ward-management.module.css                | 24 +++++++
 .../ward-management/ward-sidebar-content.tsx  | 62 +++++++++++++------
 .../ward-management/ward-sidebar.module.css   |  6 ++
 6 files changed, 122 insertions(+), 45 deletions(-)

diff --git a/src/components/ward-management/ward-management-modes.module.css b/src/components/ward-management/ward-management-modes.module.css
index e9bcfebb8..8a51da2a7 100644
--- a/src/components/ward-management/ward-management-modes.module.css
+++ b/src/components/ward-management/ward-management-modes.module.css
@@ -64,6 +64,16 @@
   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.
+ */
+:global(aside[aria-label="Ward Flow sidebar"]) ~ .modeHeader .modeBrand {
+  display: none;
+}
+
 .modeIdentity {
   display: flex;
   min-width: 0;
diff --git a/src/components/ward-management/ward-management-modes.tsx b/src/components/ward-management/ward-management-modes.tsx
index 92b4873ba..27a8b2325 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 e73dcca58..5feb5ad4e 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 680cf43b9..2d78972ed 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 5d6baa87c..ee1097f29 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 85e97bf98..814e25168 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;

From d7f91aa0ff96760be4040fcdb4169940aedef4b2 Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Wed, 26 Aug 2026 10:59:38 +0800
Subject: [PATCH 06/12] Merge main, and regenerate the outstanding-issues
 snapshot the three new requests moved

CI failed on one check: the committed snapshot of the outstanding-work ledger said
7 pending requests where the ledger had 10. Three of those are this branch's own -
Phase 5, the unvalidated state model, and the six unassigned enhancements - and
three more arrived on main while this PR was open.

Regenerated after merging main rather than before, because the count CI checks is
the count on the merge result, not on either side alone. Regenerating against the
branch alone gave 7 and would have failed again for the same reason.

check:outstanding-issues now reports in step at 91 open, 10 pending.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 data/outstanding-issues-snapshot.json | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/data/outstanding-issues-snapshot.json b/data/outstanding-issues-snapshot.json
index 7e579749e..7b3712365 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"
     }
   ]
 }

From 9d2244422ffcd862573f3b77e16b5e3bfd745738 Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Wed, 26 Aug 2026 11:01:10 +0800
Subject: [PATCH 07/12] test(ward-flow): cover header brand at tablet width

---
 tests/ui-ward-management.spec.ts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/tests/ui-ward-management.spec.ts b/tests/ui-ward-management.spec.ts
index d957cf022..1888e84d0 100644
--- a/tests/ui-ward-management.spec.ts
+++ b/tests/ui-ward-management.spec.ts
@@ -174,6 +174,18 @@ 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" }) });
+    await expect(header.getByText("Ward Flow", { exact: true })).toBeVisible({ timeout: 15_000 });
+    await expect(page.getByRole("complementary", { name: "Ward Flow sidebar" })).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" });

From c19ef127e771fda382c2b5309e0fd1f6c36ed8b6 Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Wed, 26 Aug 2026 11:06:59 +0800
Subject: [PATCH 08/12] fix(ward-flow): retain header brand below desktop

---
 .../ward-management-modes.module.css               | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/src/components/ward-management/ward-management-modes.module.css b/src/components/ward-management/ward-management-modes.module.css
index 8a51da2a7..3a618078c 100644
--- a/src/components/ward-management/ward-management-modes.module.css
+++ b/src/components/ward-management/ward-management-modes.module.css
@@ -66,12 +66,13 @@
 
 /*
  * 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.
+ * stops saying it a second time six inches to the right. Restrict this to desktop: the panel stays
+ * mounted below 64rem to retain the user's preference, but is hidden while the icon rail is shown.
  */
-:global(aside[aria-label="Ward Flow sidebar"]) ~ .modeHeader .modeBrand {
-  display: none;
+@media (min-width: 64rem) {
+  :global(aside[aria-label="Ward Flow sidebar"]) ~ .modeHeader .modeBrand {
+    display: none;
+  }
 }
 
 .modeIdentity {
@@ -864,9 +865,6 @@
     display: none;
   }
 
-  .modeIdentity span:first-child {
-    display: none;
-  }
 
   .pageGrid {
     grid-template-columns: 1fr;

From f6b399fc8ceda507406803d661f06212f4584591 Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Wed, 26 Aug 2026 11:11:05 +0800
Subject: [PATCH 09/12] test(ward-flow): cover responsive sidebar branding

---
 tests/ui-ward-management.spec.ts | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/tests/ui-ward-management.spec.ts b/tests/ui-ward-management.spec.ts
index 1888e84d0..d27531e0c 100644
--- a/tests/ui-ward-management.spec.ts
+++ b/tests/ui-ward-management.spec.ts
@@ -182,8 +182,19 @@ test.describe("@mockup Ward Flow command view", () => {
     await page.goto("/mockups/ward-flow/queue", { waitUntil: "domcontentloaded" });
 
     const header = page.locator("header").filter({ has: page.getByRole("heading", { name: "Priority queue" }) });
-    await expect(header.getByText("Ward Flow", { exact: true })).toBeVisible({ timeout: 15_000 });
-    await expect(page.getByRole("complementary", { name: "Ward Flow sidebar" })).toBeHidden();
+    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 }) => {

From e9447cd2e0acd0e00264d6f6208a9ebc937e6df0 Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Wed, 26 Aug 2026 11:11:15 +0800
Subject: [PATCH 10/12] fix(ward-flow): preserve responsive brand hierarchy

---
 .../ward-management/ward-management-modes.module.css         | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/components/ward-management/ward-management-modes.module.css b/src/components/ward-management/ward-management-modes.module.css
index 3a618078c..19ff3d719 100644
--- a/src/components/ward-management/ward-management-modes.module.css
+++ b/src/components/ward-management/ward-management-modes.module.css
@@ -865,7 +865,6 @@
     display: none;
   }
 
-
   .pageGrid {
     grid-template-columns: 1fr;
   }
@@ -892,6 +891,10 @@
     padding-top: var(--spacing-ward-phone-bar);
   }
 
+  .modeIdentity .modeBrand {
+    display: none;
+  }
+
   .modeHeader {
     position: sticky;
     top: var(--spacing-ward-phone-bar);

From e919ff44800b465ad0de3dcbd1ad60056809d8c5 Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Wed, 26 Aug 2026 11:16:47 +0800
Subject: [PATCH 11/12] Hide the header brand only where the panel that
 replaces it is actually visible

Found in review by the Codex connector on PR #2384, and it is a real defect that no
check here could have caught.

The expanded sidebar panel is MOUNTED whenever the stored preference is expanded, at
every width - below 64rem it is merely display:none. The rule that stops the header
repeating the prototype's name keys off that panel being a preceding sibling, so it
matched the hidden aside too. A user who expanded the sidebar on a desktop and later
opened the same browser at a tablet width got the icon rail with the header brand
suppressed, and nothing on screen named the prototype at all.

The rule is now inside the same 64rem media query that makes the panel visible, so
the header keeps the name at exactly the widths where the panel does not show it.

tests/ward-sidebar-phone-contract.test.ts pins it, and pins it non-vacuously: the
assertion walks back from the rule to the nearest enclosing @media and requires that
block to be the 64rem one, rather than merely finding the string somewhere in the
file. Mutated the breakpoint to 640rem and watched it fail; reverted and watched it
pass. Ward suites 40 files, 446 passed, 0 failed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 .../ward-management-modes.module.css          | 13 ++++++++++--
 tests/ward-sidebar-phone-contract.test.ts     | 20 +++++++++++++++++++
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/src/components/ward-management/ward-management-modes.module.css b/src/components/ward-management/ward-management-modes.module.css
index 8a51da2a7..38319d8c1 100644
--- a/src/components/ward-management/ward-management-modes.module.css
+++ b/src/components/ward-management/ward-management-modes.module.css
@@ -69,9 +69,18 @@
  * 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`.
  */
-:global(aside[aria-label="Ward Flow sidebar"]) ~ .modeHeader .modeBrand {
-  display: none;
+@media (min-width: 64rem) {
+  :global(aside[aria-label="Ward Flow sidebar"]) ~ .modeHeader .modeBrand {
+    display: none;
+  }
 }
 
 .modeIdentity {
diff --git a/tests/ward-sidebar-phone-contract.test.ts b/tests/ward-sidebar-phone-contract.test.ts
index 5acfeedfd..cb02b9c13 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.

From 603c77043fde8774ad24d65efddb6dccbab8533a Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Wed, 26 Aug 2026 11:33:03 +0800
Subject: [PATCH 12/12] Regenerate the repo-awareness snapshot the five new
 documents moved

Third generated file of the same species this PR has had to correct, and the last
one: ran every check:*-snapshot script plus npm run docs:update afterwards, so a
fourth round cannot be waiting.

The snapshot indexes the repository's documentation, and this PR adds five documents
- the Phase 5 spec, plan, roadmap, handover and kickoff prompt. Now in step at 192
pages, 441 documents, 2616 reviews.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 data/repo-awareness-snapshot.json | 33 +++++++++++++++++++++++++++----
 1 file changed, 29 insertions(+), 4 deletions(-)

diff --git a/data/repo-awareness-snapshot.json b/data/repo-awareness-snapshot.json
index 9429e9219..1ba2f0447 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": "c391de340e5946a35d5c7d9bf580ebe019e90c31",
-    "committed_at": "2026-08-26T00:26:15+00: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
     }
   },