assess

Assess a dependency update

Ground one dependency-update request against this repository as it exists right now, and decide whether an update is actually owed. You produce an assessment and a verdict; you change nothing. No one watches the run; the assessment file and your declared fields are the only things that persist.

You know nothing beyond this repository's checkout and the request below. You have no memory of previous runs, no knowledge of what this project's maintainers usually do, and no awareness of updates you may have assessed before. Everything you claim must be derived from files in this checkout, the project's own tooling, or the request itself — and your assessment must cite where each fact came from.

The request

$INPUTS.target

If the block above is empty, the request is the message that started this run:

$ARGUMENTS

It may name a dependency, a version, a security advisory, or a general ask ("update sharp", "address the undici advisory", "get X off the vulnerable range"). A bare issue or PR reference in the request resolves against THIS repository's tracker unless the request says otherwise — read it there first; upstream projects' trackers are secondary sources for upstream facts only.

How to assess

1. Find the dependency in this repository. Discover the package manager and manifest layout from the repository itself — lockfiles, manifest files, workspace configuration. Never assume a manager the repo does not show. Record: every manifest that declares the target, the declared constraint, and the exact locked version currently installed.
2. Establish what "current" would mean. Use the project's own tooling to learn the latest applicable version (registry info commands, the lockfile's metadata, a vendored changelog). If the environment cannot tell you, say so — name the exact command that failed or the information that is unavailable. Never guess a version number.
3. Map the blast radius. Find where the dependency is imported or configured in this repo. Read the upstream changelog or release notes between the locked and target versions if they are reachable (in the installed package, via the manager's tooling). List the breaking changes that touch code paths this repo actually uses — not every change upstream shipped.
4. Check the constraint reality. Does the declared range already admit the target version, or does the manifest need editing? Do peer/engine requirements or sibling dependencies pin it? A constraint that forbids the target is a finding, not a dead end — the assessment says what must change and what that risks.
5. Check for duplicate copies. A transitive, optional, or peer occurrence of the target elsewhere in the tree can keep the old version installed even after the direct bump — package managers do not always dedupe them. When the request's goal (an advisory, a version floor) requires those copies to move too, the update order prescribes the exact mechanism this manager supports. Prefer the manager's declared resolution mechanism — an override or resolution entry — over emergent tricks like adding a root dependency nothing imports: a declared constraint survives resolver changes and fails loudly, while an emergent dedupe can silently regress. Verify the mechanism against the project's pinned manager version — engines, CI pins, the lockfile format — because a form the pinned version ignores with a warning is not a mechanism; when its support cannot be proven from this checkout alone, also name one authorized fallback with its blast radius, so the implementer is never stranded between a falsified primary and an unauthorized improvisation. Name every consumer the mechanism moves and whether each stays inside its declared range. A consumer forced past a major boundary is a risk the assessment states loudly and the implementer validates by running that consumer's own tests — the reviewer judges it in the pull request; it is never a reason to stop.
6. Decide. update when the request's goal is real and any executable path to it exists — including a path that requires code migration or forcing a transitive pin. When several paths exist, choose the best one on the evidence and record the alternative you rejected and why: the operator judges your choice where it is concrete — in the pull request, with the diff and CI in front of them — so doing the work and presenting it always beats stopping to ask. no_action only when there is genuinely nothing to do: the repo is already current, the request does not apply here (the dependency is absent, the advisory concerns a version this repo never ships), or a stop rule fires. State the reason plainly.