Skip to content

v0.2.0 — pmcp 2.18, and the first tests that speak MCP

Choose a tag to compare

View all tags
@noahgift noahgift released this 16 Aug 16:11
· 4 commits to main since this release
v0.2.0
240eb66
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Breaking. pforge-runtime re-exports pmcp types in its public API — create_transport() -> Result<Box<dyn Transport>> is pmcp::shared::Transport — so moving pmcp 1.8 → 2.18 changes that signature for consumers. That is why this is 0.2.0 and not 0.1.5.

pmcp 1.8 → 2.18

Published pforge-runtime 0.1.4 declared pmcp: ^1.8 non-optionally, so every consumer was held ten releases back with no way to opt out — and anyone wanting pmcp 2.x elsewhere in their tree compiled two incompatible copies of it. Consumers also missed pmcp #316, where a stdio server dropped responses to requests it had already accepted once the client closed stdin (the ordinary batch/one-shot shape).

No source changes were needed across pforge's 18 pmcp call sites.

trueno-db → aprender-db

trueno-db was consolidated into the aprender monorepo (APR-MONO, 2026-06-12) and is no longer published standalone — the crates.io copy is 0.4.0, last touched 2026-04-07, against aprender-db 0.63.0.

Worth knowing if you're doing the same migration: the package renamed, the crate did not. aprender-db declares [lib] name = "trueno_db", so use trueno_db::… stays correct — changing it to aprender_db gives E0433: unresolved module or unlinked crate even though cargo tree shows the dependency present.

Fixed: pforge serve corrupted its own protocol stream

On a stdio transport stdout is the MCP channel. serve opened by writing five println! lines into it ahead of the first JSON-RPC frame:

Starting pforge server...
  Config: …
  Server: … v…
  Transport: Stdio
  Tools: N

A tolerant client skips them; a strict one fails to parse and reports the server as broken. pforge dev had the same defect and delegates to serve, so its output landed there too. Both now write progress to stderr, which is what McpServer::run already did.

Added: tests that prove pforge is an MCP server

The suite had 228 tests and not one had exchanged a JSON-RPC frame with a running server — every one stopped a layer below the protocol. e2e_test.rs::test_stdio_transport_config is the clearest case: its name says end-to-end, its body deserializes YAML and asserts an enum value.

mcp_protocol_test.rs spawns the real binary, speaks MCP over stdin/stdout, and asserts on the bytes returned. It found the stdout bug above on its first honest run.

Security

rustls-webpki 0.103.10 → 0.103.14 (RUSTSEC-2026-0098, -0099: name-constraint bypasses for URI and wildcard names) and crossbeam-epoch 0.9.18 → 0.9.20 (RUSTSEC-2026-0204). Both transitive, so a library consumer resolving their own tree was already getting patched versions; this binds the lockfile for cargo install --locked pforge.

Also

Every other dependency updated — 214 packages moved, including thiserror 1→2, rand 0.8→0.10, reqwest 0.12→0.13, notify 6→8, criterion 0.5→0.8. Coverage no longer runs cargo llvm-cov nextest (profraw explosion); PROPTEST_CASES/QUICKCHECK_TESTS are pinned so a green property run means the same amount of searching everywhere.

Verified: 230 tests pass, clippy --all-targets -D warnings clean, cargo fmt --check clean, cargo deny check advisories licenses sources → advisories ok, licenses ok, sources ok.

Assets 2
Loading