Skip to content

0.0.6 development plan

0.0.6 is a focused CLI foundations + streaming automation release. It starts from the published 0.0.5 baseline and keeps work concentrated in rs-rich-cli. The release intentionally treats subcommands, streaming orchestration, and machine-report contracts as rs-rich-cli binary-boundary work: renderers stay in rich-ext where possible, and crates/rich core behavior is unchanged.

Scope

Priority Issues Deliverable
1 #152 / #137 Add a scalable subcommand architecture while keeping all existing flat flags working without deprecation warnings.
2 #158 / #143 Define stable exit-code classes and a common JSON result/error envelope for automation.
3 #153 / #138 Add bounded-memory JSONL / NDJSON and structured-log streaming from files and stdin.
4 #64, #34, #35, #15 Update issue status for work already shipped in 0.0.5, leaving broader follow-up scope open where needed.
5 Diagnostic follow-up Harden release readiness for this release by requiring a final PR snapshot, zero unresolved review threads, a current release handoff, and Windows-safe serialized validation.

Confirmed behavior

  • Existing invocations such as rich --json file.json and rich -m README.md remain supported and do not print deprecation warnings.
  • Preferred subcommands are added as aliases over the same renderers: rich json, rich markdown, rich syntax, rich csv, rich ipynb, rich jsonl, rich log, rich gif, rich diff, rich rule.
  • --report json writes a small stable envelope to stderr, preserving stdout for rendered content; --machine-json is a compatibility alias for the same machine-readable report mode.
  • Successful JSON reports include ok, code, exit_code and a result object; error reports include the same status fields plus message and an error object. Informational exits such as --help and --version keep printing their normal text without a report envelope.
  • Exit codes are split by class: success, usage/config, input/read/write, parse/render data, and threshold/gate failure.
  • JSONL/log streaming fails fast on the first malformed record by default.
  • The diagnostic release-hardening work intentionally lives in separate layers: .github/release-readiness.json owns the shared handoff trigger and snapshot field policy, including the short wait window that lets a just-posted current-SHA handoff comment become visible before CI fails; docs/BRANCHING.md explains the policy, PR hygiene owns CI enforcement, .claude/skills/release/SKILL.md owns the agent runbook, scripts/validate_release.py owns the full local release-prep command list in serialized order and requires the audited tag, and tests cover the policy schema plus workflow regressions. This keeps the release safety checks executable without moving CLI feature code outside rs-rich-cli.

Deferred

  • intuiTUIve / rs-rich-tui (#160–#173): separate design milestone.
  • rich-art image command expansion (#159 / #144): depends on renderer work tracked in #122–#129.
  • watch, pager, config profiles and batch conversion (#154–#157): build on the command/output contracts established here.
  • Dependency PRs #95–#97 and #52–#54: keep separate from feature release work.

Expected package selection

Expected release tag: rs-rich-cli-v0.0.6.

Do not bump rs-rich, rs-rich-ext or rs-rich-art unless implementation requires a public API or dependency requirement change.