pyro-mcp/docs/roadmap/llm-chat-ergonomics/3.10.0-use-case-smoke-trust-and-recipe-fidelity.md
Thales Maciel 79a7d71d3b Align use-case smokes with canonical workspace recipes
The 3.10.0 milestone was about making the advertised smoke pack trustworthy enough to act like a real release gate. The main drift was in the repro-plus-fix scenario: the recipe docs were SDK-first, but the smoke still shelled out to CLI patch apply and asserted a human summary string.\n\nSwitch the smoke runner to use the structured SDK patch flow directly, remove the harness-only CLI dependency, and tighten the fake smoke tests so they prove the same structured path the docs recommend. This keeps smoke failures tied to real user-facing regressions instead of human-output formatting drift.\n\nPromote make smoke-use-cases as the trustworthy guest-backed verification path in the top-level docs, bump the release surface to 3.10.0, and mark the roadmap milestone done.\n\nValidation:\n- uv lock\n- UV_CACHE_DIR=.uv-cache uv run pytest --no-cov tests/test_workspace_use_case_smokes.py\n- UV_CACHE_DIR=.uv-cache make check\n- UV_CACHE_DIR=.uv-cache make dist-check\n- USE_CASE_ENVIRONMENT=debian:12 UV_CACHE_DIR=.uv-cache make smoke-use-cases
2026-03-13 13:30:52 -03:00

2 KiB

3.10.0 Use-Case Smoke Trust And Recipe Fidelity

Status: Done

Goal

Make the documented use-case pack trustworthy enough to act like a real release gate for the advertised chat-first workflows.

Public API Changes

No new core API is required in this milestone.

The user-visible change is reliability and alignment:

  • make smoke-use-cases should pass cleanly on a supported host
  • each smoke scenario should verify the same user-facing path the recipe docs actually recommend
  • smoke assertions should prefer structured CLI, SDK, or MCP results over brittle checks against human-mode text formatting when both exist

Implementation Boundaries

  • fix the current repro-plus-fix drift as part of this milestone
  • keep the focus on user-facing flow fidelity, not on broad internal test harness refactors
  • prefer exact recipe fidelity over inventing more synthetic smoke-only steps
  • if the docs say one workflow is canonical, the smoke should exercise that same workflow directly

Non-Goals

  • no new workspace capability just to make the smoke harness easier to write
  • no conversion of the product into a CI/reporting framework
  • no requirement that every README transcript becomes a literal byte-for-byte golden test

Acceptance Scenarios

  • make smoke-use-cases passes end to end on a supported host
  • the repro-plus-fix smoke proves the documented patch path without relying on fragile human-output assumptions
  • each use-case recipe still maps to one real guest-backed smoke target
  • a maintainer can trust a red smoke result as a real user-facing regression, not just harness drift

Required Repo Updates

  • use-case smoke scenarios audited and corrected to follow the canonical docs
  • any brittle human-output assertions replaced with structured checks where possible
  • docs updated if a recipe or expected output changed during the alignment pass
  • at least one release/readiness note should point to the smoke pack as a trustworthy verification path once this lands