Skip to content

What RTB does not do

Checked against the workspace at 0.9.0. Each entry says what is not supported and what to do instead. Some are deliberate scope decisions, some are unfinished work that still presents a working-looking flag — both matter, because both cost you an afternoon if you assume otherwise.

Nested subcommands are not supported

validate_command_path accepts up to four /-separated segments, but both rtb generate command and rtb remove command reject any path containing /:

x nested command paths are not yet supported
  help: multi-segment paths land in a follow-up slice; supply a single-segment name

Instead: scaffold single-segment commands, and build a nested tree by hand inside a command that owns its own clap subtree.

Setting names cannot be snake_case

rtb generate setting describes its argument as a "snake_case Rust identifier" but validates it with the flag-name validator, which allows only ^[a-z][a-z0-9-]{0,63}$. So default_name is rejected, and default-name is accepted and renders pub default-name: String, — which does not compile.

Instead: use a single lowercase word (greeting, region, retries). Add a multi-word field to AppConfig by hand, between the settings markers so regeneration preserves it.

--default on a setting does not set a default

rtb generate setting --default hello renders a // default: hello comment above the field. At runtime the field still takes its type's Default — an empty String, false, 0.

Instead: add #[serde(default = "…")] yourself, or populate the value in the tool's embedded defaults.

AI codegen only works on the minimal preset

generate command --prompt and --script target the minimal preset's synchronous fn run body. On a cli-preset project they fail before writing anything:

x AI-assisted `generate command` is not yet supported on the `cli` preset

Instead: scaffold the command without --prompt / --script and write the body yourself.

--default-is-code is not implemented

rtb generate flag --default-is-code is on the CLI surface for forward-compatibility and errors if you set it. Pass --default with a string literal instead.

--page-by-page is not implemented

rtb generate docs --page-by-page parses and changes nothing. The AI prose pass rewrites every page in one batch, in place, with no diff and no confirmation. Run it on a clean working tree so git diff is your review step.

--update-docs does nothing

rtb regenerate project --update-docs is parsed and never read, so the generated docs are not re-rendered.

Instead: run rtb generate docs again after regenerating.

regenerate project --ask never asks

The default --overwrite ask policy is documented as prompting per file. The prompt is not implemented: ask overwrites stale-but-untouched files and silently skips edited ones. --non-interactive therefore also does nothing.

regenerate project never shows a diff

Under every policy, and under --dry-run, the command prints file names and counts — never file contents. --dry-run is worse than that: files it would overwrite are counted in no column at all, so a dry run of a change that would rewrite five files reports zeroes across the board.

Instead: commit before regenerating and read git diff afterwards.

regenerate project ignores commands you generated

Only files the preset itself renders are reconciled. src/commands/*.rs files written by generate command are recorded in the manifest but are not preset outputs, so they are never refreshed and never reported as drift. Stale manifest entries for files the preset no longer ships are also skipped rather than cleaned up — run rtb regenerate manifest for that.

--output json is ignored by most commands

The global flag is honoured by exactly three commands: credentials list, credentials test and credentials doctor. version and doctor advertise it in their own --help and always print text. An unrecognised value such as --output yaml is not rejected — it resolves silently to text.

Tool-scoped AI key variables are not read

The scaffolder's source describes a three-tier key lookup — <TOOL>_<PROVIDER>_API_KEY, then <PROVIDER>_API_KEY, then a well-known fallback. Only the well-known names are actually consulted: ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY / GOOGLE_API_KEY. See environment variables.

One provider per invocation

--provider and --model are per-command flags with no configured default. There is no way to use one provider for generate command --prompt and a different one for generate docs within a single run — each command resolves its own provider, from its own flags, against the same environment. Set the flags per invocation.

There is no rtb new

The scaffolding verb is rtb generate project. rtb new has never existed as a command; older prose that mentions it is wrong.

rtb --version is not a flag

Use rtb version. The root parser reads the first token as a subcommand name, so rtb --version exits 1 with command not found: --version. Tools scaffolded from the minimal preset are the other way round: they have a root --version flag and no version subcommand.

Generated docs land in docs/components/

rtb generate docs writes into docs/components/ in the target project, hardcoded, with no flag to change it. That path is not where a Diátaxis layout wants command reference to live — this project keeps its own CLI reference under reference/cli/. Move or redirect the output yourself if your docs site follows the four quadrants.

The framework's own scope boundaries

These are settled decisions rather than unfinished work:

  • Not a web framework. RTB does not compete with axum or actix. A general serve subcommand is deferred; today the only server surface is the loopback docs serve.
  • Not a TUI library. It uses ratatui and inquire rather than replacing them.
  • Not an async runtime. It picks tokio.
  • Not a DI container. App is a plain typed context passed by cheap clone — no service locator, no injection macro, no global registry.
  • No string-keyed config accessor. There is no get_string("a.b"); configuration is a typed struct and access is by field. This is explained in Configuration.

rtb-cli-bin's library is not a public API

The crate exposes a library so its modules are testable, but every item in it is internal to the scaffolder and may change without a major version bump. Depend on the CLI grammar, not on rtb_cli_bin::.

Reporting one of these

If an entry here is out of date because the gap has been closed, the page is the bug — raise it against rust-tool-base.