Next release track
This page exists so useful branch-only work does not sit in limbo.
Page role
Next-release lane. This page is for real source work that is intentionally
unreleased. The command-level source of truth lives in
xrtm/docs/next-release-feature-track.md,
and the labeling/graduation rules live in the governance repo's
Feature Status and Graduation Policy.
- Released docs stay pinned to what ships in
xrtm==0.3.1. - This page tracks near-term conveniences that are real and valuable, but not yet promoted into the public released path.
- The roadmap remains for longer-horizon, future, or experimental work.
For command-level details, see xrtm/docs/next-release-feature-track.md.
Current decisions
| Feature family | Canonical status | Target train | Why it is not on the released surface yet | What happens next |
|---|---|---|---|---|
Guided onboarding helpers (xrtm start, starter profile scaffolding) | shipped | 0.3.1 | They are now part of the released guided first-success path. | Keep clean-install proof and the matching onboarding docs update in lockstep. |
Latest-run shortcuts (latest, --latest) | shipped | 0.3.1 | They are now part of the published operator ergonomics surface. | Keep released-artifact smoke covering the shortcuts. |
| CSV export on the top-level product surface | shipped | 0.3.1 | It is now part of the released export surface, with JSON still documented as the full-fidelity bundle. | Keep JSON/CSV documentation aligned with release packaging. |
Corpus validation workflows (validate run, list-corpora) | advanced/experimental | After corpus policy and released-stack validation mature further | These flows are real, but they depend on corpus tiers, release-gate policies, and more operator/research context than the default shipped path. | Keep them in advanced or release-engineering guidance until the corpus and compatibility story is steadier. |
Corpus preparation UX (validate prepare-corpus) | redesign-required | Not on the current release train | The current command mixes cache setup, corpus policy, and preview semantics in a way that is still too internal. | Redesign the user-facing workflow before treating it as a public release promise. |
User attribution flags (--user) | redesign-required | Not on the current release train | The implementation exists, but the public product still honestly describes team use as convention-based rather than built-in identity or multi-user workflow management. | Clarify semantics, storage, and privacy expectations first; then decide whether to release it as metadata, workflow labeling, or something else. |
How to read this page
next-releasedoes not mean “already released.” It means the feature is a good next-release candidate once validation and packaging gates pass.advanced/experimentalmeans useful work that should stay out of the default newcomer or released story for now.redesign-requiredmeans the value is real, but the current implementation should not be treated as the final public contract.
Governance rule
Unreleased-but-desired features should always have an explicit status. They should not live only in tests, draft docs, or branch folklore.
Promotion decisions here should mirror the governance policy and the owning repo's release evidence, not bypass them.
See also: