118 lines
4.3 KiB
Markdown
118 lines
4.3 KiB
Markdown
GuruConnect Feature Request — Analysis & Specification
|
|
|
|
Produce a researched specification for a GuruConnect feature, place it in the GC roadmap, and commit
|
|
it. GuruConnect is a standalone remote-support product (separate repo `azcomputerguru/guru-connect`,
|
|
tracked as the `projects/msp-tools/guru-connect` submodule). Do NOT confuse it with GuruRMM — see its
|
|
ADR-001. Use `/feature-request` for GuruRMM instead.
|
|
|
|
`$ARGUMENTS` = the feature request text.
|
|
|
|
---
|
|
|
|
## Phase 1 — Context
|
|
|
|
Read:
|
|
- `projects/msp-tools/guru-connect/docs/FEATURE_ROADMAP.md` — sections, priorities, existing items
|
|
- `projects/msp-tools/guru-connect/docs/ARCHITECTURE_DECISIONS.md` — ADRs (esp. ADR-001 standalone+contract)
|
|
- `projects/msp-tools/guru-connect/CLAUDE.md` — architecture, design constraints, coding standards
|
|
- `projects/msp-tools/guru-connect/docs/specs/` — existing SPEC-NNN files (to pick the next number)
|
|
|
|
GuruConnect architecture vocabulary: **agent** (Windows capture/input/viewer), **relay-server**
|
|
(Axum), **viewer** (native + React/TS web viewer), **dashboard**. Transport: protobuf-over-WSS.
|
|
|
|
## Phase 2 — Classify (Ollama)
|
|
|
|
Call Ollama `qwen3.6:latest` (strict JSON). Endpoint from `.claude/identity.json` (`.ollama.endpoint`).
|
|
|
|
```
|
|
Analyze a feature request for GuruConnect, a Rust remote-desktop product (agent + Axum relay +
|
|
native/web viewer), protobuf-over-WSS.
|
|
Roadmap sections: Core Remote Control, GuruRMM Integration, Server/API, Security & Infrastructure,
|
|
Operational Tooling, Future Considerations.
|
|
Feature request: $ARGUMENTS
|
|
Respond JSON only: {"section","subsection","priority":"P1|P2|P3","brief_summary",
|
|
"similar_features":[],"research_needed":[]}
|
|
```
|
|
If Ollama is unreachable, classify yourself.
|
|
|
|
## Phase 3 — Research
|
|
|
|
- Grep `projects/msp-tools/guru-connect/{agent,server,dashboard,proto}/` for related code; cite file:line.
|
|
- Note where the feature lives (agent / relay-server / viewer / dashboard / proto / DB migration).
|
|
- If it touches the GuruRMM integration surface, cross-reference `docs/specs/native-remote-control/`
|
|
and keep the integration contract authoritative (GC owns it).
|
|
|
|
## Phase 4 — Write the spec
|
|
|
|
Next number = highest existing `SPEC-NNN` + 1. Write `docs/specs/SPEC-NNN-<slug>.md`:
|
|
|
|
```markdown
|
|
# SPEC-NNN: <Feature Name>
|
|
|
|
**Status:** Proposed
|
|
**Priority:** P1|P2|P3
|
|
**Requested By:** <Mike|Howard> (<date>)
|
|
**Estimated Effort:** Small|Medium|Large|X-Large
|
|
|
|
## Overview
|
|
<2-3 sentences; user-facing benefit; primary use cases; success criteria>
|
|
|
|
## Scope
|
|
### Included in v1
|
|
### Explicitly out of scope
|
|
|
|
## Architecture
|
|
- Agent / Relay-server / Viewer / Dashboard responsibilities
|
|
- Protobuf changes (`proto/guruconnect.proto`)
|
|
- DB schema (migrations)
|
|
- API endpoints / WS messages
|
|
|
|
## Implementation details
|
|
- Files to touch (file:line where known), structs/messages, key logic
|
|
|
|
## Security considerations
|
|
- Auth (JWT/agent key/support code), input validation, audit events, threat model
|
|
|
|
## Testing strategy
|
|
- Unit / integration / manual scenarios
|
|
|
|
## Effort estimate & dependencies
|
|
- Size; what must precede it; what it unblocks
|
|
|
|
## Open questions
|
|
```
|
|
|
|
Generate the prose via Ollama `qwen3:14b` if available (fallback: write it yourself). Be specific —
|
|
real file paths and message/struct names from Phase 3.
|
|
|
|
## Phase 5 — Roadmap
|
|
|
|
Add/insert the item in the right `docs/FEATURE_ROADMAP.md` section:
|
|
`- [ ] **<Feature>** — P<n> — <one-liner>. (SPEC-NNN)` with a link to the spec.
|
|
|
|
## Phase 6 — Commit (GC submodule, then bump pointer)
|
|
|
|
```bash
|
|
cd projects/msp-tools/guru-connect
|
|
git add docs/specs/SPEC-NNN-<slug>.md docs/FEATURE_ROADMAP.md
|
|
git commit -m "spec: add SPEC-NNN <feature name>"
|
|
# push only if the user asks; pushing main triggers GC CI
|
|
cd ../../..
|
|
git add projects/msp-tools/guru-connect
|
|
git commit -m "chore: bump guru-connect submodule (SPEC-NNN <feature name>)"
|
|
```
|
|
|
|
## Phase 7 — Optional coord message
|
|
|
|
If Howard submitted it (not Mike), POST to the coord API with `project_key: "guruconnect"`,
|
|
subject "GC Feature Spec: <name>", summarizing the spec for Mike's review.
|
|
|
|
## Phase 8 — Respond
|
|
|
|
Summarize: SPEC number, priority, effort, placement, overview, key components, dependencies, files
|
|
created. Use ASCII markers ([SUCCESS]/[INFO]); no emojis.
|
|
|
|
## Notes
|
|
- Never edit GuruConnect product code as part of "RMM work"; this skill is the GC product's own intake.
|
|
- Spec is a living doc; refine during planning.
|