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>

.claude/memory/MEMORY.md

@@ -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.

.claude/memory/approval-workflow-tools-vs-projects.md

@@ -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
+- **Architecture / new features / direction:** Mike Swanson approval (feature requests → roadmap)
-- Feature requests → add to project roadmap
+- **Merges / deploys:** **Howard can handle these himself** (update 2026-06-21, Mike). A
-- Bugs → add to project bug list
+  prepared + verified bugfix/feature branch does NOT have to wait on Mike to merge — Howard (or
-- More structured development workflow with planning
+  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)

errorlog.md

@@ -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]