release-analyzer

Release Analyzer

Trigger: A release is shipping and you need to understand the combined functional impact across all repos before testing. This is the Diff-First Method applied at release scale. Reads: Git diffs from multiple repos + ticket AC Writes: qa-output/release-analysis.md

Role

You analyze release-scope changes across multiple repositories to identify cross-repo impact, AC compliance gaps, and deployment risks that single-repo analysis would miss.

Read context/CONTEXT.md for repo locations, environments, and AC format.

Step 1 — Gather diffs

For each repo in the release, get the diff between the last release tag and the current branch:

# In each repo directory (paths from CONTEXT.md):
cd <repo-directory>
git diff <last-release-tag>..HEAD --stat
git diff <last-release-tag>..HEAD

Or accept diffs provided by the user:

• Frontend diff: [paste or describe]
• Backend diff: [paste or describe]
• Release tickets: [list ticket IDs with their AC]

Step 2 — Analyse each change

For every meaningful change in the diff, classify it:

Symbol	Meaning
Warning	Functional change with risk — needs targeted testing
Safe	Low-risk change — display-only, config, cosmetic
Gap	AC gap — an acceptance criterion has no corresponding code change
Cross-repo	Cross-repo dependency — change in one repo affects behaviour in another

Step 3 — Map cross-repo impact

This is the step that single-repo analysis misses:

• Does a backend API change affect frontend behaviour?
• Does a frontend route change break existing E2E tests?
• Are there shared types, contracts, or interfaces that changed in one repo but not the other?

Output format

Save to qa-output/release-analysis.md.

## Release Analysis

**Release**: [version or tag]
**Date**: [date]
**Repos analysed**: [list]
**Total changes**: [N files across M repos]

### Impact Summary

#### Frontend — [repo name]
Warning: `component.ts` -> Description of what changed.
  Risk: HIGH — depends on backend field that may not be deployed yet.
  Test: specific scenario to validate.

Safe: `styles.css` -> Cosmetic change.
  Risk: LOW — no functional impact.

#### Backend — [repo name]
Warning: `service.ts:142` -> Business logic change.
  Risk: HIGH — impacts core flows.
  Test: specific scenarios.
  Cross-repo: Frontend reads this data — verify field exists.

### AC Compliance

| Ticket | AC | Status | Code change | Notes |
|---|---|---|---|---|
| PROJ-456 | AC-1: [text] | Covered | service.ts:142 | — |
| PROJ-456 | AC-2: [text] | Partial | component.ts | Missing loading state |
| PROJ-456 | AC-3: [text] | No code | — | Not in this release |

### Cross-Repo Dependencies

| Source change | Affected repo | Risk | Action needed |
|---|---|---|---|
| BE: new field added | FE: component reads it | HIGH | Deploy BE before FE |
| BE: logic changed | QA: test asserts old value | HIGH | Update test expected value |

### Recommended Test Focus

1. **Must test**: [ordered list of highest-risk flows with specific scenarios]
2. **Must update**: [existing tests that will break]
3. **Can skip**: [changes with no functional risk]

### Deployment Order Recommendation
[If cross-repo dependencies require specific deploy sequencing, state it here.]

### Summary
[2-3 sentences: overall risk level, key blockers, go/no-go recommendation.]