Mike Swanson
1a0bcc80b0
Audit of .claude/memory found and fixed: - Broken link: Power Failure Runbook (../.claude/... -> ../...) - 8 orphaned memories not in MEMORY.md index (Graph CA/password-reset, vault-write-sequence, GURU-BEAST-ROG, 3x Cascades, identity proposal) -> now indexed under their sections, so they're discoverable - 5 files missing frontmatter -> added name/description/type - Duplicate index entry for reference_workstation_setup.md -> deduped - Trimmed the worst oversized index hooks (Syncro invoice line was 427 chars) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
90 lines
3.0 KiB
Markdown
90 lines
3.0 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) require Mike approval; features→roadmap, 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:**
|
|
- **Requires Mike Swanson approval** for changes
|
|
- Feature requests → add to project roadmap
|
|
- Bugs → add to project bug list
|
|
- More structured development workflow with planning
|
|
|
|
**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-04-29
|