Rotini v1.3.0 has been released.

New

• Flags that skip the run. Mark a flag short_circuit: true and, when it’s set on the command line, the command’s required inputs and value rules are waived, so rtx.Inputs succeeds and the handler can act on the flag. --help is the obvious one: app deploy --help now prints help even when the service to deploy is missing. Input that can’t be read, such as an unknown flag or a value that isn’t a number, is still an error. rotini init now seeds --help and --version this way, answered once in the root handler’s CascadingPreRun, so new command stubs carry no help code at all. See flags that skip the run.
• Check inputs you collected yourself. rtx.CheckInputs(v, rotini.PresenceOf(v)) checks values from a prompt, a file or an API against the spec’s rules, and reports them the way the command line would. See checking inputs you collected yourself.
• rotini generate --dry-run. Works out everything generate would write or remove and changes nothing: exit 0 when the generated code matches the spec, 2 when it doesn’t, 1 on an error. Set generate.dry_run_env: CI in the conf and go generate ./... checks every CLI in the module on CI. rotini init --dry-run previews a new CLI the same way. See rotini generate.
• Help shows where a flag’s value can come from. A flag with an environment or config fallback gets a line under it:

  -r, --replicas int    how many instances (default 1)
                        also set by CFGCTL_DEPLOY_REPLICAS or config key deploy.replicas
  

  Man pages, markdown pages and the contract document show the same.
• Completion messages. With messages: on the completion feature, pressing TAB on a value with nothing to offer shows a line of guidance instead, from the spec (complete.message), from the input’s summary, or from a completer with rtx.AddCompletionMessage. Your users can hide them with the variable the conf names in messages_env. zsh and bash 4.4+ show them, and so do kubectl and Docker for a rotini plugin. See completion messages.
• exit_status is checked. Once a command declares exit_status:, rotini generate warns when its handler exits with a code the list leaves out, and rotini validate reports a code listed twice.
• Better error handling from handlers. A value from an environment variable or config file that breaks a rule now says where it came from, as in (from environment variable APP_PORT). Errors carry the facts a “did you mean” needs everywhere it makes sense, including env and config values and mistyped plugin commands, and rotini.SuggestionFacts(err) reads them for your own ranking. See handling errors in a handler.

Changed

• Removing a command no longer breaks go generate ./.... Its handler file is now retired in two runs: the first generate disables it with //go:build ignore, keeping your code, and the next one deletes it. Put the command back before then and the file is restored.
• Help, man and markdown pages change for every flag with an environment or config fallback. If you test your --help output against a saved copy, update it after regenerating.
• COMPATIBILITY.md and UPGRADING.md are gone. Rotini is still evolving, so a minor release can include breaking changes; every release lists them in its notes. How to upgrade is now in the guide, under upgrading.

Updated help shape and behavior

The new shape is opt-in: a project left as it is keeps its per-command help flags and the help check in each handler. To get what a fresh rotini init writes:

1. In the spec, mark the root’s --help flag cascading: true and short_circuit: true, and its --version flag short_circuit: true.
2. Add a CascadingPreRun to the root handler that answers both, and remove its rotini.NoCascadingPreRun line. rotini generate warns until the hook is there, and a fresh rotini init in a scratch directory shows the hook to copy.
3. Remove the per-command help flags the cascading one replaces, then run rotini validate.

The help check at the top of your existing handlers no longer runs once the root answers first. It does no harm, so delete it whenever you like.