azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

memory: Howard cleared to handle GuruRMM merges/deploys (Mike, 2026-06-21)

Browse Source 
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>
This commit is contained in:
Mike Swanson
2026-06-21 17:54:59 -07:00
parent 63d750b7d3
commit dd033289f6
3 changed files with 12 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
.claude/memory/approval-workflow-tools-vs-projects.md
View File

@@ -1,6 +1,6 @@
---
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.
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
---
@@ -40,10 +40,13 @@ Tools need to adapt quickly to field conditions. When a technician hits a blocke
- 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
- **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.
@@ -86,4 +89,4 @@ Projects need architectural oversight, version planning, and consideration of do
---
**Status:** Active policy
**Last Updated:** 2026-04-29
**Last Updated:** 2026-06-21 (Howard cleared to handle GuruRMM merges/deploys)