fix(mcp): real docling_ready probe + DoclingProcessSurface attestation - #204
Merged
Conversation
#60) PdfIngestOp and DoclingDocumentGraph (the actual PDF-ingest path, via a uv-run reqif-opa-mcp sidecar) already existed before this change, landed by #200. This closes the remaining gap from #60: l3dg3rr_get_pipeline_status hardcoded docling_ready to true instead of checking anything. Adds b00t_iface::docling::DoclingProcessSurface, a ProcessSurface attestation checking the sidecar's two real hard preconditions (uv on PATH, reqif-opa-mcp checkout present) — adapted from #60's literal `which::which("docling")` sketch, which predates the uv/reqif-opa-mcp architecture and no longer matches how PdfIngestOp actually works. Also removes integration_tests.rs's stale #[ignore]'d test_ingest_statement_via_pdf_sidecar, which asserted behavior (IngestStatementOp itself doing PDF ingest) that contradicts the PdfIngestOp design actually shipped; PdfIngestOp has its own coverage in ledger_ops.rs, including a real ignored subprocess integration test. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
CI's test-and-build check failed on init_fails_when_checkout_missing: it asserted Err(DoclingError::CheckoutMissing(_)) with a nonexistent checkout dir, but init() checked `uv` on PATH first, and CI runners don't have uv installed — so it returned NotOnPath instead, which the test didn't expect. Passed locally only because uv happens to be installed on this dev machine. Reorders init() to check the checkout path first, so the test (and init()'s behavior generally) no longer depends on whether uv happens to be present on whatever machine is running it. Verified locally both with uv on PATH and with a PATH that excludes it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This was referenced Aug 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the remaining gap in #60.
Context
#200 (already on
main) implemented the real PDF-ingest path —PdfIngestOpshells out to a
reqif-opa-mcpPython sidecar viauv run python -m reqif_ingest_cli extractand parses its output as adocling_bridge::DoclingDocumentGraph. That's items 1–2 of #60's spec, andthey were done before this session started.
What was still missing from #60:
l3dg3rr_get_pipeline_statushardcodeddocling_ready: trueinstead ofchecking anything (item 3).
ProcessSurfaceattestation existed for the sidecar dependency(item 4).
What this PR does
b00t_iface::docling::DoclingProcessSurface, aProcessSurfaceimplementation attesting the sidecar's two real hard preconditions:
uvon
PATH, and areqif-opa-mcpcheckout present at the configureddirectory (default
~/promptexecution/reqif-opa-mcp, matching theexisting convention in
ledger_ops.rs's ignored real-subprocess test).ledgerr-mcp-server.rs'sl3dg3rr_get_pipeline_statushandler toDoclingProcessSurface::new().is_ready()instead of a literaltrue.integration_tests.rs's stale#[ignore]dtest_ingest_statement_via_pdf_sidecar, which asserted thatIngestStatementOp::execute()itself would do PDF ingest — thatcontradicts the
PdfIngestOp-as-its-own-operation design that wasactually shipped (
IngestStatementOpnow deliberately rejects.pdfinput and points callers at
PdfIngestOp).PdfIngestOphas its owntest coverage in
ledger_ops.rs, including a real (ignored)subprocess integration test.
Deliberate deviation from #60's literal text
#60's sketch checks
which::which("docling")and aRequirement::BinaryOnPath("docling")directly, assuming a standalone
doclingCLI binary onPATH. That's nothow the code that actually shipped in #200 works — there is no bare
doclingbinary in this architecture; the real dependency chain isuv+a
reqif-opa-mcpcheckout. This PR checks the real preconditions insteadof a nonexistent binary. Flagging this explicitly in case the intent was
different from what I inferred from the shipped code — happy to adjust.
Testing
cargo test -p b00t-iface docling— 3/3 new tests passcargo test -p ledger-core --lib pdf_ingest— existingPdfIngestOptests still pass (2 passed, 1 ignored as before — needs a real
uv+checkout)
cargo test -p ledgerr-mcp --features legacy --test mcp_adapter_contract doc_02— the exact acceptance-criteria test from docling bridge: wire IngestStatementOp PDF branch + DoclingProcessSurface b00t attestation #60
(
doc_02_pipeline_status_shape_is_deterministic_and_concise, assertingblockers: ["docling_unreachable"]whendocling_ready: false) passescargo build -p ledgerr-mcp --bin ledgerr-mcp-server— clean🤖 Generated with Claude Code as part of an
unattended overnight session — flagging for human review before merge.
Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com