docs(screenconnect skill): clarify end goal — GuruRMM addon, BYO alternative to GuruConnect

Replace the thin "Future: GuruRMM integration" stub with a "Why this skill exists"
section: ScreenConnect surfaces as a per-partner Integrations Center / addons-page
entry, positioned as the bring-your-own alternative to GuruConnect (a partner already
paying for ScreenConnect uses their licensed instance as the remote-access backend).
Points at the mapped plan: SPEC-024, RMM_THOUGHTS Feature 7 + Refinement 7a, the
Integrations Center roadmap item.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-06-23 19:28:19 -07:00
parent 30841fbfb1
commit 3de8b7fde3

View File

@@ -93,15 +93,39 @@ surfacing it. It does NOT log expected/handled conditions - a missing extension
method ("web method does not exist"), a rate-limit (429), the `raw` probe path, or
selftest runs (`SC_SUPPRESS_ERRORLOG=1`) are skipped (see `_should_log_error`).
## Future: GuruRMM integration (Raw idea)
## Why this skill exists: the GuruRMM addon integration (the end goal)
Tie this into GuruRMM (parallels the multi-vendor security thought, Feature 6):
when a device is flagged for ScreenConnect in the RMM, GuruRMM looks up the
device's client/site/tags and calls `build-installer` to produce a parameterized
installer, then pushes it via the agent - so the device installs the correct SC
client and self-places into the right Company/Site/Tag automatically. `set-
properties` keeps the SC tags in sync when the RMM record changes. Capture/advance
via RMM_THOUGHTS -> /shape-spec (needs Mike's go).
This skill is the **verified connector prototype** for a GuruRMM addon, not a
one-off CLI. The end goal is to surface ScreenConnect as a first-class, per-partner
entry on the GuruRMM **Integrations Center / App Center** ("addons page"), so a
partner can wire in their OWN paid ScreenConnect instance and the RMM drives it.
**Positioning - ScreenConnect is the bring-your-own alternative to GuruConnect.**
GuruRMM's native remote-access product is **GuruConnect** (consumed via its
integration contract - see `guru-rmm/docs/GURU_CONNECT_INTEGRATION.md`). A partner
who is **already paying for ScreenConnect and does NOT want GuruConnect** enables
the ScreenConnect addon instead and uses their existing licensed instance for
remote access. Same RMM surface (the "remote control" device action, embedded/
launched session), different provider behind it - selectable per partner on the
addons page. It is an alternative remote-access backend, not an addition GuruConnect
depends on.
**What this skill proves / ports into the server:** the parameterized access
installer build (`build-installer` -> a pre-keyed URL whose repeated `c=` params
self-tag the device into the right Company/Site/Tag with no SC-console step), the
silent RMM push, and post-install control (`send-command`, `send-message`,
`set-properties` to keep SC custom properties in sync as the RMM record changes).
`sc_client.build_installer_url` + the control methods are what move server-side.
**Where the plan is mapped (all GuruRMM-side, needs Mike's go - status Raw):**
- `docs/specs/SPEC-024-screenconnect-auto-deploy.md` - the auto-deploy mechanics
(per-partner instance config, `c0..c7` slot mapping, scope toggles, dispatch).
- `docs/RMM_THOUGHTS.md` **Feature 7** - parameterized deploy + control from the RMM.
- `docs/RMM_THOUGHTS.md` **Refinement 7a** (Mike) - ScreenConnect as a per-partner
App Center entry; generalizes to a "Remote Access" category (SC/TeamViewer/AnyDesk).
- `docs/FEATURE_ROADMAP.md` **Integrations Center** - the unified addons UI surface.
Advance via RMM_THOUGHTS -> `/shape-spec`. Do NOT build until Mike gives the go.
## Reference