Tags and Properties for Check-in 02f6aadcad
- branch=strata-ui inherited from [3e3ad17751]
- closed added by [be66bb0482] on 2026-08-27 00:04:13
- sym-strata-ui inherited from [3e3ad17751]
|
2026-08-27
| ||
| 00:04 | • Edit [02f6aadcad]: Mark "Closed". artifact: be66bb0482 user: dmestas | |
| 00:03 |
Landings: a strata is one row, and a map on the record
The open queue folds a stack under its base: a strata mark, the segment count, the landable end named, and the rungs in a details element with 1/N badges — no script. Settled views stay flat; a settled segment has left its chain. The record page draws the map: every rung bottom-up, this one marked, the landable one named, a rejected base as a broken rung. Above the bottom the accept control is disabled and says the segment below lands first. Proved with a real zit: two stacked landings count one decision; the top rung's accept is refused; accepting the base retargets the next onto trunk and it becomes the landable end, still one decision. closed check-in: 02f6aadcad user: dmestas tags: strata-ui | |
| 00:03 |
RFC 0006: the strata is derived, and the queue counts decisions
AttachStrata reads the chain from target -> branch across landings: base, position, depth, and why a chain cannot be walked — a cycle, or a rejected base. Derived at read time, never stored, so a segment retargeted by zit#144 after its base lands simply stops being one. landing.list carries the reading and counts DECISIONS: a stack of five is one, the base's, because nothing above it can be acted on. landing.get carries the chain for the record's map and reports a rung above the bottom as stacked, which the merge probe must not overwrite: its answer is true and useless there. check-in: 3e3ad17751 user: dmestas tags: strata-ui | |