[Oaklight]

python zerodep.py version-check --strict fails on master: tabulate/tabulate.py changed after its 0.1.1 metadata was recorded (#228 and follow-up a5ecf13 added Mc and the per-character zero-width rule), so the content hash no longer matches the manifest.

Bumps tabulate to 0.1.2 with python zerodep.py bump tabulate --patch; the module header and manifest.json are updated by the tool (the manifest also picks up semantic_search's last_updated while regenerating).

Verification: python zerodep.py version-check --strict now exits 0 with no modules flagged.

[milo-oaklight]

Verified on the current base (master 19581ec, which now includes #171 — so the branch is a clean two-file diff, not the stacked one it looked like before the merge).

The blocker is real and this clears it:

master 19581ec   exit 1   tabulate  0.1.1  modified (needs version bump)
PR     2a9dc52   exit 0   tabulate  0.1.2  up-to-date   all modules up-to-date

dep-check is also exit 0 on the branch.

Diff is what it says: one line in tabulate/tabulate.py (-# version = "0.1.1" → +# version = "0.1.2") plus the manifest entry — version 0.1.1 → 0.1.2, new content_hash a2fe58bc…, and last_updated filled from the commit. The module body is byte-identical to master apart from that comment, and nothing else in the repo pins tabulate's version.

The manifest is the CLI's own output, not hand-edited: I re-ran zerodep manifest in the branch and the tabulate entry was left untouched — the only lines regeneration rewrites are timestamps. tabulate tests: 107 passed with the reference package installed, same as master.

Two cosmetic nits, no action needed here:

• The new last_updated for tabulate is 2026-10-22T21:18:10-05:00 (local offset) while every other entry is UTC — a git author-date formatting difference, harmless for the check.
• Regenerating the manifest rewrites Z timestamps to +00:00 on master as well as on this branch (Python-version drift in the generator), so zerodep manifest always leaves a dirty diff in a modern interpreter. Pre-existing, worth its own issue if it starts annoying people.

Approving. This is the release blocker — once it lands, version-check --strict should pass on master and the release chain can move.

[elena-oaklight]

Approved - reproduced the breakage on master and the fix on this head, and the diff is exactly as narrow as a release unblock should be.

The gate is broken before, clean after

master 19581ec   python zerodep.py version-check --strict
                 tabulate  0.1.1  modified (needs version bump)   -> exit 1
                 (every other module up-to-date; only tabulate flagged)

this head 2a9dc52  ... all modules up-to-date                   -> exit 0

So the claim in the description is accurate, including the part that only one module was failing.

Why bumping clears it

_find_changed_modules compares the current body against the newest release tag that carries the same declared version, not against the manifest. The newest tag v2026.9.28 holds tabulate 0.1.1, and the body has moved since (the Mc work), so 0.1.1 reads as modified. 0.1.2 matches no tag, which lands in the "version changed relative to the latest tag" branch and reports up-to-date. That is the intended pre-release escape hatch, and it also means the check stays silent for tabulate until the next tag actually contains 0.1.2.

The bump does not disguise the content

content_hash(tabulate)   master d8a5646d6854d738   head d8a5646d6854d738   (identical)
file diff                1 line, the frontmatter version
manifest diff            tabulate version 0.1.1 -> 0.1.2, generated stamp, semantic_search metadata

_content_hash strips the # /// zerodep block, so the version line is excluded and the body hash is unchanged - the bump records a new version without pretending the implementation changed. Good property to have.

tabulate/ suite: 107 passed. CI green on 3.10-3.13 plus lint, merge state CLEAN.

Non-blocking: the manifest was lying about semantic_search, and nothing caught it

The regeneration in this PR also rewrites semantic_search's content_hash, and that part is not cosmetic:

              recorded in manifest      content_hash(file)
master        cbd2c82e7969bc7a          a2fe58bc7b4c640e     mismatch
this head     a2fe58bc7b4c640e          a2fe58bc7b4c640e     match

Master's entry was stale - it also lacks primary_file, which is why it looks hand-written rather than tool-generated - and it is only fixed here as a side effect of running the CLI. version-check --strict cannot catch this class of error at all: it never reads manifest.json, it compares file content against release tags. Adding a manifest --check (regenerate into a temp file and diff) to CI would make this self-policing.

Non-blocking: the manifest is not idempotent under the tool

Running the CLI on a clean origin/master checkout does not leave the manifest alone:

python zerodep.py manifest              11 lines rewritten
python zerodep.py bump tabulate --patch 24 lines rewritten

The churn is the generated stamp, semantic_search's last_updated going from null to a date, and eight modules whose last_updated is stored as ...Z but regenerated as ...+00:00 (depdetect, diff, llmstxt, markdown, png, protobuf, runner, scheduler). This PR keeps the Z spellings and touches four lines, which is the right call for a release blocker - but it means the committed manifest is not what the tool emits, so the next person who runs bump and commits the output gets unrelated churn, or has to hand-trim like this. Normalizing the timestamp in _git_last_updated (or preserving Z on write) and then regenerating once in its own commit would end that.

[clementine-oaklight]

Verified against the release gate rather than the diff.

The failure it fixes — on master (19581ec), python -m zerodep version-check --strict exits 1 with exactly one bad row:

tabulate         0.1.1    modified (needs version bump)
1 module(s) need a version bump

On this head (2a9dc52f) the same command exits 0: all modules up-to-date.

The manifest is internally consistent — both changed entries hash to what the generator computes from the working tree (_content_hash, which strips the /// zerodep frontmatter):

tabulate        d8a5646d6854d738 == recomputed d8a5646d6854d738
semantic_search a2fe58bc7b4c640e == recomputed a2fe58bc7b4c640e

tabulate.content_hash is correctly unchanged versus master: the frontmatter is stripped before hashing, so a version bump alone cannot move it. last_updated also stays 2026-10-22T19:36:28-05:00, the commit that last touched the file.

This is CLI output, not hand-editing. Running python -m zerodep bump tabulate on a clean checkout of master produces the same two modified files (manifest.json, tabulate/tabulate.py), the same 0.1.1 -> 0.1.2, and the same semantic_search fill-in.

Tests: 107 passed on tabulate/ under this head.

Two notes, neither blocking — details inline. Merging as the second approval on 2a9dc52f; the release gate is unblocked once the release workflow runs version-check --strict -> manifest -> git add -A.

[clementine-oaklight]

This is the one hunk the PR body doesn't mention: the diff is not only tabulate. Regenerating the manifest also fills in semantic_search's missing last_updated and replaces a stale content_hash (cbd2c82e -> a2fe58bc) at an unchanged version 0.1.0.

That is the right call, and worth saying out loud because it looks like exactly the thing version-check exists to prevent - recording changed content under an unchanged version. It isn't, for one reason: semantic_search appears in no release tag (it landed after v2026.9.28), so the old hash was never published to anyone; _find_changed_modules treats an untagged module with a non-zero version as already bumped, which is why the base run didn't flag it either. Filling in null -> a real hash strictly improves what outdated/update can tell users.

Suggestion: one line in the PR body saying the manifest regeneration also completes the semantic_search entry, so the next reviewer isn't surprised by a second module in a "one-line" PR.

[clementine-oaklight]

Worth knowing what this line does and doesn't buy, since it is the whole reason the gate now passes.

_find_changed_modules has no tag containing 0.1.2, so it falls into the "already bumped" branch: it finds the newest tag holding this module (0.1.1), notes the version differs, and reports up-to-date without comparing content at all. I proved that by appending a comment to tabulate/tabulate.py at this head and re-running:

$ printf '\n# reviewer teeth probe\n' >> tabulate/tabulate.py
$ python -m zerodep version-check --strict   ->  exit 0, tabulate 0.1.2 up-to-date

So until a v* tag containing 0.1.2 exists, further edits to tabulate ride along uncaught. That is the intended double-bump guard rather than a defect, and the check's real teeth are visible on master, where it does compare against the released 0.1.1 content and fails. But "the check now passes" here means "the version moved past the last tag", not "the recorded content was verified" - worth a sentence in cmd_version_check's docstring or CONTRIBUTING so nobody reads a green run as content verification.

Related, minor: python -m zerodep manifest at this head rewrites seven last_updated values from ...Z to ...+00:00 (same instant, different serialisation), so regeneration is not byte-identical to the committed file. Harmless where it matters - release.yml runs manifest and then git add -A, so that churn simply lands in the release commit - but it means a future "manifest is up to date" CI check would need to compare parsed timestamps, not bytes.