diff --git a/journal/2026-07-10.md b/journal/2026-07-10.md
index 917a7c6..1f839f2 100644
--- a/journal/2026-07-10.md
+++ b/journal/2026-07-10.md
@@ -17,3 +17,10 @@ tags: [scope/global, type/log]
 **Reason:** other
 **Vault notes touched:**
 (none)
+
+## Session — 2026-07-10T13:16:06Z
+
+**Project:** /home/jared/servers/desktop
+**Reason:** prompt_input_exit
+**Vault notes touched:**
+(none)
diff --git a/reference/vaultwarden-permission-parity-gotchas.md b/reference/vaultwarden-permission-parity-gotchas.md
index 3a73ccb..5bb84cb 100644
--- a/reference/vaultwarden-permission-parity-gotchas.md
+++ b/reference/vaultwarden-permission-parity-gotchas.md
@@ -10,7 +10,7 @@ tags:
   - domain/security
 scope: global
 date: 2026-07-09
-last_updated: 2026-07-09
+last_updated: 2026-07-10
 last_reviewed: 2026-07-09
 related:
   - credvault-integration-master-plan
@@ -54,5 +54,19 @@ issue #6269):
   password preserves the old one in `passwordHistory` with `lastUsedDate`. Custom `fields`
   round-trip intact through `bw list items` JSON.
 
+## Credential rotation gotchas (verified 2026-07-10, credvault e2e)
+
+- **Master password rotation invalidates cached `bw` logins.** After changing an account's
+  master password server-side, `bw unlock` fails (exit 1) even with the correct new
+  `--passwordfile` — the cached login holds keys derived from the old password. Fix:
+  `bw logout`, then re-login with the API key, then unlock works.
+- **`bw` sessions are per `BITWARDENCLI_APPDATA_DIR`.** A plain `bw logout` in a shell only
+  clears the *default* appdata dir; tool-specific dirs (e.g. credvault's
+  `~/.config/credvault/bitwarden`) keep their stale session until you log out with the
+  matching env var set.
+- **API key rotation changes only `client_secret`** — `client_id` is stable across rotations.
+- **`bw unlock --passwordfile` reads only the first line**, so a trailing newline from an
+  editor (nvim etc.) is harmless.
+
 Rule of thumb: any "Bitwarden supports X" claim from bitwarden.com/help must be re-verified
 against the deployed Vaultwarden version before it becomes a security assumption.
diff --git a/vault-backlog-pilot-plan.md b/vault-backlog-pilot-plan.md
index ff6b025..cce23e6 100644
--- a/vault-backlog-pilot-plan.md
+++ b/vault-backlog-pilot-plan.md
@@ -7,7 +7,7 @@ tags:
   - tool/claude-code
   - project/cc-os
 status: accepted-pilot-live
-last_reviewed: 2026-07-09
+last_reviewed: 2026-07-10
 ---
 
 # Backlog system: decision and pilot plan v2 (2026-07-06)
@@ -36,7 +36,7 @@ The perspectives panel and v1 optimized for "push beats pull." The user correcte
 
 - **Three repos, three concerns:** deploy artifacts (compose, cron wiring, config, deploy PRD/runbook) live in `~/servers/ovh-prod/`; the Ruby gem (API client + `backlog` CLI + tick/digest logic) lives in `~/dev/ruby-gems/`; cc-os carries only the SessionStart-brief plugin + its eval harness. The plugin depends on the gem's installed binary — no cross-repo source coupling. ovh-prod stays behavior-free (compose + cron + config only) so all logic remains model-free-testable inside the gem.
 - **Gem is two-layer:** (1) a thin faithful **client layer** wrapping the Planka REST API broadly — core resources (projects/boards/lists/cards/tasks/due-dates/labels/comments/memberships/auth) **plus webhooks** (decided: wanted, so Planka can trigger strategic outbound actions via n8n/other APIs) and **admin + attachments** (less certain but likely useful — included in the first pass on the grounds that shipping probably-working endpoints now beats reopening the client later; Planka API churn judged low-risk); (2) a small opinionated **domain layer** (`add --quick`, `list --all`, `tick`) used by the CLI, digest, and future Hermes. Client layer generated with the `api-wrapper` skill, `plankapy` as endpoint crib. Per-credential instantiation (no global auth singleton) to support Hermes' scoped tokens.
-- **PRDs drafted 2026-07-07:** deploy PRD → ovh-prod repo docs; gem PRD → ruby-gems repo. cc-os plugin PRD deferred to Phase 1 (blocked on the extend-os-vault vs. new-`os-backlog` decision).
+- **PRDs drafted 2026-07-07:** deploy PRD → ovh-prod repo docs; gem PRD → ruby-gems repo. cc-os plugin PRD deferred to Phase 1 (plugin-home decision resolved 2026-07-10: new `os-backlog`, ADR-023).
 
 ### Organization + workflow v2 (2026-07-09 amendment — gate passed)
 
@@ -48,7 +48,7 @@ The perspectives panel and v1 optimized for "push beats pull." The user correcte
 - **Clients** project → one board per client. Initial board: **philly-search-engine-marketing** (`~/clients/philly-search-engine-marketing/`). Client cards are PM-altitude: each either links a Dev board that executes it (URL in description — no first-class card links in Planka) or carries its own task checklist when too small for a dev board.
 - **Property management and business-dev boards deferred** — hypothetical/nuanced; revisit after living with the system.
 - Uniform **lists** on every board: `Backlog → Next → Doing → Waiting → Review → Done` (Waiting = blocked on outside input, doesn't count against WIP).
-- **Labels are board-scoped in Planka**, so the CLI/seeding scripts enforce an identical label set on every board: `P0/P1/P2` (priority) + `hitl` / `afk-ready` (AI-workability convention, adopted from the gem issue cards).
+- **Labels are board-scoped in Planka**, so the CLI/seeding scripts enforce an identical label set on every board: `P0/P1/P2/P3` (priority; P3 added 2026-07-10 for the Apprise expansion cards — currently only on the cc-os board, `backlog board ensure` should adopt it) + `hitl` / `afk-ready` (AI-workability convention, adopted from the gem issue cards).
 
 **Process — kanban with WIP limits, not agile sprints.** Capture into Backlog is cheap; pulling into Next is the only planning ritual (when Next runs dry, not on a calendar); Doing is hard-capped at 2–3 for the human; cards flow one direction.
 
@@ -62,7 +62,7 @@ The perspectives panel and v1 optimized for "push beats pull." The user correcte
 
 **Board lifecycle (archive/activate) — VERIFIED 2026-07-09:** live-instance API tests confirmed Planka v2.1.1 CE **cannot move a board between projects** (`projectId` is not a patchable field), cannot move cards across projects (`E_NOT_FOUND` on foreign listId), and board DELETE is permanent (cascades, no restore — never use for archiving). The Archive-project design is therefore dead; lifecycle is the rename convention: archiving = rename board `archived--<name>` + move to bottom position (ONLY on explicit human go-ahead); activating = rename back (no approval needed). Discovery via the API board listing: active board found → use; `archived--` board found → activate silently; not found for an existing repo → stop and discuss. Label CRUD verified working per board (POST `/api/boards/:id/labels`, PATCH/DELETE `/api/labels/:id`; 41-name color whitelist, no hex). Also verified 2026-07-09 during seeding: creates require an undocumented `type` field — projects `"private"`, lists `"active"`, cards `"project"`; card-label attach is POST `/api/cards/:cardId/card-labels` `{labelId}`. **Project visibility gotcha:** a bot-created project gets `ownerProjectManagerId` set (single-owner "private" mode) and is invisible to every other account — even instance admins can't add managers (`E_FORBIDDEN`). Fix/required pattern for `backlog board ensure`: after create, PATCH the project with `{"ownerProjectManagerId": null}` (as the owner; `{"type":"shared"}` is silently ignored), then POST the human's userId to `/api/projects/:id/project-managers`.
 
-**Plugin scope widened:** the cc-os plugin (extend os-vault vs. new `os-backlog` — still open) is the AI's process-management surface and should be designed across all four plugin primitives: skills (capture/list/tick/board ops), scripts (deterministic API calls via the gem), named agents (e.g. card-triage, board-audit), and hooks (where session lifecycle genuinely helps — no push-style briefs per the notification policy).
+**Plugin scope widened:** the cc-os plugin (**decided 2026-07-10: new `os-backlog` plugin, ADR-023** — separation of concerns; os-vault stays memory/knowledge-only) is the AI's process-management surface and should be designed across all four plugin primitives: skills (capture/list/tick/board ops), scripts (deterministic API calls via the gem), named agents (e.g. card-triage, board-audit), and hooks (where session lifecycle genuinely helps — no push-style briefs per the notification policy).
 
 **Execution breakdown (2026-07-09) — grouped by subagent + model tier; Fable orchestrates and reviews only. Status 2026-07-09: steps 1–3 DONE** (API verified, 3 audits run, boards seeded: Dev {cc-os, planka} + Clients {philly-search-engine-marketing}, 50 cards incl. 12 gem slices in Review and a dashboard-design card; old "planka-api gem" project left in place pending human deletion go-ahead):
 
@@ -75,6 +75,11 @@ The perspectives panel and v1 optimized for "push beats pull." The user correcte
 
 Human gates: archive go-aheads always, plugin design decision (5), gem-card Review→Done acceptance. (Card-content pre-approval rescinded 2026-07-09.)
 
+### Plugin home + notification transport (2026-07-10 amendment)
+
+- **Plugin decision resolved (human gate passed):** new **`os-backlog`** plugin in cc-os, NOT an os-vault extension — separation of concerns (memory/knowledge vs. workflow/process, different stores and failure modes). Recorded as **cc-os ADR-023**, which also makes the ecosystem framing explicit: cc-os = the always-on personal operating layer (`os-*` plugins, mutually aware over time, on every machine); `~/dev/cc-plugins` = optional as-needed plugins.
+- **Apprise supersedes Pushover as the notification transport (cc-os ADR-024).** Planka natively speaks Apprise; the user's services (Discord, Telegram, Bark, Home Assistant, Gnome, Zoom, Pushover) are all Apprise targets. This iteration stays minimal: Apprise API server as a docker-compose service on OVH + swap the gem's Pushover P0 for a minimal Apprise `notify` client. Expansion seeded as P2/P3 cards on the cc-os board: Apprise client gem + CLI, an `os-notify` cc-os plugin (AI-routable notifications from any session/machine), multi-service routing, Planka's native Apprise integration pointed at the same server. Notification *policy* (pull beats push, silent days silent) is unchanged — transport only.
+
 ### Fallback ladder (if the phone gate fails)
 
 1. **TaskView** (taskview.tech) — on-paper ideal (native mobile apps, scoped API tokens, first-party MCP) but source-available, ~6 months old, thin sourcing. *Verify claims hands-on first, then trial.* Modern-and-unproven; only reached if Planka fails the gate.
@@ -115,7 +120,7 @@ Target trajectory: reminders are the degenerate case where AI can't act yet. Eve
 **Phase 1 — the agent layer (parallel after the gate)**
 - sonnet subagent: Ruby `backlog` CLI (`lib/` + `bin/`, model-free tests): `add --quick "title"` (defaults board/list/priority), `list --all` (cross-board), `tick` (idempotent elapsed-time recurrence catch-up from a recurrence manifest; simple offsets `+1y|+6m|+3m|+1m` only — no rule engine).
 - haiku subagent: daily `tick` scheduling on the OVH box (cron or a small container next to Planka). ~~Digest~~ dropped 2026-07-09.
-- ~~SessionStart brief~~ dropped 2026-07-09 → replaced by the pull-based unified dashboard (own Planka card; lightweight JS, not Rails). Plugin (skills/scripts/agents/hooks) home + naming per [[cc-os-plugin-skill-naming-convention]] (extend os-vault vs. new `os-backlog` — decide at build; run `bin/refresh-plugins` after).
+- ~~SessionStart brief~~ dropped 2026-07-09 → replaced by the pull-based unified dashboard (own Planka card; lightweight JS, not Rails). Plugin (skills/scripts/agents/hooks) home + naming per [[cc-os-plugin-skill-naming-convention]] (decided 2026-07-10: new `os-backlog` plugin, cc-os ADR-023; run `bin/refresh-plugins` after).
 - Fable: review all deliverables; verify a fresh session surfaces the fixtures.
 
 **Phase 2 — Hermes (independent design exercise, guardrails-first — NOT in the pilot's critical path)**