Verify Paperclip

Read the map contract, then use the feature map to select user verification recipes. For API/agent access, read the same-named agent access companion and use the actual permitted agent identity, target and work mode. Follow existing API/runner/MCP fixtures for access proof; a board request does not prove agent access. Report recipe or access drift with evidence; map updates belong to maintain-verification-skill. Read development instructions for current commands.

Select the verification target

State what is being tested before starting. Use the requested target; for ordinary feature development, default to the current checkout on the current host with isolated data. Expand into cross-platform or release qualification only when requested or needed to reproduce the problem.

Record these independent dimensions together:

• Artifact: source checkout (path, commit, dirty state), published npm package (requested channel and resolved exact version), or deployed image/release.
• Environment: local, staging, or production; target URL and intended company or workspace; board/user/agent identity and authentication mode.
• Starting data: fresh and unonboarded, freshly seeded, cloned, or reused; embedded versus external PostgreSQL; configuration/data location or a redacted database identifier. Never record credentials or connection strings.
• Platform: server OS/architecture, Node/npm versions, and browser/client OS when relevant. A Mac browser against a Linux server is Linux server evidence; WSL is Linux evidence, not native Windows evidence.
• Journey: first installation/onboarding, an existing-user feature, upgrade, or a live agent run; expected outcome and real versus simulated dependencies.