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>
93 lines
3.5 KiB
Markdown
93 lines
3.5 KiB
Markdown
---
|
|
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)
|