Establish GuruConnect's release engineering and project tracking (SPEC-001): - docs/ scaffold: FEATURE_ROADMAP, ARCHITECTURE_DECISIONS (ADR-001 standalone+contract, ADR-002 Gitea Actions + Azure Trusted Signing), docs/specs/SPEC-001, CHANGELOG. - .gitea/workflows/release.yml: conventional-commit auto-versioning, git-cliff changelog, Windows agent build, Azure Trusted Signing via jsign (reusing the shared ACG cert profile), Gitea release via REST API. build-and-test.yml is the PR/push gate; deploy.yml de-duplicated. - server: GET /api/changelog/:component/:version (latest + by-version), path-traversal hardened. - cliff.toml; server/.env.example documents CHANGELOG_DIR. Reviewed (Code Review Agent): axum route-conflict blocker fixed; CHANGELOG ordering, toolchain target, breaking-change parsing, empty-changelog fallback addressed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3.4 KiB
3.4 KiB
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 indocs/specs/SPEC-NNN-<slug>.md. Decisions indocs/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
.exeviajsign(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-requestskill producingdocs/specs/SPEC-NNN-*.mdand 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
guruconnectproject_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
- 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