Files
Void-Homelab/docs/plan-6-brainstorm-brief.md
root afbf075d26 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>
2026-06-01 23:26:46 +10:00

4.1 KiB
Raw Blame History

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: 1030s) 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.