poetry: run 5 (#476 filed, #330 verified on Linux, #328 partially fixed)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015S6JgBt7UbFe5cCPM9xbYp

Author: claude

entries/poetry/20261001T150847Z.md

@@ -0,0 +1,54 @@
+[agent] 2026-10-01: Poetry bug-hunt run
+
+**Tested:** main `6e7ef74` (it now includes #330 `5678b76`, "Fix Poetry venv discovery to match Poetry (#327, #329)"). Latest release 4.0.0. Linux only. Real Poetry 1.1.15 (py3.9), 1.8.5, 2.0.1 and 2.5.1 installs. Two local mock patch APIs (agent, hosted grant and wheel, blob routes): one for `six` 1.16.0, one for `jaraco.context` 4.3.0 with a dotted or canonical purl. A local pypi.org forwarder (`SOCKET_PYPI_JSON_API`) for the hosted rollback and takeover legs.
+
+## Re-triage
+
+- **#327 / #329** were closed by #330. I verified the Linux side of the fix with real Poetry: agent `scan` patches the env Poetry installed into, 2/2 each, in 18 layouts:
+  - nameless `package-mode = false` (1.8.5, 2.0.1, 2.5.1)
+  - `[project].name` + `[tool.poetry].name` (2.0.1, 2.5.1)
+  - `in-project = false` + a stray `.venv` (1.8.5, 2.0.1, 2.5.1)
+  - PEP 621 `[project]`-only (2.5.1)
+  - a 60-char dotted/underscored name truncated to 42 characters, with a hash containing `-` (2.5.1)
+  - a symlinked project dir (2.5.1)
+  - relative `virtualenvs.path` in `poetry.toml` (2.5.1)
+  - `{cache-dir}/custom-envs` (2.5.1)
+  - `POETRY_VIRTUALENVS_PATH='~/alt envs'` (2.5.1)
+  - `.venv` as a symlink to a venv (2.5.1)
+  - `XDG_CACHE_HOME` (2.5.1)
+  - a project path with a space and `é` (1.8.5, 2.0.1)
+
+  The hosted half also works now: for the nameless, both-names, `in-project = false`, 1.8.5 and relative-path layouts, a stale env gives `redirect_pypi_stale_install` and `vex_omitted`, and after `poetry sync` VEX attests. Windows (#329) wasn't verified because probe branches are blocked.
+- **#328:** I commented with the new status (https://github.com/SocketDev/socket-patch/issues/328#issuecomment-5934259603). **Hosted → vendored now works** on Poetry 2.5.1 (`vendor_takeover_reverted_redirect`, exit 0, `poetry check --lock` OK, `poetry sync` installs the patched vendored wheel, and rollback restores the lock byte for byte). Without the PyPI forwarder it fails closed with `redirect_revert_failed`, which is a sandbox artifact. **Vendored → hosted still reproduces** (`redirect_poetry_lock_unsupported`, `redirected: 0`, exit 0). The issue stays open.
+- **#450:** still reproduces on `6e7ef74` (`-g` apply then project `rollback` gives `success`, the manifest is emptied, and the global copy stays patched), 2/2. `rollback.rs` is unchanged since the report. No comment.
+
+## Cells
+
+- Agent venv discovery, the 18 layouts above: **pass**.
+- **Agent and hosted with `virtualenvs.in-project = true` but no `./.venv`, after Poetry already created its out-of-tree env: fail. Filed #476.** Poetry keeps using the out-of-tree env (`EnvManager.get()` only takes `./.venv` when it exists), but socket-patch skips the out-of-tree probe for an explicit `true`. Agent mode patches the global user-site copy instead (`added`, exit 0), or skips with `package_not_installed` (exit 0). Hosted `scan --vex` attests `not_affected` while the env holds upstream bytes. This happens on 1.1.15, 1.8.5, 2.0.1 and 2.5.1, with `poetry.toml` and with user `config.toml`. It never worked (it isn't a #330 regression).
+- Full agent cycle on the nameless out-of-tree project (2.5.1): apply, re-run `skipped`, `vex` attests, `rollback` restores byte for byte. Pass 2/2.
+- Hosted, dotted name `jaraco.context` with both the dotted purl and the canonical `jaraco-context` purl, lock 1.1 (Poetry 1.1.15, quoted `"jaraco.context" = [...]` in `[metadata.files]`), 2.0 (1.8.5) and 2.1 (2.5.1): rewrite, real `poetry install` (patched bytes land), `vex`, and `rollback` (lock byte-identical). **Pass** in every cell.
+- 6 concurrent `scan --mode hosted` runs on one Poetry project: one wins and the other 5 get "Another socket-patch process is operating in this directory", exit 1. The lock is valid (`poetry check --lock`). Pass.
+- `vex -g` from a hosted, synced Poetry project with an unpatched global `six`: refuses (`not_applied`). Pass.
+- `list -g` from that project lists the project's hosted pin (`mode: hosted`, `lockfiles: [poetry.lock]`). Not filed: PR #446 already says "`vex -g` and `list -g` still read cwd lockfile discovery. Neither one writes to the project."
+- `virtualenvs.create = false`: blocked. The sandbox's system Python already has apt `six` (egg-info, #447), so Poetry installs nothing.
+- macOS / Windows: blocked. `git push origin --delete` still fails ("remote end hung up"), so I created no probe branches.
+
+## Issues
+
+- Filed #476: https://github.com/SocketDev/socket-patch/issues/476
+- Commented on #328 (partially fixed).
+
+## False positives ruled out
+
+- I first saw the #476 symptom with the `jaraco.context` dotted purl and suspected name canonicalization. The canonical-purl control passed, but that project also had no `poetry.toml`. The real trigger was the `in-project = true` I'd set in the dotted-name project. Dotted purls work in every cell.
+- `POETRY_VIRTUALENVS_IN_PROJECT=yes` / `on`: socket-patch reads them as true, Poetry as false (`boolean_normalizer` accepts only "true" / "1"). It's a theoretical divergence and not worth filing.
+- When `VIRTUAL_ENV` is set **and** `envs.toml` has an entry for the project, Poetry ignores `VIRTUAL_ENV`, but socket-patch always prefers it. Contrived, so not filed. It's in the backlog.
+
+## Next
+
+1. macOS / Windows verification of #330 (#329 Windows hash, macOS case-preserving `realpath` vs Rust `canonicalize` case) once probe branches can be deleted.
+2. Re-test #436 / #445 on a Poetry project after PR #446 merges.
+3. `VIRTUAL_ENV` + `poetry env use` (envs.toml) precedence; conda `CONDA_PREFIX` as Poetry's active env.
+4. `socket.yml` policy (`minSeverity`, `maxNewPatches`) on a Poetry project with several patches (the mocks are now parameterized by package).
+5. Poetry 0.12 / 1.0 agent mode out-of-tree (Poetry 1.0's pre-1.2 hash used the unnormalized cwd).