feat(ui): shutdown planning page (ADR 0019)

Turns a library runbook into a planned outage for a real project, system
and window -- the office work that happens days before anyone stands in a
trench. Execution is task 130 and is deliberately a separate view: the
two happen at different times, by different people, and only one of them
is done wearing gloves at 2 AM. This page requires a sign-in and NEVER
writes a shutdown_step_events record; if it could, that split would
already have collapsed.

Instantiating copies the template's steps into shutdown_steps, which is
what makes a plan job-specific and editable without touching the library.
Order matters in that copy: shutdown_steps.responsible_role is a relation
while the template names roles by text key, so the project's
shutdown_roles are created from shutdown_template_roles FIRST and the
steps bound to them. Copying steps first would silently lose which role
each wanted -- the instance side has no key to fall back on. Titles come
from the library; the planner fills in contact name and phone, which is
the entire point of the registry, flagged by a banner until they do.

The schedule is derived at render from planned_window_start +
planned_offset_min and never stored: moving the window moves every window
step with it and writes no step row at all (asserted, not assumed). Both
offset forms stay separated -- minutes for window steps, labels for
pre/post -- and neither is ever synthesized from the other. Reordering
swaps seq through a parked value, because the unique (shutdown, seq)
index makes a direct two-row swap collide. No status, progress or
current_step column anywhere.

Migration U adds the schema's first and only non-admin delete rule:

  shutdown_steps.deleteRule =
    @request.auth.id != "" && shutdown_step_events_via_step.id = ""

Removing a step is required by the task ("a real tie-in is never exactly
the generic runbook") but every collection shipped deleteRule null. The
line this draws is draft vs. record. A shutdown step is the plan someone
is still writing, already freely editable for that reason; the
evidentiary weight lives in shutdown_step_events, which stays
append-only and superuser-only-delete. The back-relation guard means a
step stops being deletable the instant its first event lands, so the
draft-to-record transition derives itself with no status column.
`shutdowns` is excluded: deleting one would cascade its steps and orphan
every event for that night at once.

docs/API.md gains all eight shutdown collections and its count is
corrected from twenty-four to thirty-two -- it was missed when the module
landed because it spells the number out.

smoke test 122 -> 124 assertions, green; browser suite 7/7.

Author: mds08011

ARCHITECTURE.md

@@ -486,6 +486,26 @@ re-imports are safe.
   A pure presentation join: no schema, every cell derived at render from
   records other pages already write. This is the free deliverable; the
   compiled, hyperlinked PDF binder is the paid sidecar (ADR 0003).
+- **Shutdown planning (`shutdown_plan.html`, ADR 0019)** turns a library
+  runbook into a planned outage. Two modes off the query string: `?project=`
+  lists a job's shutdowns and creates one; `?shutdown=` is the editable plan.
+  Instantiating **copies** the template's steps into `shutdown_steps`, which is
+  what makes the plan job-specific and editable without touching the library.
+  **Order matters in that copy**: `shutdown_steps.responsible_role` is a
+  relation while the template names roles by text key, so the project's
+  `shutdown_roles` are created from `shutdown_template_roles` *first* and the
+  steps bound to them — copying steps first would silently lose which role each
+  wanted, since the instance side has no key to fall back on. The planner then
+  fills in contact name and phone, which is the whole point of the registry.
+  The **schedule is derived at render** from `planned_window_start` +
+  `planned_offset_min` and never stored: move the window and every window step
+  moves with it with no other write. Reordering swaps `seq` through a parked
+  value, because the unique `(shutdown, seq)` index makes a direct two-row swap
+  collide. Removal is refused server-side once a step has events (migration U).
+  The whole page requires auth — the deliberate opposite of the accountless
+  execution view — and it **never writes a `shutdown_step_events` record**: if
+  the planning page could log a step, the planning/execution split would
+  already have collapsed. Hold points are marked and gate nothing.
 - **Punch list (`punchlist.html`)** answers the second of the three questions
   as a listing rather than a counter. `system.html` and `project.html` show
   open A/B/C **counts**; this is the report behind them — every item grouped

docs/API.md

@@ -30,7 +30,7 @@ REST behavior is a breaking change to this contract.
 
 ## Contract collections
 
-The committed schema has twenty-four application collections. The original
+The committed schema has thirty-two application collections. The original
 sixteen are the published v1 set; rows marked **delta** are implemented but
 await a contract decision. `public` means no user token, `auth` means an
 ordinary authenticated user, and `admin-only` means no ordinary record-rule
@@ -62,14 +62,33 @@ operation. Shape-specific create rules still apply in addition to auth.
 | `service_visits` | **delta; ADR 0017** | public | public, tag XOR system + same-project rule | **never** | **never** |
 | `turnover_packages` | **delta; ADR 0010** | public | build route only (createRule `null`) | **never** | **never** |
 | `signatures` | **delta; ADR 0010** | public | auth | **never** | **never** |
+| `shutdown_templates` | **delta; ADR 0019** | public | auth | auth | admin-only |
+| `shutdown_template_steps` | **delta; ADR 0019** | public | auth | auth | admin-only |
+| `shutdown_template_roles` | **delta; ADR 0019** | public | auth | auth | admin-only |
+| `shutdown_contingencies` | **delta; ADR 0019** | public | auth | auth | admin-only |
+| `shutdown_roles` | **delta; ADR 0019** | public | auth | auth | admin-only |
+| `shutdowns` | **delta; ADR 0019** | public | auth | auth | admin-only |
+| `shutdown_steps` | **delta; ADR 0019** | public | auth | auth | **auth, only while unexecuted** |
+| `shutdown_step_events` | **delta; ADR 0019** | public | public, event shape rule | **never** | **never** |
 
 `segments` was created after the auth migration and had briefly kept public
 create/update rules; migration `1789000033` (ADR 0011) closed that gap, so its
 create/update now require auth like `tags`, with reads public. No collection
 carries a public write rule except the deliberate accountless field paths
 (`checks`/`check_items`/`punch_items` create, `test_equipment` create, the
-`loto_events` and `service_visits` shape-ruled creates, and the parent-scoped
-`attachments` create).
+`loto_events`, `service_visits` and `shutdown_step_events` shape-ruled creates,
+and the parent-scoped `attachments` create).
+
+**`shutdown_steps` carries the schema's one non-admin delete** (migration
+`1789000037`, ADR 0019). Its rule is
+`@request.auth.id != "" && shutdown_step_events_via_step.id = ""` — a signed-in
+planner may remove a plan line that has no events against it, and may not touch
+one that has. A shutdown step is a DRAFT the planner is still writing; it stops
+being a draft the moment the first event lands, and the back-relation is what
+detects that with no status column. The evidence itself
+(`shutdown_step_events`) remains append-only and superuser-only-delete, as does
+`shutdowns` — deleting an outage would cascade its steps and orphan every event
+for that night at once.
 
 Field-level shapes are defined by the migrations in `pb_migrations/` and
 explained in [ARCHITECTURE.md](../ARCHITECTURE.md). Load-bearing semantics

docs/adr/0019-shutdown-runbook-execution.md

@@ -43,6 +43,23 @@
 > are named by any step; `standby_crew` and `emergency` exist to be phoned. This
 > takes the module to **eight** collections and the schema to **32**.
 
+> **Amendment (2026-09-07, task `120`) — a planner may delete an UNEXECUTED
+> step.** Task 120 requires removing steps ("a real tie-in is never exactly the
+> generic runbook"), but every collection shipped `deleteRule: null` and
+> `docs/API.md` publishes admin-only deletes as a contract property. Maintainer
+> ruling: migration U sets
+> `shutdown_steps.deleteRule = '@request.auth.id != "" && shutdown_step_events_via_step.id = ""'`
+> — the schema's first and only non-admin delete.
+>
+> The line it draws is draft vs. record. A `shutdown_steps` row is the plan
+> someone is still writing, already freely editable for that reason; the
+> evidentiary weight lives in `shutdown_step_events`, which stays append-only
+> and superuser-only-delete. The back-relation guard means a step stops being
+> deletable the instant its first event lands — the draft/record transition
+> derives itself, with no status column (constraint #4). `shutdowns` itself is
+> NOT included: deleting one would cascade its steps and orphan every event for
+> that night at once.
+
 **Design only — no migration, no UI in this ADR** (task
 [`080`](../tasks/080-phase4-shutdown-runbook-design-adr.md)). The build tasks are
 written after this is Accepted, per the roadmap-maintenance workflow in

docs/tasks/120-shutdown-planning-ui.md

@@ -1,6 +1,7 @@
 # 120 — Shutdown planning UI: instantiate a runbook into a real outage
 
-Status: TODO
+Status: DONE (2026-09-07 — `pb_public/shutdown_plan.html` + migration U for the
+delete gap; smoke test 122 → 124 assertions, green)
 Milestone: M2 Shutdown Runbooks + Punch List (v0.10.0)
 Depends on: 110
 
@@ -46,21 +47,44 @@ if a genuinely new component is needed.
 
 ## Acceptance criteria
 
-- [ ] From a seeded database, a signed-in user can create a shutdown from the
+- [x] From a seeded database, a signed-in user can create a shutdown from the
       tie-in template against a project + system, and 22 `shutdown_steps` are
       created with their groups, offsets and hold points intact.
-- [ ] Missing `shutdown_roles` can be created inline; the shutdown's steps then
+- [x] Missing `shutdown_roles` can be created inline; the shutdown's steps then
       resolve to real role records with contact details.
-- [ ] A step can be bound to a project tag; an unmatched hint warns and does not
+- [x] A step can be bound to a project tag; an unmatched hint warns and does not
       block saving.
-- [ ] Steps can be added, removed, reordered and edited **before** execution,
+- [x] Steps can be added, removed, reordered and edited **before** execution,
       and the page never writes a `shutdown_step_events` record.
-- [ ] Wall-clock times are derived at render — confirmed by changing
+- [x] Wall-clock times are derived at render — confirmed by changing
       `planned_window_start` and seeing every window step's time move with no
       other write.
-- [ ] An unauthenticated visitor cannot create or edit; the page says so rather
+- [x] An unauthenticated visitor cannot create or edit; the page says so rather
       than failing silently.
-- [ ] Page JS stays within the ~50 KB budget; no new library; no build step.
+- [x] Page JS stays within the ~50 KB budget; no new library; no build step.
+
+## Execution notes (2026-09-07)
+
+- **Spec item 4 needed a schema change.** Every collection shipped
+  `deleteRule: null`, so "remove a step" was impossible as written. Raised, and
+  resolved by maintainer ruling: migration U, a guarded rule that permits the
+  delete only while the step has no events. ADR 0019 carries the amendment.
+- **Roles are created before steps, not offered after.** `shutdown_steps` holds
+  `responsible_role` as a relation and has no text-key fallback, so a step
+  copied before its role record existed would lose which role it wanted. The
+  page therefore creates the project's roles from the template's role table
+  (titles prefilled, contacts blank) and then binds the steps; the planner
+  fills in contacts on the plan page, flagged by a banner. This satisfies spec
+  item 2's intent — the contact details are the point — without a schema change.
+- **Two bugs the render check caught that the API tests could not**: the page
+  called a `lcAuth.authFetch()` helper that does not exist in this codebase
+  (rendered a blank shell), and sorted systems by `sequence` when the field is
+  `startup_sequence` (400, empty picker). Both fixed.
+
+**Coverage gap worth a future task:** `scripts/browser_test.sh` covers only the
+accountless field path, so no office page has render coverage. This task shipped
+an empty shell and a 400 that only a throwaway headless check caught. A small
+office-path browser suite would have caught both automatically.
 
 ## Guardrails
 

pb_migrations/1789000037_migration_u_shutdown_step_delete.js

@@ -0,0 +1,51 @@
+/// <reference path="../pb_data/types.d.ts" />
+//
+// Migration U — let a planner delete an UNEXECUTED shutdown step (ADR 0019,
+// task 120). This is the first non-admin delete rule in the schema, so it is
+// worth being explicit about why it is not a hole.
+//
+// THE PROBLEM. Task 120 requires a planner to remove steps: "a real tie-in is
+// never exactly the generic runbook." Every collection in LoopCheck ships
+// `deleteRule: null` (superuser only) and docs/API.md publishes that as a
+// contract property, so as built there was no way to do it.
+//
+// WHY THIS IS SAFE, and why it is not the same question as the ledgers.
+// `shutdown_steps` is a DRAFT, not evidence. It is the plan a planner is still
+// writing days before the outage, and ADR 0019 already made it editable for
+// exactly that reason — a row you may freely reword, reorder and re-offset is
+// not one whose deletion needs protecting. What carries the evidentiary weight
+// is `shutdown_step_events`, which stays append-only AND superuser-only-delete,
+// untouched here. Nothing about the record of what actually happened changes.
+//
+// THE GUARD. The rule is not a bare auth check. A step that has ANY event
+// against it has been executed — started, held, completed, whatever — and is no
+// longer a draft; deleting it would strand real events pointing at a step that
+// no longer exists. So the back-relation must be empty:
+//
+//   @request.auth.id != "" && shutdown_step_events_via_step.id = ""
+//
+// which means "signed in, AND nothing has happened to this step yet". The
+// transition from draft to record therefore happens by itself, at the moment
+// the first event lands, with no status column and nothing to remember
+// (constraint #4). Verified behaviour: an unexecuted step deletes for a
+// signed-in planner (204); a step with one event is refused for that same
+// planner (404); an anonymous delete is refused (404).
+//
+// Note the events' own `step` relation stays cascadeDelete:false, and events
+// carry `frozen_description` — so even in the superuser case where a step with
+// events IS force-removed, the ledger stays readable on its own terms.
+//
+// NOT extended to `shutdowns` itself, deliberately: deleting a whole shutdown
+// would cascade its steps (cascadeDelete:true) and orphan every event for the
+// outage at once. That stays superuser-only, where it belongs.
+
+migrate((app) => {
+  const steps = app.findCollectionByNameOrId("shutdown_steps");
+  steps.deleteRule =
+    '@request.auth.id != "" && shutdown_step_events_via_step.id = ""';
+  app.save(steps);
+}, (app) => {
+  const steps = app.findCollectionByNameOrId("shutdown_steps");
+  steps.deleteRule = null; // back to superuser-only
+  app.save(steps);
+});

pb_public/project.html

@@ -111,6 +111,15 @@ <h2 class="section">Safety</h2>
         <div class="sub">Every active lock, grouped by system, oldest first — visibility only, never authority</div>
       </a>
 
+      <!-- Planned outages (ADR 0019). Planning is office work and the page
+           requires a sign-in; executing a shutdown is a separate, accountless
+           view (task 130) reached from the shutdown itself. -->
+      <h2 class="section">Shutdowns</h2>
+      <a class="card" :href="'/shutdown_plan.html?project=' + project.id">
+        <div class="title">Shutdown planning</div>
+        <div class="sub">Turn a runbook into a planned outage — steps, roles, hold points, derived window times</div>
+      </a>
+
       <!-- Service cutover (ADR 0006) — only shown when the job has service
            connections, so plant-only projects never see it. -->
       <template x-if="hasServices">