1 files changed, 60 insertions, 6 deletions
diff --git a/docs/superpowers/plans/2026-08-09-card-list.md b/docs/superpowers/plans/2026-08-09-card-list.md
index 4ea9a4b..e18efaf 100644
--- a/docs/superpowers/plans/2026-08-09-card-list.md
+++ b/docs/superpowers/plans/2026-08-09-card-list.md
@@ -20,7 +20,26 @@ below will look like busywork if you have not.
 
 **Branch.** This work continues `item-20-message-rows`, which carries the tree
 model, the worker's reply walk, and `MessageNode`. All of that is kept. The
-branch is 15 commits behind `master`, so Task 0 rebases it first.
+branch is 15 commits behind `master`, so Task 0 rebases it first and then
+branches `card-list` off the result.
+
+**Nothing in this plan touches `master`.** That is a requirement, not a
+convention: the card list is an experiment on a design the user has already
+rejected once, and abandoning it must cost nothing. Every commit here lands on
+`card-list`; `master` keeps working and shippable throughout, and walking away
+is `git checkout master` with nothing to undo. Do not merge, do not fast-forward
+master, and do not push `card-list` anywhere the user builds from until they
+have seen it running (Task 10).
+
+**The escape hatch, should it be needed:**
+
+```bash
+git checkout master          # working application, unchanged
+git branch -D card-list      # only if the experiment is being discarded
+```
+
+`item-20-message-rows` is left in place either way, as the reference for what
+the rejected presentation looked like.
 
 **Build and test:**
 
@@ -72,14 +91,29 @@ claim a test that needs no painting at all.
 
 ---
 
-## Task 0: Rebase the branch onto master
+## Task 0: Rebase, then branch `card-list` off it
 
 **Files:** no source changes of your own; you are resolving other people's.
 
-- [ ] **Step 1: Confirm where you are**
+**Do this on a copy, not on the original.** `item-20-message-rows` is the record
+of what the rejected presentation looked like, and rebasing it in place destroys
+that. Branch first, rebase the branch.
+
+- [ ] **Step 0: Verify master is clean and note where it is**
 
 ```bash
-git checkout item-20-message-rows
+git status --short
+git rev-parse --short master
+```
+
+Expected: no output from the first (a dirty tree here means someone left work
+behind, and it must be dealt with before a rebase). Write down the second: it is
+what `master` must still point at when this plan finishes.
+
+- [ ] **Step 1: Create the working branch**
+
+```bash
+git checkout -b card-list item-20-message-rows
 git log --oneline -1
 ```
 
@@ -88,7 +122,7 @@ Expected: `029a50e docs: record message rows, and the user's verdict on them`
 - [ ] **Step 2: See what is coming**
 
 ```bash
-git log --oneline item-20-message-rows..master
+git log --oneline card-list..master
 ```
 
 Expected: 15 commits, including `751ca62 fix(ui): stop a restored splitter
@@ -146,6 +180,18 @@ git log --format='%h %G? %s' -5
 Expected: `G` in every second column. If any say `N`, re-sign:
 `git rebase --exec 'git commit --amend --no-edit -S' master`
 
+- [ ] **Step 7: Confirm nothing happened to master or to the original branch**
+
+```bash
+git rev-parse --short master              # unchanged from Step 0
+git rev-parse --short item-20-message-rows # still 029a50e
+git branch --show-current                  # card-list
+```
+
+If `master` moved, something rebased onto the wrong branch. Stop and fix it
+before writing any code: every later task assumes master is untouched and is
+the thing to fall back to.
+
 ---
 
 ## Task 1: The model's own tags for a reply
@@ -2132,11 +2178,19 @@ Switch the desktop between light and dark and confirm the spine, the chips and
 the dimmed reply text are all still legible. Every colour here comes from the
 palette for this reason, but the only proof is looking.
 
-- [ ] **Step 4: Report back**
+- [ ] **Step 4: Report back, and stop**
 
 Per the user's standing preference, hand the result over rather than declaring
 it done. Say what was checked and what was not.
 
+**Do not merge to master, and do not offer to.** This design was reached by
+rejecting a previous one that was also finished, tested and green, so a passing
+suite is not the thing that decides it. The user looks at the cards and says
+whether they are right. Only then is there a merge to discuss.
+
+If the answer is no, `git checkout master` is the whole of the undo, and
+`card-list` stays on disk for whatever the next attempt reuses.
+
 ---
 
 ## Self-Review Notes