V1 completion and verification audit

This audit answers #83: how much of v1 is built, and how much of it has been tested, on one fixed revision. It is a snapshot taken on 6 November 2026. It owns no fact of its own. Release scope owns what v1 is, the acceptance ledger owns acceptance results, known limitations owns limitations, and GitHub Issues own the work. When this page and one of those owners disagree later, the owner is right.

Audited revision

Evidence gathered on this revision:

• Automated tests. CI run 42036549784 on 6edff137 passed every job on attempt 2. Attempt 1 failed one engine test, slice_photos::a_press_while_a_revealed_photo_waits_never_shows_its_window_beside_it. The previous commit 3668b75a has the same engine code and passed, so this test is flaky.
• Lifecycle model check. make verify-engine-lifecycle exited 0 on 6edff137. All seven rules hold in 196 states, all three mutants break as expected, and the covered code is unchanged since sync commit f9d4ab38.
• Native run. verify-miri run 20261106-090237 drove the tested artifact with synthetic key presses and Accessibility presses on the hardware above. It is an automated native observation, not a hand check, and its files stay on Sam's Mac in ~/.cache/miri/verify-miri/runs/. The results are in Observed on the audited revision.

Status words

Each requirement below gets the furthest status that has evidence. The statuses are separate kinds of evidence, and a later one does not imply an earlier one.

On 6edff137, no requirement is hardware accepted, because no release candidate is frozen and every ledger check is Pending. No requirement is published, because Miri has no release. Every native and hand check below ran on an older revision than 6edff137, except the native run of 6 November 2026. An older result is stale when code it covers changed afterwards. The notes say so where PROGRESS.md or an issue records such a change.

Summary

The denominator is the 98 requirements in the requirement map. Each one is an accepted rule from release scope, split as the map shows, plus #302, which Sam accepted into v1 on 5 November 2026. A requirement counts as complete for a status only when the whole requirement reached it. Counted on 6edff137 with a script that reads the map's tables:

The automatically tested count includes 3 partly built requirements whose built part has tests. The native and hand count includes results on old revisions, so it says what was ever seen, not what holds now.

The acceptance ledger has 105 checks: S-1 to S-7, 70 app checks, and 28 multi-monitor checks. 0 of 105 pass, because none has run on a frozen release candidate. 0 of 3 required full runs have passed.

Feature work and release readiness are separate:

• Features. Most accepted window-management behavior is built and automatically tested. The gaps are new-window width (#305), the swipe target and its setting (#212), the login item state (#201), Karabiner-Elements and Hyper key support (#302), and undoing macOS tiling after a drop on another display (#123).
• Release. None of the signing, notarization, update, or Homebrew work exists (#82), no release candidate is frozen, and no acceptance or endurance check has passed.

Requirement map

Columns:

• Built is Built, Partly, or Not built.
• Tests names the automated coverage, or None.
• Latest native or hand evidence names the newest observation on real hardware, its kind, and its revision. Native means natively tested with synthetic input, and Hand means hand checked by Sam.
• Checks are the acceptance ledger rows that verify the requirement.

Abbreviations: SC is Sources/MiriCore, SM is Sources/Miri, E is vendor/paneru/src, T is Tests/MiriCoreTests, ET is vendor/paneru/src/tests, and TLA is the lifecycle model check.

App controls and window recovery

Privacy and diagnostics

Default shortcuts and layout

Startup and crash recovery

Setup and conflicts

Configuration

Supported platforms

Multiple monitors

Display changes

Strip gestures

Settling after a swipe

V1 interactions

Stacks

Dragging windows

Maximizing a window

System access and licence

Signing, distribution, and updates

These rows are part of the denominator. Packaging, distribution, and endurance reports them in detail.

Observed on the audited revision

verify-miri run 20261106-090237 on 6 November 2026 drove the tested artifact on the hardware above. Each line is an automated native observation with synthetic input. None of them passes a ledger check, because none ran on a frozen release candidate.

The 6 November run did not drive Restart, the crash limit, Quit, setup checks, or shortcut editing. Run 20261105-160539 on c4ba432e drove all of them except Quit. The app code for the lifecycle, setup checks, and shortcut editing is unchanged from c4ba432e to 6edff137, and only the engine pin moved.

Partial behavior, missing checks, known failures, and stale evidence

Known failures

• New windows keep their own width instead of 50% (#305, observed on 6edff137).
• A drop on another display that macOS then tiles stays tiled (#123). Sam kept this case in v1 on 6 November 2026, so it is a gap in v1, not a deferral.
• One Arrange sheet drag in 36 moved System Settings into the other display's strip. Sam accepted it as a limitation when #103 closed.
• The engine test slice_photos::a_press_while_a_revealed_photo_waits_never_shows_its_window_beside_it is flaky in CI.

Reports not reproduced

#78, #122, #166, #177, #210, #265, and #280 are open without a reproduction on a current build.

Checks with no evidence on any revision

AP-3, AP-4 for tools other than the four detected, AP-5, AP-7, AL-1, AL-4, AW-1, AW-2 with windows known to be off screen, AW-6, AC-2, AC-5, AC-6, AS-5 as a pass, AS-10, AS-12, AG-16, AU-1, AU-2, AU-4, AU-5, AR-1 to AR-3, HA-3, HD-1 to HD-3 at their required counts, HD-5 to HD-7, HR-1, HE-1, and HE-2.

Stale evidence and records

• Every native and hand result in the map, except the 6 November run, predates a5853509. Later changes touched key handling (#279 and #104, 4 Nov), startup focus (#248, 4 Nov), stack rejoining across Spaces (#144, 5 Nov), and new-window tiling (#249 and #250, 5 Nov).
• Known limitations still names main at fabf16d4 and engine 589b44b as its baseline. It lists the Mission Control drag as a confirmed defect, but #143 closed with a verified fix on 3 November. It lists swipe lag as a confirmed defect, but #66 closed as not planned on 5 November, after Sam could no longer reproduce it. It lists the 8-point drag gap as a confirmed defect, but #122 did not reproduce on 6edff137.
• Design tree status says it was reconciled with main at e516edd on 20 October.
• #302 moved Hyper key recording into v1 on 5 November, but release scope, the keybinding reference, the v2 roadmap, design tree status, and the v1 specification still defer it to v2.
• #278 is still open, although Sam decided it and #282 is merged.
• These closed issues left acceptance boxes unticked, or their closing comments name a hand check that is still open: #42, #43, #44, #106, #159, #183, #199, #205, and #219.

Remaining blockers

Owners come from issue comments and PROGRESS.md. No issue has an assignee.

Packaging, distribution, and endurance

These requirements gate a public release, not feature completion.

Q6

Release scope describes one 2-week daily-use period across both locations. The multi-monitor checklist requires 3 consecutive full runs, and each full run includes that 2-week period, which implies 6 weeks. Q6 asks how the two combine. On 15 October 2026, Sam deferred Q6 to the final check before publishing v1, as design tree status and the v1 specification record. Until then, both requirements stay as written. This audit keeps Q6 deferred, and nothing on this page depends on its answer.

The 17 feedback requests

#77 to #93 came from 17 points of feedback, one issue per point. Their own text puts 13 in v1, of which 10 are release blockers, and 4 in v2. #83 is this audit.