Lodestar

June 17, 2026 · View on GitHub

The life app — what you steer by. Capture an intention; query what's ready, blocked, and the highest-leverage keystone. The board is derived from a graph of claims, never hand-maintained.

Lodestar is a consumer of the Fram engine (a domain-neutral claim substrate). It supplies the life domain: the lifecycle projections, the cardinality vocab (FRAM_SINGLE_VALUED), capture conventions, time tracking, and the operating manual.

Run it three ways off one architecture — on your laptop, on a server you own, or as a multi-tenant service you host for others. No fork in the design; only the transport in front of the coordinator changes. See docs/hosting.md and deploy/. The conventions are still shaped around how one operator works — adapt the wrapper to your own setup.

Shape

  • EngineFram (~/code/fram): claims, Datalog, the coordinator daemon. The hard substrate.
  • Life domainsrc/lodestar/{projections,clock,clockify,staleness,audit}.bclj: the lifecycle derivations, billing projection, and staleness layer that make the engine a life app.
  • CLIbin/lodestar: aims the Fram engine at your data and sets capture provenance defaults. Life verbs (ready/blocked/leverage/next/agenda/ plate/capture/clock/…) route to lodestar.main; engine verbs (import/export/show/validate/tell/untell/…) route to Fram.
  • MCPbin/lodestar-mcp: the AI-facing edge — every tool maps to a tested CLI op through the coordinator write path.
  • Data → your own private store (the canonical claims.log, projected to ~/.local/state/lodestar/ at runtime). Data is not part of this repo.

Hosting

  • docs/hosting.md — the three modes (self-host single box, self-host remote, multi-tenant SaaS), the instance-per-tenant model, security, ops, and the roadmap.
  • deploy/Dockerfile, docker-compose.example.yml, systemd units, and the authenticated gateway (bearer token → tenant → that tenant's coordinator) with provision.sh + an integration test.

Docs

  • docs/HANDOFF.md — current project state: what's done & verified, what's pending (sequenced), the open decisions, and the engine↔app seam. Start here.
  • docs/operating-manual.md — the working manual: thread model, claim format, derived lifecycle, the CLI surface, and session behavior.
  • docs/claim-native-redesign.md — the design record for the claim-native model.
  • docs/PROPOSAL.md — the original vision and architecture.

Running and building

Running needs only babashka — the compiled Clojure is committed in out/ (no Beagle required at runtime), same as Fram. You need the Fram engine checked out too (FRAM_HOME, default ~/code/fram); bin/lodestar puts both on the classpath.

Lodestar links Fram's library API, so it's pinned to a specific Fram commit in FRAM_VERSION (CI and the Dockerfile read it). Fram's main moves independently; bump the pin deliberately when you rebuild out/ against a newer engine.

To rebuild from the .bclj sources you also need Beagle (the Lisp Lodestar is written in). build.sh links the engine sources in (src/fram, gitignored) and compiles the life-domain modules into out/; commit the result when sources change. Set FRAM_HOME/BEAGLE_HOME if they aren't at ~/code/fram / ~/code/beagle.

Tests

CP="out:$FRAM_HOME/out"
bb -cp "$CP" clock_test.clj
bb -cp "$CP" staleness_test.clj
FRAM_LOG="$FRAM_HOME/claims.log" bb -cp "$CP" cnf_lifecycle_test.clj
bash deploy/gateway/smoke_test.sh        # gateway auth + routing

License

MIT — see LICENSE.