Skip to content
g! grite refs/grite/wal grite init
About

The tracker belongs in the repo.

Every project we have ever shipped has had two parallel realities. There was the code, in git, with a clean history and merge rules everyone respected. And there was the issue tracker, somewhere else, with a different access model, a different audit story, and a different copy of the truth.

Grite is built on the bet that this split was never necessary.

The problem we kept hitting

The traditional issue tracker assumes a single authoritative database, a permissioned UI, and a developer who context-switches into it between code edits. That model worked when issues were rare and humans were the only authors. It breaks the moment two new pressures arrive at once: AI coding agents that want to participate in the queue at human speed, and small teams that want to ship without paying an annual SaaS bill for state that arguably belongs in their own repo.

External issue trackers add latency, require credentials, and create a hard dependency on internet connectivity and third-party services. State files in the repo pollute the working tree, create merge conflicts, and clutter code reviews with non-code changes. Chat-context memory is limited, ephemeral, and not shareable between sessions. Database-backed trackers require setup, maintenance, and backups.

The right fix is not a better hosted tracker. It is to move the storage layer into the same place we already trust with code.

What grite actually is

Grite is a repo-local, git-backed issue and task tracking system. Events are appended to refs/grite/wal as CBOR-encoded chunks, optionally signed with Ed25519. A local sled database materialises the current state of every issue from those events using deterministic CRDT semantics. The CLI works standalone; an optional daemon keeps the materialised view warm and serialises concurrent access.

The crate structure splits responsibility cleanly: libgrite-core for events and projections, libgrite-git for the WAL, libgrite-ipc for the daemon protocol, libgrite-cli as a programmatic API, and the two binaries. Each crate is independently useful — embed the storage engine in your own Rust project, or use git as a WAL backend for a different event-sourced system. The MIT licence is honest.

Why agents are first-class

AI coding agents face a memory problem. They start fresh every session, forget what they were working on, and cannot see what other agents have done. The existing answers — chat-context windows, brittle state files, hosted APIs — all fail in ways that compound rather than cancel out.

Grite gives any number of agents persistent, shared, conflict-free memory. grite init writes AGENTS.md, a discoverability convention that AI coding agents read automatically. From there, an agent can claim a lock, store learnings as --label memory issues, and read the accumulated context of every prior agent on every cold start.

The CRDT merge means two agents editing simultaneously cannot produce a conflict. The distributed lock layer means they cannot claim the same resource. The signed event log means an audit can prove which agent made which change. This is what "agent-native" means when it is not a buzzword.

Design principles

  1. Git is the source of truth. All state is derivable from refs under refs/grite/*. The sled view is a cache.
  2. No working tree pollution. Tracked files are never written, except for AGENTS.md, which exists because agent discoverability is more useful than purity.
  3. Daemon optional. The CLI works standalone. The daemon is a performance optimisation, not a requirement.
  4. Deterministic merges. Any two valid WALs can merge without conflict, and the result is the same regardless of merge order.
  5. Per-actor isolation. Multiple agents can work independently on the same machine or across the network without coordinating writes.
  6. Offline-first. Every operation works without network. Sync is an explicit, optional step.
  7. Cryptographic provenance. Optional Ed25519 signing makes the audit trail tamper-evident and non-repudiable.

Who is building this

Grite is a project of Neul Labs. We build tools for the next generation of agent-native engineering — small, sharp utilities that compose with the rest of the unix and git toolchain rather than wrapping it. Grite is the issue layer of that thesis. There are others coming.

How to engage

If you want to try grite, the one-line install is on the home page. If you want to read the implementation, the workspace is on GitHub at neul-labs/grite; the Rust API is on docs.rs. If you want to discuss design, the GitHub Discussions tab is the most reliable place to find us.

If grite is wrong for your team, we would like to know why. The point is to take the friction out of issue tracking, and the way you find friction is to listen to people who hit it.