docs(feature-scout): add ranked feature-idea log (2026-06-28..29)

Local discovery notes from /feature-scout runs: per-run ranked candidates,
rationale, dedup decisions, and recorded no-file outcomes. Tracks which
enhancement issues (#285-#325) were filed and why, so successive runs move
down the list instead of re-proposing.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: HanSur94

docs/.feature-ideas/ideas-2026-06-28.md

@@ -0,0 +1,148 @@
+# Feature scout — ranked ideas (2026-06-28)
+
+Run context: 69 prior `auto-generated` enhancement issues already filed (#210–#283),
+heavily covering widget options, event queries, Tag stats/persistence, and engine
+time/page navigation. Backlog Phase 999.1 (unified in-app help/wiki system) is the only
+roadmap-pending feature and is treated as **roadmap-covered** for dedupe purposes.
+
+Discovery sources mined this run: TODO/FIXME (only vendored sqlite3 — none in app code),
+`.planning/ROADMAP.md` + `STATE.md` backlog, code asymmetries across Dashboard widgets,
+and the current-milestone headline features (tabs/groups, per-widget info, detached mirrors).
+
+---
+
+## #1 — FILED THIS RUN
+
+### BarChartWidget & HistogramWidget: fixed axis limits for a stable live frame
+- **Signal (asymmetry):** ScatterWidget has `XLimits`/`YLimits` (#263) and HeatmapWidget has
+  `ColorLimits` (#231) — both filed explicitly "for a stable live frame / live color scale."
+  BarChartWidget and HistogramWidget have no equivalent. Verified in `render()`: both call plain
+  `bar`/`barh` with no `ylim`/`xlim` clamp, so the value axis (and Histogram's bin/X range)
+  auto-rescales on every live `DataFcn` refresh → bars and axes visibly jump.
+- **Value:** Operators watching a live dashboard get a stable visual frame; bar heights stay
+  comparable refresh-to-refresh instead of re-normalizing each tick. Direct sibling of two
+  already-accepted issues.
+- **Fit:** toolbox-free; pure MATLAB; backward-compatible (default `[]` = current auto behavior;
+  `toStruct` omits when empty, exactly like the existing `NumBins`/`EdgeColor` pattern, so legacy
+  serialized dashboards stay byte-identical); works through the `DashboardWidget` contract.
+- **Effort:** S — add property + one `ylim`/`xlim` clamp after the `bar()` call in each widget's
+  `render()`, plus `toStruct`/`fromStruct` lines.
+- **Confidence:** High — established sibling pattern, no dedupe hit.
+
+---
+
+## #2 — next candidate
+
+### ScatterWidget: XLabel / YLabel axis labels
+- **Signal (asymmetry):** #253 added `XLabel`/`YLabel` to BarChart & Histogram but **not** Scatter,
+  which is the most axis-label-natural widget (explicit X-vs-Y sensor pairing).
+- **Value:** Medium — clearer scatter axes; today they rely on auto/sensor-derived labels only.
+- **Fit:** Clean additive, toolbox-free, backward-compatible.
+- **Effort:** S. **Confidence:** Medium-high.
+
+## #3
+
+### DashboardEngine.setTheme(preset): runtime theme switch with live restyle
+- **Signal (asymmetry):** `Theme` is a construction-time preset string (`'light'`/`'dark'`) with a
+  `ThemeCache_`; `applyThemeToChrome` exists but there is no single public call that swaps the
+  preset AND re-themes all already-rendered widgets at runtime.
+- **Value:** Medium — runtime light↔dark toggle for demos/presentations without rebuilding.
+- **Fit:** Additive, toolbox-free. **Effort:** M (must fan out restyle across widgets + chrome).
+- **Confidence:** Medium.
+
+## Run 2 (later 2026-06-28) — updates
+
+- **#285 filed** (run 1) — now known ground.
+- **#286** appeared from a parallel loop run — `IconCardWidget: trend-direction arrow (ShowTrend)`. Noted.
+- **#2 (Scatter XLabel/YLabel) — DROPPED.** Verified `ScatterWidget.render` already auto-labels both
+  axes from the bound sensors via `axisLabelForSensor_` (lines 100–105). An explicit override would be
+  marginal, not a real gap. Removed from the active list.
+- **FILED THIS RUN: #3 promoted →** `DashboardEngine.setTheme(preset)` runtime theme switch (see below).
+
+### FILED RUN 2 — DashboardEngine.setTheme(preset): runtime theme switch with live restyle
+- **Signal (code asymmetry):** `Theme` is a public property (`'light'`/`'dark'`, default `'light'`), and the
+  machinery exists — `getCachedTheme()` rebuilds `ThemeCache_` when the preset string changes,
+  `applyThemeToChrome()` restyles the figure/chrome, `rerenderWidgets()` re-renders widgets with the new
+  theme. But there is **no single public call** that ties them together: `applyThemeToChrome`'s own doc
+  says "Widget panels are NOT touched here — call rerenderWidgets() after." So switching theme after
+  render today requires manually chaining `d.Theme=…; d.applyThemeToChrome(); d.rerenderWidgets();`
+  (and detached mirrors aren't re-themed at all).
+- **Value:** Medium — one-call runtime light↔dark for demos/screenshots and control-room night mode,
+  without rebuilding the dashboard. No dedupe hit.
+- **Fit:** Additive, toolbox-free, backward-compatible (no serialization change).
+- **Effort:** S–M (`DashboardEngine.m`; validate preset, set `Theme`, restyle chrome + rerender + re-theme
+  any `DetachedMirrors`; guard live mode). **Confidence:** High.
+
+## Run 3 (later 2026-06-28) — updates
+
+- **#287 filed** (run 2) — now known ground.
+- **#288** appeared from a parallel loop run — `Tag: exportCsv(path)`. Export vein now taken
+  (joins #210 dashboard export, #220 event CSV, #272 PlantLogStore CSV). Noted.
+- **FILED THIS RUN:** `DashboardEngine.refresh()` — public one-shot data refresh (see below).
+
+### FILED RUN 3 — DashboardEngine.refresh(): public one-shot data refresh (no live timer)
+- **Signal (code asymmetry):** the per-widget data-refresh loop (mark dirty → `w.update()` for
+  FastSenseWidget / `w.refresh()` otherwise, with realized/visible guards + detached-mirror tick) lives
+  entirely **inside the private `onLiveTick`**, driven by the live timer. The public surface offers only
+  `markAllDirty()` (flags dirty, no redraw), `rerenderWidgets()` (full tear-down + rebuild — loses zoom/
+  state, heavy), and `startLive`/`stopLive` (continuous polling). There is **no lightweight public call
+  to pull latest data into all widgets and redraw exactly once.**
+- **Value:** Scripts that load/append data (re-run a batch analysis, append to a Tag/DataStore, swap the
+  backing `.mat`) and want to update the dashboard **on demand once** must today either run continuous
+  live mode (timer churn) or `rerenderWidgets()` (rebuild). A `d.refresh()` does one live-tick's worth of
+  data update without the timer or the rebuild. No dedupe hit (distinct from #248 `setLiveInterval`).
+- **Fit:** toolbox-free; additive; backward-compatible (no serialization change); works through the
+  existing `DashboardWidget.refresh()` / `FastSenseWidget.update()` contract.
+- **Effort:** S–M — extract the existing `onLiveTick` dirty→refresh loop into a private helper
+  (`refreshWidgets_`) and expose a public `refresh()` wrapper (active page + detached mirrors; no-op
+  before render). Mostly a refactor of code that already exists. **Confidence:** High.
+
+## Run 4 (later 2026-06-28) — updates
+
+- **#289 filed** (run 3) — now known ground.
+- **#290** appeared from a parallel loop run — `FastSenseWidget: forward DownsampleMethod/DownsampleFactor`
+  (joins the FastSenseWidget-forwarding vein: #216, #227, #237, #290). Noted.
+- **Checked & cleared:** `TagRegistry` is NOT an add-only collection — it already has `unregister`,
+  `clear`, `find`, `findByLabel`, `findByKind`, `list`, `printTable`, `viewer`. No gap there.
+- **FILED THIS RUN:** `TagRegistry.toStructs()` — catalog export, inverse of `loadFromStructs` (see below).
+
+### FILED RUN 4 — TagRegistry.toStructs(): serialize the whole catalog (parity with loadFromStructs)
+- **Signal (round-trip asymmetry):** `TagRegistry.loadFromStructs(structs)` does a full two-phase
+  **import** of an entire catalog (kind-dispatch via `instantiateByKind`, duplicate detection, cross-ref
+  resolution). Every Tag already implements `toStruct` and it emits the `kind`/`key` fields that
+  `loadFromStructs` consumes (verified in `SensorTag.toStruct`). But there is **no registry-level
+  `toStructs()` / export** — the outbound half of the round-trip is missing. To persist a catalog today
+  you must manually `find(@(t)true)` and call `toStruct` on each tag yourself.
+- **Value:** Catalog persistence — the registry is an in-memory singleton with no built-in way to save
+  the catalog *definitions* and reload them across sessions. A `structs = TagRegistry.toStructs()` (the
+  exact inverse of `loadFromStructs`), optionally wrapped by `saveToFile(path)` / `loadFromFile(path)`
+  (JSON via `jsonencode`), lets engineers maintain a standard tag set on disk. Distinct from #288
+  (per-tag resolved *data* CSV — values, not definitions).
+- **Fit:** toolbox-free; additive; backward-compatible; pure MATLAB/Octave. Each Tag's `toStruct`
+  already produces `loadFromStructs`-ready output, so `toStructs` = iterate `catalog()` and collect.
+- **Effort:** S (`TagRegistry.m`; one static `toStructs()` + thin optional file wrappers).
+  **Confidence:** High.
+
+### Recorded (NOT filed) — widget click / drill-down callback
+- **Signal (domain gap / asymmetry):** No dashboard widget exposes a user click/selection callback
+  (`grep` for `ButtonDownFcn`/`OnClick`/`Callback` across `libs/Dashboard/*Widget.m` finds only
+  `GroupWidget.ReflowCallback`, injected internally). A sensor engineer can't click a bar/point/cell to
+  drill into detail.
+- **Value:** High (interactive drill-down is a real analysis workflow).
+- **Why not filed:** **Needs an architecture decision** — a base-class hit-testing/callback mechanism plus
+  per-widget wiring. L effort, design-heavy, no concrete prior signal. Better as a planned phase than a
+  crisp single auto-issue. Parked for human triage.
+
+---
+
+## #4 — NOT FILED (roadmap-covered)
+
+### Per-widget Markdown info (render `Description` via MarkdownRenderer)
+- **Signal (asymmetry):** `DashboardEngine.showInfo` renders its `InfoFile` as rich Markdown via
+  `MarkdownRenderer`; the per-widget info popup (`DashboardLayout.openInfoPopup`) shows
+  `widget.Description` as plain text in a read-only `uicontrol` edit box. The headline
+  "per-widget info tooltips" feature is therefore plain-text-only.
+- **Value:** High. **Fit:** Perfect (reuses existing `MarkdownRenderer`). **Effort:** S.
+- **Why not filed:** Backlog **Phase 999.1** (unified in-app help/wiki system) explicitly scopes
+  "every pane/widget … render markdown … reusing `MarkdownRenderer`." Treated as roadmap-covered
+  per the dedupe guardrail. Revisit only if 999.1 is descoped/declined.