The emulator complained "Sibling order 2 is used more than once" 74 times
in production, covering 19 pages across 12 parents. The cause was that
nearly every page-creation path passed orderNum 0, so each new page
collided with whatever sibling already sat at 0 or 1, and the Park
placeholder pages all shared the sentinel values 99 and 999.
The production rows themselves are repaired out of band (renumbered 1..N
per affected parent, ordered by order_num then id so the existing visual
order is preserved, plus one dangling catalog_items row whose
items_base no longer existed removed). This commit stops it recurring.
- hierarchy.ts: add nextFreeSiblingOrder(), which ignores -1 and 0 as
the same root set, treats a missing orderNum as 0, and returns an order
strictly above the highest sibling in use. An explicit order is still
honoured whenever it is free, so callers that genuinely want a position
keep it.
- page-commands.ts: createPageCommand resolves the real order through
nextFreeSiblingOrder instead of writing the requested 0 straight through.
Note that furni-import.ts and upload-import.ts still take their order
from the furnidata catInfo.order, so two categories carrying the same
furnidata order can still collide. That is caught by the emulator audit
and repaired by fixEmulatorIssues(), but it is not prevented here.
openhands
4be7eaed59