Ownership that expires.
A ticket is claimed with a lease. When the lease runs out the work is reconciled, not silently stolen.
A ticket standard for local-first coordination
Give the work a ledger.
Give the failure a reason.
fluxrecord is a ticket standard for local-first, evidence-driven coordination — built for people working across AI coding agents, CLIs, and terminal sessions.
flux art. One idea in five styles, with an optional ANSI gradient that honours NO_COLOR.01 / Quick start
One ledger, one command, one source of truth.
Zero runtime dependencies. The ledger is a SQLite file you own.
# install pip install fluxrecord # create the ledger and the project layout flux init # add a ticket with its acceptance criteria flux task-add M-0001 \ --objective "Add intake validation" \ --acceptance "Bad intake returns exit 2 with a named reason" \ --scope src/intake.py # claim it, then record what you actually did flux start M-0001 --owner agent-alpha flux checkpoint <session> \ --summary "Added intake validation" \ --evidence tests/test_intake.py \ --next "wire it into the CLI" \ --tokens 1200
02 / What it does
Bounded context, explicit ownership, visible failures.
The ledger separates a finished session from accepted work.
Checkpoints, not vibes.
Every checkpoint carries a summary, the evidence that backs it, the next step, and the tokens it cost.
The ledger exports to files.
Markdown tickets with front matter, an index, and one evidence file per checkpoint — the layout the specification describes.
GitHub as an outbox.
Durable observations and an idempotent outbox, so a public summary is never sent twice and never sent blind.
03 / See it work
The whole loop, in one ticket.
Every image is the real output of the real CLI, captured against a throwaway ledger. Nothing here is mocked.
decide accept moves it to done. Nothing else does.
flux benchmark compares the packet against the files the ticket names. Files that do not exist are not counted, so the comparison never flatters itself.
04 / The standard
A format other tools can check.
Versioned, frozen, and published as a schema somebody else can validate against.
Version 1, and frozen.
From wire format 1 onwards, changing the name of a field is a breaking change. The published schema is generated from the code, so it cannot describe the previous release.
Check your own.
The conformance suite runs a fixed sequence of commands against an implementation and checks every report against the published schema. It knows nothing about fluxrecord's internals.
What it will not do.
The core ledger opens no socket, runs no subprocess, and sends no telemetry. The adapters each declare their own. The threat model says what that does and does not protect against.