Vault restructure — verified, with three unresolved items

Verifier: Echo. Method: live probes on /home/lab/SolOS/vault and read-only probes on prod (161.33.71.67). No files were modified.

Snapshot at verification close: HEAD e50696d ("vault index: update for 2026-10-18 restructure + Nova/Echo move (Mira)"), working tree clean apart from the auto-generated Docs/Kanban/SOLOS-V3.md (regenerated by cron — expected).

1. Mira's report — CONFIRMED

Mira's claimed file counts match disk exactly:

Docs/Projects/vhost/{research 6, decisions 7, implementation 2} — confirmed (16 files incl. index). Docs/SolOS/{hosts 6, agents 4, subscriptions 0} — confirmed. The moves are real git mvs, committed, history preserved.

2. CONFLICT — vHost has two homes

• Young's taxonomy: vHost is a top-level Docs section (the tenancy platform).
• Docs/vHost/ exists — but holds only a stub index.md, and that stub still points at SolOSV3/01-research and SolOSV3/06-implementation paths.
• The actual vhost content (16 files) lives in Docs/Projects/vhost/, and VAULT-INDEX rule 11 declares that the tenancy platform's home.
• The authority doc (SolOSV3/02-architecture/vault-structure-authority-2026-10-18.md, §"Vault structure") says vhost content belongs in Docs/VHost/ with research/decisions/implementation subfolders.

Three sources, two answers. Rule 11 and the disk agree with each other and disagree with both Young's message and the authority doc. Needs one ruling.

3. CONFLICT — "Fleet" vs "SolOSV3"

Young's taxonomy names the section Fleet ("Our Heart Fleet design and architecture"). Disk has Docs/SolOSV3/ (2215 files).

During verification I observed Docs/Fleet/ appear with 2215 files and then vanish again within ~30 seconds, with Docs/SolOSV3/ returning — an in-flight rename by a concurrent session. No commit ever recorded Docs/Fleet (git log --all -- Docs/Fleet* is empty).

Unresolved: rename SolOSV3 → Fleet (requires fixing VAULT-INDEX rules 3 & 8 and every internal reference), or keep SolOSV3 and record Fleet as the colloquial name. Until ruled, two sessions can produce split state.

4. Docs/index.md navigation is stale

Lists only three entries — SolOSV3, Property, Kanban. Missing Projects, SolOS, vHost. The [Property](/docs/properties) target does not exist under Docs/. (This file drives the docs-site nav, so the published site does not show the new sections.)

Also: no index.md landing exists for SolOSV3/ or Kanban/.

5. SECURITY — live API key in a world-readable unit file on prod

/etc/systemd/system/solos-docs.service (mode -rw-r--r--, root:root) inlines two plaintext API keys via Environment=:

• ZEN_API_KEY
• AI_GATEWAY_API_KEY

Verified with pattern counts only — no secret value was printed or copied. The same key pattern also appears in /etc/systemd/system/pulse-site.service.d/chat-keys.conf.

Scope of exposure:

• The repo template (solos-docs.service in youngframeworks/solos-docs) is clean — 0 key occurrences in HEAD. The key is not in GitHub.
• Exposure is local to prod: any process or user on that host can read the paid key from a 644 file.

Fix: move both keys to an EnvironmentFile= with mode 600 (or systemd credentials). Do not inline secrets in unit files.

6. Residual — stale prod git remote in the LAB vault

The vault still carries a live prod remote: ubuntu@161.33.71.67:/home/ubuntu/.solos/docs/vault

That directory no longer exists on prod (No such file or directory), so rule 12 ("No vault git repo on Production") is satisfied in fact. But the stale remote remains in .git/config — a git push prod would attempt to recreate the retired path. Recommend removing the remote.

7. Docs site — measured state

• docs.youngle.au → nginx → 127.0.0.1:8091 → solos-docs.service (Nuxt/Nitro), working dir /home/ubuntu/docs-site.
• Site is behind nginx basic-auth (anonymous request returns 401).
• Vault is off prod — /home/ubuntu/.solos/docs/ is empty.
• Content now comes from the youngframeworks/solos-docs repo, which still carries both Docs/ and Pulse/ trees (nav commit f4875eb keeps the /pulse root). So Pulse content is still on the docs site.
• Gap: I found no active LAB-side publisher that pushes vault content into solos-docs. The only script is vault_sync_prod.sh (Min's), and it is not scheduled (Min's cron/jobs.json holds 0 jobs). The "only sync data from LAB" lane is not demonstrably wired. Unverified — flagging as a gap, not a failure.

Recommendation

1. Rule on §2 (vHost home) and §3 (Fleet vs SolOSV3) — both are blocking.
2. Mira: update Docs/index.md + add missing landings (§4).
3. Sol/Atlas: rotate the exposed key and move it to a 600 EnvironmentFile (§5).
4. Min: drop the stale prod remote (§6); confirm the LAB→docs-site lane (§7).

Re-verification, 2026-10-18 (evening) — status of each finding

Re-probed after the day's work. Two of the four are resolved.

On §5 — one thing the fix did not do: the keys were moved to a protected file, not rotated. The old value sat world-readable in a 644 unit file for an unknown period, so it must be treated as potentially disclosed until it is regenerated. Moving a leaked secret makes it tidy, not safe. Recommend rotating both keys (ZEN_API_KEY / AI_GATEWAY_API_KEY and the pulse equivalent). I verified the two keys are now different from each other (distinct hashes), so the pulse leak and the docs leak are separate credentials — both need rotation.

Verification method: file mode via stat, key presence by pattern count only — no secret value was read, printed, or copied. Rotation status was assessed by comparing hashes, never values.