test(signals): posture matrix over the store oracle's states; runner freezes the served value before probing - #3489
Conversation
|
6952121 to
9f24401
Compare
Coverage Report for CI Build 35073504349Coverage remained the same at 71.46%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
Merging this PR will degrade performance by 31.21%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ❌ | createStore setter: delete + set one root key (#3044 overlay) |
589.1 µs | 856.4 µs | -31.21% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing oracle/store-postures (2537d77) with next (5fa224a)
…freezes the served value before probing
Runs the store oracle's eight states (plain / optimistic / derived store
leaves) through the same postures as the signal states — the store's read
sites (nodeValue / serveDataKey / optimisticView) are separate
implementations of the same rules, so every cell is a parity check. The
store states move to visibility-oracle-store.states.ts; the store runner is
unchanged (72 cells, same results).
Runner fix: the closure readers (untracked / latest / isPending) assign
`served` inside the posture's own compute — boundary content — which
re-runs after the entanglement probe resolves the state's flight. The
second pass overwrote the first, so three earlier readings ("isPending
false behind a fallback", "override invisible behind a fallback", "the
projection's seed served as a value in boundary content") were artifacts;
retracted. `served` is now frozen before probing.
Findings (tests/posture-store-parity.test.ts):
- S1, violation (signal side), it.fails — adopted, unflushed: inside the
adopting action's body the store leaf answers latest 0 / isPending false
(A28), the signal answers 1 / true — adoption stamped it and
`unflushedValue` reads a stamped node with no stash as flushed-held.
Spec O4.
- S2, observed, both agree — a memo + render effect created inside
loading-boundary content over a held value publishes it (spec O2's
in-flush form).
Co-authored-by: Claude via Cursor <noreply@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
9f24401 to
2537d77
Compare
Tests and spec only — no runtime change.
What
Runs the store oracle's eight states (plain / optimistic / derived store leaves) through the same postures as the signal states. The store's read sites (
nodeValue/serveDataKey/optimisticView) are separate implementations of the same rules, so every store cell beside its signal twin is a parity check. Store states move tovisibility-oracle-store.states.ts; the store runner is unchanged (72 cells, same results). Matrix is now 621 cells.Runner fix — and a retraction
The closure readers (
untracked/latest/isPending) assignservedinside the posture's own compute — boundary content — which re-runs after the entanglement probe resolves the state's flight. The second pass overwrote the first. Three readings I reported from the earlier passes were that artifact, not the runtime:isPending(x)is false behind a showing fallback"All three vanish with
servedfrozen before probing. Nothing had been pinned or written to the spec from them.Findings —
tests/posture-store-parity.test.tsit.fails(spec O4): adopted, unflushed. Same-tick adoption is by design (O1), but A28 still says nothing is visible before the flush. Inside the adopting action's body the store leaf answerslatest0 /isPendingfalse; the signal answers 1 / true. Adoption stamps the signal with the transaction, andunflushedValuereads a stamped node with no_flushedStagedstash as "flushed, held". The store's selection doesn't take that path. One rule, two implementations; the store is right.Everything else in the store rows matches the signal rows under the same posture (adoption entanglement by O1;
latestentangles by A15; disposed readers hold nothing).signals 2,713 + 2 expected fails (S1 here; the same-flush P1 form from #3488).