Hermes Wiki
opportunities/2026-08-19-incremental-RBC_Work

Incremental Opportunities: RBC_Work (2026-08-19)

Scope: Architecture/CaseStudies/slack-quarry-ssh-to-rest-emr-pipelines (new this window) against RBC_Work's own noted gap — "network-cli mcp (for network ssh commands on multiple device (no pre-check, post-check))" (Projects/RBC_Work.md line 38). Not covered by the 08-17/08-18 passes, which focused on rollback-path independence for item #12's self-healing agent rather than the network-cli MCP's own execution model.

Finding

RBC_Work already flags, in its own words, that the network-cli MCP runs SSH commands across multiple devices with "no pre-check, post-check" — i.e., no structured before/after validation around the command, and (implicitly) no server-side record of what ran independent of the SSH session itself. Slack's Quarry case study is a close structural match for exactly this gap, just at larger scale: Slack replaced SSH-driven job submission to EMR clusters with a REST layer where a job gets submitted, tracked by ID, and its lifecycle lives server-side — decoupled from whether the SSH-equivalent connection survives. The case study's own framing of what SSH access actually was ("a broad, hard-to-audit attack surface for infrastructure that didn't need interactive shell access, only 'run this job and tell me how it went'") describes the network-cli MCP's likely actual need just as precisely as it describes Slack's EMR pipelines.

Two of Slack's specific fixes map onto the named gap directly:

  • Server-side job lifecycle (submit → job ID → poll/notify status) is the direct answer to "no pre-check, post-check" — a pre-check and post-check are exactly the kind of structured, queryable lifecycle stages Quarry's REST layer made possible that a bare SSH session doesn't give you for free.
  • REST API logging as the audit trail replaces "whatever fragments of an audit trail SSH sessions happened to leave behind" — relevant for a network-cli MCP touching production devices across an unspecified but presumably multi-region/multi-device footprint, similar in shape to Slack's eight-region EMR estate.

Suggested next step

Next time the network-cli MCP's design comes up, use Quarry as the concrete reference architecture rather than incrementally patching pre-check/post-check onto the existing SSH-command flow: a thin API in front of device SSH access that (1) accepts a command/intent, (2) runs an explicit pre-check before execution, (3) executes and tracks the action server-side with an ID, (4) runs an explicit post-check, and (5) logs the whole sequence centrally — independent of whether the MCP client's own connection survives the round trip. Slack's phased, dashboard-tracked migration (700+ operators, three quarters, no downtime) is also the reference for how to roll this out incrementally if the MCP already has active callers, rather than a flag-day cutover.

Hermes Wiki