jpmschweitzer/settled-reach
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(meta): pql changelog — visual-defect batch closed (T-1186/88/89/92 done, T-1193 filed)

Browse Source 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
jpmschweitzer
2026-07-25 14:46:52 +02:00
co-authored by Claude Fable 5
parent 4a9567c669
commit 0d8984fe53
3 changed files with 50 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.pql/changelog/ticket_history/2026-07.sql
+16
View File
@@ -1924,3 +1924,19 @@ INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, chang
ESCALATION from the T-1183 eyeball captures (2026-07-25, GJ1c, .cache/screenshots/t1183-eyeball-run2/02-region.png): this is NOT a small-body edge case and it is TWO axes, not one. At a 1920x1080 viewport the Region rung requested extent 384x216 cells x 204.8 km = 78,643 x 44,237 km — exceeding even an Earth-class circumference (~40,000 km) roughly 2x horizontally, so the continents repeat side-by-side on EVERY body at Region rung, and the vertical span overruns both poles: rows past the pole clamp to the last row and render as smeared vertical stripes filling the bottom ~40% of the frame (much uglier than the longitude repeat — looks like corrupted data, not a wrapped map). Jeroen flagged the frame as looking broken. Fix shape: cap the Region-rung request extent to the body''s region grid (circumference in the x axis, pole-to-pole in the y axis — both already known client-side from the Global canvas extent echo), letterbox the remainder, and consider the same guard for any rung whose footprint can exceed the body. Priority raised low->high: this makes the Region rung look broken on every body at standard viewports.', NULL, '2026-07-25 10:17:29', '2026-07-25 10:17:29.416', '2026-07-25 10:17:29.416', NULL, '85ba92e8f7082cc30b1a60f86556b714', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8PRRFJQ3Y2V3R348DDRRM', 'priority', 'low', 'high', NULL, '2026-07-25 10:17:39', '2026-07-25 10:17:39.835', '2026-07-25 10:17:39.835', NULL, 'f9ed56ae2da9e57b3a1179fb72112226', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FS5XW0ZMPVYA2CPBBTP88TQC', 'status', 'review', 'done', NULL, '2026-07-25 10:17:42', '2026-07-25 10:17:42.701', '2026-07-25 10:17:42.701', NULL, '4f651c137c2744d831d8b13a786fca08', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSCXX7E3BXT7WG0BYDB6PJA0', 'status', 'backlog', 'in_progress', NULL, '2026-07-25 10:20:01', '2026-07-25 10:20:01.865', '2026-07-25 10:20:01.865', NULL, '6e2c110ed6a2169857c75f628b71ffda', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSHHXXTS56ZBB78N2W43DD2G', 'status', 'backlog', 'in_progress', NULL, '2026-07-25 10:20:01', '2026-07-25 10:20:01.872', '2026-07-25 10:20:01.872', NULL, '108166dfcee0fee7fbb24a50fb5edd0c', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8PRRFJQ3Y2V3R348DDRRM', 'status', 'backlog', 'in_progress', NULL, '2026-07-25 10:20:01', '2026-07-25 10:20:01.872', '2026-07-25 10:20:01.872', NULL, '5d75d4565abe1778b7d3abae4f5f1b18', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8P6C6WXEG3X81PVCQ833M', 'status', 'backlog', 'in_progress', NULL, '2026-07-25 10:20:01', '2026-07-25 10:20:01.872', '2026-07-25 10:20:01.872', NULL, '9e773a4cc2b7b5759f5a994ede489d11', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSCXX7E3BXT7WG0BYDB6PJA0', 'assigned_to', NULL, 'dudley', NULL, '2026-07-25 10:21:12', '2026-07-25 10:21:12.179', '2026-07-25 10:21:12.179', NULL, '1b598b7dd17d56f8b367163dd03555dc', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8P6C6WXEG3X81PVCQ833M', 'assigned_to', NULL, 'dudley', NULL, '2026-07-25 10:21:12', '2026-07-25 10:21:12.182', '2026-07-25 10:21:12.182', NULL, 'f50eca9df80ee1dcef3e403523192bd1', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8PRRFJQ3Y2V3R348DDRRM', 'assigned_to', NULL, 'stig', NULL, '2026-07-25 10:21:12', '2026-07-25 10:21:12.361', '2026-07-25 10:21:12.361', NULL, '99c802490ada7749a3e4279c512733b4', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSHHXXTS56ZBB78N2W43DD2G', 'assigned_to', NULL, 'stig', NULL, '2026-07-25 10:21:12', '2026-07-25 10:21:12.368', '2026-07-25 10:21:12.368', NULL, 'c43a8a611451457c25f6ccefaaecd1a1', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8PRRFJQ3Y2V3R348DDRRM', 'status', 'in_progress', 'review', NULL, '2026-07-25 10:58:29', '2026-07-25 10:58:29.490', '2026-07-25 10:58:29.490', NULL, '0a6a26d03c6502fc627e2ae6d34798ee', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSHHXXTS56ZBB78N2W43DD2G', 'status', 'in_progress', 'review', NULL, '2026-07-25 10:58:29', '2026-07-25 10:58:29.495', '2026-07-25 10:58:29.495', NULL, 'a1f13038a99f41899712c56db261386a', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8PRRFJQ3Y2V3R348DDRRM', 'status', 'review', 'done', NULL, '2026-07-25 11:29:11', '2026-07-25 11:29:11.343', '2026-07-25 11:29:11.343', NULL, '852d91352b7f2e850f848dbf0ea5f36a', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSHHXXTS56ZBB78N2W43DD2G', 'status', 'review', 'done', NULL, '2026-07-25 11:29:11', '2026-07-25 11:29:11.346', '2026-07-25 11:29:11.346', NULL, '8e0ae72ea1a4f4f308ca402009c0b3e5', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSCXX7E3BXT7WG0BYDB6PJA0', 'status', 'in_progress', 'review', NULL, '2026-07-25 11:38:28', '2026-07-25 11:38:28.088', '2026-07-25 11:38:28.088', NULL, '6931fd55bb80213b2e4c0e0df53f7d63', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8P6C6WXEG3X81PVCQ833M', 'status', 'in_progress', 'review', NULL, '2026-07-25 11:38:28', '2026-07-25 11:38:28.093', '2026-07-25 11:38:28.093', NULL, '05dfe844068b316cbde4f4ba7175221f', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSCXX7E3BXT7WG0BYDB6PJA0', 'status', 'review', 'done', NULL, '2026-07-25 12:45:32', '2026-07-25 12:45:32.483', '2026-07-25 12:45:32.483', NULL, '9e2509493e56289b581edb395437e29b', 2) ON CONFLICT(hash) DO NOTHING;
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8P6C6WXEG3X81PVCQ833M', 'status', 'review', 'done', NULL, '2026-07-25 12:45:32', '2026-07-25 12:45:32.487', '2026-07-25 12:45:32.487', NULL, '0543405565d8175739276aa3b0fc9ffb', 2) ON CONFLICT(hash) DO NOTHING;
.pql/changelog/ticket_idmap/2026-07.sql
+1
View File
@@ -106,3 +106,4 @@ INSERT INTO ticket_idmap (record_id, ticket_id, created_at, updated_at, deleted_
INSERT INTO ticket_idmap (record_id, ticket_id, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSH4VE4TTJGFGVVQWHACDBTM', 'T-1190', '2026-07-25 09:20:26.664', '2026-07-25 09:20:26.664', NULL, '773167921a274a9d43a49cea6d3ff65b', 2) ON CONFLICT(record_id) DO UPDATE SET ticket_id=excluded.ticket_id, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > ticket_idmap.updated_at OR (excluded.updated_at = ticket_idmap.updated_at AND excluded.hash > ticket_idmap.hash);
INSERT INTO ticket_idmap (record_id, ticket_id, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSHEPE2Q7GRKYJARH8Z8RPMR', 'T-1191', '2026-07-25 10:03:27.132', '2026-07-25 10:03:27.132', NULL, '572c6d4e5698b1f6a49e9126005e7c04', 2) ON CONFLICT(record_id) DO UPDATE SET ticket_id=excluded.ticket_id, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > ticket_idmap.updated_at OR (excluded.updated_at = ticket_idmap.updated_at AND excluded.hash > ticket_idmap.hash);
INSERT INTO ticket_idmap (record_id, ticket_id, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSHHXXTS56ZBB78N2W43DD2G', 'T-1192', '2026-07-25 10:17:34.935', '2026-07-25 10:17:34.935', NULL, 'c3f3e8674c19ed92f246c8090bbcd8ea', 2) ON CONFLICT(record_id) DO UPDATE SET ticket_id=excluded.ticket_id, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > ticket_idmap.updated_at OR (excluded.updated_at = ticket_idmap.updated_at AND excluded.hash > ticket_idmap.hash);
INSERT INTO ticket_idmap (record_id, ticket_id, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSHSYM96N2M9GJTQMF58E4WC', 'T-1193', '2026-07-25 10:52:37.835', '2026-07-25 10:52:37.835', NULL, '74674a181efa9bf76960713705fe6083', 2) ON CONFLICT(record_id) DO UPDATE SET ticket_id=excluded.ticket_id, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > ticket_idmap.updated_at OR (excluded.updated_at = ticket_idmap.updated_at AND excluded.hash > ticket_idmap.hash);
.pql/changelog/tickets/2026-07.sql
+33
View File
@@ -2771,3 +2771,36 @@ INSERT INTO tickets (record_id, type, parent_record_id, title, description, stat
ESCALATION from the T-1183 eyeball captures (2026-07-25, GJ1c, .cache/screenshots/t1183-eyeball-run2/02-region.png): this is NOT a small-body edge case and it is TWO axes, not one. At a 1920x1080 viewport the Region rung requested extent 384x216 cells x 204.8 km = 78,643 x 44,237 km — exceeding even an Earth-class circumference (~40,000 km) roughly 2x horizontally, so the continents repeat side-by-side on EVERY body at Region rung, and the vertical span overruns both poles: rows past the pole clamp to the last row and render as smeared vertical stripes filling the bottom ~40% of the frame (much uglier than the longitude repeat — looks like corrupted data, not a wrapped map). Jeroen flagged the frame as looking broken. Fix shape: cap the Region-rung request extent to the body''s region grid (circumference in the x axis, pole-to-pole in the y axis — both already known client-side from the Global canvas extent echo), letterbox the remainder, and consider the same guard for any rung whose footprint can exceed the body. Priority raised low->high: this makes the Region rung look broken on every body at standard viewports.', 'backlog', 'high', NULL, 'client', NULL, '2026-07-25 07:17:28.388', '2026-07-25 10:17:39.835', NULL, 'a033d5af39befbb1b60d945dcf0ff078', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FS5XW0ZMPVYA2CPBBTP88TQC', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Client cache store: FileAccess dir, two-axis eviction, version tag, retention cap (D-255)', 'The client-side cache tiers per D-255(d) and Stig''s three-tier spec (stig-round2.md (c)): in-memory LRU (adapting atlas_window_tile_set.gd''s surviving LRU skeleton from the map-component ticket) + disk-backed FileAccess cache dir with index. Two-axis eviction per D-227 amendment (1) — staleness and storage are DISTINCT: geometry entries never go stale (determinism; byte-valid forever) and are evicted only by (2a) time-since-last-visit (Jeroen''s storage-thrift ruling) and (2b) LRU capacity budget, two independent sweeps kept separate; sim-state entries (frozen/flooded planes) carry the real staleness TTL (SIM_STATE_TTL formula — served/invalidated per the serving ticket''s server-side formula). Rung-0 Global entries: retention floor, never swept. HARDENING REQUIREMENTS from D-255(d), both mandatory: (i) per-body deep-rung retention cap (max resident chunk/block-spacing tile count or disk quota per body, independent of the rung-0 floor — the structural closure of the D-226(d) accumulation gap; the AtlasAgentInterface QA channel inherits the same cap); (ii) every persistent entry carries a schema/version tag (project version or generator stamp) — read-time mismatch = cache miss + re-fetch, NEVER decode (the D-192 co-ship boundary; a disk cache survives game updates). Index-entry schema sketch in stig-round2.md (key/file_path/tier/written_at/last_read_at/size_bytes/sim_ttl/retention_floor); sweep triggers on body-open + coarse background timer, never per-frame. Explicitly rejected by the workshop: SQLite in any shape (server-side relocation, godot-sqlite addon) — plain FileAccess + index won on both agents'' independent analyses. Design sources: stig-round2.md (c), dudley-round2.md (d), D-255(d), D-227 amendments (1)(2).', 'done', 'high', NULL, 'client', 'D-255', '2026-07-24 07:12:01.789', '2026-07-25 10:17:42.696', NULL, 'fba61e686d33cc2a162aa081fd1a925d', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSCXX7E3BXT7WG0BYDB6PJA0', 'bug', '06FBPPMZNNEV052DBYYY3A897C', 'Region-baseline latitude is pole-anchored while the derive core keys equator-anchored signed regions — northern hemisphere clamps to +90', 'Found during the PR #199 (T-1174/D-256) review fix round, PRE-EXISTING on the window path since the region climate stack (T-1078/T-1113) was wired into derive_at_metres. region_profile::region_centre_latitude_deg (region_profile.rs ~270-280) maps region row 0 to the north pole (+90) with lat_frac clamped to [0,1] — a pole-anchored, non-negative row convention. But the derive core (derive_at_metres_with_riparian, district_profile.rs ~1788) keys regions by floor-dividing EQUATOR-anchored world metres (negative wy = north), producing signed region rows (Earth-class: -49..+49). Consequence: every northern-hemisphere region has negative row -> region_centre_y_m negative -> lat_frac clamps to 0 -> baseline latitude +90 (polar) regardless of true latitude; southern-hemisphere rows 0..~48 read as compressed NORTHERN latitudes ~89..~0.7 (south pole reads as equator). Affects the region temperature baseline (and glaciation/moisture components derived from it) for the window path at every rung, and post-D-256 the batch/survey path inherits the same keys (still an improvement over the pre-D-256 body-wide region-(0,0) baseline, which read ~+89 everywhere). NOT touched in PR #199 to keep the review round scoped; goldens currently pin the wrong-latitude values. FIX SHAPE: make region_centre_latitude_deg mirror the derive core''s inverse mapping (equator-anchored signed rows: lat = -((ry+0.5)*REGION_M/meridian_m clamped to [-0.5,0.5])*180), audit the OTHER convention''s callers (the D-255 rung-0 canvas row space and the collapsed LayerRegionOutput builder use non-negative pole-anchored rows - decide ONE convention per D-256''s one-inverse-mapping principle, likely at the T-1181 rung-0 rebuild), regen affected goldens, and re-run the believability direction check. Related: D-256, D-243, T-1181, T-1078.
In-the-wild datapoint (2026-07-25, T-1184 eyeball session): GJ338Bd (Arbour, R=6711km) survey cell (42,29) — true position latitude -76.2S (wy=8,929,367m, region row 43) — derives with the pole-anchored baseline latitude +13.9N, producing an 18C temperate, glaciation-free lake district near the antarctic circle. Concrete demonstration of the southern-hemisphere-reads-as-northern-tropics half of the bug (the northern half clamps to +90). Conversion math used: scratchpad survey_to_district.py, the D-256 bridge formula.', 'in_progress', 'high', NULL, 'server', NULL, '2026-07-24 23:30:51.889', '2026-07-25 10:20:01.865', NULL, '9385f947d1c1c86418d076fab06a331f', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8P6C6WXEG3X81PVCQ833M', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Lake shorelines render as hard step-edges — no transition band unlike ocean coastlines', 'Found in the T-1182 eyeball (2026-07-25): at District and Quarter rung on GJ338Bd''s big lake (DistrictPos 13652,4360), the lake shoreline is a hard rectilinear step-edge while ocean coastlines in the SAME frame show a proper multi-tone refined transition band. Two hypotheses, likely the second: (a) the T-1184 continuous filled>elevation comparison isn''t refining lake edges positionally as designed (would violate the ticket''s own ''edges refine with rung like coastlines'' requirement — verify with a shoreline-crossing sample sweep at multiple rungs); (b) PRESENTATION: ocean transition tones come from ocean_fraction_q banding, but lake cells have ocean_fraction_q=0 and Lake is a binary morphology class — so even a perfectly-refined lake edge has no gradient vocabulary to draw with. If (b), the fix is a lake-margin tone source (e.g. a filled-surface-depth band sampled at derive time, or client-side shading from the served elevation field near Lake cells — must stay inside D-255(e)''s closed input set). Determine which, then fix accordingly. Not a T-1182 defect (viewer draws what the server sends). Captures: .cache/screenshots/t1182-eyeball/rung-ladder/. Related: T-1184, D-227 amendment (4), D-255(e).', 'in_progress', 'medium', NULL, 'server', NULL, '2026-07-25 07:17:23.681', '2026-07-25 10:20:01.872', NULL, '344d93d8cf10d024527cfaa9b1c73816', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSHHXXTS56ZBB78N2W43DD2G', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Global rung presentation: fit/center the canvas in the viewport (currently top-left anchored at raw scale)', 'From the T-1183 eyeball captures (2026-07-25, .cache/screenshots/t1183-eyeball-run2/01-global.png): the Global rung canvas (GJ1c: 177x88 texels) draws top-left-anchored at its raw integer scale, occupying only the upper-left ~885x440 of a 1920x1080 viewport — the remaining ~60% of the screen is empty background, and the Atlas legend panel overlaps the canvas itself. The body-surface opener is the first thing a player sees in the Atlas; it should fit-scale (integer multiple preserving texel-exactness per D-255, or letterboxed non-integer if ruled acceptable) and center in the available viewport, with the legend laid out beside rather than over it. Pure client map-art presentation — no wire/server change; D-255(e) unaffected (same input set, different placement/scale).', 'in_progress', 'medium', NULL, 'client', NULL, '2026-07-25 10:17:34.934', '2026-07-25 10:20:01.872', NULL, '3aa877b0d2e01d1e7a318d4cb086cb88', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8PRRFJQ3Y2V3R348DDRRM', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Region-rung viewport can exceed small-body circumference — continent visibly repeats (longitude wrap UX)', 'Found in the T-1182 eyeball (2026-07-25): on Arbour (R=6711km, circumference ~42,166km), the Region rung''s viewport-fit canvas (~200x210 cells x 204.8km) slightly exceeds the body circumference, so derive_orbital_at_metres'' deliberate longitude wrap (rem_euclid) makes the continent visibly repeat side-by-side. Not a math bug — the world legitimately wraps in view. UX question: clamp the Region-rung viewport extent to the body circumference (extent is already server-clamped per D-255(b) — a per-body circumference cap on the requested extent would be a client-side transport refinement), or draw a wrap seam indicator. Smaller bodies make it worse. Captures: .cache/screenshots/t1182-eyeball/rung-ladder/02-region.png. Related: D-243 elastic seam, D-255(a).
ESCALATION from the T-1183 eyeball captures (2026-07-25, GJ1c, .cache/screenshots/t1183-eyeball-run2/02-region.png): this is NOT a small-body edge case and it is TWO axes, not one. At a 1920x1080 viewport the Region rung requested extent 384x216 cells x 204.8 km = 78,643 x 44,237 km — exceeding even an Earth-class circumference (~40,000 km) roughly 2x horizontally, so the continents repeat side-by-side on EVERY body at Region rung, and the vertical span overruns both poles: rows past the pole clamp to the last row and render as smeared vertical stripes filling the bottom ~40% of the frame (much uglier than the longitude repeat — looks like corrupted data, not a wrapped map). Jeroen flagged the frame as looking broken. Fix shape: cap the Region-rung request extent to the body''s region grid (circumference in the x axis, pole-to-pole in the y axis — both already known client-side from the Global canvas extent echo), letterbox the remainder, and consider the same guard for any rung whose footprint can exceed the body. Priority raised low->high: this makes the Region rung look broken on every body at standard viewports.', 'in_progress', 'high', NULL, 'client', NULL, '2026-07-25 07:17:28.388', '2026-07-25 10:20:01.872', NULL, 'c7584e29e0d2228da18fc90926380c3d', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSCXX7E3BXT7WG0BYDB6PJA0', 'bug', '06FBPPMZNNEV052DBYYY3A897C', 'Region-baseline latitude is pole-anchored while the derive core keys equator-anchored signed regions — northern hemisphere clamps to +90', 'Found during the PR #199 (T-1174/D-256) review fix round, PRE-EXISTING on the window path since the region climate stack (T-1078/T-1113) was wired into derive_at_metres. region_profile::region_centre_latitude_deg (region_profile.rs ~270-280) maps region row 0 to the north pole (+90) with lat_frac clamped to [0,1] — a pole-anchored, non-negative row convention. But the derive core (derive_at_metres_with_riparian, district_profile.rs ~1788) keys regions by floor-dividing EQUATOR-anchored world metres (negative wy = north), producing signed region rows (Earth-class: -49..+49). Consequence: every northern-hemisphere region has negative row -> region_centre_y_m negative -> lat_frac clamps to 0 -> baseline latitude +90 (polar) regardless of true latitude; southern-hemisphere rows 0..~48 read as compressed NORTHERN latitudes ~89..~0.7 (south pole reads as equator). Affects the region temperature baseline (and glaciation/moisture components derived from it) for the window path at every rung, and post-D-256 the batch/survey path inherits the same keys (still an improvement over the pre-D-256 body-wide region-(0,0) baseline, which read ~+89 everywhere). NOT touched in PR #199 to keep the review round scoped; goldens currently pin the wrong-latitude values. FIX SHAPE: make region_centre_latitude_deg mirror the derive core''s inverse mapping (equator-anchored signed rows: lat = -((ry+0.5)*REGION_M/meridian_m clamped to [-0.5,0.5])*180), audit the OTHER convention''s callers (the D-255 rung-0 canvas row space and the collapsed LayerRegionOutput builder use non-negative pole-anchored rows - decide ONE convention per D-256''s one-inverse-mapping principle, likely at the T-1181 rung-0 rebuild), regen affected goldens, and re-run the believability direction check. Related: D-256, D-243, T-1181, T-1078.
In-the-wild datapoint (2026-07-25, T-1184 eyeball session): GJ338Bd (Arbour, R=6711km) survey cell (42,29) — true position latitude -76.2S (wy=8,929,367m, region row 43) — derives with the pole-anchored baseline latitude +13.9N, producing an 18C temperate, glaciation-free lake district near the antarctic circle. Concrete demonstration of the southern-hemisphere-reads-as-northern-tropics half of the bug (the northern half clamps to +90). Conversion math used: scratchpad survey_to_district.py, the D-256 bridge formula.', 'in_progress', 'high', 'dudley', 'server', NULL, '2026-07-24 23:30:51.889', '2026-07-25 10:21:12.179', NULL, '06433fd1cd5a060faf5fe503e7869183', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8P6C6WXEG3X81PVCQ833M', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Lake shorelines render as hard step-edges — no transition band unlike ocean coastlines', 'Found in the T-1182 eyeball (2026-07-25): at District and Quarter rung on GJ338Bd''s big lake (DistrictPos 13652,4360), the lake shoreline is a hard rectilinear step-edge while ocean coastlines in the SAME frame show a proper multi-tone refined transition band. Two hypotheses, likely the second: (a) the T-1184 continuous filled>elevation comparison isn''t refining lake edges positionally as designed (would violate the ticket''s own ''edges refine with rung like coastlines'' requirement — verify with a shoreline-crossing sample sweep at multiple rungs); (b) PRESENTATION: ocean transition tones come from ocean_fraction_q banding, but lake cells have ocean_fraction_q=0 and Lake is a binary morphology class — so even a perfectly-refined lake edge has no gradient vocabulary to draw with. If (b), the fix is a lake-margin tone source (e.g. a filled-surface-depth band sampled at derive time, or client-side shading from the served elevation field near Lake cells — must stay inside D-255(e)''s closed input set). Determine which, then fix accordingly. Not a T-1182 defect (viewer draws what the server sends). Captures: .cache/screenshots/t1182-eyeball/rung-ladder/. Related: T-1184, D-227 amendment (4), D-255(e).', 'in_progress', 'medium', 'dudley', 'server', NULL, '2026-07-25 07:17:23.681', '2026-07-25 10:21:12.182', NULL, '2a01d94f51c957ba8b8ce19312765d43', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8PRRFJQ3Y2V3R348DDRRM', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Region-rung viewport can exceed small-body circumference — continent visibly repeats (longitude wrap UX)', 'Found in the T-1182 eyeball (2026-07-25): on Arbour (R=6711km, circumference ~42,166km), the Region rung''s viewport-fit canvas (~200x210 cells x 204.8km) slightly exceeds the body circumference, so derive_orbital_at_metres'' deliberate longitude wrap (rem_euclid) makes the continent visibly repeat side-by-side. Not a math bug — the world legitimately wraps in view. UX question: clamp the Region-rung viewport extent to the body circumference (extent is already server-clamped per D-255(b) — a per-body circumference cap on the requested extent would be a client-side transport refinement), or draw a wrap seam indicator. Smaller bodies make it worse. Captures: .cache/screenshots/t1182-eyeball/rung-ladder/02-region.png. Related: D-243 elastic seam, D-255(a).
ESCALATION from the T-1183 eyeball captures (2026-07-25, GJ1c, .cache/screenshots/t1183-eyeball-run2/02-region.png): this is NOT a small-body edge case and it is TWO axes, not one. At a 1920x1080 viewport the Region rung requested extent 384x216 cells x 204.8 km = 78,643 x 44,237 km — exceeding even an Earth-class circumference (~40,000 km) roughly 2x horizontally, so the continents repeat side-by-side on EVERY body at Region rung, and the vertical span overruns both poles: rows past the pole clamp to the last row and render as smeared vertical stripes filling the bottom ~40% of the frame (much uglier than the longitude repeat — looks like corrupted data, not a wrapped map). Jeroen flagged the frame as looking broken. Fix shape: cap the Region-rung request extent to the body''s region grid (circumference in the x axis, pole-to-pole in the y axis — both already known client-side from the Global canvas extent echo), letterbox the remainder, and consider the same guard for any rung whose footprint can exceed the body. Priority raised low->high: this makes the Region rung look broken on every body at standard viewports.', 'in_progress', 'high', 'stig', 'client', NULL, '2026-07-25 07:17:28.388', '2026-07-25 10:21:12.361', NULL, '046d604c827f4f892d92da4db10140a7', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSHHXXTS56ZBB78N2W43DD2G', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Global rung presentation: fit/center the canvas in the viewport (currently top-left anchored at raw scale)', 'From the T-1183 eyeball captures (2026-07-25, .cache/screenshots/t1183-eyeball-run2/01-global.png): the Global rung canvas (GJ1c: 177x88 texels) draws top-left-anchored at its raw integer scale, occupying only the upper-left ~885x440 of a 1920x1080 viewport — the remaining ~60% of the screen is empty background, and the Atlas legend panel overlaps the canvas itself. The body-surface opener is the first thing a player sees in the Atlas; it should fit-scale (integer multiple preserving texel-exactness per D-255, or letterboxed non-integer if ruled acceptable) and center in the available viewport, with the legend laid out beside rather than over it. Pure client map-art presentation — no wire/server change; D-255(e) unaffected (same input set, different placement/scale).', 'in_progress', 'medium', 'stig', 'client', NULL, '2026-07-25 10:17:34.934', '2026-07-25 10:21:12.368', NULL, '4e4308dfbb0087160df2c9559f224161', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSHSYM96N2M9GJTQMF58E4WC', 'task', '06FBPPMZNNEV052DBYYY3A897C', 'StepCanvasViewer test suite lacks an injected disk-cache-root seam — tests share the real user://atlas_cache', 'Flagged by stig during the T-1189/T-1192 round (2026-07-25): test_step_canvas_viewer.gd has no injected disk-cache-root seam (unlike test_step_canvas_request.gd, which injects a disposable root), so viewer tests that exercise the disk-cache path against a real-looking body_id (e.g. GJ1c) read/write the REAL user://atlas_cache/ shared across runs — a stale real entry from earlier manual sessions can leak into test behavior. Current mitigation (used by the new T-1189/T-1192 tests and the existing sweep smoke test): distinctive synthetic body_ids. Proper fix: give the viewer suite the same injectable cache-root seam the request suite has (constructor/setter injection through StepCanvasRequest), and migrate the synthetic-body_id tests onto it. Small, test-only.', 'backlog', 'low', NULL, 'client', NULL, '2026-07-25 10:52:37.833', '2026-07-25 10:52:37.833', NULL, '9d36975961c2ee7d6532ccf56cf962fb', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8PRRFJQ3Y2V3R348DDRRM', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Region-rung viewport can exceed small-body circumference — continent visibly repeats (longitude wrap UX)', 'Found in the T-1182 eyeball (2026-07-25): on Arbour (R=6711km, circumference ~42,166km), the Region rung''s viewport-fit canvas (~200x210 cells x 204.8km) slightly exceeds the body circumference, so derive_orbital_at_metres'' deliberate longitude wrap (rem_euclid) makes the continent visibly repeat side-by-side. Not a math bug — the world legitimately wraps in view. UX question: clamp the Region-rung viewport extent to the body circumference (extent is already server-clamped per D-255(b) — a per-body circumference cap on the requested extent would be a client-side transport refinement), or draw a wrap seam indicator. Smaller bodies make it worse. Captures: .cache/screenshots/t1182-eyeball/rung-ladder/02-region.png. Related: D-243 elastic seam, D-255(a).
ESCALATION from the T-1183 eyeball captures (2026-07-25, GJ1c, .cache/screenshots/t1183-eyeball-run2/02-region.png): this is NOT a small-body edge case and it is TWO axes, not one. At a 1920x1080 viewport the Region rung requested extent 384x216 cells x 204.8 km = 78,643 x 44,237 km — exceeding even an Earth-class circumference (~40,000 km) roughly 2x horizontally, so the continents repeat side-by-side on EVERY body at Region rung, and the vertical span overruns both poles: rows past the pole clamp to the last row and render as smeared vertical stripes filling the bottom ~40% of the frame (much uglier than the longitude repeat — looks like corrupted data, not a wrapped map). Jeroen flagged the frame as looking broken. Fix shape: cap the Region-rung request extent to the body''s region grid (circumference in the x axis, pole-to-pole in the y axis — both already known client-side from the Global canvas extent echo), letterbox the remainder, and consider the same guard for any rung whose footprint can exceed the body. Priority raised low->high: this makes the Region rung look broken on every body at standard viewports.', 'review', 'high', 'stig', 'client', NULL, '2026-07-25 07:17:28.388', '2026-07-25 10:58:29.489', NULL, 'fe602c8ea1224cc7940690357e0097df', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSHHXXTS56ZBB78N2W43DD2G', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Global rung presentation: fit/center the canvas in the viewport (currently top-left anchored at raw scale)', 'From the T-1183 eyeball captures (2026-07-25, .cache/screenshots/t1183-eyeball-run2/01-global.png): the Global rung canvas (GJ1c: 177x88 texels) draws top-left-anchored at its raw integer scale, occupying only the upper-left ~885x440 of a 1920x1080 viewport — the remaining ~60% of the screen is empty background, and the Atlas legend panel overlaps the canvas itself. The body-surface opener is the first thing a player sees in the Atlas; it should fit-scale (integer multiple preserving texel-exactness per D-255, or letterboxed non-integer if ruled acceptable) and center in the available viewport, with the legend laid out beside rather than over it. Pure client map-art presentation — no wire/server change; D-255(e) unaffected (same input set, different placement/scale).', 'review', 'medium', 'stig', 'client', NULL, '2026-07-25 10:17:34.934', '2026-07-25 10:58:29.494', NULL, '82220681d07fcbf2db496e9901b0af8f', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8PRRFJQ3Y2V3R348DDRRM', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Region-rung viewport can exceed small-body circumference — continent visibly repeats (longitude wrap UX)', 'Found in the T-1182 eyeball (2026-07-25): on Arbour (R=6711km, circumference ~42,166km), the Region rung''s viewport-fit canvas (~200x210 cells x 204.8km) slightly exceeds the body circumference, so derive_orbital_at_metres'' deliberate longitude wrap (rem_euclid) makes the continent visibly repeat side-by-side. Not a math bug — the world legitimately wraps in view. UX question: clamp the Region-rung viewport extent to the body circumference (extent is already server-clamped per D-255(b) — a per-body circumference cap on the requested extent would be a client-side transport refinement), or draw a wrap seam indicator. Smaller bodies make it worse. Captures: .cache/screenshots/t1182-eyeball/rung-ladder/02-region.png. Related: D-243 elastic seam, D-255(a).
ESCALATION from the T-1183 eyeball captures (2026-07-25, GJ1c, .cache/screenshots/t1183-eyeball-run2/02-region.png): this is NOT a small-body edge case and it is TWO axes, not one. At a 1920x1080 viewport the Region rung requested extent 384x216 cells x 204.8 km = 78,643 x 44,237 km — exceeding even an Earth-class circumference (~40,000 km) roughly 2x horizontally, so the continents repeat side-by-side on EVERY body at Region rung, and the vertical span overruns both poles: rows past the pole clamp to the last row and render as smeared vertical stripes filling the bottom ~40% of the frame (much uglier than the longitude repeat — looks like corrupted data, not a wrapped map). Jeroen flagged the frame as looking broken. Fix shape: cap the Region-rung request extent to the body''s region grid (circumference in the x axis, pole-to-pole in the y axis — both already known client-side from the Global canvas extent echo), letterbox the remainder, and consider the same guard for any rung whose footprint can exceed the body. Priority raised low->high: this makes the Region rung look broken on every body at standard viewports.', 'done', 'high', 'stig', 'client', NULL, '2026-07-25 07:17:28.388', '2026-07-25 11:29:11.342', NULL, 'c7f85f322a503efc1cee80ea14bda6b8', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSHHXXTS56ZBB78N2W43DD2G', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Global rung presentation: fit/center the canvas in the viewport (currently top-left anchored at raw scale)', 'From the T-1183 eyeball captures (2026-07-25, .cache/screenshots/t1183-eyeball-run2/01-global.png): the Global rung canvas (GJ1c: 177x88 texels) draws top-left-anchored at its raw integer scale, occupying only the upper-left ~885x440 of a 1920x1080 viewport — the remaining ~60% of the screen is empty background, and the Atlas legend panel overlaps the canvas itself. The body-surface opener is the first thing a player sees in the Atlas; it should fit-scale (integer multiple preserving texel-exactness per D-255, or letterboxed non-integer if ruled acceptable) and center in the available viewport, with the legend laid out beside rather than over it. Pure client map-art presentation — no wire/server change; D-255(e) unaffected (same input set, different placement/scale).', 'done', 'medium', 'stig', 'client', NULL, '2026-07-25 10:17:34.934', '2026-07-25 11:29:11.346', NULL, '12bdd15c8649e6edb519a0a2d0edc64a', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSCXX7E3BXT7WG0BYDB6PJA0', 'bug', '06FBPPMZNNEV052DBYYY3A897C', 'Region-baseline latitude is pole-anchored while the derive core keys equator-anchored signed regions — northern hemisphere clamps to +90', 'Found during the PR #199 (T-1174/D-256) review fix round, PRE-EXISTING on the window path since the region climate stack (T-1078/T-1113) was wired into derive_at_metres. region_profile::region_centre_latitude_deg (region_profile.rs ~270-280) maps region row 0 to the north pole (+90) with lat_frac clamped to [0,1] — a pole-anchored, non-negative row convention. But the derive core (derive_at_metres_with_riparian, district_profile.rs ~1788) keys regions by floor-dividing EQUATOR-anchored world metres (negative wy = north), producing signed region rows (Earth-class: -49..+49). Consequence: every northern-hemisphere region has negative row -> region_centre_y_m negative -> lat_frac clamps to 0 -> baseline latitude +90 (polar) regardless of true latitude; southern-hemisphere rows 0..~48 read as compressed NORTHERN latitudes ~89..~0.7 (south pole reads as equator). Affects the region temperature baseline (and glaciation/moisture components derived from it) for the window path at every rung, and post-D-256 the batch/survey path inherits the same keys (still an improvement over the pre-D-256 body-wide region-(0,0) baseline, which read ~+89 everywhere). NOT touched in PR #199 to keep the review round scoped; goldens currently pin the wrong-latitude values. FIX SHAPE: make region_centre_latitude_deg mirror the derive core''s inverse mapping (equator-anchored signed rows: lat = -((ry+0.5)*REGION_M/meridian_m clamped to [-0.5,0.5])*180), audit the OTHER convention''s callers (the D-255 rung-0 canvas row space and the collapsed LayerRegionOutput builder use non-negative pole-anchored rows - decide ONE convention per D-256''s one-inverse-mapping principle, likely at the T-1181 rung-0 rebuild), regen affected goldens, and re-run the believability direction check. Related: D-256, D-243, T-1181, T-1078.
In-the-wild datapoint (2026-07-25, T-1184 eyeball session): GJ338Bd (Arbour, R=6711km) survey cell (42,29) — true position latitude -76.2S (wy=8,929,367m, region row 43) — derives with the pole-anchored baseline latitude +13.9N, producing an 18C temperate, glaciation-free lake district near the antarctic circle. Concrete demonstration of the southern-hemisphere-reads-as-northern-tropics half of the bug (the northern half clamps to +90). Conversion math used: scratchpad survey_to_district.py, the D-256 bridge formula.', 'review', 'high', 'dudley', 'server', NULL, '2026-07-24 23:30:51.889', '2026-07-25 11:38:28.087', NULL, 'c6944bb23736a91f8bd786e793f21b1e', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8P6C6WXEG3X81PVCQ833M', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Lake shorelines render as hard step-edges — no transition band unlike ocean coastlines', 'Found in the T-1182 eyeball (2026-07-25): at District and Quarter rung on GJ338Bd''s big lake (DistrictPos 13652,4360), the lake shoreline is a hard rectilinear step-edge while ocean coastlines in the SAME frame show a proper multi-tone refined transition band. Two hypotheses, likely the second: (a) the T-1184 continuous filled>elevation comparison isn''t refining lake edges positionally as designed (would violate the ticket''s own ''edges refine with rung like coastlines'' requirement — verify with a shoreline-crossing sample sweep at multiple rungs); (b) PRESENTATION: ocean transition tones come from ocean_fraction_q banding, but lake cells have ocean_fraction_q=0 and Lake is a binary morphology class — so even a perfectly-refined lake edge has no gradient vocabulary to draw with. If (b), the fix is a lake-margin tone source (e.g. a filled-surface-depth band sampled at derive time, or client-side shading from the served elevation field near Lake cells — must stay inside D-255(e)''s closed input set). Determine which, then fix accordingly. Not a T-1182 defect (viewer draws what the server sends). Captures: .cache/screenshots/t1182-eyeball/rung-ladder/. Related: T-1184, D-227 amendment (4), D-255(e).', 'review', 'medium', 'dudley', 'server', NULL, '2026-07-25 07:17:23.681', '2026-07-25 11:38:28.092', NULL, 'bcadc3c04a78b4922439c82bc6a2715f', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSCXX7E3BXT7WG0BYDB6PJA0', 'bug', '06FBPPMZNNEV052DBYYY3A897C', 'Region-baseline latitude is pole-anchored while the derive core keys equator-anchored signed regions — northern hemisphere clamps to +90', 'Found during the PR #199 (T-1174/D-256) review fix round, PRE-EXISTING on the window path since the region climate stack (T-1078/T-1113) was wired into derive_at_metres. region_profile::region_centre_latitude_deg (region_profile.rs ~270-280) maps region row 0 to the north pole (+90) with lat_frac clamped to [0,1] — a pole-anchored, non-negative row convention. But the derive core (derive_at_metres_with_riparian, district_profile.rs ~1788) keys regions by floor-dividing EQUATOR-anchored world metres (negative wy = north), producing signed region rows (Earth-class: -49..+49). Consequence: every northern-hemisphere region has negative row -> region_centre_y_m negative -> lat_frac clamps to 0 -> baseline latitude +90 (polar) regardless of true latitude; southern-hemisphere rows 0..~48 read as compressed NORTHERN latitudes ~89..~0.7 (south pole reads as equator). Affects the region temperature baseline (and glaciation/moisture components derived from it) for the window path at every rung, and post-D-256 the batch/survey path inherits the same keys (still an improvement over the pre-D-256 body-wide region-(0,0) baseline, which read ~+89 everywhere). NOT touched in PR #199 to keep the review round scoped; goldens currently pin the wrong-latitude values. FIX SHAPE: make region_centre_latitude_deg mirror the derive core''s inverse mapping (equator-anchored signed rows: lat = -((ry+0.5)*REGION_M/meridian_m clamped to [-0.5,0.5])*180), audit the OTHER convention''s callers (the D-255 rung-0 canvas row space and the collapsed LayerRegionOutput builder use non-negative pole-anchored rows - decide ONE convention per D-256''s one-inverse-mapping principle, likely at the T-1181 rung-0 rebuild), regen affected goldens, and re-run the believability direction check. Related: D-256, D-243, T-1181, T-1078.
In-the-wild datapoint (2026-07-25, T-1184 eyeball session): GJ338Bd (Arbour, R=6711km) survey cell (42,29) — true position latitude -76.2S (wy=8,929,367m, region row 43) — derives with the pole-anchored baseline latitude +13.9N, producing an 18C temperate, glaciation-free lake district near the antarctic circle. Concrete demonstration of the southern-hemisphere-reads-as-northern-tropics half of the bug (the northern half clamps to +90). Conversion math used: scratchpad survey_to_district.py, the D-256 bridge formula.', 'done', 'high', 'dudley', 'server', NULL, '2026-07-24 23:30:51.889', '2026-07-25 12:45:32.482', NULL, '3e639a87ce35024288534a352e9230cf', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FSG8P6C6WXEG3X81PVCQ833M', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Lake shorelines render as hard step-edges — no transition band unlike ocean coastlines', 'Found in the T-1182 eyeball (2026-07-25): at District and Quarter rung on GJ338Bd''s big lake (DistrictPos 13652,4360), the lake shoreline is a hard rectilinear step-edge while ocean coastlines in the SAME frame show a proper multi-tone refined transition band. Two hypotheses, likely the second: (a) the T-1184 continuous filled>elevation comparison isn''t refining lake edges positionally as designed (would violate the ticket''s own ''edges refine with rung like coastlines'' requirement — verify with a shoreline-crossing sample sweep at multiple rungs); (b) PRESENTATION: ocean transition tones come from ocean_fraction_q banding, but lake cells have ocean_fraction_q=0 and Lake is a binary morphology class — so even a perfectly-refined lake edge has no gradient vocabulary to draw with. If (b), the fix is a lake-margin tone source (e.g. a filled-surface-depth band sampled at derive time, or client-side shading from the served elevation field near Lake cells — must stay inside D-255(e)''s closed input set). Determine which, then fix accordingly. Not a T-1182 defect (viewer draws what the server sends). Captures: .cache/screenshots/t1182-eyeball/rung-ladder/. Related: T-1184, D-227 amendment (4), D-255(e).', 'done', 'medium', 'dudley', 'server', NULL, '2026-07-25 07:17:23.681', '2026-07-25 12:45:32.487', NULL, 'b3f66fd935ce03512d448f63529b1b72', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash);