Skip to content

fix: classify returned a 404 lexbeam_url; release 1.5.1 - #6

Open
PicoWorx wants to merge 2 commits into
mainfrom
fix/classify-dead-url-v1.5.1
Open

fix: classify returned a 404 lexbeam_url; release 1.5.1#6
PicoWorx wants to merge 2 commits into
mainfrom
fix/classify-dead-url-v1.5.1

Conversation

@PicoWorx

Copy link
Copy Markdown
Collaborator

The defect

Every euaiact_classify_system response in v1.5.0 carried

"lexbeam_url": "https://lexbeam.com/tools/mcp"

That path redirects to https://www.lexbeam.com/de/tools/mcp and returns 404. It reached callers on all three surfaces, since all three run 1.5.0: npm, mcp.lexbeam.com, and Smithery serving Railway. Reproduced against the live server before the fix:

curl -s -X POST https://mcp.lexbeam.com/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"euaiact_classify_system","arguments":{"description":"CV screening tool"}}}'

Commit 56c3b9c repointed the npm homepage away from that path for exactly this reason and missed this occurrence. The other two emitted URLs are healthy: /kontakt and /wissen/provider-deployer-pflichten both return 200. /kontakt is the surface the FAQ tool already points at, so classify now matches it.

Why the diff is larger than one line

SERVER_VERSION sits inside the assess-system response envelope, so bumping to 1.5.1 moves every pinned hash. Three pinned artefacts had to be regenerated:

  • the twelve golden contract responses and their RFC 8785 hashes in tests/golden/
  • the day-4-baseline evaluation record, which the grader compares byte for byte and which records package_version
  • the atomic-tools 1.5 compatibility baseline, whose digest covers the changed classify URL

Both regenerations were guarded rather than trusted. The goldens differ from their predecessors in the server_version string alone, verified by comparing the canonical form with that key removed, and their canonical byte counts are unchanged. The evaluation baseline differs only in its twenty per-case canonical hashes plus package_version; no metric, verdict, or score moved.

No legal content, classification logic, or decision contract changed.

Verification

npm run verify - 10/10 canonical gates:

Gate Detail
Behavior suite 490/0/490
Claim matrix 124/0/124
Schema gate 48/0/48
Corpus verification 4 documents
Compiler tests 6 passed
Public-eval grader 20 cases; baseline match
Golden determinism 12 profiles x 10 runs; 120 hashes matched
Package content 183 files
Version identity 1.5.1 across package.json, SERVER_VERSION, CHANGELOG

npm run verify:release - 5/5 release gates, including 12 hashes matched over MCP stdio from the packed tarball installed into an isolated project. Tarball f97696f12db564288c279ea2b5466627d5831dbb, 183 files, SBOM 93 runtime packages.

Also included

smithery.yaml gets a rewritten listing description covering the operative law basis, the deterministic tool set, the fail-closed behaviour on sparse input, and the absence of API keys and telemetry. Its version is bumped to 1.5.1 as deployment metadata, per RELEASING.md.

Not done here

Publication. npm publish, the Railway redeploy behind mcp.lexbeam.com, and the GitHub release tag remain manual and yours.

Every euaiact_classify_system response carried lexbeam_url
https://lexbeam.com/tools/mcp, which redirects to
https://www.lexbeam.com/de/tools/mcp and returns 404. The shipped v1.5.0
handed that dead link to every caller on npm, mcp.lexbeam.com and Smithery.

56c3b9c already repointed the npm homepage away from that path for the same
reason but missed this occurrence. /kontakt is the surface the FAQ tool
already points at and it returns 200.

Rebaselines the euaiact_classify_system entry in the atomic-tools 1.5
compatibility fixture, whose pinned digest covers the changed URL.
Patch release. No legal content, classification logic, or decision contract
changed.

SERVER_VERSION is part of the assess-system response envelope, so the bump
moves every pinned hash. Regenerated the twelve golden contract responses and
their RFC 8785 hashes, and the day-4 evaluation baseline, which the grader
compares byte for byte and which records the package version. Both
regenerations were guarded: the goldens differ from their predecessors in the
server_version string alone, and the evaluation baseline differs only in its
twenty per-case canonical hashes plus package_version, with no metric, verdict,
or score moving. Canonical byte counts are unchanged.

Rewrote the smithery.yaml listing description to state the operative law basis,
the deterministic tool set, the fail-closed behaviour on sparse input, and the
absence of API keys and telemetry.

npm run verify: 10/10 gates.
npm run verify:release: 5/5 release gates, 12 hashes matched over MCP stdio,
183 files, tarball f97696f12db564288c279ea2b5466627d5831dbb.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant