# Feature Spec: Feature Focus View UX Redesign — Track C: Decision-Centric Remediation

> Purpose: Rework `/feature/{feature_id}` so it behaves like an operator decision surface instead of a collection of loosely-related widgets. This track fixes the information architecture, signal quality, inspectability, and data-contract gaps left after Tracks A and B.

**Version:** 0.1
**Date:** 2026-03-16
**Status:** Complete
**Roadmap Mapping:** M46-C (Focus View Decision-Centric Remediation)
**Depends On:** M46-A (Track A), M46-B (Track B)
**Related Specs:**

- `spec-files/outstanding/agentic_orchestrator_feature_focus_view_track_a_spec.md`
- `spec-files/outstanding/agentic_orchestrator_feature_focus_view_track_b_spec.md`

---

## 0. Executive Summary

The current focus page is no longer missing only widgets. Its deeper problem is that it does not help a human make a decision.

The page currently exhibits four systemic failures:

1. **Signal without consequence**: panels render data, but they rarely tell the operator what matters now, what changed, what is blocking progress, or what to do next.
2. **Capabilities hidden in the wrong place**: meaningful inspection tools exist inside `ReviewTab`, while the `Runtime`, `History`, `Plan`, and `Changes` tabs are reduced to shallow summaries.
3. **Derived analytics are low-trust**: several panels are driven by heuristics or stale snapshots rather than evidence-backed, time-scoped, user-comprehensible state.
4. **Page composition is widget-first instead of job-first**: the page is organized by implementation components, not by operator/reviewer jobs.

Track C reorients the page around three user questions:

1. **Can I trust this feature right now?**
2. **What exactly is happening, what is blocked, and what remains?**
3. **If I need to investigate, can I get from summary to artifact in one click?**

This track is intentionally not “add more cards.” It is a structural remediation of layout, meaning, drill-down, and data contracts.

---

## 1. Primary Criticisms Of The Current Design

This section is normative. These are the problems the implementation must solve.

### 1.1 Information hierarchy is weak

The top of the page tells the user the feature ID and phase, but it does not answer:

- Is the feature healthy enough to merge?
- What is the highest-priority blocker?
- What changed most recently?
- Which agent is active?
- How much plan remains?
- What action should the human take next?

The result is that users scan multiple cards before understanding basic state.

### 1.2 Overview cards are low-signal summaries

Several Overview sections currently exist primarily because data was available, not because the section is decision-useful:

- `VerificationSignals` falls back to phase/gate heuristics and often does not reflect fresh artifact evidence.
- `PlanRevisionTimeline` shows metadata (`plan_version`, `revision_of`, `revision_reason`) but not what materially changed.
- `PlanRiskAnnotations` lists raw strings without urgency, owner, mitigation, or freshness.
- `QaCoverageMap` surfaces file rows and test counts but not unmet obligations, failing paths, or merge risk.
- `GenealogyTree` is a node list with little explanatory value.

### 1.3 The sidebar is overloaded but still incomplete

The sidebar stacks many independent sections with equal visual weight. This creates scan fatigue and causes truncation/overflow problems on small and medium widths.

Specific problems:

- long values and table-like text run through their containers
- usage and queue cards are detached from the main “what should I care about?” narrative
- pinned actions are present, but the page does not clearly explain why that action is needed now

### 1.4 The tab model is semantically wrong

Important capabilities are mounted in the wrong tabs:

- live runtime/event inspection and raw logs live in `ReviewTab`
- `RuntimeTab` is mostly a summary shell
- `HistoryTab` is a static list rather than an archive browser
- `PlanTab` shows the accepted plan but not actual plan progress or remaining work
- `ChangesTab` shows a static diff and a dead checkpoint list instead of an investigative diff workflow

The result is that the tabs do not match user expectations.

### 1.5 The page does not expose core source artifacts

The user cannot inspect the source spec from the page, and cannot reliably tell:

- where the current work sits in the plan
- how much plan is complete
- which tasks are blocked or pending
- what the agent most recently completed
- how the accepted plan maps to the current implementation state

This is a major product gap because the focus page is supposed to be the operational truth surface for a feature.

### 1.6 Time-based and history-based views are shallow

The current checkpoint and history surfaces do not support investigation well:

- checkpoint timeline is not paginated
- checkpoints are not first-class navigable entities
- there is no checkpoint compare workflow
- runtime logs are not inspectable in the Runtime tab
- raw logs are not inspectable in the History tab
- evidence is listed but not organized by run, gate, or relevance

### 1.7 Current tests validate presence, not usefulness

The focus-view tests are currently dominated by static-markup smoke assertions. They do not protect:

- decision-state derivation
- freshness/last-updated semantics
- overflow/truncation regressions
- tab ownership of capabilities
- artifact-backed signal computation
- drill-down navigation
- pagination/selection state

This has allowed low-signal panels to “pass” by existing at all.

---

## 2. Product Goals

### 2.1 Operator goals

The operator must be able to answer within 5 seconds:

1. What state is this feature in?
2. Is it progressing, stalled, blocked, or waiting?
3. What is the highest-priority issue?
4. What should I do next, if anything?

### 2.2 Reviewer goals

The reviewer must be able to answer within 30 seconds:

1. Is this safe to approve or merge?
2. Which signals are green, yellow, or red?
3. What changed materially since the previous revision?
4. Which failing tests or review concerns still matter?

### 2.3 Investigator goals

The investigator must be able to:

1. inspect a file diff in context
2. inspect runtime events and raw logs by role
3. inspect checkpoint evolution over time
4. inspect evidence artifacts by run and gate
5. inspect the accepted plan and the source spec side-by-side

### 2.4 Design principles

1. **Decision-first:** every major section must answer “why should I care?”
2. **Summary-to-artifact:** every summary panel must link to a deeper artifact or detailed view.
3. **Evidence-backed:** status panels may not infer success from phase alone when evidence exists.
4. **Progress-aware:** plan and execution progress must be explicit, not implied.
5. **Inspectability over ornament:** collapsibility, pagination, filters, and timestamps matter more than decorative cards.
6. **Low-noise defaults:** show the most consequential information first; collapse secondary detail.

---

## 3. New Page Model

Track C keeps the two-pane layout from Track A but changes the semantic roles of each zone.

### 3.1 Layout contract

#### Left rail: `Operational Sidebar`

The left rail becomes a compact decision rail with exactly four responsibilities:

1. **Identity + live state**
2. **Primary blocker / next action**
3. **Progress snapshot**
4. **Pinned actions**

The sidebar must not become a dumping ground for secondary analytics.

#### Right content area: `Decision Workspace`

The right side hosts tabs whose responsibilities become strict:

| Tab          | Responsibility                                       |
| ------------ | ---------------------------------------------------- |
| `Overview`   | Decision summary and top risks                       |
| `Plan`       | Spec, accepted plan, actual progress, remaining work |
| `Changes`    | Diff investigation and checkpoint navigation         |
| `Gates & QA` | Merge readiness, failing obligations, evidence       |
| `Review`     | Review decision workflow only                        |
| `Runtime`    | Live execution inspection                            |
| `History`    | Archived runs, evidence, and logs                    |
| `Transcript` | Human-readable agent conversation                    |

### 3.2 Required design rule

If a capability is not aligned with the responsibility of its tab, it must be moved.

Examples:

- raw logs do not belong only in `Review`
- checkpoint history does not belong only in `Review`
- plan progress does not belong only in Overview metadata
- source spec must be available from `Plan`

---

## 4. Data Contract Additions

The current `FeatureDetail` shape is insufficient for a decision-driven page. The following additions are required.

### 4.1 `FeatureDetail` additions

```ts
interface FeatureDetail {
  spec?: {
    title?: string | null;
    path?: string | null;
    markdown?: string | null;
    last_updated?: string | null;
  } | null;
  plan_progress?: {
    total_tasks: number;
    completed_tasks: number;
    in_progress_tasks: number;
    pending_tasks: number;
    blocked_tasks: number;
    percent_complete: number;
    current_task?: {
      id?: string | null;
      title: string;
      status: 'pending' | 'in_progress' | 'blocked' | 'completed';
      owner_role?: 'planner' | 'builder' | 'qa' | 'orchestrator' | null;
      started_at?: string | null;
      last_updated?: string | null;
    } | null;
    next_tasks: Array<{
      id?: string | null;
      title: string;
      status: 'pending' | 'blocked';
      blocked_by?: string[];
    }>;
    completed_recently: Array<{
      id?: string | null;
      title: string;
      completed_at?: string | null;
    }>;
  } | null;
  verification_summary?: {
    last_evaluated_at: string | null;
    readiness: 'ready' | 'at_risk' | 'blocked' | 'unknown';
    blockers: Array<{
      id: string;
      label: string;
      severity: 'high' | 'medium' | 'low';
      source: 'gate' | 'qa' | 'review' | 'dependency' | 'runtime' | 'plan' | 'budget' | 'collision';
      detail: string;
      artifact_ref?: string | null;
    }>;
    verified_requirements: number;
    at_risk_requirements: number;
    unverified_requirements: number;
  } | null;
  revision_summary?: Array<{
    id: string;
    timestamp: string | null;
    type: 'plan_update' | 'checkpoint' | 'review_event' | 'gate_run' | 'merge_event';
    headline: string;
    detail: string;
    file_count?: number | null;
    artifacts?: string[];
  }>;
}
```

### 4.2 Existing fields that must become trustworthy

The following existing fields may remain, but their derivation must be improved:

- `usage_burn`
- `collision_radar`
- `gate_history`
- `genealogy`
- `qa_test_index`
- `log_entries`
- `checkpoints`

### 4.3 Required new lazy endpoints

Heavy artifacts must be lazily loaded rather than stuffed into the initial page payload.

#### `GET /api/features/[id]/spec`

Returns:

```ts
{
  ok: true;
  data: {
    title?: string | null;
    path?: string | null;
    markdown: string;
    updated_at?: string | null;
  };
}
```

#### `GET /api/features/[id]/plan-progress`

Returns the `plan_progress` structure above, derived from accepted plan + worker/runtime evidence.

#### `GET /api/features/[id]/checkpoints`

Query params:

- `cursor`
- `limit`
- `direction=older|newer`

This endpoint returns paginated checkpoint metadata plus `diff_snapshot` only for the selected page.

#### `GET /api/features/[id]/checkpoint-diff`

Query params:

- `checkpoint_id`
- `file`

Returns filtered or full diff content for the selected checkpoint.

#### `GET /api/features/[id]/history/runs`

Returns archived run groups with timestamps, statuses, evidence counts, and log availability.

#### `GET /api/features/[id]/history/run/[runId]`

Returns evidence, timeline, and log metadata scoped to a single historical run.

### 4.4 Freshness contract

Any derived section that claims “current” or “latest” state must expose:

- `last_updated_at`
- source of derivation
- empty/loading/error states

This is required for:

- Verification signals
- Usage burn
- Plan progress
- Runtime summaries
- QA coverage

---

## 5. Sidebar Redesign

## 5.1 Replace stacked generic cards with a single `OperationalSummaryCard`

`HeroBlock`, `DiagnosisPanel`, pipeline summary, and fragmented usage/action context must be consolidated into a tighter summary block.

The top rail must show:

- feature id
- phase
- activity state
- active role
- time in phase
- last meaningful change time
- one-line primary diagnosis
- one-line next recommended action

### 5.2 Add `Progress Snapshot`

The sidebar must show a small progress module:

- `N / total tasks complete`
- current task
- next task
- budget state
- merge readiness state

This is the only progress summary that should remain always visible.

### 5.3 Keep usage and merge queue compact

`UsageBurnChart` and `MergeQueueCard` remain in the sidebar, but as compact summaries by default.

Rules:

- they must show `last updated` timestamp
- they must not render large explanatory text by default
- a click should open the corresponding deep view in the main content area

### 5.4 Overflow and wrapping requirements

All sidebar labels and values must satisfy:

- long feature IDs wrap or clamp instead of overflowing
- code-like strings use `overflow-wrap: anywhere`
- grid children use `min-width: 0`
- tables/lists do not exceed the card width

This specifically addresses the current “text runs through the box” failure mode.

---

## 6. Overview Tab Redesign

The Overview tab must become a merge/readiness briefing, not a card cemetery.

### 6.1 New section order

1. `Decision Banner`
2. `Top Blockers`
3. `Verification Summary`
4. `Recent Material Changes`
5. `Risk & Collision`
6. `Coverage & Confidence`
7. `Secondary diagnostics`

### 6.2 `Decision Banner`

New component: `FeatureDecisionBanner`

It must answer in one row:

- `Ready to merge` / `Not ready` / `Blocked`
- primary reason
- recommended action
- last evaluated time

Example:

`NOT READY · 2 open review threads and 1 failed gate step · resolve review, rerun merge gate · evaluated 14:22`

### 6.3 `Verification Summary` replaces naive `VerificationSignals`

Current weakness:

- items are driven by `plan.acceptance_criteria` parsing plus phase fallback

Required replacement behavior:

- verification items must be sourced from explicit evidence when available
- each item must show:
  - status
  - why
  - last evidence timestamp
  - artifact link

If evidence is absent, the UI must say `No evidence recorded` rather than implying a pass/fail from phase alone.

### 6.4 `Recent Material Changes` replaces current `PlanRevisionTimeline`

Current weakness:

- version metadata exists, but users cannot tell what changed

Required behavior:

- display last 5 meaningful revision events
- each row must include:
  - timestamp
  - event type
  - human summary
  - files changed or tasks affected
  - jump target (`Plan`, `Changes`, `Gates`, or `History`)

Examples of valid event summaries:

- `Plan v4 added 2 QA remediation tasks after failed merge gate`
- `Checkpoint cp-012 introduced edits to 3 auth files`
- `Review request changes reopened feature with 4 unresolved threads`

`FeatureGenealogy` may remain as a deeper provenance model, but Overview must show a human summary layer, not raw nodes.

### 6.5 `Plan Risks` becomes `Actionable Risks`

Current weakness:

- severity strings are shown, but no owner, freshness, mitigation, or impact

Required behavior:

Each risk row must show:

- severity
- risk statement
- why it matters for merge/release
- suggested mitigation
- owner role if known
- freshness indicator

If the risk data source only provides strings, Track C must derive a simpler but explicit structure and label it as derived.

### 6.6 `CollisionRadar` must be collapsible and consequence-oriented

Current weakness:

- always open when present
- no explanation of practical consequence

Required behavior:

- render as collapsed `<details>` by default
- summary row must show counts by risk level and highest-impact path
- expanded view shows files plus competing feature links
- each row must include a consequence label:
  - `merge conflict likely`
  - `same area, low direct conflict`
  - `watch list`

### 6.7 `QA Coverage Map` becomes `Coverage & Confidence`

Current weakness:

- file rows + required test counts do not help a reviewer decide anything

Required behavior:

The primary surface must summarize:

- obligations with passing evidence
- obligations with missing evidence
- files with failing tests
- files with no mapped tests
- flaky overlap count

The detailed table may still exist, but it must be subordinate to the summary.

Required row columns:

- file or obligation
- status
- failing/passing tests
- last run
- evidence link

### 6.8 Secondary analytics stay collapsed

`AgentRolePerformanceCard` and deep lineage views may remain in Overview, but must be collapsed under a `Diagnostics` or `Agent Performance` section so they do not compete with readiness signals.

---

## 7. Plan Tab Redesign

The Plan tab currently shows accepted plan metadata only. This is insufficient.

### 7.1 Required layout

Two-column layout on desktop:

- left: `Source Spec`
- right: `Accepted Plan + Progress`

Single-column stack on mobile/tablet.

### 7.2 `Source Spec` panel

New component: `SpecViewer`

Features:

- render `spec.md` markdown
- sticky mini table of contents
- anchor navigation
- copy path / open raw
- if unavailable, show explicit empty state

### 7.3 `Plan Progress` panel

New component: `PlanProgressPanel`

Must show:

- percent complete
- completed / total tasks
- current task
- pending tasks
- blocked tasks
- recently completed tasks

### 7.4 `Accepted Plan` panel

`PlanViewer` must be upgraded to:

- show task status badges
- group tasks by role or phase if possible
- show file scope
- show gate profile
- support expansion/collapse per task

### 7.5 Required progress derivation rules

Progress cannot depend only on plan task status fields if they are not actively maintained.

Track C must derive a `display progress` model using:

- explicit task status when present
- worker events indicating plan submission / patching / QA completion
- checkpoint timestamps
- gate outcomes
- review state

If the derivation is partial, it must be labeled `estimated`.

### 7.6 Decision-support requirement

The top of the Plan tab must explicitly answer:

- what is being worked on now
- what remains
- whether remaining work is blocked

---

## 8. Changes Tab Redesign

The Changes tab must become an investigative diff workspace.

### 8.1 Required sections

1. `Current Diff Overview`
2. `File Explorer`
3. `Checkpoint Rail`
4. `Checkpoint Inspector`
5. `Compare Mode`

### 8.2 `Current Diff Overview`

Keep the existing diff, but add:

- file count
- additions/deletions
- filter by file
- “open in inspector” action

### 8.3 `Checkpoint Rail`

The checkpoint timeline must be paginated and selectable.

Rules:

- default page size: 20 checkpoints
- newest first
- controls: `Newest`, `Older`, `Newer`
- selected checkpoint is visually active
- selection updates the checkpoint inspector instantly

### 8.4 `Checkpoint Inspector`

When a checkpoint is selected, the user must be able to:

- see metadata
- inspect the full diff
- filter to a file
- inspect validation violations
- open side-by-side inspector

### 8.5 `Compare Mode`

New workflow:

- select baseline checkpoint
- select comparison checkpoint
- render checkpoint-to-checkpoint diff summary

If full pairwise diff is too expensive for initial rollout, Track C may start with:

- compare metadata
- compare touched file lists
- compare violation sets

But the spec target is pairwise diff investigation.

### 8.6 Reuse existing review inspector

The existing file inspector and diff-investigation code from `ReviewTab` must be moved into reusable components and owned by `ChangesTab`, not trapped inside review-specific layout.

---

## 9. Gates & QA Tab Redesign

### 9.1 Required top summary

The top of the tab must answer:

- has the merge gate passed
- which gate step failed last
- how many retries have occurred
- which files/requirements still lack evidence

### 9.2 `GateFlakinessSummary`

It may remain, but it must:

- be collapsed by default unless retries exist
- show last failure timestamp
- distinguish flaky from consistently failing
- link to the corresponding evidence or run

### 9.3 Replace weak QA coverage framing

The QA surface must prioritize:

- failing files
- uncovered obligations
- flaky tests affecting required scope
- explicit evidence viewer links

### 9.4 Add `EvidenceViewer`

`EvidenceViewer` must be mounted here and organized by:

- gate run
- artifact type
- timestamp

The user must not need to leave the QA tab to inspect relevant artifacts.

---

## 10. Runtime Tab Redesign

The Runtime tab must own runtime inspection.

### 10.1 Required sections

1. `Runtime Summary`
2. `Agent Sessions`
3. `Runtime Inspector`
4. `Live Event Timeline`
5. `Directed Agent Console`
6. `Live / Raw Role Logs`
7. `Checkpoint Scrubber`

### 10.2 Mount the existing `RuntimeInspectorPanel`

The existing `packages/web-dashboard/src/components/features/runtime-inspector/RuntimeInspectorPanel.tsx`
contains richer runtime inspection than the current focus tab exposes. Track C must reuse or adapt this instead of maintaining two different runtime-inspector systems.

### 10.3 Move raw log access here

Role-scoped raw logs must be inspectable directly in Runtime.

Features:

- filter by role
- file selector
- content viewer
- download action

### 10.4 Improve runtime summary

Current session rows are insufficient. Add:

- active role
- last event time
- event rate / heartbeat freshness
- provider + model per active role
- blocked/waiting reason if any

### 10.5 Keep `CheckpointScrubber`, but deepen it

Track B introduced a scrubber, but it is not enough on its own.

Add:

- click from checkpoint scrubber into selected checkpoint inspector
- file filter persistence
- page position memory
- timestamp labels with human format

---

## 11. History Tab Redesign

The History tab must be an archive browser, not two static lists.

### 11.1 Required sections

1. `Run History`
2. `Evidence Archive`
3. `Historical Raw Logs`
4. `Checkpoint Archive`
5. `Past Review / Merge Events`

### 11.2 `Run History`

New component: `RunHistoryBrowser`

Each run row must show:

- run id
- start/end time
- final status
- evidence count
- log availability

Selecting a run scopes the rest of the tab.

### 11.3 `Evidence Archive`

Use `EvidenceViewer`, but grouped by run and gate.

### 11.4 `Historical Raw Logs`

The current History tab must provide the log-inspection capability the user expects from a historical surface.

### 11.5 `Past Review / Merge Events`

Add a compact event feed for:

- approve / deny / request changes
- merge-ready transitions
- merge execution
- reopened reviews

---

## 12. Transcript Tab Redesign

Track B improved transcript presentation. Track C makes it investigation-grade.

### 12.1 Required additions

- jump from transcript turn to related checkpoint if timestamps overlap
- jump from transcript turn to raw log file
- show role, actor, and exact timestamp more clearly
- search within transcript
- filter by role and by time window

### 12.2 Preserve live follow behavior

Transcript must maintain explicit `Follow live` state with visible status when a stream is disconnected or paused.

---

## 13. Review Tab Redesign

The Review tab must shrink in scope.

### 13.1 Review owns only review

The Review tab must contain:

- review brief
- review decision form
- approval token
- merge strategy
- review decision history

### 13.2 Remove non-review inspection from Review tab

The following must move out:

- runtime inspector
- raw agent output browser
- checkpoint archive
- general diff investigation tools

The Review tab should be the smallest tab after Track C, not the largest.

---

## 14. Component Architecture Refactor

### 14.1 Required decomposition

The current focus view relies on a mix of shallow tabs and a very large `ReviewTab`.

Track C must create reusable components:

- `FeatureDecisionBanner`
- `OperationalSummaryCard`
- `ProgressSnapshotCard`
- `VerificationSummaryCard`
- `RecentMaterialChanges`
- `ActionableRiskList`
- `SpecViewer`
- `PlanProgressPanel`
- `CheckpointRail`
- `CheckpointInspector`
- `RunHistoryBrowser`
- `RoleLogViewer`

### 14.2 Ownership rule

No component may own a capability that belongs to a different tab’s domain.

Example:

- file diff inspector may be shared, but `ChangesTab` owns its primary workflow
- role log viewer may be shared, but `RuntimeTab` and `HistoryTab` own where it is used

---

## 15. Testing Strategy

Track C requires a stronger testing bar than “renders heading text.”

### 15.1 Unit tests

Required for:

- verification summary derivation
- plan progress derivation
- revision summary derivation
- checkpoint pagination
- risk prioritization
- usage freshness labeling

### 15.2 Component tests

Required for:

- collapsible panels
- overflow wrapping behavior
- tab-to-capability ownership
- inspector selection
- checkpoint rail pagination
- spec viewer empty / loaded states
- runtime log viewer

### 15.3 Integration tests

Required for:

- `/feature/[id]` tab navigation with realistic payloads
- runtime logs visible in Runtime tab
- raw logs visible in History tab
- plan + spec visible in Plan tab
- clicking a checkpoint opens diff inspector

### 15.4 Regression tests for current failures

Explicitly add tests for:

- text overflow in cards and tables
- Verification Signals updating from evidence rather than phase fallback
- `CollisionRadar` collapsed-by-default behavior
- `UsageBurnChart` showing freshness and live update semantics
- `PlanTab` showing current task and remaining tasks
- `ChangesTab` supporting checkpoint pagination and inspection

---

## 16. Implementation Plan

### Slice 1: Data and derivation

- extend `FeatureDetail`
- add spec and plan-progress endpoints
- add checkpoint pagination endpoints
- add revision summary derivation
- strengthen verification summary derivation

### Slice 2: Sidebar + Overview

- replace stacked sidebar cards with operational summary
- add decision banner
- redesign overview summaries
- collapse secondary diagnostics

### Slice 3: Plan + Changes

- add spec viewer
- add plan progress panel
- move diff inspector into reusable component
- implement checkpoint rail and inspector

### Slice 4: Runtime + History

- mount runtime inspector
- move raw logs to Runtime and History
- add run history browser
- group evidence by run

### Slice 5: QA + Review cleanup

- mount evidence viewer in Gates & QA
- reduce Review tab to review-only scope
- finalize transcript deep links

### Slice 6: Quality hardening

- accessibility pass
- responsive pass
- visual overflow pass
- integration/regression tests

---

## 17. Acceptance Criteria

Track C is complete only when all of the following are true:

1. An operator can open `/feature/{id}` and identify readiness, primary blocker, active role, and next action in under 5 seconds.
2. `Verification Summary` reflects evidence-backed state and exposes freshness timestamps.
3. `CollisionRadar` is collapsed by default and expands into an inspectable list.
4. `PlanTab` exposes both the source spec and actual plan progress.
5. `ChangesTab` supports checkpoint pagination and selectable checkpoint investigation.
6. `RuntimeTab` exposes live runtime inspection and raw log viewing.
7. `HistoryTab` exposes archived runs, evidence, and raw logs.
8. `ReviewTab` is reduced to review-only responsibilities.
9. Long text values no longer overflow card boundaries.
10. Tests cover decision derivation and investigative interactions, not only heading presence.

---

## 18. Non-Goals

Track C does not require:

- redesigning the board page
- introducing a database
- adding drag-resizable panes
- building a generic analytics platform
- changing kernel semantics or execution policy

---

## 19. Architecture Notes

This track should prefer reusing existing infrastructure where it already exists:

- reuse `RuntimeInspectorPanel` rather than building a third runtime view
- reuse artifact-reading endpoints where possible
- reuse diff inspector logic from `ReviewTab`, but relocate ownership

At the same time, Track C should not preserve weak architecture merely because it exists. If a current component is the wrong abstraction, replace it.
