claudetools/session-logs/2026-05-29-session.md

# Session Log — 2026-05-29

## User
- **User:** Mike Swanson (mike)
- **Machine:** GURU-5070
- **Role:** admin

## Session Summary

Shaped a pre-implementation spec for native integrated remote control in the GuruRMM ecosystem, then restructured how the guru-connect product is tracked in the monorepo. The session began as a "fix lint errors" request that was redirected into a GuruRMM feature request for the guru-connect (GC) project: native, integrated remote control comparable to ScreenConnect/Splashtop, built entirely on our own Rust stack to avoid third-party agents and supply-chain exposure.

Research established that GC already implements the full remote-control engine (DXGI/GDI capture, input injection, viewer, `guruconnect://` protocol handler, persistent/unattended + support-code/attended modes, protobuf over WSS) and that GuruRMM already has the orchestration rails (per-agent command dispatch, stable `device_id` identity, the AgentDetail action-button pattern, and a half-built generic `tunnel` scaffold). Two parallel Explore agents mapped the exact integration surfaces with file:line references. The feature is therefore ~80% wiring against existing capability, not greenfield. Architecture decisions were captured via the user: broker model (RMM orchestrates the separate GC agent), both unattended and attended access, multi-monitor in scope, file transfer / session recording / non-Windows agents out of scope, priority P2.

The `/shape-spec` skill produced four files in `projects/msp-tools/guru-connect/specs/native-remote-control/` (shape, plan, references, standards). The user then clarified that GC is a standalone product with its own pipeline/cadence, and the real intent is a durable, versioned integration contract so the two products stay integration-compatible without coupling. The spec was rewritten around a GC-owned, semver'd integration contract (`/api/integration/v1/`, capability discovery, embedded session viewer). A concrete blocker was identified: GC's `security_headers.rs` sets `frame-ancestors 'none'`, which must be relaxed to a scoped RMM-origin allowlist for the embedded viewer. RMM-side hints were added (ADR-008 + `docs/GURU_CONNECT_INTEGRATION.md`) recording that RMM consumes GC via the contract and does no active dev on GC. The spec and hints were committed across both repos (commit-only, no push).

The user then asked to wire GC as a submodule like guru-rmm. Investigation revealed the remote `azcomputerguru/guru-connect` repo was ~4 months stale (frozen 2026-01-18) while the local monorepo copy was far ahead (entire `middleware`/`metrics`/`utils` modules, token blacklist, Phase-1 security/deploy work, the new spec). Per the user's decisions (publish local to the existing repo as a snapshot commit; preserve history), the Gitea Agent published the local working state to GC main (fast-forward `5b7cf5f..e3e95f8`, history preserved, KEEP paths `.gitignore`/`.cargo`/`server/static/downloads` retained), then converted the vendored directory into a submodule pinned at `e3e95f8`. Confirmed that GC `deploy.yml` triggers only on `v*.*.*` tags / manual dispatch, so the push ran CI build/test but did not deploy to production.

Finally, the user confirmed RMM and GC are the only versionable products; everything else stays in the monorepo. This policy was recorded to memory (`project_versionable_products.md`).

## Key Decisions

- Broker architecture: RMM orchestrates the separate GC agent (two agents coexist) rather than merging GC into the RMM agent — reuses GC's existing engine, ships sooner, keeps GC standalone.
- The deliverable is a GC-owned, semver'd integration contract + capability discovery, not one-off broker wiring — so the two products stay in-sync via the contract without sharing pipelines or releasing in lockstep.
- Stable cross-product identity = RMM `device_id` passed as the GC `agent_id`, so brokered sessions deterministically match the endpoint.
- Supply-chain guard made concrete: the RMM agent downloads the GC binary only from GC's release channel and verifies SHA-256 before launch (reusing GC's `releases.checksum_sha256`).
- Embedded viewer over native-only: relax `frame-ancestors`/`X-Frame-Options` on the viewer route to a scoped RMM-origin allowlist; keep `'none'` everywhere else.
- Spec lives in the GC repo (GC owns the contract); RMM gets ADR-008 + a pointer doc reminding it not to perform active dev on GC.
- Submodule reconciliation: publish the local (authoritative) state up to the stale GC repo as a snapshot commit on top of existing main (preserve history), then submodule-add — nothing lost.
- Only GuruRMM and GuruConnect are versionable products (own repos/submodules); all other projects stay in the claudetools monorepo. Split only for an independent pipeline OR a versioned external consumer.
- All git operations committed but NOT pushed (claudetools), per the established pattern of leaving the push to the user; the GC repo push was mandatory for the submodule to resolve.

## Problems Encountered

- Initial "fix lint errors" request was ambiguous (clean tree, multiple lintable projects). Asked which project; user redirected to the GC feature request instead.
- CLAUDE.md warns that a Gitea repo named `guru-connect` is an "abandoned duplicate." Verified by inspecting the remote repo's contents (`proto/guruconnect.proto`, `agent/`, `server/`, `dashboard/`) that `azcomputerguru/guru-connect` is the real GC product, not the abandoned RMM duplicate the warning refers to.
- The remote GC repo was 4 months stale and the local monorepo copy had diverged substantially (whole modules + Phase-1 work never pushed). A naive `submodule add` would have reverted that work. Resolved by diffing local vs remote, surfacing the divergence, and publishing local→remote before converting.
- Production-deploy risk on push: checked GC's `.gitea/workflows`; confirmed `deploy.yml` triggers only on `v*.*.*` tags / `workflow_dispatch`, so pushing to main runs CI but does not deploy.

## Configuration Changes

Created (committed `afbe5a8`, then moved into the GC repo via the submodule conversion):
- `projects/msp-tools/guru-connect/specs/native-remote-control/shape.md`
- `projects/msp-tools/guru-connect/specs/native-remote-control/plan.md`
- `projects/msp-tools/guru-connect/specs/native-remote-control/references.md`
- `projects/msp-tools/guru-connect/specs/native-remote-control/standards.md`

guru-rmm submodule (committed `7701d26` in the submodule):
- Modified `docs/ARCHITECTURE_DECISIONS.md` — added ADR-008 (GC is a separate product consumed via versioned contract)
- Created `docs/GURU_CONNECT_INTEGRATION.md` — RMM-side boundary/pointer doc

Repo structure:
- `.gitmodules` — added `projects/msp-tools/guru-connect` submodule entry (branch main)
- `projects/msp-tools/guru-connect` — converted from vendored directory to submodule (gitlink mode 160000 at `e3e95f8`)

Memory:
- Created `.claude/memory/project_versionable_products.md`
- Updated `.claude/memory/MEMORY.md` index (Project section)

## Credentials & Secrets

None discovered or created this session. The spec references secrets to be sourced from env/SOPS at implementation time (`CONNECT_INTEGRATION_KEY`, `CONNECT_SERVER_URL`, per-machine GC agent keys, `CONNECT_EMBED_ALLOWED_ORIGINS`) — none provisioned yet.

## Infrastructure & Servers

- Gitea (internal): http://172.16.3.20:3000 — used for repo inspection + GC push (per internal-API preference)
- GC relay server: 172.16.3.30:3002, proxied via NPM to connect.azcomputerguru.com
- GuruRMM server: 172.16.3.30:3001, dashboard rmm.azcomputerguru.com
- GC repo CI: `.gitea/workflows/{build-and-test,test,deploy}.yml` — deploy only on `v*.*.*` tags / manual dispatch

## Commands & Outputs

Repo divergence check (local vs remote GC), shallow clone + `diff -rq` — confirmed local far ahead; cleaned up temp clone afterward.

GC publish (Gitea Agent):
- `git push origin main` → `5b7cf5f..e3e95f8  main -> main` (fast-forward, 73 files changed, 15611 insertions, 5760 deletions; `Cargo.lock` dropped — not tracked in the authoritative copy)

Submodule conversion (Gitea Agent):
- `git rm -r --cached projects/msp-tools/guru-connect` + `rm -rf` + `git submodule add -b main <url>`
- `git submodule status` → `e3e95f8 ... guru-connect (heads/main)`, `7701d26 ... guru-rmm (heads/main)`

## Pending / Incomplete Tasks

- claudetools commits are LOCAL, not pushed: `53e14da` (submodule conversion) + `1fc2401`/`afbe5a8` (spec + pointer bump) from earlier. Push when ready.
- GC repo housekeeping: re-add `Cargo.lock` (dropped in the snapshot; wanted for reproducible builds).
- GC submodule URL uses the internal IP `172.16.3.20:3000`; guru-rmm uses the public `git.azcomputerguru.com`. Off-network clones (Howard's Mac) won't resolve the internal IP — consider switching to the public hostname for parity.
- GC CI run kicked off by the publish push may be red (the snapshot may not build cleanly; Cargo.lock removed). Check the Actions run.
- Implementation of the feature itself has not started — Task 0 of the spec (commit the spec) is effectively satisfied; Tasks 1+ are not begun.

## Reference Information

- Spec: `projects/msp-tools/guru-connect/specs/native-remote-control/` (4 files) — now in the GC repo at `e3e95f8`
- ADR: `projects/msp-tools/guru-rmm/docs/ARCHITECTURE_DECISIONS.md` ADR-008
- RMM pointer: `projects/msp-tools/guru-rmm/docs/GURU_CONNECT_INTEGRATION.md`
- GC repo: `azcomputerguru/guru-connect`; published `5b7cf5f → e3e95f8`
- guru-rmm submodule commit: `7701d26`
- claudetools commits: `afbe5a8` (spec), `1fc2401` (submodule ptr bump for ADR), `53e14da` (GC submodule conversion)
- Roadmap context: `projects/msp-tools/guru-rmm/docs/FEATURE_ROADMAP.md:635-675`, `docs/UI_GAPS.md:155-186`
- Key GC integration files: `server/src/middleware/security_headers.rs:30,37-39` (frame-ancestors), `server/static/viewer.html`, `server/src/relay/mod.rs:187` (agent key validation), `server/src/main.rs:300` (`/api/version`)
- Key RMM files: `server/src/api/commands.rs:87-157` (command dispatch), `agent/src/device_id.rs`, `dashboard/src/pages/AgentDetail.tsx:1893-1931`

---

## Update: 17:52 PT — GuruConnect operational tooling + Pluto native CI build (green)

### Session Summary

Brought GuruConnect to operational parity with GuruRMM and stood up native Windows CI on Pluto.
Established GC's `docs/` (FEATURE_ROADMAP, ARCHITECTURE_DECISIONS ADR-001/002, SPEC-001, CHANGELOG),
added the `/gc-feature-request` skill, and registered the `guruconnect` coord project_key. Built CI
in Gitea Actions: conventional-commit auto-versioning, git-cliff changelog + `/api/changelog`
endpoint, and Azure Trusted Signing (jsign, reusing RMM's cert profile) on a workflow_dispatch-gated
release. Decisions: modernize in Gitea Actions (not RMM's webhook/script model), reuse RMM's exact
Trusted Signing cert profile, leave RMM's own pipeline untouched (its beta→stable promotion already
provides release control — better than tag-gating).

Native Windows agent build: rather than mingw cross-compile, provisioned Pluto (Unraid VM
"Claude-Builder", hostname PLUTO, 172.16.3.36) as a Gitea Actions runner driven entirely through its
GuruRMM agent (no SSH — GURU-5070's key isn't authorized). Installed act_runner (label windows-msvc,
host-mode SYSTEM, scheduled-task autostart), Node 20, PowerShell 7, protoc 28.3; confirmed rc.exe +
MSVC cargo 1.95 present. Iterated the CI to green through a stack of pre-existing breakage: cargo fmt
drift (ran `cargo fmt --all`), clippy made informational, `.cargo/config` windows-msvc default-target
leaking into Linux clippy/test (CARGO_BUILD_TARGET override), PROTOC env + protoc PATH in the Windows
jobs, workspace-root artifact paths (binary is at root `target/`, not `agent/target/`), committed the
missing root `Cargo.lock` (fixes cargo audit), audit made informational, and removed the redundant/
broken `test.yml`. build-and-test run #17 is fully GREEN (Server Linux, Agent native MSVC on Pluto,
Security Audit, Build Summary).

Also located the portal and recorded infra knowledge (see below).

### Key Decisions
- GC operational tooling in Gitea Actions; reuse RMM's Azure Trusted Signing cert profile (ADR-002).
- Native MSVC build on Pluto via a Gitea Actions runner (drop mingw cross-compile); sign on Linux via jsign (artifact handoff).
- RMM pipeline left as-is — promotion/rollback already provides deliberate release control.
- clippy + cargo audit are informational (warn-only) until the GC re-spec refreshes deps/wires API.
- Release is workflow_dispatch-gated (no auto-release on push).

### Problems Encountered
- No Gitea Actions runner existed (RMM uses webhook+scripts) → provisioned act_runner on Pluto.
- act_runner registered but `.runner` not written (ErrorActionPreference=Stop aborted on stderr) → re-registered with `*>` redirection.
- Host-mode Windows runner needs node + pwsh for JS actions and BOM-free GITHUB_PATH → installed Node 20 + PowerShell 7.
- RMM command 180s reaper killed slow installs (PS7 extract) → used .NET ZipFile extract; cached RMM JWT to avoid login rate-limiting.
- Agent CI failures were config, not code: missing protoc, workspace-root artifact path, missing Cargo.lock. Native build itself compiles clean (verified directly on Pluto, 4m20s).

### Configuration Changes
- GC repo: `docs/FEATURE_ROADMAP.md`, `docs/ARCHITECTURE_DECISIONS.md`, `docs/specs/SPEC-001-operational-tooling-parity.md`, `CHANGELOG.md`, `cliff.toml`, `Cargo.lock` (new); `.gitea/workflows/build-and-test.yml` + `release.yml` (native Pluto build, PROTOC, paths, audit); `.gitea/workflows/test.yml` (deleted); `server/src/api/changelog.rs` + routing; `server/.env.example` (CHANGELOG_DIR).
- claudetools: `.claude/commands/gc-feature-request.md` (new); CLAUDE.md project-keys (+guruconnect); memory `feedback_no_botalerts_internal_rmm.md`, `feedback_autonomous_infra_setup.md`, `project_versionable_products.md`; updated `reference_pluto_build_server.md`, `.claude/machines/pluto.md`, `wiki/systems/pluto.md` (Claude-Builder=PLUTO).
- Pluto (172.16.3.36): act_runner (C:\actrunner, scheduled task GiteaActRunner-guruconnect), Node 20 (C:\node), PowerShell 7 (C:\pwsh), protoc 28.3 (C:\protoc; PROTOC machine env) — all added to machine PATH.

### Credentials & Secrets
- Added 8 Gitea Actions secrets to `guru-connect` repo (values from `services/azure-trusted-signing.sops.yaml` / `/etc/gururmm-signing.env`): AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, TS_ENDPOINT, TS_ACCOUNT, TS_CERT_PROFILE, TS_TIMESTAMP_URL, CI_PUSH_TOKEN (CI_PUSH_TOKEN reuses the azcomputerguru Gitea api-token from `services/gitea.sops.yaml`).
- No new secrets created. Azure Trusted Signing = account `gururmm-signing`, profile `gururmm-public-trust`, `wus2.codesigning.azure.net`.

### Infrastructure & Servers
- PLUTO = Unraid VM "Claude-Builder" = 172.16.3.36 (Windows Server 2019, 16c/16GB). RMM agent id 07a11ece-… (changes on re-enroll; resolve by hostname PLUTO). Drive via /rmm; no `pluto` vault entry.
- Gitea runners: `guruconnect-builder` (Linux 172.16.3.30, ubuntu-latest) + `pluto-guruconnect` (Pluto, windows-msvc) — both online.
- GC portal: tech dashboard live at https://connect.azcomputerguru.com/dashboard (NPM → 172.16.3.30:3002, DNS 72.194.62.4). End-user support-code portal NOT built (gap).

### Commands & Outputs
- RMM login: `POST http://172.16.3.30:3001/api/auth/login` (creds `infrastructure/gururmm-server.sops.yaml` credentials.gururmm-api.*); run cmds via `POST /api/agents/:id/command`, poll `/api/commands/:id`. JWT rate-limits on repeated login — cache it.
- Gitea Actions runner mgmt via API token (`services/gitea.sops.yaml` credentials.api.api-token): runners at `/api/v1/repos/azcomputerguru/guru-connect/actions/runners`; logs at `http://172.16.3.20:3000/<repo>/actions/runs/<n>/jobs/<idx>/logs`; terminal state is in task `status` (NOT `conclusion`, which stays null).
- Native build verified: `cargo build --release --target x86_64-pc-windows-msvc` on Pluto → `target/x86_64-pc-windows-msvc/release/guruconnect.exe`, 4m20s clean.

### Pending / Incomplete Tasks
- Validate the gated `release.yml` end-to-end (version bump → native build → Azure Trusted Signing → Gitea release). NEXT STEP this session.
- GC re-spec: re-tighten clippy + cargo audit to hard gates after a dependency refresh; build the end-user support-code portal.

### Reference Information
- GC commits: `60519be` (tooling), `f2e0456` (gate), `1c5c1e7` (cargo fmt), `b2f9cbc` (clippy/target), `cd88fac` (clippy informational), `8a47332` (native Pluto build), `39e9ac4` (workflow_dispatch), `4ddced1` (CI suite fixes). build-and-test run #17 green.
- claudetools: `…ab78de2` (submodule bumps), `7d326f2` (Pluto memory/wiki docs).
- SPEC-001: `projects/msp-tools/guru-connect/docs/specs/SPEC-001-operational-tooling-parity.md`.

---

## Update: 19:21 PT — Release pipeline validated (signed v0.2.2 published)

### Session Summary

Validated the GuruConnect `release.yml` pipeline end-to-end by dispatching it (workflow_dispatch).
It took three dispatches, each surfacing one real bug, all fixed:
1. Run 18: version-bump + native Pluto build succeeded; sign failed — jsign 6.0 lacks the
   `TRUSTEDSIGNING` keystore type (Azure Trusted Signing needs jsign >= 7.0). Fixed by pinning
   jsign 7.1 (matches `/usr/share/jsign/jsign-7.1.jar` on the build host).
2. Run 20: jsign 7.1 signed the binary successfully ("Adding Authenticode signature... [OK]"),
   but the separate verify step called `jsign --info` (not a real jsign subcommand) and wrongly
   failed the job. Removed the bogus verify; jsign's non-zero exit under `set -euo pipefail`
   already gates signing fail-closed.
3. Run 22: ALL GREEN. Published release `v0.2.2` (draft=false) with assets `guruconnect.exe`
   (Azure-Trusted-Signing-signed), `guruconnect.exe.sha256`, `CHANGELOG.md`.

Confirmed the full chain works: conventional-commit version bump -> git-cliff changelog -> native
MSVC build on the Pluto runner -> Azure Trusted Signing (jsign 7.1) -> Gitea REST release. Deleted
the two orphan tags (v0.2.0, v0.2.1) from the failed attempts; v0.2.2 is the sole tag/release. GC
manifest versions now start at 0.2.2 (legitimate first signed release).

### Key Decisions
- jsign 7.1 (not 6.0) for Azure Trusted Signing in CI; matches the build host's version.
- Removed the jsign-based verify step rather than replace it — jsign's exit code is the fail-closed gate; `jsign --info` does not exist.
- Kept the validation release real (v0.2.2) rather than reverting version churn; cleaned up only the orphan tags.

### Problems Encountered
- Two-workflow confusion in the CI poller (build-and-test + test.yml/deploy.yml sharing pushes) → filtered the poller by `workflow_id` and run_number threshold.
- Release dispatch queued ~10 min behind the push-triggered build-and-test before starting (single shared runner concurrency).

### Configuration Changes
- `projects/msp-tools/guru-connect/.gitea/workflows/release.yml`: JSIGN_VERSION 6.0 -> 7.1 (commit `e7f38ce`/rebased `5727ccf`); removed broken `jsign --info` verify step (commit `5727ccf`).
- Gitea: deleted tags v0.2.0, v0.2.1 (HTTP 204 each); v0.2.2 release published.

### Credentials & Secrets
- No new secrets. Signing used the 8 Actions secrets set earlier (Azure Trusted Signing SP + CI_PUSH_TOKEN); source `services/azure-trusted-signing.sops.yaml` / `/etc/gururmm-signing.env`.

### Infrastructure & Servers
- jsign on build host (172.16.3.30): `/usr/bin/jsign` wrapper -> `/usr/share/jsign/jsign-7.1.jar` (the known-good Trusted Signing version).
- Published release: `http://172.16.3.20:3000/azcomputerguru/guru-connect/releases/tag/v0.2.2`.

### Commands & Outputs
- Dispatch a workflow: `POST /api/v1/repos/azcomputerguru/guru-connect/actions/workflows/release.yml/dispatches` `{"ref":"main"}` (HTTP 204).
- Delete a tag: `DELETE /api/v1/repos/.../tags/<tag>` (HTTP 204).
- jsign 6.0 error: `Unknown keystore type 'TRUSTEDSIGNING'`. jsign sign success marker: `Adding Authenticode signature to guruconnect.exe`.

### Pending / Incomplete Tasks
- GC re-spec: re-tighten clippy + cargo audit to hard gates after dependency refresh; build the end-user support-code portal.
- 5 unrelated `temp/` scratch files remain untracked on GURU-5070 (datto/ksteen — another session's; left untouched).

### Reference Information
- GC release commits: `e7f38ce`/`5727ccf` (jsign 7.1 + verify fix). Release run #22 green. Release `v0.2.2`.
- claudetools: `…70d2190` (submodule bump for verify fix).

---

## Update: 20:47 PT — Birth Biologic SmartBadge correction, GuruRMM 0.3.36 deploy, alert re-routing, Rednour onboarding + onboarding diagnostic

## User
- **User:** Mike Swanson (mike)
- **Machine:** GURU-5070
- **Role:** admin

### Session Summary

Began with Birth Biologic: Kristin Steen (KSTEENBB2025) could not use the Datto SmartBadge Excel add-in. RMM recon against her machine and the working reference (EVO-X1) showed the 2026-05-28 fix had gone the wrong direction — it removed the newer Datto Workplace v10.53.4 (Workplace2, the fleet standard) and left the older Workplace Desktop v8.50.13. Corrected it: Mike Revo-uninstalled v8 (clean, swept the `{2B96EDC1}` CLSID + non-`_CC` add-in keys), then via RMM installed Workplace v10.53.4 from her Downloads, aligned the SmartBadge `_CC` CLSID/add-in to EVO-X1, and cleared her stuck per-user `LoadBehavior=2`. Verified byte-for-byte against EVO-X1. Filed Syncro #32339 public tech notes + 1hr warranty, and stood up a 7-day daily verification (scheduled task on GURU-5070 + coord todo).

GuruRMM Integration Center ("Store") planning: confirmed it is greenfield (MSP360 built, Syncro/catalog not). Locked five design decisions (partner-scoped, generic JSONB config storage with MSP360 migrated in, catalog + Syncro built together, code-defined plugin registry, AES-256-GCM reuse) and landed a revised SPEC-005 as gururmm PR #28. Parked per Mike; tracked in coord todo. Mike also questioned why site API keys are published when enrollment correlates by site_id — code review confirmed the modern `POST /enroll` gate is site_id-only and the site api_key is used only by the legacy WS path + install-info; filed as a security/arch decision.

Resolved Howard's blocker: the gururmm server on 172.16.3.30 was still running 0.3.32 despite an 18:51 restart. Root cause — the 0.3.36 binary had been copied to `/usr/local/bin/gururmm-server`, but the systemd `ExecStart` is `/opt/gururmm/gururmm-server`, which was still yesterday's 0.3.32. Copied 0.3.36 to the correct path, restarted, verified `/status` = 0.3.36 and command flow (test command to ACG-DC16 returned completed/exit 0). Replied to Howard on coord.

Re-routed bot alerts: RMM/Dev alerts (`[RMM]/[DEPLOY]/[DEV]/[BUILD]/[GURURMM]/[SMARTBADGE-WATCH]`) now auto-route to the new private #dev-alerts (Howard + Mike); Syncro/general stay in #bot-alerts. Onboarded Rednour Law Offices (client + site "Main", `GREEN-FALCON-7214`), vaulted the one-time enrollment key, and documented the whole flow as `/rmm onboard` in the skill. Three Rednour agents enrolled and online.

Built Phase 1 of an onboarding diagnostic (`/rmm diagnose`): a PS5.1/ASCII/SYSTEM-safe security+health probe dispatched via RMM, a triage layer grading RED/AMBER/GREEN, immutable per-client baselines, prior-baseline diff, and CRITICAL alerts to #dev-alerts. Code-reviewed (no blockers; folded in immutability guard, severity-independent finding ids, Defender-unknown sentinel, expanded competitor/backup detection). Baselined all three Rednour machines. Mike clarified the "foreign agents" it flagged (ScreenConnect/CW Control, Splashtop, Syncro, Datto RMM+EDR) are ACG's own stack — filed a detection-tuning todo and saved a memory so they aren't re-flagged. Real day-one findings surfaced: two machines on EOL Win10 22H2, RDP-without-NLA on REDNOURCARRIEVI, missing BitLocker, low disk, no backup agent on FrontDeskReception.

### Key Decisions

- **Reversed the 2026-05-28 SmartBadge fix** — the fleet standard is the *newer* Datto Workplace v10.53.4 (Workplace2); Workplace Desktop v8 is older despite the name. EVO-X1 used as the canonical reference.
- **Let Mike Revo-uninstall v8** rather than silent-uninstall via RMM — GUI uninstaller sweeps leftovers a silent uninstall leaves; coordinated to avoid both touching the live box at once.
- **SmartBadge daily watch via local scheduled task, not /schedule** — `/schedule` provisions cloud agents that can't reach the internal RMM API (172.16.3.30); only a LAN machine can.
- **Integration Center: partner-scoped, generic JSONB storage, catalog+Syncro together, code plugin registry, AES-256-GCM reuse** — corrected SPEC-005's internal-only, DB-catalog-table assumptions.
- **Server deploy to `/opt/gururmm/gururmm-server`** — that is the real `ExecStart`; the wiki's `/usr/local/bin` path is stale and caused the failed deploy.
- **Alert routing by message prefix** — auto-routes existing call sites with no edits; explicit `dev`/`bot` 2nd-arg override retained.
- **Onboarding diagnostic Phase 1 = script via /rmm now, Phase 3 = native GuruRMM feature later**; baselines stored in repo now, GuruRMM DB when the native feature lands ("both").

### Problems Encountered

- **Excel rewrote per-user add-in state on exit** — required Excel closed before clearing Kristin's `LoadBehavior=2`; the fix script guards on EXCEL.EXE.
- **sops encrypt failures** — needed `--config "$VR/.sops.yaml"` from outside the vault dir; bare YAML dates threw `Cannot walk value, unknown type: time.Time` (quote them); failed encrypt leaves plaintext on disk (verify with `grep -c 'ENC['`). Documented in `/rmm onboard`.
- **Server "rebuild" didn't take** — 0.3.36 binary was deployed to the wrong path (`/usr/local/bin` vs the service's `/opt/gururmm`). Fixed by copying to the correct path + restart.
- **Discord 400 on em-dash** — a unicode em-dash in an alert broke the JSON post (Windows Git Bash argv encoding); ASCII-only is already the rule.
- **Agent ~32KB command-size cap** — the 62KB diagnostic probe was rejected; runner base64-chunks the upload (<24KB chunks) then decodes/runs/cleans up.
- **Detection false positives** — substring matches (`cove`->Recovery, `ltsvc`->Vaultsvc) and PS5.1 scalar `.Count`; fixed with `\b` anchors and `@(...)` wrapping. Then ACG's own stack flagged as "foreign" — filed tuning todo + memory.
- **git push rejected (non-fast-forward)** twice — other instances had advanced origin; resolved with `pull --rebase` then push.

### Configuration Changes

- KSTEENBB2025 (via RMM): uninstalled Datto Workplace Desktop v8.50.13 (Revo); installed Datto Workplace v10.53.4; `_CC` CLSID `{3C639243}` -> Workplace2 x64/x86 DLLs; removed `{2B96EDC1}` + non-`_CC` add-in keys; per-user `Datto.SmartBadgeShim_CC` LoadBehavior 2->3, cleared Resiliency, set DoNotDisableAddinList.
- 172.16.3.30: `cp /usr/local/bin/gururmm-server /opt/gururmm/gururmm-server` (0.3.36), old saved `/opt/gururmm/gururmm-server.0.3.32.bak`, `systemctl restart gururmm-server`.
- `.claude/scripts/post-bot-alert.sh` — dev/bot channel routing by prefix + override arg.
- `.claude/scripts/ksteen-smartbadge-verify.ps1`, `ksteen-smartbadge-fix.ps1`, `check-ksteen-smartbadge.sh` — new (SmartBadge verify/fix/daily-runner).
- `.claude/scripts/onboarding-diagnostic.ps1`, `run-onboarding-diagnostic.sh` — new (onboarding diagnostic Phase 1).
- `.claude/commands/rmm.md` — added `/rmm onboard`, `/rmm diagnose`, dev-alerts routing notes.
- `.claude/memory/reference_acg_msp_stack.md` (+ MEMORY.md index) — new.
- `wiki/clients/birth-biologic.md` — agents table, dual-Workplace SmartBadge known issue + fleet standard, 5/28-5/29 history.
- Vault `D:/vault/clients/rednour/gururmm-site-main.sops.yaml` — new (Rednour enrollment key).
- Scheduled task "ClaudeTools - KSTEEN SmartBadge Daily" on GURU-5070 (daily 09:00, 2026-05-30..06-05).
- gururmm PR #28 (branch `feat/spec-005-integration-center`) — revised SPEC-005.

### Credentials & Secrets

- Rednour GuruRMM site API key (one-time, `grmm_...`): vaulted at `clients/rednour/gururmm-site-main.sops.yaml` (credentials.api_key). Site `GREEN-FALCON-7214`.
- Gitea API token field path correction: `services/gitea.sops.yaml` -> `credentials.api.api-token` (not `credentials.api-token`).
- Syncro API key: `msp-tools/syncro.sops.yaml` -> `credentials.credential` (unchanged).
- No new secrets created beyond the Rednour site key.

### Infrastructure & Servers

- GuruRMM server 172.16.3.30: `/status` -> 0.3.36; service `ExecStart=/opt/gururmm/gururmm-server` (NOT /usr/local/bin — wiki stale); build via `sudo /opt/gururmm/build-server.sh` (builds in `/home/guru/gururmm/server`, log `/var/log/gururmm-build.log`).
- Rednour Law Offices: client `85f7cff4-d4db-48a8-b477-b8788122a361`, site Main `c7f5787c-8e71-45b3-841f-fa52436f7d26` / `GREEN-FALCON-7214`. Agents: FrontDeskReception `04765560-...`, LegalAsst `18825ea7-...`, rednourcarrievirt `8e4e2221-...`.
- BB agents: BB-SERVER `6c02baa7`, KSTEENBB2025 `ee3c6aea`, EVO-X1 `9595f002`, BB-Office2 `48763401`.
- Discord channels: #bot-alerts `624710699771232265`, #dev-alerts `1509998508198068484` (private).

### Commands & Outputs

```bash
# Server fix (172.16.3.30)
sudo cp /opt/gururmm/gururmm-server /opt/gururmm/gururmm-server.0.3.32.bak
sudo systemctl stop gururmm-server
sudo cp /usr/local/bin/gururmm-server /opt/gururmm/gururmm-server
sudo systemctl start gururmm-server
curl -s localhost:3001/status | jq .version   # -> "0.3.36"

# vault new entry (non-interactive)
sops --config "$VR/.sops.yaml" --encrypt --in-place <file>   # quote dates; secrets under credentials:

# onboarding diagnostic
bash .claude/scripts/run-onboarding-diagnostic.sh <host> <client-slug>
```

### Pending / Incomplete Tasks

- **Rednour:** real findings to action — 2x EOL Win10 22H2 (LegalAsst, REDNOURCARRIEVI), RDP-without-NLA (REDNOURCARRIEVI), missing BitLocker, low disk (REDNOURCARRIEVI ~12%), no backup agent (FrontDeskReception). Mike to direct remediation.
- **KSTEENBB2025:** SmartBadge confirmed working; 7-day watch running (coord todo `4a5b09b3`).
- **Integration Center:** PR #28 open for review/merge; then /shape-spec + scaffold (coord todo `0198ba04`). PARKED.
- **GuruRMM enrollment security:** site_id-only enrollment gate decision (coord todo `00074cd8`).
- **Onboarding diagnostic:** Phase 3 native feature (coord todo `76c6050b`); single-element-array MD-table bug (`cc5dbdfa`); ACG-stack detection allowlist tuning (`3d886f1a`).
- **Wiki:** gururmm.md ExecStart path (/opt vs /usr/local/bin) should be corrected; no wiki article for Rednour yet.

### Reference Information

- Syncro #32339 (BB SmartBadge): public cmt 414607766, warranty li 42639366. Customer 17983014.
- gururmm PR #28: https://git.azcomputerguru.com/azcomputerguru/gururmm/pulls/28
- Coord: Howard reply f888b21c; broadcast bafae411; todos 4a5b09b3 / 0198ba04 / 00074cd8 / 76c6050b / cc5dbdfa / 3d886f1a.
- Rednour install page: https://rmm.azcomputerguru.com/install/GREEN-FALCON-7214
- Baselines: `clients/rednour/onboarding-baselines/` (FRONTDESKRECEPT, LEGALASST, REDNOURCARRIEVI).