44 lines
1.8 KiB
Markdown
44 lines
1.8 KiB
Markdown
# 070 — CLI functionality needs to be greater — scope this out
|
|
|
|
## Summary
|
|
|
|
Wishlist feedback: "CLI functionality needs to be greater - todo
|
|
fleshout." This is a scoping ticket, not an implementation one — the
|
|
request as given doesn't say which CLI surface is thin (flags to
|
|
`ottyl` itself vs. profile/dashboard management vs. something
|
|
scriptable/headless) or what "greater" should mean in practice.
|
|
|
|
Current CLI surface, for reference: `main.rs`'s arg parsing wires
|
|
stdin/`--file` tailing, `--metrics-url` polling, and profile
|
|
selection/loading (see `settings.rs`/`profile.rs`) into engine startup.
|
|
Anything beyond piping a command and viewing the dashboard in a browser
|
|
(inspecting state, managing profiles, exporting data, scripting against
|
|
a running instance) has no CLI path today — it's all through the web
|
|
UI's API calls.
|
|
|
|
## Scope
|
|
|
|
- Talk to Hugh about what's actually missing before writing an
|
|
implementation ticket. Candidate directions worth raising:
|
|
- A way to inspect current state (params/metrics/alert rules, log
|
|
counts) from the terminal without opening the browser.
|
|
- Profile management from the CLI (list/create/switch profiles)
|
|
rather than only through the web UI's settings.
|
|
- A non-interactive/headless mode for CI-type use (e.g. run for N
|
|
seconds against piped input, dump a summary, exit) — distinct from
|
|
today's "serve until the piped process exits" model.
|
|
- Flags to declare params/metrics/dashboards at launch without
|
|
hand-editing the profile file first.
|
|
- Once scoped, split into one or more concrete tickets with specific
|
|
acceptance criteria — this ticket should be closed by replacement,
|
|
not by a partial implementation guessing at the ask.
|
|
|
|
## Acceptance criteria
|
|
|
|
- N/A — this ticket's output is a conversation and a follow-up
|
|
ticket (or tickets), not code.
|
|
|
|
## Depends on
|
|
|
|
None.
|