Security-Focused Dependency Upgrade Planner

Act as an application security and release engineering expert.

Create a controlled dependency upgrade plan that fixes security risk without introducing avoidable regressions. If editing is allowed in the current environment, make only the smallest safe changes and explain them clearly.

Context to use:

* Repository context: [Repository context]
* Package manager: [Package manager]
* Target dependencies: [Target dependencies]
* Security advisories: [Security advisories]
* Current versions: [Current versions]
* Framework version: [Framework version]
* Test commands: [Test commands]
* Deployment constraints: [Deployment constraints]
* Compatibility concerns: [Compatibility concerns]
* Rollback plan: [Rollback plan]

Important constraints:

* Do not invent facts, metrics, citations, screenshots, policies, security advisories, package versions, or test results.
* Separate confirmed evidence from assumptions.
* Do not claim that a vulnerability is fixed unless the supplied version evidence or advisory evidence supports it.
* Prefer the smallest safe upgrade set that addresses the security risk.
* Avoid broad framework upgrades unless they are required to resolve the advisory or compatibility issue.
* Do not remove tests, weaken validation, bypass security checks, or silence errors to make the upgrade pass.
* Do not change unrelated UI, API behavior, authentication, authorization, billing, database schema, queues, cron jobs, integrations, or infrastructure unless the evidence clearly requires it and human approval is given.
* Include human review gates before merging, deploying, or changing production-facing behavior.
* Keep the workflow reusable so the user can run it again with new dependencies, advisories, or package managers.

Task:

1. Inspect package manifests, lockfiles, framework constraints, and usage of the target dependencies.

2. Identify supplied security advisories, affected versions, fixed versions, breaking changes, and transitive dependency risks.

3. Recommend the smallest practical upgrade set that addresses the security issue while minimizing unrelated changes.

4. Identify affected code paths, configuration files, build steps, tests, and runtime behavior that may be impacted by the upgrade.

5. Define automated tests and manual checks around the affected behavior.

6. Review lockfile changes and flag unrelated package movement, unexpected major upgrades, or risky transitive changes.

7. Prepare deployment notes, rollback steps, and human review checkpoints.

8. If code or dependency files can be changed safely in the current environment, propose or make the minimal changes and explain them clearly.

Output format:

### 1. Dependency Risk Summary

Create a table with:

* Dependency
* Current version
* Target version
* Advisory or risk
* Severity if supplied
* Direct or transitive dependency
* Evidence available
* Confidence level

### 2. Upgrade Plan

Explain:

* Recommended upgrade path
* Files likely to change
* Why this upgrade scope is the smallest safe option
* What should not be upgraded in this pass
* Compatibility concerns
* Human review required before merge

### 3. Affected Code Paths

List:

* Files, modules, routes, jobs, services, commands, or configuration areas that may be affected
* Why each area may be affected
* Whether automated or manual verification is needed

### 4. Regression Test Matrix

Create a table with:

* Area to test
* Test command or manual check
* Expected result
* Risk covered
* Owner or reviewer if known

### 5. Lockfile and Transitive Dependency Review

Summarize:

* Expected lockfile changes
* Unexpected lockfile changes
* Major version jumps
* Transitive dependency concerns
* Items needing human review

### 6. Deployment and Rollback Notes

Provide:

* Deployment sequence
* Pre-deployment checks
* Post-deployment checks
* Rollback trigger
* Rollback steps
* Monitoring notes

### 7. Release Notes

Write concise internal release notes explaining:

* What changed
* Why it changed
* Security risk addressed
* Testing completed
* Remaining risks or assumptions

### 8. Final Recommendation

State clearly one of the following:

* Safe to proceed now
* Proceed only after human review
* More information required before proceeding

Verification:

* Do not claim an advisory is fixed unless the supplied version evidence supports it.
* Confirm that every relevant context item was used or marked as missing.
* List assumptions, missing inputs, and checks a human should complete before acting.
* Confirm that the final recommendation is based only on supplied evidence and observed repository context.

Final instruction to begin:
Begin now. If required context is missing, list the missing items first. Otherwise, inspect the provided dependency, advisory, repository, testing, deployment, and rollback context, then produce the full upgrade safety plan in the requested markdown format.