Slice 08: the cleanup gets done — remove a worktree from the browser, and it stays gone #470

Merged

mph merged 33 commits from dashboard-control-plane into main 2026-08-27 19:39:06 +00:00

Conversation 0 Commits 33 Files changed 46 +3908 -223

mph commented 2026-08-27 11:27:19 +00:00

Owner

Copy link

The card (frozen)

Goal — I remove the worktrees I am finished with from the browser, where I
already see them, and they stay gone.

Fit test — I clear out the worktrees I am finished with from the browser in
one sitting, without opening a terminal. It closes only on Michal's read:
nothing missing, nothing foreign, and "is it actually gone, or does the sweep
bring it back?" answered correctly.

Fit passed on his read.

The card's three invariants shaped every decision below:

1. Nothing leaves a mark without an explicit confirm, and a dirty worktree needs
   a second, separate confirm with the changed files named first.
2. The dashboard is a front end over the same behaviour, never a fork — removal
   runs ./iw rm and re-implements none of its guards.
3. Dashboard state is honest — a removal reported done means disk agrees.

What ships

The board already showed 70 registered worktrees and no page offered a way to
remove one. The only existing removal, DELETE /api/v1/worktrees/:issueId,
unregistered from server state alone — and slice 01's disk sweep re-registered
the worktree on the next GET /, so an unregister-only remove undid itself.

• ./iw rm can be driven without a terminal. --no-prompt refuses a dirty
  worktree with exit 2 instead of asking a question nobody can answer;
  --expect-dirty <id> forces only over the changes the caller already named,
  re-reading porcelain and refusing on a mismatch so nothing is destroyed
  unnamed; --path <dir> removes a worktree that follows no naming convention.
• DirtyState is the one reading of what a removal would destroy, shared by
  the CLI and the dashboard, so the two cannot disagree about it.
• A Remove control on the project-page cards and the worktree detail page.
  It confirms, names every uncommitted file before the second confirm, shows the
  click landed, and takes the card away when the worktree is gone.
• The removal itself is ./iw rm, run as a subprocess in the project the
  registration recorded. The dashboard reads the exit code and parses no prose.

Proven, not asserted

The fit test asks whether a removal sticks. Both halves are pinned:

• WorktreeSweepItest — a sweep that demonstrably recovers a live worktree
  brings back neither a removed-and-unregistered one nor a removed one whose
  best-effort unregister never landed.
• WorktreeRemovalItest — the real route drives a real worktree off disk
  through a ./iw that first checks the dashboard asked the way ./iw rm
  expects to be asked.
• A sandbox run of the whole act on a real repository with a live tmux
  workspace: directory gone, workspace closed, branch kept, off the board, off
  the project page, detail 404 — still true after a real sweep and a cold
  restart.

Found on the way, fixed at source

• ProcessAdapter.run trimmed every command's stdout, eating the leading
  space of git status --porcelain — so M README.md parsed as a staged
  change to EADME.md. Phase-commit validation had been reading its first file
  that way for as long as it has existed.
• The dashboard had no Forgejo case and rendered its cards as skeletons
  forever, indistinguishable from a pending fetch. Four duplicated tracker
  dispatches are now one pure IssueSource.
• Prompt.confirm threw on a closed stdin where Prompt.ask had always
  taken the default.
• The README claimed iw rm deletes the branch. It never has. The flags,
  the refusals and the exit codes are now in docs/commands/rm.md.

From the close review

Two rounds, seven skills. Two criticals, both fixed and pinned:

• A crafted worktree key could hijack a click. hx-vals was built by
  interpolation; htmx reads that attribute back with getAttribute, which undoes
  the HTML escaping, then parses it as JSON. A registered key is checked only for
  being non-empty, so a key holding a quote rendered a confirm whose button
  posted a forced removal of a different worktree, past the dirty-file
  list. Round 2 then found the same key still raw in a URL path (where / and
  .. read as dot segments the browser resolves away) and in a CSS selector
  (where a comma widens the swap target). Each context is now escaped for itself.
• Invariant 3 rested on an exit code. ./iw rm exits 0 both when it removed
  the worktree and when a human declined its prompt. The dashboard now checks
  disk before reporting Removed — and CommandResult.cancelled (4) makes the
  CLI's own contract say it, leaving 0 to mean the worktree is gone.

Also fixed in-loop: a failed dirty check was shown as "nothing to lose"; the
assembled removal path had no test; the removable card wiring was untested;
confirm/confirmDirty were duplicated.

Full report: project-management/efforts/dashboard-control-plane/slices/08-the-cleanup-gets-done/review-slice-20260826-141022.md

Follow-up (parked, not done here)

• The destructive route is unauthenticated, and worktree registration
  accepts any non-empty key with any absolute path — so whoever can register
  can plant a card pointing at another worktree's directory. No escaping
  fixes that; it is the registration boundary. → the-board-says-who-may-look
• No CSRF defence on the destructive POST.
• No per-key lock, so two removals of one worktree can race two ./iw rm
  processes over one directory.
• ./iw rm's output, including whatever a project cleanup hook prints, is
  rendered verbatim on failure.
• Every non-dirty refusal becomes a 500, including ordinary ones like "you
  are in its workspace".
• A card says why it cannot show an issue. A permanent tracker failure
  still renders as the same skeleton a pending fetch renders. Carries with it
  that IssueSource now falls back to the shared example.com placeholder
  for a GitHub project with no repository configured.
• Finding or marking the stale ones — a merged PR is not a staleness signal.
  → the-quiet-ones-fold-away

Lessons

Eight entries triaged with Michal before this PR. Three filed against kanon:
#189 (an
iw kanon/lesson command that validates the entry shape),
#190 (a
rendered control is not a verified control) and
#191
(escaping is per-context). Two landed as
.claude/skills/dashboard-htmx-controls/, one in CLAUDE.md, the rest at
source.

## The card (frozen) **Goal** — I remove the worktrees I am finished with from the browser, where I already see them, and they stay gone. **Fit test** — I clear out the worktrees I am finished with from the browser in one sitting, without opening a terminal. It closes only on Michal's read: nothing missing, nothing foreign, and *"is it actually gone, or does the sweep bring it back?"* answered correctly. **Fit passed** on his read. The card's three invariants shaped every decision below: 1. Nothing leaves a mark without an explicit confirm, and a dirty worktree needs a **second, separate** confirm with the changed files **named first**. 2. The dashboard is a front end over the same behaviour, never a fork — removal runs `./iw rm` and re-implements none of its guards. 3. Dashboard state is honest — a removal reported done means disk agrees. ## What ships The board already showed 70 registered worktrees and no page offered a way to remove one. The only existing removal, `DELETE /api/v1/worktrees/:issueId`, unregistered from server state alone — and slice 01's disk sweep re-registered the worktree on the next `GET /`, so an unregister-only remove undid itself. - **`./iw rm` can be driven without a terminal.** `--no-prompt` refuses a dirty worktree with exit `2` instead of asking a question nobody can answer; `--expect-dirty <id>` forces only over the changes the caller already named, re-reading porcelain and refusing on a mismatch so nothing is destroyed unnamed; `--path <dir>` removes a worktree that follows no naming convention. - **`DirtyState`** is the one reading of what a removal would destroy, shared by the CLI and the dashboard, so the two cannot disagree about it. - **A Remove control** on the project-page cards and the worktree detail page. It confirms, names every uncommitted file before the second confirm, shows the click landed, and takes the card away when the worktree is gone. - **The removal itself is `./iw rm`**, run as a subprocess in the project the registration recorded. The dashboard reads the exit code and parses no prose. ## Proven, not asserted The fit test asks whether a removal *sticks*. Both halves are pinned: - `WorktreeSweepItest` — a sweep that demonstrably recovers a live worktree brings back neither a removed-and-unregistered one nor a removed one whose best-effort unregister never landed. - `WorktreeRemovalItest` — the real route drives a real worktree off disk through a `./iw` that first checks the dashboard asked the way `./iw rm` expects to be asked. - A sandbox run of the whole act on a real repository with a live tmux workspace: directory gone, workspace closed, branch kept, off the board, off the project page, detail 404 — still true after a real sweep and a cold restart. ## Found on the way, fixed at source - **`ProcessAdapter.run` trimmed every command's stdout**, eating the leading space of `git status --porcelain` — so ` M README.md` parsed as a *staged* change to `EADME.md`. Phase-commit validation had been reading its first file that way for as long as it has existed. - **The dashboard had no Forgejo case** and rendered its cards as skeletons forever, indistinguishable from a pending fetch. Four duplicated tracker dispatches are now one pure `IssueSource`. - **`Prompt.confirm` threw on a closed stdin** where `Prompt.ask` had always taken the default. - **The README claimed `iw rm` deletes the branch.** It never has. The flags, the refusals and the exit codes are now in `docs/commands/rm.md`. ## From the close review Two rounds, seven skills. Two criticals, both fixed and pinned: - **A crafted worktree key could hijack a click.** `hx-vals` was built by interpolation; htmx reads that attribute back with `getAttribute`, which undoes the HTML escaping, then parses it as JSON. A registered key is checked only for being non-empty, so a key holding a quote rendered a confirm whose button posted a **forced** removal of a **different** worktree, past the dirty-file list. Round 2 then found the same key still raw in a URL path (where `/` and `..` read as dot segments the browser resolves away) and in a CSS selector (where a comma widens the swap target). Each context is now escaped for itself. - **Invariant 3 rested on an exit code.** `./iw rm` exits 0 both when it removed the worktree and when a human declined its prompt. The dashboard now checks disk before reporting `Removed` — and `CommandResult.cancelled` (4) makes the CLI's own contract say it, leaving `0` to mean the worktree is gone. Also fixed in-loop: a failed dirty check was shown as "nothing to lose"; the assembled removal path had no test; the `removable` card wiring was untested; `confirm`/`confirmDirty` were duplicated. Full report: `project-management/efforts/dashboard-control-plane/slices/08-the-cleanup-gets-done/review-slice-20260826-141022.md` ## Follow-up (parked, not done here) - [ ] **The destructive route is unauthenticated**, and worktree registration accepts any non-empty key with any absolute path — so whoever can register can plant a card pointing at another worktree's directory. No escaping fixes that; it is the registration boundary. → `the-board-says-who-may-look` - [ ] No CSRF defence on the destructive POST. - [ ] No per-key lock, so two removals of one worktree can race two `./iw rm` processes over one directory. - [ ] `./iw rm`'s output, including whatever a project cleanup hook prints, is rendered verbatim on failure. - [ ] Every non-dirty refusal becomes a 500, including ordinary ones like "you are in its workspace". - [ ] **A card says why it cannot show an issue.** A permanent tracker failure still renders as the same skeleton a pending fetch renders. Carries with it that `IssueSource` now falls back to the shared `example.com` placeholder for a GitHub project with no repository configured. - [ ] Finding or marking the stale ones — a merged PR is not a staleness signal. → `the-quiet-ones-fold-away` ## Lessons Eight entries triaged with Michal before this PR. Three filed against kanon: [#189](https://code.iterative.works/iterative-works/dev-docs/issues/189) (an `iw kanon/lesson` command that validates the entry shape), [#190](https://code.iterative.works/iterative-works/dev-docs/issues/190) (a rendered control is not a verified control) and [#191](https://code.iterative.works/iterative-works/dev-docs/issues/191) (escaping is per-context). Two landed as `.claude/skills/dashboard-htmx-controls/`, one in `CLAUDE.md`, the rest at source.

mph added 28 commits 2026-08-27 11:27:19 +00:00

workflow(sl): define dashboard-control-plane/08-the-cleanup-gets-done ... e21ffb3257

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

workflow(sl): review-state for dashboard-control-plane/08-the-cleanup-gets-done ... 493beee153

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

workflow(sl): seed 08 tracker with the non-interactive Rm contract ... ed0fe950bc

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

feat(rm): name the changed files, and answer without a terminal ... 711ae7d1a3

DirtyState reads `git status --porcelain` once into the changed paths and a
fingerprint of them, so `./iw rm` names what a removal would destroy instead of
only counting it, and every surface reads the same list.

`--no-prompt` gives a caller with no terminal a way in: a dirty worktree that was
not forced exits `CommandResult.needsApproval` (2) and asks nothing, which tells
the dirty refusal apart from every other failure by code alone.

`git status --porcelain` is now read untrimmed. The first status character is a
space for a working-tree-only change, and trimming it turned that first line into
a staged change to a path missing its first letter — `getStagingCheck` read it
that way too.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

feat(dashboard): remove a worktree from the browser ... 41158f7ce8

The worktree detail page gets a Remove control: a confirm that names the
worktree and says the workspace will close and the branch will stay, then a
removal that actually happens.

The removal runs the project's own `./iw rm <key> --no-prompt` as a subprocess in
the project directory, so nothing here re-implements the exists check, the "you
are in its workspace" guard, the cleanup hooks, the workspace close or the
`git worktree remove` — and a cleanup hook that throws or hangs costs a request,
not the server. The exit code alone says which of the four answers to render, so
no prose is parsed: 0 removed, 2 needs a human's approval over uncommitted
changes, anything else failed.

The control sits outside the detail page's polled content, so a confirm the
human opened survives the refresh that lands under it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

workflow(sl): checkpoint 08-the-cleanup-gets-done 6573bc9f98

workflow(sl): awaiting fit on the detail-page Remove control fa4437e978

workflow(sl): fit reaction — dirty removals blocked, click needs feedback 0668619a05

feat: remove a worktree that holds uncommitted changes, over a named list ... 1b5d75823a

The dashboard reads the worktree's dirty state through the same DirtyState the
CLI gates on, names every file the removal would destroy, and asks a second,
separate confirm. Forcing sends back the id of that very list as
`--force --expect-dirty <id>`; `./iw rm` re-reads porcelain and refuses with exit
2 if a path went dirty in between, so nothing is destroyed that was never named.
A refusal — unforced or mismatched — re-renders the confirm against the list as
it stands now, so the loop converges without a third exit code.

The id follows the key on the command line on purpose: an `./iw` that does not
know the flag reads the first bare argument as the key, so the forced path works
on a CLI without this contract.

A destructive click now shows it landed — the button goes busy, says "Removing…"
and cannot be clicked twice — and a failure leads with its first line, folding
the rest away instead of opening on a stack trace.

Prompt.confirm took a closed stdin as an NPE, so any command asking a question
with no terminal to answer it died rather than taking its default. Prompt.ask
had always handled it; confirm now does too.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

workflow(sl): checkpoint — dirty path and click feedback done 71ea6c340d

feat(rm): remove a worktree that follows no naming convention ... 931bd14189

A worktree made by hand lives at a path of its own and is keyed on its branch —
neither an issue nor an effort. `./iw rm` could not remove it at all: the name
failed to parse, and the path it would have derived (`<project>-<name>` beside
the project) is not where the worktree is.

`--path <dir>` aims the removal at a directory. The name is then opaque: it
identifies the registration and nothing is derived from it, so a branch-keyed
worktree removes like any other. Git still decides whether the directory is a
worktree of this project, so an arbitrary directory is refused. The kept-branch
reminder is printed only when the name says which branch that is.

The dashboard passes the registered path for every removal — the card the human
clicked stands for one exact directory, and deriving it a second time is what
let these worktrees fall through.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

workflow(sl): checkpoint — branch-keyed worktrees are removable ba484fccb7

feat(dashboard): Remove on the project page worktree cards ... f6df2c2376

The project page is where the worktrees that claim no act live, and they are the
ones a cleanup is about. Each card now carries the same Remove control the detail
page has, with the same confirm and the same dirty path.

A card refetches itself every 30s and swaps its own outerHTML, so the control has
to survive that: the box is hx-preserve'd, and the card asks for a removable card
back (`?removable=true`) rather than one without the control. A removal takes the
card away with it through an out-of-band delete — a card left standing after
"Removed" is the dashboard disagreeing with the disk.

The board still has none, deliberately: a destructive control beside the acts the
human must perform is a mis-click. A test now pins that.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

fix(dashboard): preserve the slot around the removal box, not the box ... c86c590a60

htmx's handlePreservedElements substitutes the existing DOM node for any
incoming element carrying hx-preserve with the same id. The removal box was both
the swap target and preserved, so on a project-page card every click would have
been answered by htmx putting the old box straight back — the confirm would never
have appeared, and no server test could have caught it.

The preserved element is now a slot wrapping the box. The card refresh keeps the
slot with whatever the human has open inside it; the removal flow swaps the box
within. A test asserts that nothing a swap replaces is ever itself preserved.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

fix(dashboard): a removal route must tolerate the hx-vals a card leaks ... 299f23aa55

HTMX bug #1119: the worktree list's hx-vals is inherited by every request made
from inside a card, and hx-disinherit does not stop it. The removal routes
refused the uninvited `have` parameter with 400, so on the project page the
Remove button did nothing at all — no server test could see it, only a browser.

Caught by driving the page in Playwright, along with the preserved-target bug
fixed in c86c590. An integration test now sends `have` at all three routes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

workflow(sl): checkpoint — the project page can remove d764bda2bd

workflow(sl): awaiting fit on the project page 311f70aeee

workflow(sl): record the Forgejo fetch gap found while checking IW-426 95fb9c7314

fix(dashboard): read Forgejo issues, instead of loading forever ... 2fe3fe26ff

The dashboard matched linear, github and youtrack and fell through to
`Left("Unknown tracker type: Forgejo")`. WorktreeCardService reads that Left as
"the API failed, use the cache", the cache was never filled, and the skeleton
card rendered — the same rendering a card shows while it is genuinely still
loading. Every Forgejo worktree sat at "Loading…" permanently: 0 of 8 cached in
the live state, against 32 of 44 for YouTrack.

The dispatch existed four times over — two fetch overloads and two URL builders —
and three of them were missing Forgejo, the fourth answering
`https://example.com/issue/IW-426`. They are now one pure `IssueSource.resolve`,
which decides which tracker, which repository and which instance without a
network call, and carries the page a human opens. Fetching is left with only the
call and its credentials.

ForgejoClient.fetchIssue and Constants.EnvVars.ForgejoApiToken already existed;
only the dispatch to them was missing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

workflow(sl): the Forgejo gap was fixed here, not deferred f203add7c1

test(dashboard): a removed worktree stays gone across the disk sweep ... 9eec3a1ba5

The sweep recovers worktrees from disk, so the question the cleanup has to
answer is whether it also brings back the ones a removal took away. It does
not, and now something says so: one real repository, one worktree removed and
unregistered, one removed whose best-effort unregister never landed, and one
alive but unknown to state. The live one is recovered — without that the test
could pass on a sweep that did nothing — and neither removed one comes back,
on the board, on the project page, or in state.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

workflow(sl): checkpoint 08-the-cleanup-gets-done ... 6c6cf202be

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

fix(dashboard): a removal is named in the URL, and checked against disk ... a5c712b79f

Two holes the close review found, both under the card's own invariants.

htmx reads hx-vals back with getAttribute, which undoes HTML escaping, and
then parses it as JSON — so escaping it as HTML never made it safe as JSON.
A worktree key carrying a quote closed the string and added members of its
own, and a registered key is only checked for being non-empty. A card whose
key read `x", "force": "true", "y": "` therefore rendered a confirm whose
Remove button posted a force-removal of a different worktree, past the
dirty-file list the human is supposed to read first. The worktree is now
named in the URL, where cask parses it out of the path, and the values that
remain are written by a JSON writer.

And exit 0 alone never meant the worktree was gone: `./iw rm` also ends
cleanly when a human declines its prompt, so a CLI built before --no-prompt,
asked over a closed stdin, answers 0 having touched nothing. The dashboard
would have reported that as Removed. Disk now says whether it was.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

fix(dashboard): say what the confirm cannot tell, and document what rm promises ... b3d0ea1bb4

Three more from the close review.

A confirm read git for uncommitted changes and treated "git did not answer"
the same as "there are none" — showing the plain confirm, which reads as an
assurance nobody gave. It now says it could not tell, and still offers the
removal, because `./iw rm` re-reads the worktree and refuses on its own.

The removal outcome carried a base-class key no caller ever read; every case
already names its own.

And `iw rm`'s surface was undocumented and the README's one line about it was
wrong — it has never deleted the branch, which is the behaviour this slice
depends on. The flags, what it refuses, and the exit codes a caller reads it
by are now written down where a caller looks.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

workflow(sl): close review for 08-the-cleanup-gets-done, and two lessons from it ... 1df68e2f22

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

fix(dashboard): a key names one box and one worktree, or nothing ... c802330bec

Round 2 of the close review found the first fix had moved the problem rather
than closed it. A registered key is only checked for being non-empty, and it
was still written raw into two places that read their own metacharacters.

In a URL path, a key holding `/` and `..` reads as dot segments the browser
resolves away before the request is sent, so `../api/worktrees/other` left the
page aimed at `other`. The key is now escaped into one segment; cask matches
it undecoded, so a key that needed escaping is answered for nobody and fails
closed, while issue ids, effort slugs and branch-derived keys encode to
themselves.

In an hx-target, a key holding a comma turned one id selector into a selector
list, and htmx swaps whatever `querySelector` matches first — another
worktree's card, or the body. The selector is now written as a CSS identifier.

The escaping also emptied the posted values on the detail page, where there is
nothing else to send. Cask has no form to parse then and the click dies at the
parser, so the flag is always written, false included.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

workflow(sl): record round 2 of the close review ... 13ceb8c08a

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

workflow: triage lessons for dashboard-control-plane ... e1cf757cb8

Promoted:
- a trimming process adapter corrupted whitespace-significant output → fixed-at-source (711ae7d)
- the README says `iw rm` deletes the branch → fixed-at-source (b3d0ea1)
- a first LESSONS entry overwrote an effort's existing one → kanon #189, redirected from
  discard: Michal proposed the mechanism instead of the note — `./iw kanon/lesson`, which
  resolves the file by the rule, always appends, and validates the five-field schema
- the dashboard runs the iw-cli IW_HOME names → CLAUDE.md, Dashboard development
- two dead-click bugs no server-side test could see → .claude/skills/dashboard-htmx-controls
  and kanon note #190
- the dashboard has no Forgejo case → fixed-at-source (2fe3fe2); the half that is not fixed —
  a permanent failure rendering as a pending one — went to the tracker's PARKED list, which
  sl-close flushes into the effort map, rather than competing with a tracker issue
- HTML escaping is not JSON escaping → the same project skill, and kanon note #191
- a clean exit is not a promise that the work was done → fixed-at-source (a5c712b), and the
  contract now says so itself: CommandResult.cancelled (4) tells a decline from a removal, so
  exit 0 means the worktree is gone

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

mph referenced this pull request from a commit 2026-08-27 11:41:27 +00:00

workflow(sl): close 08-the-cleanup-gets-done (flush parked items)

mph added 1 commit 2026-08-27 11:41:27 +00:00

workflow(sl): close 08-the-cleanup-gets-done (flush parked items) ... e24ea82415

Tracker closed, review-state at awaiting_review against PR #470.

Map: remove-worktree marked done; the unfixed half of the Forgejo finding
becomes the candidate a-card-says-why-it-cannot-say; the-board-says-who-may-look
records what slice 08 shipped behind it, including that registration — not the
view — is the trust boundary; eight asides land under Parked.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

mph added 1 commit 2026-08-27 18:52:27 +00:00

Merge remote-tracking branch 'origin/main' into dashboard-control-plane ... 811feec24d

# Conflicts:
#	core/commands/CommandEnv.scala
#	core/commands/LiveCommandEnv.scala
#	core/test/fixtures/FakeCommandEnv.scala

mph added the

contract

label 2026-08-27 18:54:17 +00:00

mph added 1 commit 2026-08-27 19:07:58 +00:00

workflow(sl): restore the card after ci-gate misread a re-run ... 2475c34469

CI is green on 811feec — all six checks, contract included — and the forge's
combined status for that commit says so. `iw ci-gate` reported it failed and
wrote ci_failed into the card: a commit's status list is append-only, and the
gate found the failure rows from the first run, which a network-unreachable
runner had produced, still sitting below the success rows from the re-run.

Card corrected by hand after confirming the combined status. The gate defect is
recorded as a lesson, pending triage.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

mph referenced this pull request 2026-08-27 19:12:27 +00:00

iw ci-gate reads a commit's whole status history, so a re-run can never go green #472

mph added 1 commit 2026-08-27 19:13:29 +00:00

workflow: triage the ci-gate lesson found after the close ... a6ebc1b4ff

Promoted:
- iw ci-gate reads a commit's whole status history → IW-472

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

mph added 1 commit 2026-08-27 19:26:21 +00:00

workflow(sl): record the gate's own green for 08-the-cleanup-gets-done ... 126376daa5

ci-gate agrees on a6ebc1b, whose status history holds one run. That it agrees
here and not on 811feec is the evidence in IW-472.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bfg3hyasiGoVrKpgaBjrqJ

mph merged commit ee9bfc9a2a into main 2026-08-27 19:39:06 +00:00

mph referenced this pull request from a commit 2026-08-27 19:39:08 +00:00

Merge pull request 'Slice 08: the cleanup gets done — remove a worktree from the browser, and it stays gone' (#470) from dashboard-control-plane into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

agent-ready

  

bug

Something isn't working

  

contract

Run the tool-contract suite on this PR

  

documentation

Improvements or additions to documentation

  

duplicate

This issue or pull request already exists

  

enhancement

New feature or request

  

good first issue

Good for newcomers

  

help wanted

Extra attention is needed

  

invalid

This doesn't seem right

  

needs-human

  

needs-input

Intake asked the human a question on the issue; waiting for the answer

  

question

Further information is requested

  

wontfix

This will not be worked on

No labels

agent-ready

bug

contract

documentation

duplicate

enhancement

good first issue

help wanted

invalid

needs-human

needs-input

question

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

iterative-works/iw-cli!470

No description provided.