PATTERN Cited by 1 source

Preview-package reporter-verification gate¶

Intent¶

Publish a candidate package from an automated repair and ask the original reporter to validate it in the environment where the issue occurred before escalating the patch to a pull request.

Structure¶

candidate patch
  → package preview
  → issue comment: summary + logs + installation instructions
  → reporter tests against original project
  → explicit confirmation
  → workflow records verification and opens linked PR

Astro uses pkg.pr.new for the preview artifact and moves the issue to fix verified only after reporter confirmation. (Source: sources/2026-08-04-cloudflare-astro-issue-triage)

Why use an external reporter gate¶

The original application is often the only environment that contains the exact dependency graph, configuration, data shape, or integration timing that exposed the defect. Reporter confirmation is therefore a targeted complement to local reproduction and automated tests, not a replacement for them.

Risks and safeguards¶

Treat a reporter confirmation as evidence for the reported case, not an authorization to bypass maintainer review or CI.
Make preview installation instructions clear and reversible.
Protect the workflow against impersonated, ambiguous, or stale confirmations.
Retain the preview version, logs, and patch identity so confirmation can be tied to a specific artifact.
Expire or garbage-collect previews carefully; the source does not state pkg.pr.new retention semantics.

Seen in¶

sources/2026-08-04-cloudflare-astro-issue-triage — Astro’s triage workflow gates PR creation on reporter validation of a pkg.pr.new package.