## Operator feedback on #1334
PR #1334 (the #1293 marker a11y change) added a baked-in white outline
at `stroke-width=2` to every node marker via `makeRoleMarkerSVG`.
Operator reports it's too heavy and dominates the map at zoomed-out
levels — every node reads as a "big white blob with a colour core",
which actually drowns out the per-role shape silhouette at the exact
zoom levels where the shape distinction matters most.
## Fix
Drop the always-on stroke from **2 → 1** across all marker producers:
| Producer | Before | After |
|----------|--------|-------|
| `public/roles.js` `makeRoleMarkerSVG` (circle / square / triangle /
diamond / hexagon) | `stroke-width="2"` | `stroke-width="1"` |
| `public/roles.js` `makeRoleMarkerSVG` (star branch) |
`stroke-width="1.5"` | `stroke-width="1"` |
| `public/live.js` `addNodeMarker` inline fallback SVG |
`stroke-width="2"` | `stroke-width="1"` |
| `public/map.js` `makeMarkerIcon` switch (all shapes) |
`stroke-width="2"` / `"1.5"` | `stroke-width="1"` |
| `_highlightRing` (pulse on selected/active) | `weight: 3 → 2` |
**unchanged** |
The highlight ring used by `pulseNodeMarker` is the one place where a
heavy outline carries real signal (selected state), so it stays at
weight 3 → 2. The always-on shape stroke is now just enough to keep
silhouettes distinct on both Carto dark and light basemaps without
dominating the surrounding terrain.
## Constraints preserved
- Shape variation (#1293) — per-role shapes still rendered, helper
untouched except for stroke width.
- Colorblind palette — fills/colors unchanged, all via CSS variables /
`ROLE_COLORS`.
- Highlight ring still visible — pulse weight ≥ 2 retained and asserted.
## Tests
New: `test-marker-outline-weight.js` (added to `test-all.sh` unit suite)
- Asserts every `stroke-width` literal in `makeRoleMarkerSVG` is `<= 1`.
- Asserts `live.js` inline fallback SVG `stroke-width <= 1`.
- Asserts the `_highlightRing` (`ringHl.setStyle({ weight: N })`) keeps
at least one `weight >= 2` so highlight stays visible.
Red commit (`d17cfcc`) fails on assertion; green commit (`6cfe99b`)
flips it.
Existing `test-issue-1293-marker-shapes.js` still passes — the
shape-variation and outline-ring highlight contracts are intact.
---------
Co-authored-by: openclaw-bot <bot@openclaw>
## Summary
`/api/nodes/{pk}/paths` (paths-through-node) attributed the same
transmission to **every** prefix-sibling when their hop bytes collided
(e.g. 5 nodes with `c0…` on staging). Querying any of them returned the
tx — visible bug per #1352 where Kpa Roof Solar's view included a packet
whose actual relay was C0ffee SF.
## Root cause
`handleNodePaths` has two branches:
1. **Canonical resolved_path branch (#1278)** — when a tx has a
persisted `resolved_path`, membership is decided from the stored
pubkeys. This branch is correct.
2. **Fallback branch** — when `resolved_path` is NULL/missing, the code
invoked `pm.resolveWithContext(hop, []string{lowerPK}, graph)` to
re-resolve hops. The `hopContext=[lowerPK]` anchors the resolver on the
*queried target*, so the tier-2 (geo-proximity) / tier-3
(GPS+observation-count) tiers preferentially pick the target. Every
`paths-through-X` call for any `X` in the sibling set then resolved the
colliding hop to `X` and counted the tx — wrong-node attribution across
the whole sibling set.
## Fix
Server-side, query-time only. **No DB writes** (`#1289` read-only
invariant preserved). **No canonical-branch changes** — only the
fallback path.
In the fallback branch, accept a biased-resolver match as evidence of
target membership *only* when **either**:
- (a) the tx is already pre-confirmed via the resolved_path index hit or
SQL `INSTR(resolved_path, pubkey)` check, **or**
- (b) the hop's prefix candidate set is unique (`len(pm.m[hop]) <= 1`) —
no collision, no bias possible.
Multi-candidate prefix hops without independent SQL/index confirmation
are now treated as ambiguous and excluded from paths-through. Same rule
applied to the unresolvable-hop sub-case (when `resolveHop` returns nil
but the prefix could match the target).
## Which canonical resolved_path source is used
This PR does **not** introduce a new resolved_path source. It piggybacks
on what's already in place:
- **Canonical branch**: `s.store.fetchResolvedPathForTxBest(tx)` →
SQLite `observations.resolved_path` (populated upstream by the
hop-disambiguator from #1198/#1200/#1235).
- **Pre-confirmation in fallback**: `confirmedByFullKey` (membership
index `s.store.byPathHop[lowerPK]`) and `confirmedBySQL`
(`s.store.confirmResolvedPathContains` → `INSTR(LOWER(resolved_path),
"pubkey")`).
So when canonical data exists, attribution is purely persisted-path
driven; when it doesn't, attribution requires either a SQL pubkey hit or
a unique prefix candidate. Biased resolution alone is no longer
sufficient.
## TDD — red, then green
Two new tests in `cmd/server/paths_through_collision_1352_test.go`:
1. `TestHandleNodePaths_PrefixCollision_1352` — canonical branch
(already green via #1278). 3 nodes share `c0`, tx canonical
resolved_path = [B]. Only paths-through-B includes the tx.
2. `TestHandleNodePaths_PrefixCollision_1352_FallbackBranch` — **red**
before the fix. 3 GPS-having `c0` siblings, NULL resolved_path. Before:
A=1 B=1 C=1 (wrong-node attribution on all). After: ≤1 attribution.
Mutation: reverting the `len(pm.m[hop]) <= 1` guard in `routes.go`
restores the failing red state.
Existing tests preserved:
- `TestHandleNodePaths_PrefixCollisionExclusion` (#929) — still green.
- `TestHandleNodePaths_AnchorBiasInconsistency_Issue1278` (#1278) —
still green.
- Full `go test ./...` on `cmd/server` and `cmd/ingestor`: green.
## Acceptance criteria (from #1352)
- [x] On node detail for Kpa Roof Solar-shape, packet where actual relay
is C0ffee SF does NOT appear in paths-through (canonical branch test).
- [x] On node detail for C0ffee SF-shape, that same packet DOES appear
(canonical branch test).
- [x] Ambiguous fallback case (NULL resolved_path,
multi-prefix-collision) attributes to ≤1 node (fallback test).
- [x] Mutation test: removing the uniqueness guard makes the fallback
test fail.
## Out of scope
- Frontend UX for "ambiguous (N candidates)" badge (separate UX issue).
- Wider hop-disambiguator changes (#1198 family).
Fixes#1352
---------
Co-authored-by: bot <bot@example.com>
Co-authored-by: corescope-bot <bot@corescope>
## Summary
PR #1289 moved neighbor-graph construction into the ingestor with a 60s
ticker. `buildAndPersistNeighborEdges` then issued an **unbounded**
`SELECT … FROM observations o JOIN transmissions t …` every tick. On
staging (3.7M observations) one tick took ~2 minutes; with
`max_open_conns=1`, the SQLite single-writer was held continuously and
MQTT ingest collapsed (~6,500 tx/day → ~180 tx/day, 97% loss).
## Fix
Watermark-bounded delta scan. Each call derives the watermark from
`MAX(neighbor_edges.last_seen)` and restricts the SELECT to `WHERE
o.timestamp > ? ORDER BY o.timestamp LIMIT 50000`. `neighbor_edges`
itself is the persistence — no new metadata table, no in-memory state,
restarts resume cleanly from whatever the table reflects.
- Empty edges table → watermark 0 → full warm-up scan (preserves #1289's
synchronous warm-up intent).
- Warm-up loops the builder until a call returns fewer than the batch
cap, so the first server snapshot load sees a fully-populated table even
on fresh DBs.
- 50k batch cap stops any single tick from monopolising the writer; a
backlog drains over successive ticks.
- Per-tick wallclock is logged (`tick: N edges in DUR`); a tick >5s is
logged loudly as a possible regression of #1339. Broader instrumentation
is tracked in #1340.
- Output schema unchanged — server's `neighbor_recomputer.go` is
unaffected.
## Trade-off
An anomalously-old observation that arrives after its timestamp has been
crossed by the watermark will be skipped. Acceptable for an approximate
neighbor graph; a periodic full-rebuild can land later if needed.
## TDD
- **RED** (`d88e2522`): `TestNeighborEdgesBuilderDeltaScan` seeds 100k
observations, asserts an empty-delta tick is a no-op (<1s), and a
100-row delta is upserted in <500ms with no rescan of baseline rows.
Baseline builder fails the empty-delta assertion (sees all 200k baseline
edges).
- **GREEN** (`cf6fbb4e`): watermark + LIMIT — all assertions pass.
- **Mutation**: revert the `WHERE o.timestamp > ?` clause → the test
hangs to lock-contention timeout, confirming the WHERE actually gates
the behavior.
## Benchmark (synthetic, 100k observations, local sqlite)
| | Scan duration |
|---|---|
| Baseline builder, full scan every tick | ~40s |
| Patched builder, empty-delta tick | <50ms |
| Patched builder, 100-row delta | <50ms |
Staging projection: 2–3 min ticks → <1s ticks; SQLite writer freed for
MQTT ingest.
Fixes#1339
---------
Co-authored-by: openclaw-bot <bot@openclaw.local>
Fixes#1293
## What
Marker shape now varies per role (WCAG 1.4.1 — colour is no longer the
only carrier of role identity), and the live map's selection/highlight
no longer stacks same-colour concentric markers.
| Role | Shape | Why |
|-----------|----------|-----|
| repeater | circle | default, most common |
| companion | square | flat sides, easy to distinguish from circle |
| room | hexagon | tessellation hint = group |
| sensor | triangle | "alert-like" silhouette |
| observer | diamond | network-infrastructure suggestion |
Existing role colours are preserved; the shape is the new differentiator
so red/green colourblind operators can still tell roles apart.
## How
- `public/roles.js`: new `window.ROLE_SHAPES` map (single source of
truth), `ROLE_STYLE.shape` synced, shared
`window.makeRoleMarkerSVG(role, color, size)` helper that emits
self-contained `<svg>` strings — including a new `hexagon` branch.
- `public/map.js`: `makeMarkerIcon` switch picks up the `hexagon` case.
- `public/live.js`: `addNodeMarker` now builds an `L.divIcon` via
`makeRoleMarkerSVG` (was a flat `L.circleMarker` — colour only). A
hidden stroke-only `_highlightRing` is allocated per marker; `pulseNode`
grows + fades that ring instead of recolouring the marker fill, so the
blue-on-blue concentric stacking the issue called out cannot occur.
`rescaleMarkers`, `pruneStaleNodes`, matrix mode toggling now drive the
divIcon via small DOM helpers.
- `public/live.js` role legend: emits SVG shape + colour swatch (was a
bare coloured dot).
- `public/live.css`: `.live-shape-swatch` wrapper for the SVG legend
swatches.
## TDD
Red commit: `7e5e2d95` — `test-issue-1293-marker-shapes.js` asserts the
shape map, helper, hexagon branches, divIcon switch in `addNodeMarker`,
SVG-based legend, and outline-ring highlight (no same-colour fill
overlay). Wired into `deploy.yml` JS unit tests.
Green commit: `fb33ca96`.
## Design check
Coblis simulator (deuteranopia / protanopia / tritanopia) — reviewer to
run on the staging build; shapes carry the signal independent of hue, so
all role categories should remain distinguishable. Existing colours are
retained per the issue's "keep colours, vary shape" guidance.
## Preflight
`bash ~/.openclaw/skills/pr-preflight/scripts/run-all.sh origin/master`
— all gates pass.
---------
Co-authored-by: corescope-bot <bot@corescope>
## Summary
On mobile (≤640px) the Map controls panel was capped at `max-height:
200px` and forced an internal scrollbar through all the
layer/filter/display toggles. This makes every section a single-open
accordion and drops the cap, so the visible content always fits without
internal scroll.
## Changes
- `public/map.js` — Each `fieldset.mc-section` legend becomes a tappable
`aria-expanded` toggle. On mobile the first section opens by default;
activating any other section auto-closes the previously open one
(single-open). Desktop still renders all sections expanded.
- `public/style.css` — `@media (max-width: 640px)` rules:
- `max-height: 200px` → `calc(100vh - 80px)`.
- `.mc-collapsed > *:not(legend) { display: none }` hides bodies of
collapsed sections.
- Legend styled as flex row with ▸/▾ indicator (colors via
`var(--text-muted)`).
- All new rules live inside the mobile media query, so desktop layout is
unchanged.
## Test
`test-issue-1329-map-controls-accordion-e2e.js` (added to CI in
`deploy.yml`):
- mobile 375x812: ≥1 accordion toggle present, ≤1 expanded by default,
no internal scroll, clicking another toggle collapses the first.
- desktop 1280x800: `position: absolute`, panel <50% viewport wide, all
controls visible.
Red commit: `85fdc25267eaf210369371f55da767016435dbff` (test fails on
master — no accordion toggles exist; all fieldsets render expanded under
the 200px cap forcing scroll).
E2E assertion added: `test-issue-1329-map-controls-accordion-e2e.js:56`.
Fixes#1329
---------
Co-authored-by: openclaw-bot <bot@openclaw.dev>
## Summary
Row-overlay Trace and Filter buttons silently did nothing on touch
swipes. `ensureRowOverlay` stamped `data-hash` only on the Copy button,
while `onClickAction` gates both `trace` and `filter` navigation on
`hash && ...` — so the click handler short-circuited before
`location.hash` was set. Users saw the buttons but tapping them was a
no-op.
## Fix
`public/touch-gestures.js` — in `ensureRowOverlay`, stamp `data-hash` on
all three buttons (Trace, Filter, Copy) from the same source the Copy
button already used (`row.getAttribute('data-hash') ||
row.getAttribute('data-id')`). One-line factoring of the attribute
fragment to avoid duplicating the escape logic.
Behavior after fix:
- Trace → `#/packets/<hash>`
- Filter → `#/packets?hash=<hash>`
- Copy → clipboard (unchanged)
All three match the existing branches in `onClickAction`.
## TDD
- **RED commit** (`dd90f72c`): removes the cov1/cov2 workaround in
`test-touch-gestures-coverage-e2e.js` that artificially stamped
`data-hash` on trace/filter buttons from the test harness. With this
commit alone, cov1/cov2 fail their `location.hash` assertions because
`onClickAction`'s guard short-circuits.
- **GREEN commit** (`a526c30f`): production fix in `ensureRowOverlay`.
cov1/cov2 now pass natively against the real production code path with
no harness-side stamping.
## Browser verified
Coverage E2E (`test-touch-gestures-coverage-e2e.js`) exercises the real
swipe → overlay → button-click → navigation path in headless Chromium
against the running server. cov1 asserts `location.hash ===
#/packets/<hash>`, cov2 asserts `location.hash ===
#/packets?hash=<hash>` — these assertions are the regression gate.
E2E assertion added: test-touch-gestures-coverage-e2e.js:227 (cov1
trace) and test-touch-gestures-coverage-e2e.js:259 (cov2 filter).
## Preflight
All hard gates and warnings pass.
Fixes#1305
---------
Co-authored-by: openclaw <bot@openclaw>
Test-only flake fix. `drawer.getBoundingClientRect().left` can be
`-0.79` or `-0.000003` due to sub-pixel float rounding in the browser
compositor; relax `=== 0` to `Math.abs(rect.left) < 1` (1px tolerance —
anything larger would represent an actual layout bug).
No production code touched. Unblocks master CI.
Co-authored-by: openclaw-bot <bot@openclaw.local>
## Problem
The ingestor stamps every stored packet with its own ingest-time
`time.Now()`
(`BuildPacketData` in `db.go`; channel/DM paths in `main.go`),
discarding the
observer receive time the uploader already puts in the MQTT envelope's
`timestamp` field. `MQTTPacketMessage` had no `Timestamp` field and
`handleMessage` parsed every envelope field except that one.
Observers that buffer packets offline and upload hours later get every
buffered packet displayed at upload time, not receive time — a 5-hour
deferred upload shows packets 5 hours late. Retained messages and broker
backlog hit the same skew.
## Why the envelope timestamp is trustworthy
Uploaders stamp `timestamp` when the radio receives the frame and freeze
it;
the MQTT *message* is published late, but the `timestamp` *field* is not
re-stamped at publish. A buffered packet uploaded hours late still
carries
its true receive time.
## Fix
New `resolveRxTime` helper reads `msg["timestamp"]` and falls back to
`time.Now()` only when it is missing, unparseable, or implausibly in the
future. Applied to all three ingest paths (raw packet, channel, DM). No
wire-format change — the field already exists.
Channel/DM dedup hashes intentionally stay on ingest time, since those
bridge
messages carry no real packet hash and need ingest-unique input.
## Observer/node last_seen correction
Packet timestamps must reflect receive time, but observer/node
`last_seen`
must not. `InsertTransmission` fed `data.Timestamp` (now rxTime) into
`observers.last_seen` and `UpsertNode`'s `last_seen`, so a buffered
upload
could drag both fields backwards, and retained-message replay on MQTT
reconnect could flash long-offline observers as Online.
- `UpsertObserverAt` takes an explicit `lastSeen`; the status-packet and
BLE
companion handlers pass the resolved rxTime. `UpsertObserver` keeps its
wall-clock behaviour for other callers.
- All three `last_seen` writes are guarded with
`MAX(MIN(existing, ingestNow), rxTime)`: `last_seen` never moves
backwards
from a stale retained message, and never locks in a future value.
## Naive UTC+N timestamps
`resolveRxTime` rejects a timestamp only when it is >14h ahead (UTC+14
is the
maximum standard offset — anything further is a genuine clock error). A
timestamp that is merely in the future is soft-clamped to ingest time: a
future rxTime means a live packet from a UTC+N observer whose naive
local
clock parses as-if UTC, not a buffered packet, so ingest time is correct
and
no future timestamp reaches the DB.
For buffered packets from naive-clock uploaders a bounded residual
offset
remains (equal to the observer's UTC offset); uploaders emitting
zone-aware
ISO8601 everywhere would be the full cure but is a separate format
change.
## Test
`cmd/ingestor/rxtime_test.go` covers `parseEnvelopeTime` (zone-aware,
naive,
microseconds, garbage, empty) and `resolveRxTime` (plausible past used
verbatim, missing/garbage/future → ingest-time fallback). The existing
`TestBuildPacketData` is updated to supply an envelope timestamp and
assert it
propagates, since `BuildPacketData` no longer self-stamps.
Red commit `2a8102b9` (failing test) → green commit `bb957c9f`. CI:
https://github.com/Kpa-clawbot/CoreScope/actions/workflows/ci.yml?query=branch%3Afix%2Fissue-1321Fixes#1321.
## Why
On staging `/api/scope-stats` 500'd with `scope_name column not present`
despite the ingestor adding the column ~0.5s after server startup.
`cmd/server/db.go detectSchema()` runs in `OpenDB` and caches
`hasScopeName`/`hasDefaultScope`/`hasObsRawHex` booleans. With
supervisord launching server + ingestor simultaneously, the server's
PRAGMA can fire BEFORE the ingestor's `ALTER TABLE` completes — and the
boolean stays false until the server restarts. Same race class as #1283;
#1289 moved server-side ensures to `dbschema` but the optional columns
the ingestor still owned were left out.
## Fix — option (c) from the issue
Made `internal/dbschema/dbschema.go` the single source of truth for the
optional columns the server detects.
**Migrations moved from `cmd/ingestor/db.go applySchema` into
`dbschema.Apply`:**
- `transmissions.scope_name` + `idx_tx_scope_name` partial index
- `nodes.default_scope`
- `inactive_nodes.default_scope`
- `observations.raw_hex`
**`AssertReady` now asserts** every one of those columns. The server
cannot start with stale-false booleans because `AssertReady` will fatal
first if the columns are missing. The ingestor's old gated blocks are
replaced with pointer comments so anyone hunting for them lands in
`dbschema.go`. The `_migrations` marker rows are preserved (`INSERT OR
IGNORE`) to keep legacy DBs idempotent.
**Documented invariant** in the package doc: any new optional column the
server PRAGMA-detects belongs in `internal/dbschema/dbschema.go`, NOT in
`cmd/ingestor/db.go applySchema`.
## Tests
Added `internal/dbschema/dbschema_test.go` (RED in `2a8102b9`):
- `TestApplyAddsOptionalColumns_CanonicalSource` — post-`Apply`, all
four columns must exist.
- `TestAssertReady_RequiresOptionalColumns` — `AssertReady` must refuse
a DB missing them AND pass after full `Apply`.
`cmd/ingestor` and `cmd/server` full suites green.
---------
Co-authored-by: openclaw-bot <bot@openclaw.local>
## Summary
- `#darkModeToggle` sits inside `.nav-right` which is `display: none
!important` at ≤768px — mobile users had no way to switch themes
- Adds a **Dark mode / Light mode** button at the bottom of the More
sheet, separated from the route list by a hairline rule
- Click delegates to `#darkModeToggle` so `app.js` remains the single
owner of all theme logic (no duplication)
- Icon (`🌙` / `☀️`) and label sync on every sheet open and after each
toggle
## Test plan
- [ ] Mobile (≤768px): open More sheet → "Dark mode" / "Light mode"
button visible at the bottom
- [ ] Tap button → theme toggles, sheet closes, icon/label update
correctly on next open
- [ ] Tap button repeatedly → theme keeps toggling correctly
- [ ] Desktop (>768px): no visual change, `#darkModeToggle` in top-nav
still works normally
- [ ] `prefers-reduced-motion`: no transitions (inherited from existing
sheet-item rule)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Summary
- `nav-drawer.js` was wired up in `index.html` (issue #1064) but
`nav-drawer.css` was never created
- Without `position: fixed` and `transform: translateX(-100%)` the
`<aside class="nav-drawer">` rendered as a visible inline block at the
bottom of every page, showing **"Navigate×"** followed by the route list
- Adds the missing stylesheet with proper slide-over layout, backdrop,
transition, and `display: none` guard at ≤768px (bottom-nav More tab
covers those routes)
## Test plan
- [ ] Desktop (>768px): "Navigate×" bar no longer visible at bottom of
any page
- [ ] Desktop: left-edge swipe/touch still opens the drawer and it
slides in from the left
- [ ] Mobile (≤768px): nav drawer fully hidden, bottom-nav More tab
unchanged
- [ ] Dark mode and light mode: drawer uses the correct `--nav-bg` /
`--nav-text` tokens
- [ ] `prefers-reduced-motion`: transitions disabled
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Summary
- `animatePath` signature changed from `(..., hash)` to `(..., pktMeta)`
when #923 was merged
- The `drawAnimatedLine` call inside `nextHop()` still referenced the
bare `hash` variable, which is no longer in scope
- This causes a `ReferenceError` on every hop iteration, aborting the
chain after the first pulse dot — **animated lines never draw**, only
blinking dots appear
## Fix
Replace `hash` → `pktMeta?.hash` on the single affected
`drawAnimatedLine` call (line 2891 in `public/live.js`).
## Test plan
- [ ] Open MESH LIVE page with live MQTT data flowing
- [ ] Confirm animated path lines draw between nodes (not just blinking
dots)
- [ ] Confirm clickable path popups still work (pktMeta.hash still
passed correctly)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Problem
When CI flakes on a `push` to master and is later manually re-run via
`workflow_dispatch`, the `🚀 Deploy Staging` job is **skipped** even
though all upstream jobs pass. Staging stays stale until someone pushes
another commit.
Example: run `26266461986`.
## Fix
`.github/workflows/deploy.yml` — relax the deploy job's `if:` gate to
allow `workflow_dispatch` reruns on master:
```yaml
deploy:
name: "🚀 Deploy Staging"
if: |
(github.event_name == 'push' || github.event_name == 'workflow_dispatch')
&& github.ref == 'refs/heads/master'
needs: [build-and-publish]
```
Behavior matrix:
- Push to master → deploys (unchanged)
- Manual `workflow_dispatch` on master → **deploys** (was: skipped —
this is the fix)
- PR runs → no deploy
- Push to non-master branch → no deploy
- `needs: [build-and-publish]` still gates on Docker build success
## TDD exemption
Pure CI workflow config change. AGENTS.md "Config changes" exemption
applies — testing this guard requires triggering a real CI run, which
the PR itself does. No test files modified; existing tests stay green
and unaltered.
## Scope
One file: `.github/workflows/deploy.yml` (3 lines added, 1 removed).
Fixes#1319
Co-authored-by: openclaw-bot <bot@openclaw.local>
Master CI failing on `test-channel-color-picker-e2e.js` outside-click
step. Test-only fix copied from PR #1300 branch (SHA 7f848848): real
mouse click instead of `element.click()`, wait for listener install.
Test-only change; no production code touched.
Co-authored-by: Kpa-clawbot <bot@kpa-clawbot.local>
## Summary
- Adds configurable GPS polygon areas to `config.json`; nodes are
attributed to an area if their last-known position falls inside the
polygon
- New `Area: …` dropdown filter (matching the existing region filter
style) appears on all analytics, nodes, packets, map, and live screens
when areas are configured
- Backend resolves area membership with a 30s TTL cache; area filter
bypasses the 500-node cap on `/api/bulk-health` so all area nodes are
always returned
- Includes a polygon builder tool (`/area-map.html`) for drawing and
exporting area boundaries
## Changes
**Backend**
- `AreaEntry` type + `Areas` config field
- `GetNodePubkeysInArea` DB query + `resolveAreaNodes` (30s TTL,
`areaNodeMu` RWMutex)
- `PacketQuery.Area` + `filterPackets` polygon check
- `?area=` param propagated through all analytics, topology,
clock-health, and bulk-health routes
- `/api/config/areas` endpoint
**Frontend**
- `area-filter.js`: single-select dropdown, persists to localStorage,
cleans up stale keys on load
- Wired into analytics, nodes, packets, channels, map, and live pages
- Live map clears node markers on area change
**Docs & tools**
- `docs/user-guide/area-filter.md` — configuration and usage guide
- `docs/api-spec.md` — updated with new endpoint and `?area=` param
table
- `tools/area-map.html` — polygon builder for defining area boundaries
- Demo areas added to `config.example.json`
## Test plan
- [x] No areas configured → filter dropdown does not appear on any page
- [x] Areas configured → dropdown appears, "All" selected by default
- [x] Selecting an area filters nodes/packets/topology/map correctly
- [x] Selecting "All" restores unfiltered view
- [x] Selection persists across page reloads (localStorage)
- [x] Stale localStorage key (area removed from config) is cleared on
load
- [x] `/api/bulk-health?area=X` returns all nodes in area (no 500-node
cap)
- [x] `/api/config/areas` returns correct list
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Kpa-clawbot <kpaclawbot@outlook.com>
Co-authored-by: openclaw-bot <bot@openclaw.local>
@
## What this PR does
Implements region-scoped transport-route packet tracking with two
sub-features:
### Feature 1 — Scope statistics (`scope_name`)
- At ingest, transport-route packets (route_type 0/3) with Code1 !=
`0000` are HMAC-matched against configured `hashRegions` keys (mirroring
the `hashChannels` pattern). Matched region name (or `""` for unknown)
stored in new `transmissions.scope_name` column via migration
`scope_name_v1`.
- New `GET /api/scope-stats?window=` endpoint (1h/24h/7d, 30s
server-side TTL) returning transport totals, scoped/unscoped counts,
per-region breakdown, and time-series.
- New **Scopes** tab in Analytics with summary cards, per-region table,
and two-line SVG chart. Auto-refreshes every 60s.
### Feature 2 — Node default scope (`default_scope`)
- Per-node `default_scope` column on `nodes`/`inactive_nodes` (migration
`nodes_default_scope_v1`) tracks the most recently matched region for
each node, derived from transport-scoped ADVERT packets.
- `GET /api/nodes` response includes `default_scope` field when column
is present.
- Node detail panel displays the default scope badge.
- Async startup backfill (`BackfillDefaultScopeAsync`) populates the
column for nodes with pre-existing ADVERT data.
### Config
Add `hashRegions` to `config.json` (see `config.example.json`). One
entry per region name (with or without leading `#`).
@
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Kpa-clawbot <kpaclawbot@outlook.com>
Co-authored-by: openclaw-bot <bot@openclaw.local>
Master Docker build fails with `internal/prunequeue/go.mod: no such file
or directory` because #738 added `internal/prunequeue/` as a
replace-directive module in `cmd/server` and `cmd/ingestor` `go.mod`,
but `Dockerfile` was never updated to `COPY` it into the builder stages.
Adds the missing `COPY internal/prunequeue/ ../../internal/prunequeue/`
to both server and ingestor sections, alongside the other `internal/*`
COPYs.
Same class of bug as #1308 (dbschema, after #1289). Config-changes
exemption per AGENTS.md (Dockerfile-only).
Fixes#1314
Co-authored-by: Kpa-clawbot <bot@kpa-clawbot.local>
Red commit: `5f366b71` — CI: pending (will link once first run starts).
Fixes#1311
## The bug
`applyNavPriority` in `public/app.js` had no floor on the iterative
overflow loop:
```js
let i = 0;
while (!fits() && i < overflowQueue.length) {
overflowQueue[i].classList.add('is-overflow');
i++;
}
```
The `overflowQueue` is built non-high-first then high-priority tail.
When `fits()` kept returning `false` — because the active-route pill
renders wider than other links — the loop walked past the non-high tail
and started dropping high-priority links too. On a non-high active route
(`/#/perf`, `/#/audio-lab`, `/#/analytics`, `/#/observers`) at
~1101–1200px, this nuked Home/Packets/Map/Live/Nodes and left the user
with brand + "More ▾" + the active pill.
## Repro (master)
1. `go build ./cmd/server` and serve against the e2e fixture
2. Visit `http://localhost:13581/#/perf` at 1101px viewport
3. Inline strip shows only "More ▾" + the ⚡ Perf pill —
Home/Packets/Map/Live/Nodes are all gone
4. New E2E (`test-nav-priority-1311-e2e.js`) reproduces this: 4/16 cases
fail at 1101px on master.
## The fix
Two-line floor in the loop guard: break when the next queue item is a
high-priority link.
```js
while (!fits() && i < overflowQueue.length) {
if (overflowQueue[i].dataset.priority === 'high') break;
overflowQueue[i].classList.add('is-overflow');
i++;
}
```
The `>=2` More-menu floor (#1139) gets the same guard — never promote a
high-priority link just to hit the floor. A degenerate 1-item dropdown
is a smaller paper-cut than nuking primary nav.
## TDD trail
- **RED commit `5f366b71`**: `test-nav-priority-1311-e2e.js` lands
first. Asserts (`assert.deepStrictEqual`) all 5 high-priority hrefs are
visible inline at 900/1024/1101/1200px on /#/perf, /#/audio-lab,
/#/analytics, /#/observers (16 cases). Fails 4/16 against master.
- **GREEN commit `6d1a5542`**: floor added; 16/16 pass. Existing nav
suite still green:
- `test-nav-priority-1102-e2e.js`: 5/5 ✅
- `test-nav-more-floor-1139-e2e.js`: 10/10 ✅
- `test-nav-fluid-1055-e2e.js`: 20/20 ✅
- **Mutation guard**: stash the floor → test fails 4/16 again on the
same cases.
Browser verified: chromium 136 against local Go server with
`test-fixtures/e2e-fixture.db` at 900/1024/1101/1200px on each non-high
route.
E2E assertion added: `test-nav-priority-1311-e2e.js:107`
(`assert.deepStrictEqual`).
## Constraints respected
- Existing 5/5 inline behavior on /#/home (active route IS
high-priority) — preserved by 1102 suite ✅
- `<=1100` branch — unchanged (already data-priority-aware) ✅
- `>=2` More-menu floor (#1139) — preserved + extended with the same
high-pri guard ✅
- All colors via CSS vars ✅
- PII preflight clean ✅
---------
Co-authored-by: CoreScope Bot <bot@corescope>
## Summary
- **Filter bar heights**: `.btn` and `.col-toggle-btn` carried
`min-height:48px` from the WCAG touch-target rule, making buttons like
`Group by Hash`, `★ My Nodes`, `Columns ▾`, and text inputs visibly
taller than the `multi-select-trigger` / `region-dropdown-trigger`
controls (which don't carry `.btn` and were already correct at 34px).
Fix adds `min-height:34px` overrides to `.filter-bar .btn`,
`.filter-group .btn`, `.filter-bar .col-toggle-btn`, and `.filter-bar
input, .filter-bar select` so the entire filter bar renders at a uniform
34px on desktop.
- **MESH LIVE panel**: `.live-overlay` sets `flex-direction:column` on
all overlay panels; `.live-header` did not override this. With
`#liveAreaFilter` populated (when areas are configured), the panel
stacked 4 rows — title, stats, toggles, area filter — consuming ~⅓ of
viewport height. Switch `.live-header` to `flex-direction:row;
flex-wrap:wrap`, give `.live-toggles` `flex:0 0 100%` to force it to its
own line, and move `#liveAreaFilter` inside `.live-toggles` so the area
dropdown is inline with the other controls. Panel shrinks from 4 rows to
2 rows.
## Test plan
- [x] Packets page filter bar: `Filters ▾`, text inputs, `All
Observers`, `All Types`, `Group by Hash`, `★ My Nodes`, `Columns ▾`,
`Hex Paths` all render at uniform ~34px height on desktop
- [x] Mobile (≤767px): filter bar touch targets unaffected (mobile media
query still authoritative)
- [x] Live page: MESH LIVE panel occupies 2 rows (title+stats / toggles)
instead of 4
- [x] Live page: `Area: All ▾` appears inline in the toggles row when
areas are configured; panel hides the area control entirely when no
areas are configured (existing behavior)
- [x] Audio controls still appear correctly when the Audio toggle is
checked
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Summary
- Drop prefix-only paths from path graph: partial observations (same
packet seen at 1, 2, 4, 5 hops as it propagated) were treated as
separate routes, producing long shortcut edges to Dest that visually
obscured the actual relay chain. Now filters out any path that is a
strict prefix of a longer observed path before building the graph.
- Fix invisible node labels: intermediate hop nodes used white text on
`--surface-2` background, making labels invisible in the light theme.
Labels now appear below circles and use `var(--text)` for theme-aware
contrast. Increased SVG height and node radius to give labels room;
intermediate fill uses a subtle accent tint with accent border.
## Test plan
- [ ] Open a TRACE packet's path graph with a node that has multiple
partial observations — verify no spurious shortcut edges
- [ ] Check path graph in light theme — verify intermediate hop labels
are visible
- [ ] Check path graph in dark theme — verify no regression
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Summary
- Adds `"compression": {"gzip": true, "websocket": true}` config option
(both `false` by default — no behavior change)
- HTTP gzip middleware wraps the entire router; skips WebSocket upgrade
requests and clients without `Accept-Encoding: gzip`
- WebSocket permessage-deflate enabled via
`hub.upgrader.EnableCompression` when `websocket: true`
- `CompressionConfig` struct and `GZipEnabled()` /
`WSCompressionEnabled()` helpers on `Config`
- `Hub.upgrader` moved from package-level var to struct field so tests
using `NewHub()` don't need changes
## Why opt-in / off by default
Operators behind a reverse proxy that already compresses (nginx, Caddy
with `encode gzip`) should leave this off to avoid double-compression.
Only enable when the proxy does **not** compress.
## Test plan
- [x] `TestCompressionConfigDefaults` — both helpers return false when
`Compression` is nil
- [x] `TestCompressionConfigExplicitFalse` — both helpers return false
when set to false
- [x] `TestCompressionConfigEnabled` — both helpers return true when set
to true
- [x] `TestGZipMiddlewareCompresses` — response body is valid gzip,
headers set correctly
- [x] `TestGZipMiddlewareSkipsNoAcceptEncoding` — passthrough when
client doesn't send Accept-Encoding: gzip
- [x] `TestGZipMiddlewareSkipsWebSocket` — WebSocket upgrades are never
gzip-wrapped
All 6 tests pass (`go test ./...` in `cmd/server`).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: OpenClaw Bot <bot@openclaw.local>
Co-authored-by: efiten-bot <bot@efiten.dev>
## Summary
- **Backend**: adds `relayTimes` in-memory index (sorted unix-millis per
repeater pubkey), maintained in lockstep with `byPathHop`. Populated at
startup from all packet observations (not just best), updated on
ingest/evict/backfill. Exposes `relay_count_1h`, `relay_count_24h`,
`last_relayed` in both `/api/nodes` (for repeaters) and
`/api/nodes/{pubkey}/health`.
- **Frontend**: `getNodeStatus` extended to three-state (`relaying` /
`active` / `stale`) for repeaters based on relay_count_24h.
`getStatusInfo` is the single source of truth for status label,
explanation, and relay stats. Detail pane shows relay counts and last
relayed time. Nodes list gets a status emoji column with hover tooltip
showing relay info.
- **Correctness fixes**: relay index scans all observations per packet
(not just best); backfill now updates relay index after resolving paths;
pubkeys lowercased consistently throughout index.
## Changes
### `cmd/server/store.go`
- `relayTimes map[string][]int64` field added to `PacketStore`
- `addTxToRelayTimeIndex` / `removeFromRelayTimeIndex`: scan all
observations, idempotent sorted insert, lowercase keys
- `relayMetrics(times, nowMs)`: returns `(count1h, count24h,
lastRelayed)`
- `buildPathHopIndex`: populates `relayTimes` at startup
- `pollAndMerge`: updates relay index on ingest and eviction; new `else`
branch for path-unchanged observations
- `addTxToPathHopIndex` / `removeTxFromPathHopIndex`: lowercase resolved
pubkeys (fixes casing mismatch with lookup)
### `cmd/server/routes.go`
- `GetBulkHealth` / `GetNodeHealth`: include relay stats for repeater
nodes
- `handleNodes`: enriches repeater nodes with relay stats from
`relayTimes` so list view has same data as detail pane
### `cmd/server/neighbor_persist.go`
- `backfillResolvedPathsAsync`: calls `addTxToRelayTimeIndex` after
`pickBestObservation` to capture newly resolved pubkeys
### `public/roles.js`
- `getNodeStatus(role, lastSeenMs, relayCount24h)`: three-state logic
for repeaters
- `getStatusInfo(n)`: single source of truth returning status, label,
explanation, relay counts, last relayed
### `public/nodes.js`
- Detail pane: `n.stats` populated from health endpoint before
`getStatusInfo` call
- Nodes list: status emoji column with relay hover tooltip; status
filter uses `getStatusInfo`
### Tests
- `relay_liveness_test.go`: index functions, relay metrics, wiring
integration, bulk/single health endpoints
- `test-repeater-liveness.js`: three-state frontend logic, backward
compat
## Test plan
- [x] Repeater with recent relay traffic shows green relaying emoji in
list and detail pane
- [x] Repeater with no relay traffic in 24h shows yellow idle in both
views
- [x] Repeater not heard recently shows grey stale in both views
- [x] Non-repeater nodes unaffected (no relay stats, no status change)
- [x] Hover tooltip on list emoji shows relay count and last relayed
time
- [x] `go test ./...` passes
- [x] `node test-repeater-liveness.js` passes
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: openclaw-bot <bot@openclaw.local>
## Summary
Master CI failing on `test-home-coverage-e2e.js` (from #1303). Two flaky
tests blocking all downstream PRs:
- search suggestions timeout (5s too tight)
- "Full health" click hits stale element handle
## Fix (test-only)
- Wait for `#homeSearch` visible before fill; raise suggestions wait 5s
→ 15s; accept `.suggest-loading` intermediate state
- Switch Full health click to locator (auto-retries on detach);
pre-click waitForFunction for non-zero bounding rect; force-click
fallback
No production code touched. PII preflight clean.
---------
Co-authored-by: Kpa-clawbot <bot@kpa-clawbot.local>
Co-authored-by: clawbot <bot@openclaw.local>
Extends VCR speed cycle to `[0.25, 0.5, 1, 2, 4, 8]` so users can watch
live paths in slow motion.
## Changes
- `vcrSpeedCycle()`: speed array extended to include `¼x` and `½x`;
saves preference to `localStorage('live-vcr-speed')`
- `speedLabel()`: new helper returning `¼x` / `½x` for sub-1x, used in
the speed button
- `drawAnimatedLine`: step interval scales with speed (`33 / VCR.speed`)
- `drawMatrixLine`: `DURATION_MS` scales with speed (`1100 / VCR.speed`)
- Speed preference restored from localStorage on page load
## Tests
3 new unit tests; 72 pass, 0 regressions.
Closes#771 (M1 of 3)
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Problem
`handleNodes` enriches each repeater/room node by calling
`GetRepeaterRelayInfo` and `GetRepeaterUsefulnessScore` **per node**
inside a loop. `GetRepeaterUsefulnessScore` acquires `s.mu.RLock()` and
then iterates **all** `byPayloadType` entries to compute the non-advert
denominator — once per node.
On a deployment with ~1500 repeater/room nodes and ~145K transmissions
in memory, this is **~220M iterations per `/api/nodes` request**, plus
~3000 separate lock acquisitions. Response times of 18–44 seconds have
been observed in production, especially during startup backfill when
write-lock contention compounds the issue.
## Fix
Add `GetRepeaterNodeStatsBatch(pubkeys []string, windowHours float64)
map[string]RepeaterNodeStats` to `repeater_usefulness.go`:
- Takes **one** `s.mu.RLock()` for the entire node list
- Computes the non-advert denominator **once** (shared across all nodes)
- Snapshots `byPathHop` slice headers for all requested pubkeys under
that single lock
- Processes timestamps and counts **outside** the lock
Update `handleNodes` to collect repeater/room pubkeys first, call the
batch method once, and apply results.
**Complexity: O(M + N) instead of O(N × M)** per request (M = total
transmissions, N = repeater nodes).
`GetRepeaterRelayInfo` and `GetRepeaterUsefulnessScore` are unchanged —
they are still correct for single-node calls (e.g. `handleNodeDetail`).
## Test plan
- [ ] `go build ./cmd/server` passes
- [ ] `/api/nodes` response is correct (relay_active,
relay_count_1h/24h, usefulness_score fields present for repeaters)
- [ ] No change in output for `/api/nodes/{pubkey}` (uses existing
single-node methods)
- [ ] CI passes
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: openclaw-bot <bot@openclaw.local>
After a path animation completes, keeps an invisible clickable polyline
on the map for 30s. Clicking it shows a compact Leaflet popup with type
badge, hop chain, relative time, and a link to the full packets page.
Popup auto-dismisses after 20s.
## Changes
- `clickablePathsLayer`: new Leaflet layer for invisible hit-target
polylines
- `buildClickablePathPopupHtml()`: pure function generating popup HTML
(type badge, hop chain, time, hash link)
- `pruneClickablePaths()`: TTL (30s) + FIFO eviction (max 50); runs on
existing `_pruneInterval`
- `registerClickablePath()`: adds invisible polyline with click → popup
handler
- `animatePath()`: accepts optional `pktMeta` (`hash`, `ts`); calls
`registerClickablePath` on completion
- Teardown clears `clickablePathsLayer` and `clickablePaths`
## Tests
7 new unit tests; 77 pass, 0 regressions.
Closes#771 (M2 of 3)
---------
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
## Problem
`indexByNode()` was called during `Load()` immediately when each
`StoreTx` was created — before observations were appended and before
`pickBestObservation()` set `tx.ResolvedPath`. The resolved_path
indexing branch added in #708 was effectively dead code on every server
restart.
**Symptom:** After any restart, `byNode[relay_pubkey]` was empty for
relay-only nodes even when `resolved_path` was correctly persisted in
the DB. Analytics showed `totalPackets = 0` for repeater nodes despite
active relay traffic.
## Fix
Call `s.indexByNode(tx)` again in the post-load loop after
`pickBestObservation()`, where `ResolvedPath` is populated. Same fix
applied to `backfillResolvedPathsAsync()`, which also called
`pickBestObservation()` without re-indexing afterward.
The dedup in `nodeHashes` prevents double-counting: pubkeys already
indexed from decoded JSON fields are skipped; only the relay hop pubkeys
from `resolved_path` are new additions.
## Test
`TestLoadIndexesRelayHopsFromResolvedPath` — inserts a packet with
`resolved_path` containing a relay pubkey that does not appear in
`decoded_json`, calls `Load()`, and verifies `byNode[relay_pubkey]` is
populated.
## Related
Closes#692 (together with #707, #708, #711 already merged)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Kpa-clawbot