verify-paperclip

Topics in the source

• Verify Paperclip
• Select the verification target
• Deployment handoff
• Launch an empty checkout instance
• Doctor (owned checkout helper only)
• Drive
• Evidence
• Preserve failures through acceptance

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. 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;

This is an excerpt. Refer to the complete source and its current requirements.