Redesign worktree card for clearer next actions #118

New issue

Open

opened 2026-01-14 09:07:53 +00:00 by mprihoda · 1 comment

mprihoda commented

2026-01-14 09:07:53 +00:00

(Migrated from github.com)

Rethink the worktree card design:

Review what information is displayed and how it's represented
Make it immediately clear what the next step is for each worktree
Give the user prominent, correct action buttons based on current state
Reduce cognitive load when scanning multiple worktrees

Rethink the worktree card design: - Review what information is displayed and how it's represented - Make it immediately clear what the next step is for each worktree - Give the user prominent, correct action buttons based on current state - Reduce cognitive load when scanning multiple worktrees

claude commented

2026-10-16 08:57:18 +00:00

Member

Intake: needs-input

1. Where must the card get each worktree's "next step"?

The review-state card already has an available_actions field (core/model/ReviewStateValidator.scala:376-381). The dashboard does not read it. The card now shows the status text and subtext from review-state (WorktreeCardRenderer.scala#L905-L916). It also shows the tracker status, the git status and the PR.

a) From review-state. The card shows the available_actions that the workflow writes. The dashboard decides nothing, but a worktree with no review-state gets no next step.
b) The dashboard calculates it. One fixed rule reads git, PR, progress and tracker status, so every worktree gets a step. But the rule can disagree with the workflow.
c) Review-state first, then the rule from b) when there is no review-state. This gives the most coverage and costs the most.

Recommended: a) — the workflow already writes this data, so the dashboard keeps no second copy of the workflow rules.

2. What can the "action buttons" do?

The card now has only links: Repo, PR and Zed (WorktreeCardRenderer.scala#L560-L650). Buttons that run commands overlap open issues #91 (remove button), #477 (one orchestration for worktree commands) and #354 (send instructions to an agent).

a) Links only. The card puts the correct link first for each state. No new server endpoints.
b) Links, and buttons that run iw commands (for example phase-pr, phase-merge, rm). This needs endpoints and touches #91 and #477.

Recommended: a) — it changes the least and does not get ahead of #477.

3. Must this be an interactive design slice with you, or an unattended change from a written spec?

The issue says "rethink" and "reduce cognitive load". It is difficult to judge that without a person who looks at a prototype.

a) An interactive slice. You start it with sl-define and judge each prototype. This loop stops here.
b) Unattended. The analyst works from your answers to 1 and 2, and you review the result in the PR.

Recommended: a) — "clearer" and "less cognitive load" are fit judgements that only you can make.

Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

Intake: needs-input ### 1. Where must the card get each worktree's "next step"? The review-state card already has an `available_actions` field (core/model/ReviewStateValidator.scala:376-381). The dashboard does not read it. The card now shows the status text and subtext from review-state ([WorktreeCardRenderer.scala#L905-L916](https://code.iterative.works/iterative-works/iw-cli/src/branch/main/dashboard/jvm/src/presentation/views/WorktreeCardRenderer.scala#L905-L916)). It also shows the tracker status, the git status and the PR. - **a) From review-state.** The card shows the `available_actions` that the workflow writes. The dashboard decides nothing, but a worktree with no review-state gets no next step. - **b) The dashboard calculates it.** One fixed rule reads git, PR, progress and tracker status, so every worktree gets a step. But the rule can disagree with the workflow. - **c) Review-state first, then the rule from b) when there is no review-state.** This gives the most coverage and costs the most. **Recommended: a)** — the workflow already writes this data, so the dashboard keeps no second copy of the workflow rules. ### 2. What can the "action buttons" do? The card now has only links: Repo, PR and Zed ([WorktreeCardRenderer.scala#L560-L650](https://code.iterative.works/iterative-works/iw-cli/src/branch/main/dashboard/jvm/src/presentation/views/WorktreeCardRenderer.scala#L560-L650)). Buttons that run commands overlap open issues #91 (remove button), #477 (one orchestration for worktree commands) and #354 (send instructions to an agent). - **a) Links only.** The card puts the correct link first for each state. No new server endpoints. - **b) Links, and buttons that run iw commands** (for example phase-pr, phase-merge, rm). This needs endpoints and touches #91 and #477. **Recommended: a)** — it changes the least and does not get ahead of #477. ### 3. Must this be an interactive design slice with you, or an unattended change from a written spec? The issue says "rethink" and "reduce cognitive load". It is difficult to judge that without a person who looks at a prototype. - **a) An interactive slice.** You start it with sl-define and judge each prototype. This loop stops here. - **b) Unattended.** The analyst works from your answers to 1 and 2, and you review the result in the PR. **Recommended: a)** — "clearer" and "less cognitive load" are fit judgements that only you can make. Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

claude added the

needs-input

label

2026-10-16 08:57:18 +00:00