mind: bundles.md registry + dashboard Bundles section

.github/workflows/dashboard_refresh.yml

@@ -35,6 +35,7 @@ on:
       - "parked.md"
       - "planned.md"
       - "condemned.md"
+      - "bundles.md"
       - "dashboard.md"
       - "dashboard.html"
   pull_request:
@@ -45,6 +46,7 @@ on:
       - "parked.md"
       - "planned.md"
       - "condemned.md"
+      - "bundles.md"
       - "dashboard.md"
       - "dashboard.html"
   workflow_dispatch:

REFERENCE.md

@@ -304,6 +304,8 @@ Free-form markdown. Strong conventions:
   Filed: 2026-07-09         # optional; the day the prompt was written
   Issued: 2026-08-19        # optional; set when the prompt advances to active/
   Blocked-by: PyAutoFit#1436          # optional; see "Declaring a gate" below
+  Epic: cluster-strong-lensing        # optional; an entry in epics.md
+  Bundle: euclid-pipeline-tidy        # optional; an entry in bundles.md
   ```
 
   When present, `Type:` should match the work-type folder. The goal is light
@@ -339,6 +341,18 @@ Free-form markdown. Strong conventions:
   had closed without anyone noticing — including one whose exit condition was met
   the same day it was written.
 
+  **Declaring group membership — `Epic:` / `Bundle:`.** Both optional, both
+  naming a slug in the matching registry file, and the two mean opposite things
+  about ORDER. `Epic: <slug>` (`epics.md`, plus an optional `Phase: <n>`) says
+  this prompt is one phase of an ordered programme: the dashboard pulls it out
+  of every pick list and shows it only under its epic, worked in phase order.
+  `Bundle: <slug>` (`bundles.md`) says the opposite — this prompt is
+  INDEPENDENT, and a human has pinned it to a set worth running in one
+  orchestrated session. A bundle member keeps its normal place on the
+  dashboard and gains a Bundles card; it leaves only the *auto*-bundle pool,
+  since it is already spoken for. A slug naming no registry entry still
+  groups, loudly (⚠️ on the page), so a typo is visible rather than silent.
+
   The optional `Difficulty:` / `Autonomy:` / `Priority:` keys let both people and
   PyAutoBrain see, at a glance, how hard a task is, whether an agent can safely
   take it on, and how urgent it is. What each `Autonomy:` level *does* at every
@@ -497,7 +511,7 @@ no prompt.
 | Ledger — merged automatically | Code — always a human |
 |---|---|
 | `draft/**`, `active/**`, `complete/**` | `scripts/`, `tests/`, `.github/`, `skills/`, `policy/`, `docs/` |
-| `active.md`, `planned.md`, `parked.md`, `condemned.md`, `epics.md`, `ideas.md`, `autonomy_log.md` | `repos.yaml`, `README.md`, `AGENTS.md`, `REFERENCE.md`, `ROUTING.md`, … |
+| `active.md`, `planned.md`, `parked.md`, `condemned.md`, `epics.md`, `bundles.md`, `ideas.md`, `autonomy_log.md` | `repos.yaml`, `README.md`, `AGENTS.md`, `REFERENCE.md`, `ROUTING.md`, … |
 | `dashboard.md`, `dashboard.html` | anything unclassified — a new root file, a new top-level folder |
 
 Two exceptions inside the ledger dirs: a **dot-path** anywhere, and a file

bundles.md

@@ -0,0 +1,34 @@
+# Bundles
+
+Sets of **independent** tasks that make sense to run in one orchestrated
+session: an architect session (Fable) plans them, subagent sessions (Opus)
+implement them, and every member still gets its own issue and its own PR — so
+`/prm` closes each one out exactly as it would a standalone task. The skill
+that runs one is `start_bundle` (PyAutoBrain).
+
+**A bundle is not an epic.** An epic is *ordered* and phase-gated: one phase at
+a time, worked through its ledger, and its members are pulled out of the pick
+lists so nobody starts phase 3 first. A bundle is a *flat set* — its members
+have no order and no dependency on each other, so they stay in their usual
+dashboard sections and a bundle is only an additional VIEW of the backlog. If
+the members must happen in order, it is an epic (`epics.md`), not a bundle.
+
+This file holds **pinned** bundles only — the ones a human decided are worth
+doing together. The dashboard also proposes **auto** bundles, computed fresh
+from the backlog every time it is rendered (same target repo, unblocked,
+non-epic, under a size cap, minimum two members); those are proposals and are
+never written here. Pinning is how a proposal becomes a record — and how a
+bundle that spans repos, or that no rule would ever spot, gets onto the page.
+
+Schema per entry: `## <slug>` then `- title:` / `- members:` / `- rationale:`
+(why these belong in one session) / `- status:` (optional, coarse and durable).
+`- members:` opens a list of prompt paths, one per indented `  - <path>`
+bullet, and closes at the next `- key:` line.
+
+A member prompt may also declare its own membership in its header:
+`Bundle: <slug>` (this file's slug). A prompt carrying that header leaves the
+auto pool, and if its slug names no entry here the dashboard renders the group
+with a ⚠️ rather than silently dropping it.
+
+<!-- No entries yet: the dashboard's auto bundles cover the same-repo case, so
+     pin one only when the grouping is something a rule would not find. -->