docs: add ADRs for gitignored visibility and saved view ordering (guard — from commits d2c15b8, fd92ff5)

docs/adr/0094-gitignored-content-visibility-boundary-filter.md

@@ -0,0 +1,37 @@
+---
+type: ADR
+id: "0094"
+title: "Gitignored content visibility as a command-boundary filter"
+status: active
+date: 2026-04-29
+---
+
+## Context
+
+Tolaria's vault scanner now indexes more of the real filesystem so Folder views, search, and reload flows can reflect what is actually in the vault. In Git-backed vaults, that includes generated, local-only, or machine-specific content that users intentionally hide through `.gitignore`.
+
+Always showing Gitignored files makes Folder lists and search noisy, especially in vaults that contain exports, build artifacts, or personal local scratch files. But removing those files during scanning would make visibility dependent on cache shape, complicate toggling, and blur the distinction between "what exists in the vault" and "what this installation chooses to surface."
+
+## Decision
+
+**Tolaria keeps the vault scan and cache complete, then applies Gitignored-content visibility at the command boundary before entries, folders, or search results reach React.**
+
+- `hide_gitignored_files` is an installation-local app setting and defaults to `true`.
+- Visibility checks use batched `git check-ignore --no-index --stdin` so Tolaria follows normal Git ignore and negation semantics as closely as practical.
+- `list_vault`, `reload_vault`, `list_vault_folders`, and keyword search all apply the same filter when the setting is enabled.
+- Toggling the setting reloads the current vault surfaces instead of rebuilding a different cache format.
+- If a vault has no `.gitignore`, or Gitignored visibility is turned off, Tolaria shows the full scanned result.
+
+## Options considered
+
+- **Complete scan/cache + boundary filter** (chosen): keeps the filesystem model authoritative, makes toggling cheap and consistent, and avoids cache divergence.
+- **Skip Gitignored content during scan/cache**: reduces later filtering work, but makes visibility part of the persisted cache shape and complicates instant toggling.
+- **Always show Gitignored content**: simplest implementation, but too noisy for real Git-backed vaults and undermines users' existing ignore rules.
+
+## Consequences
+
+- Gitignored visibility is a per-installation comfort preference, not vault-authored shared metadata.
+- Search, folder lists, and note reloads stay aligned because they all consult the same boundary filter.
+- The cache can still support future visibility changes without a data migration.
+- Users can reveal ignored content again immediately by disabling the setting.
+- Future features that expose vault file lists should apply the same boundary filter unless they intentionally need raw filesystem output.

docs/adr/0095-saved-view-order-field.md

@@ -0,0 +1,35 @@
+---
+type: ADR
+id: "0095"
+title: "Saved views use an explicit YAML order field"
+status: active
+date: 2026-04-29
+---
+
+## Context
+
+Saved Views already persist as user-editable YAML files in the vault and sync through Git. Filename ordering was stable, but it forced users to rename files just to change sidebar order and gave Tolaria no durable way to support drag reordering, move actions, or keyboard-first ordering controls.
+
+The ordering choice also needs to travel with the view definition itself. Saved Views are part of the vault's shared information architecture, not a machine-local preference.
+
+## Decision
+
+**Each Saved View may store an optional top-level `order` number in its YAML definition, and Tolaria sorts views by that value before falling back to filename.**
+
+- Lower `order` values render earlier in the sidebar and other Saved View lists.
+- Views without `order` sort after ordered views and then fall back to filename ordering for stability.
+- Reordering actions rewrite affected view files with a dense sequence of order values instead of encoding position in filenames.
+- The same persisted order supports drag handles, explicit move buttons, and command-palette ordering actions.
+
+## Options considered
+
+- **Explicit `order` field in the view YAML** (chosen): portable, Git-syncable, easy to inspect by hand, and consistent with the existing file-first view model.
+- **Filename-based ordering only**: no schema change, but makes reordering clumsy and couples user-visible structure to file naming.
+- **App-local ordering state**: easy to prototype, but breaks cross-device consistency and separates ordering from the view artifact users already version.
+
+## Consequences
+
+- Saved View ordering becomes part of the vault and syncs naturally through Git.
+- Existing views remain valid; unordered files keep a stable fallback sort until reordered.
+- Reordering can touch multiple view files in one action because Tolaria normalizes the sequence.
+- Future Saved View features should treat `order` as part of the shared YAML schema rather than introducing a parallel ordering store.

docs/adr/README.md

@@ -146,3 +146,5 @@ proposed → active → superseded
 | [0091](0091-gemini-cli-external-ai-setup.md) | Gemini CLI external AI setup | active |
 | [0092](0092-vault-ai-agent-permission-modes.md) | Vault-scoped AI agent permission modes | active |
 | [0093](0093-shared-cli-agent-runtime-adapters.md) | Shared CLI agent runtime adapters | active |
+| [0094](0094-gitignored-content-visibility-boundary-filter.md) | Gitignored content visibility as a command-boundary filter | active |
+| [0095](0095-saved-view-order-field.md) | Saved views use an explicit YAML order field | active |