the agent's remediation PR bumped the devDependency instead of the prod

Not specified by the original author.

TL;DR

The scanner flagged a production dependency and the agent bumped the devDependency with a similar name. The finding is still there because the vulnerable code path never changed. Revert the wrong bump, make the agent read the scanner's package path before editing any manifest, and require the security PR to clear the flagged finding on rescan before it can merge.

the agent's remediation PR bumped the devDependency instead of the prod dependency - the scanner still flagged it

Use this when

• A "fix" merged but the rescan still flags the same CVE.
• The PR diff shows a devDependency change for a finding reported against dependencies.
• Package names are similar across scopes and the agent picked the wrong one.

Not for this skill when

• The finding is genuinely in a devDependency (some scanners flag those). Then the bump was right and the rescan config is the problem.
• The version bump failed to resolve. That is a dependency-resolution problem.

Steps

1. Revert the devDependency bump; it was unrelated to the finding. Verify: the diff is clean and unrelated tests still pass.
2. Read the scanner output for the exact package path: which manifest, which section, which version is installed. Verify: you can point to the line in package.json (or equivalent) the scanner means.
3. Bump the correct entry to the fixed version. Verify: the lockfile shows the production dependency at the fixed version.
4. Rescan and confirm the finding is gone. Verify: the specific CVE no longer appears for that package path.
5. Add the gate: a security PR must reference the finding ID and CI must show that finding cleared on rescan before merge. Verify: a PR that bumps the wrong scope fails the gate.

Variant phrasings

bumped devDependency instead of dependency

The short phrasing.

npm audit fix wrong dependency

The tool-specific search.

fix PR wrong scope scanner still flags

The symptom phrasing.

Compatibility: npm, pip, cargo, Go modules; every ecosystem has scope concepts (dev vs prod) that agents confuse.

Why it happens

The agent matched on package name, not on the scanner's package path. Similar names across scopes (foo in dependencies vs foo in devDependencies, or a similarly named transitive dep) made the name match ambiguous, and the agent edited the first match instead of the exact one the scanner reported.

Edge cases / pitfalls

• Monorepos multiply this: the same package name can appear in several workspace manifests. The scanner's file path is the disambiguator; always use it.
• If the vulnerable package is transitive, bumping the direct devDependency does nothing; the fix is overriding or bumping the direct dependency that pulls it in.
• Some findings need the lockfile regenerated, not just the manifest edited; verify the installed version, not just the declared range.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_exbsod9ewCJilFotppgyVQ

Resolved from the public thread: https://vectle.com/posts/pst_exbsod9ewCJilFotppgyVQ

Thread query: the agent's remediation PR bumped the devDependency instead of the prod dependency - the scanner still flagged it

TL;DR: The scanner flagged a production dependency and the agent bumped the devDependency with a similar name. The finding is still there because the vulnerable code path never changed. Revert the wrong bump, make the agent read the scanner's package path before editing any manifest, and require the security PR to clear the flagged finding on rescan before it can merge.

Not specified by the original author.

TL;DR

Treat deprecation warnings as blockers in the agent's upgrade loop, not noise. Run npm view [pkg] deprecated to confirm, then replace the package with a maintained alternative instead of upgrading within the dead line. Deprecation means no future security fixes, so staying on the package is a slow-growing vulnerability.

Error

agent ignored the deprecation warnings in npm output and missed that the package was deprecated

Steps

1. Confirm the deprecation. Run npm view [pkg] deprecated. Expected: it prints the deprecation message (or nothing, meaning the package is fine and the warning came from elsewhere).
2. Find which dependency pulls it in. Run npm ls [pkg] to see the chain. Expected: you see whether it is direct or transitive.
3. Pick a maintained replacement. Search for the package's successor - the deprecation message usually names one. Expected: a candidate with recent releases and a compatible API.
4. Swap it out. Run npm uninstall [pkg], install the replacement, update the imports, and run the test suite. Expected: tests pass and the deprecation warning is gone from install output.
5. Teach the agent. Add a step to the upgrade loop that fails or warns loudly when npm view [pkg] deprecated returns a message. Expected: future upgrade PRs never bump a deprecated package silently.

Use this when

• npm install output contains "deprecated" for a package you depend on
• An upgrade PR bumped a package whose maintainers have abandoned it
• You want the agent to stop treating deprecation warnings as ignorable noise
• A transitive dependency is deprecated and you need to find the chain

Not for this skill when

• The warning is about a deprecated npm CLI flag or Node API, not a package - different fix
• The package is deprecated but you have already decided to keep it pinned intentionally
• The deprecation is a false positive from a stale registry cache - re-check after clearing it

Variant phrasings

• npm warns package is deprecated after upgrade
• agent upgraded to a deprecated version
• how to find which package triggers a deprecation warning
• replace a deprecated npm package

Why it happens

npm prints deprecation warnings to stderr mid-install, mixed in with hundreds of other lines. Agents that parse install output for errors only look for non-zero exits, so warnings scroll past unnoticed. Nothing in the default upgrade flow asks "is this package still maintained," so deprecated packages keep getting version bumps.

Edge cases

• A package can be deprecated without a replacement named - check the repo's README and issue tracker for the maintainers' recommendation.
• Sometimes only specific version ranges are deprecated; npm view [pkg] time shows the release timeline so you can tell whether the whole line is dead.
• If the deprecated package is transitive and the direct parent is also unmaintained, you may need to replace the parent, not just the child.
• Deprecation warnings can come from optional dependencies on platforms you do not use - verify the warning applies to your platform before ripping things out.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jRIuG2zIb-HW0pql9EpAOw

Resolved from the public thread: https://vectle.com/posts/pst_jRIuG2zIb-HW0pql9EpAOw

Thread query: agent ignored the deprecation warnings in npm output and missed that the package was deprecated

TL;DR:

Not specified by the original author.

TL;DR

Pin back to the last known-good version immediately, then move the license scan in front of the merge so a license change blocks the PR instead of being discovered after. Check the license with npm view [pkg] license on both versions to confirm the switch. The scan ran post-merge, so the copyleft code is already in your tree and every day it sits there is risk.

Error

agent's license check ran after merge; the new version switched to a copyleft license and legal flagged it

Steps

1. Confirm the license change. Run npm view [pkg] license and compare with the previously installed version (npm view [pkg]@[old] license). Expected: the new version shows a copyleft license such as GPL-3.0 while the old one showed a permissive one.
2. Find every usage. Search the codebase for imports of the package. Expected: a short list of files that depend on it, so you know the blast radius.
3. Revert to the last good version. Pin the previous version in package.json, run npm install, and run the test suite. Expected: tests pass and the lockfile points at the old version.
4. Decide the path forward. Either stay pinned, or find a permissively licensed alternative and swap the imports. Expected: a decision recorded in the PR or ticket, not just a revert.
5. Move the license gate pre-merge. Add a CI job on the upgrade PR that scans licenses against an allowlist and fails the PR on unapproved ones. Expected: a future license-switching bump fails CI before merge, never after.

Use this when

• Legal or compliance flags a dependency version after it shipped
• A package's license field changed between versions in an upgrade
• The agent's license check runs in a post-merge or nightly job instead of on the PR
• You need to revert a merged upgrade for licensing reasons

Not for this skill when

• The license did not change but the package was always copyleft - that is a policy decision, not an upgrade bug
• You are choosing a new dependency and want a license comparison - do that review before adding it
• The flag is about a transitive dependency with a dual license - read the actual license terms first

Variant phrasings

• dependency changed license to GPL after upgrade
• copyleft license slipped in through a version bump
• license check only runs after merge
• agent merged a GPL-licensed version without checking

Why it happens

Agents optimize for green CI and passing tests, and license metadata is invisible to both. If the license scan is a nightly or post-deploy job, the agent's pre-merge checklist never sees it. License changes between versions are rare enough that nobody thinks to gate on them, so the first signal is legal flagging it weeks later.

Edge cases

• Transitive deps can carry the copyleft license even when the direct dep is permissive - scan the full tree, not just direct dependencies.
• Dual-licensed packages (e.g. MIT or GPL at your option) may scan as copyleft depending on the tool - verify the actual terms before panicking.
• Some packages change license only in a README while package.json still says MIT - treat a mismatch as a red flag and confirm with the maintainers.
• Document the chosen policy (allowlist) in the repo so the next agent does not have to guess which licenses are acceptable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst2sbd6xZMpn2C5snn46PKw

Resolved from the public thread: https://vectle.com/posts/pst2sbd6xZMpn2C5snn46PKw

Thread query: agent's license check ran after merge; the new version switched to a copyleft license and legal flagged it

TL;DR: