## Summary
Reframes the CB-preset feature as an **end-user opt-in** layered above
operator
config — not the canonical color source for the app. Implements the
cascade
defined in #1446's acceptance test and fixes the #1444 cascade trap as a
side effect.
**Cascade (top wins):**
```
user per-role override > active CB preset > server config.nodeColors > built-in :root defaults
```
Red commit: f59c0c5e (8 scenarios, 9 assertions red on master)
Green commit: 21f9b80c (all 16 assertions pass; reverting any one of the
four
source files brings the test back red).
## Changes
| File | What |
|---|---|
| `cb-presets.js` | `currentPreset()` returns `null` on no-stored-preset
(was `'default'`). `initFromStorage()` no longer auto-applies Wong cold.
New `clearPreset()` API. |
| `style.css` | Drop the `body[data-cb-preset="default"]` block. Wong
remains `:root` baseline; that block was masking server config in the
"no preset" state. |
| `roles.js` | `setRoleColorOverride` writes to `body.style` with
`!important` so user picks win on equal-specificity cascade against
`body[data-cb-preset="X"]` (root cause of #1444). |
| `customize-v2.js` | `applyCSS`: when no preset active, server-config
nodeColors get `--mc-role-{role}` too. UI re-ordered (Node Role Colors
first, preset section labelled "Optional"). Wires `cb-preset-changed`
listener so `clearPreset()` re-applies server config live. |
## Backward compat
- Visitors with a stored CB preset in localStorage continue to see it on
load.
- Visitors without one: now see operator's `config.json` colors (or
built-in
Wong if config has no `nodeColors`). Visually identical for default
deploys.
## Acceptance scenarios (verified in
`test-issue-1446-cb-preset-cascade.js`)
1. Cold boot, no localStorage → no `data-cb-preset` attr, no
`--mc-role-*` clamp
2. Server `nodeColors.repeater = #aaaaaa`, no preset →
`--mc-role-repeater = #aaaaaa`
3. User picks `#ff00ff` while `deut` active → body inline `!important`
wins
4. Clear override while `deut` active → reverts to `#FE6100` (deut)
5. Clear preset (server config present) → reverts to server config
6. Stored preset auto-applies on boot (backward compat)
7. Customizer UI: Node Role Colors block precedes preset block
8. `style.css`: no body data-cb-preset rule re-defines Wong (would mask
server)
Post-merge CDP verification on staging will run the 5 issue-acceptance
scenarios.
Closes#1446Fixes#1444 (cascade)
E2E assertion added: `test-issue-1446-cb-preset-cascade.js:124`
(scenario 3 — user override beats active preset on body inline with
!important).
Browser verified: pending hot-deploy + CDP run post-merge (per task
brief).
---------
Co-authored-by: openclaw-bot <bot@openclaw.local>
## Summary
Closes the final gap left by #1439 (marker SVG `fill="var(--mc-role-X)"`
migration) and #1441 (body.style write in `setRoleColorOverride`).
Both prior PRs made marker SVGs read from `--mc-role-{role}` CSS vars,
and made the LIVE customizer pick path write that var via
`setRoleColorOverride`. But the second leg of the round-trip was still
broken:
**On page reload**, `customize-v2.js applyCSS()` replays
`userOverrides.nodeColors` from localStorage and writes only
`--node-{role}` (the legacy var). `setRoleColorOverride` is **not**
replayed. Result: marker fills revert to the active preset's colors even
though the operator's custom hex is still in localStorage.
## Fix
Extend the per-role loop in `applyCSS` to write **both** `--node-{role}`
(legacy compat) and `--mc-role-{role}` (the var marker SVGs now read).
```js
for (var role in nc) {
root.setProperty('--node-' + role, nc[role]);
root.setProperty('--mc-role-' + role, nc[role]); // NEW
}
```
`public/customize.js` `setRoleColorOverride` path: already correct in
`roles.js` (#1441 wrote the body.style hop with the explicit #1438
comment). No change needed there — the gap was specifically the
reload-time replay in customize-v2.
## Test
New `test-issue-1438-customizer-mcrole.js` — source-invariant assertions
on the loop body. Red commit fails on the `--mc-role-` assertion; green
commit passes 4/4. Added to `test-all.sh`.
## Verification plan
Post-merge hot-deploy + CDP verify on `analyzer-stg.00id.net`:
1. `setOverride('nodeColors','repeater','#ff00ff')` →
`applyCSS(computeEffective())`
2. Assert
`getComputedStyle(documentElement).getPropertyValue('--mc-role-repeater')
=== '#ff00ff'`
3. Sample a repeater marker SVG, assert `getComputedStyle(...).fill ===
'rgb(255, 0, 255)'`
4. Screenshot
Closes#1438.
---------
Co-authored-by: openclaw-bot <bot@openclaw.local>
## Summary
Follow-up to #1439. Empirical CDP verification on staging caught a
residual bug: the customizer per-role override updated
`documentElement.style` (where the override helper writes) but mounted
SVG markers and other CSS-var consumers kept showing the active preset
colour.
## Root cause
`cb-presets.js` ships stylesheet rules of the form:
```css
body[data-cb-preset="deut"] {
--mc-role-companion: #648FFF;
...
}
```
This selector beats inheritance from `:root.style` (which is where
#1439's `setRoleColorOverride` wrote). Body inline style beats both.
## Fix
`setRoleColorOverride` now writes the override to BOTH
`documentElement.style` and `document.body.style`. The first-override
snapshot is captured per target so clear-override still restores the
active preset value (#1412 contract preserved).
## Verification
- `test-issue-1438-marker-css-vars.js` extended with assertion E2
(helper touches `document.body` / `body.style`)
- `test-issue-1412-customizer-no-override.js` — 13/13 still pass
(clear-override-restores-preset)
- `test-issue-1407-cb-preset-propagation.js` — 61/61 still pass
- Staging CDP verified: `applyPreset('deut')` +
`setRoleColorOverride('companion', '#ff00ff')` repaints all 55 mounted
companion markers to magenta without reload.
## Preflight
`bash ~/.openclaw/skills/pr-preflight/scripts/run-all.sh origin/master`
— clean.
Fixes the residual case left after #1439.
Co-authored-by: OpenClaw Bot <bot@openclaw>
## Summary
Fixes#1438. Map + Live node markers and customizer per-role overrides
did not honor CB-preset switches because:
- SVG markers baked `ROLE_COLORS[role]` hex into `fill=` attribute at
marker creation. Existing markers were stale until full page reload
after `MeshCorePresets.applyPreset(...)`.
- `setRoleColorOverride` only mutated the JS `_roleOverrides` map; the
`--mc-role-{role}` CSS var (source of truth for cluster pills, route
lines, all CSS-var-driven surfaces) was never updated, so operator picks
were invisible to those surfaces.
## Fix shape
Empirically verified in headless chromium: CSS-var-on-SVG-fill **does**
repaint mounted elements when the variable value changes. Pure CSS-var
migration is sufficient — no `cb-preset-changed` listener needed on the
marker layers.
- **`public/roles.js makeRoleMarkerSVG`** — default fill is now
`var(--mc-role-{role})`; callers passing an explicit colour (matrix
mode, stale dim) still win.
- **`public/map.js makeMarkerIcon` + observer star overlay** — same
migration to `var(--mc-role-{role})` / `var(--mc-role-observer)`.
- **`public/live.js addNodeMarker`** — passes `null` to
`makeRoleMarkerSVG` so the var path is used; inline fallback SVG also
uses the var.
- **`public/roles.js setRoleColorOverride`** — now writes
`--mc-role-{role}` on `documentElement.style`. On clear, restores the
preset value captured at first-override time, preserving #1412's
contract ("clearing override reverts to active preset").
## TDD
Red commit: `test-issue-1438-marker-css-vars.js` asserts the CSS-var
contract across all four files. Failed 5 assertions on `master`:
- `makeRoleMarkerSVG emits var(--mc-role-X) in default fill path`
- `makeMarkerIcon body references var(--mc-role-*)`
- `observer star overlay uses var(--mc-role-observer)`
- `addNodeMarker body references var(--mc-role-*)`
- `setRoleColorOverride body writes --mc-role-{role} CSS var`
Green commit: code fix → all 13 assertions pass.
## Verification
- `test-issue-1438-marker-css-vars.js` (new) — 13/13 pass
- `test-issue-1407-cb-preset-propagation.js` — 61/61 pass (no
regression)
- `test-issue-1412-customizer-no-override.js` — 13/13 pass
(clear-override-restores-preset contract preserved by
`_presetCssSnapshot`)
- `test-marker-outline-weight.js` — 6/6 pass
- Full `test-all.sh` — same pre-existing pass/fail count (no new
failures introduced)
Browser verified: CSS-var-on-SVG-fill repaint behavior confirmed live in
headless chromium (about:blank test svg, `setProperty('--test-color',
'#0000ff')` flips a mounted `<rect fill="var(--test-color)">` from red
to blue without re-mount). Staging hot-deploy + CDP verification will
happen post-merge (per fix-issue playbook).
## Preflight
`bash ~/.openclaw/skills/pr-preflight/scripts/run-all.sh origin/master`
— all gates clean.
---------
Co-authored-by: OpenClaw Bot <bot@openclaw>
# feat(#1420): dark-tile provider picker in customizer (4 variants)
Closes#1420.
## What
Operator pick: don't force a single dark-tile choice on everyone. Wire 4
candidates into the customizer + server config so users can choose which
dark basemap they want, with per-browser persistence.
## Providers shipped
| ID | Source | Filter |
|---|---|---|
| `carto-dark` (default) |
`https://{s}.basemaps.cartocdn.com/dark_all/{z}/{x}/{y}{r}.png` | none |
| `esri-darkgray-labels` | Esri Dark Gray Base + Reference (two stacked
layers) | none |
| `voyager-inverted` | Carto Voyager + CSS `invert(1) hue-rotate(180deg)
brightness(0.9) contrast(1.05)` on `.leaflet-tile-pane` | applied in
dark, cleared in light |
| `positron-inverted` | Carto Positron + same CSS invert | applied in
dark, cleared in light |
No new dependencies — all providers are URL-only.
## Architecture
- **`public/map-tile-providers.js`** — registry + 5 public helpers
(`MC_TILE_PROVIDERS`, `MC_setDarkTileProvider`,
`MC_getDarkTileProvider`, `MC_setServerDefaultTileProvider`,
`MC_applyTileFilter`). Persists to
`localStorage['mc-dark-tile-provider']`. Dispatches
`mc-tile-provider-changed` on user pick.
- **`public/map.js` / `public/live.js`** — resolve the active dark
provider via the registry, manage the Esri labels overlay lifecycle (add
when needed, remove cleanly so we don't leak layers on repeated theme
toggles), and apply/clear the CSS filter on `.leaflet-tile-pane`. Listen
for both `data-theme` mutations AND `mc-tile-provider-changed`.
- **`public/customize-v2.js`** — new "Dark Map Tiles" dropdown in the
Display tab. On change, calls `MC_setDarkTileProvider(id)`; the maps
re-render live without reload.
- **`public/roles.js`** — hydrates the server default via
`MC_setServerDefaultTileProvider` from `/api/config/client`.
- **Server (`cmd/server/`)** — new `mapDarkTileProvider` string on
`Config` + surfaced in `ClientConfigResponse`. Default empty → client
uses `carto-dark`.
- **`config.example.json`** — documents the new field with all allowed
values.
## Behavior guarantees (from the acceptance criteria)
- ✅ Light mode is **completely unchanged** — `_resolveTileUrl(false)`
short-circuits to `TILE_LIGHT` with no filter and no overlay logic.
- ✅ Switching dark→light always clears the CSS filter, even if an
inverted provider remains selected (`MC_applyTileFilter` is called on
every theme change and early-returns to `style.filter = ''` when not
dark).
- ✅ Switching light→dark with an inverted provider re-applies the
filter.
- ✅ Attribution is updated per provider (Esri credit for Esri, CartoDB
credit for the others); the Leaflet attribution control is refreshed.
- ✅ Esri uses two stacked layers (base + reference labels). The
reference layer is added/removed cleanly so repeat toggles do not leak.
- ✅ Customizer change → immediate re-render, no reload. Uses the same
"live setting + persist + dispatch event" pattern as cb-presets (#1361).
## TDD
- Red commit: `148b71c3` — `test(#1420): add failing tests for dark-tile
provider registry (red)` — 6/7 assertions fail (stub only returns
nulls).
- Green commit: `49ffb230` — `feat(#1420): dark-tile provider picker — 4
variants wired into customizer` — 7/7 pass.
## Tests
`test-issue-1420-tile-providers.js` (wired into `test-all.sh` and
`.github/workflows/deploy.yml` JS-unit step):
```
── #1420 Dark-tile provider registry ──
✅ MC_TILE_PROVIDERS has all 4 IDs with url + attribution
✅ Inverted providers have non-null invertFilter; non-inverted have null
✅ MC_setDarkTileProvider persists to localStorage and dispatches mc-tile-provider-changed
✅ MC_setDarkTileProvider rejects unknown IDs (no persistence, no dispatch)
✅ MC_getDarkTileProvider falls back to server default, then carto-dark
✅ Apply filter for inverted provider in dark mode; clear when switching to non-inverted
✅ Light mode always clears the CSS filter even if inverted provider is selected
7 passed, 0 failed
```
`cd cmd/server && go build ./... && go vet ./...` — clean.
## CDP verification
Not run in this PR — the sandbox does not have a Chrome CDP endpoint
reachable, and staging cannot exercise this code path until this branch
is deployed. The issue body's "CDP-verified candidate set" table covers
prior provider-URL validation; the new code path (registry lookup +
filter swap + Esri overlay lifecycle) is covered by the unit tests
above. **Recommend operator run a quick manual verification on staging
post-deploy:** dark mode → open customizer → cycle through all 4
providers, confirm tiles render and the CSS filter is applied for
`voyager-inverted` / `positron-inverted` (verify via
`getComputedStyle(document.querySelector('.leaflet-tile-pane')).filter`).
## Files touched
- `public/map-tile-providers.js` (new)
- `public/map.js`, `public/live.js`, `public/customize-v2.js`,
`public/roles.js`, `public/index.html`
- `cmd/server/config.go`, `cmd/server/routes.go`, `cmd/server/types.go`
- `config.example.json`
- `test-issue-1420-tile-providers.js` (new), `test-all.sh`,
`.github/workflows/deploy.yml`
- `.eslintrc.json` (register new `MC_*` globals)
---------
Co-authored-by: openclaw <bot@openclaw.local>
## Root cause
`repeaterEnrichTTL` was **15 seconds**, but the background recomputer
(`StartRepeaterEnrichmentRecomputer`) runs every **5 minutes**.
After each recomputer tick, the relay/usefulness caches were valid for
15 seconds. For the remaining 4m45s, every `/api/nodes` request hit a
stale TTL gate in `GetRepeaterRelayInfoMap` /
`GetRepeaterUsefulnessScoreMap` and fell through to
`computeRepeaterRelayInfoMap` **on the request goroutine**. On
production (16k+ transmissions, 240k hop records) that rebuild takes ~18
seconds, making `/api/nodes?limit=5000` freeze on virtually every page
load.
The pattern was:
```
recomputer runs at T=0 → cache valid
T=15s → TTL expires
T=15s … T=5min → every request rebuilds on-thread (18s each)
T=5min → recomputer runs again → 15s valid window
repeat
```
## Fix
One line in `repeater_enrich_bulk.go`:
```go
// Before
const repeaterEnrichTTL = 15 * time.Second
// After
const repeaterEnrichTTL = 10 * time.Minute
```
The TTL now exceeds the recomputer interval so the cache is always warm
between background ticks. The TTL remains as a safety net for cases
where the recomputer isn't running (tests, early startup edge cases) —
it just no longer expires between ticks.
## Production results (analyzer.on8ar.eu)
Tested with binary injection on the live server before opening this PR.
| Metric | Before | After |
|--------|--------|-------|
| TTFB (`/api/nodes?limit=5000`) | 18.6 s | 0.47–0.54 s |
| Total response time | 18.9 s | 1.55–1.73 s |
| Improvement | — | **34–39×** |
Confirmed still fast at t+60s (well past the old 15s window).
## Test results
```
TestHandleNodesPerfLargeFleet elapsed=1.9ms budget=2s PASS
TestHandleNodesLimit2000ColdMiss elapsed=5.3ms budget=2s PASS
```
Both existing perf regression tests pass unchanged — the TTL change
doesn't affect their behavior (they test the cold-prewarm path, not TTL
expiry).
## Why this wasn't caught by tests
`TestHandleNodesLimit2000ColdMiss` only tests the cold-startup path
(cache nil → on-thread build → cache hit). It doesn't test the
TTL-expiry path (cache exists but stale → on-thread rebuild). A test
covering the latter would need to fast-forward time past the TTL, which
the existing fixture doesn't do.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
# Route view v2 redesign
Fixes#1418, Fixes#1419, Fixes#1422
This is the route-view redesign that came out of a long iterative QA
cycle. The first commit (`a3c39636`) landed the v1 sidebar timeline +
multi-path baseline; this PR's second commit (`0e2e913f`) is the v2
polish covering packet context, multi-path picker, mobile bottom-sheet,
CB-preset live colors, and dozens of operator-driven UX fixes.
## The journey, in one line
> "The data is a sequence. Geography is annotation. The packet is the
cargo, the route is the road — show both."
## New surfaces
### 1. Packet context block (sidebar header)
Above the multi-path chip, a per-type fact list explaining **what** is
traveling. Operator was tired of "the route view shows the road but not
the cargo."
| Type | Chip | Facts |
|-------------|-----------------|---------------------------------------------------------|
| ADVERT | 📡 ADVERT | name · role · sig ✓ · self-reported GPS · pubkey
prefix |
| TXT_MSG | ✉ DM | src → dst · 🔒 encrypted |
| REQ/RESPONSE| 🔒/🔓 REQUEST/…| src → dst · 🔒 encrypted |
| GRP_TXT | # CHANNEL MSG | #channel · 🔓 decrypted · "…content preview…"
· sender |
| TRACE | ⌖ TRACE | Official: N hops · Observed: M |
| PATH | 🔀 PATH | src → dst (with "from payload" chip on SRC/DST rows) |
Sources merge `pkt.decoded_json` + `obs.decoded_json` (channel data
often lives at packet level) and fall back to byte-level `raw_hex`
parsing for encrypted DMs and unkeyed channel msgs.
### 2. Multi-path picker
The header lists every unique observer-path with `<count>/<total>` chip
+ hex hop string. Click a path → full-clear and redraw that path only
(Tufte v6's "replace + retain subpath weights"). "All" →
edge-deduplicated UNION view (each unique edge drawn once, stroke =
observer count, single accent color, no seq numbers because there's no
single ordering).
### 3. Deep-link URLs
`#/map?packet=<hash>&obs=<id>` — bookmarkable, shareable, the single
source of truth. sessionStorage flow removed. "Back to packet" preserves
the obs id.
### 4. Hop resolution
Priority: server `resolved_path` → shared `window.HopResolver` (same
resolver as packets page, observer-IATA-aware) → raw prefix. Eliminates
a whole class of "route view named hops differently than packet detail"
bugs.
### 5. Markers (v5/v6/v7)
- All markers same 22 px filled circle, seq number rendered **inside**
- SRC + DST get a 2 px hollow endpoint ring
- SRC = DST loop → **double concentric ring** (ring grammar extended, no
new glyph)
- Spider-fan within 14 px collisions (16 px arc, dashed hairline),
re-runs on `zoomend` only, debounced
### 6. CB preset live colors
- Each preset gets a `routeRamp` (5 stops): default/trit = viridis,
deut/prot = plasma, achromat = pure luminance
- `cb-presets.js` writes `--mc-rt-ramp-0..4` CSS vars; route reads them
via `getComputedStyle`
- `cb-preset-changed` + `theme-changed` listeners hot-recolor without
re-render
### 7. Desktop chrome
- **Resize handle** on right edge of sidebar (drag, persisted to
`localStorage["mc-rt-sidebar-width"]`)
- **Collapse button** = round chevron **centered on the right edge**
(Material/Drive style — not in the top-right corner, doesn't collide
with the close X)
- Collapsed = 36 px strip with rotated "ROUTE" label, expand on click
### 8. Mobile (bottom sheet)
- Anchored above bottom-nav (`bottom: 56px + safe-area-inset`)
- Collapsed = thin summary line `TYPE · N hops · X km · M obs` + hex
preview, tap chevron to expand to ~75 vh
- Drag-grip removed (conflicted with browser pull-to-refresh +
CoreScope's own pull-to-reconnect)
- Desktop collapse / resize affordances hidden on mobile (sheet is the
mobile collapse affordance)
- Map controls toggle floats top-right, panel collapses on route entry,
reachable via toggle click
- All three mobile detail panels (`pktRight`, `.slide-over-panel`,
`#mobileDetailSheet`) explicitly closed when entering route view
### 9. Map fit / centering
- Manual layer-children walk because `L.LayerGroup.getBounds()` doesn't
aggregate (only `FeatureGroup` does)
- Mobile padding: `paddingTopLeft: [30, 70]`, `paddingBottomRight: [30,
190]` to clear top-nav + sheet+nav stack
- Re-fits on: initial render, isolate, All, `window.resize` (iOS URL-bar
collapse)
- Staggered timers 0/200/600/1400 ms (and 2800 ms on initial render) to
survive layout settles
### 10. Hop drill-in refinements
- SNR sparkline suppresses connecting polyline when n < 3 (two points
implies a trend across time it can't represent — dots only)
- "Node details" link properly chip-styled with aria-label including
node name + route count
## Edge weight scales
| View | Range |
|---------------------------------|----------------|
| Single-path | 5 px flat |
| Multi-path interior | 3..9 |
| Origin→hop1 / last-hop→dest | proxy via max adjacent edge count |
| Union overlay | 2..8 |
Boundary edges (SRC→first hop, last hop→DST) used to render thin because
`edgeCounts` only tracks `path_json` transitions. Now they take the
strongest adjacent edge count as proxy (every observer who saw the
packet implicitly transited that boundary edge).
## Files
- **NEW** `public/route-tufte.js` (~1700 lines) — the route renderer +
sidebar
- **NEW** `public/route-tufte.css` (~750 lines) — all styling
- **MOD** `public/map.js` — async draw functions, deep-link loader,
`__mc_nodes` exposure, raw_hex extraction
- **MOD** `public/packets.js` — View Route → deep-link URL only, closes
all mobile panels
- **MOD** `public/cb-presets.js` — `routeRamp` per preset + CSS var
write
- **MOD** `public/index.html` — script + stylesheet tags
## Testing
Manually CDP-validated across desktop and mobile-emulator viewports for
every major change. Fixtures cover:
- ADVERT (4 hops, single-obs)
- DM (TXT_MSG, raw_hex parse)
- GRP_TXT (#test channel, decrypted text)
- PATH (operator's bug case)
- TRACE (3-hop)
- 1-hop edge case
- Multi-path (75-observer 4-hop with 47 unique paths)
- 32-hop stress
- Loop (SRC = DST)
- Bay Area dense cluster (spider-fan)
Per AGENTS.md net-new-UI exemption, no failing-test-first; existing
tests stay green. **TODO**: Playwright E2E follow-up PR.
## What's deferred to v2.1 / follow-ups
- **Glyph overlay on SRC marker** for packet type (e.g. 📡 corner glyph
on ADVERT marker, ⌖ on TRACE)
- **Per-hop SNR sparkline for TRACE packets** (their payload contains
real per-hop SNR contributions, distinct from observer-derived SNR)
- **GRP_TXT full content preview** (currently truncated at 80 chars;
could expand inline)
- **Playwright E2E test** covering the deep-link → isolate → All flow
## Screenshots
(would be useful here — CDP screenshots captured during dev show:
desktop with sidebar + multi-path picker, mobile with bottom sheet +
overlay toggle, isolated-path view, union view, spider-fan on Bay Area
cluster, packet context for each of the 5 main types)
## Operator's frustration patterns (lessons for next time)
1. **Browser-validate every UI change, not just compute state** —
CDP-screenshot before claiming a UI fix is done. Verifying
`display:none` resolves correctly is necessary but not sufficient; the
visual layout matters.
2. **Edge-deduplicated drawing beats per-path overlays** for union views
(Tufte v6) — operator's instinct was correct from the start.
3. **Material/Drive UI conventions exist** because they work — center
collapse handles on borders, don't pile them in corners.
4. **Mobile = different problem than desktop** — bottom-sheet, no
drag-grip near pull-to-refresh zone, asymmetric fitBounds padding,
redundant refits to survive iOS URL-bar collapse.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: openclaw-bot <bot@openclaw.local>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: corescope-bot <bot@corescope.local>
WIP — red commit only. Reproduces #1412.
## TDD red phase
`test-issue-1412-customizer-no-override.js` asserts that after
`MeshCorePresets.applyPreset('deut')` and a server-config push of legacy
`nodeColors`, `window.ROLE_COLORS.repeater === '#FE6100'`. On master
this
fails because `customize-v2.js:553` pushes server-config into the
`_roleOverrides` map, which the live getter prefers over CSS vars.
Green commit (customize-v2.js + customize.js fix) follows.
Refs #1412
---------
Co-authored-by: corescope-bot <bot@corescope.local>
## What
Fix the horizontal overlap between `.nav-more-btn` (in `.nav-left`) and
`.nav-stats` (in `.nav-right`) at viewport widths roughly 1101..1599px.
At vw=1200 the count number in the stats badge rendered on top of the
"More ▾" text.
## Root cause
`.top-nav` uses `display: flex; justify-content: space-between;` but had
**no column gap** between its children, and `.nav-links` had **no
flex-grow**. So `.nav-left` only consumed its content's intrinsic width
and `.nav-right` (with `flex-shrink: 0`) was free to abut it. Worse, the
Priority+ measurement loop in `app.js` (`applyNavPriority` → `fits()`)
compared intrinsic widths against `window.innerWidth` while `.top-nav {
overflow: hidden }` masked the actual collision — so the loop happily
declared "fits" while pixels overlapped.
CDP measurement on master at vw=1200 (`/#/packets`):
- `.nav-more-btn` rect: x=499..557 (w=58)
- `.nav-stats` rect: x=496..962 (w=466)
- Gap: **−60.7px** (overlapping)
Fix candidates tested via Chrome DevTools Protocol (`Runtime.evaluate` +
`Emulation.setDeviceMetricsOverride`) across vw=1101, 1200, 1366, 1440,
1600, 1920 (plus 768, 900, 1024, 1080, 1100, 1300, 1500, 1700, 1800 as a
sanity sweep). Winner:
```css
.top-nav { column-gap: 16px; }
.nav-links { flex: 1 1 auto; min-width: 0; }
```
Per-viewport gap (`stats.left - more.right`) baseline → fix:
| vw | baseline | fix |
|------|----------|----------|
| 1101 | −144.0 | **16.0** |
| 1200 | −60.7 | **16.0** |
| 1300 | 8.4 | **16.0** |
| 1366 | 64.2 | 64.2 |
| 1440 | 0.0 | **44.5** |
| 1600 | 24.2 | 24.2 |
| 1920 | more hidden (no overflow) — n/a | n/a |
Single-candidate variants (`.nav-left { flex: 1 1 auto }` alone,
`.top-nav { justify-content: space-between }` alone — already on, no
effect, `.nav-links { flex: 1 1 auto }` alone, margin/padding hacks on
`.nav-right`/`.nav-stats`) all still produced ≤8px gap at vw=1200. Only
the combo (column-gap on parent + flex-grow on `.nav-links`) cleanly
resolves all six required widths.
## TDD
Red commit: `3d374b4c93319805e89e46d8fdc8a8ea8c6c1479` (CI:
https://github.com/Kpa-clawbot/CoreScope/actions/runs/26482870401)
- `test-issue-1413-nav-overlap-e2e.js` — Playwright at vw 1101, 1200,
1366, 1440, 1600, 1920 on `/#/packets`. Asserts `.nav-more-btn.right + 8
<= .nav-stats.left` (when both visible) and that `.top-nav` does not
horizontally scroll. Wired into `.github/workflows/deploy.yml` alongside
the other `test-nav-*-e2e.js` entries.
- Red commit ships ONLY the test (+workflow line); CI fails on the
assertion at vw=1101..1300 and vw=1440 (gap below 8px threshold).
- Green commit applies the two CSS rules above and turns CI green.
## Manual verification
1. Open `http://analyzer-stg.00id.net/#/packets` in a desktop browser.
2. Resize the viewport to ~1200px wide.
3. Confirm the "More ▾" button and the stats badge are visibly separated
(≥16px gap) and the badge count is not stacked on the button text.
4. Repeat at 1101, 1300, 1440, 1600, 1920px — gap ≥16px at all widths
where stats is visible.
5. At ≤1100px confirm `.nav-stats` is still hidden (display:none,
unchanged).
## Scope guards
- No changes to the Priority+ algorithm (`applyNavPriority` / `fits()`
in `app.js`). #1391, #1311, #1139, #1148, #1102, #1055 logic untouched.
- No changes to the More dropdown (`position: fixed`, #1406).
- No changes to `.nav-left { overflow }` (#1405 stayed dropped).
- Mobile (<768px) hamburger layout unchanged.
Fixes#1413
---------
Co-authored-by: openclaw-bot <bot@openclaw.local>
## What
Delete the unconditional
`localStorage.setItem('channels-show-encrypted', 'true')` call (+
misleading "#1034 PR1: sectioned sidebar" comment) at
`public/channels.js:783-786`. The sectioned-sidebar grouping the comment
referenced was never implemented; in practice the call was
force-flipping the encrypted-visibility gate on every init so an
operator could never turn it off.
## Root cause
`channels.js` init ran:
```js
var showEncrypted = true;
try { localStorage.setItem('channels-show-encrypted', 'true'); } catch (e) {}
```
unconditionally on every load. The `loadChannels()` reader at line ~1563
(`localStorage.getItem('channels-show-encrypted') === 'true'`) then sent
`includeEncrypted=true` on the `/api/channels` call, so the server
returned all 246 encrypted placeholder channels alongside the 19 real
ones — 265 rows flooding the sidebar with no UI control to suppress.
Verified via CDP on staging:
- `localStorage['channels-show-encrypted']` was always `"true"` after
page load.
- `GET /api/channels` → **19** entries (default — encrypted excluded).
- `GET /api/channels?includeEncrypted=true` → **265** entries (246
encrypted).
- Manually `removeItem('channels-show-encrypted')` + reload → list
dropped to 19.
Confirmed the force-set was the only gate driving the flood.
## TDD
- RED commit `a71cecbc` — `test-issue-1409-no-encrypted-flood.js`
source-greps `public/channels.js` for the forbidden literal
`setItem('channels-show-encrypted', 'true')`. Asserts no match. Fails on
master.
- GREEN commit `14281b63` — delete the 2 lines + rewrite comment. Test
passes.
Tests:
```
$ node test-issue-1409-no-encrypted-flood.js
Issue #1409 — no force-enable of channels-show-encrypted
✅ channels.js does NOT unconditionally setItem(channels-show-encrypted, true)
✅ channels.js still reads channels-show-encrypted (toggle gate preserved)
2 passed, 0 failed
```
## Manual verification
- After fix, default `localStorage.getItem('channels-show-encrypted')`
is `null` on first load.
- `loadChannels()` reader returns `false`, so `includeEncrypted` is
omitted from the API call → server returns the 19 real channels only.
- Existing reader is preserved, so a future user-facing toggle that
writes the flag will continue to work.
## Out of scope (follow-ups)
- "Show encrypted" header toggle UI — issue acceptance criteria mentions
it as optional; not added here.
- Sectioned-sidebar grouping of encrypted channels (#1034 PR1 design) —
separate issue.
- Cap/collapse behavior when toggle is ON — separate issue.
Fixes#1409
---------
Co-authored-by: openclaw-bot <bot@openclaw.local>
Kpa-clawbot
