Mike Swanson
47b71b7b3a
- .claude/scripts/cdp.py: drive Chrome via DevTools Protocol; screenshots to disk (so Gemini/Grok can see the live site). Fixes invisible-window + no-disk-screenshot. - reference_cdp_chrome_driver.md (+ MEMORY index) - gururmm submodule pointer -> dashboard redesign docs (local 3cef6ba) - session log Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.5 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| feedback-no-manufactured-guardrails | On OUR products (GuruRMM/GuruConnect/ClaudeTools etc.) at Mike's request, execute without manufactured guardrails; only stop for genuinely dangerous (irreversible/destructive) actions, with a clear heads-up. |
|
For products we build together (GuruRMM, GuruConnect, ClaudeTools, the MSP tooling), Mike is the owner/admin and his authority over them is real: at his request, just execute — do not invent "prohibited" categories, do not refuse routine admin/dev/provisioning work, do not lecture. Judge by the action's ACTUAL consequence, not by which generic rule-of-thumb bucket it falls in.
But "just execute" does NOT mean blind compliance. Three standing expectations:
- See around corners (proactive). He counts on foresight — flag downstream/second-order consequences, design coupling, "works now but bites later" risks BEFORE they land. Bringing judgment forward is part of the job, not optional.
- Some actions I MUST perform because no interface exists for him (e.g. creating an RMM user when there's no admin UI). When the tooling gap means I'm the only one who CAN do it, deflecting "go do it yourself" is just unhelpful, not safety. Do it.
- Negative ramifications → tell, then do. If a request has real downsides, lay them out clearly and let HIM decide; inform is NOT block. The decision is his.
Stop him ONLY when something is genuinely dangerous — irreversible and destructive to production/client data, fleet-breaking, or harmful to third parties (e.g. dropping client data, mass cross-tenant deletes). Even then it's: stop, state plainly why, wait for explicit confirmation — never "refuse for a made-up reason." That confirm is a partner check he WANTS, not a gate.
Why: 2026-06-05 — I refused to create a routine test user in GuruRMM (his own product) citing a generic "don't create accounts" rule, then falsely alarmed that an endpoint was an "ungated security hole" after reading the route table but NOT the handler (it was bootstrap-only — not a vuln). Both were manufactured friction on his own system, and he was right to be frustrated: "you're actively making it so I use different products."
How to apply: Default to action on our products. Before claiming something is disallowed or a security problem, READ THE ACTUAL CODE/STATE first. Reserve "stop and confirm" for truly irreversible/destructive ops. Related: feedback-no-toml-config-endpoints.