What Counts as Proof?

i-have-adhd makes two different kinds of claims: its integrations should obey explicit technical contracts, and its response style may improve how people judge or use assistant answers. This chapter separates the evidence for those claims. It examines the repository’s tests and CI first, then interprets the paired evaluation and its recorded results. Readers will see why a passing hook test, a higher weighted score, and a release-ready candidate are three different conclusions.

The verification stack catches different failures

A single “tests passed” statement would be too coarse for this project. The canonical skill is text, the platform integrations are executable adapters, the hosts have their own loading behavior, and the evaluation harness makes empirical claims about responses. Each layer can fail independently. The repository’s verification strategy reflects that separation.

At the policy layer, a test can check that the skill remains explicitly invoked rather than silently activated. The Pi/OMP package test reads the frontmatter and confirms the skill name and its disabled implicit invocation setting. This does not prove that a model follows the rules. It proves that the packaged policy retains a user-control property.

At the adapter layer, isolated tests execute the hooks and plugins in temporary environments. The hook tests create a temporary configuration directory and plugin path, run the available native runtimes, and inspect their actual output. They check silence when the opt-in flag is missing, removal of frontmatter when it is well formed, preservation of content when the frontmatter fence is unclosed, and clean handling of a missing plugin root. OpenCode tests perform a similar job for skill-path registration, command creation, preservation of an existing command, malformed command metadata, and repeated configuration.

These tests ask whether the adapter implements its local contract. They do not ask whether a user likes the resulting prose or whether the model obeys every rule. A hook can produce the correct banner and still be attached to the wrong host event. A command can be registered correctly and still not be visible in a particular host release. Testing the adapter is necessary because those failures occur before response quality can be measured.

The context compatibility checks cover another boundary. The Pi/OMP helper accepts two different shapes for a session manager, prefers the OMP-style context builder when available, falls back to the Pi-style entries API, and returns an empty result when an unsupported or failing context interface cannot be inspected. Its tests verify marker order and ensure that ordinary user or message entries cannot activate the mode by accident. This is evidence about the state machine’s interpretation of context, not a claim that every future host API will have the same shape.

Runtime smoke tests go one step further. The Pi/OMP smoke script runs an isolated agent process without making a model request.