01 / Pointing at the source of truth
Compile the examples that readers see
Rendered TypeScript and TSX snippets must live under examples/docs and be imported into MDX as raw source. The required build-check ties the displayed example to a maintained, compilable file.
Source excerpt starting at line 138.138- Every TypeScript or TSX snippet shown in authored docs must come from a compilable source file under `examples/docs/`, be imported into MDX with `?raw`, and pass `pnpm -F docs-code build-check`. Do not add ad hoc TypeScript or TSX fenced blocks directly to MDX. If an example is not useful enough to maintain and build-check as a complete source file, explain the behavior in prose instead. Do not add artificial runtime side effects, such as `console.log`, solely to mark declarations as used; the `examples/docs/` TypeScript project permits unused declarations so documentation examples can stay focused on the behavior they teach.
02 / Verification by change type
Classify documentation checks by the complete diff
Editorial, Content, and Structural tiers distinguish wording changes from changed claims, snippet wiring, navigation, and generators. The highest applicable tier determines focused checks across all task-owned files.
Source excerpt starting at line 44.44Classify the complete task-owned diff, including committed, staged, unstaged, and task-owned untracked files, by the highest applicable documentation risk tier. This section is the source of truth for documentation-specific verification; skills that edit or audit docs must reference these tiers instead of defining a second verification policy. These tiers add focused documentation checks only. They do not change the existing eligibility rules for `$implementation-final-review`, `$code-change-verification`, `$changeset-validation`, or `$pr-draft-summary`.
03 / Verification by change type
Look for stale ownership at asynchronous boundaries
Review awaits, callbacks, retries, reconnects, cleanup, and rollback for stale ownership. Findings must name the concrete interleaving and missing invariant.
Source excerpt starting at line 100.100- When changed code mutates shared state across an `await`, callback, retry, reconnect, cancellation, cleanup, or rollback boundary, check whether stale or failing work can overwrite, revert, or dispose state owned by surviving work. Report the concrete interleaving and the missing ownership, generation, identity, transaction, revalidation, or serialization invariant at the actual mutation boundary; sequential happy-path tests are insufficient.
04
Keep persisted data from granting runtime authority
Serialized state, manifests, and provider data cannot control host-owned security, identity, or cleanup decisions without a supported trust boundary.
Source excerpt starting at line 102.102- Flag persisted, resumed, serialized, provider-controlled, or manifest data that is treated as authority for a host-owned runtime, security, identity, or cleanup decision unless the supported trust boundary explicitly grants that authority. Preserve trusted current configuration and validate untrusted state before it can affect side effects, replay, or resource ownership.
05 / Behavioral framing
Make a runtime finding prove a supported consequence
Review comments must connect changed code to incorrect behavior on a supported path. A constructible typed value, alternate semantic preference, or imagined symmetry does not establish a defect on its own.
Source excerpt starting at line 88.88- Report a runtime defect only when the changed code causes a concrete incorrect behavior on a supported path. State the triggering scenario and the caller-visible, compatibility, security, persistence, or lifecycle consequence; omit the finding when no such consequence can be established.
06
Reuse scripted doubles except at their fidelity limit
Reuse shared doubles for models, realtime transports, and sandbox sessions. A specialized replacement needs a documented fidelity gap such as wire conversion, concurrency, or exact abort delivery.
Source excerpt starting at line 202.202- For provider-neutral agent workflow tests, prefer `ScriptedModel` over a new mock or fake `Model`. Prefer `ScriptedRealtimeTransport` for Realtime session tests and `scriptedSandboxSession()` for deterministic Sandbox calls. Keep a specialized double only for provider-wire conversion, malformed streams, controlled suspension/concurrency, or exact abort/lifecycle delivery that the scripted utilities cannot preserve; document that boundary in the test.
