QA: CLI, MCP, and API

Default to the smallest set of programmatic-interface lanes that can prove the change. Automated tests are necessary but do not replace a live smoke test when the changed boundary is only exercised by a real client or deployment.

This QA workflow is independent from releasing. A release request alone does not invoke it, and its results do not approve or block a release.

Choose the scope first

Inspect the exact branch, commit, or diff and map changed code to its direct consumers before creating fixtures or credentials. In a GitButler workspace, use but status and but show <commit-or-branch>; do not use the synthetic workspace HEAD as the candidate or combine unrelated applied branches.

Find the original reproduction in the current or past Codex task, linked issue, PR, support report, or regression test. State the selected lanes and the reason for each before testing.

Targeted regression mode (default)

Select lanes by behavior, not by the existence of this checklist:

• CLI parsing, output, or local DB access → CLI plus the closest contract tests.
• Webhook endpoints, signing, or delivery retries → the webhook cases only.
• Shared agent-access DTOs, exports, filtering, or pagination → every direct consumer, including hosted REST or remote MCP when affected, plus cross-surface parity only for the changed fields.
• Hosted auth, snapshots, entitlements, isolation, purge, or Supabase policy → the affected hosted REST lifecycle and negative cases.
• Local or remote MCP protocol/tool changes → that MCP lane and its direct transport/contract dependency.
• Shared hosted REST/MCP behavior → both hosted consumers, but not unrelated local surfaces.