Is my bug actually fixed? (the release ledger)

What it is

When you report a bug in Omniscio, a session is started to fix it. Until now, nothing ever checked whether that session actually fixed anything — the report just sat there saying "Building", forever, whether the fix shipped weeks ago or never happened at all.

The release ledger answers two questions the app previously could not:

• Which reported bugs are really fixed — and are they in the version I'm running?
• Which features have actually shipped, rather than just being finished?

Where to find it

Where you see it

On the Report Tracker board (Bug Intake → Tracker). A report that has been traced to real landed work now reads Fixed, and the card shows its receipts — how many changes landed and which release carries them, for example "5 changes · in v0.1.105".

On the command line, for the wider picture including features:

npm run release:ledger                 the last 45 days
npm run release:ledger -- --days 14    a narrower window
npm run release:ledger -- --markdown   a paste-ready block
npm run release:ledger -- --json       the raw data

Omniscio needs to be running — the command asks the app rather than guessing where your data lives. It only ever reports; it never changes anything.

How it behaves

How it knows

Every commit already carries a hidden stamp naming the session that wrote it, and every bug report already records the session that was started to fix it. Nobody had ever connected the two. The ledger follows that trail:

your report → the session started to fix it → the commits that session actually wrote → the release those commits are in

Nothing is guessed. If a report can't be traced, it says so rather than inventing an answer.

What each answer means

You'll see	It means
Fixed and released	Real changes landed and they are in the release named — you have the fix.
Fixed, ships in the next release	The work is done and on master, but no release has been cut yet.
Being worked on now	A session is still live on it. Nothing has landed yet, which is not a failure.
Finished with no code change	A session looked at it, finished, and left nothing behind. This is the bucket worth reading.
Cannot be traced	Filed before commit stamping began (8 September 2026). Unknowable, not unfixed.

Two honest limits

"Finished with no code change" does not always mean dropped. Some things are fixed by a setting, a cloud-side change, or a decision not to build a requested feature. Each entry shows whether it was a bug, a feature request, or feedback, so you can tell those apart at a glance.

The count is the fixing session's landed work, not only that one bug. A session sometimes does more than the bug it was given. That is exactly why both the board and the command line print the actual change descriptions — so a weak match is something you can see, rather than a number you have to trust.

Why "Fixed" and "Done" are different

They are not synonyms, and the difference is the whole point.

• Done is a guess: the session that was investigating stopped running. That says the investigation ended, not that anything was repaired.
• Fixed is evidence: real commits were traced to the report, and the ledger can show them.

Before this existed the board only had the guess, so every finished report looked identical. Now Done means what it always should have: finished, with no code change behind it.

Related

The ledger records what shipped; these two are the other live records of what happened.

• Job monitor — the live view of the background jobs running on this machine.
• Session event log — the per-session record of what happened, in order.