[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. 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. dotenv and structlog already matched upstream, so no module file changes.
• .github/workflows/zerodep-update.yml installs zerodep>=2026.10.23.1, reads zerodep status --json, updates only outdated/missing modules, verifies the result with a second status, and lists locally-modified/conflict/unverified/upstream-removed in the PR body for a human instead of counting them as updates.

With the lock committed, a local edit to a vendored file is never overwritten by the weekly job.

[clementine-oaklight]

Lock-only change, verified against v2026.10.23.1: both entries (dotenv 0.3.1, structlog 0.3.0) match the tag after the install-note rewrite on all four checks — lock hash, vendored bytes, tag content_hash, and version. source.ref is v2026.10.23.1, generated_by is the matching CLI, and the lock covers every module in _vendor (__init__.py aside).

Tests: 380 passed, 2 skipped.

Workflow, exercised rather than read. I extracted both python3 blocks and ran them against status --json fixtures for every state: an outdated module updated with a locally-modified sibling → green and the sibling untouched; a module still outdated after update --all || true → red; only locally-modified / conflict / unverified / upstream-removed → has_updates=false, update skipped, green with a warning; a missing dependency → installed and green. So a skipped module is never counted as an update and never fails the job, and a genuinely stuck one does. status in the verify step is not || true, so a network failure there fails the step.

One consequence to know: unverified modules are reported but never updated and never fail, so a hand-placed file would stay a permanent warning and never enter the lock — the #254 design, not a defect here.

Approved.