verify-in-production

First check whether you can observe it in the current session or whether a test already proves it — most changes file nothing. Only changes whose effect appears later, like a deployed site or converged repo, get a deferred verification issue filed.

File only after the PR has merged, never before, and only when the change has an observable effect that no test covers and that cannot be watched in-session. Filing early risks verifying a change that gets rejected or rewritten.

The coded form uses declarative URL probes executed by an agentless queue task, suited for public URLs. The agentic form runs an unattended GitHub-scoped session for reads like issue state, file contents at HEAD, or workflow conclusions.

No — an agentic run can only read GitHub within its routine's named scope, and cross-repo reads park on scope denial. If the artifact has a public URL, use the coded form instead; otherwise file nothing and report the change as unverified.

The run reopens the original issue with a comment stating what was asserted, what was observed instead, and where it was read. The verification issue itself then converges to done, since finding the fault was its job.

Not-before holds the item until just past the expected release moment, and Retry-every defines how far the field is pushed forward when the change is not yet live. This lets the queue re-adopt and re-check the item automatically without human intervention.