fix(prm): make the dashboard regen unconditional, not a third bullet

The regen landed as leg 3 of a sub-step whose first two legs are judgement
calls, which reads as "do this if the sweep found something". It is the opposite:
`lifecycle.py record` changes what the page shows all by itself, so the ordinary
close-out — clean sweep, no sibling retired — is exactly the one that still has
to re-render.

- Leg 3 is now stated as a command with no condition, ahead of the three legs,
  with both verbs spelled out (`intake --apply dashboard`, then
  `intake dashboard --check` for the confirmation).
- Verified and documented that re-rendering an already-current tree is a no-op:
  `--apply` rewrites both files byte-identically and `git status` stays clean.
  So there is no judgement to make about whether it is needed — the cheap
  mistake is the redundant render, not the stale page.
- Added the leg's own check: `git show --stat HEAD` must name dashboard.md and
  dashboard.html beside the record, or leg 3 did not happen. The ledger's
  dashboard line is a claim that has to be backed.
- Closed the loophole in Notes. "A task with no issue/prompt/worktree skips
  those sub-steps" does not extend to the regen — that is skippable only where
  the close-out wrote nothing to Mind at all.
- reference.md notes both invocation paths (direct `_intake.py` and the
  `pyauto-brain` router), since the environment decides which resolves.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011QFJaycmUfaEhR4XoZajy9

Author: claude

skills/prm/prm.md

@@ -139,7 +139,14 @@ step 6. Order is forced by the tooling, so do not reorder:
    is released; it is finished when `dashboard.md` stops offering this work.
    `dashboard_refresh.yml` self-heals a stale *render*, never a stale *prompt*,
    so this leg belongs to `/prm` and to nothing else — skipping it is how
-   shipped and half-shipped tasks accumulate on the page:
+   shipped and half-shipped tasks accumulate on the page.
+
+   Legs 1 and 2 are judgement and may find nothing. **Leg 3 is a command, and it
+   runs on every close-out that touched Mind at all** — including the ordinary
+   one where the sweep is clean and no sibling is retired. Moving a prompt
+   `active/` → `complete/` changes the page by itself; a close-out that recorded
+   the task and did not re-render has left the page wrong. There is no "nothing
+   changed" exit from leg 3, only a `--check` that says the render is current.
 
    1. **Sweep what this task is named in.** Grep the slug and the prompt
       filename across `draft/`, `active/`, `epics.md` and the registry files.
@@ -156,15 +163,25 @@ step 6. Order is forced by the tooling, so do not reorder:
       `/prm` authorization. One that merely *looks* alike gets a ledger line
       naming it and the `/intake reconcile` door; never retire on resemblance,
       and never turn this sweep into a second question (step 6 owns the only one).
-   3. **Regenerate.** `pyauto-brain intake --apply dashboard` — never hand-edit
-      `dashboard.md` / `dashboard.html`. Commit the render **with** the record,
-      in one commit: the workflow's heal commit is made with `GITHUB_TOKEN`,
-      which triggers no other workflow and has to re-dispatch
-      `pages_dashboard.yml` by hand, so a self-healed page reaches Pages later
-      than a correctly-committed one — and heals nothing you retired in 1 and 2.
+   3. **Regenerate — always.** Two commands, in this order, no condition on
+      either:
+
+      ```bash
+      pyauto-brain intake --apply dashboard     # writes dashboard.md + dashboard.html
+      pyauto-brain intake dashboard --check     # must print "…are current"
+      ```
+
+      Never hand-edit `dashboard.md` / `dashboard.html`. Commit the render
+      **with** the record, in one commit: the workflow's heal commit is made
+      with `GITHUB_TOKEN`, which triggers no other workflow and has to
+      re-dispatch `pages_dashboard.yml` by hand, so a self-healed page reaches
+      Pages later than a correctly-committed one — and heals nothing you retired
+      in 1 and 2.
 
    Then `lifecycle.py check` and push Mind — on `main`, and note that
-   `prompt_sync_push` stages `-A`, so check for unrelated work first.
+   `prompt_sync_push` stages `-A`, so check for unrelated work first. The push
+   is not the end of the leg: `git show --stat HEAD` must name `dashboard.md`
+   and `dashboard.html` alongside the record, or leg 3 did not happen.
 5. **Worktree** — `worktree_remove <task>` (source `bin/worktree.sh`, `PYAUTO_MAIN`
    set), never `rm -rf`. It refuses on a dirty repo and on a claim still
    registered in `active.md` — which is exactly why step 3 comes first.
@@ -178,7 +195,8 @@ step 6. Order is forced by the tooling, so do not reorder:
    released, **dashboard regenerated** (plus any sibling prompt retired, and any
    suspect left standing with its `/intake reconcile` prefix), worktree removed,
    branches deleted, and anything skipped. Branches are simply absent from the
-   ledger where sub-step 6 did not apply.
+   ledger where sub-step 6 did not apply. The dashboard line is not optional
+   prose: if you cannot write it, leg 4.3 did not run — go back and run it.
 
 **Remote (mobile/codex):** sub-steps 1 and 2 run over `gh`/`git ls-remote` as
 usual. Mind (3) works if PyAutoMind is checked out; otherwise say the record is
@@ -212,4 +230,8 @@ Stop and report instead of pressing on when:
 - Under a `--auto` workflow run, merge stays human: `/prm` is a human-typed door
   and is never invoked by the autonomous queue.
 - A task with no issue, no Mind prompt, or no worktree (a direct wiring change,
-  say) simply skips those sub-steps and says so — it is not an error.
+  say) simply skips those sub-steps and says so — it is not an error. That
+  licence does **not** extend to the dashboard regen: it is skippable only where
+  the close-out wrote nothing to Mind at all. Re-rendering an already-current
+  tree is a no-op that leaves `git status` clean, so when in doubt, run it —
+  the cheap mistake is the redundant render, not the stale page.

skills/prm/reference.md

@@ -230,14 +230,24 @@ Mind script importing a Brain module inverts the organ boundary — which is why
 `dashboard_refresh.yml` checks out both repos to do it. So the render stays a
 step someone has to take, and `/prm` is the door that takes it.
 
-**Regenerate, and commit the render with the record:**
+**Regenerate, and commit the render with the record.** Unconditional — the
+sweep and the reconcile above may both come back empty, this does not:
+`lifecycle.py record` alone changes what the page shows.
 
 ```bash
 python3 "$BRAIN" --mind . --apply dashboard      # writes dashboard.md + dashboard.html
 python3 "$BRAIN" --mind . dashboard --check      # "…are current"; exit 1 = drift
 python3 scripts/lifecycle.py check
 ```
 
+Or through the router, identically — `pyauto-brain intake --apply dashboard` and
+`pyauto-brain intake dashboard --check`; use whichever the environment resolves.
+
+Running it on an already-current tree is a **no-op**: the renderer rewrites both
+files byte-identically and `git status` stays clean, so there is never a reason
+to guess whether it is needed. `--apply` prints
+`Wrote: dashboard.md + dashboard.html (<n> prompts, <n> hygiene flag(s))`.
+
 `--check` exits **1** for drift and anything higher for a renderer failure
 (Brain/Mind version skew) — a non-1 code is not a stale page, so read the
 message rather than re-rendering.
@@ -248,8 +258,13 @@ work first and use explicit pathspecs if any exists:
 ```bash
 git status --short                                            # unrelated work?
 source scripts/prompt_sync.sh && prompt_sync_push "complete: <task>"
+git show --stat HEAD                                          # names dashboard.md + dashboard.html?
 ```
 
+That last line is the leg's own check: a close-out commit that does not carry
+`dashboard.md` and `dashboard.html` beside the record did not regenerate, and
+the ledger's dashboard line would be a claim you cannot back.
+
 One commit carrying the record, the retirements and the regenerated pages is the
 goal. The workflow's fallback is strictly worse: its heal commit is made with
 `GITHUB_TOKEN`, which triggers no other workflow, so it must dispatch