sync: auto-sync from GURU-5070 at 2026-06-12 17:44:04

Author: Mike Swanson Machine: GURU-5070 Timestamp: 2026-06-12 17:44:04
2026-06-12 17:44:19 -07:00
parent aebf307a81
commit ac3dbbbec9
2 changed files with 35 additions and 2 deletions
--- a/.claude/memory/MEMORY.md
+++ b/.claude/memory/MEMORY.md
@@ -75,6 +75,7 @@
 - [Memory tooling may delete now — additive-only constraint dropped](feedback_memory_sync_destructive_ok.md) — As of 2026-06-02, memory-dream and sync-memory.sh are sanctioned to perform destructive ops (apply proposed merges/dedups, propagate repo deletions back to harness profile stores). Onboarding-phase safety net now fights deliberate consolidation (e.g. 2026-06-01's 39 deletions resurrected on the next sync). Script updates pending.
 - [Unsaved sessions are recoverable from transcripts](feedback_session_recovery.md) — Crashed/closed-before-save sessions live in `~/.claude/projects/<slug>/*.jsonl`; the detector auto-recovers orphans, `/recover <uuid>` does it manually. Ollama prose + Python verbatim. See `.claude/RECOVERY.md`.
 - [agy review is not read-only](feedback_agy_review_not_readonly.md) — agy review/review-files CAN write files + run npm despite docs claiming plan-mode; always git diff after and treat Gemini's output as a proposal to validate, not trusted/finished work.
 - [Don't present inferred topology as fact](feedback_no_inferred_topology_as_fact.md) — Private-IP overlap (172.16.x on both sides) is NOT proof of a site-to-site link; I fabricated a VWP<->office VPN. State observations vs inferences; a failed reachability test disproves a link, don't explain it away; test "can reach RMM" against the EXTERNAL endpoint, not internal 172.16.3.30.
 ### Syncro
 - [Syncro API plumbing](feedback_syncro_api.md) — Content-Type required on all POST/PUT; NO idempotency anywhere — always GET before retrying; response wrappers (`.ticket.id`, `.comment.id`); add_line_item shape (internal ID, flat response, required fields); HTML uses `<br>` not `<ul>/<li>`; timer_entry response is FLAT but SUPERSEDED (use add_line_item).
@@ -134,5 +135,5 @@
 - [Beast = primary GuruRMM Windows build host](gururmm-beast-windows-build-host.md) — GURU-BEAST-ROG (i9), reached from .30 via Tailscale-on-.30 at 100.101.122.4 as guru; Pluto is the fallback (`attempt_build beast || attempt_build pluto`). WiX must be 4.x (v6+ = OSMF); Beast NuGet needed nuget.org added
 - [GuruRMM command_type gotcha](reference_gururmm_command_type.md) — only shell/powershell/python/script/claude_task (+cmd alias); unknown type silently dropped, looks like a black-hole
 - [GuruRMM log analysis -> Claude Haiku](gururmm-log-analysis-claude-cutover.md) — cut over from Ollama-on-Beast (timed out on fleet-sized prompts; "unreachable" was a mislabeled 120s timeout) to Anthropic API Haiku 4.5 w/ structured outputs; key at vault `projects/gururmm/anthropic-api`; ZDR pending; deploy needs root on .30 (.env + restart)
- [IX WHM API access = 'ClaudeTools' token, not password](ix-whm-dns-api-access.md) — IX cPanel/WHM (ix.azcomputerguru.com:2087) DNS + all API work uses the FULL-ACCESS-root WHM API token at vault `infrastructure/ix-server` `credentials.whm-api-token` via header `Authorization: whm root:<token>` (force curl -4). Password basic-auth on legacy json-api now 403s. Public NS ns1/ns2.acghosting.com = 52.52.94.202.
+- [IX WHM API access = 'ClaudeTools' token, not password](ix-whm-dns-api-access.md) — IX cPanel/WHM (ix.azcomputerguru.com:2087) DNS + all API work uses the FULL-ACCESS-root WHM API token at vault `infrastructure/ix-server` `credentials.whm-api-token` via header `Authorization: whm root:<token>` (force curl -4). Password basic-auth on legacy json-api now 403s. Public NS ns1/ns2.acghosting.com = 52.52.94.202.
- [Vault EVERY credential surfaced in-session](feedback-vault-every-credential.md) — any cred (pasted/created/discovered) -> store via the vault skill + document purpose & exact usage immediately; it's a standing job rule (reinforced in CORE CLAUDE.md). Lost IX creds wasted ~1h on 2026-06-12.
+- [Vault EVERY credential surfaced in-session](feedback-vault-every-credential.md) — any cred (pasted/created/discovered) -> store via the vault skill + document purpose & exact usage immediately; it's a standing job rule (reinforced in CORE CLAUDE.md). Lost IX creds wasted ~1h on 2026-06-12.
--- a/.claude/memory/feedback_no_inferred_topology_as_fact.md
+++ b/.claude/memory/feedback_no_inferred_topology_as_fact.md
@@ -0,0 +1,32 @@
 ---
 name: feedback_no_inferred_topology_as_fact
 description: Never present an inferred network link as an observed fact; private-IP overlap is not evidence of a shared fabric, and a failed reachability test disproves a link rather than needing to be explained away.
 metadata:
  type: feedback
 ---
 On 2026-06-12, investigating VWP-ROSE (Valley Wide Plastering), I concluded Valley
 Wide was "Local" to the ACG office via a site-to-site VPN. Mike: there is NO
 site-to-site between VWP and the office. I had fabricated the link.
 **Why it was wrong:**
 - I asserted "VWP-ROSE reached the office RMM server (172.16.3.30) by its real
  private IP with no NAT" — I never observed that. Field agents connect to
  `rmm-api.azcomputerguru.com` (PUBLIC IP), like ~199/200 of the fleet. `172.16.3.30`
  is only *my* office-side base URL; the agent never uses it.
 - I read a `172.16.x` overlap (office `172.16.3.x` vs VWP `172.16.9.x`) as a shared
  fabric. It is coincidence — `172.16.0.0/12` is RFC1918 space countless unrelated
  LANs reuse. Overlapping private ranges prove nothing.
 - My own test (force `172.16.3.30` over the corp NIC) FAILED — that disproved the
  link. I rationalized it as "asymmetric routing" to preserve my conclusion.
 **How to apply:**
 - State only what was observed; label inferences as inferences. Never narrate an
  unobserved packet/path as if it happened.
 - Private-IP overlap is NOT evidence two networks are connected. Require positive
  proof (a tunnel config, a successful end-to-end reach with the real source IP).
 - When a test contradicts the hypothesis, update the hypothesis — do not invent a
  mechanism to dismiss the failure.
 - To test "can this adapter reach RMM," use the EXTERNAL endpoint
  (`rmm-api.azcomputerguru.com` / its public IP), not the internal `172.16.3.30`.
  Nearly every agent is external. See [[reference_gururmm]].