diff options
| author | Danilo M. <danix@danix.xyz> | 2026-08-13 11:54:28 +0200 |
|---|---|---|
| committer | Danilo M. <danix@danix.xyz> | 2026-08-13 11:54:28 +0200 |
| commit | 2471356c99f506b6227c4f9a9399f051b85ef76c (patch) | |
| tree | 82f11d61904fef65787df94f435d10db13731078 /docs/superpowers | |
| parent | 4361411957e3e4d0b4739cf784fc12dfa8654714 (diff) | |
| download | qtmaildir-2471356c99f506b6227c4f9a9399f051b85ef76c.tar.gz qtmaildir-2471356c99f506b6227c4f9a9399f051b85ef76c.zip | |
docs: the data-loss defect took the note too
The first pass of the field repair restored the query and the tags and
stopped there. The note was also blank, which the user noticed: every
sibling account rule carries an identical note and only the damaged rule
had none.
The reason it was missed is worth keeping. The shell backup was read for
the tagging command, and the note comes from the comment block above it,
which the migration had given to all five account rules alike. The
handler at fault writes every field of a rule, so every field is equally
exposed, and a repair that checks only the fields that first drew
attention will leave some of the damage in place.
Restored from the four siblings, which are byte-identical, and the whole
file re-audited: no rule now has an empty query, id, note or tag list.
Diffstat (limited to 'docs/superpowers')
| -rw-r--r-- | docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md | 12 |
1 files changed, 10 insertions, 2 deletions
diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md index f9f8c53..00a7f76 100644 --- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md +++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md @@ -4904,8 +4904,16 @@ Fixed on the `rule-builder` branch as part of item 76, with regression test. It fails against the unfixed code. **Damage in the field, and the repair.** The live rules file had exactly one -casualty: the account rule sitting first in the list, with both `query` and -`add` empty while every sibling account rule was intact. +casualty: the account rule sitting first in the list, with its `query`, its +`add` and its `note` all empty while every sibling account rule was intact. + +**The note was missed on the first pass of the repair**, because the shell +backup was read for the tagging command and the note comes from the comment +block ABOVE it, which the migration had given to all five account rules +alike. The user spotted the gap. `applyEditsToCurrentRule()` writes every +field, so every field is equally exposed: repair work here must check the +whole rule, not the fields that first drew attention. Restored from the four +siblings, which carry byte-identical notes. Restored from `post-new.shell-backup`, which item 44's migration kept, and verified by loading the file through mailctl's own reader: 17 rules, correct scoping. The rule had stopped tagging, but only one message had arrived in the |