A notebook opens in its own order

The hand-made order is where a notebook's own arrangement lives:
separators show, rows can be put where they belong, nothing slides about
by itself. Starting in "last changed" made both of those look broken
until the sort menu was found — pressing "+ Separator" there drew a line
the order cannot display, so the button appeared dead. A notebook nobody
has arranged still reads newest-first, because untouched rows all carry
position 0, so nothing is lost by starting there. The views keep "last
changed": they are questions asked of every notebook at once and have
nowhere to keep an arrangement. The button that draws a line is now only
offered in the order that can show one.

Removing a chapter left you stuck in the confirmation. Every destructive
action goes through one helper that takes the question down again; this
one set the dialog directly and bypassed it, so the chapter was removed
and the prompt stayed over the app. Closing now happens where the dialog
is rendered, so it happens whoever asked and however they asked.

The suites did not catch that, and the reason is worth keeping: they
read the list straight through the overlay, which is in the DOM the
whole time, and passed while the screen was in fact stuck. Both now
assert the question is gone afterwards.

The separator is no wider than its name. It sat in a fixed 132px slot —
chosen so the row would not jump when renaming began — with a short name
floating in a gap it did not fill.

Thirteen suites green: 345 browser checks, 241 unit tests.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
marcandClaude Opus 5 committed 2026-08-12 21:45:03 +02:00
1 parent cc0b58dd2f
commit c96885d5b3
9 files changed
+223 -69

No files matched your search

+33
View File
@@ -8,6 +8,39 @@ not from the output of `docker push`.
---
## 2026-08-12 — A notebook opens in its own order
**Images** — web `sha256:…`, server unchanged in substance
**Fixed**
- **Removing a chapter left you stuck in the confirmation.** Every destructive
action goes through one helper that takes the question down again; this one
set the dialog directly and bypassed it, so the chapter was removed and the
prompt stayed over the app with nothing but a reload to get out of. Closing is
now done where the dialog is rendered, so it happens whoever asked.
The suites had **checked the list straight through the overlay** — which is in
the DOM the whole time — and passed. Both now assert the question is gone.
- **The separator button appeared to do nothing** in any order but the hand-made
one, because that is the only order a line shows in. The button is now only
there in that order.
**Changed**
- **A notebook starts in the hand-made order.** That is where its own
arrangement lives — lines show, rows can be dragged into place. A notebook
nobody has arranged still reads newest-first, since untouched rows share
position 0. The views ("All Notes", "Starred", the bin) keep "last changed":
they are questions asked of every notebook at once and have nowhere to keep an
arrangement.
- **The separator is smaller and no wider than its name.** The label sat in a
fixed 132px slot — chosen so the row would not jump when renaming began — with
a short name floating in a gap it did not fill. It is sized to the name now,
between a floor and a ceiling, with less room above it and smaller type.
- **A chapter has one menu entry for its name and colour**, not two. The
"Colour" submenu sat beside "Rename" offering half of what the dialog already
does, and read as a different thing.
---
## 2026-08-12 — A chapter you can see, in the colour you chose
**Images** — web `sha256:65799ecb…`, server `sha256:a51b96ad…`