Write Dep Review

Naming

docs/phase-{N}/{N.X}_dep-review_{package-name}.md

Bundle multiple deps when they share context: docs/phase-2/2.1_dep-review_python-upgrades.md

Workflow

1. Motivation

Why is this dependency being added/upgraded? What problem does it solve?

2. Dependencies Under Review

Table: package, current version, target version, ecosystem. Document version pinning strategy for each lockfile.

3. License Audit

Check every package's license. Flag SSPL, AGPL, or non-OSI-approved licenses.

4. Security Audit

• Check CVEs (pip-audit, npm audit, GitHub Advisory Database)
• Assess supply chain health: maintainer count, bus factor, funding, ownership transfers
• Run OpenSSF Scorecard
• Check for typosquatting
• Verify package signing/provenance

5. Breaking Changes

For each breaking change: what it is, how many files are affected, what fix is needed.

6. Transitive Dependencies

List NEW transitive deps introduced. Check licenses and size impact. Assess runtime impact: cold start, memory overhead.

7. Maintenance Plan

Define: update strategy, update owner, breaking change policy, deprecation monitoring, fallback if abandoned.

8-10. Alternatives, Rollback, Decision

Alternatives only for new deps (skip for bumps). Rollback command. Approval decision.

Quality Checklist

• License is compatible with project
• pip-audit / npm audit shows no unresolved CVEs
• Supply chain health assessed (maintainer count, bus factor)
• Breaking changes identified with fix plan
• Transitive deps reviewed for license and size
• Maintenance plan defines who owns future updates
• Fallback plan exists if dependency is abandoned
• Rollback command is documented and tested