Map: what the plan has that the build lacks (audit, 2026-10-28)

claude-bot commented

2026-10-28 15:13:51 +00:00

Collaborator

The owner asked (2026-10-28), before cutting v4.6.2: "recheck the original plan for the markers and the map and make sure nothing else was forgotten or dropped."

This is a read-only audit of main at v4.6.1 (cd79fd1c) against the plan.

Plan sources: #593 (body and all comments), #734, CATALOGUE WIKI-11/WIKI-12 and the map D-rows, coverage/lane6d.py (which marks every WIKI-11 row except IS-489/490 as drawn, and #734 requires drawn rows to be built), the prototype lane6d.html and shared/wiki.js.

Code checked: routers/maps.py, map_service.py, map_audience.py, models/map.py, atlas_archive.py, the maps migration, Map.jsx, MapCanvas.jsx, OnTheMap.jsx, WhereParty.jsx, Party.jsx, WikiText.jsx.

The only written departures are a code comment at Map.jsx:21-26: no move or rename, travel links only through the API, and the filter not remembered. They were never recorded as a decision.

A. Breaks, or leaves bad data

Removing a marker that is a trail stop fails with a 500. Stops saved from "Where the party ended…" carry only marker_id. trail_stops.marker_id is ON DELETE SET NULL, and ck_trail_stops_where needs marker_id or (map_id, x, y), so the DELETE violates the check. Verified: prod has 5 stops, all marker_id only. No test covers it.
A failed "Add a map" leaves an orphan. createMap (and createAtlas) run before the upload. A refused picture leaves a map with no picture, and Retry or resubmitting makes another map (and atlas) each time. None of them can be deleted.

B. The UI offers something it can't do

A marker can't be linked to its wiki page, or edited. This is #1260. Every "On the map" section, and quest "where" (IS-102), is empty for markers made in the UI.
"A travel link" kind: offered to the GM, but no UI makes the link. The "Link the stair to another map" dialog was drawn but not built, and there is no delete. Links are table-only.
"A holding" kind: offered, but names no group. org_entry_id has no UI, there is no "Held by", and there is no per-group filter (IS-087).
Linking a marker to an existing map (child_map_id) has no UI. Only "Add a map → Inside" links a new map.
There's no way to give a map its picture again, though the server's failure text tells the GM to "add its picture again". IS-489/490 lead there.
Maps become unreachable: a second top-level map in an atlas, or a child map whose opening marker is removed. There's no map list, and no rename or delete of a map or atlas.
Trail: waypoints don't link to their session (IS-077), and a wrong stop can't be removed (no route or UI).
The GM's copy shows whose a player's marker is, and how private it is, only for notes (IS-076: "the GM always sees every marker, labelled as such").

C. Planned or drawn, not built

A GM-only map or atlas from the UI: AddMapForm sends no audience (D193; the server supports it).
The party's location carrying up to the region and world maps (#593).
The trail drawn across portals and underground hops (IS-078); it's drawn only within one map.
Label collision between always-on labels (IS-082), and the party marker's own popover.
Scale labels ("Region", "Town") on the crumbs, a "+" on markers that open a map, and "No map of this place yet. Its marker opens the page".
Second parties (D168): a player's "The party" always means the main party; only the main party's trail.
The party page showing location and trail (IS-112); the front page shows a line, not a map (IS-124).
The ![[Map: X]] embed (IS-043).
Moving a marker, and changing a marker's audience after the reveal Undo is gone.
A filter per group, and remembering the filter (IS-079).

Deferred in writing

The Surface/Underground switch (#593, IS-073).
Trail suggestions from the event log (#593 "Later").
Moving a marker, in #1260.

The full table, with file and line evidence per row, was produced in-session and is summarised above.

**The owner asked (2026-10-28), before cutting v4.6.2:** "recheck the original plan for the markers and the map and make sure nothing else was forgotten or dropped." This is a read-only audit of `main` at v4.6.1 (cd79fd1c) against the plan. **Plan sources:** #593 (body and all comments), #734, CATALOGUE WIKI-11/WIKI-12 and the map D-rows, `coverage/lane6d.py` (which marks every WIKI-11 row except IS-489/490 as **drawn**, and #734 requires drawn rows to be built), the prototype `lane6d.html` and `shared/wiki.js`. **Code checked:** `routers/maps.py`, `map_service.py`, `map_audience.py`, `models/map.py`, `atlas_archive.py`, the maps migration, `Map.jsx`, `MapCanvas.jsx`, `OnTheMap.jsx`, `WhereParty.jsx`, `Party.jsx`, `WikiText.jsx`. The only written departures are a code comment at `Map.jsx:21-26`: no move or rename, travel links only through the API, and the filter not remembered. They were never recorded as a decision. ## A. Breaks, or leaves bad data 1. **Removing a marker that is a trail stop fails with a 500.** Stops saved from "Where the party ended…" carry only `marker_id`. `trail_stops.marker_id` is `ON DELETE SET NULL`, and `ck_trail_stops_where` needs `marker_id` or `(map_id, x, y)`, so the DELETE violates the check. *Verified:* prod has 5 stops, all `marker_id` only. No test covers it. 2. **A failed "Add a map" leaves an orphan.** `createMap` (and `createAtlas`) run before the upload. A refused picture leaves a map with no picture, and Retry or resubmitting makes another map (and atlas) each time. None of them can be deleted. ## B. The UI offers something it can't do 3. **A marker can't be linked to its wiki page, or edited.** This is #1260. Every "On the map" section, and quest "where" (IS-102), is empty for markers made in the UI. 4. **"A travel link" kind:** offered to the GM, but no UI makes the link. The "Link the stair to another map" dialog was drawn but not built, and there is no delete. Links are table-only. 5. **"A holding" kind:** offered, but names no group. `org_entry_id` has no UI, there is no "Held by", and there is no per-group filter (IS-087). 6. **Linking a marker to an existing map** (`child_map_id`) has no UI. Only "Add a map → Inside" links a *new* map. 7. **There's no way to give a map its picture again,** though the server's failure text tells the GM to "add its picture again". IS-489/490 lead there. 8. **Maps become unreachable:** a second top-level map in an atlas, or a child map whose opening marker is removed. There's no map list, and no rename or delete of a map or atlas. 9. **Trail:** waypoints don't link to their session (IS-077), and a wrong stop can't be removed (no route or UI). 10. **The GM's copy** shows whose a player's marker is, and how private it is, only for notes (IS-076: "the GM always sees every marker, labelled as such"). ## C. Planned or drawn, not built 11. A GM-only map or atlas from the UI: `AddMapForm` sends no audience (D193; the server supports it). 12. The party's location carrying up to the region and world maps (#593). 13. The trail drawn across portals and underground hops (IS-078); it's drawn only within one map. 14. Label collision between always-on labels (IS-082), and the party marker's own popover. 15. Scale labels ("Region", "Town") on the crumbs, a "+" on markers that open a map, and "No map of this place yet. Its marker opens the page". 16. Second parties (D168): a player's "The party" always means the main party; only the main party's trail. 17. The party page showing location and trail (IS-112); the front page shows a line, not a map (IS-124). 18. The `![[Map: X]]` embed (IS-043). 19. Moving a marker, and changing a marker's audience after the reveal Undo is gone. 20. A filter per group, and remembering the filter (IS-079). ## Deferred in writing - The Surface/Underground switch (#593, IS-073). - Trail suggestions from the event log (#593 "Later"). - Moving a marker, in #1260. The full table, with file and line evidence per row, was produced in-session and is summarised above.

claude-bot added this to the v4.6.2 - The map, as planned milestone

2026-10-28 15:26:00 +00:00

claude-bot commented

2026-10-28 15:28:09 +00:00

Author

Collaborator

Owner's decisions, 2026-10-28:

v4.6.2 covers all of A, B and C. It's a point release, because it fixes planned functionality that was dropped.
Deleting a map or atlas sends it to a bin with restore, like wiki pages (#408) and campaigns (#405), and it's purged after the grace period. No reason was ever recorded for leaving delete out: the FKs already cascade, and only the route and UI were missing.
Build first, review on dev. The new controls reuse existing patterns. The owner reviews them on the 4.6.2 rc.

Build plan. One integration branch integ/4.6.2, with #1260 and #1261 included.

Server (qb-implementer, branch fix/1263-map-server):
- PATCH marker (label, line, kind, page, opens-map, held-by, x/y, and audience for a GM).
- A trail stop made from a marker also stores that marker's map/x/y, plus a migration that backfills existing stops (this fixes A1).
- DELETE for a trail stop and for a travel link; an audience on links.
- PATCH map and atlas (name, scale label, audience, parent/root).
- Soft delete for maps and atlases (deleted_at/deleted_by_id): a bin listing, restore, and a purge task that also removes the picture and tiles.
- Reads exclude binned rows. _check_marker_links refuses binned pages and maps.
App, part 1 (qb-frontend, files outside Map.jsx):
- ![[Map: X]] embed in WikiText.
- Label collision and a "+" badge in MapCanvas.
- The party page's location and trail.
- "Holdings on the map" in OnTheMap.
App, part 2 (qb-frontend, Map.jsx, after 1):
- Marker edit/move, the page/holding/existing-map pickers, the travel-link dialog and removal, what the GM sees on player markers.
- The map list with rename/delete, the bin view and restore.
- Re-upload a picture; the Add-a-map retry fix (A2); GM-only map/atlas; scale label.
- Trail stops linked to their sessions and removable.
- Second parties (D168); the party location carried up; the trail across links; the party marker's popover; a remembered filter.
Then: verification, wording rows on the owner's Wording Review page, CATALOGUE rows, rc on dev, owner review, final, and prod on the owner's say.

**Owner's decisions, 2026-10-28:** - **v4.6.2 covers all of A, B and C.** It's a point release, because it fixes planned functionality that was dropped. - **Deleting a map or atlas sends it to a bin** with restore, like wiki pages (#408) and campaigns (#405), and it's purged after the grace period. No reason was ever recorded for leaving delete out: the FKs already cascade, and only the route and UI were missing. - **Build first, review on dev.** The new controls reuse existing patterns. The owner reviews them on the 4.6.2 rc. **Build plan.** One integration branch `integ/4.6.2`, with #1260 and #1261 included. 1. **Server** (qb-implementer, branch `fix/1263-map-server`): - `PATCH` marker (label, line, kind, page, opens-map, held-by, x/y, and audience for a GM). - A trail stop made from a marker also stores that marker's map/x/y, plus a migration that backfills existing stops (this fixes A1). - `DELETE` for a trail stop and for a travel link; an audience on links. - `PATCH` map and atlas (name, scale label, audience, parent/root). - Soft delete for maps and atlases (`deleted_at`/`deleted_by_id`): a bin listing, restore, and a purge task that also removes the picture and tiles. - Reads exclude binned rows. `_check_marker_links` refuses binned pages and maps. 2. **App, part 1** (qb-frontend, files outside `Map.jsx`): - `![[Map: X]]` embed in `WikiText`. - Label collision and a "+" badge in `MapCanvas`. - The party page's location and trail. - "Holdings on the map" in `OnTheMap`. 3. **App, part 2** (qb-frontend, `Map.jsx`, after 1): - Marker edit/move, the page/holding/existing-map pickers, the travel-link dialog and removal, what the GM sees on player markers. - The map list with rename/delete, the bin view and restore. - Re-upload a picture; the Add-a-map retry fix (A2); GM-only map/atlas; scale label. - Trail stops linked to their sessions and removable. - Second parties (D168); the party location carried up; the trail across links; the party marker's popover; a remembered filter. 4. Then: verification, wording rows on the owner's Wording Review page, CATALOGUE rows, rc on dev, owner review, final, and prod on the owner's say.