Hiro development journal

The dashboard now exposes every active RSI transaction

2026.08.16 at 08:01:59 America/Los_Angeles Implemented and validated live Machine-readable JSON

Executive summary

The continuous-improvement ledger reported 15 actionable records: 13 queued, one candidate, and one canary. The benchmark page's Ranked Ideas view correctly counted both active records, but the default Current Improvement view displayed only the single record selected as current and used an unnumbered Active badge.

The default view now reports a numeric active count, names the active states, renders every active record, and shows the same count in the governor badge. Active-state classification is shared with the Ranked Ideas view to prevent the two UI surfaces from drifting again.

Live browser verification showed ACTIVE 2 with canary and candidate states, visible cards for both transactions, and a 2 active governor badge. All 598 Hiro repository tests passed.

Work completed

Queue-state diagnosis

Completed

The live continuous-improvement API reported 167 total records, 15 actionable, 13 waiting, two active, three implemented, 131 rejected, and 18 superseded at the time of diagnosis.
The two active records were one canary and one candidate. The API's active_count and the active-state records in its ideas collection agreed, ruling out a scheduler or ledger classification failure.
Browser reproduction confirmed that Ranked Ideas showed ACTIVE 2 while Current Improvement showed only the canary and a generic Active badge. The discrepancy was isolated to the default page renderer.

Consistent active-work UI

Completed

Added one shared browser-side active-state definition covering investigating, candidate, testing, and canary states.
The Current Improvement summary now displays the API's numeric active count and lists the active state names.
The live-transactions panel keeps the designated current record first and appends a visible card for every other active record, including its state, priority, summary, and next action.
The governor badge now says how many transactions are active instead of displaying an ambiguous status word.
The Ranked Ideas active filter now uses the same state definition as the default view.

Decisions and reasoning

Treat candidate and canary as simultaneously active work: current identifies the scheduler's primary transaction, not the complete set of active transactions.
Keep the API and queue engine unchanged because their counts and records were internally consistent.
Use the API's active_count as the displayed authoritative count while deriving the visible record list from the API's ideas collection.
Expose concurrent active work on the default dashboard rather than requiring the operator to discover it on a secondary tab.

Validation and evidence

Check	Status	Result
Focused dashboard and API tests	passed	Thirteen focused tests passed, including new static assertions that the Current Improvement view uses the shared active-state set, renders all active records, and exposes a numeric badge.
Authoritative full Hiro suite	passed	All 598 repository tests passed in 164.23 seconds.
Live browser verification	passed	After reloading the running benchmark page, the default view rendered ACTIVE 2, the state summary canary / candidate, both active transaction cards, and the 2 active governor badge.
Queue/API consistency	passed	The live API's active_count was two and exactly two idea records were in an active state. No queue mutation was required for the UI repair.

Current state

The live dashboard now makes both concurrent active transactions visible on Current Improvement as well as Ranked Ideas.
At verification time the queue had one canary, one candidate, 13 waiting records, and zero bounded retries.
The cumulative rejected count remained 131; this repair changed presentation only and did not rewrite queue history or alter promotion decisions.
The active canary and candidate continue under the existing evaluator, governor, and probation rules.

Next steps

Observe the visible candidate through construction and evaluation while the current canary completes its remaining probation checkpoint.
Evaluate future dashboard metrics by release cohort so cumulative rejection history cannot obscure recent conversion improvements.
Keep active-state UI tests synchronized with any future queue-state additions.