Track what shipped with Coverage

Approving a design is half the job. Coverage answers the other half: of everything we approved, what is actually in the code? For each approved release, it lists every change the release made and follows each one through your pull requests, using only what GitHub and M1rror's own checks report.

How an item moves

Each approved item has one of four statuses:

Status	What it means
Approved	The release approved it, and no pull request has changed it yet.
Implemented	A linked pull request's real diff changes it.
Verified	That pull request's current commit has passing evidence and no failing evidence.
Merged	GitHub reports the pull request as merged.

The headline counts them, for example 12 of 15 approved items shipped, and each item links to the pull request and files behind it.

What counts as an item

An item is one change the release made compared with the release approved before it. For a project's first release, that is everything compared with where the project started.

Item	Counts as implemented when
Token	A changed line in the pull request names its CSS variable (M1rror's name or your repository's own, such as --acme-color-accent) or its dotted path.
Component	A file the component is bound to in your code is in the diff.
Screen	The file the screen was imported from is in the diff.
Screen state	Only when a coding agent reports it done and the files it names are in the diff. A diff alone can't tell which state a change builds.

Read the Coverage tab

1. Open Coverage

   Open Ship mode › Coverage. It shows the latest approved release. If you have more than one, pick another with Approved release.

2. Filter the items

   Choose All, Left to ship or Shipped. Each row shows the item, its kind, its status and the pull requests that changed it, with the files.

3. Check the pull requests

   Pull requests lists every pull request behind the release: Opened by M1rror or Linked, its state (Open, Merged, Closed without merging, Branch, no PR yet or Not read from GitHub yet), its latest commit and how many files it changes.

Link a pull request to a release

M1rror's own implementation pull requests are linked automatically. A pull request your team or your coding agent opened can be linked in two ways:

• Add the release line to its description. Coverage shows the exact line to copy when nothing is linked yet. It looks like M1rror-Release: rel_… (v1.2.0, sha256:…). When GitHub tells M1rror about the pull request, it is linked if that release is approved and belongs to the project the repository is connected to.
• Let your coding agent link it with taste_link_pull_request. See connect a coding agent.

The release must be approved, and the repository must be connected to the project. Linking the same pull request twice changes nothing.

To read a linked pull request, M1rror uses a short-lived, read-only token for that one repository. It stores the paths of the changed files and the design values named on changed lines, never your code.

When an item counts as verified

A pull request is verified when its current commit has at least one passing record and no failing ones. Records come from:

• M1rror's own checks on that commit;
• evidence your coding agent submitted for the pull request, marked not run by M1rror;
• the pull request design check for that commit.

Pushing a new commit moves the pull request on, so it stops being verified until new evidence arrives. An item merged with no evidence shows Merged with Merged without recorded evidence.

Coverage on the pull request itself

When the pull request design check reports on a pull request that implements an approved release, its report adds an Approved release coverage section: the release's counts and which of its items this pull request changes.

If something looks wrong

• "Nothing approved to ship yet." Coverage starts once a release is approved. A newer release still in review is named but not counted until it is approved.
• "This release approved no changes." It matches the release before it, so there is nothing new to ship.
• An agent reported an item done, but it isn't counted. The row says Reported done, but the files are not in the PR diff: not counted. The files the agent named aren't in the pull request M1rror read.
• A pull request says "Not read from GitHub yet". M1rror hasn't been able to read it. The reason is shown with it; nothing is counted until it can.
• Work for an earlier release landed in a later release's pull request. Only pull requests linked to a release count for it, so that work counts for the later release.

Limits

• GitHub lists at most 300 changed files for a comparison. A larger pull request is marked as cut short.
• Token files in formats other than CSS (JSON, a Tailwind config or native files) count only when a changed line names the exact dotted path.
• Components and screens with no known file count only through a coding agent's progress report whose files are in the diff.