Skill: Write a Spec

Do not write one when…

• An existing journey spec covers the behaviour; extend it.
• The change is a pure function; write a colocated unit test, not evidence.
• You would import ../../apps|packages|ee, read source files, or spawn another test runner. That is a unit test in disguise; the boundary ratchet rejects it.

One spec per user journey, not per PR; bug fixes add an assertion to the journey they escaped from.

Write new tests in evals/specs/**/*.test.ts and import test from @omnirush/testkit. App-driving E2E tests use .e2e.test.ts; the PR lane excludes them. Model setup as resources in dependency order: needs() → server() → app().

Use the testkit primitives

• server() boots or reuses Den and provisions isolated organizations.
• app() boots a signed-in desktop. Use profileDir for caller-owned profile continuity and localServerDelayMs for deterministic startup races.
• inviteMember() adds a named member to an existing Den.
• faultProxy() injects faults.status() or faults.latency() and exposes the requests log for assertions about attempts and recovery.
• eventually() bounds polling and reports its last value or error.
• readDenClientState(), readConnectState(), and readConnectStateFile() expose client, local-server, and persisted-profile state.

Claims and witnesses