agent's license scan false-positived on a vendored file — the upgrade was blocked for a week

Not specified by the original author.

TL;DR

The scanner flagged a license header inside vendored third-party code, which you do not own and cannot change. Scope the scan to your code, allowlist the vendored directory, and re-run so the upgrade can proceed.

Error

agent's license scan false-positived on a vendored file  -  the upgrade was blocked for a week

Steps

1. Confirm the false positive: open the flagged file and verify it sits in vendor/ or a third-party directory and carries upstream's license header. Expected output: The flag is on code you did not write.

2. Check the upstream package's actual license against your policy; vendored code inherits the package license you already accepted. Expected output: The package license is already approved, so the flag adds nothing.

3. Exclude vendor/ and third-party directories from the license scan scope, or add the specific file to the allowlist with a note. Expected output: The scan covers your code, not upstream's.

4. Re-run the scan and confirm it is clean, then unblock the upgrade PR. Expected output: The upgrade proceeds.

5. Add the exclusion to the shared scan config so the next vendored file does not block the next upgrade. Expected output: The false positive class is fixed, not just the instance.

When to use

• A license scan flags files in vendor/ or third-party directories
• An upgrade is blocked by a scan finding on code you did not write
• You are configuring license-scan scope

When not to use

• A genuine license conflict in your own code; get legal input
• A vendored package whose license actually changed upstream; that is real
• Scan failures from misconfiguration rather than findings

Variant phrasings

license scan flagged a vendored file

false positive license finding blocking upgrade

exclude vendor directory from license scan

Why it happens

Scanners walk the whole tree including vendor/, and upstream license headers (or ambiguous ones) trip the rules. The finding is technically accurate (the text is there) and practically useless (it is not your code to relicense), but the gate treats it as blocking.

Edge cases

• Copyleft code vendored into a proprietary product is a real issue; do not allowlist what you have not reviewed.
• Some vendors ship multiple licenses in one package; scope the review to the files you actually use.
• Keep the allowlist annotated with reasons and dates so it stays auditable.

Provenance

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

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

Thread query: agent's license scan false-positived on a vendored file - the upgrade was blocked for a week

TL;DR: The scanner flagged a license header inside vendored third-party code, which you do not own and cannot change. Scope the scan to your code, allowlist the vendored directory, and re-run so the upgrade can proceed.

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:

Not specified by the original author.

TL;DR: Security updates always ship in their own PR, separate from every other bump. Split the security patch out of the grouped PR, merge and release it first, then deal with the major on its own timeline. Configure the agent to treat security-flagged updates as their own group with priority handling. A CVE fix must never wait on unrelated breakage.

agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

1. Identify the security-flagged update inside the grouped PR (advisory ID, CVE number, or the scanner's severity label). Expected: one clearly-labeled security bump among the grouped changes.

2. Cherry-pick just the security bump onto a fresh branch and open it as its own PR with the advisory reference in the body. Expected: a minimal PR containing only the security fix.

3. Run CI on the security PR alone and merge it as soon as it is green, on the normal release train or hotfix path. Expected: the CVE fix ships while the major is still being fixed.

4. Leave the major upgrade in its own PR to be fixed and reviewed on its own timeline. Expected: the major's breakage no longer blocks anything security-related.

5. Change the agent's grouping config so security-flagged updates always form their own group, separated from feature and major bumps, with automerge-on-green if your policy allows it. Expected: the next advisory arrives as a standalone PR by default.

Use this when

• a CVE fix is bundled with an unrelated major upgrade
• a security patch is blocked by someone else's breakage
• the agent groups all updates into one PR regardless of severity
• auditors ask why a known CVE sat unpatched for weeks

Not for this skill when

• the security fix itself requires the major upgrade (then they are genuinely coupled; document why)
• the "security" label is a false positive from the scanner (downgrade the severity first)
• your policy forbids automerge on security PRs (keep the separate PR, just review it manually)

Variant phrasings

• "security patch stuck behind major upgrade"
• "CVE fix blocked by grouped PR"
• "renovate grouped security update with major"
• "how to separate security updates from regular bumps"
• "dependabot security PR mixed with feature upgrades"

Why it happens

Grouping rules usually key on schedule or package, not severity, so a security patch lands in whatever group was forming that day. The agent sees one fewer PR as a win. But security fixes and major upgrades have opposite risk profiles: the patch must ship fast with minimal change, the major needs slow careful review. Bundling them forces the fast item to move at the slow item's pace, which is exactly backwards.

Edge cases

• Some advisories only publish a fix on the new major line; then the security PR legitimately includes a major. Say so in the PR body so reviewers know it is not optional.
• Backport branches may need the same security patch separately; check whether the advisory affects maintained older lines.
• Automerging security PRs can still break the build; keep the CI gate, just skip the human review queue when policy allows.
• If the scanner flags a devDependency CVE as critical, weigh exploitability before hotfixing; not every critical needs the fast lane.

Provenance

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

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

Thread query: agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

TL;DR: