Comprehensive Vault Audit — Fable Prompt

Created 2026-07-04

Tags planvaultauditaiosplatform-agnosticfable

Comprehensive Vault Audit — Prompt for Fable

Open a Claude Code session with Fable (claude-fable-5) in the vault root (~/Obsidian/baseworks-kb-shared-brain/) and paste the block below, or open this file and say “execute this plan.” Everything between the rules is the prompt.

You are performing a complete diagnostic audit of the Baseworks Knowledge Base (“shared brain”) vault. This is a read-and-diagnose pass first; do not make destructive or structural changes until I approve the plan you produce. Work methodically, verify everything against the actual filesystem rather than assuming, and produce a single prioritized written report at the end.

Context you need

Vault: ~/Obsidian/baseworks-kb-shared-brain/, a private git repo (p-oancia/baseworks-kb-shared-brain) synced across Patrick’s Mac, Asia’s Mac, and the VPS (/srv/baseworks/knowledge-base/). Branch main only.
Readers: only two people, Patrick and Asia. The published site kb.baseworks.com (Astro/Starlight → Cloudflare Pages) is access-gated (Cloudflare Access, per-email 2FA), not world-visible. So privacy inside the vault is a soft preference, not a hard constraint.
Top-level structure: 00-inbox, 01-projects, 02-areas, 03-resources, 04-archive, 05-private, plus scripts/, site/, templates/, CLAUDE.md, README.md, index.md, vault-index.db, .codex/, .claude/.
Instruction files: root CLAUDE.md (vault rules), .codex/CODEX.md (Codex integration), and the global ~/.claude/CLAUDE.md. Read all three before judging anything, plus 00-inbox/claude-code-shared-context.md (single source of truth for infra state).
Goal of the audit: optimize the workflow, structure, and tooling, and move the whole system toward being platform-agnostic and self-contained (the model to emulate is the ~/Obsidian/Patrick-Personal/AIOS/ pattern). The end state should run cleanly on any of the three machines with minimal machine-specific assumptions.

What to audit (cover every section, in order)

1. Memory system

Read ~/.claude/projects/-Users-vboy-Obsidian-baseworks-kb-shared-brain/memory/MEMORY.md and every file in that memory/ directory.
Flag: stale facts (references to files, scripts, flags, or paths that no longer exist — verify each against the filesystem), duplicates or near-duplicates that should be merged, internal contradictions, [wikilinks](/wikilinks/) between memories that point nowhere, and entries that duplicate what the repo/CLAUDE.md already records (those should be deleted per the memory rules).
Check the index (MEMORY.md) matches the actual files: every file has a one-line pointer, every pointer resolves to a file.

2. Structure and content integrity

Map the 00–05 top-level scheme. Is the numbering coherent? Does 05-private still earn a separate folder now that the site is gated and there are only two readers, or should it publish and/or be renamed? Recommend.
Frontmatter health across the vault: run/read scripts/vault-audit.py and the /vault-audit skill if present. Check for the failure modes the root CLAUDE.md warns about (missing --- delimiters, markdown inside frontmatter, manually-added vault_path, duplicate keys, unquoted titles with colons).
Wikilink integrity: run python3 scripts/check-wikilinks.py (full scan). Report broken links, and separately report orphans (files nothing links to).
Directory hygiene: every content directory should have an index.md (per the vault’s wikilink standards). List directories missing one.

3. Databases and index functionality

The only database file present is vault-index.db (SQLite, gitignored, rebuilt by the post-sync hook; schema in scripts/build-vault-index.py). Note: I referred to a “QMD database” — there are no .qmd files in the vault, so determine whether I meant (a) this SQLite index, (b) the markdown-derived content index site/src/content/page-index.json, or (c) something else, and tell me which. Locate any other data store you find.
Verify vault-index.db integrity: run PRAGMA integrity_check;, confirm the schema matches build-vault-index.py, check whether it is stale versus the current file tree (counts of files/links/tags vs. what’s on disk), and confirm the incremental and --full rebuild paths both work (python3 scripts/build-vault-index.py and --full).
Confirm the queries the vault relies on still work (backlinks, tag search, orphans, broken links) and that the post-sync hook actually rebuilds it.

4. Build and sync pipeline

Read site/scripts/sync-content.mjs, site/scripts/audit-links.mjs, site/scripts/audit-pages.mjs, site/scripts/copy-crepe-css.mjs.
Confirm the CONTENT_DIRS allowlist, the wikilink resolver, and the stub-page generation behave as documented. Flag the known gap: the sync does not gate on internal tag or draft status, so those tags currently mean nothing to the build. Recommend whether that should change, especially for the future scenario of inviting new people into the vault (which would reintroduce a real public/private boundary).
Decide and recommend how 05-private should be handled by the sync (publish to the gated site, or stay excluded).

5. Tooling, automation, and platform-agnosticism (the core of the AIOS refactor)

Inventory every script in scripts/ (there are ~25, including vault-sync.sh, people-pipeline.sh, forum-content-sync.py/.sh, people-webhook-daemon.py, build-*.py, export-contact-inquiries.py, translate-community-content.py, archive-inbox.py, post-sync-hook.sh, plus git-hooks/, hooks/, launchd/). For each: what it does, when/how it runs, and whether it is machine-specific.
Platform-agnostic audit specifically: find every hardcoded path (/Users/vboy/, /srv/baseworks/, /Volumes/), every macOS-only assumption, and the split between macOS launchd jobs and Linux systemd units (people-webhook.service, slack-notify-systemd-failure@.service, files under scripts/launchd/). Propose how to make scheduling, paths, and service definitions portable across Patrick’s Mac, Asia’s Mac, and the VPS (config file, env vars, a single job manifest, whatever you judge best). This is the heart of what I want.
Review .claude/skills/ (the ~19 vault skills), .claude/settings.local.json, and .codex/CODEX.md. Flag skills that are broken, redundant, or reference things that have moved, and check the Claude/Codex integrations are consistent with each other.
Check scripts/audit-log.json and scripts/_migration-map.json for what past migrations did and whether any are half-finished.

6. Anything else you find

Security/secrets hygiene (any credentials committed that should not be), .gitignore correctness, large or orphaned binaries, broken symlinks in *-assets/ folders, and dead or duplicated content in 04-archive.
Consistency between the three instruction layers (global ~/.claude/CLAUDE.md, vault CLAUDE.md, .codex/CODEX.md) — flag contradictions.

How to work

Start by reading the three instruction files and 00-inbox/claude-code-shared-context.md, then build a todo list covering the six sections above before touching anything.
Prefer the vault’s own tools (vault-audit.py, check-wikilinks.py, build-vault-index.py, /vault-audit skill) over ad-hoc reimplementation.
This is diagnostic-first. Do not delete, rename, move, or restructure anything until I approve. If a fix is trivial and safe (e.g. correcting one broken wikilink), you may note it as “quick win” but still list it rather than silently applying, unless I say go.
Respect the git rules: main only, and site code belongs in the changelog repo, not the vault (per CLAUDE.md).

Deliverable

Write a single report to 03-resources/plans/vault-audit-report-2026-07-05.md with:

Executive summary — overall health in a few sentences, and the 3–5 highest-impact changes.
Findings by section (the six areas above), each finding tagged severity [critical] / [high] / [medium] / [low], with the concrete file/line/command evidence.
Prioritized remediation plan — an ordered checklist of what to change, grouped into “quick wins” (safe, do immediately) and “structural” (needs discussion), with the platform-agnostic refactor broken into concrete steps.
Open questions for Patrick — anything that needs my decision before you proceed (the 05-private publish question, the internal-tag gating question, the AIOS target structure, etc.).

At the end, stop and walk me through the report before making any changes.