Hi diddly-ho Eli — dug into the pool timeline widget (ts/components/RevealTimeline.vue, used in the Reveal workbench detail panel) to map out what "barely workable" and "key takes up too much data" mean in the code, plus what it takes to make the timeline track manual condition sets.

Where the widget stands today

Timeline dots come from feature_pool_state via GET /api/feature/{id} → pool.state_history, loaded in Reveal.vue:loadFeatureHistory() when a pool is selected. Export markers come from pool.exports (currently always [] from real data).
The key/legend renders all 7 conditions + Export unconditionally, even when the pool's timeline only has 1–2 statuses — that's the "key takes up too much data" part. The fix (legend computed from pool.detections only, Export chip only when exports exist) is actually already written on the issue-176-n-items branch (N7, commit 3dbc4139) but that PR (#188) is stalled/not mergeable, so it never landed on main.
"Barely workable" issues I see in the current main version:
1. activeYear defaults to the current calendar year, not the latest year that has detections — a pool whose history is in 2024–2025 renders an empty track until you click a year tab.
2. "Load Imagery" is a stub — it just sets imageryLoaded = true and shows a banner; it doesn't load anything.
3. The legend shows every possible condition regardless of what's on the pool.

On the timeline updating when the condition is manually set
Today the manual condition set happens in the review interfaces (sudo/RevealReview.vue / review/VisionTaskReview.vue → putVisionTask → reviewed condition saved; on analysis commit, platform/vision_analysis_commit.go inserts a new feature_pool_state row — which is the timeline data). The gap: featureStore.fetchByID caches by ID and never invalidates, so the Reveal workbench timeline keeps showing the stale history until a full page reload. That's the concrete thing to fix for your requirement.

Proposed plan (small PR on main)

Dynamic legend — only statuses present on the pool's timeline; Export chip only when exports exist (port the N7 change from #188's branch).
Default the year tab to the most recent year with detections (fall back to current year when empty).
Make "Load Imagery" either actually load/zoom the satellite basemap for the selected detection date or drop the stub button.
Timeline freshness: add a force-refresh path to featureStore (or invalidate on select) so loadFeatureHistory refetches state_history after a manual condition set + commit, instead of serving the cached detail.

One question to scope #4 correctly: should the timeline also be embedded in the review UI (sudo RevealReview / VisionTaskReview) so the reviewer sees the pool's history while setting the condition and it updates live? Or is refreshing the workbench timeline after commit the intended behavior? I can wire either.

Hi diddly-ho Eli — dug into the pool timeline widget (`ts/components/RevealTimeline.vue`, used in the Reveal workbench detail panel) to map out what "barely workable" and "key takes up too much data" mean in the code, plus what it takes to make the timeline track manual condition sets. **Where the widget stands today** - Timeline dots come from `feature_pool_state` via `GET /api/feature/{id}` → `pool.state_history`, loaded in `Reveal.vue:loadFeatureHistory()` when a pool is selected. Export markers come from `pool.exports` (currently always `[]` from real data). - The key/legend renders **all 7 conditions + Export unconditionally**, even when the pool's timeline only has 1–2 statuses — that's the "key takes up too much data" part. The fix (legend computed from `pool.detections` only, Export chip only when exports exist) is actually already written on the `issue-176-n-items` branch (N7, commit 3dbc4139) but that PR (#188) is stalled/not mergeable, so it never landed on main. - "Barely workable" issues I see in the current main version: 1. `activeYear` defaults to the *current* calendar year, not the latest year that has detections — a pool whose history is in 2024–2025 renders an empty track until you click a year tab. 2. "Load Imagery" is a stub — it just sets `imageryLoaded = true` and shows a banner; it doesn't load anything. 3. The legend shows every possible condition regardless of what's on the pool. **On the timeline updating when the condition is manually set** Today the manual condition set happens in the review interfaces (`sudo/RevealReview.vue` / `review/VisionTaskReview.vue` → `putVisionTask` → reviewed condition saved; on analysis commit, `platform/vision_analysis_commit.go` inserts a new `feature_pool_state` row — which *is* the timeline data). The gap: `featureStore.fetchByID` caches by ID and never invalidates, so the Reveal workbench timeline keeps showing the stale history until a full page reload. That's the concrete thing to fix for your requirement. **Proposed plan (small PR on main)** 1. Dynamic legend — only statuses present on the pool's timeline; Export chip only when exports exist (port the N7 change from #188's branch). 2. Default the year tab to the most recent year with detections (fall back to current year when empty). 3. Make "Load Imagery" either actually load/zoom the satellite basemap for the selected detection date or drop the stub button. 4. Timeline freshness: add a force-refresh path to `featureStore` (or invalidate on select) so `loadFeatureHistory` refetches `state_history` after a manual condition set + commit, instead of serving the cached detail. One question to scope #4 correctly: should the timeline also be embedded in the *review* UI (sudo RevealReview / VisionTaskReview) so the reviewer sees the pool's history while setting the condition and it updates live? Or is refreshing the workbench timeline after commit the intended behavior? I can wire either.