Files

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 Permalink 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)

Grid library. v1 used gridstack v10. Keep it, or go CSS-grid + a lighter DnD? (Affects bundle + the no-build-step constraint.)
Card taxonomy & sizing. Status cards vs. interactive cards vs. agent-output cards — do they share one chrome or differentiate?
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?).
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?
Per-agent cards as a pattern. If Dross/Yerin/Orthos each own a card, define one "agent output card" component once.
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.

4.1 KiB Raw Permalink Blame History Unescape Escape