Token Meter Verification

---
name: token-meter-verification
description: Use when Token Meter changes or claims need independent source, test, runtime, native, browser, privacy, or platform verification.
---

# Token Meter Verification

## Purpose

Independently verify the task envelope's acceptance criteria against one exact head.
Do not modify tracked files or repair failures while acting as tester.

## Build the verification matrix

Read `specs/AGENTS.md`, the task envelope, developer result, current diff, and
`.agents/workflow/review-policy.yaml`. Select checks from the surfaces the diff can
affect:

| Surface | Evidence |
|---|---|
| Python and contracts | Focused tests, full suite when proportionate, and `py_compile` |
| Dashboard | Embedded-JavaScript parse plus live wide-desktop and 1024-pixel-laptop interaction checks |
| Native menu | Swift compile, deterministic smoke output, and live menu behavior |
| Packaging | Installer syntax, manifest coverage, installed-runtime revision, and source/runtime parity |
| HTTP behavior | `/health`, relevant endpoint payloads, cache/privacy boundaries, and failure states |
| Cross-platform | Target-host parse, launch, interaction, update, and uninstall evidence |

Run focused checks first, then the broader checks required by risk. Synthetic fixture
passes do not replace real upstream, installed-runtime, or visible behavior where the
acceptance criteria depend on them.

## Evidence rules

- Record the command or interaction, outcome, and inspected head.
- Use `passed`, `failed`, `blocked`, or `not-run`; never turn missing evidence into a
  pass or measured zero.
- Separate source checks from live installed behavior.
- Confirm source/runtime parity after installation rather than assuming the checkout
  is what the user sees.
- Preserve exact target-host limitations. macOS evidence does not prove Windows or
  Linux behavior.
- Stop and report a failure; return the change to the developer instead of fixing it.

## Tester result

Return acceptance-criteria coverage, commands and live checks, counts where useful,
the exact head, failures, not-run checks, unverified behavior, blockers, and the
recommended next state. A later tracked code or test change invalidates the result.