stack-currency

name

stack-currency

description

Check each recorded stack component for currency — latest stable version, end-of-life status, deprecation notices, upstream abandonment, and whether a successor project has taken over. Answers "is this still a current stack" without reading application code. Use when the user says "is my stack up to date", "check for EOL", "are we on old versions", "what needs upgrading", "stack modernization check". Reads docs/stack/stack.json written by stack-inventory; run that first if it is missing or stale.

stack-currency

Component-by-component: is this still the current thing, and is it still supported?

Version currency and support status are different questions and both matter. Postgres 14 is several majors behind and still supported; CentOS 8 is dead regardless of version number.

Inputs

• path (optional): repo root. Defaults to cwd.
• slots (optional): restrict to named slots, e.g. runtime,database-primary.

Procedure

1. Load the record

Read docs/stack/stack.json. If missing, run stack-inventory first.

If run.date is more than 90 days before today, or run.commit is not an ancestor of HEAD, the record is stale — say so and offer to re-run the inventory. Checking currency against a stale inventory produces confidently wrong answers.

2. Resolve latest stable versions

Per component, cheapest reliable source first:

# registries — fast, authoritative, no scraping
npm view <pkg> version                       # npm
curl -s https://pypi.org/pypi/<pkg>/json | jq -r .info.version
curl -s https://crates.io/api/v1/crates/<crate> | jq -r .crate.max_stable_version
curl -s https://proxy.golang.org/<module>/@latest | jq -r .Version
docker run --rm <image>:latest --version     # only when nothing else answers

For frameworks, runtimes, and infrastructure, mcp__gateway__context7__resolve-library-id followed by query-docs gives current version and migration guidance in one step and is usually better than a registry number alone.

Latest stable. Not a release candidate, not a nightly, not a pre-1.0 tag that upstream has not promoted. Being behind a beta is not a finding.

3. Resolve end-of-life status

https://endoflife.date/api/<product>.json covers runtimes, databases, OSes, and major frameworks and is the fastest path:

curl -s https://endoflife.date/api/postgresql.json | jq '.[] | select(.cycle=="16")'

For anything it does not cover, check the project's own support policy page. Record the source URL either way — an EOL claim without a source is not usable six months later.

Web access escalates: if a fetch fails or is blocked, go to the next route rather than reporting that the version could not be determined. mcp__gateway__geo-egress__fetch_json and fetch_markdown egress from a different IP and usually succeed where the default route does not.

4. Check for deprecation and abandonment

Beyond version numbers:

• Deprecated — upstream says stop using it. npm prints a deprecation notice; PyPI marks yanked releases; repos get archived; READMEs get a "this project is no longer maintained" banner.
• Superseded — a successor exists and upstream points at it. Record the successor by name; a deprecation notice without the replacement is half an answer.
• Abandoned — no release or commit in 24+ months with no successor named. Check mcp__gateway__github__get_latest_release and the default branch's last commit date. Note that a mature, finished library with no commits is not the same as an abandoned one — say which you think it is and why.

5. Classify

Assign each component a currency value from the schema (current, behind-minor, behind-major, eol, eol-soon, deprecated, abandoned, unversioned, not-applicable).

eol-soon means end of support within 12 months of the run date. That window exists so upgrades get planned rather than discovered.

6. Assess what upgrading actually costs

A version gap is not automatically a finding. For each non-current component establish:

• What broke between here and there? Read the upstream migration guide or changelog, not the version delta.
• Is the gap blocked by something else in the stack — a peer dependency ceiling, a runtime floor, a managed provider that only offers the old version?
• What is gained? Security fixes and support runway are real; a minor version bump for its own sake is churn.

Being behind is not a defect. A stable, supported, working component two minors back is fine. Say so plainly rather than manufacturing an upgrade task. The findings worth raising are: past EOL, EOL within 12 months, unpatched known vulnerabilities, deprecated with a named successor, abandoned, or blocking something the project actually wants to do.

7. Record

Update each component in stack.json with version_latest_stable, the eol block including checked date and source, and currency. Append findings for category: "currency" or "eol", with first_seen set to today for new ones and preserved for existing ones.

Write docs/stack/reports/<date>-currency.md with the detail — per component: current version, latest, support status, upgrade path, what it buys, what it risks.

8. Report

Lead with anything past or near EOL. Then majors behind with a real reason to move. Then, in one line, the count of components that are current and need no action — the user should be able to see that most of the stack is fine.

Guardrails

• Every EOL and version claim carries a source URL and the date checked. Both go in the file.
• Do not report a version you inferred from a lockfile transitive pin as the declared version.
• Do not recommend an upgrade whose migration cost you have not looked at.
• Do not run any upgrade. This skill reports; stack-proposal sequences; an execution agent acts.