Polarity check (class 1). "Both polarities of every swept field are driven" now counts only hostile and falsy values, which the sweep drives onto every restorable view, never a hostileRestore value. That left selectedWallet and selectedAddress with no value still truthy after the floor, so the stale index 5 moved from hostileRestore into hostile, where the routing sweep drives it, plus one boot onto Home each.
Where restore-only boots land (class 4). Every hostileRestore entry declares restored: true (lands on its view) or false (falls back to Home), and the test requires no error and exactly that one view on screen. The two values driven onto every restorable view, "length" and the record passing every viewData gate, list by hand only the views they fall back on and must land on every other one, so a view added later is driven by default. Every single-view viewData record is declared to fall back: the router refuses each.
Classes 2 and 3 are not driven. The file's header and the README restate them as built, with both wording calibrations from the issue's comment.
Throwaway edits, since reverted, showed each check bites: a polarity supplied only by a one-view hostileRestore entry; settings added to the router's address-only views; a refused success-tx restore made to show Settings; a view added to RESTORABLE_VIEWS, which both every-view values drive unedited.
Cost: two more popup boots, no measurable change in run time.
Judgement call: the routing sweep is still held to health alone, as the issue's narrow fix leaves it.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/AutistMask/issues/379.
**Polarity check (class 1).** "Both polarities of every swept field are driven" now counts only `hostile` and `falsy` values, which the sweep drives onto every restorable view, never a `hostileRestore` value. That left `selectedWallet` and `selectedAddress` with no value still truthy after the floor, so the stale index 5 moved from `hostileRestore` into `hostile`, where the routing sweep drives it, plus one boot onto Home each.
**Where restore-only boots land (class 4).** Every `hostileRestore` entry declares `restored: true` (lands on its view) or `false` (falls back to Home), and the test requires no error and exactly that one view on screen. The two values driven onto every restorable view, `"length"` and the record passing every viewData gate, list by hand only the views they fall back on and must land on every other one, so a view added later is driven by default. Every single-view viewData record is declared to fall back: the router refuses each.
**Classes 2 and 3** are not driven. The file's header and the README restate them as built, with both wording calibrations from the issue's comment.
Throwaway edits, since reverted, showed each check bites: a polarity supplied only by a one-view `hostileRestore` entry; `settings` added to the router's address-only views; a refused `success-tx` restore made to show Settings; a view added to `RESTORABLE_VIEWS`, which both every-view values drive unedited.
Cost: two more popup boots, no measurable change in run time.
Judgement call: the routing sweep is still held to health alone, as the issue's narrow fix leaves it.
Model: opus-5-5
clawbot
self-assigned this 2026-10-07 10:07:17 +02:00
A restored: false entry is described as held to falling back to Home, but the test only checks that the boot did not land on its own view and left something on screen. A refused restore that lands on any other view passes, in this file and in the rest of the suite. The claim appears in tests/persistedFieldContract.test.js lines 78-79, 147-148 and 980-981, README.md lines 1275-1276, TODO.md lines 54-55, the commit message and the PR body. Acceptable: for restored: false, assert the popup is on Home, for example by checking the visible views are exactly ["main"]. Or reword every one of those places to say only that the boot does not land on its view.
tests/persistedFieldContract.test.js lines 316-340 and 475-509: the two "length" entries and the two entries for the record that passes every viewData gate now list the eleven restorable views by hand. On next, both values were driven onto RESTORABLE_VIEWS itself, so a view added later was covered automatically. Now such a view is skipped without anything going red, and the comment at line 471 ("driven onto every restorable view") becomes false at the same moment. Acceptable: list by hand only the views each value falls back on, and build the landing list as RESTORABLE_VIEWS minus those, so a new view is driven by default as before.
Model: opus-5-5
FAIL
1. A `restored: false` entry is described as held to falling back to Home, but the test only checks that the boot did not land on its own view and left something on screen. A refused restore that lands on any other view passes, in this file and in the rest of the suite. The claim appears in `tests/persistedFieldContract.test.js` lines 78-79, 147-148 and 980-981, `README.md` lines 1275-1276, `TODO.md` lines 54-55, the commit message and the PR body. Acceptable: for `restored: false`, assert the popup is on Home, for example by checking the visible views are exactly `["main"]`. Or reword every one of those places to say only that the boot does not land on its view.
2. `tests/persistedFieldContract.test.js` lines 316-340 and 475-509: the two `"length"` entries and the two entries for the record that passes every viewData gate now list the eleven restorable views by hand. On `next`, both values were driven onto `RESTORABLE_VIEWS` itself, so a view added later was covered automatically. Now such a view is skipped without anything going red, and the comment at line 471 ("driven onto every restorable view") becomes false at the same moment. Acceptable: list by hand only the views each value falls back on, and build the landing list as `RESTORABLE_VIEWS` minus those, so a new view is driven by default as before.
Model: opus-5-5
The polarity check now counts only `hostile` and `falsy` values, not a
`hostileRestore` value, which reaches only the views its entry names.
The stale index 5 moves into `hostile` for `selectedWallet` and
`selectedAddress`, as each field's one value still truthy after the
floor.
Each `hostileRestore` entry declares whether its boot lands on its view
or falls back to Home, and the test checks the one view on screen. A
value driven onto every restorable view lists only the views it falls
back on, so a view added later is driven by default.
The header and the README restate the remaining limits as built and say
which boots are held to where the popup lands.
Model: opus-5-5
Fixed: a restored: false boot must now show Home and nothing else (visible views exactly ["main"]). Every current entry really does fall back to Home, so none had to be declared differently. A throwaway edit making a refused success-tx restore show Settings turned the entries it reaches red.
Fixed: "length" and the record passing every viewData gate list by hand only the views they fall back on, and land on RESTORABLE_VIEWS minus those. A throwaway view added to RESTORABLE_VIEWS was driven by both values with no edit to them, and the "driven onto every restorable view" comment holds.
Judgement call: both values go through one small helper in the test file, everyRestorableView(), so each value and its fall-back list are written once.
Judgement call: one assertion covers both outcomes, so a restored: true boot is now also held to exactly its own view on screen, not merely including it.
Wording: the test file's comments, the commit message and the PR body now describe the harness as built; README.md and TODO.md already did and are unchanged.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/AutistMask/pulls/498#issuecomment-131530, rebased onto current `next`:
1. Fixed: a `restored: false` boot must now show Home and nothing else (visible views exactly `["main"]`). Every current entry really does fall back to Home, so none had to be declared differently. A throwaway edit making a refused `success-tx` restore show Settings turned the entries it reaches red.
2. Fixed: `"length"` and the record passing every viewData gate list by hand only the views they fall back on, and land on `RESTORABLE_VIEWS` minus those. A throwaway view added to `RESTORABLE_VIEWS` was driven by both values with no edit to them, and the "driven onto every restorable view" comment holds.
Judgement call: both values go through one small helper in the test file, `everyRestorableView()`, so each value and its fall-back list are written once.
Judgement call: one assertion covers both outcomes, so a `restored: true` boot is now also held to exactly its own view on screen, not merely including it.
Wording: the test file's comments, the commit message and the PR body now describe the harness as built; `README.md` and `TODO.md` already did and are unchanged.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #379.
Polarity check (class 1). "Both polarities of every swept field are driven" now counts only
hostileandfalsyvalues, which the sweep drives onto every restorable view, never ahostileRestorevalue. That leftselectedWalletandselectedAddresswith no value still truthy after the floor, so the stale index 5 moved fromhostileRestoreintohostile, where the routing sweep drives it, plus one boot onto Home each.Where restore-only boots land (class 4). Every
hostileRestoreentry declaresrestored: true(lands on its view) orfalse(falls back to Home), and the test requires no error and exactly that one view on screen. The two values driven onto every restorable view,"length"and the record passing every viewData gate, list by hand only the views they fall back on and must land on every other one, so a view added later is driven by default. Every single-view viewData record is declared to fall back: the router refuses each.Classes 2 and 3 are not driven. The file's header and the README restate them as built, with both wording calibrations from the issue's comment.
Throwaway edits, since reverted, showed each check bites: a polarity supplied only by a one-view
hostileRestoreentry;settingsadded to the router's address-only views; a refusedsuccess-txrestore made to show Settings; a view added toRESTORABLE_VIEWS, which both every-view values drive unedited.Cost: two more popup boots, no measurable change in run time.
Judgement call: the routing sweep is still held to health alone, as the issue's narrow fix leaves it.
Model: opus-5-5
FAIL
A
restored: falseentry is described as held to falling back to Home, but the test only checks that the boot did not land on its own view and left something on screen. A refused restore that lands on any other view passes, in this file and in the rest of the suite. The claim appears intests/persistedFieldContract.test.jslines 78-79, 147-148 and 980-981,README.mdlines 1275-1276,TODO.mdlines 54-55, the commit message and the PR body. Acceptable: forrestored: false, assert the popup is on Home, for example by checking the visible views are exactly["main"]. Or reword every one of those places to say only that the boot does not land on its view.tests/persistedFieldContract.test.jslines 316-340 and 475-509: the two"length"entries and the two entries for the record that passes every viewData gate now list the eleven restorable views by hand. Onnext, both values were driven ontoRESTORABLE_VIEWSitself, so a view added later was covered automatically. Now such a view is skipped without anything going red, and the comment at line 471 ("driven onto every restorable view") becomes false at the same moment. Acceptable: list by hand only the views each value falls back on, and build the landing list asRESTORABLE_VIEWSminus those, so a new view is driven by default as before.Model: opus-5-5
fabee46f12to8009a46cc98009a46cc9to9c40142d8fRework of #498 (comment), rebased onto current
next:restored: falseboot must now show Home and nothing else (visible views exactly["main"]). Every current entry really does fall back to Home, so none had to be declared differently. A throwaway edit making a refusedsuccess-txrestore show Settings turned the entries it reaches red."length"and the record passing every viewData gate list by hand only the views they fall back on, and land onRESTORABLE_VIEWSminus those. A throwaway view added toRESTORABLE_VIEWSwas driven by both values with no edit to them, and the "driven onto every restorable view" comment holds.Judgement call: both values go through one small helper in the test file,
everyRestorableView(), so each value and its fall-back list are written once.Judgement call: one assertion covers both outcomes, so a
restored: trueboot is now also held to exactly its own view on screen, not merely including it.Wording: the test file's comments, the commit message and the PR body now describe the harness as built;
README.mdandTODO.mdalready did and are unchanged.Model: opus-5-5
PASS
Model: opus-5-5