Development Conventions

Origin's daemon owns the local store that multiple AI clients read from and write to. A small boundary mistake can leak framework dependencies into core logic, change a public response shape, or make private data harder to inspect safely.

The conventions are intentionally practical: keep business logic in the core crate, keep public wire types stable, keep state snapshots short-lived, and keep user data out of public bug reports.

origin-core owns storage, retrieval, graph logic, pages, evals, and other business behavior. It should not depend on Axum or Tauri. origin-server should frame HTTP requests and call core logic instead of becoming a second business layer.

origin-types stays lightweight because it is shared by the daemon, MCP connector, CLI-adjacent tooling, desktop app, and downstream Rust clients. origin-mcp should deserialize daemon responses into typed structs so envelope drift fails loudly.

Use parameterized SQL instead of interpolated query strings. Preserve Option<T> as SQL NULL so unset values stay distinguishable from empty strings.

Rust strings are UTF-8, so avoid byte indexing for user content. Wrap multi-row mutations in transactions, and redact memory contents before copying diagnostics into public issues.

Do not hold long-lived state guards across awaits. Route handlers should clone the small pieces they need, drop the lock, and then call storage, LLM, or eval code.

This matters most around LLM calls, imports, distillation, eval paths, and any request that can take longer than a normal local HTTP round trip.

A source checkout can talk to the same product daemon and data directory that your installed Origin uses. For isolated development, run the daemon on a different port with a temporary data directory.

Worktrees have their own gitignored caches and generated artifacts. After squash merges, git cherry can mislead; verify integration by commit message, PR body, or the actual diff instead.

Add the smallest relevant test before changing daemon behavior, public wire shapes, MCP tool outputs, or retrieval semantics. Keep PRs narrow enough that reviewers can reason about them.

If a change affects what users install, run, cite, or troubleshoot, update the matching docs page in the same PR.