wiki+memory: consolidate kittle-design -> kittle (redirect stub); add feedback memories (syncro preview, refresh-first, autonomy scope)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.claude/memory/MEMORY.md

@@ -116,3 +116,6 @@
 - [No manufactured guardrails on our products](feedback_no_manufactured_guardrails.md) — At Mikes request on GuruRMM/GuruConnect/ClaudeTools, just execute; stop only for genuinely irreversible/destructive ops (with a heads-up). Read the actual code/state before claiming something is disallowed or a security hole.
 - [Stream-of-thought design convos](feedback_stream_of_thought_design.md) — Mike brainstorms features free-form, adding requirements iteratively; Claude validates/sharpens as a design partner but does NOT build until an explicit go, then captures parked threads durably (PARKED_*.md + todos) for a later /shape-spec.
 - [RMM Thoughts backlog](feedback_rmm_thoughts_backlog.md) — GuruRMM ideas from Mike & Howard go in projects/msp-tools/guru-rmm/docs/RMM_THOUGHTS.md (Status: Raw); pipeline thought -> discuss -> spec (/shape-spec) -> roadmap. Don't build until an explicit go.
+- [Syncro preview mandatory](feedback_syncro_preview_mandatory.md) — preview+confirm every Syncro write, including internal notes
+- [Refresh session history first](feedback_refresh_session_history_first.md) — read prior incident logs before acting; do not re-remediate already-handled accounts
+- [Autonomy scope](feedback_autonomy_scope.md) — confirm only for client-affecting actions; internal docs/wiki/ClaudeTools = act autonomously

.claude/memory/feedback_autonomy_scope.md

@@ -0,0 +1,12 @@
+---
+name: feedback_autonomy_scope
+description: Confirm-before-acting applies ONLY to client-affecting actions; internal docs/wiki/memory/ClaudeTools are trusted — act autonomously.
+metadata:
+  type: feedback
+---
+
+The "preview / ask before acting" discipline is scoped to actions that **affect a client directly** — Syncro writes (tickets/comments/billing), customer emails, and changes to a client's M365/infra (password resets, session revokes, MFA/CA changes, domain blocks, mailbox changes). Those get a payload preview + Mike's explicit confirmation.
+
+**Internal documentation and anything within ClaudeTools — wiki articles, memory, session logs, repo housekeeping, consolidating/redirecting wiki pages — is trusted: just do it, no asking.** Mike (2026-06-09): "The ask before is only for things that will affect a client directly. I trust you to manage internal documentation and within claudetools."
+
+**Why:** asking permission for internal repo/wiki edits is friction with no upside; the guardrail exists for irreversible client-facing actions. See [[feedback_syncro_preview_mandatory]] and [[feedback_refresh_session_history_first]] (those remain correct — they're about client-facing writes).

.claude/memory/feedback_refresh_session_history_first.md

@@ -0,0 +1,12 @@
+---
+name: feedback_refresh_session_history_first
+description: Before touching an in-flight client incident, read the existing session logs/reports first; never re-remediate an account without checking it wasn't already handled.
+metadata:
+  type: feedback
+---
+
+When picking up an in-flight client incident (especially one worked across multiple/concurrent sessions), **grep + read `clients/<slug>/session-logs/` and `clients/<slug>/reports/` FIRST**, before investigating the live tenant. This session's context does NOT carry other sessions' work.
+
+**Why:** On 2026-06-09 (Kittle BEC) I worked the incident blind to the prior 6/8-night and 6/9-AM sessions and re-derived settled work — re-flagging the City-of-Tucson lookalike domain, the ~800 victim-warning emails, and the Accounting "disappearing mail" rules as new "discoveries," and — worse — **re-remediated Ken** (revoked his sessions a second time in one day) based on P2 detections that were *historical, from the already-contained compromise*. That disrupted the company owner unnecessarily and made ACG look disorganized. Mike: "Did you forget half of the work you did? ... That makes me look bad."
+
+**How to apply:** (1) Refresh from session logs/reports at the start of incident work; frame already-done items as confirmations, not discoveries. (2) Before any **disruptive write** (session revoke, password reset, role/MFA change, license change) on a user, confirm it wasn't already done recently and **ask Mike** rather than assuming "found = act." Pair with [[feedback_syncro_preview_mandatory]].

.claude/memory/feedback_syncro_preview_mandatory.md

@@ -0,0 +1,12 @@
+---
+name: feedback_syncro_preview_mandatory
+description: Every Syncro write needs a payload preview + explicit confirmation BEFORE posting — including hidden/internal notes.
+metadata:
+  type: feedback
+---
+
+Before ANY Syncro POST (ticket, comment, line item, invoice) — **including `hidden:true` / `do_not_email:true` internal notes** — show Mike the full payload and wait for explicit confirmation. Do NOT post-then-report.
+
+**Why:** Syncro comments cannot be edited or deleted via API; a wrong/redundant/alarmist note becomes permanent client-record. The preview gate is the only chance to catch it. On 2026-06-09 (Kittle BEC) I bypassed the preview on most running internal notes and posted directly — one of them re-framed an already-remediated account ("Ken also compromised") as a fresh event, which then couldn't be undone. Mike: "you bypassed the mandatory preview and posted that syncro note without any oversight."
+
+**How to apply:** Treat the `/syncro` skill's "show the full payload and wait for explicit confirmation" rule as absolute — no internal-note exception, no "I'll just log this quickly." Draft → show → wait for yes → post. See [[feedback_refresh_session_history_first]].