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>
1.3 KiB
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);thenVACUUM; - 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_entriestable: grows to 5GB+. Truncate periodically. - Docker overlay layers: survive normal prune.
-avariant 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 -abut that kills CI images — only do this if truly desperate