1 files changed, 45 insertions, 0 deletions
diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
index c83e41c..376272b 100644
--- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
+++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md
@@ -10912,3 +10912,48 @@ while moves report through another signal. An error bumps the same ticket, so
 a late "done" cannot cover the error message. Tested by
 `aWriteSaysItIsApplyingUntilTheWorkerHasRunIt`, which fails when the reply is
 dropped.
+
+## 212. A rule edit reaches only new mail
+
+**Observed.** From the user, 2026-10-31: after adding an address to the promo
+rule, "I have to manually go and apply the tags, because filters run on new
+mail only."
+
+**Cause.** Not a defect. The `post-new` hook scopes every rule to `tag:new`,
+and backfill was deliberately deferred by the tagging-rules spec until the
+confirmation question was settled.
+
+**Approach.** See `specs/2026-10-31-rule-apply-and-archive-design.md`, Part A.
+
+**Constraints.** Revises the no-confirmation rule in `CLAUDE.md` with a second
+exception, by property: a write scoped to the whole mailbox confirms with the
+count. Undo still applies.
+
+**Done 2026-10-31, unreleased.** Built as the spec's Part A with three changes
+recorded there and in `CLAUDE.md`: the worker's `applyRule` resolves the ids
+once and writes one tag at a time, it answers with one `ruleApplied` from which
+`onRuleApplied` builds the undo macro (nothing is armed on the shared
+confirmation queue in advance), and Apply during a sync is refused rather than
+held. The ordering defect found on the way, in the ordinary undo path, is item
+214.
+
+## 213. A rule removing `inbox` is skipped whole by the hook
+
+**Observed.** Found while designing 212. Every sync logs
+`rule 'promo' would remove inbox; skipped`, so new promotional mail is never
+tagged `promo` and stays in the inbox. This is how the 10k messages of item
+211 accumulated.
+
+**Cause.** Verified in `assets/hooks/post-new`: `PROTECTED_REMOVALS` is
+`{unread, inbox}` and a rule naming either is `continue`d past entirely, not
+applied without the removal. The rules dialog says nothing about it.
+
+**Approach.** See the same spec, Part B.
+
+**Constraints.** A rule-format change: both readers, both suites, and the hand
+round trip under "Changing the rule format". The hook runs every ten minutes
+on real mail.
+
+**Done 2026-10-31, unreleased.** Built as the spec's Part B. The hand round
+trip under "Changing the rule format" step 4 was run over a throwaway index;
+its counts are in the commit that closed this item.