feat: add /gc-feature-request skill; register guruconnect coord key

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.claude/CLAUDE.md

@@ -192,6 +192,7 @@ curl -s -X PUT "http://172.16.3.30:8001/api/coord/components/gururmm/server" \
 | project_key | Components | States |
 |-------------|------------|--------|
 | `gururmm` | `server`, `agents`, `dashboard`, `db_migrations` | `building`, `built`, `deploying`, `deployed`, `degraded` |
+| `guruconnect` | `server`, `agent`, `dashboard` | `building`, `built`, `deploying`, `deployed`, `degraded` |
 | `claudetools` | `api`, `db_migrations`, `coord_api` | `deploying`, `deployed`, `degraded` |
 | `dataforth-dos` | `app`, `db` | `active`, `idle`, `degraded` |
 | `clients/<name>` | `(free-form)` | `(free-form)` |

.claude/commands/gc-feature-request.md

@@ -0,0 +1,117 @@
+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.