[lua-engineering]

# Machine-readable delivery state (ITEM #19). EMITTED state, not a signature — a PR-body edit can change it;
# the trust-anchored copies are the outcome ledger + provenance chain on the ticket row. Join key: lineage + specHash.
ticket: BAC-1894
lineage: wfr_16fbe05b-d9c8-4d8b-ba58-b28524e3494e
run: wfr_16fbe05b-d9c8-4d8b-ba58-b28524e3494e
base: main
baseSha: 782f235fa6be57a84745657fc7923d05d2d181c0
changeClass: behavioral
model: anthropic/claude-sonnet-5-5
promptVersion: pe-2026-09-15
guard: clean
blockers: -
testsRun: 268
additions: 37
deletions: 6
duplication: unverified
specHash: faae81a369bb22ba9970b7c4

BAC-1894: [security] Upgrade 5 vulnerable packages in cursor-lua-agent-builder (2 lockfiles)

Scorecard

Scale: low = low concern, high = high concern (rollback ease, reviewability and test coverage read as the risk in that dimension); security clean < warn < block; duplication none < possible < likely.

Dimension	Level	Notes
Overall	med	the highest of the eight dimensions
Reviewability	low	37 added / 6 removed across 2 file(s)
Blast radius	med	2 file(s) across 2 package(s)
Downtime risk	low	a single additive deploy
Migration / data risk	low	no persisted-state change in the contract
Rollback ease	low	additive / back-compatible — easy to roll back
Test coverage	low	9 regression test(s)
Security	clean	no secret or injection pattern in the added lines
Duplication	unverified	the duplicate scan could not run

Reviewer guidance: Review the flagged dimensions before merging.

Reviewer guide

Start here: Review the flagged dimensions before merging.

Change class: behavioral — changes existing runtime behaviour — read the diff and the tests closely.

Attestation: this change did NOT touch CI configuration, secrets, credentials, dependency manifests, lockfiles, hooks or infra — the deterministic guard read the full diff and found no protected path.

Contract + tests: the review checked each Contract section (below) against the diff. Regression tests added: 9 — the implementer states the pre-fix (red-before-green) failure in Implementation notes below.

Spots flagged for close review (derived from the plan's risks and the review's non-blocking findings — a proxy for where the pipeline was least confident, NOT posted as inline comments; real inline review comments are the documented follow-on):

- package-lock.json: Planned conditional change dropped as unnecessary: I read the lockfile and every resolved browserslist (4.28.7), baseline-browser-mapping (2.11.1), js-yaml (4.3.2 and nested 3.15.2) is already at or above its fixed version, so no change is needed. The guard's claims_unmatched finding is cleared by …
- mcp/lua-platform/package-lock.json: Planned conditional change dropped as unnecessary: browserslist 4.28.7, baseline-browser-mapping 2.11.1 and js-yaml 3.15.2 are already at or above their fixed versions. The new per-lockfile test now guards baseline-browser-mapping here too.
- package.json: Planned conditional change dropped as unnecessary: no lockfile needed an update, and the existing overrides already pin js-yaml to ^4.3.2 and ^3.15.2.

Summary

The base ref (782f235, BAC-1598 merged) already resolves every package this ticket lists at or above its fixed version in both lockfiles, so the ticket's premise that these alerts are still open does not match the checkout. The spec is deliberately additive and verify-first. The coding agent re-checks all five resolutions with `npm ls --all --ignore-scripts` and the lockfile JSON. If every one is already outside the listed vulnerable range, it makes NO lockfile or package.json change, because regenerating would only add unrelated churn. It extends `test/lockfile-security.test.mjs` to close the gaps the old test left: `baseline-browser-mapping` is never asserted in `mcp/lua-platform/package-lock.json`, and the same-major-line criterion is not asserted. It also adds the per-ticket changelog fragment. This differs from the held attempts, which tried to regenerate both lockfiles with a test and fixtures that did not match the diff. Here the test is written first, every fixture literal is asserted by it, and the only conditional lockfile edit is a targeted `npm update <pkg> --ignore-scripts` in the one lockfile where a package is genuinely still vulnerable. The existing test assertions stay untouched, so the change is additive.

Contract

premise: The ticket claims browserslist, js-yaml and baseline-browser-mapping still resolve vulnerable versions. The code contradicts that: `package-lock.json` resolves browserslist 4.28.7 (line 1539), baseline-browser-mapping 2.11.1 (line 1502), js-yaml 4.3.2 (line 3308) and nested js-yaml 3.15.2 (line 657). `mcp/lua-platform/package-lock.json` resolves browserslist 4.28.7 (line 1671), baseline-browser-mapping 2.11.1 (line 1634) and js-yaml 3.15.2 (line 3209). The plan is aligned with the code: verify,…
dataModel: none — no schema, type or runtime data changes; only dependency lockfiles are in play, and they are expected to stay unchanged.
validation: Enforced at test time by `test/lockfile-security.test.mjs`, which parses both lockfiles and compares every resolved browserslist, js-yaml and baseline-browser-mapping version, including nested `node_modules/**/node_modules/<name>` entries, against the fixed floors and current majors. A violation fails Jest with an `expect(...).toBe(false)` or `toContain` mismatch naming the package.
durableState: none — the pinned versions live in the two committed lockfiles, one entry per resolved path; nothing is persisted at runtime.
events: none — no events, audit rows or logs are added; the CI Jest failure output is the only signal.
readSurfaces: `test/lockfile-security.test.mjs` (Jest output via `npm test`), `package-lock.json` and `mcp/lua-platform/package-lock.json` (read via `npm ls <pkg> --all`), and `changelog.d/BAC-1894.md`.
backCompat: Existing lockfile entries and existing test assertions are unchanged. Proof: the pre-existing tests in `test/lockfile-security.test.mjs` still pass untouched, and the lockfiles stay on browserslist 4.x, js-yaml 3.x and 4.x, and baseline-browser-mapping 2.x.
deployOrder: No ordering: one PR, and the plugin has no runtime deploy for a lockfile or test change. If a lockfile does change, the root and `mcp/lua-platform` updates land together in the same PR.
docsChangelog: New fragment `changelog.d/BAC-1894.md` with one line: 'security: lockfile test now guards baseline-browser-mapping in mcp/lua-platform and same-major-line pins for browserslist, js-yaml and baseline-browser-mapping'. Do not edit any shared CHANGELOG.

Changes

- test/lockfile-security.test.mjs — Add tests only; keep every existing assertion. (1) Move the `baseline-browser-mapping` floor check (`>=2.11.0`) into the `describe.each(LOCKFILES)` block so it runs for `mcp/lua-platform/package-lock.json` too; today only the root lockfile is checked. (2) Add a same-major-line check per lockfile: e…
- changelog.d/BAC-1894.md — New per-ticket fragment (the repo has no changelog convention, so create `changelog.d/BAC-1894.md`). One line: security: lockfile guard now also covers baseline-browser-mapping in mcp/lua-platform and the same-major-line invariant for browserslist, js-yaml and baseline-browser-mapping; resolved ver…
- package-lock.json — CONDITIONAL, only if verification finds a resolved browserslist <=4.28.6, js-yaml in >=3.0.0 <3.15.2 or >=4.0.0 <4.3.2, or baseline-browser-mapping <2.11.0. At base the lockfile is already clean (browserslist 4.28.7 at line 1539, baseline-browser-mapping 2.11.1 at 1502, js-yaml 4.3.2 at 3308, neste…  [planned — NOT in this diff]
- mcp/lua-platform/package-lock.json — CONDITIONAL, same rule as the root lockfile. At base it is already clean (browserslist 4.28.7 at line 1671, baseline-browser-mapping 2.11.1 at 1634, js-yaml 3.15.2 at 3209, no js-yaml 4 present), so expect NO diff here. If a package is vulnerable, run a targeted `npm update <pkg> --ignore-scripts` …  [planned — NOT in this diff]
- package.json — CONDITIONAL, expect no change. The root `overrides` already pin `js-yaml@4` to `^4.3.2` and `js-yaml@3` to `^3.15.2`. Touch it only if a targeted update cannot move a package because the parent pins it; then add or raise a minimal override on the same major line.  [planned — NOT in this diff]
- mcp/lua-platform/package.json — CONDITIONAL, expect no change. `overrides` already pin `js-yaml@3` to `^3.15.2`. Same rule as the root `package.json`.  [planned — NOT in this diff]

Regression fixtures

- `4.28.7` — browserslist, the fixed version resolved in both lockfiles; used by the browserslist floor and boundary tests as the passing value.
- `4.28.6` — browserslist, the last vulnerable version (the `<=4.28.6` ceiling); the boundary test asserts it is flagged, on the vulnerable side of the rule.
- `3.15.2` — js-yaml 3.x fixed version, resolved at `node_modules/js-yaml` in `mcp/lua-platform` and at `node_modules/@istanbuljs/load-nyc-config/node_modules/js-yaml` in the root; used by the js-yaml floor and nested-path tests and as the existing literal that must keep passing.
- `3.15.1` — vulnerable js-yaml 3.x literal; used by the boundary test and the existing 'no vulnerable literal' test.
- `4.3.2` — js-yaml 4.x fixed version resolved at `node_modules/js-yaml` in the root lockfile; used by the js-yaml floor test.
- `4.3.1` — vulnerable js-yaml 4.x literal; used by the boundary test.
- `2.11.1` — baseline-browser-mapping resolved in both lockfiles; used by the new floor test run for each lockfile.
- `2.10.0` — a baseline-browser-mapping version below the `<2.11.0` floor, used only as a synthetic input to the `lt` boundary assertion (not present in any lockfile).

Implementation notes

Base already resolves every listed package at or above its fixed version in both lockfiles (browserslist 4.28.7, baseline-browser-mapping 2.11.1, js-yaml 4.3.2 and nested 3.15.2 in the root; js-yaml 3.15.2 in mcp/lua-platform). Because of that I changed no lockfile or package.json. I extended test/lockfile-security.test.mjs in three ways. The baseline-browser-mapping floor check now runs for both lockfiles, since it covered only the root before. A same-major-line check was added per lockfile. Boundary tests cover the fixed literals 4.28.7, 3.15.2, 4.3.2 and 2.11.1 and the vulnerable literals 4.28.6, 3.15.1, 4.3.1 and 2.10.0. I also added changelog.d/BAC-1894.md. The new tests pass on base, as expected for an already-patched tree. When I set the mcp lockfile's baseline-browser-mapping to 2.10.0, the new per-lockfile floor test failed, and I then restored the file. The other new tests were not run against a downgraded lockfile, and the boundary tests use `lt` on literals, so they cannot go red from a lockfile change. `npm ls` was only run in the root; mcp/lua-platform has no node_modules, so its versions were checked in the lockfile directly. The PR should note that the Dependabot alerts are expected to auto-close on rescan.

Verified with npm test -- --maxWorkers=2 (the repository's own command; npm test (detected from package.json) could not start here)

Test Suites: 18 passed, 18 total
Tests: 268 passed, 268 total
2.7M	/workspace/.home/tmp
/dev/nvme1n1    9.8G   65M  9.7G   1% /workspace

Repository gates and regression tests

Gates: none run
Regression tests:
- fixed 4.28.7 is not flagged — 4.28.7
- fixed 3.15.2 is not flagged — 3.15.2
- fixed 4.3.2 is not flagged — 4.3.2
- fixed 2.11.1 is not flagged — 2.11.1
- vulnerable 4.28.6 is flagged — 4.28.6
- vulnerable 3.15.1 is flagged — 3.15.1
- vulnerable 4.3.1 is flagged — 4.3.1
- vulnerable 2.10.0 is flagged — 2.10.0
- baseline-browser-mapping stays at or above 2.11.0 (2.11.1) — mcp/lua-platform/package-lock.json 2.11.1 (failed when set to 2.10.0)

Review — pass (round 1)

- [minor] package-lock.json: Planned conditional change dropped as unnecessary: I read the lockfile and every resolved browserslist (4.28.7), baseline-browser-mapping (2.11.1), js-yaml (4.3.2 and nested 3.15.2) is already at or above its fixed version, so no change is needed. The guard's claims_unmatched finding is cleared by this note. The Dependabot alerts are expected to auto-close on rescan.
- [minor] mcp/lua-platform/package-lock.json: Planned conditional change dropped as unnecessary: browserslist 4.28.7, baseline-browser-mapping 2.11.1 and js-yaml 3.15.2 are already at or above their fixed versions. The new per-lockfile test now guards baseline-browser-mapping here too.
- [minor] package.json: Planned conditional change dropped as unnecessary: no lockfile needed an update, and the existing overrides already pin js-yaml to ^4.3.2 and ^3.15.2.
- [minor] mcp/lua-platform/package.json: Planned conditional change dropped as unnecessary: no lockfile needed an update, and the existing js-yaml override already pins ^3.15.2.

Tests after review: green; repository gates after review: green

Diff guard — clean

2 file(s) changed, none protected, no policy blocker

Acceptance judge (independent, read-only)

verdict: solves

The architect verified that both lockfiles already resolve fixed versions: browserslist 4.28.7, baseline-browser-mapping 2.11.1, js-yaml 4.3.2 and nested 3.15.2 in the root, and js-yaml 3.15.2 in mcp/lua-platform. So the ticket's vulnerability criteria already hold on base, and the stated criteria expect the diff to touch only the test file and a changelog. The diff matches that. It extends the lockfile test so the baseline-browser-mapping floor is checked in both lockfiles and adds a same-major-line check per lockfile. It also adds boundary tests and a changelog entry. No lockfile or package.json is changed, so there is no unrelated churn and no scripts were run. The same-major-line criterion is covered by a new test. Weaknesses: the boundary tests are literal-only, and the implementer says it did not run npm ls or the new tests against downgraded lockfiles, apart from one baseline-browser-mapping check. The `npm test` pass is claimed but not shown in the diff. Since the tree is already patched, the diff plausibly satisfies the criteria.

Risks

- Premise mismatch: the ticket says the advisories are still open, but base already contains the BAC-1598 fix. The alerts may be stale or still be indexed against an older lockfile. The coding agent must check first and do the minimal correct thing either way. If the lockfiles are clean it ships only…
- If Dependabot still flags these versions, the advisory ranges may differ from the ticket's text (for example a newer patched release than 4.28.7). I cannot resolve this offline, so I followed the ticket's stated ranges, and the PR should flag it for a human.
- Previous attempts were held on `claims_unmatched` and `fixtures_unused`. Mitigation: every claim in this spec maps to an assertion in `test/lockfile-security.test.mjs`, and every fixture literal below is used by that test. Do not add claims or fixtures the diff does not exercise.
- The lockfile paths are protected, and the ticket authorises editing them only if a package really is vulnerable. Do not regenerate them wholesale. A full `npm install` could bump unrelated packages and breach the 'only these packages and required parents' criterion.
- A patched parent might not exist for a transitive package, which would force an `overrides` entry. This is not expected at base, because the lockfiles are already clean.
- Compatibility strategy: the test change is additive and opt-in; existing assertions are not modified, so existing behaviour is unchanged. The new per-ticket fragment creates a `changelog.d/` directory the repo does not use yet; it is a harmless new file that cannot collide with another PR.

Closes BAC-1894

[lua-engineering]

🔎 Merge requirements for main

This repository requires: 1+1 approval(s) · threads resolved.

Before this PR can merge:

• Extra approval for unattributed commits — these commits are not attributed to a GitHub account, so this repo requires one approval beyond the base count; a human review is needed (the agent cannot self-approve).

[lua-code-reviewer]

Code review: Approved · low risk

Reviewed head 340c86ecdd52 (round 1) · CI: green · confidence 0.80

Checklist

correctness	tests	security	data	billing	performance	repo rules	compat
pass	pass	pass	n/a	n/a	n/a	pass	n/a

Tests (the reviewer's reading of the code, not a run): cover the change: yes · would fail without it: unknown — Four tests are new or moved. 'baseline-browser-mapping stays at or above 2.11.0' now runs per lockfile through describe.each. 'resolved versions stay on their current major lines' is new. The 'version boundaries' fixed and vulnerable tables exercise lt(). These tests guard against future regressions; because the lockfiles are already fixed, they would pass on the base too.

Rolling deploy and side effects

item	status	evidence
Ordering between services	n/a
Mixed-version safety	n/a
Caches and serialized data	n/a
Idempotency of new writes	n/a
Background jobs and cron	n/a
External calls and billing	n/a
Data backfills	n/a
Feature flag default	n/a
Rollback safety	pass	Only test/lockfile-security.test.mjs and changelog.d/BAC-1894.md change; reverting has no runtime effect.

Summary

The PR changes no lockfile or runtime code. It moves the baseline-browser-mapping floor assertion from the root-only describe into the per-lockfile describe.each, so mcp/lua-platform is now covered too. It also adds same-major-line assertions, boundary tests for the lt helper and a changelog fragment. The change is test and docs only, it is additive in coverage, and it is safe to merge.

Advisory (1, not blocking)

• test/lockfile-security.test.mjs:69 Boundary table row compares a version to itself — The row ['4.28.7','4.28.7'] tests lt(x, x), which only checks strictness. The existing browserslist assertion uses a floor of 4.28.6 exclusive, so this row's floor is inconsistent with it. Fix: Use a shared FIXED constant for the browserslist floor so the table and the per-lockfile assertion agree.

_{Automated review by lua-code-reviewer[bot] for the Lua Engineering fleet. This approval is for the exact head above; any new push needs a new review.}

[lua-engineering]

Not validated on staging: no Staging Sentinel attestation; merged on the designated reviewer's approval.

Head 340c86ecdd52 (behavioral). This repository's policy is that a change that was not exercised on staging says so on the main PR — this is that note. Watch the production rollout and probe after it lands.