80 lines
4.3 KiB
Markdown
80 lines
4.3 KiB
Markdown
# Audita CLI Reference
|
|
|
|
The shared version-2 configuration parser and offline profile inspection serve
|
|
`process`, `config validate`, and `config print-effective`.
|
|
The [configuration reference](config.md) owns fields, defaults, and validation;
|
|
the [migration guide](migrations/v2.md) maps retired inputs.
|
|
|
|
## Commands and help
|
|
|
|
```sh
|
|
audita process <transcript.json> --glossary <glossary.yml> [flags]
|
|
audita config validate --config <config.yml> [flags]
|
|
audita config print-effective [flags]
|
|
```
|
|
|
|
Root invocation, `--help`, `-h`, and command help succeed without loading a config
|
|
file or resolving secrets. Unknown commands and flags return exit code `2`.
|
|
`process` accepts exactly one transcript path, either before the flags or after
|
|
them. With flags first, put the transcript last. Both config commands reject
|
|
positional arguments and process-only flags.
|
|
|
|
All three commands accept `--config <path>` and `--overlay <name>`. `config validate`
|
|
requires an explicit nonempty `--config`; the other commands select the explicit
|
|
file, then `/usr/local/etc/audita/config.yml`, then `/etc/audita/config.yml`.
|
|
Missing system candidates are skipped; inaccessible selected files are errors.
|
|
No file means a configuration error. `AUDITA_CONFIG` is ignored. The selected
|
|
overlay is loaded beside the main file, not used to locate profile files.
|
|
|
|
## Setting overrides
|
|
|
|
Only flags actually supplied override file or overlay settings. `--modules ''`
|
|
clears the module pipeline, and an explicit numeric zero reaches configuration
|
|
validation. The shared setting flags are:
|
|
|
|
| Setting | Flags |
|
|
| --- | --- |
|
|
| Profile selection | `--proposal-profile`, `--validation-profile` |
|
|
| Pipeline and output | `--modules`, `--output-schema` |
|
|
| Validation budget | `--validation-max-prompt-tokens` |
|
|
| Chunking | `--target-sections`, `--max-section-tokens`, `--min-section-tokens` |
|
|
| Normalization (numeric seconds) | `--normalize-max-segment-gap`, `--normalize-ellipsis-gap`, `--normalize-max-segment-duration`, `--normalize-max-segment-tokens` |
|
|
| Confidence thresholds | `--glossary-confidence-threshold`, `--homophones-confidence-threshold`, `--spoken-word-confidence-threshold`, `--grammar-confidence-threshold` |
|
|
| Context | `--transcript-description` |
|
|
| Diagnostics | `--work-dir`, `--work-dir-retention` |
|
|
|
|
`process` alone accepts `--glossary` (required), `--output`, and `--report-json`.
|
|
Per-role model, base URL, key, timeout, retry, and concurrency flags have been
|
|
removed. Models and generation controls belong to PromptKit profiles, backend
|
|
credentials and capacity to configuration, and retry/deadline settings to the
|
|
shared LLM section. Legacy configuration environment overrides are ignored.
|
|
|
|
## Streams and exit status
|
|
|
|
`config validate` loads settings and both selected PromptKit profiles offline,
|
|
then prints `config is valid` on success. `config print-effective` accepts
|
|
`--view settings|profiles|explain` and defaults to `settings`. Settings writes
|
|
ConfigKit's redacted effective-settings YAML. Profiles writes an Audita-owned
|
|
YAML summary of selected ID, backend, model, sampling controls, per-attempt
|
|
timeout, service tier, and reasoning effort for each role. It omits credentials,
|
|
endpoints, and arbitrary extra provider parameters. Explain writes a YAML
|
|
sequence of field paths, source origins, and recorded derivations without
|
|
resolved setting values. These views share the same settings and profile
|
|
validation path as `process`. Unknown views are usage errors. The effective
|
|
settings YAML is for inspection and is not guaranteed reloadable.
|
|
|
|
For `process`, `--output` writes the corrected transcript to a file and leaves
|
|
stdout empty on success. Without it, stdout carries transcript JSON only on
|
|
success. `--report-json` writes a separate report file. Stderr carries readable
|
|
errors and diagnostic locations. A successful run can contain skipped corrections
|
|
or warnings; see the [report contract](integrations/output-files.md).
|
|
|
|
Exit codes are `0` for success, `1` for runtime or output failure, and `2` for
|
|
usage or configuration input errors. Invalid settings and profiles return `2`;
|
|
broken embedded assets and serialization or write failures return `1`.
|
|
Configuration commands inspect profiles without contacting a provider.
|
|
|
|
See the [input files](integrations/transcript-glossary-files.md),
|
|
[subprocess contract](integrations/subprocess.md), and
|
|
[artifact lifecycle](operations.md) for their respective details.
|