obsidian-vault-template

The Tier-B (per-project) vault skeleton for the obsidian-vault-platform (SPEC.md §6, stage 2 — "vault deploy"). Instantiated by orch.obsidian-vault-provision (grepleria-configs) into a new project's <dataset>/Notes (or the root of a BYO SMB/NFS share) — standard folders + .obsidian/ preconfigured to use LiveSync + vault-operator, with NO secrets (no CouchDB credentials, no E2E passphrase, no MCP token — those are broker-minted per-project and layered on top afterward, same as apps/obsidian-runner layers them onto a Tier-A vault).

Layout

Everything under obsidian-vault-template/ (the inner directory — deliberately separate from this repo's own README/LICENSE, so provisioning copies obsidian-vault-template/* verbatim into the new vault root without also carrying this repo's OWN meta-files into the user's vault) IS the vault:

obsidian-vault-template/
├── Welcome.md                          # stock Obsidian first-run note
├── Templates/                          # empty — Obsidian's "templates" core plugin folder
├── Attachments/                        # empty — default attachment folder
└── .obsidian/
    ├── app.json                       # {} — Obsidian defaults
    ├── appearance.json                # {} — Obsidian defaults
    ├── core-plugins.json              # Obsidian's OWN "sync" core plugin OFF
    │                                   # (would otherwise compete/confuse with LiveSync)
    ├── community-plugins.json         # ["obsidian-livesync", "vault-operator"]
    ├── graph.json / workspace.json    # stock first-run defaults
    └── plugins/                       # NOT present here — orch.obsidian-vault-provision
                                        # fetches the pinned plugin release assets +
                                        # writes their data.json (with the broker-minted
                                        # CouchDB creds / E2E passphrase / MCP token)
                                        # AFTER stage 4 (secrets) mints them — same
                                        # fetch-and-seed logic apps/obsidian-runner's
                                        # salt state uses for Tier-A, retargeted at the
                                        # project's dataset instead of /vaults/<name>.

community-plugins.json lists both plugins as enabled ahead of their data.json existing — Obsidian tolerates an enabled plugin with no data.json (falls back to that plugin's own defaults) until the orch's later stage writes real settings; it does not error on load.

Why no secrets, no plugin binaries

Per-project CouchDB database/user, the client-side E2E passphrase, and the vault-operator MCP bearer token are all self-minted by orch.couchdb-databases/orch.obsidian-vault-provision at provisioning time (never hand-authored, never committed here). Plugin release assets (main.js/manifest.json/styles.css for both obsidian-livesync and vault-operator) are pinned by version + sha256 in apps/obsidian-runner/salt/pillar/default.sls (grepleria-configs/apps-catalog) and fetched directly from their GitHub releases at deploy time — this template stays free of both secrets and binary/generated content, so it's safe to version-control plainly.

Consumers

• Tier A — apps/obsidian-runner (grepleria-apps-catalog) seeds a Tier-A infra vault directly onto the ZFS-backed /vaults/<name> tree. It does NOT instantiate this template today (Tier-A vaults are hand-curated, few, and already exist) — but a future "add a new Tier-A vault" ceremony could.
• Tier B — orch.obsidian-vault-provision (grepleria-configs) instantiates this template into each new project's dataset/share as stage 2 of the provisioning pipeline (SPEC.md §6).