Mike Swanson
7ab87384a7
Everything the console does should be callable by API, documented and discoverable. Adds: OpenAPI 3.x generated from code (utoipa) + Swagger/Redoc at /api/docs (drift-proof, route<->spec parity test); long-lived revocable scoped API tokens (connect_api_tokens, hashed like agent keys) distinct from the 24h dashboard JWT and agent keys; an API-completeness gap audit (folds in SPEC-004/ 006/007 endpoints); consistent pagination/filtering + versioning policy. Today there is zero API doc tooling and no programmatic token. Depends on SPEC-008 for the documented error envelope; distinct from the ADR-001 integration contract. Large. Parallel guru-rmm SPEC-019. Requested by Mike 2026-05-30. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
69 lines
7.2 KiB
Markdown
69 lines
7.2 KiB
Markdown
# 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](specs/SPEC-001-operational-tooling-parity.md).
|
|
|
|
- [ ] **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
|
|
|
|
- [x] Screen capture (DXGI primary, GDI fallback)
|
|
- [x] Input injection (mouse/keyboard)
|
|
- [x] Native viewer + `guruconnect://` protocol handler
|
|
- [x] Support-code (attended) and persistent (unattended) agent modes
|
|
- [x] 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/`](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
|
|
|
|
- [x] JWT auth, Argon2id passwords, rate limiting, security headers
|
|
- [x] 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](specs/SPEC-003-machine-inventory.md))
|
|
- [ ] **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](specs/SPEC-004-session-lifecycle-and-removal.md))
|
|
- [ ] **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](specs/SPEC-005-machines-list-view-parity.md))
|
|
- [ ] Machines "by Company" tree nav with per-company counts — P3 — left-nav grouping sidebar (screenshot parity). Follow-up sub-item of SPEC-005.
|
|
- [ ] **Universal machine search ("everything is searchable")** — P2 — server-side `?q=` on `/api/machines` matching case-insensitive substring across ALL attributes (OS, logged-on user, external/private IP, company, site, tag, serial, MAC, version, …), pg_trgm GIN-indexed; multi-term AND + optional field-scoped syntax (`os:`, `user:`, `ip:`). Replaces the hostname-only client filter. Depends on SPEC-003 (attrs must be persisted). ([SPEC-006](specs/SPEC-006-universal-machine-search.md))
|
|
- [ ] **Managed-agent installer builder ("Build Installer")** — P2 — dashboard wizard to build a pre-labeled persistent-agent installer (Name/Company/Site/Department/Device Type/Tag/Type) with Download / Copy URL / Send Link, reusing the existing embed-config download path; adds department + device_type to EmbeddedConfig/AgentStatus so labels persist at install time. Pairs with revocable per-machine keys; signature-vs-appended-config is the key open question. ([SPEC-007](specs/SPEC-007-managed-agent-installer-builder.md))
|
|
- [ ] **Valuable error messages (structured errors + no silent swallows)** — P2 — one structured API error envelope with stable codes + a correlation id that also lands in the logs; contextual tracing on server/agent; sweep the 37 `let _ =` swallows (the pattern that hid the migration-005 bug); dashboard surfaces the real cause + id instead of a generic line. ([SPEC-008](specs/SPEC-008-valuable-error-messages.md))
|
|
- [ ] **Feature-rich, fully-documented management API** — P2 — everything the console can do, callable by API: OpenAPI 3.x generated from code (utoipa) + browsable docs at `/api/docs`, long-lived revocable scoped API tokens (PAT-style, distinct from the 24h JWT + agent keys), an API-completeness gap audit, and consistent pagination/error conventions. Distinct from the ADR-001 RMM integration contract. ([SPEC-009](specs/SPEC-009-feature-rich-documented-api.md))
|
|
- [ ] Programmatic session pre-create + viewer-token (integration contract) — P2
|
|
|
|
## Security & Infrastructure
|
|
|
|
- [x] 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
|