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.