File organization audit

Host: prabhashs-g10 Audit time: 2026-08-29 17:56 UTC Scope: metadata-only review of the home directory, selected directory sizes, names, permissions, repository roots, generated directories, and container storage. No user files were changed.

Executive summary

The home directory is usable but has three overlapping organizational systems: active repositories under ~/Projects, older repositories and mirrors under ~/Documents, and project-generated data directly under ~. The highest-value improvement is to make ~/Projects/{Work,Personal} the single home for source trees, put archives/mirrors in one explicit archive area, and keep generated data out of the home-directory root.

Storage pressure is meaningful: the 466 GiB filesystem is 84% used, with 72 GiB available. The largest clearly identified consumers are development/container state, browser/editor profiles, package caches, and repeated or historical project trees. This is not primarily a Downloads problem; ~/Downloads is only 100 KiB.

Priority findings

1. Establish one authoritative source-code hierarchy

~/Projects already has the strongest structure:

  • ~/Projects/Work — at least 25 GiB from children that completed scanning
  • ~/Projects/Personal — 8.8 GiB
  • ~/Projects/Work/p8 — 17 GiB
  • ~/Projects/Work/P8 — 1.4 GiB
  • ~/Projects/Work/p8.workspaces — 685 MiB
  • ~/Projects/Work/p8.worktrees — scan timed out
  • ~/Projects/Work/p8-knowledge-agent-old — 182 MiB

Meanwhile, ~/Documents still contains many source repositories and repository-like stores:

  • p8.git — 7.6 GiB
  • p8-old — 6.2 GiB, including node_modules, logs, IDE state, and a Git repository
  • ManagementServer — 956 MiB
  • LiteWebAgent — 653 MiB
  • B.Free-Chrome-Extension.git — 592 MiB
  • dotfiles — 319 MiB
  • B.Free — at least 219 MiB
  • many smaller repositories such as FileServer, FileServerOld, CSE, and tutorial/test projects

Opportunity: treat ~/Projects/{Work,Personal} as authoritative. Give mirrors, bare repositories, retired projects, and snapshots an explicit separate home such as ~/Archive/repos or ~/Backups/git. This avoids having active, old, and mirror copies intermixed with ordinary documents.

Before any future move or deletion, identify which P8 tree is canonical and whether .git-suffixed directories are intentional mirrors. Similar names (p8, P8, p8-old, p8.git, p8.workspaces, and multiple worktrees) are the largest ambiguity in the current layout.

2. Separate source from generated and reproducible data

Under ~/Documents and ~/Projects, the scan found:

Generated directory Count
target 1,875
node_modules 1,571
__pycache__ 535
build 272
dist 86
.gradle 27
coverage 16
.venv / venv 7
.terraform 6
.idea 5

These are likely the main reason project scans are slow. They also make archives such as p8-old much larger and less portable than source-only archives.

Opportunity: retain generated directories only in active checkouts, keep them ignored by Git, and archive source/history rather than dependency and build output. A periodic review can use each ecosystem’s own safe cache/clean commands rather than broad filesystem deletion.

3. Move loose work artifacts out of the home root

The home root contains 16 related latency artifacts (PNG, CSV, and JSON), one timestamped MP4, message.bin, whitelist.txt, and seven zero-byte files with malformed/non-text names. The latency files form one coherent experiment but are not grouped.

Opportunity: use a small destination hierarchy such as ~/Projects/Work/<project>/artifacts/<date> or ~/Documents/experiments/<topic>/<date>. Put recordings under one recording location. Review the seven malformed zero-byte files as probable accidental creations.

The top-level source/config symlinks into ~/Documents/dotfiles are coherent and should remain distinct from accidental loose files.

4. Consolidate recordings and screenshots

Recordings currently appear in four places:

  • ~/Videos — 1.9 GiB
  • ~/Videos/OBS
  • ~/Videos/Recordings
  • ~/recordings — 3.7 MiB
  • one MP4 directly in ~

~/Pictures/screenshots contains 390 files (88.7 MiB by logical file sizes; its directory occupies more on disk). Most names are timestamped, so they can be grouped by year/month without renaming.

Opportunity: choose ~/Videos/Recordings/{OBS,screen,...} as the sole recording hierarchy. Add year/month folders for screenshots only if browsing the current flat set is cumbersome. The screenshot set is organizational clutter, not a major storage risk.

5. Put generated logs and indexes under state/cache locations

Several generated collections live directly under ~:

  • ~/p8_build_info — 199 MiB; 356 build logs totaling 197.3 MiB
  • ~/js-tags — 489 MiB; one dependency tag file is 458.6 MiB
  • ~/go — 2.9 GiB, mainly normal Go workspace/cache/tool data
  • ~/logs — small, but creates another log location

Opportunity: classify these explicitly:

  • disposable indexes/tags → ~/.cache/<tool>
  • durable application state → ~/.local/state/<tool> or ~/.local/share/<tool>
  • human-reviewed project artifacts → inside that project’s artifact directory
  • logs → ~/.local/state/<tool>/log, with an explicit retention policy

The P8 build-log collection is an especially clear candidate for retention by age or count. ~/js-tags should be treated as reproducible cache if it can be regenerated.

6. Review large application state with application-aware tools

Large hidden/runtime areas include:

Path Approximate size
~/.local 24 GiB in the bounded scan
~/.local/share/containers 21 GiB in the bounded scan; storage traversal reported about 29 GiB
~/.config 17 GiB
~/.gradle 7.8 GiB
~/.npm 7.0 GiB
~/.cache 4.9 GiB
~/.rustup 3.4 GiB
~/snap 2.6 GiB
~/.m2 2.1 GiB
~/.pi 1.8 GiB
~/.cargo 1.6 GiB

Largest application profiles/caches:

  • ~/.config/google-chrome — 7.1 GiB
  • ~/.config/Code — 4.5 GiB
  • ~/.cache/net.imput.helium — 3.4 GiB
  • ~/.config/net.imput.helium — 2.1 GiB
  • ~/.config/Antigravity — 811 MiB
  • ~/.config/Claude — 590 MiB
  • ~/.cache/go-build — 907 MiB
  • ~/.cache/jdtls — 472 MiB

These paths mix genuine settings with caches, browser profiles, extension state, and databases. Do not reorganize them manually. Use browser/editor/package-manager/container commands to inspect and prune disposable state while preserving profiles and credentials.

Container storage deserves separate attention. podman system df failed because one mounted layer has stale file handles, and direct traversal hit stale handles and permission-protected volume data. Resolve that storage-health issue before attempting container cleanup; named volumes may contain durable databases.

7. Consolidate secrets and tighten their boundary

Sensitive-looking material is spread across ~, ~/Documents, and ~/Documents/keypairs:

  • ~/.env
  • three GitHub recovery-code text files in ~/Documents
  • ~/Documents/keypairs/GitHub-PATs.txt
  • two PEM private keys

The recovery-code/PAT text files and ~/.env are group-readable and world-readable (0664). One PEM is correctly 0400; the other is 0600.

Opportunity: make one encrypted credential system authoritative (the existing password store is a natural candidate), document where non-password private keys belong, remove plaintext duplicates only after verification, and restrict permissions. This is both organization and risk reduction. Do not bulk-move keys without updating callers and backups.

8. Remove lifecycle debris after verification

Small temporary/test directories are visible directly under ~, including .pi-worktree-*, .shellcheck.*, .snooze-test.*, .state-test.*, .test-runit.*, .tmp-*, .pkg.*, and .grafana-provision.*. Together they are small, but they create noise. Many broken symlinks found by the scan are inside these test directories, reinforcing that they are incomplete test artifacts.

Other review candidates:

  • ~/Projects/.git/index.lock is an empty lock dated 2026-08-11; verify no Git process relies on it.
  • ~/.config/nvim.backup.20251005100451
  • ~/.xinitrc.bak
  • ~/.ssh/known_hosts.old
  • ~/dotfiles-backups, currently empty
  • standard empty folders such as Desktop, Music, Public, Sync, and Templates; these are harmless and may be retained for XDG compatibility

Suggested target layout

A small, explicit hierarchy is enough:

~/Projects/
  Work/                 active work repositories
  Personal/             active personal repositories
~/Documents/            human documents, PDFs, exports
~/Archive/
  repos/                retired source snapshots
  git-mirrors/          bare mirrors and bundles
  recordings/           only if recordings are archival
~/Videos/Recordings/     active/raw recordings
~/Pictures/screenshots/  screenshots, optionally YYYY/MM
~/.cache/                reproducible indexes and build caches
~/.local/state/          logs and mutable tool state
~/.local/share/          durable application data

Avoid adding an elaborate taxonomy. The key rules are: one canonical checkout per active project, archives clearly labeled, generated data outside the home root, and secrets in one protected system.

Audit limitations