Problem
While running workspace artifact cleanup after old worktree cleanup, DMC generated dry-run artifact cleanup rows that could not be applied immediately afterward because apply-plan revalidation reported a branch mismatch.
Example command flow:
studio wp datamachine-code workspace worktree cleanup-artifacts --dry-run --limit=100 --offset=0 --format=json > /wordpress/tmp/dmc-artifact-cleanup-second-0.json
studio wp datamachine-code workspace worktree cleanup-artifacts --apply-plan=/wordpress/tmp/dmc-artifact-cleanup-second-0.json --force --format=json
Apply skipped rows like:
{
"handle": "data-machine@fix-execute-workflow-system-task-settings",
"reason": "planned artifact cleanup row no longer matches current state: branch"
}
Other observed handles with the same branch mismatch:
block-format-bridge@refresh-h2bc-card-label-spans
data-machine-frontend-chat@deploy-public-audience
data-machine@adopt-agents-memory-contracts
data-machine@fix-core-bundle-artifact-apply-v2
data-machine@fix-execute-workflow-system-task-settings
data-machine@fix-non-handler-completion-assertions
Expected behavior
A dry-run plan produced by cleanup-artifacts --dry-run should be immediately applicable through --apply-plan if the worktree path and artifact path still match.
If branch identity is only a display/lifecycle field and can legitimately differ between inventory sources, artifact apply-plan should either normalize it consistently in dry-run and apply, or compare a stable identity such as handle/path plus artifact path.
Actual behavior
The dry-run plan reports valid reconstructable artifacts, but apply-plan rejects them as artifact_plan_mismatch due to branch only.
This leaves reconstructable artifacts behind unless an operator bypasses DMC and manually deletes paths, which we should avoid.
Cleanup context
This came up after reclaiming disk on intelligence-chubes4:
- DMC cleanup-eligible worktree cleanup removed 70 worktrees and reclaimed ~176G.
- Artifact cleanup removed a large amount of
node_modules/vendor artifacts through reviewed plans.
- Remaining DMC-visible artifact candidates included several rows blocked only by this branch mismatch.
Problem
While running workspace artifact cleanup after old worktree cleanup, DMC generated dry-run artifact cleanup rows that could not be applied immediately afterward because apply-plan revalidation reported a
branchmismatch.Example command flow:
studio wp datamachine-code workspace worktree cleanup-artifacts --dry-run --limit=100 --offset=0 --format=json > /wordpress/tmp/dmc-artifact-cleanup-second-0.json studio wp datamachine-code workspace worktree cleanup-artifacts --apply-plan=/wordpress/tmp/dmc-artifact-cleanup-second-0.json --force --format=jsonApply skipped rows like:
{ "handle": "data-machine@fix-execute-workflow-system-task-settings", "reason": "planned artifact cleanup row no longer matches current state: branch" }Other observed handles with the same branch mismatch:
block-format-bridge@refresh-h2bc-card-label-spansdata-machine-frontend-chat@deploy-public-audiencedata-machine@adopt-agents-memory-contractsdata-machine@fix-core-bundle-artifact-apply-v2data-machine@fix-execute-workflow-system-task-settingsdata-machine@fix-non-handler-completion-assertionsExpected behavior
A dry-run plan produced by
cleanup-artifacts --dry-runshould be immediately applicable through--apply-planif the worktree path and artifact path still match.If branch identity is only a display/lifecycle field and can legitimately differ between inventory sources, artifact apply-plan should either normalize it consistently in dry-run and apply, or compare a stable identity such as handle/path plus artifact path.
Actual behavior
The dry-run plan reports valid reconstructable artifacts, but apply-plan rejects them as
artifact_plan_mismatchdue tobranchonly.This leaves reconstructable artifacts behind unless an operator bypasses DMC and manually deletes paths, which we should avoid.
Cleanup context
This came up after reclaiming disk on
intelligence-chubes4:node_modules/vendorartifacts through reviewed plans.