Updates guru-rmm submodule pointer to include the audit report
(reports/2026-05-19-rmm-audit.md) and updated UI_GAPS.md living doc
from the /rmm-audit skill run.
Note: .claude/CLAUDE.md (/rmm-audit command row) and
.claude/skills/rmm-audit/SKILL.md were committed in the prior
sync at 5ead5d4.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
5-pass audit: API/route inventory, UI gap detection, Rust quality, TypeScript
quality, and data integrity/security. Produces timestamped reports in
projects/msp-tools/guru-rmm/reports/ and keeps UI_GAPS.md current.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Cloud-only M365 user created, SPB license assigned, SSPR group added,
CA/MFA audit, Syncro billing for tickets #109316879 and #110120097.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The UserPromptSubmit hook requires .claude/current-mode to determine work mode
and gate coordination lock checks. This file is machine-local (gitignored) but
had no initialization logic for fresh clones, causing hooks to fail.
Changes:
- check-messages.sh: Added auto-creation logic with "general" as default
- CLAUDE.md: Documented auto-initialization behavior
- ONBOARDING.md: Added machine-local configuration section
- session-logs/2026-05-19-session.md: Documented investigation and fix
Impact:
- Fixes coordination hooks on all machines
- Prevents first-clone hook failures
- No manual setup required
- Backwards compatible
Resolves: "cood hook seems to be broken on all my machines"
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Investigated auto-update system and agent deployment status
- Verified 35 agents (70%) already on v0.6.22 with process collection
- Confirmed process data collection and API functionality working
- Feature is fully operational in production for all v0.6.22 agents
- 15 offline agents will auto-update when they reconnect
- Updated guru-rmm submodule reference to commit 55e8a86
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Cascades of Tucson — created 4 new caregiver accounts, Alma Montt admin account,
terminated Niel Castro, reclassified Celia Lassey and Patricia Sandoval-Beck from
SG-Caregivers. Entra sync run; Alma Montt M365 license pending background task.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Added MSP360 Managed Backup Service API credentials to SOPS vault.
Session work:
- Created temporary file for user to input API credentials
- Generated SOPS-encrypted vault entry at msp-tools/msp360-api.sops.yaml
- Verified decryption with vault wrapper script
- Committed and pushed to vault repository (5e8cb0b)
- Deleted temporary unencrypted file
Credentials stored for GuruRMM MSPBackups integration (P2 priority):
- API Login and Password for MSP360 authentication
- Bearer token flow documented
- Monitoring endpoint available for backup status polling
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Diagnosed and resolved ClaudeTools sync issues on Mac. Network connectivity
to internal Gitea server (172.16.3.20:3000) was working but slow through
Tailscale relay after office power failure recovery. Resolved submodule
conflict during rebase and successfully synced repository.
- Comprehensive network diagnostics (Tailscale, routing, connectivity)
- Manual submodule conflict resolution (guru-rmm reference)
- Context recovery from recent PC sessions (power failure recovery, GuruRMM dev)
- Directives refresh confirmed
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Comprehensive session log covering today's work on the Valley Wide
Plastering app modernization project. Recovered Darv's VB6 source from
a set of backup rotation drives, including the production Orders_10A.exe
from the 97-Server\VWP2\ iteration workspace. Resolved the 4-year gap
question: no .vbp source newer than 2020-06-09 exists on any of the
three rotation drives; Darv worked in rename-and-try on the compiled
EXE only from 2021 onward.
Includes quick-resume instructions for tomorrow when the next drive is
connected.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drive 3 yielded the biggest finds in the project so far.
VHDX mount + scan (D:\WIN7-Orders\Darv-2\VWP1.VHDX, 117 GB Hyper-V disk):
- Mounted read-only as F:, scanned in 85s, dismounted
- NOT Darv's dev box - it's the office "owner" admin workstation
- No newer source code found inside, but:
- Vwp11.mdb (2023-07-27, 369 MB) - NEWEST DB snapshot anywhere
- Vwp.mdb (2022-12-23, 769 MB) - on Desktop\Darv VWP
- Orders Versions/ desktop folder with 2 EXEs + 7 shortcuts
- The .lnk shortcuts all pointed to G:\VWP2\Orders*.exe - the
"Aha!" that revealed where Darv's iteration happened
- Saved to source-code/from-VHDX-VWP1/
The VWP2 grab (D:\97-Server-G-Drive\g$ 2024-04-10\VWP2\):
- This is Darv's actual iteration workspace on the production
Orders server (G: drive)
- 16.36 GB total, 1,061 files. Grabbed 886 files (~893 MB) filtered to
*.exe, *.rpt, *.ocx, and VB6 source extensions:
- 64 Orders*.exe versions - complete iteration history (includes the
production Orders_10A.exe + Orders_10Z.exe variant + dozens more
with Darv's "iterate-and-rename" naming pattern)
- 820 Crystal Reports (.rpt)
- 2 .ocx supporting controls
- Skipped 23 historical .mdb backups (15.8 GB) - we already have
newer snapshots from 000_ASource and VHDX
- Skipped 6 large subfolders (HOLD, HHOLD, Pay_2021_0325, GWAC,
20220205, 20211010 RPT) - mostly more MDBs
- Saved to source-code/from-VWP2-97server/
What we learned about the 4-year gap:
- No source code newer than 2020-06-09 ORDERS_C.vbp baseline found
on any of the three rotation drives
- The 64 EXE versions in VWP2 go through 2022 - Darv was iterating
and rebuilding compiled output but not updating his .vbp source
control. This is consistent with his "rename and try" workflow
- The production exe (Orders_10A.exe) is in this batch - now we can
use VB Decompiler Pro on it without needing the original drive
Helper scripts:
- scan_vhdx.ps1 - fast PowerShell scan of a mounted VHDX for source/DB
- find_vwp2.py - cross-CSV search for the VWP2 path
- vwp2_summary.py - size+type breakdown of the VWP2 folder
- debug_vwp2.py - one-off debug helper
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drive 3 (12 TB, 11.99 TB used, only 43 GB free) — third VWP backup
rotation drive. Per Mike, all three drives are rotation copies; content
largely overlaps.
Net-new content vs drives 1 and 2:
- D:\WIN7-Orders\Darv-2\VWP1.VHDX (117 GB, 2023-09-01) — Hyper-V disk
named "VWP1" in a Darv-2 folder. Likely Darv's later workstation.
Strongest candidate for finding any 2021-2023 source code that
postdates our 2020-06-09 ORDERS_C.vbp baseline. Not copied.
- D:\WIN7-Orders\WindowsImageBackup\VWIN7-PC\...vhd (22 GB) — Windows
Image Backup of the VWIN7-PC machine, dated 2023-08-31.
- D:\VWP-FIN\ (~44 GB) — Finance machine backups + RAR archives. Not
relevant to Orders modernization but useful for QuickBooks context.
SourceSafe search:
- 1224 SourceSafe-related matches but ALL are Visual Studio install
directories (Microsoft Visual Studio\Common\VSS\) and .SCC sentinel
files. No srcsafe.ini (actual repository) anywhere on this drive.
The SourceSafe repo is on a different drive (likely Darv's personal
drive, not in the office rotation).
Source code:
- No .vbp newer than 2020-06-09 baseline. Same TEST_VWP.vbp scaffold
from drive 2 (2021-08-16, 810 bytes) present here too.
Updated .gitignore: added *.vhd (was missing — only had *.vhdx).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drive 2 (label "Backup", 12 TB, 6.77 TB used) — second of N VWP
backup drives. Scanned via WizTree, analyzed with analyze_wiztree.py.
NEW source content:
- 000_ASource/ — Darv's active work-in-progress folder. Contains
TEST_VWP.vbp (2021-08-16, only .vbp newer than the 2020-06-09 baseline),
four frmLotInfo*.frm variants (2020-10 to 2021-08), and an
MSSCCPRJ.SCC file confirming Darv used Visual SourceSafe.
- The accompanying Vwp.mdb (2022-10-19, 764 MB) stays on local disk
per .gitignore — newest database snapshot we have.
Analysis CSVs:
- source-analysis/drive2-2026-05-16/ — per-category + per-keyword
breakdown of drive 2's 3.95M files (vs drive 1's 1.87M). Categories
largely match drive 1 but with ~2x volume.
Net findings vs drive 1:
- Confirmed 4-year gap: only 4 .vbp files newer than 2020-06-09 on
drive 2, all the same TEST_VWP.vbp scaffold. Main ORDERS_C.vbp source
remains 2020-06-09. Darv stopped active VB6 dev around mid-2020.
- 43 GB Win7 Backup-and-Restore set in D:\Archive\Darv-Win7-PC\ (2023)
not copied — deferred to later drives, ZIPs extractable on demand.
- Master Darv folder is bit-for-bit duplicate of drive 1's master (135 GB,
same file/folder counts). Skipped.
New helper scripts:
- find_newer_vbp.py — list .vbp files newer than a date, filter SDK noise
- drive2_inspect.py / drive2_priorities.py — drive-specific triage
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Recovered Darv's VB6 source for the Valley Wide Plastering Orders
application from the D: backup drive (label "Backup", 8 TB, 5.3 TB used).
This is the first time we've had the actual source — prior session only
had a single frmPayroll.frm from the AD server.
Three project variants identified across two snapshots:
- Full-Project/ (2,129 files, 124 MB) — D:\Office-Estimates\Darv\Full\Project\
- Kingston-Project/ (2,189 files, 130 MB) — D:\Office-Estimates\Darv\Kingston\Project\
- Source/ (170 files, 559 MB) — D:\Office-Estimates\Darv\Source\ wholesale
- SOURCE-HOLD/ (3 files, 1 MB) — D:\Office-Estimates\Darv\SOURCE HOLD\
Latest ORDERS_C.vbp date is 2020-06-09 (Kingston snapshot). Production
Orders_10A.exe was live as of April 2024 — open question whether newer
source exists on other backup drives Mike will scan next.
Also includes per-category and per-keyword analysis CSVs from a WizTree
file-list export, plus the analyzer script that produced them
(re-runnable for the next drive's CSV).
VMs (VWIN7-DW.vdi 8.3 GB + XP-for-ORDERS_copy.vdi 2.8 GB), the live
VWP.mdb, and the 393 MB raw WizTree CSV stay on disk only — gitignored.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tmp_qwen_reason.py, tmp_qwen_test.py, tmp_qwen_test2.py — additional
local qwen test scratch from today's benchmarking work. The routing
decisions live in OLLAMA.md; the throwaway scripts don't need to ship.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Removes tmp_bench_8b.py, tmp_hw_check.ps1, and tmp_ollama_bench.py
from DESKTOP-0O8A1RL's qwen3:8b benchmark. The routing decisions and
numbers are captured in OLLAMA.md; the scripts were one-off scratch
work and don't need to live in the repo.
Untracked counterparts on GURU-BEAST-ROG (benchmark_qwen_3_6.py,
rescore_qwen.py, qwen-benchmark-2026-05-16.{md,json}) were also
removed locally.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The qwen3:8b routing update inserted footnote lines mid-table in both
the "What Ollama owns" and "When to Use Which Model" sections, splitting
each table in half so renderers treated the qwen3.6 rows as paragraph
text. Moved footnotes below the closing table row in both places.
Also updated the bottom "Rule of thumb" line: previously named qwen3:14b
with a "2x faster" claim that's now stale on DESKTOP-0O8A1RL where 8b is
the prose model. Generalized to "the per-machine prose model".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Benchmarked qwen3.6 (36B MoE) vs qwen3:14b and qwen3:32b on 16
representative prompts. qwen3.6 scored 15/16 vs 14b 11/16 and 32b
12/16, winning every strict-format/adherence test (multi-step rules,
weekend-aware scheduling, prompt-injection resistance, word-limit
summary). Single reasoning regression noted for re-check at qwen3.7.
Updated .claude/OLLAMA.md (Models, Documentation Engine, and
When-to-Use tables) and .claude/CLAUDE.md one-line model summary to
route strict-format work to qwen3.6 and keep bulk prose on qwen3:14b
(2x faster). Also removed openclaw npm package + ~/.openclaw data dir
earlier in the session.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
