dl --purge deletes workspaces devlaunch never created

[blooop]

Question

dl --purge deletes workspaces devlaunch never created and knows nothing about.
What should "mine" mean, and what should it do with the rest?

Graduated from the e2e blast-radius build ticket,
which explicitly scoped itself to making the test suite safe and left this
open. Its metal evidence: run unscoped, --purge would have deleted
pythontemplate — a workspace on this host that devlaunch did not create, does
not track, and cannot recreate.

purge_all_data() iterates everything list_workspaces() returns
(devlaunch/dl.py:335-339), and list_workspaces() is a straight read of
devpod list. devpod's namespace is shared with every other way a person makes a
workspace — devpod up by hand, another tool, an older devlaunch. --purge
treats all of it as devlaunch's to destroy.

The ownership predicate already exists, unused. This is what makes the ticket
worth doing rather than merely worth noting: workspace ids derive from
(owner, repo, ref) through WorkspaceId (devlaunch/workspace_id.py:204,219),
and devlaunch already records the ones it created in metadata.json. "Mine" is
answerable from state devlaunch already keeps — no new concept, which is exactly
what principle 2 wants.

The open sub-question, and the real decision here: what should --purge do
about workspaces it finds but does not recognise? Candidates, judge them:

• Delete only recognised ones, silently ignore the rest. Safe, but a user who
  expected a clean slate is surprised by what survives.
• Delete only recognised ones and report the others by name. Costs one line
  of output and removes the surprise.
• Keep today's behaviour behind an explicit opt-in flag for people who really do
  want everything.

Principle 3 is live here: if "recognised" and "unrecognised" are two different
things --purge can do, that is a distinction the code should be able to state,
not something inferred from a lookup miss at the point of deletion.

This is a wayfinder:build ticket: go through /tdd.

Test-first, and mind the shape of the red test — the same trap
#103 hit. A test whose red state
deletes real workspaces is not acceptable. #103's merged seam (a per-run scoped
DEVPOD_HOME/DEVPOD_SSH_CONFIG) should make an honest end-to-end test of this
safe to write; prefer that over stubbing if it holds. The red test wants to be:
a scoped namespace containing one workspace devlaunch created and one it did not,
--purge, and the unrecognised one still standing.

Blocked on #103 — it supplies the safe harness this ticket's tests need.

Relation to the destination. This is not strictly about developing in a
devcontainer. It is in scope because the map's own work surfaced it, because a
nested daemon hides it (inside a container every workspace is devlaunch's, so
the bug becomes invisible exactly where developers will now be working), and
because leaving a known destructive defect behind while building the thing that
conceals it is the opposite of principle 1.

[blooop]

breadcrumb: input from PR #106's review, which this ticket should absorb rather than have its own ticket: CLAUDE.md's scratch-XDG paragraph is a demonstrably incomplete safeguard for the manual workflow it recommends. #106 makes the test suite safe; a human following CLAUDE.md and running dl-next --purge by hand is still exposed, because XDG_* does not scope devpod list.

Two ways to close that gap, and this ticket should pick one rather than both (principle 2): teach --purge an ownership predicate, after which the manual workflow is safe without the human doing anything — or amend CLAUDE.md to name DEVPOD_HOME/DEVPOD_SSH_CONFIG. The first subsumes the second. Note the qualifier below before relying on the second.

Qualifier established by the same review: DEVPOD_SSH_CONFIG is subcommand-scoped — registered on devpod up only (up: 1, ssh: 0, delete: 0, stop: 0). up is the writer, so the ssh-config harm is covered, but devpod ssh/delete still resolve the real ~/.ssh/config.

[blooop]

breadcrumb: blocked on #120 — same function, and an ordering that makes this ticket simpler. Both rework the list_workspaces → purge_all_data path in dl.py; building them in parallel guarantees a conflict for no gain. #120 makes the list trustworthy (unreadable stops being indistinguishable from empty), which is the assumption this ticket wants to build ownership filtering on top of. Landing them the other way round would mean writing an ownership predicate over a list that might silently be [] because devpod failed.

[blooop]

breadcrumb: stage → build, and the predicate is decided. Working in a
worktree off main at b09d37d (which carries #120's UnreadableWorkspaceList);
the primary checkout is untouched.

"Mine" is: the workspace's source is inside devlaunch's cache directory. Not
metadata.json, which is what this ticket proposed. Both candidates were checked
against the same host, read-only, and the check is what moved the choice:

• devpod list --output json here returns 6 workspaces. Four are sourced from
  ~/.cache/devlaunch/repos/<owner>/<repo>/<id> (bencher-test1-pipagito,
  bencher-main-kivagede, devlaunch-main-zovomobo, devlaunch-t1-vebilote);
  two are sourced from the developer's own directories — pythontemplate
  (~/projects/python_template, the workspace The e2e suite can delete a developer's real devpod workspaces #103 measured --purge would have
  eaten) and devlaunch (~/projects/devlaunch, a plain devpod up of the
  primary checkout).
• metadata.json holds 39 worktree records for those 6 live workspaces. It is
  an append-mostly log that goes stale; nothing prunes it. On the live six the two
  predicates agree exactly — same four — so the choice costs nothing in
  accuracy and is settled on the failure modes instead.

Three reasons the cache-source predicate wins on principle 1:

1. It is self-healing where metadata is self-erasing. metadata.json lives
   inside the cache directory --purge deletes. purge_all_data only warns
   when devpod delete fails, then removes the cache anyway — so under a
   metadata predicate one failed delete plus one successful purge produces a
   workspace that is unrecognisable forever after. A source-path check still
   matches, because devpod keeps the source string whether or not the directory
   is still there.
2. It states the actual invariant. --purge deletes devlaunch's cache; the
   workspaces it deletes are exactly the ones backed by that cache. Everything
   left standing keeps working after the purge, because its source was never
   touched. That is one sentence, and it explains the behaviour rather than
   describing it.
3. It reads no extra state. No MetadataStorage in dl.py's purge path, and
   the same XDG_CACHE_HOME scoping CLAUDE.md already teaches now genuinely
   protects a manual dl-next --purge — which is the gap Give the test suite a devpod namespace of its own #106's review graduated
   into this ticket.

Known and deliberate incompleteness, which no candidate predicate closes: dl ./path and dl <git-url> create workspaces devlaunch neither clones into its
cache nor records in metadata.json, so they are not recognised and survive a
purge. Closing that needs a new record of "workspaces I created", which is a new
concept and a schema change — principle 2 says no, and being conservative in the
destructive direction is the right way to be wrong. They are reported by name
rather than silently skipped, so the survivor is never a surprise.

Sub-question answered: delete recognised, report the rest by name. No opt-in
"delete everything" flag — that is the footgun this ticket exists to remove, and
dl <id> rm already deletes one workspace on purpose.

[blooop]

breadcrumb: build stage complete → in review. PR #129 is open on wayfinder/devlaunch-107.

Red was proved in two stages, not one. Adding the type and the predicate while
leaving purge_all_data untouched put the suite at 7 failed, 12 passed — the
predicate and value tests green, every purge test red, and one of them printing
Deleting DevPod workspace: pythontemplate in its captured output. So the
behaviour demonstrably was not there before the wiring, rather than the tests
merely failing to import.

Three mutations on the landed code, each reverted: iterating
owned.mine + owned.foreign reds all seven; a str.startswith predicate reds the
sibling-prefix and cache-root tests; dropping the source != cache_dir guard reds
the cache-root test.

Verified on metal, read-only, and it is the ticket's outcome exactly. The real
devpod list on this host run through the new code: it would delete the four
clones under ~/.cache/devlaunch/repos/... and leave pythontemplate and
devlaunch — the two sourced from the developer's own directories. dl --purge
was never run for real, no devpod delete was issued, the e2e suite was not run;
devpod list reports the same six workspaces before and after and ~/.ssh/config
is unchanged.

One residual the reviewer should weigh rather than accept. The e2e purge test
asserted the defect — that --purge deleted the workspace devpod up had just
built for it. It now asserts the survivor arm instead, which is true and needed no
new machinery. But that means the e2e suite no longer covers the deletion arm,
and the change is unrun, because this ticket's constraints forbid invoking
--purge for real or running the e2e suite here. Restoring the deletion arm costs
one more container, built from a clone under the scoped cache, on a machine where
the suite can be run. Everything the e2e test used to prove is now proven by unit
tests against a recorded listing plus the read-only host check above.

Routing to /review in fresh context.

[blooop]

breadcrumb: gate result — CI red, and it is a real datum rather than a flake. Python matrix (py310–py313), prek and GitGuardian all green at 777c942; the e2e job failed.

Two things worth recording. First: the e2e job runs pixi run test-e2e on ubuntu-latest for every PR, which I had not accounted for when I first wrote this ticket's e2e change. That changes the calculus — an e2e test here is not unverifiable, so I put the deletion arm back and the suite now builds two real workspaces differing only in where the source lives. That is the one claim a recorded listing cannot prove: that devpod records the clone path devlaunch passed as the workspace source.

Second, the failure itself. Both workspaces were built (5 workspaces created), both were listed, and dl --purge -y exited 1. The reason was truncated out of pytest's repr, and the visible tail is a quoted path pointing at the clone inside the scoped cache — consistent with shutil.rmtree failing on files the container left behind under a different uid than the runner's, which would be a pre-existing hazard in the cache half of the purge rather than anything to do with ownership filtering. Consistent with is not the same as verified, and this map's extra principle says so, so I am not acting on that reading. The assertions now carry --purge's own stdout and stderr — the same pattern test_git_status_via_ssh already uses for the same reason — and the next run will say what actually happened instead of assert 1 == 0.

Stage stays in review rather than dropping back: the two review axes were already running against b09d37d...HEAD when this landed, and nothing in the production diff has changed.

[blooop]

breadcrumb: review posted on PR #129 — changes requested, one blocking finding per axis, both now fixed at 48bb714. Neither reviewer had seen the code written; both ran against the fixed merge-base.

Spec, blocking, and it is the sharper of the two. The e2e test I had just added could not pass. theirs = "e2e-test-purge" is a substring of mine = "e2e-test-purge-mine", so assert "Deleting ... e2e-test-purge" not in stdout failed on correct output while its neighbour assert theirs in stdout passed on no evidence — one substring making one assertion impossible and the other vacuous. My own note that the change was "unrun" is exactly what let it through, and the PR body was claiming metal verification for it. Fixed by ids that do not contain one another and by matching whole lines rather than substrings.

Standards, blocking. A surviving mutant: deleting if workspace.source_type != "local": return False left all 1047 tests green. The two tests naming that branch passed for the wrong reason — a git URL and "{}" are not absolute paths, so containment already rejected them and the guard was never reached. The only shape that tests it is a git/unknown source that is an absolute path under the cache. Fixed, and the test now also asserts the same path is recognised when local so the setup cannot rot.

A process defect, and it is mine. A Standards subagent ran its mutation experiment in the shared worktree while I was committing, and 1e72e14 swept up the live mutation — deleting that same guard from the branch. It surfaced only because the subagent said so. A reviewing agent that mutates code must do it in its own worktree, and git add -A must not run while one is live. Guard restored; the full five-mutation battery is now dead on the corrected code.

Should-fixes taken: the three byte-identical spellings of devlaunch's cache directory (dl._get_cache_dir, config._get_cache_base, storage._get_default_metadata_path) now share one answer in devlaunch.xdg — they became load-bearing rather than merely duplicated the moment --purge started reading one to decide what the other two created; the partition makes one pass; the frozen-dataclass test is gone because ty already rejects the assignment.

Two declined, with reasons on the PR: the CHANGELOG prose stays in the PR body under this run's batching policy, and the symlinked-~/.cache case is left measured-not-guessed rather than getting a speculative resolve().

[blooop]

breadcrumb: metal-verified, and by CI rather than by me. The e2e job on ubuntu-latest is green at 48bb714: 8 passed, 14 skipped, 5 workspaces created: e2e-test-create, e2e-test-lifecycle, e2e-test-git, e2e-purge-devlaunchs, e2e-purge-hand-made. Two real workspaces built by real devpod up, differing only in where the source lives, and dl --purge -y deleted the clone under devlaunch's cache and left the hand-made one standing and named. That is the one claim a recorded listing could not settle — that devpod records back the clone path devlaunch handed it — and it is now settled by running the thing.

A second finding came out of that run, and it is not this ticket's. On the runner, dl --purge -y exits 1 with Error removing <cache>: [Errno 13] Permission denied: '<cache>/repos/blooop/e2e-repo/e2e-purge-devlaunchs'. The workspace half did everything right — 1 DevPod workspace(s), Leaving 1 workspace(s) devlaunch did not create: e2e-purge-hand-made, Deleting DevPod workspace: e2e-purge-devlaunchs — and then shutil.rmtree hit EACCES. The container writes into the bind-mounted clone as its own user (vscode, uid 1000 in the fixture image) while the suite runs as runner, uid 1001, and a non-owner cannot chmod the directory to empty it. Pre-existing, unrelated to ownership filtering, and not fixable from inside the process — it is the cache half of the purge, whose code this PR does not touch. It went unnoticed until now because the e2e purge test's workspace source used to be outside the cache, so no container ever wrote into the cache during a run. Graduating it to the map rather than folding it in.

Rebased onto a moved main. 19 commits landed while this was in review (including a bump to 0.0.18 and the test/docker/ deletion from #98), so I merged origin/main in and re-ran everything rather than merging a green tick earned against a stale tree: 1058 passed, 23 deselected, lint 10.00/10, and the merge touched none of my files by hand. Waiting on CI for the merged head before merging.

[blooop]

agent-decided (principle 1, long-term maintainability): dl --purge deletes only the workspaces devlaunch created, and names the rest. Landed in PR #129, merged as c2cb062. No release produced — the highest tag is still v0.0.18 on 12fb91c, the commit before this merge; the proposed CHANGELOG prose sits in the PR body for a release PR to lift.

"Mine" means: the workspace's source is a clone under devlaunch's own cache directory. Not metadata.json, which this ticket proposed. Principle 1 decided it, because on accuracy the two were a tie and the tiebreak was how each fails over time. Both were checked read-only against the same host and agree exactly on the six live workspaces. But metadata.json lives inside the directory a purge removes, and purge_all_data only warns when devpod delete fails — so one failed delete plus one successful purge would leave a workspace no later purge could ever recognise. It is also append-mostly: 39 worktree records for 6 live workspaces, 35 of them stale, nothing pruning it. A source path is read back from devpod every time and outlives the cache it names.

It also states the invariant in one sentence instead of describing a coincidence: a purge removes devlaunch's cache, and the workspaces it deletes are the ones backed by that cache. Everything left standing keeps working afterwards, because nothing a purge touches backs it.

The sub-question this ticket named — what to do with the unrecognised — was decided by principle 2: delete the recognised, report the rest by name, before the confirmation rather than after the deletions. No opt-in "delete everything anyway" flag; that is the footgun the ticket exists to remove, and dl <workspace> rm already deletes one workspace on purpose. Principle 3 got the shape: a frozen WorkspaceOwnership(mine, foreign), so the count a user approves and the set that dies read one object, and the unrecognised arm has somewhere to be named from rather than being inferred from a lookup miss.

Verify on metal, twice, and the second time was not mine. Read-only on the development host, the real devpod list through the new code deletes the four clones under ~/.cache/devlaunch/repos/ and leaves devlaunch and pythontemplate — pythontemplate being the exact workspace #103 measured an unscoped purge would have eaten. Then CI's e2e job settled the one claim a recorded listing cannot: two real workspaces built by real devpod up, differing only in where the source lives, one deleted and one left standing and named. dl --purge was never run for real on this host, no devpod delete was issued, and the six real workspaces and ~/.ssh/config are unchanged.

Known and deliberate incompleteness, named in the output, the README and the predicate's own docstring: dl ./path, dl <git-url>, and a config.toml pointing repos_dir outside the cache all produce workspaces this does not recognise, so they survive. Closing that needs a new record of "workspaces I created" — a new concept and a schema change — and erring this way costs a user one dl <workspace> rm where the other kind of mistake costs work that cannot be recovered.

Two things came out of this that outlive the ticket.

1. #131, graduated to the map. CI's e2e run found that dl --purge exits 1 and leaves the whole cache when a container has written into a clone as a different uid — pre-existing, in the half of the purge this diff does not touch, and directly relevant to Develop devlaunch inside its own devcontainer, on an isolated Docker daemon #93 because developing inside a devcontainer is exactly where host and container uids stop agreeing.
2. A process defect, and it was mine. A review subagent ran its mutation experiment in the shared worktree while I was committing, and one commit swept up the live mutation — deleting a guard from the branch. It surfaced only because the subagent said so. A reviewing agent that mutates code must do it in its own worktree, and git add -A must not run while one is live.

The review earned its place. One blocking finding per axis, both real: the e2e test I had written could not pass (one workspace id was a substring of the other, making one assertion impossible and its neighbour vacuous), and the source-type guard had a surviving mutant that left all 1047 tests green when deleted. Both fixed; the full five-mutation battery is now dead.

Also fixed on the way, because this change made it load-bearing: dl._get_cache_dir, worktree/config._get_cache_base and worktree/storage._get_default_metadata_path were three byte-identical spellings of the same directory. --purge now reads the first to decide what is devlaunch's while the other two are what put those clones on disk, so a copy that drifted would make a purge silently stop recognising its own work. They share one answer in devlaunch.xdg now, beside config_home, which exists for exactly this reason.

And the gap #106's review graduated into this ticket is closed without needing the second option that review named: the scratch XDG_CACHE_HOME recipe in AGENTS.md now genuinely protects a manual dl-next --purge, where before no XDG_* variable could scope it.