Events in refs/grite/wal
Every issue mutation is stored as an event under a dedicated git ref — refs/grite/wal — so your working tree stays clean and code review never scrolls past tracker noise.
Everything grite does
grite keeps issue tracking native to development: the issues live in git refs, merge deterministically, and are built for agents and humans. Here is the whole feature set, grouped by what it is for.
Git-native storage
The issues live in your repo, not a database. If you can git push, you can sync.
Sync is git fetch / git push
No API keys, no service accounts, no third-party uptime. The WAL travels through the same remote you already push code to, and you have it offline the moment you clone.
git 2.38+ is the only dependency
grite needs nothing but a recent git. No server to run, no database to provision, no account to create.
Event log & encoding
An append-only, content-addressed log — tamper-evident by construction.
Append-only event log
Issues are never edited in place; each change appends a new event. The full history is immutable and always reconstructable from the log.
CBOR-encoded events
Events are serialised as compact CBOR — a binary, self-describing format that stays small in the WAL and fast to decode.
Content-addressed integrity
Each event is addressed by a cryptographic hash of its payload. Change any byte and the chain breaks, so history cannot be silently rewritten.
Deterministic merge
Two agents, two branches, zero conflicts. The merge result never depends on order.
CRDT semantics
grite merges concurrent edits with conflict-free replicated data type rules — last-write-wins on scalar fields, commutative sets on labels and dependencies.
No merge conflicts
Any two valid WALs merge cleanly. The result is identical regardless of merge order, and no edit is silently dropped.
Branch and merge with the code
Because issues live in git, they branch when you branch and merge when you merge — the tracker follows the same history model as your source.
Provenance & signing
Optional cryptographic proof of who wrote what, for audit and compliance.
Ed25519 signatures
Events can be signed with a per-actor Ed25519 key, giving non-repudiable provenance for every issue mutation.
Tamper-evident WAL
The append-only, content-addressed log is tamper-evident: any modification invalidates the hash chain and is immediately detectable.
Data stays in your infra
Sensitive issues never leave the systems you already control — there is no external service holding your task graph.
Interface & distribution
One CLI, an optional daemon, and every package manager you already use.
Single CLI
grite is one command-line binary. Create, list, and close issues from the terminal, with structured output for scripting.
Optional daemon
grite-daemon keeps a materialised view warm and serialises concurrent calls. It is a performance optimisation, not a requirement — the CLI works standalone.
Six install channels
Distributed via Cargo, npm (grite-cli), pip (grite-cli), gem (grite-cli), Homebrew, and Chocolatey — pick whichever fits your stack.
Built for agents
Designed so AI coding agents are first-class issue authors from day one.
Agents as first-class authors
grite is built for AI coding agents and humans alike. Agents can open, update, and close issues as a durable, shared memory across sessions.
Deterministic multi-agent work
Because merges are conflict-free, several agents can work the same task graph in parallel without stepping on each other.
Repo-local memory
The task graph lives with the code it describes, so any future agent that clones the repo inherits the full context.
Put the tracker back in the repo
Install grite, run grite init, and the next time you git push your issues go too.