In theory, "arc" is user-facing only and not an API.

In practice, this is often untrue, and arc unit --target ..., arc call-conduit, arc --conduit-token ... are all "blessed" use cases which pretty clearly make arc an API.

One issue with this is that we have a lot of advisory/guardrail prompts which API callers would probably like to always ignore. Some commands have a --force, but this generally does not skip every prompt, and callers don't necessarily want it to skip every prompt.

I'd like to standardize how workflows prompt users, and realistically consider API callers in the design. Some possibilities include:

--no-guardrails: Separate prompts into "guardrail" prompts and "actually important" prompts, and let callers disable the advisory ones. Possibly, disable the advisory ones automatically if stdout is not a TTY. I don't like this because the bucketing is pretty arbitrary, there are almost certainly prompts which don't fit cleanly into either bucket, and I doubt it really gives us much traction against this.

Just make --force skip every prompt: give users enough rope to shoot themselves in the foot. But some prompts have super awful consequences and I don't actually trust users to use this kind of power responsibly, e.g. see the giant red skull on bin/remove destroy.

Plumbing/porcelain: Say that the "API" is either separate plumbing commands (arc repository-amend) or that you have to write a workflow and call the API yourself. Separating commands likely means some checks are slow/late (if they occur in the wrapped plumbing workflow) or some checks are duplicated (if they occur in both so that the command can fail quickly). I'd also like to make "write a workflow" easier, but: don't believe most users will do it; and don't necessarily want the entire internal API to realllly be API surface area -- we should still be able to stick a giant "caution, advanced" sticker on extension development.

Enumerate every prompt: I haven't really talked myself into this yet, but we could enumerate every prompt and let callers pre-respond. An arc prompts <workflow> could list all possible prompts. Configuration could let interactive users pre-respond, too. Advantages to this include that it's explicit, works for interactive use cases, and would let us get rid of a lot of --ignore-x, --allow-y type flags.