Housekeeping: 12 empty scaffold dirs need code add or deletion (not a .musekeep bug)
Corrected finding
Original title/premise was wrong -- filed before verifying, corrected after testing.
12 empty scaffold directories are sitting untracked in the working tree (.claude/skills/, .cursor/skills/, .overseer/policy/, completions/, docs/architecture/, docs/demo/, docs/protocol/, muse/cli/commands/plumbing/, muse/mcp/namespaces/, muse/plugins/knowtation/, out/, tools/omzsh-plugin/).
Initially assumed this meant muse can't track empty directories without a
.musekeep marker (mirroring git's .gitkeep convention). Verified this
is wrong on both counts:
muse code add out/(no.musekeeppresent) staged it fine as{"path": "out", "mode": "new dir"}-- empty directories are first-class, content-addressed objects (EMPTY_DIR_OID) that can be explicitly staged and committed with zero marker files. Confirmed via commit history:f992d46a7 feat(status): first-class empty directory tracking,3f4636765 refactor: directories are proper content-addressed objects (EMPTY_DIR_OID)..musekeep(domain.py, core/snapshot.py, plugins/code/plugin.py) governs a different, narrower thing: passive walk-based auto-discovery during a snapshot diff, which is deliberately conservative (an unmarked empty dir found on disk isn't auto-picked-up as "added" -- see tests/test_directories_feature.py's TestEmptyDirectoryGhost, guarding against noise from arbitrary build/temp dirs). It has nothing to do with whether an explicitmuse code add <dir>works -- that path never needed a marker.
No muse regression, no missing feature. The actual action item is pure housekeeping for this repo: each of the 12 directories needs one of two things --
- If it represents real, intentional scaffolding for planned work
(
muse/plugins/knowtation/,muse/mcp/namespaces/,muse/cli/commands/plumbing/look like they might be this), runmuse code add <dir>to actually track it, so its existence survives a fresh clone and its intent is visible in history. - If it's accidental cruft from a tool/installer that created structure it never populated, delete it.
Next step
Go through the 12 directories one at a time with whoever/whatever created them and make that call per-directory. Not urgent, not a correctness bug -- closing this out is just tidiness.
Confirmed resolved — closing.
Checked this exact ~/ecosystem/muse checkout directly: all 12 directories listed in this ticket no longer exist on disk. muse status --json reports clean ("untracked": []), and muse ls-files confirms zero tracked entries for any of the 12 paths — none were code added as intentional scaffolding, so all 12 were resolved as cruft (deleted) rather than tracked.
Can't personally verify each was reviewed one-by-one as the "next step" suggested vs. a bulk cleanup, but the end state is exactly right: no leftover untracked directories, nothing silently baked into history as phantom scaffolding.
Root cause (#95) is now fixed and shipped, so this class of leftover won't recur from muse switch/merge/pull/rebase/etc. going forward.
Root cause confirmed and filed separately: #95 (muse switch leaves empty directories behind when their last file is removed). These 12 directories are leftovers from checking out review/216-branchmeta (real OverseerKit install, commit 05ad6bb82) for MP #12's review, then switching back to dev -- not accidental cruft, not a .musekeep issue. Safe to delete locally per #95's repro; the actual fix belongs in muse switch's working-tree sync, tracked there.