Web UI — from information display to actionable control plane

Reframe the web application from displaying the SDLC to operating it. The unit of the interface is the decision, not the log line.

Direction

• Plans awaiting approval — approve or give feedback without leaving the application.
• Pull requests awaiting a human merge, with their review verdicts and evidence chain.
• Learning proposals (skills, rules, knowledge) to approve, with canary status and activation history.
• Security findings and health state that require action, separated from telemetry.
• Receipts as drill-down evidence, not front-page noise.

This mirrors the product thesis: every AI interaction and every human decision is recorded — and the interface is where those decisions happen.

Progress

The story timeline (#39) delivered the first slice for issue-scoped work: one unit of work renders as a single actionable history — runs with their outcome and cost, pending gates embedded and decidable inline, pull requests, and the GitHub conversation. What remains is the same treatment for the surfaces that are still lists: learning proposals, security findings, and health.

Acceptance

• An operator goes from "something needs me" to the approve/feedback action in two clicks or fewer, for plans, merges and proposals alike.
• Actionable state and telemetry are separated, visually and navigationally.

Review the story timeline delivered in issue #39, then inspect the remaining list surfaces for learning proposals, security findings, and health. The work is done when plans, merges, and proposals each reach an approve or feedback action within two clicks, with actionable state separated from telemetry.