exec: optional passthrough to centrs for richer validation

[mobileskyfi]

The decision

Whether quickchr should grow an optional, opt-in path that routes an exec
(and possibly other command-shaped calls) through tikoci/centrs'
validate → explain → run so callers get richer validation, warnings, and tips —
or defer that surface wholly to centrs and keep quickchr QEMU/lifecycle-focused.

This issue exists to track the concept formally (so it is no longer a note in a
backlog) and to be the anchor for the cluster of items that drove centrs' design.
It does not design --via-centrs — the name and shape are out of scope until decided.

Options

• A — Optional passthrough (--via-centrs, better name TBD). quickchr stays the
  VM-lifecycle owner; when the flag/option is set, the command is handed to centrs for
  validation before running over the existing transport. Off by default; no new hard
  dependency on the common path.
• B — Defer entirely to centrs. quickchr exposes only the raw transport
  (exec.ts/REST); centrs consumes quickchr and adds validation on its side.
• C — Thin validator seam. quickchr exposes a hook/interface that centrs (or any
  validator) plugs into, without quickchr depending on centrs.

Recommended default

B, leaning C. The validation-heavy items below are more involved than
QEMU-focused quickchr — that is why they drove centrs' design. Keeping them in centrs
avoids duplicating a validator here. Revisit A only if a first-party consumer needs the
richer surface through quickchr's CLI rather than centrs' own.

What it changes

Public CLI/library API surface (a new opt-in flag/option on exec, or a validator
seam). No persisted-state or port change. Option A needs a soft/optional-dependency
story so the common path doesn't pull in centrs.

Done-when

The direction is recorded here, and either a follow-up Task issue is filed to implement
the chosen shape or this is closed as "defer to centrs."

---

Centrs-owned cluster (tracked here, not as separate quickchr issues)

These are "in a sense done — they live in centrs." Revisit in quickchr only if the
passthrough (option A) happens. Full prior notes: git log -p -- BACKLOG.md.

• exec() soft-error detection — HTTP-200-with-error corpus → opt-in
  throwOnCliError / isRouterOSError(). Previously flagged "may be subsumed by a
  centrs validation path."
• Protocol-adapter reuse spike — compare centrs' REST/native-api seam with
  rest.ts / exec.ts before quickchr adds SSH/native-api paths (coordinate with the
  SSH-transport issue).
• MAC-Telnet bidirectional — socket-connect proven for MNDP
  (test/lab/mndp/REPORT.md); the same request/reply technique for MAC-Telnet is
  centrs' domain.

The REST-timeout contract reconciliation (60s ceiling inherited from centrs) is a
grounding task, tracked in the REST lab-grounding umbrella — the durable rule lives
in routeros-rest.instructions.md "REST Timeout Ceiling".

[mobileskyfi]

Let also think about this in context of tikoci/centrs#134 which is where centrs can reference a quickchr machine. Like to flush out the options a bit more after some research. The "A" option I agree is not best. It the B or C that I'm still not sure on.

To clarify a few points:

• centrs is optional and used only if installed; i'm not fan of either depending on the other. e.g. if installed, potential use
• QGA is the only richer interface in quickchr, so how that's handle be another decision point. e.g. --via qgq force internal local without validation, and/or require some explict --skip-validation-with-centrs (not real flag name, conceptual).
• perhaps some --validate=true that trigger "centrs" (if present) is a better way to think about it, and if no validator was present...warn/remediation shown to install bun -g @tikoci/centrs. but not sure i'd a too tight a coupling is my only concern on that kinda of approach
• ideally an out-of-date centrs be identified, on either side (but like centrs)

[mobileskyfi]

Decision from the cross-project review with tikoci/centrs#134:

• Do not add a centrs passthrough mode to quickchr exec. quickchr exec stays a raw/simple execution channel.
• centrs owns validated RouterOS operations (validate -> explain -> run, envelopes, fan-out, protocol selection).
• quickchr owns CHR/QEMU lifecycle, provisioning, and QEMU-local channels.
• The integration path is centrs resolving a quickchr machine via --quickchr <name> through quickchr's public API/descriptor, not by reading machine.json.
• quickchr should improve the handoff and discovery surfaces around that boundary, outside of exec.

Follow-up quickchr issues:

• QGA: define quickchr-scoped centrs handoff #70 — QGA: define quickchr-scoped centrs handoff
• API: live descriptor contract for centrs --quickchr targets #71 — API: live descriptor contract for centrs --quickchr targets
• CLI/docs: steer quickchr users to centrs for validated RouterOS operations #72 — CLI/docs: steer quickchr users to centrs for validated RouterOS operations
• examples: show centrs consuming a quickchr machine #73 — examples: show centrs consuming a quickchr machine

Closing this umbrella as decided: defer validation/rich execution to centrs, and keep quickchr dependency-free on the common path.