From caa34f1f4616b6c3e7a11295e7b07fe303b183fb Mon Sep 17 00:00:00 2001 From: "Danilo M." Date: Tue, 8 Sep 2026 11:17:29 +0200 Subject: feat: make Sync follow the account being looked at Item 101. The sync run was already account-aware for pending edits and consulted the account dropdown for nothing, so looking at one account and pressing Sync collected every one of them. pendingSyncChannels() now reads the dropdown as well as m_editedAccounts. The two are a UNION rather than one replacing the other, which is the whole safety property: looking at one account while having edited another is ordinary, and a run that dropped the edited account's channel would strand that write with nothing on screen to say so. All accounts is the empty key and narrows nothing, so a full fetch stays what an unselected window asks for. The existing fallback is untouched: an account whose section names no channel still widens the run rather than being silently skipped. syncStartedText() is the visibility half. A run opened with "Syncing..." whether it covered one account or all of them; it now names what it covers. The exit paths overwrite the label with their own wording immediately, so the parameter is defaulted rather than threaded through them. Four tests. The narrowing one asserts the channel list is EMPTY before the gesture, since empty is what a full fetch looks like and a test starting from a narrowed state could not tell the fix from a window that had never widened. Mutation-checked twice: ignoring the selection fails three of them, and replacing the pending set instead of unioning with it fails the union test alone, which is the version that looks correct and loses a write. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01KphFXTc2QajxXsHWyvGJ4R --- .../2026-08-03-post-0.1.0-usability-closed.md | 46 ++++++++++++++++++++++ 1 file changed, 46 insertions(+) (limited to 'docs/superpowers/plans/2026-08-03-post-0.1.0-usability-closed.md') 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 6613059..bcb6431 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 @@ -10232,3 +10232,49 @@ sends, and asserts the row arrives with no further gesture: no second against the defect. Mutation-checked by disabling the connection, which fails on the row count. +## 101. Sync is account-aware for edits but not for the account the user is looking at + +**Done 2026-09-08.** The user chose BOTH halves the entry offered, and then +narrowed the first one: not a second action beside Sync, but the existing Sync +made account-aware. "If 'All Accounts' is selected, Sync works as today, if +'work' is selected, hitting Sync works only for 'work'." + +**What was built.** `pendingSyncChannels()` now reads the account dropdown as +well as `m_editedAccounts`, and the two are a UNION rather than one replacing +the other. That union is the whole safety property and is the constraint the +original entry named: looking at one account while having edited another is +ordinary, and a run that dropped the edited account's channel would strand that +write with nothing on screen to say so. All accounts is the empty key and +narrows nothing, so a full fetch is still what an unselected window asks for, +which is what keeps item 49's reasoning intact. The existing fallback survives +untouched: an account whose section names no channel still widens the run to +everything rather than being silently skipped. + +The visibility half is `syncStartedText()`, called from `setSyncBusy()`. A run +used to open with "Syncing..." whether it covered one account or all of them, +which is precisely the invisibility the entry complained about; it now reads +"Syncing all accounts..." or "Syncing work-channel, personal-channel...". The +exit paths pass no channels and overwrite the label with their own wording +immediately, so the parameter is defaulted rather than threaded through them. + +**Four tests**, three on the channel resolution and one on the generated +string. `syncNarrowsToTheSelectedAccount` asserts the list is EMPTY before the +gesture, which matters more than it looks: empty is what a full fetch looks +like, so a test starting from a narrowed state could not tell the fix from a +window that had never widened. `aNarrowedSyncStillCarriesAnEditFromAnotherAccount` +is the union, and it is the one that fails under the plausible wrong +implementation. `theStatusLineNamesWhatASyncWillCover` asserts on the generated +string rather than on a label after a real run, which would be a test of +QProcess timing. + +Mutation-checked twice: ignoring the selection fails all three channel tests, +and replacing the pending set instead of unioning with it fails the third one +alone. That second mutation is the one worth having, since it is the version +that looks correct and loses a write. + +**One thing deliberately not done.** The separator in the channel list is a +plain `", "`, not a translated string. `lupdate` picked it up as translatable +when it was written with `tr()`, and a comma joins a list the same way in +Italian; a translatable separator is a string for a translator to get wrong for +no gain. + -- cgit v1.2.3