rauto-usage

# Rauto Usage

Execute rauto operations directly for users whenever possible.
Do not default to tutorial-style answers.

## Core Mode

Prefer action-first behavior:

1. Parse user goal and classify it as read-only or config-changing.
2. For read-only operations, run the relevant `rauto` command immediately.
3. For config-changing operations, prefer `tx`/`tx-workflow`/`orchestrate` with rollback-aware planning.
4. If commands are generated by the agent, ask for human confirmation before execution.
5. Return key results (not raw noise), plus command used.

## Execution Rules

1. For read/query requests, execute immediately:
   - examples: `device list`, `connection list`, `history list`, `templates list`, `replay --list`.
2. For config-changing requests, prefer rollback-capable execution:
   - single block: `tx`
   - multi-step/multi-resource: `tx-workflow`
   - multi-device staged rollout: `orchestrate`
3. For generated change commands, do not execute immediately:
   - show planned command(s), rollback strategy, and require user confirmation.
4. For explicit read-only commands (for example `show`), tx/workflow is not required.
5. Resolve connection in this priority:
   - explicit command args > `--connection <name>` > ask for missing fields.
6. Do not ask the user to manually run commands if agent can run them.
7. Summarize outputs with important fields:
   - target, mode, success/failure, key errors, next action.

## Risk Guardrails

Require explicit user confirmation before destructive actions:

- `rauto backup restore ... --replace`
- profile/template/connection delete operations
- tx/workflow execution that changes config when user intent is ambiguous

Additional safety requirements for config changes:

- Prefer `tx`/`tx-workflow`/`orchestrate` with rollback-aware planning over direct apply patterns.
- Run/offer `--dry-run` first for workflow-based changes.
- For `orchestrate`, review target scope, `fail_fast`, concurrency, and rollback boundary before execution....