# Rho TODO

This file tracks the near-term engineering plan for the Rust `rho-cli` crate.
The release pipeline is live; the active product work is consolidating the CLI
into one real `rho` executable.

## Current State

- [x] The crate publishes to crates.io as `rho-cli`.
- [x] The primary installed executable is named `rho`.
- [x] `v0.1.2` was released by GitHub Actions.
- [x] GitHub Release artifacts are built for Linux, macOS Intel, macOS Apple
  Silicon, and Windows.
- [x] PR CI runs formatting, clippy, tests, e2e smoke tests, and package dry-run.
- [ ] The crate still defines and packages multiple `rho-*` binaries.
- [ ] `src/bin/rho.rs` still dispatches by launching sibling executables.

## 1. Release Pipeline

Status: shipped. Keep this section as the acceptance record and a place for
release hardening tasks.

### Completed

- [x] Run formatting, clippy, tests, and builds for every PR to `main`.
- [x] Support GitHub merge queue checks with `merge_group`.
- [x] Run Rust checks on Linux, macOS, and Windows.
- [x] Run the non-live e2e suite with `./test.sh` on Linux.
- [x] Run `cargo publish --dry-run --locked` in CI.
- [x] On merge to `main`, run quality gates before publishing.
- [x] Bump the Cargo package version automatically, patch by default.
- [x] Allow manual release dispatch with `patch`, `minor`, `major`, or an exact
  `force_version`.
- [x] Commit only `Cargo.toml` and `Cargo.lock` for version bumps.
- [x] Publish using the repo secret `CARGO_REGISTRY_TOKEN`.
- [x] Create a GitHub tag and release only after crates.io publishing succeeds.
- [x] Package the current binaries in per-platform archives:
  - `rho`
  - `rho-crypto`
  - `rho-dataset`
  - `rho-id`
  - `rho-message`
  - `rho-publish`
  - `rho-repo`
  - `rho-request`
  - `rho-result`
  - `rho-run`
  - `rho-tools`

### Release Follow-Up

- [ ] Add branch protection so PR CI and merge queue checks are required before
  merge.
- [ ] Update GitHub Actions dependencies before the Node 20 runner deprecation
  becomes a release blocker.
- [ ] Add a root `README.md` with install and usage examples for the crates.io
  page.
- [ ] Decide whether to add Linux ARM and musl targets using `cross`.
- [ ] After the single-binary migration, update release archives to contain only
  `rho`.

## 2. Single `rho` Binary

Status: active next milestone.

The repo currently has a `rho` dispatcher plus multiple `rho-*` binaries. That
was useful for the first Rust slice, but the target architecture should be one
installed executable with subcommands:

- `rho dataset`
- `rho publish`
- `rho message`
- `rho request`
- `rho run`
- `rho result`
- `rho id`
- `rho crypto`
- `rho repo`
- `rho tools`

A single binary is better for installation, updates, autocompletion, JSON-mode,
doctor checks, plugin ordering, and Windows support.

### Goals

- [ ] Publish one installed executable from `rho-cli`: `rho`.
- [ ] Replace shell-style dispatch with direct Rust subcommand dispatch.
- [ ] Keep behavior stable while changing invocation from `rho-*` to
  `rho <subcommand>`.
- [ ] Avoid duplicate command implementations.
- [ ] Keep process exit codes and stderr/stdout behavior compatible.

### Non-Goals

- Do not redesign command semantics during the consolidation.
- Do not add a CLI framework unless it clearly reduces migration risk.
- Do not keep long-term duplicate implementations for legacy binaries.
- Do not block the consolidation on live Pi/provider tests.

### Current Command Map

| Current binary or dispatcher path | Target command |
| --- | --- |
| `rho-dataset` | `rho dataset` |
| `rho-publish` | `rho publish` |
| `rho-message` | `rho message` |
| `rho-request` | `rho request` |
| `rho-tools` | `rho tools` |
| `rho-run` | `rho run` |
| `rho-result` | `rho result` |
| `rho-id` | `rho id` |
| `rho-crypto` | `rho crypto` |
| `rho-repo` | `rho repo` |
| `rho approve` dispatcher alias | keep as `rho approve`, backed by request logic |
| `rho status` dispatcher alias | keep as `rho status`, backed by repo logic |
| `rho add user` dispatcher alias | keep as `rho add user`, backed by repo logic |
| `rho gh` | already implemented in `rho` |
| `rho commit` | already implemented in `rho` |
| `rho env` | already implemented in `rho` |
| `rho install-shell` | already implemented in `rho` |
| `rho version` / `rho --version` | already implemented in `rho` |

### Migration Plan

- [ ] Create internal command modules under `src/commands/`.
- [ ] Move each `src/bin/rho_*.rs` implementation into a callable module:
  - `dataset`
  - `publish`
  - `message`
  - `request`
  - `tools`
  - `run`
  - `result`
  - `id`
  - `crypto`
  - `repo`
- [ ] Convert each old `main()` into a `run(args: &[String]) -> i32` or
  equivalent API.
- [ ] Update `src/bin/rho.rs` to dispatch directly to those modules.
- [ ] Preserve help text, error messages, JSON output, file paths, environment
  variables, and exit statuses.
- [ ] Update tests and scripts from `cargo run --bin rho-* -- ...` to
  `cargo run --bin rho -- <subcommand> ...`.
- [ ] Update docs that mention the old binaries.
- [ ] Remove the extra `[[bin]]` entries from `Cargo.toml`.
- [ ] Update `.github/workflows/release.yml` so release builds and archives only
  package `rho`.
- [ ] Update `install.sh` so it installs only `rho`.

### Compatibility Decision

Preferred path: make the next minor release the clean single-binary release and
document the new subcommand invocations.

Optional fallback: keep tiny compatibility shims for one release if real users
already depend on `rho-*`. If shims are kept, they must call the same internal
modules as `rho` and must not duplicate command logic.

### Verification

- [ ] `cargo fmt --all -- --check`
- [ ] `cargo clippy --all-targets --all-features --locked -- -D warnings`
- [ ] `cargo test --all-targets --all-features --locked`
- [ ] `./test.sh`
- [ ] `cargo publish --dry-run --locked`
- [ ] Confirm `cargo metadata --no-deps --format-version 1` lists only one bin
  target: `rho`.
- [ ] Confirm release artifacts contain `rho` only.

## 3. Docs And Examples

- [ ] Add `README.md` with:
  - `cargo install rho-cli --bin rho`
  - basic `rho id`, `rho repo`, `rho crypto`, and controlled-run examples
  - release archive install instructions
- [ ] Refresh architecture docs that still describe `rho-*` as separate
  installed commands.
- [ ] Keep live/provider tutorials separate from smoke-test documentation.
- [ ] Document the relationship between `rho-cli` and the `repos/vouch`
  submodule once the integration direction is clear.

## 4. Later Distribution Targets

- [ ] Decide whether Homebrew packaging is needed after the single-binary
  release.
- [ ] Decide whether shell completions should be generated by `rho`.
- [ ] Decide whether `rho doctor` should become a top-level command that checks
  install, repo, identity, crypto, and release readiness.
