memory: GuruRMM holistic development principles
Documented two fundamental GuruRMM development principles: 1. Holistic Feature Development (MANDATORY): - Every feature requires complete stack: backend, API, UI/UX, docs - Features without management interfaces are incomplete - Design for scalability and future expansion - Example workflows included 2. AI-Optional Operation: - Product must work without AI agents (Claude, autonomous tools) - AI features are enhancements, not requirements - Core operations remain deterministic and reliable Principles documented in guru-rmm/docs/DESIGN.md and now in memory for cross-session reference. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
@@ -35,6 +35,7 @@
|
|||||||
- [Mac gururmm setup pending](project_mac_gururmm_setup_pending.md) — ACTION REQUIRED: run `bash scripts/install-hooks.sh` in gururmm repo on Mikes-MacBook-Air before any RMM work
|
- [Mac gururmm setup pending](project_mac_gururmm_setup_pending.md) — ACTION REQUIRED: run `bash scripts/install-hooks.sh` in gururmm repo on Mikes-MacBook-Air before any RMM work
|
||||||
|
|
||||||
## Project
|
## Project
|
||||||
|
- [GuruRMM Development Principles](gururmm-development-principles.md) - MANDATORY: every feature needs full stack (backend, API, UI, docs, scalability). Product must work without AI agents (AI features are enhancements). Documented in guru-rmm/docs/DESIGN.md.
|
||||||
- [Sync script bug — untracked files](project_sync_script_bug.md) — Flagged for Mike. `.claude/scripts/sync.sh` line 53 misses untracked-only changes; one-line fix included.
|
- [Sync script bug — untracked files](project_sync_script_bug.md) — Flagged for Mike. `.claude/scripts/sync.sh` line 53 misses untracked-only changes; one-line fix included.
|
||||||
- [MasterBooter Side Project](project_masterbooter.md) — Howard's Rust+Slint Windows deployment toolkit at C:\MasterBooter, separate from client work. Do not log to clients/.
|
- [MasterBooter Side Project](project_masterbooter.md) — Howard's Rust+Slint Windows deployment toolkit at C:\MasterBooter, separate from client work. Do not log to clients/.
|
||||||
- [Audio Processor Architecture](project_audio_processor_architecture.md) - Segment-first pipeline: detect breaks before transcription for complete content capture
|
- [Audio Processor Architecture](project_audio_processor_architecture.md) - Segment-first pipeline: detect breaks before transcription for complete content capture
|
||||||
|
|||||||
89
.claude/memory/gururmm-development-principles.md
Normal file
89
.claude/memory/gururmm-development-principles.md
Normal file
@@ -0,0 +1,89 @@
|
|||||||
|
# GuruRMM Development Principles
|
||||||
|
|
||||||
|
**Created:** 2026-04-29
|
||||||
|
**Authority:** Mike Swanson (owner)
|
||||||
|
**Location:** Documented in `projects/msp-tools/guru-rmm/docs/DESIGN.md`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Holistic Feature Development (MANDATORY)
|
||||||
|
|
||||||
|
When planning or implementing ANY GuruRMM feature, the complete stack must be considered and built:
|
||||||
|
|
||||||
|
### Required Components for Every Feature:
|
||||||
|
1. **Backend/Agent Logic** — core capability implementation
|
||||||
|
2. **API Endpoints** — control and monitoring interfaces
|
||||||
|
3. **UI/UX** — dashboard configuration, status display, management interface
|
||||||
|
4. **Documentation** — user guides and operational docs
|
||||||
|
5. **Scalability Design** — architected for future expansion
|
||||||
|
|
||||||
|
### Example: Network Discovery Node
|
||||||
|
A complete implementation includes:
|
||||||
|
- Agent-side scanning capability (ICMP, ARP, SNMP)
|
||||||
|
- Server-side data storage and API endpoints
|
||||||
|
- Dashboard UI for:
|
||||||
|
- Designating which agent is the discovery node
|
||||||
|
- Viewing discovered devices
|
||||||
|
- Configuring scan schedules
|
||||||
|
- Setting IP ranges and exclusions
|
||||||
|
- Status indicators (discovery progress, last scan time)
|
||||||
|
- Future-proof data model supporting multiple discovery methods
|
||||||
|
|
||||||
|
### Why This Matters:
|
||||||
|
- **Completeness:** Features without UI are unusable by non-API-expert admins
|
||||||
|
- **User Experience:** Configuration should be intuitive, not require documentation diving
|
||||||
|
- **Consistency:** Every feature should feel native to the product
|
||||||
|
- **No Dead Ends:** Design decisions shouldn't block obvious next steps
|
||||||
|
|
||||||
|
**Features shipped without their UI/configuration interfaces are incomplete and will be rejected.**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## AI-Optional Operation
|
||||||
|
|
||||||
|
GuruRMM must be fully functional without requiring AI agents (Claude, autonomous analysis tools) to operate.
|
||||||
|
|
||||||
|
### Core Requirements:
|
||||||
|
- All functionality accessible via traditional dashboard/API
|
||||||
|
- Configuration and management through standard interfaces
|
||||||
|
- Usable by MSP techs with zero AI/ML knowledge
|
||||||
|
- Deterministic, reliable operation for production environments
|
||||||
|
|
||||||
|
### AI Features Are Enhancements:
|
||||||
|
- **Agentic analysis** (AI-powered log analysis, anomaly detection, troubleshooting) — planned enhancement
|
||||||
|
- **Agentic command routing** (intelligent decision-making about command execution) — planned enhancement
|
||||||
|
- Users choose whether to enable AI features
|
||||||
|
- Product does not mandate AI usage
|
||||||
|
|
||||||
|
### Why This Matters:
|
||||||
|
- Real MSPs need deterministic, reliable systems
|
||||||
|
- AI features can break, hallucinate, or be unavailable
|
||||||
|
- Core operations cannot depend on AI availability
|
||||||
|
- Production stability over experimental features
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Application to Development
|
||||||
|
|
||||||
|
### When Adding Features:
|
||||||
|
1. ✅ Design the complete stack before starting implementation
|
||||||
|
2. ✅ Include UI mockups in feature planning
|
||||||
|
3. ✅ Consider future expansion in data model design
|
||||||
|
4. ✅ Ensure feature works via dashboard without API knowledge
|
||||||
|
5. ✅ Never assume AI availability for core functionality
|
||||||
|
|
||||||
|
### When Reviewing Features:
|
||||||
|
1. ❌ Reject backend-only implementations without UI
|
||||||
|
2. ❌ Reject features that require API expertise to configure
|
||||||
|
3. ❌ Reject designs that paint into architectural corners
|
||||||
|
4. ❌ Reject features that require AI to function
|
||||||
|
|
||||||
|
### Planning Questions:
|
||||||
|
- "How does an admin configure this in the dashboard?"
|
||||||
|
- "What does the status display look like?"
|
||||||
|
- "How do we expand this in v2/v3?"
|
||||||
|
- "Does this work if AI services are unavailable?"
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**These principles apply to ALL features — past, present, and future.**
|
||||||
Reference in New Issue
Block a user