Hatchdoor: the vault via MCP

On this host the vault is remote and reached only through the Hatchdoor MCP tools. There is no local vault on disk, so read and change vault content through the Hatchdoor MCP tools, never through file tools, shell, or filesystem paths.

Start with Vault discovery

1. Call list_vaults before any Vault-scoped tool. It supplies the canonical vault_id, registry revision, source type, readiness, and supported capabilities. Never use all for a mutating call.
2. Select the enabled Vault that has the required capability. Do not infer a Vault ID from its name or source path. A Vault reporting search: "stale" is reindexing and still answers searches; only search: "indexing" (a first index) has nothing to search.
3. For managed-Git Vaults, use sync_vault only when an immediate sync is needed and the Vault advertises it as eligible; use retry_vault only when the Vault advertises retry eligibility. existing_git and local Vaults have different sync semantics.
4. Vault-registry changes (create_vault, edit_vault, enable/disable/disconnect) require a fresh registry_revision from list_vaults. Treat a revision conflict as a concurrent change: reread, reassess, and retry only if still appropriate.

Before any note change

1. Read the note "Vault - Operating Rules" (resolve_wikilink, then get_note) and follow it: it is the source of truth for filing, tags, links, and change reports.
2. If tags may be added or changed, read "Tags Reference" first.
3. Decide the note's shape before writing a word of it. Read "Hatchdoor - Markdown Feature Showcase" and pick the components that carry what the note has to say: a callout for a verdict or a caveat, a two-column table for repeated labelled facts, a task list for open items, dated sub-headings for anything that accumulates over time, a Mermaid diagram for a flow, a fenced block with its language for anything to be copied and run. Its Choosing a shape section maps the common cases. This applies to every note, not only ones you have already decided are rich: bullets top to bottom is a choice too, and usually the wrong one. Layout only: it never licenses adding content the user did not give (see Minimal capture).
4. Search before creating with search_notes. Prefer linking to or updating an existing note over creating a duplicate.
5. Before a hash-protected mutation, obtain a fresh expected_content_hash: from get_note, or from get_note_outline / get_note_section when the change touches one part of a long note, since both return the whole note's hash. This applies to edit_note, replace_section, update_note, append_to_note, move/rename/archive/delete operations. If the hash is rejected, reread before attempting another edit.