Home

Hosomaki Roadmap

---

Phase 1: Complete the Core

The current commands work. This phase makes them complete.

explain

• --since / --until for time-bounded log queries
• --context to pull logs from multiple related services at once (e.g. nginx + postgresql)
• --diff to compare logs between two boots and explain what changed
• audit
• watch <service>
• why <exit-code> --service <name>

Quality of life

• --output json
• hosomaki ports
• hosomaki crons
• hosomaki mounts
• hosomaki timers

---

Phase 2: Workflow Tools

These make Hosomaki useful in daily routines rather than just incident response.

• summarise --since <time>
• compare --service <name> --boot -1
• history
• alias
• env-check

---

Phase 3: Memory Layer

The biggest architectural milestone. Everything before this is stateless.

Storage

• SQLite + embeddings via Ollama's /api/embeddings
• pgvector

predict

---

Phase 4: Daemon Mode

A background service that keeps an eye on the system continuously. Unlocked properly by the memory layer.

• Real-time anomaly detection
• Proactive warnings before things fail
• Continuous predictions based on the machine's own history
• Instant status and doctor responses
• daemon becomes the brain, the CLI is just a client

Note: Do not underestimate this one

---

Phase 5: Multi-provider AI Support

• Ollama
• OpenAI and Anthropic as opt-in remote providers
• Any OpenAI-compatible endpoint (LM Studio, llama.cpp, vllm, etc.) via a unified interface
• Opt-in cloud analysis path: logs are scrubbed and sanitised locally before anything leaves the machine, then analysed by a stateless remote agent. The user explicitly enables this. Nothing leaves by default.

---

Out of scope (decisions made)

• chat interface: not a CLI feature. If a conversational interface is built eventually, it belongs in a UI on top of the daemon, not as a CLI command.