memory: Howard cleared to handle GuruRMM merges/deploys (Mike, 2026-06-21)
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:
@@ -7,7 +7,7 @@
|
||||
- [ACG Office Network Infrastructure](infra_office_network.md) — IPs/hosts/roles for pfSense/Jupiter/VMs/Docker. Check before assuming; .21 (Uranus) is storage.
|
||||
- [Power Failure Runbook](../POWER_FAILURE_RUNBOOK.md) — Recovery order after a power event: Tailscale routes, libvirt/VMs, Seafile, NPM/DNS.
|
||||
- [Syncro API — Invoice Verification Pattern](syncro_invoice_verification_pattern.md) — /invoices?customer_id=X returns no ticket linkage; query /invoices/{number} for ticket_id. Compare by ticket ID, not number.
|
||||
- [Approval Workflow: Tools vs Projects](approval-workflow-tools-vs-projects.md) — Tools (remediation, scripts): Howard/Claude with approval. Projects (GuruRMM): Mike approval; features→roadmap, bugs→bug list.
|
||||
- [Approval Workflow: Tools vs Projects](approval-workflow-tools-vs-projects.md) — Tools (remediation, scripts): Howard/Claude with approval. Projects (GuruRMM): Mike approval for architecture/features; Howard can handle merges/deploys himself (2026-06-21); bugs→bug list.
|
||||
- [CDP Chrome driver](reference_cdp_chrome_driver.md) — Drive Chrome via DevTools Protocol (.claude/scripts/cdp.py): visible window + screenshots-to-disk so Gemini/Grok can SEE the live site. Use localhost not 127.0.0.1; dedicated profile. Antigravity-style.
|
||||
- [Firefox driver (ff.py)](reference_ff_firefox_driver.md) — PREFERRED browser driver. Drive Firefox via Playwright (.claude/scripts/ff.py): daemon on :9333, persistent profile, nav/shot/click/type/eval/console/network. Mike dislikes Chrome; claude-in-chrome connector disabled 2026-06-06.
|
||||
- [Community Forum (Flarum)](reference_community_forum.md) — Flarum forum at community.azcomputerguru.com, API access, database, posting workflow.
|
||||
|
||||
@@ -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)
|
||||
|
||||
@@ -17,6 +17,8 @@ Categories (the `[type]` tag): _(none)_ = skill/command execution failure ·
|
||||
|
||||
<!-- Append entries below this line -->
|
||||
|
||||
2026-06-22 | GURU-5070 | coord/gururmm-merge-authority | [correction] assumed GuruRMM merges/deploys are Mike-only (held BUG-018 for Mike's go); correct is Howard can handle merges himself
|
||||
|
||||
2026-06-22 | Mikes-MacBook-Air.local | coord/check-messages.sh | [correction] broadcasts never marked read on server, only in local seen-file -> repeat on every session [ctx: fix: mark broadcasts read on server like personal messages]
|
||||
|
||||
2026-06-21 | Howard-Home | git/submodule | [friction] Did feature work directly in the SHARED guru-rmm submodule working tree while a CONCURRENT Claude session was active in it. The other session switched branches (fix/audit-cleanup -> bugfix/bug-019 -> detached) and repointed my branch ref mid-work, and the working tree ended up with BOTH sessions' uncommitted changes mixed together. Wasted a recovery cycle. FIX: when doing submodule feature work and other sessions may be live (the /save note warns 3-4 sessions share one tree), create an isolated 'git worktree add <path> origin/main' FIRST, do all edits + commit + push-by-SHA there, then 'worktree remove' — never rely on the shared checkout's branch/HEAD surviving. Do NOT 'git checkout --' shared files to clean up (clobbers the other session's uncommitted work). [ctx: ref=git/submodule detached-HEAD + stale-audit friction]
|
||||
|
||||
Reference in New Issue
Block a user