- Similar existing features: - Codebase search results: - External research: - Architecture fit: CODING GUIDELINES REQUIREMENTS: Write a comprehensive specification with these sections: 1. OVERVIEW - What the feature does (2-3 sentences) - User-facing benefit - Primary use cases 2. SCOPE - What's included in v1 - What's explicitly out of scope (for future) - Success criteria 3. ARCHITECTURE - Components involved (agent/server/dashboard) - Data flow - Database schema changes - API endpoints needed 4. IMPLEMENTATION DETAILS Agent (if applicable): - Files to modify/create - Rust structs/enums needed - IPC commands (if any) Server (if applicable): - API routes - Database migrations - Business logic modules Dashboard (if applicable): - New pages/components - State management - API integration 5. SECURITY CONSIDERATIONS - Authentication/authorization requirements - Input validation - Audit logging - Potential vulnerabilities and mitigations 6. TESTING STRATEGY - Unit tests needed - Integration tests - Manual test scenarios 7. ROLLOUT PLAN - Feature flag approach - Backward compatibility - Migration path - Documentation needs 8. EFFORT ESTIMATE - Small (1-2 days), Medium (3-5 days), Large (1-2 weeks), X-Large (2+ weeks) - Breakdown by component Be specific and actionable. Reference actual file paths, struct names, and patterns from the codebase. ``` If Ollama unreachable, write the specification yourself using the research findings. --- ## Phase 6 — Roadmap Placement Analysis Analyze the FEATURE_ROADMAP.md structure to determine: 1. **Exact placement:** Which existing subsection does this belong in? Or does it need a new subsection? 2. **Build sequencing:** Based on the roadmap structure and existing priorities: - What features must be built before this one? (dependencies) - What features does this unblock? (enables) - Which sprint/milestone does this fit into? 3. **Priority justification:** - P1: Blocks other critical features, security-critical, or MVP requirement - P2: Important for competitive parity, customer requests, or usability - P3: Nice-to-have, future enhancement, or edge case --- ## Phase 7 — Write Specification Document Create a new file: `projects/msp-tools/guru-rmm/docs/specs/SPEC-XXX-.md` Where XXX is the next available number (check existing specs directory). **File format:** ```markdown # SPEC-XXX: **Status:** Proposed **Priority:** P1/P2/P3 **Requested By:** () **Estimated Effort:** --- ## Overview <2-3 sentence summary> **Use Cases:** - - **Success Criteria:** - --- ## Scope ### Included in v1 - - ### Explicitly Out of Scope - --- ## Architecture ### Components - **Agent:** - **Server:** - **Dashboard:** ### Data Flow ### Database Schema ```sql -- New tables or columns ``` ### API Endpoints - `POST /api/...` — - `GET /api/...` — --- ## Implementation Details ### Agent (`agent/src/`) **Files to modify:** - `agent/src/xyz.rs` — **New structs/enums:** ```rust // Example code ``` ### Server (`server/src/`) **Files to modify:** - `server/src/routes/xyz.rs` — **Database migrations:** - `migrations/YYYYMMDD_feature_name.sql` ### Dashboard (`dashboard/src/`) **New components:** - `dashboard/src/components/XyzFeature.tsx` — **API integration:** - Use `useQuery` for GET, `useMutation` for POST/PUT --- ## Security Considerations - **Authentication:** - **Authorization:** - **Input Validation:** - **Audit Logging:** - **Threat Model:** --- ## Testing Strategy ### Unit Tests - `agent/tests/xyz_test.rs` — - `server/tests/api/xyz_test.rs` — ### Integration Tests - ### Manual Testing 1. 2. --- ## Rollout Plan 1. **Feature flag:** `feature.xyz.enabled` (default: false) 2. **Database migration:** Apply schema changes 3. **Agent update:** Deploy agent with feature flag check 4. **Dashboard deploy:** UI available when feature enabled 5. **Documentation:** Update user guide ### Backward Compatibility --- ## Dependencies **Must be completed first:** - **Enables future features:** - --- ## Open Questions - - --- ## References - Related roadmap section: - Similar implementations: - External documentation: --- **Next Steps:** 1. Review specification with team 2. Refine based on feedback 3. Move to sprint backlog 4. Assign to developer ``` --- ## Phase 8 — Update Roadmap Add or update the feature in `FEATURE_ROADMAP.md`: - If it fits an existing subsection, add it there - If it needs a new subsection, create one - Link to the spec document: `[Feature Name](docs/specs/SPEC-XXX-feature-name.md) - P2` - Add checkboxes for sub-tasks if applicable --- ## Phase 9 — Commit Changes ```bash cd projects/msp-tools/guru-rmm git add docs/specs/SPEC-XXX-feature-name.md docs/FEATURE_ROADMAP.md git commit -m "spec: add SPEC-XXX Comprehensive specification for . Requested by . - Full architecture analysis - Implementation details across agent/server/dashboard - Security considerations - Effort estimate: - Priority: P1/P2/P3 - Added to roadmap under

/" git push origin main ``` Then update submodule pointer in parent repo: ```bash cd /Users/azcomputerguru/ClaudeTools git add projects/msp-tools/guru-rmm git commit -m "chore: update guru-rmm submodule (SPEC-XXX )" git push origin main ``` --- ## Phase 10 — Send Coord Message (if requested by Howard) If Howard submitted this (not Mike), send a coord message: ```bash curl -s -X POST http://172.16.3.30:8001/api/coord/messages \ -H "Content-Type: application/json" \ -d '{ "from_session": "/claude-main", "to_session": "ALL_SESSIONS", "project_key": "gururmm", "subject": "Feature Spec Complete: ", "body": "Howard submitted a feature request. Full specification created.\n\nSPEC: docs/specs/SPEC-XXX-.md\n\nPriority: \nEffort: \nPlacement:

/\n\nSummary:\n<2-3 sentence summary>\n\nReady for review and sprint planning." }' ``` --- ## Phase 11 — Response to User Provide a comprehensive summary: ``` [SUCCESS] Feature specification created SPEC-XXX: Priority: P1/P2/P3 Effort: Placement:

/ OVERVIEW <2-3 sentence summary> KEY COMPONENTS - Agent: - Server: - Dashboard: SECURITY CONSIDERATIONS - DEPENDENCIES - Requires: - Enables: FILES CREATED - docs/specs/SPEC-XXX-.md (full specification) - Updated FEATURE_ROADMAP.md The specification includes: ✓ Complete architecture analysis ✓ Implementation details for all components ✓ Security threat model and mitigations ✓ Testing strategy ✓ Rollout plan with feature flags ✓ Effort breakdown Coord message sent to Mike for review and sprint planning. P1: Schedule for immediate sprint P2: Add to near-term backlog P3: Track for future consideration ``` --- ## Error Handling - If Ollama unreachable: Perform all analysis yourself (no degradation) - If coord API fails: Warn user but continue (they can manually notify Mike) - If spec number conflicts: Check existing specs and use next available - If roadmap section unclear: Create new subsection rather than force-fit --- ## Notes - This command can take 2-5 minutes due to research and specification generation - The specification is a living document — can be refined during sprint planning - Feature flags ensure safe rollout even for partially complete features - Effort estimates are initial and may be revised during implementation