Ebene auf einmal sortieren, verwaiste Placements aufräumen

[usekaneo]

Zwei bekannte Einschränkungen der 31818-Platzierung: Die Ordnung liegt pro Seite, also lässt sich eine ganze Ebene nicht in einem Zug sortieren — jede verschobene Seite braucht eine eigene Signatur. Und nichts räumt die Platzierung einer gelöschten Seite auf; ein 31818 ohne Revisionen wird ignoriert, ist also träge statt schädlich.

Aufgabe: Sammelsortierung einer Ebene (mehrere Placements in einem Rutsch signieren) und Aufräumen verwaister Placements — sinnvollerweise zusammen mit dem Tombstone-Ticket.

Quelle: docs/02-data-model-events.md (zwei „Open"-Punkte zur Sortierung)

---

_{Task: al2ddd2icfc4jbkitai1wxoi}

[usekaneo]

CON-21

[usekaneo]

**** commented:

Technical refinement

Status: ready, but two clarifications up front. (1) 'sign several placements in one go' cannot reduce the number of signatures: NIP-07 signs one event per call and each 31818 is its own event. What it can do is make it one user action with a consistent snapshot and honest partial-failure reporting. (2) Cleaning up orphaned placements is mostly hygiene — a placement whose slug has no revisions is already ignored (src/domain/pages.ts), and the tombstone ticket (CON-11) filters removed pages at the consumer level.

What exists today

• publishPlacement (src/nostr/publish-placement.ts) publishes exactly one 31818 for one (pubkey, slug); a move replaces that author's previous event, so a retry is naturally idempotent.
• useMovePage (src/ui/move-page.ts) does the subtree/no-op checks and calls it once. The sidebar computes per-gesture keys with keyBetween (src/domain/order.ts).
• buildPages prefers a placement over the revision's initial tags; a page with no order sorts by its normalised title. This is the key fact for batch sorting: clearing order makes a level sort by title.
• SpaceStore keeps only the winning placement per slug (placements map) — enough for the tree, not enough to enumerate orphans.
• docs/02 names both gaps as Open: 'the order is per page, so a level cannot be sorted in one go' and 'nothing cleans up the placement of a deleted page'.

Approach — batch reordering

1. Two operations, both one action:
   • Sort level by title: for every sibling of the level, publish a placement with the current parent and order: null. That is the whole algorithm — the implicit key is the normalised title, so the level sorts alphabetically without inventing keys. It also removes order keys that no longer mean anything.
   • Apply a manual order: compute one key per sibling up front from the current sibling list (walk keyBetween(prev, next) over the new sequence), then publish one placement per page with the computed key. Computing all keys from the same snapshot is what makes the result consistent; publishing them one at a time from stale state is how a level ends up interleaved.
2. A single batch publisher publishPlacements(signer, { relayUrl, groupId, items }) next to publishPlacement: labels each item, publishes sequentially, collects per-item { slug, ok, reason }. Do not fire them concurrently — the relay's answer for page B should not race the UI's busy state for page A, and sequential keeps the error honest.
3. Partial failures are the normal case, not an edge. If some pages succeed and some are refused, the level is half-sorted. The UI must list exactly which slugs failed with their reason and offer a retry of just those; a retry is safe because each placement replaces the previous one for that author. If the failure is permission, stop the batch — every remaining publish would fail the same way.
4. Where it lives. A 'Sort level' entry in the tree heading menu (CON-15's menu) and/or the Space settings page. It is a write, so it is gated on spaceAccess === 'member' and checked with ensureSamePubkey once before the first signature.

Approach — orphan cleanup

5. Find the orphans. The store's winner-only view cannot see them, so the action does one bounded read: all 31818 with #h=groupId, then group by slug. A placement is orphaned when its slug has no page (no revision at all) or only tombstoned pages (CON-11).
6. Remove what the viewer may remove, report the rest. A user may delete only their own placement (NIP-09 kind 5, CON-10); an admin may 9005 any. So the action is best-effort by construction: it removes the viewer's own orphans (and an admin's, if they ask), and lists the remaining ones owned by others as 'cannot remove'. Do not silently claim a clean level.
7. Do not invent a deletion tag. An addressable 'removed' placement would be a fourth state to reason about; NIP-09/9005 on the event is the model the project already chose. If the relay turns out to ignore kind 5 in groups, 9005 (admin) is the fallback — which is exactly why the cleanup is an admin/maintenance action, not something every member is nudged into.
8. Run it together with CON-11. Tombstoning a page is the moment an orphan is created; offering 'also remove the placement' right there (for the viewer's own placement) closes the loop while the user is thinking about it. The standalone maintenance action covers the backlog.

Subtasks

• publishPlacements batch helper with per-item results and stop-on-permission
• 'Sort level by title' (order = null) and 'apply manual order' (precomputed keys)
• Batch UI with per-slug progress and a partial-failure list + retry
• Orphan read (31818 by #h) + removal via CON-10's kind 5 / 9005, with an explicit 'cannot remove' list
• Hook 'remove my placement' into the tombstone flow (CON-11)
• Tests: key computation for a batch, partial-failure reporting, orphan detection incl. tombstoned slugs
• Docs: docs/02 both Open items, docs/06 sort entry, CON-11 cross-reference

Acceptance criteria

• 'Sort level by title' makes the level alphabetical in one action, with one signature per sibling and a clear progress/result.
• A manual batch order produces a level no client would order differently (every key computed from one snapshot).
• If some publishes fail, exactly the failed slugs are listed with the relay's reason, and retrying only those fixes the level without duplicates.
• The cleanup finds placements whose slug has no live page and removes the ones the viewer is allowed to remove; it reports the others instead of pretending they are gone.
• No placement operation changes any revision or head.

Risks / open decisions

• Cost is linear in pages: sorting a 50-page level is 50 signatures and 50 publishes. Acceptable for a deliberate maintenance action, not for a hover affordance; the UI must say how many signatures it will ask for first.
• Cross-author placement churn: a batch by one member leaves winning events only for slugs where their event is newest; older winners by others are superseded but remain. That is the existing last-writer-wins model, not a new problem.
• Concurrent sorting: two people sorting the same level at once interleave per page. A merge is impossible for positions; the honest answer is last-writer-wins with the id tie-break (docs/02), and the UI should not promise atomicity.
• Relay support for kind 5 in groups is unverified (CON-10); the cleanup may be reduced to 'admin only via 9005' in practice.

Depends on / relates to

CON-10 (deletion helper), CON-11 (tombstone creates the orphans), CON-15 (menu entry point), docs/02 (open items), docs/06.

[usekaneo]

**** commented:

Reviewed in worktree .worktrees/con-21 (feat/con-21-sort-level-and-orphan-placements @ 18c0034). Verification run for this review on that worktree: npm run typecheck, npm run lint, npm test, npm run build — all four pass.

Review — CON-21: "Ebene auf einmal sortieren, verwaiste Placements aufräumen"

Verdict

❌ Changes requested — the orphan-cleanup half and the "clear the keys instead of computing new ones" approach are sound, well-reasoned and well documented. But the batch-sort half silently skips visible pages in a reachable case, which is exactly the failure its own comment says must never happen (Finding 1). That is the only must-fix; everything else is polish.

Summary

The change adds two maintenance actions under Space settings → Page tree (src/ui/PageTreeMaintenance.tsx). "Sort by title" re-signs a placement (kind 31818) for every page in one level that still carries an explicit page-order key, with the key omitted so the level falls back to title order — avoiding one signature per page and not freezing today's alphabet into the data. A second panel lists placements whose slug has no revisions left (orphanPlacements in SpaceStore), and offers a NIP-09 kind 5 naming the placement by <kind>:<pubkey>:<d> address (only one's own, only when the slug has no revisions). docs/02-data-model-events.md replaces the two "Open" points with a written rationale.

Acceptance criteria

• Batch-sort a level, one signature per page that actually needs it. sortLevelByTitle (src/domain/sort-level.ts:55-62) returns only pages with a key; PageTreeMaintenance signs them sequentially and stops on the first refusal (src/ui/PageTreeMaintenance.tsx:86-121); mounted at src/routes/SpaceSettings.tsx:199-206. Works, but see Finding 1 for pages it misses.
• Orphaned placements are surfaced. SpaceStore.rebuildPages computes orphanPlacements from placements whose slug has no revisions (src/nostr/space-store.ts:155-163), exposed on SpaceSnapshot (src/nostr/space-store.ts:33-40) and rendered (src/ui/PageTreeMaintenance.tsx:208-240).
• Cleanup is a NIP-09 request naming the address, not an event id. placementAddress / publishPlacementDeletion (src/nostr/publish-deletion.ts:60-94); TAGS.DELETED_ADDRESS added in the one allowed place (src/nostr/kinds.ts:111-116).
• Both gates are enforced client-side. Own author only (src/nostr/space-store.ts:182,184) and no-revisions only (src/nostr/space-store.ts:183), with a regression test that a stale request cannot unplace a page that came back (src/nostr/space-store.test.ts:526-544).
• The two "Open" points in docs/02-data-model-events.md are closed. docs/02-data-model-events.md:257-289.
• Tests for the new domain/publish/store behaviour. src/domain/sort-level.test.ts, src/nostr/publish-deletion.placement.test.ts, src/nostr/space-store.test.ts:456-544, src/domain/deletion.test.ts:95-129. Meaningful, but incomplete (see Tests).

Findings

Must fix before merge

1. [major] The sort groups by "a page exists", not by "a page is visible" — it silently skips the visible children of a hidden page.
src/domain/sort-level.ts:29-32:

function effectiveParent(pages: Page[], page: Page): string | null {
  if (!page.parentSlug || page.parentSlug === page.slug) return null
  return pages.some((entry) => entry.slug === page.parentSlug) ? page.parentSlug : null
}

The docstring above it claims this is "the level a page is actually drawn in", and calls out a missing parent. But buildTree draws by a different rule: it excludes hidden pages from the node map first, so any page whose parent is hidden comes up to the top level (src/domain/pages.ts:177-189; verified by the existing test src/domain/pages.test.ts:400-412, "does not take its subpages with it — they come up to the top level"). effectiveParent only tests pages.some(...), and pages includes hidden pages, so it returns the hidden parent's slug.

Consequences, all reachable by tombstoning a page that has subpages:

• Those subpages are drawn at the top level but are grouped into the hidden page's level. Selecting "Top level" and sorting does not clear their keys, so a page the user can see keeps its stale position — precisely the case the comment at lines 25-27 says must not happen ("sorting the top level would quietly skip a page sitting in it, which is the one thing a 'sort this level' action must not do").
• The picker offers a level named after a page that is nowhere in the tree (src/domain/sort-level.ts:107-118), and its count is the number of pages actually drawn at top level.
• The top level's page count, previewLevelOrder ("Afterwards: …") and the set of keys that would be cleared are all wrong for the same reason.
• The existing test covers the vanished parent (src/domain/sort-level.test.ts:126-136, "counts a page with a vanished parent into the top level") but not the hidden parent, which is the case where pages.some is true.

Suggested fix: make the two functions agree, e.g.

const parent = pages.find((entry) => entry.slug === page.parentSlug)
return parent && !parent.hidden ? page.parentSlug : null

Note this deliberately resolves the tension with the comment at lines 80-85 ("so it also names a level under a hidden page … sortable for the day the parent comes back"): that offering is what makes the top level wrong, because a page cannot be counted in two levels. Matching buildTree is the honest rule — "sort the level as you see it". Add a regression test mirroring pages.test.ts:400: a keyed child of a hidden parent must appear in the top level and be returned by sortLevelByTitle(pages, null).

Nice to have

2. [minor] A partial sort failure hides what actually landed.
src/ui/PageTreeMaintenance.tsx:116-120 records the count of successful signatures in done, but the render gate is {done && !error ? …} (src/ui/PageTreeMaintenance.tsx:248). Because the loop sets error and breaks before done can show, a run that sorted 3 of 5 pages reports only "That did not work" — the user cannot tell that three placements were already rewritten, and the level is left half-sorted. This also contradicts the documentation, which claims "the first refusal stops the run (a half-sorted level is worse than an unsorted one)" (docs/02-data-model-events.md:262); the code stops after a partial success, i.e. it does produce a half-sorted level. Either fold landed into the error message ("3 of 5 were rewritten before this stopped") or stop before the first publish if any is unacceptable. levelNeedsSorting would not help here; the honest message is the fix.

3. [minor] The batch sort is admin-only, while moving a single page is not.
The panel lives in SpaceSettings, which returns early for anyone who is not an admin (src/routes/SpaceSettings.tsx:79-96). Dragging one page, which signs the same 31818 placement through the same publishPlacement, is enabled for every signed-in member (src/ui/layout/Sidebar.tsx:193, src/ui/move-page.ts:39-43). So an ordinary member can move pages one at a time but cannot re-sort a level. docs/02 justifies the location ("rare" action) but not the admin restriction. If that is intentional it should be stated; otherwise the control needs a non-admin home (or SpaceSettings needs to render it for members too).

4. [minor] Two deletion tests are misnamed or redundant.
src/domain/deletion.test.ts:113 is titled "still refuses a request that names only kinds of ours" but supplies [TAGS.DELETED_KIND, '1'] — kind 1 is not ours, so it asserts the same thing as the existing "rejects a request that names another kind" at line 68, and the scenario in its title is never tested. Also src/domain/deletion.test.ts:127-129 duplicates the existing "rejects a request that names no target" at lines 91-93. Rename the first (e.g. "refuses a request whose kinds are all foreign") and drop the duplicate, or give the title's scenario a real case (our kinds, no usable target).

5. [minor] The batch loop itself has no test.
Other interactive components do (src/ui/PageEditor.test.tsx, src/routes/SpaceSettings.test.tsx, src/ui/SpaceHiddenNotice.test.tsx), and the new component carries the only nontrivial control flow: stop-on-first-refusal, the partial-success count (Finding 2), the signed-out guard and the "mine vs theirs" split. Only the pure domain functions are covered. A small PageTreeMaintenance.test.tsx with mocked publishPlacement would pin Finding 2 and the loop.

6. [nit] levelNeedsSorting and SortableLevel.keyed are dead in the app.
Both are exported/computed but read only by tests (src/domain/sort-level.ts:65-67 and :77,116; the UI renders entry.pages, not keyed). Either display keyed (it is genuinely useful — "3 pages carry a position") or drop it to keep the module honest.

7. [nit] Address parsing truncates a d that contains a colon.
src/nostr/space-store.ts:180 does const [kind, pubkey, slug] = address.split(':'). Slugs produced by normalizeSlug cannot contain :, but parsePlacement does not normalise the d tag (src/domain/placement.ts:45-46), so a placement from another client with such a slug produces 31818:<pk>:a:b, parses as slug a, and can never be matched for cleanup. Splitting off only the first two colons (kind and pubkey are colon-free by construction) makes this robust.

8. [nit] "Clean up 0 of mine" is rendered when only other authors' orphans exist.
src/ui/PageTreeMaintenance.tsx:219-225 always renders the button when orphanPlacements.length > 0; with mine.length === 0 the label reads Clean up 0 of mine (disabled). Hiding the button in that case, or labelling it "Nothing of yours to clean up", reads better.

Docs

• docs/02-data-model-events.md:257-289 is accurate and unusually good: it explains why clearing beats handing out fresh keys, and mirrors the two gates. The only inaccuracy is line 262 ("a half-sorted level is worse than an unsorted one") versus the code's actual stop-after-partial-success behaviour (Finding 2).
• src/routes/SpaceSettings.tsx:199-206 is the only place the docs' "space settings under Page tree" claim can land, and it is admin-gated (Finding 3).
• docs/09-security-privacy.md:28-33 still says the client honours a NIP-09 request "only for the requester's own revision"; the placement path added here is a second honoured target and the paragraph should say so. This is the security/privacy statement of the honour rule, so leaving it stale is more than cosmetic.
• NOSTR.md NIP-09 and kind-5 rows are updated accurately (they correctly explain that a is the only way to name an addressable event). docs/05-versioning-history.md:121-125 already points to 02 for the genuinely orphaned case and needed no change.

Tests

• Would they fail against a dummy? Yes for the parts they cover: the store tests assert concrete orphanPlacements contents that an empty/no-op implementation cannot satisfy (src/nostr/space-store.test.ts:490-544), and publish-deletion.placement.test.ts asserts the exact tags and a parser round-trip. sort-level.test.ts pins the key-clearing, per-level scoping, parentage preservation and the vanished-parent grouping.
• Covered edge cases: hidden page itself included (src/domain/sort-level.test.ts:80-88), parent cycle does not hang (:138-141), address-only deletion parses (src/domain/deletion.test.ts:95-111), only the placement's author may delete (src/nostr/space-store.test.ts:512-524), a request is ignored once the slug has revisions again (:526-544).
• Missing: (a) the hidden-parent grouping (Finding 1) — the single most valuable missing case; (b) a component test for the batch loop and its partial-failure reporting (Finding 5); (c) a case where two authors have placements for the same orphaned slug — the store keeps only the winner, so a shadowed author can never clean up their own stale event even though the UI wording implies only the other author's is unreachable. Worth deciding explicitly, even if the answer is "acceptable, the winner is the only one that matters".

What is good

• The core insight is right and clearly argued: with no batch signing in NIP-07, "sort" should remove keys rather than compute new ones, so only keyed pages are rewritten and a later rename still moves the page. sortLevelByTitle implements exactly that, and the domain test pins it.
• Carrying the page's own parentSlug through a sort rather than the effective one (src/domain/sort-level.ts:58-61) is a subtle, correct separation of "position" from "parentage", and it is tested.
• The cleanup gates are the right two, explained honestly as client-side because the relay enforces neither, and they are tested against the exact attack the docs describe (a request from someone who is not the placement's author, and a stale request against a page that came back).
• Deriving orphanPlacements on every rebuild instead of storing a second index (src/nostr/space-store.ts:155-163,176-189) keeps the result independent of event arrival order, consistent with effectiveDeleted.
• The publish path names the address, not an event id, and the parser round-trip test proves the two agree.

[usekaneo]

**** commented:

Worked in .worktrees/con-21 (feat/con-21-sort-level-and-orphan-placements @ 18c0034). Changes are left uncommitted in the working tree for review. Verification after the changes: npm run typecheck, npm run lint, npm test, npm run build — all four pass (511 tests, 50 files).

Review response — CON-21

Every finding was checked against the code before acting on it. All of them held up; one did not need a code change (Finding 3, a design decision — see Open decisions). One hazard the review did not raise is fixed as well (Finding 9 below).

Findings

1. [major] Grouping by "a page exists" instead of "a page is visible" — fixed

Verified. buildTree (src/domain/pages.ts) removes hidden pages from its node map before it hangs anything, so a child of a hidden page becomes a root — pinned by the existing pages.test.ts case "does not take its subpages with it — they come up to the top level". effectiveParent only asked pages.some(...), and pages contains hidden pages, so it returned the hidden parent's slug. Reachable by tombstoning any page that has subpages: the child is drawn at the top level but grouped into an invisible one, so "sort the top level" skipped it, and the picker offered a level named after a page that is nowhere in the tree.

Changed src/domain/sort-level.ts: effectiveParent now resolves the parent and treats a hidden one as absent, matching buildTree. The docstring explains the buildTree rule it has to agree with, and the sortableLevels comment that previously justified offering a level under a hidden page was rewritten — a page cannot be counted in two levels, and a hidden member of a level (still included, deliberately) is a different thing from a hidden parent (not offered).

Regression test src/domain/sort-level.test.ts, "sorts the child of a hidden parent with the top level, where it is drawn". Confirmed to fail against the unfixed function (expected [] to deeply equal [ 'onboarding' ]) and pass after. It also asserts the parentage is still not repaired, and that the hidden page is not offered as a level.

2. [minor] A partial sort failure hid what had landed — fixed

Verified. done was set after the loop, but the render gate was {done && !error}, so a run that rewrote 3 of 5 and then hit a refusal reported only "That did not work". The user could not tell the level was half sorted, nor that re-running was safe.

Changed src/ui/PageTreeMaintenance.tsx: both loops now collect failure instead of setting it mid-loop, and the failure message folds in what already landed ("… — but 1 of 4 had already been rewritten, so this level is half sorted. Sorting it again picks up where this stopped."). The cleanup loop does the same. done and error are now mutually exclusive by construction, so the gate is plain {done}. Re-running is genuinely safe and the message says so: a placement replaces the author's previous one, and only pages that still carry a key are offered.

Docs: the contradicting sentence in docs/02-data-model-events.md ("a half-sorted level is worse than an unsorted one") is replaced by a description of what the code actually does — stop on first refusal, report what landed, re-running is safe.

Regression test in the new src/ui/PageTreeMaintenance.test.tsx: "stops at the first refusal and says what had already landed" (4 pages, refused on the second). Confirmed to fail against the old reporting — the rendered text was only "That did not work / refused by the relay".

3. [minor] Batch sort is admin-only while a single move is not — not changed, reported as open

Verified, exactly as described. SpaceSettings returns early for non-admins (src/routes/SpaceSettings.tsx), while dragging one page signs the same 31818 through the same publishPlacement and is open to every signed-in member (src/ui/move-page.ts).

This is a product decision about who may re-sort a level, not a defect with one correct fix, so it was not decided here. What was done: docs/02-data-model-events.md now records it as Open, stating that the location was chosen for rarity and not to restrict the action, and that whether the batch sort needs a home members can reach is undecided. See Open decisions.

4. [minor] Misnamed and duplicated deletion tests — fixed

Verified. "still refuses a request that names only kinds of ours" supplied [DELETED_KIND, '1'], which is not one of ours, so it asserted the same thing as "rejects a request that names another kind"; and "refuses a request that names nothing at all" was character-for-character the same case as "rejects a request that names no target".

Changed src/domain/deletion.test.ts: the first is renamed to "refuses a request whose kinds are all foreign, whatever it points at" (its real subject: the k tags decide even when the e tag names an event of ours). The exact duplicate is replaced with the scenario the old title claimed but never tested — a request naming our placement kind with no e and no a — which was genuinely uncovered.

5. [minor] The batch loop had no test — fixed

Added src/ui/PageTreeMaintenance.test.tsx (7 tests), following the mocking pattern of PageEditor.test.tsx. Covers: one placement per keyed page with order: null; stop-on-first-refusal plus the partial-success report (Finding 2); a cancelled signature reporting nothing as written; a level already in title order offering nothing to sign; only the viewer's own orphans being published; no button when none are theirs (Finding 8); and no action at all while loading (Finding 9).

6. [nit] levelNeedsSorting and SortableLevel.keyed dead in the app — fixed, one each way

levelNeedsSorting was dropped: it is exactly sortLevelByTitle(...).length > 0, which is what the UI already computes as pending.length. keyed was kept and is now displayed — the picker labels a level "Top level (5, 3 positioned)", so a level with work to do can be spotted without selecting each one in turn.

7. [nit] Address parsing truncated a d containing a colon — fixed

Verified: parsePlacement does not normalise the d tag, so a placement from another client can carry a colon; address.split(':') destructured into three parts cut the slug short, and that placement could never be matched for cleanup. Changed src/nostr/space-store.ts to take everything after the second colon as the slug (kind and pubkey are colon-free by construction). Test added in src/nostr/space-store.test.ts: "matches a slug that contains a colon, which only the address separates".

8. [nit] "Clean up 0 of mine" — fixed

The button is no longer rendered when none of the orphans belong to the viewer; the sentence explaining whose they are already carries the whole answer. Covered by the new component test.

9. [major, not in the review] The cleanup was destructive while the space was still loading — fixed

Found while checking the review's orphan-cleanup concern. orphanPlacements is recomputed on every event and exposed regardless of loading, and SpaceStore subscribes revisions and placements as separate subscriptions with separate EOSEs (loading turns false only after all five). In the window where placements have arrived and revisions have not, every placement has a slug with no revisions, so the panel listed live pages as stale and "Clean up N of mine" would have signed NIP-09 requests against the positions of pages that exist. That is the one way this screen could destroy something.

Changed: PageTreeMaintenance takes loading and offers neither action until the space is in, with a short explanation instead; SpaceSettings passes space.loading (MemberAdmin next to it already did). Covered by the new component test, and recorded in docs/02-data-model-events.md.

Docs

• docs/02-data-model-events.md: corrected the partial-failure sentence (Finding 2); added the drawn-vs-tagged grouping rule including hidden parents (Finding 1); added the loading guard (Finding 9); added two Open notes (Finding 3, and the shadowed-author case below).
• docs/09-security-privacy.md: the deletion paragraph said the client honours a request "only for the requester's own revision". It now names the placement as the second honoured target, why it is addressed by <kind>:<pubkey>:<d> rather than by id, and both client-side gates. The review was right that leaving this stale is more than cosmetic — it is the security statement of the honour rule.

Open decisions (not decided here)

1. Who may sort a level (Finding 3). Today: admins only, because the panel lives in admin-gated space settings, while any member can move pages one at a time. Either give the batch sort a member-reachable home, or state the restriction as intended. Recorded as Open in docs/02.
2. The shadowed author's orphan (review, Tests (c)). SpaceStore keeps only the winning placement per slug, so when two authors both left one behind for the same gone page, only the winner's is listed — the shadowed author can neither see nor clean up their own stale event, although the UI wording implies only somebody else's is out of reach. Fixing it means a second index per slug for a rare, inert case. Recorded as Open in docs/02 rather than decided.

Verification

Run from .worktrees/con-21:

Command	Result
npm run typecheck	pass (tsc --noEmit, no output)
npm run lint	pass (eslint ., no findings)
npm test	pass — 511 tests, 50 files
npm run build	pass — built in 37.14s (pre-existing chunk-size warning only)

One note on honesty: the first full npm test run had a single failure in src/ui/markdown-live.test.ts ("2 checkboxes, got 1"), a file untouched by this work. It passes in isolation and passed on a second full run; it is a CodeMirror timing flake under parallel load, unrelated to these changes. Recording it rather than quietly re-running.

Files changed (working tree, uncommitted)

• src/domain/sort-level.ts — Findings 1, 6
• src/domain/sort-level.test.ts — Finding 1 regression, Finding 6
• src/ui/PageTreeMaintenance.tsx — Findings 2, 6, 8, 9
• src/ui/PageTreeMaintenance.test.tsx — new, Finding 5 (covers 2, 8, 9)
• src/routes/SpaceSettings.tsx — Finding 9
• src/nostr/space-store.ts — Finding 7
• src/nostr/space-store.test.ts — Finding 7
• src/domain/deletion.test.ts — Finding 4
• docs/02-data-model-events.md, docs/09-security-privacy.md — docs