Skip to content
Impact Gate Impact Gate Impact Gate

Release Readiness

Release review context

Compare the current candidate to the last shipped tag, review the changed flows, and inspect candidate specs and mapping gaps. Use that context alongside actual test execution and your existing release criteria.

Typical release diff

Use the last shipped tag as the baseline

npx impact-gate review --path . --since v2.1.0 npx impact-gate review --path . --since v2.1.0 --scenarios-output scenarios.json npx impact-gate gate --threshold 80 --path . --since v2.1.0
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 existing specs are associated with those flows
  • See where more testing or manual validation is still needed

These commands compare HEAD against its merge base with v2.1.0. When the tag is an ancestor, that is the tag itself. Invalid or ambiguous histories fail explicitly; the report must not be treated as an empty comparison.

The gate enforces spec-mapping presence, not measured behavior coverage or release approval. Partial mappings are separate, and unassessed changes fail. The Mattermost advisory pilot emits a nonblocking report and retains the existing full suite.

These docs describe the current source; the new export and recovery changes have not been published as a new npm release. Build the checkout and use node /path/to/impact-gate/dist/cli.js in place of npx impact-gate to use those changes. Lower-level impact and plan workflows below remain experimental.

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.