pure - Verified execution runtime unifying state, persistence, and replication.

	Commit message (Collapse)	Author	Age	Files	Lines
*	Say where the shared board now lives, and what is left (105)	eunhhu	2026-09-30	1	-1/+9
\| \| \| \| \| \| \| \| \|	The board is Vega's examples/shared-board.aup, and Vega's shared_board check runs its two nodes: changes on either agree, and a partition healed agrees on the later change. Reading a named field list once a delivery would save part of 310 ns a record during upgrades alone: not worth an API. What review 004 asked that is left is 103's third item, broader performance comparisons under conditions stated first.
*	Say that sends and applies now spread their fields (105)	eunhhu	2026-09-30	1	-4/+8
\| \| \| \| \| \| \| \| \|	aup spreads an item or a message into a send or a record, and sets an item whole (c69682e): the board sends { ..at } and applies cards[k] = Card { ..remote }, and a new field is written in two places, the record and the output. v6 on both nodes, cut apart and joined again, agrees on the later change; its module is byte for byte the one with every field written.
*	Say what laying a record out anew costs (014)	eunhhu	2026-09-30	1	-1/+1
\| \| \| \| \| \| \|	A board record of five fields (38 B) sent with v3's output fields took 310 ns to lay out for v4's input, reading the field list each time. Only streams of another shape pay it, and only while nodes are upgraded one after the other: less than a delivery's own work.
*	Say how growing a board two nodes share went (105)	eunhhu	2026-09-30	1	-0/+119
	103's next step: grow a real app, adding and reordering fields, cutting the connection, starting again, and write down what gets in the way. Two nodes share a board (from Vega's examples/board.aup), each sending its changes to the other, the later change winning. Upgrading them one after the other deadlocked: fixed by recasting waiting sends by name (9aa123e) and taking fields by name (014, 5ce7655), and under it a link that stopped for good when a refused stream's try was lost (baaf955). Now the older node's changes reach the newer one during the upgrade, the newer one's new field waits for the older, and the boards agree a second after. Fields in another order agree at once; a partition healed agrees on the later change; both nodes started again go on. Two rough edges eased on the way (the node's name, message like in aup); sends and applies are still written field by field. CHECKPOINT's row for links says so.