chore(memory): consolidate scattered feedback/project/reference files
Compressed memory store 104 -> 71 files via four passes: - Syncro: 19 scattered feedback_syncro_* files merged into 3 rule files (api/billing/workflow) + an on-demand feedback_syncro_history.md for incident detail, quotes, and tech/product ID tables. - Four near-duplicate merges: Howard paste-safety, Pluto build server, Howard backend deferral, IX server access (ssh+tailscale). - Per-cluster rule/state/history split applied to GuruConnect (2->1), Dataforth (3->2), Cascades (7->3), GuruRMM (13->3). - New reference_resource_map.md: single auto-loaded cheatsheet for "do I have access to X and how do I connect from this machine?" - MEMORY.md rewritten to match the new layout. Health: broken backlinks 8->7, overlap clusters 12->5, orphans 17->0.
This commit is contained in:
@@ -1,108 +0,0 @@
|
||||
---
|
||||
name: GuruRMM Development Principles
|
||||
description: Every GuruRMM feature is full-stack (backend+API+UI+docs+scalability); product works without AI; the FEATURE_ROADMAP entry update is part of definition-of-done. Mirrors guru-rmm/docs/DESIGN.md.
|
||||
type: project
|
||||
---
|
||||
|
||||
# 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.**
|
||||
|
||||
---
|
||||
|
||||
## Living Roadmap (MANDATORY)
|
||||
|
||||
`projects/msp-tools/guru-rmm/docs/FEATURE_ROADMAP.md` is the single living record of intent — where the product is going AND where it has been. It is a status-and-plan tracker, NOT a write-once backlog. Convention: `[ ]` = planned, `[x]` = shipped (annotate with date).
|
||||
|
||||
**Consult it going in, update it coming out — the roadmap update is part of definition-of-done:**
|
||||
- **Before building:** read the feature's roadmap entry for intent/scope. New work that isn't on the roadmap gets an entry first.
|
||||
- **When shipping or modifying a feature:** update its roadmap entry in the SAME change — flip `[ ]`→`[x]` with a date, or revise/add the item. A code change that ships or alters a roadmap feature WITHOUT touching FEATURE_ROADMAP.md is incomplete (same standard as shipping without UI).
|
||||
- **Don't over-claim:** an entry's text must match what's actually built. If only part is done, keep `[ ]` and annotate the scope (e.g. "TCP probing shipped; ICMP/ARP/SNMP pending") rather than flipping.
|
||||
|
||||
`/rmm-audit`'s roadmap pass is the **backstop** that reconciles drift — it is not the primary maintainer. Dev work keeps the roadmap honest; the audit catches what slipped. See [[feedback_rmm_dev_is_mike]] (RMM dev is Mike's).
|
||||
|
||||
---
|
||||
|
||||
## 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