Vault Git State
Consolidated. This note's findings now live in
../MIN-STUDIES.md§12. The original is kept for its measurements; do not re-derive from it.
The vault's git state — measured, and safe
Sol found it while verifying the untouched-list: "git status in the vault
reads 2,839 lines. A repository in that state cannot answer 'is anything stale?'"
He is right about the problem, and the cause is a mass move that was never committed. I verified the safety of it, because that is the question that matters first.
1. ✅ The safety verdict: nothing is lost
| Check | Measured |
|---|---|
git status --short lines | 2,841 |
| tracked-but-deleted in worktree | 2,669 |
| staged | 0 |
| untracked (new) | 143 |
| files in HEAD | 3,078 |
| deleted files NOT in HEAD | 0 |
Every one of the 2,669 is in HEAD. Verified per file with
git cat-file -e HEAD:<path> — zero misses. So every deletion is recoverable
with one command:
git checkout HEAD -- <path> # one file
git checkout HEAD -- <dir> # a directory
This is the ' D' status, not 'D ' — deleted in the worktree, still
committed. The content is in history and always was.
2. What actually happened: a move, not a deletion
The files were relocated. The old path is gone from disk; the same content exists under a new one:
Docs/solos/Daily Briefings/2026-07-31.html
→ Docs/SolOSV3/05-archive/reference-tree/SolOS Legacy/solos/Daily Briefings/2026-07-31.html ✅ exists
"SolOS (legacy reference only)/" (in HEAD)
→ Docs/SolOSV3/05-archive/reference-tree/SolOS Legacy/ (on disk) ✅ renamed
So it is a rename the index has not been told about — git sees delete here,
untracked there, which is exactly what git status reports as 2,669 deletions.
The scale: 1,032 mapped by the obvious prefix rewrite; the rest live under
other renames (Docs/Pulse/ → Pulse/, Docs/research/ → legacy, …). Spot-checks
confirm the content exists.
76 files have no same-named copy on disk — and they are copilot config and
tooling (Docs/copilot/skills/*, copilot/skills/*, .obsidian/graph.json,
AGENTS.md). All 76 are still in HEAD, so they are recoverable regardless.
3. 🔴 The real finding — and it is Sol's, sharpened
The problem is not the deletions. It is that the repository cannot be read.
"A repository in that state cannot answer 'is anything stale?' — which is the question a cleanup exists to serve."
And it is worse than a tidiness issue: the vault has two remotes, and one of them points at the production host:
origin https://github.com/youngframeworks/solos-vault.git
prod ubuntu@161.33.71.67:/home/ubuntu/.solos/docs/vault
So the moment anyone runs git add -A && git commit && git push, a 2,669-file
restructure — which no one has reviewed as a change — propagates to production.
That is the vault's own rule firing in the worst way: "a deletion committed here propagates there." The deletions are recoverable here and would be destructive there.
4. What must NOT happen, and what should
| ❌ Must not | Why |
|---|---|
git add -A on the vault | commits 2,669 unreviewed deletions and 143 unreviewed additions |
git checkout HEAD -- . to "clean up" | reverts the move — the new Docs/SolOSV3/05-archive/reference-tree/SolOS Legacy/ layout is what is on disk and what the tree uses |
| Any push before a review | prod is the production host |
| ✅ Should | Why |
|---|---|
Commit the move as a move — git add -A is correct once the change is reviewed as the restructure it is | it records renames, so --follow survives and history is legible |
| Verify no content was dropped in the move — diff the HEAD file list against the disk file list | the 76 with no disk copy should be confirmed intentional |
Decide the prod push separately, before committing | a committed restructure propagates; that decision is Young's |
The first action is not a git command — it is a review. The change is a restructure; it needs to be read as one.
5. Why this is now an owned concern
Sol's recommendation, adopted: git hygiene becomes an owned operational item.
The vault and .solos both need it, and .solos's remote cannot be set up
meaningfully while the vault's own state is illegible — which is exactly the
sequencing Sol named.
| Item | State |
|---|---|
.solos | 7 commits, 16 tracked, 0 remotes — needs a destination |
| the vault | 2,841 status lines, 2,669 uncommitted deletions, 2 remotes including production |
| Owner | 🔴 needs naming — it is an operational concern, and it is not in any stage |
Recommended: Mira (operational, and it is a data-safety concern), with the
prod push decision reserved to Young.
6. What this changes in the plan
Nothing in the stages changes. Two things are added:
- Stage 9 (backup/recovery) gains a real subject — the vault is a store V3 depends on, and it is one command from propagating an unreviewed restructure to production.
- The
.solosremote (9.1) is correctly sequenced after the vault review, not before — Sol's point, and it holds.
Not established
- The move was not fully mapped. 1,032 of 2,669 were traced by prefix; the rest were spot-checked, not exhaustively. A full HEAD-vs-disk diff is the review action above, and it has not been run.
- The 76 no-disk-copy files were categorised by path, not read. They are in HEAD, so recoverable either way.
- Nothing was committed or pushed. The state is exactly as found.
prodwas not contacted. LAB rules put the production host off-limits to Min.