---
title: Is my bug actually fixed? (the release ledger)
---

# Is my bug actually fixed?

## 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

No sibling library page is referenced here, so a reader who wants more should open [INDEX.md](INDEX.md), the library index, which lists the pages covering bug reporting and releases.