docs: security sweep, code review, Yerin design, Plan 6 brainstorm brief

- security-sweep-2026-06-01.md: fresh sweep of alpha.6 (1 fixed, findings + carry-overs)
- code-review-2026-06-01.md: optimisation/cleanliness notes (pool error handler,
  O(n) bcrypt token scan, FTS index alignment, dup auth parsing)
- yerin-security-agent.md: security-agent design + tool roadmap + Orthos role proposal
- plan-6-brainstorm-brief.md: Sacred Valley widget inventory + open design questions
- security-followups.md: marked the pending_changes CHECK finding RESOLVED

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/plan-6-brainstorm-brief.md

@@ -0,0 +1,64 @@
+# Plan 6 — Sacred Valley Widgets — Brainstorming Brief
+
+> **Status: PREP, not a plan.** Plan 6 is design-led. Per
+> `[[void-v2-frontend-design-plugin]]`, the actual brainstorm must run **with you**
+> and the `frontend-design` skill invoked at the brainstorm stage so it shapes the
+> spec, not the implementation. This brief assembles the raw material so that
+> session is fast — it does **not** make the design decisions.
+
+## What Sacred Valley was in Void 1.x (the inventory to port)
+
+From the live Void 1.x dashboard (CT 301), gridstack cards (`gs-id`):
+
+| Card | Source / data | Void 2.0 status |
+|------|---------------|-----------------|
+| `clock` | client clock, NY + Melbourne | Trivial port; pure client. (Note: your TZ is Melbourne — drop NY-primary.) |
+| `weather` | Open-Meteo, Melbourne, 15-min cache, no key | Port as-is (add `/api/weather` or keep client-side). |
+| `speedtest` | hourly `speedtest-cli` cron → history bar chart | Needs a worker/cron + a results table in v2. Medium. |
+| `host-perf` | `/proc` CPU/RAM/disk/net, 30s refresh | Port `lib/resources.js`; new `/api/host` endpoint. |
+| `yerin-alerts` | 5-min service-health cron | **Becomes the Yerin security agent surface** — see `docs/yerin-security-agent.md`. |
+| `littleblue-nightly` | 2 AM heal/diagnostics | Needs the Little Blue agent + cron in v2. Defer. |
+| `claude` | Claude usage (today/week/session) | v2 companion runs on the **Max subscription via CLI** — there's no API usage meter. Rethink: show CLI turn/cost from the `result` events instead. |
+| `briefing` | 7 AM Dross briefing (Claude) | Dross exists in v2; needs a scheduled briefing pass + card. |
+| `orthos-council` | 6:50 AM Orthos briefing (Ollama) | **Becomes the Orthos Advisor surface** — local-model reflective digest. |
+| dynamic service cards | per-YAML health check | v2 has a real `resources` table + status — render from that, not YAML. |
+
+## What Void 2.0's *new* backend unlocks (v2-native widgets)
+
+These didn't exist in v1 and are the more exciting half of Plan 6:
+
+- **Capture queue / Jobs** — live pg-boss job states (ingest.blob → extract.pdf →
+  embed). A "what's flowing in" card. Data already in the Jobs view/API.
+- **Hybrid search spotlight** — a search-box card over the FTS+vector RRF endpoint.
+- **Inbox / pending changes** — agent-proposed drafts awaiting approval, as a card
+  (shares the rail's approve/reject path).
+- **Knowledge connections (Orthos)** — embedding-graph "things converging" card.
+- **Security pulse (Yerin)** — recent audit highlights + alerts card.
+- **Space switcher / recent entities** — v2 is Space-scoped; v1 wasn't.
+
+## Open design questions for the brainstorm (decide WITH frontend-design)
+
+1. **Grid library.** v1 used gridstack v10. Keep it, or go CSS-grid + a lighter
+   DnD? (Affects bundle + the no-build-step constraint.)
+2. **Card taxonomy & sizing.** Status cards vs. interactive cards vs. agent-output
+   cards — do they share one chrome or differentiate?
+3. **Theme tokens.** v1 is blackflame (`--accent: #ff4f2e`). The companion rail
+   already shipped orange (mockup wanted violet — `--rail-accent` deferred). Plan 6
+   is the moment to settle the token system (accent, rail-accent, per-agent hues:
+   Dross / Yerin / Orthos identity colours?).
+4. **Real-time.** Cards poll (v1: 10–30s) vs. an SSE/event bus (v2 already streams
+   companion turns). Worth a shared `space-active`-style event channel?
+5. **Per-agent cards as a pattern.** If Dross/Yerin/Orthos each own a card, define
+   one "agent output card" component once.
+6. **Persistence.** v1 stored layout in localStorage. Per-Space layouts in the DB?
+
+## Suggested first slice (to propose at the brainstorm, not commit)
+A thin vertical: **host-perf + weather + clock** (pure ports, prove the grid +
+theme tokens) → then **Jobs card + Inbox card** (prove v2-native data) → then the
+**agent cards** (Yerin pulse, Orthos council) once those agents are wired. This
+sequences design risk before agent-integration risk.
+
+## Pre-reqs that aren't UI
+- Orthos & Yerin agents need seeding + wiring (see `docs/yerin-security-agent.md`)
+  before their cards have data.
+- speedtest/host-perf need their v2 data endpoints.