memory: correct a review point we got wrong, rather than leave it to be re-asserted

We read design-dev's 'SET order' as 'the order they were set in' and told him it
was already (created, id). He meant the SET's order — by tile number — which
genuinely differs: flag #15 then #07 and today's panel lists #15, #07 while his
tray lists #07, #15.

His rule is also cleaner than the one we proposed. The flag set sorted by its
target's position in sorted(rel) is a total order needing no tie-break at all,
because rels are unique. The memory row now says so explicitly and tells the
next session not to re-raise the point.

Round 1's booth is kept; he releases it once the flow ask is ruled.
This commit is contained in:
vh
2026-09-23 07:21:19 -07:00
parent af57933255
commit f87976b54d
+19 -10
View File
@@ -67,19 +67,28 @@ _As of 2026-09-22:_
arc**, **plain-and-direct copy**, **no emblem**. He withdrew his own round-1
`svos` ask as superseded — he did NOT answer anything on the operator's
behalf.
- ⚠ **`booth-svos-retheme` HAS NO HOLD AND WILL SWEEP.** Withdrawing the ask
removed the last open pick and there is no `.forever`. Round 1's renders are
the only rendered baseline to judge round 2 against; they are reproducible
from the staged branch but not one click away. Flagged to him; `booth keep`
is his call, not ours.
- ✅ **`booth-svos-retheme` IS KEPT** — design-dev ran `booth keep` after we
flagged that withdrawing his ask had removed the last hold. Round 1's renders
stay one click away while the operator chooses; he releases it once `flow` is
ruled.
- ✅ **ORDERING REVIEW DONE FOR ROUND 2's SURFACES** (he asked before building).
His **ordinals rule improves invariant 6** — an ordinal that counts across ALL
items makes "#07" stable under every filter, where today "the third one" is
ambiguous the moment a filter is on. Two corrections returned: flag "set
order" IS `(created, id)` because `set_flag` upserts and unflag REMOVES, so no
new field is needed but the tie-break is; and "last activity" must reuse
`_newest_mtime`, whose `.lock` exclusion is load-bearing — a naive `max(mtime)`
lets a no-op mark POST float a dead booth to the top.
ambiguous the moment a filter is on.
⚠ **One correction we sent was WRONG, and the record is corrected here rather
than left to be re-asserted.** We read his "SET order" as "the order they were
set in" and told him it was already `(created, id)`. He meant **the SET's
order — by tile number.** Those genuinely differ: flag #15 then #07, and
today's panel lists #15, #07 while his tray lists #07, #15. His rule is also
cleaner than ours — the flag set sorted by its target's position in
`sorted(rel)` is a **total order needing no tie-break, because rels are
unique.** Do not re-raise the tie-break point; it was our misreading.
The correction that held: **"last activity" must reuse `_newest_mtime`**,
whose `.lock` exclusion is load-bearing — a naive `max(mtime)` lets a no-op
mark POST float a dead booth to the top. Taken, with no second definition of
activity on the Desk.
- 🔶 **SVOS CONCEPT ROUND IS UP AND THREE RULINGS ARE WITH THE OPERATOR**
(booth `booth-svos-retheme`, ask id `svos`: ship / voice / emblem, all three
with design-dev's recommendation attached). **Nothing from us gates it and