azcomputerguru/guru-connect
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases 2 Wiki Activity
Files
cdc182f0fbc044931606f1e6293ea3d7c6c150a3
guru-connect/docs/FEATURE_ROADMAP.md
Mike Swanson cdc182f0fb spec: add SPEC-005 machines list view (dual indicators + rich rows) 
ScreenConnect "Access"-list parity for the Operator Console machines list:
per-row dual Host/Guest connection indicators (Guest=agent is_online,
Host=viewer_count>0 with viewer names + durations) and rich inline metadata
(company, site, device type, tags, logged-on user + idle, client version in
red when outdated). Live Host/Guest state already exists on SessionInfo
(is_online, viewer_count, viewers); main work is enriching /api/machines with
that + SPEC-003 inventory and redesigning MachinesPage rows. Depends on
SPEC-003 (data), reads cleanest after SPEC-004 (dedup), dovetails SPEC-002
Phase 2. Company-tree nav split out as a P3 follow-up. Requested by Mike
2026-05-30.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-05-30 16:17:48 -07:00

5.3 KiB
Raw Blame History

GuruConnect — Feature Roadmap

Living roadmap for the GuruConnect product. Status markers: [ ] planned · [~] in consideration · [x] shipped. Priorities: P1 (blocking/MVP) · P2 (important) · P3 (nice-to-have). Specs live in docs/specs/SPEC-NNN-<slug>.md. Decisions in docs/ARCHITECTURE_DECISIONS.md.

GuruConnect is a standalone remote-support product (ScreenConnect/Splashtop-class) on our own Rust stack. It ships independently of GuruRMM and integrates with it via a versioned contract (see specs/native-remote-control/ and ADR-001).

Operational Tooling & Release Engineering

Bringing GC to parity with GuruRMM's release engineering. Full plan: SPEC-001.

  • Code signing — Azure Trusted Signing in CI — P1 — sign the Windows agent .exe via jsign (TRUSTEDSIGNING) in Gitea Actions, reusing the shared ACG cert profile. (SPEC-001 §2)
  • Automatic versioning — P1 — conventional-commit-driven version bump across agent/server/dashboard, embedded via build.rs. (SPEC-001 §3)
  • Changelog generation & API — P2 — CHANGELOG.md + per-version changelogs from conventional commits, served at /api/changelog/.... (SPEC-001 §4)
  • Feature-request workflow — P2 — /gc-feature-request skill producing docs/specs/SPEC-NNN-*.md and updating this roadmap. (SPEC-001 §1)
  • Roadmap / ADR / spec tracking — P1 — this file + ARCHITECTURE_DECISIONS.md + docs/specs/. (SPEC-001 §5) — bootstrapped
  • Coord-API registration — P3 — register guruconnect project_key + components (server, agent, dashboard) in the coordination API. (SPEC-001 §6)
  • [~] Release distribution / update channels — P3 — beta→stable rollout with health metrics (mirrors RMM updates.rs). Deferred — larger subsystem, post-parity.

Core Remote Control

  • Screen capture (DXGI primary, GDI fallback)
  • Input injection (mouse/keyboard)
  • Native viewer + guruconnect:// protocol handler
  • Support-code (attended) and persistent (unattended) agent modes
  • Protobuf-over-WSS transport, Zstd frame compression
  • [~] React/TS web viewer (dashboard/src/components/RemoteViewer.tsx) — embeddable session viewer
  • Multi-monitor switching — P2
  • File transfer — P3 (out of scope for native-remote-control v1)
  • Session recording — P3 (out of scope for native-remote-control v1)

GuruRMM Integration

  • Native remote control via broker — P2 — versioned integration contract so GuruRMM can launch/embed GC sessions on managed endpoints. Full spec: specs/native-remote-control/. (Contract owned by GC; RMM consumes it.)
  • /api/integration/v1/ namespace + capability discovery — P2 (part of native-remote-control)
  • Per-machine agent keys (replace shared AGENT_API_KEY) — P2
  • Embedded-viewer framing allowlist (scoped frame-ancestors) — P2

Server / API

  • JWT auth, Argon2id passwords, rate limiting, security headers
  • Sessions / machines / support-codes / events
  • Full machine inventory in the connection DB — P2 — persist per-machine device inventory (OS+locale+install, CPU/RAM, mfr/model/serial, external WAN IP captured server-side + private LAN IP + MAC, logged-on user, idle, time zone, uptime, local-admin) on connect_machines, refreshed each AgentStatus, shown in the dashboard machine detail (ScreenConnect "Guest Info" parity). Data layer for SPEC-002 Phase 2; closes GC side of agent-IP gap (todo 7459428e). (SPEC-003)
  • Stable machine identity + session lifecycle reaping + operator removal — P1 — give the agent a deterministic machine-derived machine_uid (Windows MachineGuid-based) so the same box can't register duplicates (root cause: agent_id is a config-file random UUID that a portable/misconfigured run regenerates each launch); key registration on it; add TTL reaping + same-machine supersede as defense-in-depth; and admin-gated per-row + multi-select bulk removal of stale sessions/units. Identity must be bound to the per-machine agent key (spoof guard). Fixes ghost-session accumulation seen on the live console (15 sessions / 0 live, ~10 orphans for one machine). (SPEC-004)
  • Machines list view — dual connection indicators + rich rows — P2 — ScreenConnect "Access"-list parity: per-row Host/Guest two-segment connection bar (Guest=agent online, Host=viewer connected, with names + durations) and rich inline metadata (company, site, device type, tags, logged-on user + idle, client version in red when outdated). Server-enriches /api/machines with live session state + SPEC-003 inventory. (SPEC-005)
  • Machines "by Company" tree nav with per-company counts — P3 — left-nav grouping sidebar (screenshot parity). Follow-up sub-item of SPEC-005.
  • Programmatic session pre-create + viewer-token (integration contract) — P2

Security & Infrastructure

  • Phase-1 security hardening (SEC-1..5), systemd units, backups
  • CI security audit gate (cargo audit) wired to release — P2

Future Considerations

  • macOS / Linux remote-control agents — P3
  • Auto-update for the agent — P3
Reference in New Issue View Git Blame Copy Permalink