> Public study copy. Original Xavier note path: `AGENTS.md`. Secrets/credential-like values, if any, are redacted.

# Xavier Vault Operating Rules

Use these rules when working inside the Xavier Obsidian vault.

## Core model

- The vault is Paulo and Xavier's durable human-readable workspace.
- Use Johnny.Decimal IDs for navigation and chat references.
- Prefer updating existing notes over creating duplicates.
- Keep dashboards operational, visual, and concise.

## Memory boundaries

- Runtime memory must stay compact.
- Long-form project state, decisions, plans, reports, and relationship context belong in Obsidian.
- Procedures with steps, commands, pitfalls, and verification belong in Hermes skills.
- Session history is for recall on demand; do not copy raw conversations into notes.

## Decision capture

When a conversation closes options or chooses a direction, record it as:

- Decision:
- Rationale:
- Implication:
- Status:
- Date:

Use project-specific decision registers for project decisions, and cross-project registers for platform-level decisions.

## Canonical owner rule

Every durable information object should have one canonical owner note:

- source/provenance → `60-69 Sources`;
- concept/framework → `40-49 Knowledge`;
- project decision → relevant project decision register;
- current project state → dashboard/tracker;
- task → task board/tracker;
- procedure → skill or operation/playbook.

Other notes should link to the owner and record only local implications. Avoid copying the same synthesis into multiple notes.

Before creating a new Johnny.Decimal note, answer: What is the existing owner? Is this an update rather than a new object? Can it be captured as a section inside the owner note? What lifecycle will it have: active, draft, appendix, historical, superseded? Will it be exposed on a dashboard or only linked by backlinks/JDex?

Project-specific restraint:

- PhD/article work: if material deepens Article 1, Article 2, or Article 3, update `37.62`, `37.63`, or `37.64` first. Cross-article framing goes to `37.61` or `37.65`.
- Voice Lab: during recruitment, strategy changes and launch gates deepen `32.25`; formal decisions go to `32.03`; implemented copy stays with `32.22`; deploy/recovery stays with `32.20`/`32.24`; `32.01` stays dashboard-light.

## Paulo scratchpad exception

- [[20.99 Paulo Scratchpad - Do Not Process]] is Paulo's personal free-form scratchpad.
- Do not promote, summarize, classify, archive, clean, or use its contents unless Paulo explicitly asks.
- It is intentionally outside the normal intake/governance pipeline.

## Safety

- Never store secrets, tokens, passwords, API keys, private keys, webhook URLs, or credential values in notes, memory, skills, logs, or final summaries.
- Store only references to external secret managers or credential locations when needed.
- If a proposed memory/note might be sensitive, ask before saving.

## Structural-edit preflight

Before any rename, move, bulk link cleanup, category restructuring, or governance edit:

1. Validate the Johnny.Decimal address: folder/category and note ID must align, e.g. `64 Media` → `64.xx` notes.
2. Validate active names against decision registers and canonical notes. Existing filenames do not override later decisions.
3. Distinguish active labels from historical labels. Historical labels may remain only as explicit rename/history context, not active note titles or links.
4. Prefer dry-run first: list proposed renames/moves and risky link edits before applying, unless Paulo explicitly asks to apply immediately.
5. Verify after changes: path exists, old path is gone, links resolve, duplicate active IDs are zero, and no forbidden active labels were reintroduced.

## Before editing project state

- Read the relevant dashboard.
- Read the relevant decision register.
- Check whether the information belongs in runtime memory, Obsidian, a skill, or nowhere.