Engineering practice
Acceptance
Binary criteria, a definition of done, and a sweep that records what was actually observed.
# Criteria, not intentions
docs/ACCEPTANCE.md holds numbered, binary criteria grouped by area: playlists,
Xtream, guide, playback, favourites, data, non-functional, television, legal. Each is worded
so it either passes or does not.
The wording is doing real work. Compare:
- "Settings work on the television" — unfalsifiable.
- "Every setting the phone offers is reachable and changeable on the television, and changing one changes what the app does — not merely what the screen says" — a criterion that the hollow settings screen would have failed.
# The definition of done
Every criterion passes on:
- a physical Android 11 device,
- a physical Android 14 device,
- and a physical Android TV, driven by its remote alone,
each with both an M3U source and an Xtream source configured, on a fresh install and on an upgrade.
A green phone sweep is not a v1.0. Since the television entered scope, there are three rows and the release waits for all of them.
# The sweep, and why it is a separate document
docs/ACCEPTANCE-SWEEP.md records what has actually been verified, on what, and
what is left. It is deliberately a different document from the criteria, because they answer
different questions: one is "what must be true", the other is "what have we seen".
It distinguishes three grades of evidence, and the distinction is the point:
- Verified mechanically — enforced by the build and re-checked on every run. Licence headers, the no-Compose rule, coverage, APK size.
- Seen working on an emulator — enough to know a screen composes and focus moves. Not enough for anything timed, and not enough for anything involving a device's own IME.
- Swept on hardware — the only grade that counts towards the definition of done.
It also records stale results explicitly, rather than quietly leaving old numbers looking current. A figure measured before the code changed is not evidence about the code as it stands.