You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit ba9ada4
Browse filesBrowse the repository at this point in the historyBrowse files
Fix vendored-ledger root under --manifest-path (#745) (#1345)
* Root vendored-ledger access at the manifest project
WIP for #745.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Root vendored-ledger access at the manifest project
With --manifest-path into another project, rollback, remove, repair,
apply --check, vex and agent-mode scan/get read (and rollback/remove
saved) the vendor ledger of --cwd while list, apply and vendor --check
read the manifest project's. One run could revert one project's agent
patches and another project's vendored artifacts, and rollback wrote a
ledger its apply lock did not cover.
Every ledger read, revert and save now uses GlobalArgs::project_root;
the vendored backend and the scan --prune vendored GC run re-rooted
there. Hosted/vendored scan and get, and vendor other than --check,
rewire --cwd's lockfiles, so they now refuse a manifest in another
project (exit 2, manifest_path_foreign_project). An architecture test
pins that no ledger access outside the vendoring engine takes a cwd.
Fixes#745
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Keep a bare --manifest-path file in the cwd project
A manifest file outside any .socket/ directory (--manifest-path
state/patches.json, /etc/socket/manifest.json) relocates only the
manifest; the project whose vendor ledger and lockfiles a run uses
stays --cwd. Previously project_root() named the file's own
directory, so list and apply looked for the ledger next to the
relocated manifest, and the new foreign-manifest guard would have
refused hosted scan for such a file.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Unwind hosted pins in the manifest project too
Bugbot on #1345: rollback, remove and repair read the vendor ledger
from the manifest's project but still discovered and restored hosted
pins (and the pre-v5 redirect ledger) in --cwd, so a foreign-manifest
rollback could unwind two projects at once, and missed the pins list
and vex report. The hosted inventory, the legacy-ledger probes and
retirement, and the hosted restore leg now run at project_root too.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Run standalone vex at the manifest's project
vex loaded the ledgers and wiring discovery from the manifest's
project but detected the product, crawled installed copies and ran the
pnpm/PnP guards in --cwd. With --manifest-path into another project,
that project's hosted pins could vouch for --cwd's lockfile-only
packages, and the product came from the wrong package.json. vex now
runs under GlobalArgs::at_project_root(), so the whole document
describes one project (a no-op in the default layout).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* Refuse embedded --vex with a manifest in another project
`apply --vex` and agent-mode / report-only `scan --vex` patch --cwd's
installed copies, but the VEX document's product, ledgers and lockfile
wiring come from the manifest's project (#745), so one document would
attest one project from another's state. Re-rooting would instead verify
copies the run never patched. Refuse the combination up front with the
existing usage-error code `manifest_path_foreign_project` (exit 2), using
the same project-root comparison (`manifest_project_is_foreign`) as the
hosted/vendored refusals. A manifest resolving into --cwd's own project
is never refused; `apply --check` (no document) and standalone `vex`
(runs wholly in the manifest's project) stay allowed.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
0 commit comments