feat(web-ui): context-aware Quick Actions based on workspace state (#471)

[frankbria]

Summary

• QuickActions now accepts taskCounts?: TaskStatusCounts and derives a pipeline state from it
• State machine:
  • no_tasks (total == 0): Create PRD (primary) + Import PRD
  • tasks_ready (READY > 0, IN_PROGRESS == 0): Execute Tasks (primary) + Manage Tasks
  • executing (IN_PROGRESS > 0): View Running Tasks (primary) + Manage Tasks
  • done (DONE > 0, IN_PROGRESS == 0, READY == 0): View Proof Gates (primary) + Review Changes
  • mixed (fallback): original View PRD + Manage Tasks + Review Changes (all outline)
• page.tsx passes tasksData?.by_status to <QuickActions />
• QuickActionsProps added to web-ui/src/types/index.ts

Closes #471

Test plan

• No tasks → shows "Create PRD" (filled primary) + "Import PRD" (outline)
• READY tasks, not executing → shows "Execute Tasks" (primary) + "Manage Tasks"
• IN_PROGRESS tasks → shows "View Running Tasks" (primary) + "Manage Tasks"
• Only DONE tasks → shows "View Proof Gates" (primary) + "Review Changes"
• Mixed states (BACKLOG + BLOCKED) → shows fallback 3-button layout
• Build passes clean

Summary by CodeRabbit

• New Features
  • Quick Actions panel now dynamically displays context-aware options based on pipeline state, showing creation options for new pipelines, execution controls for active tasks, and review actions for completed work.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 1babfc82-a84b-4bea-ab12-a69db192e67d

📥 Commits

Reviewing files that changed from the base of the PR and between 49ff38b and 99dde04.

📒 Files selected for processing (3)

• web-ui/src/app/page.tsx
• web-ui/src/components/workspace/QuickActions.tsx
• web-ui/src/types/index.ts

---

Walkthrough

The QuickActions component now dynamically adapts its displayed buttons based on task status counts. The parent WorkspacePage passes fetched task-by-status data to QuickActions, which derives a pipeline state (no_tasks, tasks_ready, executing, done, or mixed) and conditionally renders context-appropriate action buttons.

Changes

Cohort / File(s)	Summary
Component Props & Types web-ui/src/types/index.ts	Added QuickActionsProps interface with optional taskCounts property to establish the component's input contract.
Page Data Flow web-ui/src/app/page.tsx	Updated WorkspacePage to pass task status counts (taskCounts={tasksData?.by_status}) to QuickActions component.
Context-Aware Quick Actions web-ui/src/components/workspace/QuickActions.tsx	Introduced state-driven button rendering: new PipelineState type, getPipelineState() derivation logic, and conditional rendering that displays different action buttons (Create/Import PRD, Generate/Manage Tasks, Execute Tasks, View Proof Gates, Review Changes) based on workspace task state.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 Quick actions now know the way,
Tasks speak, and buttons obey,
State by state, the path unfolds,
Context-aware, the story told. ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: implementing context-aware Quick Actions based on workspace state.
Linked Issues check	✅ Passed	The PR implementation addresses all key objectives from issue #471: dynamic state-based rendering (no_tasks, tasks_ready, executing, done, mixed), context-aware primary CTAs, hidden/de-emphasized irrelevant actions, and affected components updated.
Out of Scope Changes check	✅ Passed	All changes are scoped to the context-aware Quick Actions feature: component signature update, state machine implementation, type definitions, and page.tsx integration to pass task counts.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/issue-471-context-aware-quick-actions

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[claude]

Code Review

The state machine approach is clean and directly supports the Think → Build → Prove → Ship pipeline. A few issues worth addressing:

Bug: Loading state shows "Create PRD" prematurely

getPipelineState treats counts === undefined the same as total === 0 — both return no_tasks. On first load while tasksData is still fetching, users will briefly see "Create PRD" even if tasks exist. Consider returning null when counts is undefined and rendering a skeleton/nothing until data arrives.

Issue: done state matches too broadly

The condition counts.DONE > 0 && counts.READY === 0 (with the implicit IN_PROGRESS === 0 guard above) also fires when BACKLOG or FAILED tasks coexist with DONE tasks. That is not a completed state. Consider adding counts.BACKLOG === 0 && counts.FAILED === 0 to the guard, or falling through to mixed.

Minor: Multiple buttons in the same state link to the same route

• tasks_ready: "Execute Tasks" and "Manage Tasks" both go to /tasks
• executing: "View Running Tasks" and "Manage Tasks" both go to /tasks
• no_tasks: "Create PRD" and "Import PRD" both go to /prd

If the destination page doesn't differentiate by query param or anchor, the secondary button is a duplicate. Either add a filter param (e.g. /tasks?filter=ready) or leave a comment marking the intent for a future route.

No unit tests for getPipelineState

The function is pure with clear branching — ideal for automated tests. Edge cases worth covering: undefined counts, only FAILED/BLOCKED tasks, DONE+BACKLOG mix. The manual test plan is good but automated tests would prevent regressions.

Nit: total calculation could use Object.values

The current 7-field addition is correct. Using Object.values(counts).reduce((a, b) => a + b, 0) would be more maintainable if new statuses are ever added to TaskStatusCounts.

---

Overall the feature is well-scoped, the component API is backwards-compatible (taskCounts? is optional), and the pipeline states map cleanly to the Think → Build → Prove → Ship stages. The loading-state flash and the done over-matching are the main items to address before merge.