Projects and explorations

Case Study

Problem: People managing several web identities can easily mix browser-owned cookies, storage, service workers, permissions, and history inside a default profile. Many tools then overstate environment separation as device impersonation or undetectability, obscuring the real boundary.

Design: The desktop app launches Chrome or Edge with a dedicated `--user-data-dir` per Silo and keeps VeriSilo metadata and seeds in a local encrypted vault. The optional Companion observes and explains the current environment only after an explicit user action, with local redacted report storage by default.

• Uses a dedicated browser data directory per Silo so browser-owned cookies, storage, cache, service workers, permissions, and history separate naturally.
• Distinguishes reliable control, best-effort observation, and unavailable capabilities instead of hiding evidence behind an anonymous score.
• Keeps Native Messaging, page messages, and report export explicitly validated, user-triggered, local, and redacted by default.

Case Study

Problem: Most food logs can record what you ate, but rarely improve the next decision. Photos, physical feedback, trends, and corrections stay scattered, so each analysis starts from guesswork and leaves little reusable experience behind.

Design: A local-first workbench organizes meal photos, ingredients, daily questions, nutrition data, and user corrections. A Web UI and CLI handle capture, tasks, and review; JSON Schema validates agent output; corrections append history instead of silently overwriting it.

• Connects recommendations, daily state, food photos, ingredient analysis, nutrition data, and memory in one local feedback path.
• Supports question-by-question daily check-ins, per-question drafts, skipping, and version history without turning missing information into conclusions.
• Uses CLI tasks, context export, schema validation, and explicit result submission instead of opaque background analysis.

Case Study

Problem: When several coding agents run at once, running, waiting, permission-request, completed, and failed states are scattered across terminals and tools. Developers cannot quickly tell which task needs attention without reading the full work contents.

Design: Crewlight uses a local-first, read-only event aggregation model. It receives status events through allowlisted adapters, organizes current sessions in Desktop, a floating Companion, a browser Dashboard, and a CLI, and avoids storing prompts, transcripts, tool I/O, or complete platform payloads.

• Runs on the local loopback by default, needs no cloud service, and neither controls agents nor automatically approves permissions.
• Sets explicit safety boundaries for event size, timeouts, duplicate notifications, malformed input, SSH host verification, and notifier failures.
• Keeps sessions in memory only, retaining at most the latest 1,000 by default; stable events are exactly deduplicated during their retention period.
• Existing adapters have been data-minimized and protocol-corrected; unreliable automatic setup for MiMo, Pi Agent, OpenClaw, and Reasonix is temporarily disabled.

Case Study

Problem: Beginners often lose an entire lesson to downloads, ports, configuration, and opaque daemon failures before they can observe HDFS or YARN.

Design: One lifecycle CLI wraps a single-node first-run mode and a three-node role mode. Preflight checks, explicit health evidence, namespaced labs, safe resets, and redacted diagnostics keep the environment understandable and recoverable.

• One lifecycle CLI covers a single-node first run and a three-node role mode, carrying the learning path naturally into node failure and recovery.
• Preflight checks, explicit health evidence, namespaced labs, safe resets, and redacted diagnostics keep the environment understandable and recoverable.
• Uses a passing `doctor`, healthy `status` service map, WordCount result, and its lesson check as reviewable learning evidence instead of treating “containers started” as success.