disinto/supervisor/best-practices/disk.md
johba 77cb4c4643 refactor: rename factory/ → supervisor/, factory-poll → supervisor-poll
The supervisor agent was confusingly named "factory" (same as the
project). Rename directory, script, log, lock, status, and escalation
files. Update all references across scripts and docs.

FACTORY_ROOT env var unchanged (refers to project root, not agent).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-15 18:06:25 +01:00

1.3 KiB

Disk Best Practices

Safe Fixes

  • Docker cleanup: sudo docker system prune -f (keeps images, removes stopped containers + dangling layers)
  • Truncate supervisor logs >5MB: truncate -s 0 <file>
  • Remove stale worktrees: check /tmp/${PROJECT_NAME}-worktree-*, only if dev-agent not running on them
  • Woodpecker log_entries: DELETE FROM log_entries WHERE id < (SELECT max(id) - 100000 FROM log_entries); then VACUUM;
  • Node module caches in worktrees: rm -rf /tmp/${PROJECT_NAME}-worktree-*/node_modules/
  • Git garbage collection: cd $PROJECT_REPO_ROOT && git gc --prune=now

Dangerous (escalate)

  • docker system prune -a --volumes — deletes ALL images including CI build cache
  • Deleting anything in $PROJECT_REPO_ROOT/ that's tracked by git
  • Truncating Woodpecker DB tables other than log_entries

Known Disk Hogs

  • Woodpecker log_entries table: grows to 5GB+. Truncate periodically.
  • Docker overlay layers: survive normal prune. -a variant kills everything.
  • Git worktrees in /tmp: accumulate node_modules, build artifacts
  • Forge cache in ~/.foundry/cache/: can grow large with many compilations

Lessons Learned

  • After truncating log_entries, run VACUUM FULL (reclaims actual disk space)
  • Docker ghost overlay layers need prune -a but that kills CI images — only do this if truly desperate