Refactor Yasumu's architecture (prototype -> maintainable)

[twlite]

Context

The current Yasumu codebase represents a fast-moving prototype rather than a finalized architecture. This is the result of multiple iterations and rewrites (this is effectively the 5th rewrite so far), driven by limited time/resources and a focus on validating ideas quickly instead of polishing internals.

While this approach helped explore several important concepts, the accumulated complexity is now getting in the way of maintainability and clarity.

Current problem

At the moment, even a simple query flows through a long and tightly layered chain, roughly:

frontend
→ client SDK
→ platform bridge
→ custom RPC layer
→ Hono client (RPC)
→ Tauri fetch
→ Tauri IPC
→ embedded Deno runtime (HTTP server)
→ Hono server
→ custom Nest-inspired DI / module system
→ Drizzle + SQLite

This level of indirection is overkill for many core use cases and makes the system harder to reason about, debug, and extend.

Additionally, the frontend codebase was never taken seriously as most of the time was spent on other areas due to limited time and resources.

Why it ended up this way

This architecture was intentionally over-engineered early on to support long-term goals, such as:

• Running Yasumu headlessly in different environments (CLI, CI/CD, etc.)

• Reusing the same core logic across desktop, non-UI, and future platforms

• Experimenting with runtime-level capabilities by embedding a minimal subset of Deno

Embedding Deno, in particular, allowed experimentation in a Node-like environment while keeping things minimal and flexible at runtime. While the experimentation was valuable and opened the door for so many possibilities, the resulting structure reflects exploration more than a clean, stable design.

Why this issue exists

Now that the direction of the project is clearer and I'm pretty satisfied with how this rewrite turned out, the current architecture needs to be revisited and simplified. The goal is to reduce unnecessary layers, clarify responsibilities, and make the system easier to evolve without breaking existing user-facing behavior.

This issue exists to explicitly acknowledge the technical debt and to track a gradual redesign rather than continuing to pile changes on top of a prototype foundation.

Goals

• Simplify the request/data flow for common operations

• Reduce unnecessary abstraction layers where possible

• Clarify internal boundaries and responsibilities

• Improve readability and maintainability

• Preserve backwards compatibility for users during public beta

Non-goals

• No big-bang rewrite

• No breaking changes for existing users during beta

• No premature optimization beyond architectural clarity

Approach

Refactoring will be done incrementally alongside regular development. Internals may change significantly, but user-facing APIs, data formats, and workflows should remain stable.

[linear]

YAS-10