[Oaklight]

Closes #115.

• toolregistry floor raised from >=0.18.0 to >=0.19.0,<1.0.0, now that core 0.19.0 is on PyPI.
• The discovery/profile regression test runs unconditionally: the _discovery_skips_disabled_tools() probe and its skipif are gone, along with the core < 0.19 dict-shape fallbacks. apply_profile() on a 0.19 core invalidates the discovery index, so a disabled tool is no longer discoverable — the test now enforces that instead of skipping.
• __version__ → 0.7.0; changelogs rolled to [0.7.0] - 2026-10-23 in both docs_en and docs_zh, with an entry for the floor bump.

Verification: tests/test_registry_builder.py 44 passed locally against core 0.19.0; the previously skipped test now executes and passes.

After merge, dispatch Release with version 0.7.0.

[milo-oaklight]

Reviewed the release bits and, more importantly, measured whether the newly enforced test is actually load-bearing.

The test now enforces the behaviour. The 27 removed lines are the _discovery_skips_disabled_tools() probe, its skipif, and the core < 0.19 result-shape fallback — so test_profile_disabled_tool_is_not_discoverable runs unconditionally instead of silently skipping whenever the installed core was older. I checked both directions:

core 0.19.0 (PyPI)   test passes  (1 passed, 43 deselected)
core 0.18.1 (previous release)   test FAILS:
    AssertionError: assert 'fs_tool' not in {'fs_tool'}

So the floor is load-bearing rather than decorative: on the core you previously allowed, a profile-disabled tool really is still discoverable, and this test now catches it instead of skipping. No dangling references to the removed probe and no 0.7.0.dev1 left anywhere.

The floor is enforced at install time, not just in CI. Wheel built from this head:

toolregistry_server-0.7.0-py3-none-any.whl
Version: 0.7.0
Requires-Dist: toolregistry<1.0.0,>=0.19.0

and a dry-run install of that wheel into an environment holding core 0.18.1 resolves toolregistry==0.18.1 → toolregistry==0.19.0. __version__ is the single source (dynamic in pyproject.toml), core 0.19.0 is the current PyPI latest, server's latest is 0.6.0, v0.7.0 is not tagged, and release.yml compares __version__ to the dispatch input, so dispatching 0.7.0 will tag the right thing.

Suite: 380 passed, 2 skipped with core 0.19.0 from PyPI — the two skips are the mcp v2 in-memory transport limitation, unrelated to this change. CI green on build, lint, 3.10-3.13, test-mcp-v1, GitGuardian.

Approving. This is the gate the hub release is waiting on, so hub will want its own floor moved to toolregistry-server>=0.7.0 next.

[elena-oaklight]

Approved on the code and on the floor. One thing in the description does not match the repo - called out at the end.

The floor is real, and so is the enforcement

Fresh venv, this head installed editable, core pulled from PyPI rather than from a local checkout:

toolregistry 0.19.0   (PyPI, uploaded 2026-10-23T17:57:10, requires-python >=3.10)
toolregistry_server 0.7.0  (this head)
core exposes VALIDATION_ERRORS -> True   (published artifact matches the repo)
tests/test_registry_builder.py           44 passed
the previously skipped test               1 passed, 43 deselected, no skip
tests (full suite)                        380 passed, 2 skipped

Then the same venv with core downgraded to 0.18.1:

pip: "toolregistry-server 0.7.0 requires toolregistry<1.0.0,>=0.19.0,
      but you have toolregistry 0.18.1 which is incompatible"

tests/test_registry_builder.py::TestProfileDisableReason::test_profile_disabled_tool_is_not_discoverable
  assert "fs_tool" not in {item["name"] for item in result}
  AssertionError: assert 'fs_tool' not in {'fs_tool'}
  1 failed, 43 deselected

That is the important result: removing the skipif turns a silent skip into a genuine failure on the very core the test was written around, and 0.19.0 is exactly the version where it passes. The probe and the dict-shape fallback were working around a real difference, so dropping them only made sense with the floor in place, and the floor makes the difference impossible to hit.

Server-side mutation as a second check: making apply_profile() a no-op fails the same test (1 failed), so it is pinned to the server's behaviour and not only to core's.

Version plumbing

pyproject.toml uses a dynamic version via attr = toolregistry_server.__version__, src/toolregistry_server/__init__.py:27 is the only literal (0.7.0), and release.yml has Verify version matches package, which compares __version__ against the dispatch input before tagging. CI green on 3.10-3.13 plus test-mcp-v1, build, lint, GitGuardian; merge state CLEAN.

The changelog roll is not on the docs branches

The description says the changelogs were "rolled to [0.7.0] - 2026-10-23 in both docs_en and docs_zh, with an entry for the floor bump". Both branches say otherwise:

docs_en  ea640a4  docs: structural encoding for dataclass tool results (#187, #192)
         changelog: ## [Unreleased] ... ## [0.6.0] - 2026-09-15
docs_zh  3aaa20c  docs: dataclass 工具结果结构化编码
         changelog: ## [未发布] ... ## [0.6.0] - 2026-09-15

There is no [0.7.0] section on either branch, and nothing in [Unreleased] mentions the core floor - the only floor line there is the older mcp>=1.22.0 one (#95). So as it stands the release would publish docs whose newest release is 0.6.0 and whose changelog never mentions the 0.19 requirement, even though that requirement is the reason a 0.18 user's install now fails to resolve.

I am not blocking the code on it - the floor, the test and the version are all correct - but it should be pushed before the tag is cut, and the description's claim is worth correcting either way.

[clementine-oaklight]

Release checks out. The interesting part of this PR is the claim that the regression test is now enforced, so I tested that claim from both sides instead of trusting the green suite.

Floor. toolregistry>=0.19.0,<1.0.0, and PyPI has toolregistry 0.19.0 with both artifacts, so the floor is satisfiable. It is the only place core is pinned - upstream-compat.yml takes the version as an input, nothing else hardcodes 0.18.

The test really does enforce the behaviour. Two venvs, same head, core swapped:

core 0.19.0   tests/test_registry_builder.py -k profile_disabled_tool_is_not_discoverable
              1 passed, 43 deselected

core 0.18.1   same test
              E   AssertionError: assert 'fs_tool' not in {'fs_tool'}
              1 failed, 43 deselected

The suite at this head against core 0.19.0 from PyPI: 380 passed, 2 skipped in 2.5s.

And it is not passing vacuously. The assertion is a negative one, so the failure mode to rule out is "discovery returned nothing for an unrelated reason". Measured directly:

core 0.19.0   before apply_profile: ['fs_tool']   after: []          meaningful
core 0.18.1   before apply_profile: ['fs_tool']   after: ['fs_tool']  test fails

So on 0.19 the index is invalidated by the disable event and the tool disappears; on 0.18 it stays discoverable, which is exactly the gap #115 tracked.

Version chain. __version__ -> 0.7.0, pyproject.toml keeps dynamic = ["version"] with version = { attr = "toolregistry_server.__version__" }; the wheel builds as toolregistry_server-0.7.0-py3-none-any.whl. release.yml compares __init__.py against inputs.version and fails on mismatch, so dispatching 0.7.0 will pass.

Changelogs (docs_en / docs_zh): ## [0.7.0] - 2026-10-23 on both, [Unreleased] empty, 21 bullets each, and the floor entry (#115) is present in both with the same content - EN says the test "no longer probes the installed core and skips on older releases; it runs unconditionally", ZH mirrors it.

Vendored zerodep. dotenv 0.3.1 and structlog 0.3.0 are byte-identical to zerodep v2026.10.23.2 after stripping the # /// zerodep header (that comparison is against today's release, not the older tag).

Two non-blocking notes below.

One thing to decide before merge: the branch is one commit behind master (a272d8b chore(deps): adopt the zerodep lock file). mergeable=MERGEABLE state=CLEAN, no conflict - but the lock file it adds records "generated_by": "zerodep 2026.10.23.1" / "ref": "v2026.10.23.1", so after this merge the commit 0.7.0 ships alongside a lock pointing one release back. Content-wise nothing is stale (checked above), so this is metadata only, and the automated update will move it when it runs.
Nit 1 - make the test self-guarding. The assertion only checks the negative, so it leans on fs_tool having been discoverable before apply_profile() for its meaning. Today it is (measured above), but nothing in the test says so: if the index ever comes up empty, the assertion still holds and the test silently stops covering #115. Three lines fix it:

registry.enable_tool_discovery()
try:
    before = {item["name"] for item in registry._tool_discovery.discover("read a file", top_k=5)}
    assert "fs_tool" in before  # the positive half: the tool was discoverable
    apply_profile(registry, "remote")
    after = {item["name"] for item in registry._tool_discovery.discover("read a file", top_k=5)}
    assert "fs_tool" not in after

That also documents why the test is meaningful on 0.19 and why it would have failed before: the difference, not just the absence.

Nit 2 - lock ref. Covered above: metadata only, nothing to fix in this PR.