The skill/command DOCS instructed Claude to run a bare `py ...`, which is the
Windows py-launcher — absent on Linux/macOS (exit 127, hit on GURU-KALI). A blind
py->python3 swap is wrong too: python3 is a broken MS Store shim on some Windows
boxes where `py` is the correct launcher.
Fix mirrors the resolution the .sh skill scripts already do:
- New .claude/scripts/py.sh: picks the interpreter that actually RUNS —
identity.json python.command first, then py -> python3 -> python, each
validated with `-c 'import sys'` so the MS Store stub is skipped. exec's it.
- Repointed all DOC invocations (10 files, ~70 sites) from `py ...` to
`bash "$CLAUDETOOLS_ROOT/.claude/scripts/py.sh" ...` (incl. the `py -c` and
`py -` heredoc forms in checkpoint.md / mailbox.md).
- Left the .sh skill scripts untouched — they already resolve py/python/python3.
- errorlog.md: marked the GURU-KALI entry RESOLVED.
Depends on CLAUDETOOLS_ROOT (seeded by ensure-settings-env.py); py.sh also
self-resolves the repo root via git/cwd as a fallback.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Triggered by ~1h lost on 2026-06-12 when the IX WHM access method was forgotten and
password auth no longer worked. CLAUDE.md Key rules now mandates vaulting via the vault
skill + thorough documentation for any credential surfaced in a session.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Phase 2a used `customers?name=` which is near-exact and missed slug/name spelling
mismatches — e.g. slug gonzvar-tax-services vs Syncro "Gonzvar Tax Service"
(singular), causing a false "not in Syncro". Switch to `query=` (fuzzy) with a
fallback ladder (first word, then de-pluralized token) before concluding not-found.
- guruconnect: seeded wiki/projects/guruconnect.md (v0.3.0 production; artifact-based
from guru-connect repo @ origin/main ded99c5 + session logs + project_guruconnect
memory). [[guruconnect]] backlinks now resolve. Indexed.
- gonzvar-tax-services: found in Syncro via fuzzy `query=` — customer is "Gonzvar Tax
Service" (singular), id 1830740, break-fix/~$175hr, 6 assets. Billing fields corrected.
- tucson-golden-corral: email platform set to Neptune Exchange (per owner/Mike); IX
cPanel kept as a caveat to reconcile. TGC-SERVER documented as colocated at ACG main
office (behind ACG office network, not a naked public box at the restaurant).
Inventory NUL/jsonb reject (7 Windows agents) + update scanner dropping
non-Windows binaries (macOS/Linux agents never offered updates). Both
ROOT-CAUSED from the 2026-06-12 fleet log-analysis reconciliation.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Seeded via /wiki-compile (parallel sub-agents):
- clients: gonzvar-tax-services, tohono-oodham-doit (Syncro 33069069),
tucson-golden-corral (Syncro 3859123)
- projects: gururmm-agent (artifact-based, agent/ @ origin/main), msp-tools (umbrella)
Index rows added for all five. Deduped the duplicate system:neptune compile-queue
entry (merged the cert/DkimSigner note into one).
Left as-is (intentional, not duplicates/dead): wiki/projects/guru-rmm.md is a
redirect tombstone; the patterns/tailscale-client-enroll.ps1 index link is valid
(the .ps1 script exists).
internal-infrastructure.md inventory + backlink still called .30 a "GuruRMM VM /
Linux VM on Jupiter" and Pluto the MSI build server; pluto.md backlink still said
Pluto was the "exclusive" build machine. Both corrected: .30 is a physical box,
Beast primary / Pluto fallback. Found by /wiki-lint.
Two sweeps:
1. .30 is a PHYSICAL box (Lenovo ThinkCentre M83, Ubuntu 26.04), not a Jupiter
VM — the VM was decommissioned 2026-06-12. Fixed inventory tables and the
gururmm-build system page (overview, index, jupiter, gururmm-build,
POWER_FAILURE_RUNBOOK).
2. Windows build chain: Beast (GURU-BEAST-ROG, tailnet 100.101.122.4, i9-14900K)
is PRIMARY; Pluto (172.16.3.36) is FALLBACK. Verified against build-windows.sh
(`attempt_build beast || attempt_build pluto`). Fixed overview, index,
projects/gururmm (build-host table + flow + host detail), systems/pluto, and
the reference_pluto_build_server memory.
Submodule advanced: build-pipeline doc comments corrected to match.
- .gitignore: ignore root tmp/ (temp/ and .claude/tmp/ were already ignored;
root tmp/ was not, which is how scratch got committed and needed cleanup).
- New .claude/scripts/tmp-promotion-check.sh: advisory, read-only, never blocks.
Scans the gitignored scratch dirs (tmp/, temp/, .claude/tmp/) and flags files
worth graduating (scripts, substantial docs, session-log-referenced) before
they're lost to cleanup. Silent when scratch is empty.
- /save (Phase 4) and /scc (new step 2) run the check before sync.sh, pointing
at .claude/TEMP_GRADUATION.md for the graduate-vs-delete decision.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Removed 44 scratch files that got committed into the tracked root tmp/
(grok/gemini second-opinion rounds r1-r7, rmm-diag-* dumps, ns*.out
captures, and throwaway helpers jssh.py/addnpmnat.php/delnpmnat.php/
cleanup.sh/fix_ws_agent.py) — all from the resolved RMM command_type
'cmd' investigation, already captured in session logs + the gururmm wiki.
Graduated the three non-scratch artifacts per TEMP_GRADUATION.md:
- tmp/site-scan.sh -> scripts/cpanel-wp-site-scan.sh (+ header)
- tmp/ix-site-audit.md -> clients/internal-infrastructure/reports/2026-03-16-ix-server-cpanel-wp-audit.md
- tmp/ix-scan-results.txt -> clients/internal-infrastructure/reports/2026-03-16-ix-server-scan-results.txt
tmp/ is now empty.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
