31 may 2026

Spent most of today deep in the weeds of agent tooling and “second brain” integration, with a side quest into local-model tooling and eval metrics. The main theme: getting a personal-agent plugin truly verifiable end-to-end instead of “it probably works.”

What I learned

• Plugin build artifacts matter for real installs. If your plugin loader can’t rely on prepare, you need to commit built output (and ideally enforce it with a “dist stays in sync” test).
• Joplin Web Clipper auth is a sharp edge. A stale token can fail writes while other read paths still appear to work (especially if some reads are coming from a local/SQLite path). Without strict error propagation, this becomes a silent failure mode.
• Search semantics can create security issues. Tokenized/full-text search can unintentionally match and pull in sensitive notes, which then get injected into prompts. That’s a real “blast radius” problem if you’re auto-loading “project notes” into system context.
• Local dev servers: auth + ports + GUI env vars are tricky. For the OpenCode server, I ended up having to reason carefully about which process owned which port, what was actually serving the SPA vs the JSON API, and how Basic Auth credentials get set (and how environment variables propagate—or don’t—into GUI apps).
• Local LLM tooling tradeoffs. I watched comparisons of Ollama/LM Studio/llama.cpp and then actually tried LM Studio with Sarvam model variants/quantizations, plus looked into Mac resource monitoring to understand whether bigger GGUFs would push me into swap.

What I built

• Fix in my OpenCode personal-agent project: updated the Joplin client to use the correct /search endpoint (instead of /notes with ignored query params), rebuilt dist, and re-ran the full test suite to confirm the change and artifacts match.
• Hardening + documentation: wrote up a concrete explanation of the Joplin integration failure modes (stale token, swallowed errors) and the much more serious prompt data leakage vector via note search/snippets.
• E2E verification workflow: put together a repeatable checklist for validating plugin hooks, slash commands, pattern detection, and reflection/idle behavior through the OpenCode web/API paths, including log-based evidence.

Experimenting with

• LLM security + exploit writeups (learning only). Read through a few vulnerability analyses (buffer overflow / ROP-chain style writeups) to understand how modern exploit writeups are structured and what details matter in root-cause explanations.
• Local LLM judge idea for eval harnesses. Sketched an “indic-eval” concept: call external APIs for STT/TTS/translation but use a local judge model + caching to control cost/rate limits, and explored metrics like WER vs “LLM-WER” and intent/entity preservation scoring.
• Sarvam ecosystem reconnaissance. Looked through Sarvam’s platform pages, GitHub org, Hugging Face models, and community Discord to understand what’s public, what’s supported, and where an open-source contribution could be high leverage.