diff --git a/.pql/changelog/ticket_history/2026-07.sql b/.pql/changelog/ticket_history/2026-07.sql
index 35a013595..41f2ce707 100644
--- a/.pql/changelog/ticket_history/2026-07.sql
+++ b/.pql/changelog/ticket_history/2026-07.sql
@@ -3148,3 +3148,7 @@ AUDIT COMPLETE (2026-07-26). Set was 11 files, not 12-13 (tiger.md deleted in 0a
 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 ('06FSW30GPFFEB05M6EXD1WFANW', 'status', 'in_progress', 'done', NULL, '2026-07-26 11:49:42', '2026-07-26 11:49:42.508', '2026-07-26 11:49:42.508', NULL, 'dced5473823b32b586d691d67cb0d726', 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 ('06FMZZ0184R5B8YMFJW5NWPNXW', 'status', 'in_progress', 'review', NULL, '2026-07-26 12:13:13', '2026-07-26 12:13:13.762', '2026-07-26 12:13:13.762', NULL, '55eb94032833d9e19a7a60116bf300f5', 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 ('06FMZZ0184R5B8YMFJW5NWPNXW', 'status', 'review', 'done', NULL, '2026-07-26 12:29:54', '2026-07-26 12:29:54.219', '2026-07-26 12:29:54.219', NULL, 'cd9fa62db8d8d1d359024df22c19d2e7', 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 ('06FSWCYA60VHFK44J09WW78FY0', 'status', 'backlog', 'in_progress', NULL, '2026-07-26 12:33:36', '2026-07-26 12:33:36.682', '2026-07-26 12:33:36.682', NULL, '126ba2bbb5114ed57d1aa1facb156709', 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 ('06FSP3GEJYTA966BSSR9354YC4', 'status', 'backlog', 'in_progress', NULL, '2026-07-26 12:33:36', '2026-07-26 12:33:36.687', '2026-07-26 12:33:36.687', NULL, '5c62d31cdde3da8bba4160924929d6c7', 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 ('06FSWCYA60VHFK44J09WW78FY0', 'assigned_to', NULL, 'dudley', NULL, '2026-07-26 12:33:41', '2026-07-26 12:33:41.592', '2026-07-26 12:33:41.592', NULL, 'c08a8b496d3a91055577832000605428', 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 ('06FSP3GEJYTA966BSSR9354YC4', 'assigned_to', NULL, 'stig', NULL, '2026-07-26 12:33:42', '2026-07-26 12:33:42.082', '2026-07-26 12:33:42.082', NULL, 'c401604d7344f97f2aaf943be53f48eb', 2) ON CONFLICT(hash) DO NOTHING;
diff --git a/.pql/changelog/tickets/2026-07.sql b/.pql/changelog/tickets/2026-07.sql
index 627e319b3..a6c056d97 100644
--- a/.pql/changelog/tickets/2026-07.sql
+++ b/.pql/changelog/tickets/2026-07.sql
@@ -5333,3 +5333,7 @@ INSERT INTO tickets (record_id, type, parent_record_id, title, description, stat
 AUDIT COMPLETE (2026-07-26). Set was 11 files, not 12-13 (tiger.md deleted in 0a9b0d00a, Tiger off the roster). 66 unique D-ids body-matched across all 11. THREE new slip-family members, all in gestalt.md, each verified by full body-match and lead-spot-checked: D-130 written where D-131 (broad life-verb vocabulary) was meant (x3: lines 20/48/62) and D-118 written where D-133 (skills affect outcome) was meant (x2: lines 22/43). All five fixed on main. The other 10 briefings are citation-clean. Context findings recorded on follow-ups: T-1208 (eight wholesale-stale briefings, rewrite backlog, qatux.md + tyre.md highest value; also the systemic superseded-cluster and D-123/D-138 notes). Final slip-family tally across T-1199+T-1205: 16 mis-citations in 6 of 18 briefings, all from the single f4c72e148 commit, all fixed.', 'done', 'medium', 'clerk', 'server', NULL, '2026-07-26 10:50:18.675', '2026-07-26 11:49:42.508', NULL, '805203e281a681f4f5aee386d365941f', 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 ('06FMZZ0184R5B8YMFJW5NWPNXW', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Interstitial fill — tile character between building footprints (setback-driven open space vs. built ops-surface) at chunk derive', 'Deferred slice of T-959 (Layer 5 fill), split out during /whats-next review 2026-07-08. T-988 landed BuildingExteriorTag.setback_tier + BlockSkeleton.interstitial_character (OpenSpace|OperationsSurface, D-233 bulk-driven), and FillChunk now reads materials onto Wall/Roof shell voxels. What remains: actually FILL the between-footprint tiles at chunk-derive time — resolve each non-footprint ground tile to its character (setback-driven interstitial type: void/court/garden/plaza/dock_slip/market_pad/open_lawn per D-235; or the block''s OperationsSurface tag for bulk industry per D-233/T-1097).\n\nWHY DEFERRED (Dudley''s rationale, PR review): FillChunk''s work item today carries only Vec<BuildingPropertyTag> (per-building) with zero block-level metadata; setback_tier is per-building on exterior, but ''the gap between buildings'' is block-shaped. And ''what is an interstitial tile inside a 64m chunk derive'' is a real geometry question (the BSP leaves that lost the coverage roll in subdivide_block_footprints? a separate ground-fill pass?) that needs a design pass, not a guess. Nothing consumes FillChunk in production until Phase 5, so this blocks nothing today.\n\nSCOPE: (1) thread block-level metadata (interstitial_character + setback/density) into the FillChunk work item; (2) decide + implement the ground-fill geometry (which chunk tiles are interstitial vs footprint-covered vs street); (3) resolve each to its D-235 interstitial type / D-233 ops-surface tag; (4) stays pure/cache-free (T-987). Write a short brief pinning the geometry model before implementing.', 'review', 'medium', 'dudley', 'server', 'D-235', '2026-07-11 07:02:23.297', '2026-07-26 12:13:13.762', NULL, 'a1cca37f45b6dd0644785bb2db398942', 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 ('06FMZZ0184R5B8YMFJW5NWPNXW', 'task', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Interstitial fill — tile character between building footprints (setback-driven open space vs. built ops-surface) at chunk derive', 'Deferred slice of T-959 (Layer 5 fill), split out during /whats-next review 2026-07-08. T-988 landed BuildingExteriorTag.setback_tier + BlockSkeleton.interstitial_character (OpenSpace|OperationsSurface, D-233 bulk-driven), and FillChunk now reads materials onto Wall/Roof shell voxels. What remains: actually FILL the between-footprint tiles at chunk-derive time — resolve each non-footprint ground tile to its character (setback-driven interstitial type: void/court/garden/plaza/dock_slip/market_pad/open_lawn per D-235; or the block''s OperationsSurface tag for bulk industry per D-233/T-1097).\n\nWHY DEFERRED (Dudley''s rationale, PR review): FillChunk''s work item today carries only Vec<BuildingPropertyTag> (per-building) with zero block-level metadata; setback_tier is per-building on exterior, but ''the gap between buildings'' is block-shaped. And ''what is an interstitial tile inside a 64m chunk derive'' is a real geometry question (the BSP leaves that lost the coverage roll in subdivide_block_footprints? a separate ground-fill pass?) that needs a design pass, not a guess. Nothing consumes FillChunk in production until Phase 5, so this blocks nothing today.\n\nSCOPE: (1) thread block-level metadata (interstitial_character + setback/density) into the FillChunk work item; (2) decide + implement the ground-fill geometry (which chunk tiles are interstitial vs footprint-covered vs street); (3) resolve each to its D-235 interstitial type / D-233 ops-surface tag; (4) stays pure/cache-free (T-987). Write a short brief pinning the geometry model before implementing.', 'done', 'medium', 'dudley', 'server', 'D-235', '2026-07-11 07:02:23.297', '2026-07-26 12:29:54.214', NULL, 'af93331f15b043918cee4603267a41fe', 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 ('06FSWCYA60VHFK44J09WW78FY0', 'bug', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Synthetic-overflow settlement placement has no ocean-mask guard — can land in open water', 'Found during the PR #215 review fix round (T-1116, Tyre finding 3 follow-through): attractor_matching.rs::synthetic_attractor (the D-211 Phase-4 overflow path, PlainCenter at min-spacing) takes no heightmap/TerrainAnalysis argument — it derives positions by pure grid arithmetic (grid_h/2, grid_w/4, spacing-walk) with zero ocean_mask check. Every EXTRACTED attractor type is land-guaranteed (features.rs::extract_attractors filters !ocean_mask, D-209), but a synthetic-overflow settlement can be placed in open water — visible as an ocean-stranded settlement marker on the Atlas. T-1116''s routing relaxation degrades this case gracefully (surrogate anchor within ring 3, else an isolated unrouted node — never a panic or a water road), but the placement guarantee itself is the gap. Documented in road_graph.rs''s anchor comment and the D-210 amendment (PR #215). Fix shape: thread the ocean mask (or TerrainAnalysis) into synthetic_attractor and nudge/reject water candidates deterministically — mind D-211''s seed-derived-position promise (any nudge must be a pure function of seed + terrain, no RNG state change). Verify by hunting a real body whose synthetic overflow currently lands in water (none observed yet — GJ251c/GJ380c placements are all extracted attractors) or a synthetic fixture.', 'in_progress', 'medium', NULL, 'server', NULL, '2026-07-26 11:33:42.064', '2026-07-26 12:33:36.681', NULL, '024114313664da355c50c920ebf8339f', 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 ('06FSP3GEJYTA966BSSR9354YC4', 'task', '06FBPPMZNNEV052DBYYY3A897C', 'Atlas header readout ghosted in Quarter capture — rung-transition alpha artifact', 'Araminta''s T-1196 secondary observation (first GJ1002b captures, 2026-07-25): the ''ATLAS - CAPARICA / QUARTER'' header readout above the legend rendered faded/ghosted in the Quarter frame (scratchpad t1196/gj1002b_quarter.png), while the District and Region frames from the same session and capture path rendered it fully legible. Suspect a z-order or alpha transition state caught mid-render on rung change (the capture settles on StepCanvasRequest.is_pending() then waits 2 frames — a header fade animation may outlast the data settle). Reproduce with a T-1157-harness jump_to capture at any Quarter rung and inspect header alpha across post-settle frames; if it is a fade animation racing the capture, decide whether the fix is harness-side (settle until animations idle) or UI-side (no fade on rung change). Likely cosmetic; the only frame of the three with a legibility defect.', 'in_progress', 'low', NULL, 'client', NULL, '2026-07-25 20:53:37.559', '2026-07-26 12:33:36.687', NULL, '61c09dcec6f2765796beb7a85fa45550', 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 ('06FSWCYA60VHFK44J09WW78FY0', 'bug', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Synthetic-overflow settlement placement has no ocean-mask guard — can land in open water', 'Found during the PR #215 review fix round (T-1116, Tyre finding 3 follow-through): attractor_matching.rs::synthetic_attractor (the D-211 Phase-4 overflow path, PlainCenter at min-spacing) takes no heightmap/TerrainAnalysis argument — it derives positions by pure grid arithmetic (grid_h/2, grid_w/4, spacing-walk) with zero ocean_mask check. Every EXTRACTED attractor type is land-guaranteed (features.rs::extract_attractors filters !ocean_mask, D-209), but a synthetic-overflow settlement can be placed in open water — visible as an ocean-stranded settlement marker on the Atlas. T-1116''s routing relaxation degrades this case gracefully (surrogate anchor within ring 3, else an isolated unrouted node — never a panic or a water road), but the placement guarantee itself is the gap. Documented in road_graph.rs''s anchor comment and the D-210 amendment (PR #215). Fix shape: thread the ocean mask (or TerrainAnalysis) into synthetic_attractor and nudge/reject water candidates deterministically — mind D-211''s seed-derived-position promise (any nudge must be a pure function of seed + terrain, no RNG state change). Verify by hunting a real body whose synthetic overflow currently lands in water (none observed yet — GJ251c/GJ380c placements are all extracted attractors) or a synthetic fixture.', 'in_progress', 'medium', 'dudley', 'server', NULL, '2026-07-26 11:33:42.064', '2026-07-26 12:33:41.587', NULL, 'f5e116e6900eaad013ca4a2200586e35', 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 ('06FSP3GEJYTA966BSSR9354YC4', 'task', '06FBPPMZNNEV052DBYYY3A897C', 'Atlas header readout ghosted in Quarter capture — rung-transition alpha artifact', 'Araminta''s T-1196 secondary observation (first GJ1002b captures, 2026-07-25): the ''ATLAS - CAPARICA / QUARTER'' header readout above the legend rendered faded/ghosted in the Quarter frame (scratchpad t1196/gj1002b_quarter.png), while the District and Region frames from the same session and capture path rendered it fully legible. Suspect a z-order or alpha transition state caught mid-render on rung change (the capture settles on StepCanvasRequest.is_pending() then waits 2 frames — a header fade animation may outlast the data settle). Reproduce with a T-1157-harness jump_to capture at any Quarter rung and inspect header alpha across post-settle frames; if it is a fade animation racing the capture, decide whether the fix is harness-side (settle until animations idle) or UI-side (no fade on rung change). Likely cosmetic; the only frame of the three with a legibility defect.', 'in_progress', 'low', 'stig', 'client', NULL, '2026-07-25 20:53:37.559', '2026-07-26 12:33:42.081', NULL, '125ff7ed1722e7e21e2c98d8817c1d25', 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);