fix(state): evaluate a re-set state against its own generation - #266

Part of #258. It fixes two of the three symptoms and pins the rest.

What was wrong

Re-setting a state object left machinery pointing at the previous generation, because the things it is keyed by are identical across generations.

X10, the cache. A wildcard-free getter's absolute address is the same object before and after a re-set, so the old value came back with dirty:false. mount({items:[1,2], get sum(){…}}) read 3, was re-set to {items:[5,6]}, and still read 3.

X7's internal half, the ledgers. The setter clears pathSet, listPaths and elementPaths, and the recursion teardown removes the edges of the previous generation's generated accessors. Nothing rebuilt them, so after a re-set a whole-list write threw Cannot expand dynamic dependency with wildcard for non-list address while the DOM moved on regardless.

What this does

• Cache entries carry the generation they were written in, and a read only hits an entry from the current generation. The generation advances after the previous generation is torn down and before the new state object is installed.
• The path registrations of live bindings are re-derived after the setter's clears, so the ledgers and static chains are rebuilt for the new generation. Clearing pathSet stays: it is the self-heal that restores the static edges the recursion teardown removes, and keeping it was measured to matter.
• The rebuild exclusion accumulates across generations. Taken from the previous teardown alone, a second re-set with no read in between re-registered static edges for generated paths that were never materialized.

$watch now reaches its handler after a re-set in a shape where the write used to throw before getting there.

The generation contract, as measured

Seven $ declaration validators run in the setter. Four are pure validation and run before the generation advances, so a throw there leaves the element wholly in the previous generation. Three need what the setter installs and run after it, so a throw there leaves the new state in place with the generation already advanced. What each one leaves behind differs, and rather than describe it in prose the tests pin it: one test per validator, plus three that assert the ledger state after the throw and whether a later whole-list write succeeds.

That split is the result of three rounds of getting it wrong. Round 1 wrote the rule as universal and pinned one validator. Round 2 corrected that, said there were six validators and that the late ones landed alike; there are seven, and they do not. Round 3 removed the prose and let the tests be the enumeration.

Still open, pinned as known holes

• A re-set does not re-apply established bindings. Reads move to the new generation; scalars, wildcard-free getters and for rows keep the first generation's text. This is the author-visible half of X7.
• A re-set on a <wcs-state mount="…"> volume is a silent no-op for the page. The graft is a one-time copy, so the root tree and the DOM stay on the first generation with no error and no warning.
• X6, hydration, is untouched here.

Both open symptoms are pinned with DEFECT: comments in integration.stateGenerationReset.test.ts and will be split into their own issues.

Verification

Every behavioural claim was measured on this branch and on main with the same probe, and the numbers are in the commit messages and the test titles.

The known-defect pin for 欠陥8 now asserts the fix rather than the stale read.

🤖 Generated with Claude Code