Hygiene cleanup summary can label candidates safe-to-remove before fresh safety probes

[chubes4]

Problem

workspace hygiene --format=json can report explicit cleanup-eligible rows as safe_to_remove_now / would_remove based on cheap inventory, but the recommended bounded apply immediately blocks those same rows after fresh dirty/unpushed probes.

Evidence

Final hygiene after active-no-signal cleanup reported:

• cleanup.summary.would_remove: 5
• cleanup.summary.cleanup_buckets.safe_to_remove_now: 5
• bounded_cleanup_eligible_apply.apply_command: studio wp datamachine-code workspace worktree bounded-cleanup-eligible-apply --limit=5

Running that exact apply command removed nothing:

{
  "processed": 5,
  "removed": 0,
  "bytes_reclaimed": 0,
  "blockers": {
    "dirty_worktree": { "count": 3 },
    "remove_failed": { "count": 1 },
    "unpushed_commits": { "count": 1 }
  }
}

Examples included:

• blocks-engine@fix-raw-html-canvas-diagnostic blocked by dirty worktree
• studio-native@cook-codebox-browser-sdk-boundary-20260624 blocked by dirty worktree
• wp-codebox@add-fuzz-runner-capabilities blocked by dirty worktree
• homeboy@cook-command-contract-single-source blocked by remove failure / dirty files
• homeboy@cook-lab-loop-preflight-20260619b blocked by one unpushed commit

Expected

Hygiene should avoid calling cheap-inventory candidates safe_to_remove_now unless it has run the same fresh safety probes the apply path will run. Suggested shape:

• Use a softer label like explicit_cleanup_candidates for cheap inventory.
• Reserve safe_to_remove_now / would_remove for probed rows.
• Make the apply command wording clear that candidates may still be blocked by fresh probes.

AI assistance

• AI assistance: Yes
• Tool(s): openai/gpt-5.5 via OpenCode
• Used for: Capturing observed cleanup output and drafting the issue.