Capture the next UX pass after the workspace-core readiness review so the roadmap reflects the remaining friction a new chat-host user still feels. Add milestones for trustworthy use-case smoke coverage, host-specific Claude/Codex/OpenCode MCP onramps, and the planned 4.0 default flip to workspace-core so the bare server entrypoint finally matches the recommended path. This is a docs-only roadmap update based on the live use-case review and integration validation, with the full advanced surface kept as an explicit opt-in rather than the default.
54 lines
2 KiB
Markdown
54 lines
2 KiB
Markdown
# `3.10.0` Use-Case Smoke Trust And Recipe Fidelity
|
|
|
|
Status: Planned
|
|
|
|
## 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
|