agentic-orchestrator 0.1.27 → 0.2.0

package/spec-files/completed/agentic_orchestrator_feature_focus_view_track_c_decision_centric_remediation_spec.md

@@ -0,0 +1,1037 @@
+# 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.