Research: notes-app config as a vault note (path-gen rule, surfaced fields, etc.) via useVaultSettings

[unforced]

Background

Aaron flagged: notes-app config could live as a vault note (the existing `.parachute/notes/settings` pattern Tag Roles already uses via `useVaultSettings`). Then per-vault customization of notes-side behavior doesn't require vault schema changes — vault stays generic; notes reads its own config from its own settings note.

Specific candidates that would benefit from per-vault config:

• Path generation rule (e.g., `notes/-` vs `notes/` vs custom).
• Which fields Capture surfaces by default (path? summary? tags?). Currently hardcoded; could be per-vault.
• Summary metadata field (metadata.summary is currently arbitrary; whether it's surfaced as a first-class Capture field could be configurable).
• Default tags applied on Capture (today comes from Tag Roles, which is per-vault — this works; pattern proves the model).
• Autosave timing (5s today; some vaults might want longer/shorter).

Why this matters

Earlier work tried to model "notes-specific schema" inside vault and got over-complicated — that complexity has since been ripped out. The lighter path: notes stores its own config in a settings note, vault remains a generic substrate.

This research issue is about identifying which notes-side behaviors should be per-vault configurable, and what shape the settings note should take.

What to do

1. Audit current Notes-side hardcoded behaviors (path gen, autosave timing, fields surfaced, etc.).
2. Catalog which would benefit from per-vault config.
3. Propose a config schema (likely extending the existing useVaultSettings JSON blob in .parachute/notes/settings).
4. Identify any UI surface needed for users to edit per-vault config (Settings page extensions).

Output: a short design note (not implementation). After review, pick the highest-leverage items to implement.

Constraints

• Don't add anything to vault. Vault stays generic — it just stores the settings note. Same pattern Tag Roles already uses.
• Per-vault config should be optional with sensible defaults — operator who doesn't care never sees it.
• Migration from existing hardcoded behavior should be seamless.

Related

• useVaultSettings hook at src/lib/vault/settings.ts — the existing pattern Tag Roles uses.
• notes#TBD — Capture path-generation issue (would benefit from per-vault rule).
• notes#TBD — Text-size accessibility issue (less relevant to per-vault since text-size is device-local).
• Aaron's framing 2026-05-13: "we had been playing with the idea of notes config being saved as a note... it would be interesting if without adding any extra stuff to vault, this notes app can just save its config as a note."