Mike Swanson
dd033289f6
Corrects the assumption that GuruRMM merge-to-main (=deploy) is Mike-only. Mike still owns RMM architecture/direction, but Howard can land prepared+verified branches himself — they no longer bottleneck on Mike. Updated approval-workflow-tools-vs-projects + MEMORY.md index + logged the correction in errorlog. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3.5 KiB
3.5 KiB
name: Approval workflow — tools vs projects
description: General MSP tools (remediation, onboard scripts) — Howard can modify or Claude runs with Howard/Mike approval. Projects (GuruRMM): Mike approval for architecture/features, but Howard can handle merges/deploys himself (2026-06-21); bugs→bug list.
type: feedback
Approval Workflow: Tools vs Projects
Created: 2026-04-29 Authority: Mike Swanson (owner) Context: Cascades CA role gap fix discussion
General Tools (Immediate Operational Changes)
Scope:
- remediation-tool skill and all subscripts
- onboard-tenant.sh and MSP automation utilities
- Backup scripts, sync scripts, operational tooling
- Any utility designed to support field work
Approval Authority:
- Howard Enos can modify directly to further his work
- Claude can execute changes with approval from either Howard or Mike
- No roadmap process required
- Changes go directly to implementation
Rationale: Tools need to adapt quickly to field conditions. When a technician hits a blocker (like the CA role gap), the tool should be fixed immediately to unblock the work.
Projects (Structured Development)
Scope:
- GuruRMM (Rust/Axum server + dashboard)
- ClaudeTools API (FastAPI/MariaDB)
- Radio show audio processor
- Any larger software system with architectural complexity
Approval Authority:
- Architecture / new features / direction: Mike Swanson approval (feature requests → roadmap)
- Merges / deploys: Howard can handle these himself (update 2026-06-21, Mike). A prepared + verified bugfix/feature branch does NOT have to wait on Mike to merge — Howard (or Claude on Howard's say-so) can merge to main (= deploy). This nuances the older "RMM dev = Mike" framing in feedback_gururmm: Mike still owns RMM direction, but Howard is cleared to land merges. Bugs → bug list as before.
- More structured development workflow with planning for new capabilities
Rationale: Projects need architectural oversight, version planning, and consideration of downstream impacts. Changes follow formal development process.
Examples
Tool Fix (Approved Immediately)
- Scenario: Howard discovers Tenant Admin SP lacks CA Administrator role in newly onboarded tenant
- Action: Fix onboard-tenant.sh to assign the role automatically
- Approval: Mike approved in conversation; Howard could have approved directly
- Process: Implement immediately, test, commit
Project Feature (Roadmap)
- Scenario: Howard wants GuruRMM to add automatic Windows patching workflow
- Action: Add to GuruRMM roadmap with priority and scope notes
- Approval: Mike reviews roadmap quarterly, prioritizes features
- Process: Design → approval → sprint planning → implementation
Project Bug (Bug List)
- Scenario: GuruRMM dashboard doesn't refresh agent status automatically
- Action: Add to GuruRMM bug list with severity and reproduction steps
- Approval: Mike reviews bug list, assigns priority
- Process: Triage → fix → test → deploy
When Unclear
If in doubt about tool vs project:
- Tools are utilities that support the work
- Projects are systems that are the work
If in doubt about approval:
- Operational blocker in the field → tool fix, proceed with available approval
- Enhancement or new capability → ask Mike first
- Security or credential handling → always confirm with Mike
Status: Active policy Last Updated: 2026-06-21 (Howard cleared to handle GuruRMM merges/deploys)