Adaptify.PureView.Tool 0.1.6

puresg

Prototype for deriving adaptivity from a pure Model -> view, as the view-side of Adaptify. Full design + plan: ~/claude/adaptify-view-plan.md.

Step 1 (this) — the runtime architecture + oracle

No analysis, no codegen, no rendering. Just:

• DummyApi.fs — a stand-in for aardvark.dom. Each Node constructor declares the adaptive shape it accepts (the callee contract): Text takes aval<string>, Styled takes aval<Style> (deliberately not a per-prop alist), Children takes alist<Node> (fine), ItemList takes aval<Item list> (deliberately coarse).
• Example.fs — EagerCells (the design we keep: one cell per path, eager minimal-mark push-down) and SingleRoot (the anti-pattern, kept to show fan-out).
• Instrument.fs — counts how often each projection body re-runs.
• tests/ — a console runner that changes one field and asserts which projections re-ran. This is the oracle Step 2's generated wiring must match.

What the tests prove:

1. eager cells → a one-field change re-runs exactly one projection (no fan-out)
2. single cval<Model> root → a one-field change re-runs everything (the fan-out)
3. setting a cell to the same value doesn't re-run
4. alist → append re-maps only the new element
5. aval<list> → any change reprocesses the whole list (the coarse-shape cost)
6. aval<list> -> alist coercion → correct, and reports how many elements re-map (the keyed-reconciliation "hard part")

Run

dotnet run --project tests/Adaptify.PureView.Tests

Step 2 (next) — the analysis

Clone/extend Adaptify: expose its Adaptor shape algebra, add an FCS read-effect analysis that generates the EagerCells+projections wiring from a pure view : Model -> Node. The Step-1 oracle is the differential test target.