Annotate TUI prompt with factual risk signals (not a conflated score)

[cuihtlauac]

Problem

The TUI prompt (src/tui.rs:76-117) shows the command, resolved path, reason, session, host, and time — but every command looks visually identical. A pipeline that touches /etc or makes a network connection should stand out at a glance from a cat /var/log/syslog. Today nothing in the prompt distinguishes "obviously fine" from "worth pausing on."

The naive fix is a single "risk: low/medium/high" badge. That's worse than nothing: heuristics that summarise to a single colour erode trust the first time they get it wrong ("why is apt install vim flagged red?"), and the operator learns to ignore the badge.

Proposal

Show specific, falsifiable signals as one-line annotations between the command and the Y/N prompt — never a single conflated score. Each signal is true or false, derivable from static inspection of the request:

• escalates: sudo — privilege escalation is in play (privileged: true).
• writes-to: /etc, /usr — argv contains paths or flags that imply writes to system dirs (apt install, install, cp, tee, redirected writes inside a stage).
• binary-not-in: /usr/bin, /usr/sbin, /bin, /sbin — resolved argv[0] is outside well-known dirs (already partly available via the existing Resolves: line at src/tui.rs:104-115).
• pipeline: N stages — only shown for N > 1; a multi-stage pipeline is structurally different from a single command.
• unknown-binary — which returned None; today this prints (not found in PATH) near the resolved-path line, lift it into the signals block.

The signals are descriptive, not prescriptive. The operator decides what they mean.

Things to consider:

• Exit early if zero signals fire — don't add visual noise to ls /tmp.
• Resist the urge to involve an LLM or learned model. The whole point is that signals are auditable and predictable.
• Per-stage vs per-pipeline: signals like writes-to: should aggregate across all stages of req.pipeline (src/protocol.rs:16).
• Colour: use the existing TUI styling sparingly — bold yellow for the signals block header, no per-signal colouring.
• This becomes much more useful once Append-only audit log of approved requests and outcomes #6 (audit log) lands, because operators can grep historical approvals for "every request that fired escalates: sudo and writes-to: /etc."