Saved views — named filter presets stored as vault notes

[unforced]

Why

Building "my daily journal view" or "untagged from this week" once, naming it, and returning to it — is core to how people use real note tools. Lens has powerful filters (search, tag, path, sort) but no way to save combinations.

Design: stored in the vault, not frontend

Saved views live as notes in the vault at a conventional path, e.g. UI/Views/<name>. Benefits:

• Portable: the views follow you across devices
• Shareable: if two people use the same vault, they share views (or can opt out)
• Agent-readable: Claude can see your saved views as context
• Doesn't litter localStorage

The view note's metadata stores the filter spec:

kind: saved-view
filters:
  search: "..."
  tags: ["a", "b"]
  tagMatch: "all"
  pathPrefix: "Projects/"
  sort: "created:desc"

Content is freeform (description, notes). Tag: view (or a role-configured tag).

Scope

• Save current filter state: button on /notes when filters are active → prompts for name → writes a UI/Views/<name> note via createNote.
• List saved views: sidebar section on /notes showing saved views, click to apply that filter state.
• Edit: edit a view's filters by modifying the filter state and "Save as" or "Update existing".
• Delete: standard delete-note flow on the view note.
• Default views (built-in, not saved): Untagged, Orphaned, Pinned, Archived, Today — these come from their respective routes, not saved-view machinery.

Tests

• Save a view → vault gets a note with correct metadata
• Apply a view → URL params / filter state reflect the spec
• List of saved views refreshes on create/delete

Out of scope

• Automatic view suggestions (overkill)
• Shared views with per-user overrides (if it matters, separate issue)
• Views that span multiple vaults (conceptually weird — skip)

Priority

Mid. Composes well with other organizational work but isn't a standalone must-have.