Regels

De echte angst is niet verspilde ruimte, maar verloren werk. Daar zijn de regels van Devbroom voor, en geen ervan is een instelling.

Scannen leest alleen

Scannen verandert geen enkel bestand. Tenzij je in Automatisch onderhoud een regel op “Zelf uitvoeren” zet, wordt niets aangeraakt wat je niet in de voorvertoning hebt gezien en bevestigd.

Elk oordeel komt met een reden

Geen item is Klaar of Geblokkeerd zonder reden. De redenen van elk oordeel staan naast het item, en op de opdrachtregel met --details.

Geblokkeerd en Onbekend kun je niet selecteren

Dit is een grens, geen voorkeur. Items met Nakijken worden alleen opgeruimd met “Toch meenemen”; op de opdrachtregel is dat --include-review, en dat vraagt om bevestiging in de terminal.

Vlak voor het verwijderen opnieuw gecontroleerd

Als je op Opruimen drukt, wordt elk item opnieuw gecontroleerd tegen de processen die op dat moment draaien. Een item waarvan het oordeel of de inhoud sinds de scan veranderd is, blijft staan, en je hoort waarom het is overgeslagen.

Eerst de Prullenmand

De Prullenmand is de standaard, en elk item kun je terugzetten via Geschiedenis. Definitief verwijderen is een aparte keuze, die je bevestigt door de knop ingedrukt te houden; je organisatie kan het uitzetten. Ruimte die naar de Prullenmand is verplaatst, telt pas als vrijgemaakt als je de Prullenmand leegt.

Worktrees: nooit --force

  • Een worktree met niet-gecommitte wijzigingen, of niet-gevolgde of gestagede bestanden, is Geblokkeerd. Git verwijdert hem niet zonder --force; Devbroom gebruikt nooit --force.
  • Genegeerde bestanden maken het Nakijken, omdat git worktree remove ze zonder te vragen verwijdert.
  • Niet-gepushte commits op een branch blijven bestaan als de worktree wordt verwijderd; op een detached HEAD zou dat niet zo zijn. Daarom bewaart Devbroom de HEAD vóór het verwijderen onder refs/devbroom/removed; lukt dat niet, dan verwijdert het niet.
  • Er zijn maar drie acties voor worktrees: verwijderen (remove), opschonen (prune) en repareren (repair).

Handen af van lopend werk

Als er een agentsessie in die map of de bovenliggende map draait, er een proces vanuit draait of een bestand erin geopend is, is het item Geblokkeerd. Bij buildmappen maakt een sessie in de bovenliggende map het Nakijken.

Devbroom raakt de processen van een actieve agentsessie nooit aan. Processen die agents achterlieten worden alleen gevraagd te stoppen als jij dat zegt, en pas na een nieuwe controle; nooit systeemprocessen of processen van andere gebruikers.

Een naam is niet genoeg

De naam van een map alleen is geen bewijs:

Map Om Klaar te zijn
node_modules Een package.json ernaast
.next Een Next.js-configuratie of package.json ernaast
.turbo Een turbo.json of package.json ernaast
target De markering van Cargo erin (CACHEDIR.TAG)
.venv Een pyvenv.cfg erin
DerivedData Bestanden van Xcode erin
dist, build, vendor Een projectbestand ernaast, en een buildscript dat het maakt

Zonder markering blijft de map Nakijken. Het moet ook een map zijn die git negeert, zonder bestand erin dat git volgt.

Echte grootte

Ruimte die via hard links en APFS-klonen met andere mappen gedeeld wordt (zoals pnpm doet), telt niet mee. Het getal dat je ziet is wat verwijderen vrijmaakt. Symbolische links worden niet gevolgd, en gekoppelde volumes worden overgeslagen.

De eigen weg van de agent

Databases en inloggegevens van agents worden nooit aangeraakt. Als een agent een eigen opruimopdracht heeft, gebeurt het zo of wordt het je zo getoond. De geschiedenis van Claude Code wordt verwijderd met claude purge of gearchiveerd: de gesprekken worden eerst naar een archief in de map van Devbroom geschreven en vergeleken met de originelen, en pas daarna naar de Prullenmand verplaatst; het geheugen van het project (memory/) blijft staan, en het archief kun je weer openen via Geschiedenis. Voor Codex-sessies wordt codex delete getoond. Sessies van andere agents worden alleen gelezen.

Alles op je Mac

Geen account, geen telemetrie; er wordt niets over jou verstuurd. De app controleert op updates; als je een Pro-licentie invoert, activeert hij die eenmalig en controleert hem ongeveer eens per maand stilletjes opnieuw (alleen de licentiesleutel en de naam van je Mac). Zonder licentie is de updatecontrole het enige netwerkverzoek. Uit sessielogs haalt hij alleen tokenaantallen en modelnamen; zoeken in sessies leest de logs op dat moment, bewaart geen index of log en verbergt tekenreeksen die op geheimen lijken in fragmenten. Details op de pagina Privacy.

Laatst bijgewerkt: 7 oktober 2026