sdlc-technology-upgrader

# sdlc-technology-upgrader

Scans a codebase to produce a structured technology inventory, policy compliance summary, and upgrade dependency graph. This skill does the data collection; the Technology Upgrade Agent interprets the results and writes the playbook.

## Responsibility

Read manifests, config files, and toolchain definitions. Output a structured inventory of every technology component with current version, upgrade urgency, and policy compliance status. Do not write code. Do not modify files.

## Input

```json
{
  "repository_path": "absolute path to repo",
  "tech_stack_standards": ".github/standards/TECH_STACK_STANDARDS.md",
  "tech_policy_matrix": ".github/standards/tech-policy-matrix.yaml",
  "reverse_engineering_output": "docs/codebase-analysis/ if available"
}
```

## Scan Targets

| File | What To Extract |
|---|---|
| `package.json` | Node.js engine field, framework dependencies and versions |
| `.nvmrc`, `.node-version` | Pinned Node.js version |
| `pom.xml` | Java version, Spring Boot version, dependency versions |
| `build.gradle` / `build.gradle.kts` | Java toolchain, dependency groups and versions |
| `requirements.txt`, `pyproject.toml`, `setup.py` | Python version constraint, library versions |
| `Gemfile`, `Gemfile.lock` | Ruby version, gem versions |
| `go.mod` | Go version, module dependencies |
| `.csproj`, `global.json` | .NET target framework version, SDK version |
| `Cargo.toml` | Rust edition, crate versions |
| `Dockerfile`, `docker-compose.yml` | Base image name and tag (extract version from tag) |
| `.github/workflows/*.yml` | Tool versions in uses: and with: blocks |
| `.gitlab-ci.yml`, `Jenkinsfile` | Image versions, plugin versions |
| `terraform/*.tf`, `bicep/*.bicep`, `*.yaml` (CF) | Provider versions, module source versions |

## Classification Rules

For each component found, set urgency:

| Condition | Urgency |
|---|---|
| Known CVE affecting this version | urgent |
| Component is past end-of-life date | urgent |
| Component violates tech policy (blocked version or unapproved) | urgent |
| EOL within 12 months | high |
| 1+ major versions behind current stable | high |
| 1-2 minor versions behind current stable | medium |
| On latest stable or latest patch | low |

Set `policy_status`:
- `compliant` — within approved version range in policy matrix
- `warning` — within range but near policy boundary or marked as deprecated-next
- `non_compliant` — outside approved range or blocked
- `unknown` — not present in policy matrix

## Upgrade Dependency Graph Rules

Some upgrades must precede others. Set dependency order:
- Test framework version must be compatible with the runtime version → upgrade runtime AFTER test framework
- ORM must be compatible with database driver → upgrade database driver first
- CI pipeline tool versions must be updated before workflow syntax changes are safe
- Frontend framework version must align with build toolchain version

For each dependency relationship: `component_a` must