---
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)