[Oaklight]

Why

The vendored zerodep modules had no install record, so the weekly zerodep-update job could only compare content hashes: it could not tell an upstream change from a local edit, and the old CLI would have overwritten either. It also filtered on a single status == 'outdated' value that no longer exists.

What changed

• zerodep.lock.json added next to the vendored modules, pinned to v2026.10.23.1. It records the source ref, each module's version and upstream hash, and the sha256 of every installed file.
• Pending updates applied: httpclient 0.5.1 → 0.6.1, httpserver 0.5.1 → 0.6.1, jsonx 1.0.0 → 1.0.2. The other five modules already matched upstream and are now recorded as such.
• .github/workflows/zerodep-update.yml now:
  • installs zerodep>=2026.10.23.1;
  • reads zerodep status --json and treats only outdated/missing as automatable;
  • lists locally-modified, conflict, unverified and upstream-removed in the PR body as needing a human, instead of counting them as updates;
  • runs zerodep update --all and verifies with a second status that every previously-outdated module reached up-to-date, so an exit 1 for skipped modules is not mistaken for a failed install nor for success.

From now on a local edit to a vendored file is never overwritten by the weekly job; it becomes a locally-modified line in the PR body (or a warning when nothing is automatable).

Testing

• Ran the new CLI against this tree: before status reported 3 unverified + 5 up-to-date; after adoption and update, all 8 are up-to-date.
• Simulated the workflow locally: a locally edited file is classed locally-modified, update --all skips it (exit 1), the verification step still passes, and the edit is intact.

[clementine-oaklight]

Lock provenance verified against v2026.10.23.1. For each entry I fetched the module from the tag, applied the CLI's install-note rewrite, hashed it, and compared to the lock, the vendored file, the tag's content_hash, and the version:

• httpclient 0.6.1, httpserver 0.6.1, jsonx 1.0.2, jsonschema 0.4.1, sparse_search 0.4.0, structlog 0.3.0, yaml 0.3.1 — all four checks match exactly.
• validate 0.7.1 — the code matches (content_hash equal, so upstream_hash is right), but the vendored bytes are not what the tag produces: its frontmatter still says note = "Install/update via: https://zerodep.readthedocs.io/..." where the tag says note = "Install/update via `zerodep add validate`". The frontmatter is outside content_hash, so bootstrap adopted it and status correctly reports up-to-date — but the lock's per-file hash for that entry records local bytes, not v2026.10.23.1 bytes. Inline note filed; low, and add validate --force fixes it if you want the entry exact.

source.ref is v2026.10.23.1, generated_by is the matching CLI, and the lock covers every module in _vendor (only __init__.py is outside it).

Workflow, exercised rather than read. I extracted both python3 blocks from zerodep-update.yml and ran them against status --json fixtures covering every state:

• outdated updated + a locally-modified sibling → green, and the skipped module is untouched
• outdated still outdated after update --all || true → red (update did not bring these modules up to date: ['yaml'])
• only locally-modified / only conflict / only unverified / only upstream-removed → has_updates=false, update step skipped, green with a warning
• a missing dependency → has_updates=true, installed, green
• outdated updated while an unverified module stays behind → green

So a skipped module is never counted as an update and never fails the job, while a genuinely stuck module does. status in the verify step is not || true, so a network failure there fails the step rather than passing silently. One consequence worth knowing: unverified modules are reported but never updated and never fail, so a hand-placed or patched file stays a permanent warning and never enters the lock — that is the #254 design, not a defect in this PR.

Tests. 1818 passed, 14 skipped with the bumped modules. For comparison I swapped back master's httpclient/httpserver/jsonx and got the same 1818/14 — no regression, but the suite does not discriminate the bump either, so it is a safety net rather than a proof that the new paths work. That is fine given the bump carries zerodep's own 2668-test suite, just don't read green here as "the upgrade is exercised".

Approved.

[clementine-oaklight]

This entry's files hash is the vendored file's bytes, which differ from what the tag produces: the frontmatter still carries note = "Install/update via: https://zerodep.readthedocs.io/en/latest/guide/cli/" while v2026.10.23.1 writes note = "Install/update via `zerodep add validate`". The frontmatter is excluded from content_hash, so adoption matched and status is right to call the module up to date — but this lock records bytes that did not come from the tagged CLI, which is the one thing the lock claims not to do. zerodep add validate --force (or delete the file and re-add) makes it exact.

[Oaklight]

Fixed clementine's provenance nit: validate.py still carried the old generic note in its frontmatter, so the lock recorded local bytes rather than the tagged bytes (frontmatter is outside content_hash, which is why status called it current). Re-ran zerodep add validate --force, so the note now matches the tag and the lock is byte-exact. All eight modules still report up-to-date.