Post-Merge Check

Prove three separate facts in order: the change merged, the intended runtime received the expected artifact, and the changed user behavior works there in a fresh session. Never let one fact stand in for the next.

Post-Merge Check may inspect remote state, wait for pipelines, read logs and observability, and exercise ordinary non-destructive flows on an explicitly identified test, demo, or staging target. It does not deploy, roll back, change configuration, touch a different environment, send messages, or perform durable, costly, destructive, or production test actions without explicit authorization.

Entry contract

Resolve these identities before testing:

• merged pull request and merge result;
• expected source revision, merge commit, release tag, image digest, or artifact identifier;
• intended environment and exact host or service;
• relevant frontend, API, worker, realtime, or background components;
• approved test account, tenant, device, browser, and data;
• original ticket or user-visible acceptance criteria.

Do not choose the environment from whichever deployment dashboard is easiest to access. If target or allowed test side effects are ambiguous, stop before interaction and ask.