[P1] CI: install the way users install, with fresh resolution #46

Links

• Epic: Tracking: gaps surfaced by an agent-driven document workflow (from #40) #44
• Origin: [Bug] mcp-pandoc 0.8.1 crashes on startup with mcp SDK 2.0.0 (AttributeError: 'Server' object has no attribute 'list_tools') #40
• Evidence: docs/audits/2026-08-agent-workflow-audit.md → Finding 8
• Code: .github/workflows/ci.yml

Problem

CI installs with uv sync, which installs the pinned contents of uv.lock. Users install with uvx, which resolves fresh to the newest version each constraint allows. Only one of those is tested.

CI                                  A real user
uv sync  → installs uv.lock         uvx  → fresh resolve, newest allowed
  └─ stayed on mcp 1.x                └─ resolved to mcp 2.0.0 → crash on import

Causality, stated precisely. The root cause of #40 was the uncapped mcp dependency. Lockfile-based CI was a detection gap, not the cause. Capping the dependency fixed the bug; this issue closes the detection gap.

Timeline

The break window was roughly three days. An earlier version of this issue claimed eleven months; that was wrong and conflated the outage with a quiet period in the repo.

An honest limit on the scheduled-job argument

Users reported this within one day. A weekly scheduled check averages 3.5 days and would have been slower than the community. So the case for scheduled fresh-resolution testing is not "it would have caught #40 sooner". It is that it gives detection we control, for breaks subtler than a startup crash that users may never report at all.

Acceptance criteria

• A CI job installs the built artifact with fresh dependency resolution, not from uv.lock
• That job completes a real stdio MCP handshake, not a mocked session
• It runs on PRs at minimum
• A scheduled variant is added only if the PR-triggered job proves insufficient
• Any scheduled failure is visible: notification, or an auto-filed issue

Out of scope

The exact uv invocation and the schedule cadence.