iterative-works/iw-cli

Watch

Fork 0

Review-state cards of finished issues are never removed #706

New issue

Open

opened 2026-10-04 14:12:04 +00:00 by claude · 3 comments

claude commented

2026-10-04 14:12:04 +00:00

Member

Filed from IW-702 follow-ups. Once the card lives in the git dir (IW-702), cards of finished issues stay behind in two places:

Bulk-untrack the review-state cards of merged issues that stay tracked on main (84 in iw-cli). — evidence: git ls-files 'project-management/issues/*/review-state.json' lists them (73 on the IW-702 branch on 2026-10-04)
Prune review-state cards in the common git dir after iw rm removes their worktree. — evidence: iw rm leaves the out-of-tree card behind

Filed from IW-702 follow-ups. Once the card lives in the git dir (IW-702), cards of finished issues stay behind in two places: - [ ] Bulk-untrack the review-state cards of merged issues that stay tracked on `main` (84 in iw-cli). — evidence: `git ls-files 'project-management/issues/*/review-state.json'` lists them (73 on the IW-702 branch on 2026-10-04) - [ ] Prune review-state cards in the common git dir after `iw rm` removes their worktree. — evidence: `iw rm` leaves the out-of-tree card behind

mph referenced this issue from a commit

2026-10-04 14:14:37 +00:00

chore(IW-702): file follow-ups (#706, #707, #708, dev-docs#439)

claude referenced this issue

2026-10-04 14:14:47 +00:00

IW-702: Keep the review-state card out of version control #709

claude commented

2026-10-07 00:22:15 +00:00

Author

Member

Intake: needs-input

1. Is item 1 a one-time cleanup commit in iw-cli, or a command that any repository can run?

74 review-state.json files are still tracked on main (git ls-files today). After IW-702, nothing reads them: the dashboard reads only the card in the git dir. IW-702's analysis called a bulk tool "new scope" and said the cleanup is a one-line command that a human can run. It also says other repositories have the same problem. Git history keeps the files after either option.

"A bulk untrack tool is new scope and nothing breaks without it … The per-repository cleanup is a one-line git rm --cached that a human can run."
https://code.iterative.works/iterative-works/iw-cli/src/branch/main/project-management/issues/IW-702/analysis.md#L279-L281

a) One chore commit in iw-cli. It removes the 74 files from the tree. A short docs note gives the command for other repositories. This is about 15 minutes of work.
b) An iw command or a doctor fix. It finds the tracked cards in any repository and removes them. This is new code with tests and docs.
c) Both. Make the commit now, and build the command as well.

Recommended: a) — nothing breaks without a tool, and a) changes the least.

2. When must `iw rm` delete the card in the git dir, if ever?

IW-702 made the card survive iw rm on purpose. iw rm keeps the branch, and iw start on that branch then resumes with the card's PR link, phase checkpoints and workflow type. If iw rm always deletes the card, a resume after rm loses that state.

"An iw rm followed by iw start on the same branch … resumes with the card … iw rm does not delete the card."
https://code.iterative.works/iterative-works/iw-cli/src/branch/main/project-management/issues/IW-702/analysis.md#L255-L259

a) Always delete it in iw rm. This is simple, but a resume after rm loses its state.
b) Delete it only when the card says the work is finished (status all_complete). A resume of unfinished work still has its state.
c) A separate prune command or an iw rm flag. Nothing is deleted unless the human asks.
d) Drop item 2. Cards are small. Keep them.

Recommended: b) — it removes the cards of finished issues and keeps the resume behaviour that IW-702 chose.

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. Is item 1 a one-time cleanup commit in iw-cli, or a command that any repository can run? 74 `review-state.json` files are still tracked on `main` (`git ls-files` today). After IW-702, nothing reads them: the dashboard reads only the card in the git dir. IW-702's analysis called a bulk tool "new scope" and said the cleanup is a one-line command that a human can run. It also says other repositories have the same problem. Git history keeps the files after either option. > "A bulk untrack tool is new scope and nothing breaks without it … The per-repository cleanup is a one-line `git rm --cached` that a human can run." https://code.iterative.works/iterative-works/iw-cli/src/branch/main/project-management/issues/IW-702/analysis.md#L279-L281 - **a) One chore commit in iw-cli.** It removes the 74 files from the tree. A short docs note gives the command for other repositories. This is about 15 minutes of work. - **b) An iw command or a doctor fix.** It finds the tracked cards in any repository and removes them. This is new code with tests and docs. - **c) Both.** Make the commit now, and build the command as well. **Recommended: a)** — nothing breaks without a tool, and a) changes the least. ### 2. When must `iw rm` delete the card in the git dir, if ever? IW-702 made the card survive `iw rm` on purpose. `iw rm` keeps the branch, and `iw start` on that branch then resumes with the card's PR link, phase checkpoints and workflow type. If `iw rm` always deletes the card, a resume after `rm` loses that state. > "An `iw rm` followed by `iw start` on the same branch … resumes with the card … `iw rm` does not delete the card." https://code.iterative.works/iterative-works/iw-cli/src/branch/main/project-management/issues/IW-702/analysis.md#L255-L259 - **a) Always delete it in `iw rm`.** This is simple, but a resume after `rm` loses its state. - **b) Delete it only when the card says the work is finished** (status `all_complete`). A resume of unfinished work still has its state. - **c) A separate prune command or an `iw rm` flag.** Nothing is deleted unless the human asks. - **d) Drop item 2.** Cards are small. Keep them. **Recommended: b)** — it removes the cards of finished issues and keeps the resume behaviour that IW-702 chose. 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-07 00:22:15 +00:00

mph commented

2026-10-10 19:13:47 +00:00

Owner

1: a, 2:b

claude removed the

needs-input

label

2026-10-11 02:40:33 +00:00

claude commented

2026-10-11 02:52:53 +00:00

Author

Member

Intake: needs-input
Workflow: waterfall
Reason: G7 (1 [human] finding), and one fact the earlier answer to question 2 rested on
Analysis: project-management/issues/IW-706/analysis.md on branch IW-706

1. Should the cleanup commit also delete the 11 effort slice cards, or only the 74 issue cards? (G7)

You chose option a: one cleanup commit that "removes the 74 files", meaning the issue cards. The analysis adds 11 more files to that commit. They are the slice cards of the effort dashboard-control-plane, under project-management/efforts/dashboard-control-plane/slices/*/review-state.json, so the commit deletes 85 files. No reader uses these 11 cards, and all 11 slice trackers say status: closed. But you did not approve them. See analysis.md L78.

a) Delete all 85. The 11 slice cards go in the same commit. It is one commit, and no work stays for later.
b) Delete only the 74 issue cards. The 11 slice cards stay tracked, and one line in FOLLOW-UPS.md records them. This does exactly what you approved, but it needs a second cleanup later.

Recommended: a): the slice cards are dead for the same reason as the issue cards, and keeping them saves nothing.

2. Should `iw rm` delete a card marked "finished" while its final pull request is still open? (G7)

You chose this rule: iw rm deletes the card only when its status is all_complete. But kanon (at commit a0ffcfc) sets all_complete when the final PR is created, not when it is merged. If you run iw rm before the merge, the card is deleted, and with it the PR link and the phase checkpoints. The review-state schema has no status that means "final PR merged". Today iw rm does not ask the forge about PRs.

--message "All phases complete - final PR created" (kanon commands/wf-implement.md:672-693)
all_complete — "Next Step: Review and merge final PR" (kanon skills/review-state-schema/SKILL.md:468-472)

a) Keep the rule as it is. This adds no code. If you run rm before the merge, the card is lost and iw start on that branch starts with no saved state.
b) Also require the PR to be merged. iw rm asks the forge for the state of the card's pr_url. If it cannot tell, it keeps the card. This adds a forge call and a test fake to rm.
c) Add a merged status in kanon and delete only on that status. This is a change to kanon, outside this issue. Until it lands, rm deletes nothing.

Recommended: b): it closes the gap and keeps the "if unsure, keep the card" rule, and it needs no change to kanon.

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 Workflow: waterfall Reason: G7 (1 [human] finding), and one fact the earlier answer to question 2 rested on Analysis: project-management/issues/IW-706/analysis.md on branch IW-706 ### 1. Should the cleanup commit also delete the 11 effort slice cards, or only the 74 issue cards? (G7) You chose option a: one cleanup commit that "removes the 74 files", meaning the issue cards. The analysis adds 11 more files to that commit. They are the slice cards of the effort `dashboard-control-plane`, under `project-management/efforts/dashboard-control-plane/slices/*/review-state.json`, so the commit deletes 85 files. No reader uses these 11 cards, and all 11 slice trackers say `status: closed`. But you did not approve them. See [analysis.md L78](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-706/project-management/issues/IW-706/analysis.md#L78-L78). - **a) Delete all 85.** The 11 slice cards go in the same commit. It is one commit, and no work stays for later. - **b) Delete only the 74 issue cards.** The 11 slice cards stay tracked, and one line in `FOLLOW-UPS.md` records them. This does exactly what you approved, but it needs a second cleanup later. **Recommended: a)**: the slice cards are dead for the same reason as the issue cards, and keeping them saves nothing. ### 2. Should `iw rm` delete a card marked "finished" while its final pull request is still open? (G7) You chose this rule: `iw rm` deletes the card only when its status is `all_complete`. But kanon (at commit a0ffcfc) sets `all_complete` when the final PR is created, not when it is merged. If you run `iw rm` before the merge, the card is deleted, and with it the PR link and the phase checkpoints. The review-state schema has no status that means "final PR merged". Today `iw rm` does not ask the forge about PRs. > `--message "All phases complete - final PR created"` (kanon `commands/wf-implement.md:672-693`) > `all_complete` — "Next Step: Review and merge final PR" (kanon `skills/review-state-schema/SKILL.md:468-472`) - **a) Keep the rule as it is.** This adds no code. If you run `rm` before the merge, the card is lost and `iw start` on that branch starts with no saved state. - **b) Also require the PR to be merged.** `iw rm` asks the forge for the state of the card's `pr_url`. If it cannot tell, it keeps the card. This adds a forge call and a test fake to `rm`. - **c) Add a merged status in kanon and delete only on that status.** This is a change to kanon, outside this issue. Until it lands, `rm` deletes nothing. **Recommended: b)**: it closes the gap and keeps the "if unsure, keep the card" rule, and it needs no change to kanon. 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-11 02:52:53 +00:00

claude referenced this issue

2026-10-16 06:55:30 +00:00

Add iw finish command: merge final PR and remove worktree #249