Skip to content
Impact Gate Impact Gate Impact Gate

Release Readiness

Ship with confidence

Compare the current candidate to the last shipped tag, review the changed flows, and turn that delta into a ship-focused E2E plan. This keeps release readiness grounded in evidence instead of prompt-only guesswork.

Typical release diff

Use the last shipped tag as the baseline

npx impact-gate impact --path . --since v2.1.0 npx impact-gate plan --path . --since v2.1.0 npx impact-gate gate --threshold 80 --path .
What it answers

Release comparison turns one delta into a reviewable plan

  • Compare the current release candidate to the last shipped tag
  • Determine which flows changed
  • Review which tests already cover those flows
  • See where more testing or manual validation is still needed

That tells the tool: “treat v2.1.0 as the already-shipped baseline, and build the test plan for everything that changed after it.”

When Teams Use This

Release cadence

Common release scenarios

  • release branch vs previous stable tag
  • release candidate vs last production release
  • hotfix branch vs current production tag
  • milestone validation before a coordinated rollout
Why teams use it

The plan becomes a QA review packet

Teams use the written artifacts for release notes, QA sign-off, and a shared view of what changed between shipped versions.

01

Run impact to inspect the raw changed families

Start with the deterministic view of what changed between the shipped release and the current candidate.

02

Run plan to produce run sets and gap analysis

This is the moment where the diff becomes a release-specific test plan.

03

Review the written artifacts with QA and release owners

Use .e2e-ai-agents/ci-summary.md and .e2e-ai-agents/plan.json as the shared evidence layer.

04

Gate the release when you need an explicit threshold

Use gate for a pass/fail decision once the manifest is trustworthy enough to enforce.

05

Add targeted generation only if the remaining gaps matter

AI generation should follow the plan, not replace it.

Artifacts To Review

The release-readiness path is most useful when you inspect the written artifacts, not just stdout:

Plan

.e2e-ai-agents/plan.json

Structured run sets, confidence, gaps, and decisions.

Summary

.e2e-ai-agents/ci-summary.md

Human-readable release review notes for PRs and sign-off.

Metrics

.e2e-ai-agents/metrics-summary.json

Aggregated metrics for dashboards, audits, and CI reporting.

These artifacts are useful for release notes, QA sign-off, and CI reporting.

Example Release Checklist

Checklist

Questions to answer before you ship

  • Has every P0 or P1 impacted family been reviewed?
  • Is the run set small enough to be actionable?
  • Are there any must-add-tests decisions?
  • Are there changed files with no family mapping?
  • Are there risky areas with low confidence?
  • Do the generated or existing specs still need manual verification?
CI pattern

Keep release readiness grounded in evidence

Use the deterministic plan on every release-candidate branch first. Then add AI generation or healing only when the route-family manifest is already reliable enough to trust. That keeps release readiness from turning into a prompt-only exercise.