Context
When a project portfolio becomes an operating system
My AI products live across separate repositories, each with its own tasks, Git state, quality checks and agent sessions. The RomainOS vault adds another layer of decisions and follow-up.
Reviewing each source independently produced plenty of information but no immediate answer to the useful question: where should I intervene now?
Problem
State was scattered. So was trust.
A dirty repository, a failed health check and stale documentation do not carry the same urgency. The system had to combine those signals without flattening them into a generic list.
Agents introduced a second problem: automating an action without being able to explain, review or stop it would merely shift the operational burden.
My role
Product design, architecture and operation
I defined the data model, health rules, attention score and review flows. I then built the scanner, React dashboard, Electron app and scheduled jobs.
I also designed the trust model: one actionable queue, Git branch isolation, risk-based gates, an audit trail and a kill switch.
Solution
A command centre built around the next action
One JSON registry describes the six monitored projects. Scanners read Git state, tasks and health checks, then produce comparable status and attention scores.
The interface brings genuinely actionable items into one Inbox. AI analysis remains advisory until the kernel turns it into a reviewed proposal.
The same system ships as a dedicated macOS app connected to the live local backend and repository rather than a static copy of the data.
Key decisions
Four decisions that preserve control
One registry as the source of truth
The CLI scanner and React dashboard consume the same project file. Adding or changing a project does not require maintaining two parallel configurations.
A local core with explicit boundaries
The dashboard and scanners stay local. Anthropic, Telegram and Whoop calls belong to separate layers, enabled only with their own keys and documented accordingly.
One actionable queue
CMA analysis remains advisory. Only the kernel review queue can move an item from proposed to approved and then executed.
Autonomy that fails into review
Agent actions run on isolated branches, are audited and must pass gates. A risky command, dirty repository or failed check sends the action back to a human instead of forcing execution.
Outcome & learning
Six projects, one operating view
The Command Center monitors six entries, including itself. Scans run every thirty minutes and at login. The dashboard has been packaged and launched as a dedicated macOS app.
The main lesson: governance is part of the interface in an agentic product. Provenance, risk, gates and the stop control need to be as legible as the recommendation itself.
This is a personal tool, so there is no published user count or time-saving claim. The verifiable outcome is an operational system, not an extrapolated adoption metric.
Stack & methods
Local-first, observable and supervised
- React + Vite
- Node.js
- Electron
- better-sqlite3
- Git and local scanners
- launchd
- Agent Trust Kernel
- Review queue + QA gates
- Vitest