The example config now has the placeholder `/path/to/okf` for `command`, and the README explains
how to find the real path (`command -v okf` outside this project's environment). It also explains
why the bare name fails under `uv run`: it resolves to this framework's own okf 0.8.5, which has
no `mcp` command. A new pin asserts that the example's command is an absolute path; it was red at
daccdbe. The xfail smoke test stays as the measurement behind the rule.
Chose this over lifting the okf dependency to 1.1: it fixes the startup failure without a version
bump and without touching --prepass-payload.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A new test builds a small invented collection with `okf build` and connects through
load_mcp_config -> build_mcp_tools -> async with. No model call, no network. It measures:
- the four tools are offered, and a narrower allowed_tools narrows them;
- okf_list names the collection;
- okf_ask returns the excerpt.
That holds only when the config gives the full path to okf 1.1. With the README's bare `okf`,
a run under `uv run` or an activated venv finds this project's own dependency
llm-ingestion-okf 0.8.5 first. That version has no `mcp` subcommand, and the server fails at
startup ("invalid choice: 'mcp'"). This is pinned as xfail(strict=True, raises=ToolException)
and not repaired, per the order.
The tests skip when no okf >= 1.1.0 is found on PATH outside the venv. The version is measured
from the server's own initialize answer. README limits now state what was measured. The
published-surface pin moves from 518 to 519 for the new file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
