@@ -0,0 +1,29 @@
+[agent] 2026-10-15: Yarn classic (1.x) bug-hunt run
+
+**Tested:** main `15db5c4` (since run 40: #1548 fixes #1538, #1543 nested npm projects in vendored scans, #1551 berry portal/link, plus CI-only changes). Latest release v5.0.1; the published v4.0.0 (npm) was used to write pre-v5 pins. Linux sandbox, Node 22, yarn 1.7.0 / 1.10.1 / 1.22.22, with a new generic mock (`MN` / `MV` / `PJ`) built from the run-18 mock on probe branch `20261008-grammar-xos`. No probe branches: everything this run is lock-text logic.
+
+## Filed
+- **#1558**: lock-only yarn classic VEX wrongly omits a correctly pinned patch with `dependency_not_installed` (regression from #1548, `e719a9b`).
+  - A `""` range in the patched package.json: yarn and the hosted writer both write `ms ""`, but `block_dep_maps` skips empty ranges, so the check fails right after a clean hosted scan.
+  - The same name in `optionalDependencies` and `dependencies`: the writer puts it under both, and yarn's next write (`yarn add ms`) keeps it only under optional (`cleanDependencies`), after which lock-only VEX omits.
+  - `"*"` in dependencies plus a devDependencies range (yarn writes the dev range): same root cause, seen once.
+  - Frozen installs are patched and installed VEX attests in every cell. Reproduced ×2 on 1.7.0 / 1.10.1 / 1.22.22. Controls attest. https://github.com/SocketDev/socket-patch/issues/1558
+
+## Re-triage
+- **#1538** (closed by #1548): verified on main. v4.0.0-written pins with a changed range (`is-number ^6`→`^7`) and with an added dependency are omitted with `dependency_not_installed` by installed and lock-only `vex` on 1.10.1 / 1.22.22.
+- **#1115**: still reproduces on 1.22.22 (member `.yarnrc` `yarn-offline-mirror`: hosted scan exits 0 with no refusal; the member's `--offline --frozen-lockfile` install fails). Not re-commented: nothing new.
+
+## Cells (Linux, `15db5c4`)
+- Dependency-changing hosted pins, lock-only VEX: plain range change, locked (± `yarn add`): pass. Opt+dep dup without `yarn add`: pass. `""` range: fail #1558. Opt+dep dup after `yarn add`: fail #1558. `*`+devDeps after `yarn add`: fail #1558.
+- Installed VEX for all of the above: pass (attests). Frozen installs: patched.
+- v4-pin changed range / added dep (installed and lock-only): pass (#1538 fixed).
+
+## False positives ruled out
+- My first harness's `pkill -f h/mock.py` killed its own shell (exit 144). Fixed by anchoring the pattern; not a socket-patch problem.
+
+## Next
+1. #1558 follow-ups after a fix; check whether the writer's un-normalised sub-map makes rescans after `yarn add` churn the block.
+2. Ask npm / pnpm / bun whether their dependency checks normalise manifests the way their PM does (hand over if they don't).
+3. Windows probe of `file:..\x` renamed-copy spellings after #1517.
+4. #691 / #692 / #991 re-check; `--focus` member installs; `yarn workspace <m> add` × vendored.
+5. Merge flows: both branches vendor the same package at different uuids.
@@ -1,8 +1,8 @@
 [agent] Progress ledger for the scheduled Yarn classic (1.x) bug-hunt routine (label pm:yarn-classic).
 
-Last updated: 2026-10-14 (run 40), main `a3f56f7`, release v5.0.1. Run 40 filed #1538: VEX still attests a yarn.lock pin written by v4.0.0 that yarn installs without the patched package's dependencies. #1463's `dependency_not_installed` check only asks whether the dependency name resolves, so a patch that changes a range (is-odd `is-number ^6`→`^7`, lock has only ^6) is attested by `vex` AND by the in-run `scan --vex` that reported it `redirect_unconfirmed`. Lock-only `vex` attests both the changed-range and the original #1462 added-dependency shape. Reproduced on 1.7.0 / 1.10.1 / 1.22.22. #1516 is verified fixed on main by #1517 (outside-root dir/tgz, non-`package/` root, URL and absolute-path renamed copies all warn H/V and VEX refuses). #692 still reproduces (not re-commented). #991 is half-fixed: `vendor --check` now exits 1 `vendor_ledger_missing`, but `rollback` still exits 0 and deletes the ledger while the other branch's package stays wired (commented). CI's yarn-classic-matrix (1.0.2–1.22.22) is green on the 2026-10-14 scheduled run.
+Last updated: 2026-10-15 (run 41), main `15db5c4`, release v5.0.1. Run 41 filed #1558, a regression from #1548 (`e719a9b`): lock-only yarn classic `vex` omits a correctly pinned, correctly installed patch with `dependency_not_installed` when the patched package.json has a `""` range (right after a clean hosted scan, because `block_dep_maps` skips empty ranges), or names a dependency in both `optionalDependencies` and `dependencies` (after any `yarn add`, because yarn's `cleanDependencies` keeps it only under optional). Reproduced ×2 on 1.7.0 / 1.10.1 / 1.22.22. #1538 is verified fixed on main (v4-pin changed-range and added-dep shapes are omitted by installed and lock-only VEX on 1.10.1 / 1.22.22). #1115 still reproduces (not re-commented).
 
-Previous: 2026-10-14 (run 39), main `23fa8d4`, release v5.0.1. Run 39 filed #1516: #1489's renamed-copy detection fails open when it can't read a copy's identity, so H/V scans succeed and VEX attests while the copy installs unpatched. The shapes are a `file:` copy outside the project root, a tarball whose root isn't `package/`, and a non-registry URL; it reproduces on 1.7.0 / 1.10.1 / 1.22.22. #1236 is fixed by #1489 and closed with evidence. #1115 still reproduces (commented). #1462 was closed by #1463. Run 38 filed #1462: a hosted rescan on main accepts a yarn.lock pin written by v4.0.0 when the patch's package.json adds a dependency the lock lacks. With a sha1 grant, the already-pinned artifact is never fetched, so the #591 check never runs. With a no-sha1 grant, it warns but keeps the pin. In both cases `vex` attests while yarn installs without the dependency (the hosted twin of #1379). #558 / #1271 / #591 / #1158 / #1081 / #1379 are closed, and #558 / #1271 are verified fixed on main. #692 still reproduces (commented). #691 now warns `yarn_classic_workspace_member_install_risk` (commented; needs-human). Run 37: #1158 / #1081 are verified fixed by #1180 and #1236's main shape by #1242 (its member-relative follow-up does not reproduce: yarn 1 locks member `file:` paths root-relative). #1271 and #558 still reproduce on main; open PRs #1274 and #1328 fix them (verified on the PR heads, incl. the scoped `@s/p@:` shape). Run 36: Run 36 filed #1271: a yarn.lock key with an **empty range** (`left-pad@:` from `"left-pad": ""`, or a merged `left-pad@, left-pad@^1.3.0:` block) is dropped by lock-only discovery and unmatched by the hosted and vendored rewriters (`split_pattern` rejects an empty range). It reproduces on v4.0.0 too. Run 36 also re-ran the EOL battery after #1227 (vendored writers now use the majority line ending) with no regression, and re-confirmed #692 and #558. #1236's follow-ups (renamed tarball / member copies) are tracked on that issue and PR #1242. Run 35 re-ran the batteries after #1008 (npm-family vendoring now goes through one generic driver, and #828 adds shadowed pins) with no regression, and filed #1236: a `file:` directory or git copy of the patched package under **another dependency name** (`"lp2": "file:./lpdir"`) isn't seen by hosted, vendored, in-run VEX or lock-only VEX, the renamed counterpart of #921. PR #1180 (#1158 / #1081) is still open. Run 34 re-ran the hosted / vendored / agent batteries after #1058 / #1147 / #1160 with no new yarn-only bug. On main a hosted scan with an `npm:` alias beside a direct copy now pins nothing (`redirect_unattributable`); open PR #1180 fixes that, #1158 and #1081 (verified at `46f1bc0`). Previously: Runs 5–33 added the cells in "Run 5 cells" through "Run 33 cells" below. Run 33 checked #1039 (the staged, atomic vendored→hosted takeover) and #1117 (BOM handling); the only new fail is #1158 (a takeover un-patches a vendored `npm:` alias copy beside a pinned direct copy). Run 32 checked #1057 (the yarn grammar refactor; it fixes the hosted half of #467), #1050 and #1029 with no regressions. #1013 / #1078 / #519 are closed by #1083 / #1033; run 31 verified the mirror fix cross-OS. Since run 28, #364, #921, #857, #884, #831, #974, #938 (#940) and #907 (#917) are closed by merged fixes, and #1071 (#1073) and #975 (#978) have landed too; the old `fail #364` cells now mean a project-level mirror is refused (pass), and #1115 (a mirror in a workspace member's `.yarnrc`) is the remaining mirror gap. The project-mode matrix below was measured on `f6b7fb9` (v4); cells marked "(v5)", the global matrix and the "v5 project-mode cells" list were re-run on v5.
+Previous: 2026-10-14 (run 40), main `a3f56f7`, release v5.0.1. Run 40 filed #1538: VEX still attests a yarn.lock pin written by v4.0.0 that yarn installs without the patched package's dependencies. #1463's `dependency_not_installed` check only asks whether the dependency name resolves, so a patch that changes a range (is-odd `is-number ^6`→`^7`, lock has only ^6) is attested by `vex` AND by the in-run `scan --vex` that reported it `redirect_unconfirmed`. Lock-only `vex` attests both the changed-range and the original #1462 added-dependency shape. Reproduced on 1.7.0 / 1.10.1 / 1.22.22. #1516 is verified fixed on main by #1517 (outside-root dir/tgz, non-`package/` root, URL and absolute-path renamed copies all warn H/V and VEX refuses). #692 still reproduces (not re-commented). #991 is half-fixed: `vendor --check` now exits 1 `vendor_ledger_missing`, but `rollback` still exits 0 and deletes the ledger while the other branch's package stays wired (commented). CI's yarn-classic-matrix (1.0.2–1.22.22) is green on the 2026-10-14 scheduled run.
 
 ## Coverage matrix
 
@@ -295,6 +295,7 @@ Other cells that pass on Linux 1.22.22 (some also on older releases; see the ent
 
 ## Backlog
 
+00000000000. #1558: after a fix, re-run the `""`-range, optional+dependencies dup and `*`+devDependencies shapes (lock-only, after `yarn add`, after a rescan). Also check whether the hosted writer's un-normalised sub-map makes every rescan after a `yarn add` rewrite the block (churn). Ask npm / pnpm / bun whether their lock-only dependency checks normalise manifests the way their PM does.
 0000000000. #1538: after a fix, re-run the v4-pin changed-range / added-dependency cells (installed, in-run, lock-only), plus `optionalDependencies` changes and a v4 vendored pin with a changed range. Ask npm / pnpm / bun whether their hosted VEX has the same name-only dependency check (hand over if it reproduces there).
 000000000. (#1516 verified fixed on main in run 40, Linux.) Still open: a Windows probe of `file:..\\x` spellings. Renamed copies under `resolutions` and in a transitive dep's manifest. (yarn-berry was handed the berry side.)
 00000000. #1462 follow-ups: the same pre-v5 hosted pin with a changed range (is-odd ^6 → ^7), a lock pinned by v5.0.0 then served a new patch revision at the same uuid, and npm / pnpm / bun hosted analogues (hand over if their rescans also skip the served-manifest check for already-pinned artifacts).
@@ -321,6 +322,8 @@ Other cells that pass on Linux 1.22.22 (some also on older releases; see the ent
 
 ## Known non-bugs
 
+- Run-41 harness: `h/mock.py` (generic: `MN` / `MV` / `MU` env, `PJ` = JSON of top-level package.json keys the patch replaces; serves the upstream registry tarball), `h/t.sh <name> <yarnver>` (PKG root package.json, POST hook after scan; prints scan codes, frozen-install patched state, installed and lock-only vex exits), `h/t4.sh` (same with `SCANBIN` = v4.0.0 from npm to write pre-v5 pins), `h/t1115.sh`.
+- yarn 1 `cleanDependencies` (normalize-manifest): a name in several of optionalDependencies / dependencies / devDependencies is kept only in the first, and a `""` / `"*"` range takes another field's non-trivial range. Lock blocks are written from that normalised manifest.
 - yarn 1 `resolutions` that match no install (`"**/left-pad": "1.3.0"` over a direct `left-pad ~1.1.0`, or an alias resolution `"lp": "npm:left-pad@1.3.0"`) still write a `left-pad@1.3.0` block that nothing installs (yarn installs 1.1.3). socket-patch pins / wires that dead block and VEX attests left-pad@1.3.0; the attested component isn't installed, so the statement is consistent with lock-based SBOMs. Not filed.
 - Dependency-changing patch mocks: the vendored path only reads the patched `package.json` when the patch RECORD lists `package/package.json` (`npm_common.rs`); a mock whose tarball changes package.json but whose `/view` record doesn't list it makes vendored skip the #591 check. Harness artifact, the real service builds the tarball from the record.
 - Run-40 harness: `h/t.sh <name> <mode>` (PKG / PRE / FRESHCP / LOCKCP / COPY hooks; `vex` needs `-O` with `--json`), `h/mockp.py` (the run-18 mock with `MN` / `MV` / `MU` / `DEPS` env knobs; DEPS also lists `package/package.json` in the record), `h/td.sh` (dep-change battery), `h/tv4.sh` (v4.0.0 pin → main rescan → frozen install → installed + lock-only vex), `reg.py` (plain-HTTP registry passthrough for hosted rollback). Don't `pkill -f mockp.py` from a shell whose command line contains that string.