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.