# GuruRMM Session Log — 2026-05-12

## User
- **User:** Mike Swanson (mike)
- **Machine:** DESKTOP-0O8A1RL
- **Role:** admin
- **Session span:** 2026-05-12 early morning

## Update: 18:19 PT — WS auth fix verification, 0.6.3 agent build, Claude Code hooks, heartbeat update dispatch

### User
- **User:** Mike Swanson (mike)
- **Machine:** DESKTOP-0O8A1RL
- **Role:** admin
- **Session span:** 2026-05-12 late evening through 2026-05-13 ~01:10 UTC (18:00–18:19 PDT local)

### Session Summary

The session covered four parallel tracks spanning a full overnight build/deploy cycle.

The first track confirmed the enrollment-key WS auth fix deployed in the prior session. DESKTOP-0O8A1RL and GND-SERVER eventually reconnected successfully via the `agk_` enrollment key path. Auth failures in the 23:34–00:04 window were caused by agents working through retry backoff after two server restarts, not a code regression.

The second track addressed a stale zombie lock file (`/var/run/gururmm-build.lock`, PID 526025) that was blocking the Gitea webhook from triggering `build-agents.sh`. The lock was cleared manually and the build triggered (`sudo nohup /opt/gururmm/build-agents.sh`). Version 0.6.3 built successfully in 377 seconds with Authenticode-signed Windows binaries — resolving the SmartScreen warning that affected 0.6.2 unsigned builds. A manual update trigger dispatched 0.6.3 to DESKTOP-0O8A1RL; the agent acknowledged `status=starting` and disconnected as expected during MSI install, but did not reconnect before session end. Update status remains `pending` in the DB; machine needs manual check.

The third track implemented two Claude Code PreToolUse hooks to prevent recurring Git Bash / PowerShell failures. One hook blocks `powershell.exe -Command` and `pwsh -c` inline execution (forces the `.ps1` file approach); the other blocks Windows backslash paths in Bash commands (forces forward slashes). Hooks were written to `D:/claudetools/.claude/hooks/` and registered in `C:\Users\guru\.claude\settings.json`. Multiple iteration rounds were needed to fix: `python3` not in Git Bash PATH (switched to `jq`), false positives from grepping raw JSON stdin rather than the extracted command value, and `\b` word boundary not supported in `grep -E`.

The fourth track implemented heartbeat-based update dispatch based on Mike's clarification that agents should be notified of available updates on their next heartbeat while already connected — not only at reconnect or via manual API trigger. The change was made to `AgentMessage::Heartbeat` in `server/src/ws/mod.rs`, adding a DB lookup, `needs_update` check, `get_pending_update` guard, and update dispatch using the same `state.agents.read().await.send_to()` pattern as the existing API trigger endpoint. Code review: approved. Built clean, deployed, committed as `e8e0c79`.

### Key Decisions

- **`jq` over `python3` in hooks**: `python3` is not in Git Bash's PATH on this machine. `jq` is available at `/c/Users/guru/AppData/Local/Microsoft/WinGet/Links/jq` and handles JSON extraction reliably.
- **Extract `tool_input.command` before grepping**: Grepping the raw JSON stdin for blocked patterns caused false positives when the test bash command itself contained those patterns in echo arguments. Extracting just the command field with `jq` eliminates self-referential false blocks.
- **`(-Command|-c) ` trailing space instead of `\b`**: Git Bash's `grep -E` does not support `\b` word boundaries. Alternating a trailing space and end-of-line anchor correctly matches the flags without matching filename arguments like `-CommandTool`.
- **Heartbeat arm over Metrics arm for update dispatch**: Both fire regularly, but Heartbeat is simpler (one DB call currently) and a clean insertion point. Metrics arm has heavier processing and adding redundant update checks there is unnecessary since heartbeat handles it.
- **`if let Ok(...)` (non-fatal) for update check in heartbeat handler**: A DB hiccup during the update probe should not kill an otherwise healthy WS connection. Only `update_agent_status` uses `?` because a failure there means connection state is corrupted.
- **`get_pending_update` guard**: Prevents duplicate update dispatch if an update is already pending/downloading/installing for an agent. A previously failed update has no blocking row (status not in the pending set), so a retry will dispatch correctly.

### Problems Encountered

- **Zombie lock blocking build**: `/var/run/gururmm-build.lock` held by defunct PID 526025. `sudo rm /var/run/gururmm-build.lock` cleared it; build triggered manually.
- **Hook false positives on self-referential test**: When testing hooks by echoing blocked patterns inside a bash command, the hook saw the full command string (including echo content) and blocked itself. Fixed by extracting only `tool_input.command` via `jq` rather than grepping raw stdin.
- **`\b` not supported in `grep -E`**: Pattern `(-Command|-c)\b` failed to match `pwsh -c Get-Date`. Replaced with alternation: match trailing space OR end of line.
- **SSH commands auto-backgrounded**: Multiple SSH commands to 172.16.3.30 were auto-backgrounded by the Bash tool, making it hard to get synchronous psql output. Worked around by using separate sequential calls and checking output files.
- **DESKTOP-0O8A1RL update stalled**: Agent received update command, acknowledged `status=starting`, disconnected at 00:44:54 UTC, never reconnected. Update record remains `pending`. Root cause unknown from server side — machine needs local inspection.

### Configuration Changes

**`D:/claudetools/.claude/hooks/pre-bash-pwsh-script.sh`** (new file)
- Blocks `powershell.exe -Command` and `pwsh -c` / `pwsh -Command` inline execution
- Forces `.ps1` file approach via Write tool + `pwsh -NoProfile -File`

**`D:/claudetools/.claude/hooks/pre-bash-backslash.sh`** (new file)
- Blocks Windows backslash paths (e.g. `C:\Users\foo`) in Bash commands
- Forces forward slashes (`C:/Users/foo`)

**`C:\Users\guru\.claude\settings.json`** (updated)
- Added `hooks.PreToolUse` section with both hook scripts registered for Bash tool
- Hooks run via Git Bash with 10s timeout each

**`server/src/ws/mod.rs`** (remote: `/home/guru/gururmm/server/src/ws/mod.rs`)
- Added heartbeat-based update dispatch in `AgentMessage::Heartbeat` arm of `handle_agent_message`
- 45 lines inserted; commit `e8e0c79` on `azcomputerguru/gururmm` main

### Infrastructure & Servers

- **GuruRMM server:** 172.16.3.30:3001 | service: `gururmm-server`
- **Build machine (Windows):** Pluto 172.16.3.36 (SSH)
- **Build lock:** `/var/run/gururmm-build.lock`
- **Build log:** `/var/log/gururmm-build.log`
- **Agent downloads dir:** `/opt/gururmm/downloads/`
- **Sign script:** `/opt/gururmm/sign-windows.sh`
- **Agent install dir (Windows):** `C:\ProgramData\GuruRMM\`
- **Agent logs (Windows):** `C:\ProgramData\GuruRMM\logs\`

### Commands & Outputs

```bash
# Clear zombie build lock
sudo rm /var/run/gururmm-build.lock

# Trigger build manually
sudo nohup /opt/gururmm/build-agents.sh

# Manual update dispatch for DESKTOP-0O8A1RL (0.6.2 -> 0.6.3)
# POST /api/agents/c043d9ac-4020-4cab-a5f4-b90213d11e73/update
# Response: "Update triggered: 0.6.2 -> 0.6.3"

# Verify update record
PGPASSWORD=43617ebf7eb242e814ca9988cc4df5ad psql -U gururmm -d gururmm -h localhost \
  -c "SELECT update_id, status, started_at FROM agent_updates WHERE agent_id = 'c043d9ac-4020-4cab-a5f4-b90213d11e73' ORDER BY started_at DESC LIMIT 3;"
# Result: update_id=86a1a7d2..., status=pending, started_at=2026-05-13 00:44:23

# Server log sequence for DESKTOP-0O8A1RL update attempt
# 00:44:23 - "Update trigger: agent=c043d9ac"
# 00:44:23 - "Agent needs update: 0.6.2 -> 0.6.3 (windows-amd64)"
# 00:44:23 - "Received update result: update_id=86a1a7d2..., status=starting"
# 00:44:54 - "WebSocket error: Connection reset without closing handshake"
# 00:44:54 - "Agent c043d9ac connection closed"
# (never reconnected)
```

### Pending / Incomplete Tasks

- **DESKTOP-0O8A1RL update stalled**: Agent is offline at 0.6.2. Update record `pending`. Check locally: `Get-Service GuruRMM` in PowerShell. If stopped, check `C:\ProgramData\GuruRMM\logs\`. If service missing, reinstall 0.6.3 MSI from dashboard.
- **Scanner push to connected agents**: `spawn_scanner` in `server/src/updates/scanner.rs` only updates the in-memory version cache — does not push to connected agents when a new version is found. Requires threading `state.agents` and `state.db` into the scanner task. Deferred; heartbeat dispatch covers the gap for now.
- **Howard's hooks**: Hook scripts are in repo and will sync to Howard's machine, but `~/.claude/settings.json` is machine-local and gitignored. Howard needs to manually add the `hooks` section.
- **Pre-commit hook not executable on server**: Gitea Agent noted `scripts/hooks/pre-commit` is not executable on the server. Needs `chmod +x` to activate lint/format checks on server-side commits.

### Reference Information

- **GuruRMM Gitea repo:** `http://172.16.3.20:3000/azcomputerguru/gururmm`
- **Dashboard:** `https://rmm.azcomputerguru.com`
- **0.6.3 heartbeat dispatch commit:** `e8e0c79` (gururmm main)
- **DESKTOP-0O8A1RL agent UUID:** `c043d9ac-4020-4cab-a5f4-b90213d11e73`
- **GND-SERVER agent UUID:** `cd086074-6766-46b5-93ad-382df97b1f54`
- **Pending update record:** `update_id=86a1a7d2-a634-4e07-82c3-5214bf4338c0`, status=pending
- **Hook scripts:** `D:/claudetools/.claude/hooks/pre-bash-pwsh-script.sh`, `pre-bash-backslash.sh`
- **Claude Code settings:** `C:\Users\guru\.claude\settings.json`

---

## Session Summary

The session focused on auditing the GuruRMM remote execution bridge to identify robustness gaps. Review of server and agent source files revealed eight specific deficiencies, including issues with command dispatching, timeout handling, PowerShell execution, and output management. Following identification, all fixes were implemented in a single commit, addressing each deficiency through database schema changes, message type updates, background reaper task implementation, and enhanced agent-side command execution logic.

The PowerShell execution was corrected with proper flags to prevent execution-policy blocks and OEM-garbled output on Windows. Output size was capped at 5MB with truncation markers. Cancel handling was changed from a misused Error message to a typed CancelCommand that the agent handles by actually aborting the subprocess. All changes were pushed to the main branch, triggering the build pipeline.

## Key Decisions

- **Single commit for all fixes**: Atomic change — easier to revert if a regression surfaces; all protocol changes (new message types) land together so server and agent are never out of sync during a deploy.
- **`timeout_seconds` stored in DB**: The server previously had no basis for reaping stuck-running commands; storing the value at command creation time lets the reaper use the caller's intent rather than a global hardcoded ceiling.
- **Typed `CancelCommand` message instead of `ServerMessage::Error`**: The old cancel sent an Error message; the agent logged it but took no action. A dedicated variant allows the agent to match it explicitly, abort the JoinHandle, and send a `CommandCancelled` ack.
- **`abort_all()` on disconnect**: Commands spawned as fire-and-forget tasks would keep running after the WS connection dropped. `abort_all()` ensures orphaned processes are killed when the agent reconnects rather than accumulating.
- **5MB output cap**: Unbounded stdout/stderr could OOM the agent before the result is sent. The truncation marker makes it clear in the dashboard when output was cut.
- **600s default reaper timeout for commands with no stored timeout**: Existing rows have NULL `timeout_seconds`; 10 minutes is a safe ceiling that prevents permanent stuck-running state without affecting normal commands.

## Problems Encountered

No problems encountered. All eight gaps were identified from code review and fixed cleanly.

## Configuration Changes

### GuruRMM repo (git.azcomputerguru.com/azcomputerguru/gururmm)

**New file:**
- `server/migrations/014_add_command_timeout.sql` — `ALTER TABLE commands ADD COLUMN IF NOT EXISTS timeout_seconds BIGINT`

**Modified:**
- `server/src/db/commands.rs` — `timeout_seconds: Option<i64>` in `Command` and `CreateCommand`; updated INSERT; added `fail_timed_out_commands()`
- `server/src/ws/mod.rs` — `CancelCommand`/`CommandCancelled` message variants; pending-command dispatch on reconnect; `CommandCancelled` handler
- `server/src/api/commands.rs` — `timeout_seconds` passed to `CreateCommand`; cancel sends `CancelCommand` instead of `Error`
- `server/src/main.rs` — background reaper task (60s interval)
- `agent/src/commands/mod.rs` — full `CommandExecutor` (was a stub)
- `agent/src/transport/mod.rs` — `CancelCommand`/`CommandCancelled` variants in agent-side enums
- `agent/src/transport/websocket.rs` — `CommandExecutor` integration; PowerShell flags; 5MB output cap; `abort_all()` on disconnect

## Credentials & Secrets

No new credentials this session.

## Infrastructure & Servers

| Component | Value |
|-----------|-------|
| GuruRMM server | 172.16.3.30:3001 (Rust/Axum) |
| Build host (Linux) | 172.16.3.30 |
| Build host (Windows/MSVC) | Pluto @ 172.16.3.36 |
| Gitea repo | git.azcomputerguru.com/azcomputerguru/gururmm |
| Dashboard | https://rmm.azcomputerguru.com |

## Commands & Outputs

### Commit pushed
```
commit 0a7521b
feat(commands): robust remote execution bridge

- Server pushes pending commands to agent on reconnect
- Background reaper marks stuck-running commands failed after timeout
- timeout_seconds stored in DB (migration 014); default 600s for commands with no explicit timeout
- CancelCommand message type actually signals agent; agent aborts subprocess and acks
- CommandExecutor tracks JoinHandles; abort_all() on disconnect cleans up orphaned tasks
- PowerShell: -ExecutionPolicy Bypass + -OutputEncoding UTF8 on Windows
- Output capped at 5MB with truncation marker

8 files changed, 230 insertions(+), 28 deletions(-)
```

### Key gap summary (pre-fix)
```
Server:
  - pending commands never dispatched on agent reconnect
  - stuck-running commands never reaped (no timeout in DB)
  - cancel_command sent ServerMessage::Error — agent ignored it
Agent:
  - powershell without -ExecutionPolicy Bypass → execution blocked on default PS configs
  - powershell without -OutputEncoding UTF8 → OEM-garbled non-ASCII output
  - JoinHandles not tracked → cancel impossible, orphaned processes on disconnect
  - no output size cap
  - commands/mod.rs was a stub
```

## Pending / Incomplete Tasks

| Task | Status | Notes |
|------|--------|-------|
| Apply migration 014 on live server | **PENDING** | Run before restarting server: `sqlx migrate run` or manual `psql` |
| Verify build pipeline green | **PENDING** | Check Gitea Actions / build log after push |
| Deploy new agent to managed endpoints | **PENDING** | After build confirms green; PowerShell fix is live-impacting |
| Align server Cargo.toml version (shows 0.2.0, agent is 0.6.2) | **PENDING** | Minor; low urgency |
| Temperature collection (BUG-006) | **PENDING** | sysinfo::Components, GPU sources |
| First deployment: Len's (10 endpoints, GPO) | **PENDING** | |

## Reference Information

- Migration to run before server restart: `server/migrations/014_add_command_timeout.sql`
- Reaper default ceiling: 600 seconds (for commands with NULL timeout_seconds)
- PowerShell invocation (agent, Windows): `powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -OutputEncoding UTF8 -Command <cmd>`
- Output cap: 5MB per stdout/stderr; truncation marker appended if exceeded
- Build log: `/var/log/gururmm-build.log` (on 172.16.3.30)

---

## Update: 08:15 MST — TRMM Research + Phase 1 Dev Kickoff

### Summary

Conducted a deep source code analysis of Tactical RMM (https://github.com/amidaware/tacticalrmm + rmmagent) to extract implementation patterns for GuruRMM Phase 1. Cloned both repos with `--depth 1` to `D:\trmm-research\`. Spawned a `deep-explore` agent to read and analyze all major modules: checks, alerts, autotasks, scripts, NATS protocol, client/site hierarchy, automation policies, checkin flow, patch management, and cross-cutting design patterns.

The analysis produced a comprehensive gap report and feature comparison. Key findings: TRMM's check system uses three separate tables (checks, check_results, check_history), a `fails_b4_alert` fail counter that resets on passing, rolling 15-value history for CPU/memory averaging, and a hidden-flag alert dedup pattern. TRMM uses a dual-channel architecture (NATS for server→agent commands, HTTP REST for agent→server data) and a separate Go sidecar that writes agent heartbeats directly to Postgres bypassing Django.

GuruRMM Phase 1 work was kicked off: Coding Agent launched in a git worktree to implement Script Library (migration 017, scripts + script_runs tables, CRUD API, RunScript/ScriptResult WebSocket messages, agent-side execution), Check System (migration 018, checks + check_results + check_history tables, 7 check types, fails_b4_alert pattern, rolling average, background check runner), and Alert Extension (migration 019, check alert dedup via hidden flag + fail_count). The WebSocket protocol file (`ws/mod.rs`) and API router (`api/mod.rs`) have already been updated by the Coding Agent.

PROJECT_STATE.md was updated with a session lock documenting exactly which files the Coding Agent is touching, blocking other sessions from those components until the work is merged.

### Key Decisions

- TRMM source is source-available (not OSI open source) under Tactical RMM License v1.0. MSP use is permitted. Concepts and architecture are not copyrightable — borrowing patterns is clean. Code was not copied.
- Cloned TRMM repos to `D:\trmm-research\` (outside claudetools repo) to avoid git contamination.
- Phase 1 build order: Script Library first (foundation for script checks), then Check System, then Alert extension — each layer depends on the previous.
- Used agent worktree isolation so Phase 1 changes don't land on main until reviewed.
- SERVICE check on non-Windows platforms returns "passing" with a note rather than erroring — cross-platform safety.
- Agent reports raw numeric values for CPU/memory/disk; server applies thresholds and rolling average — cleaner separation, server owns the evaluation logic.
- `RequestChecks` flow: agent sends `AgentMessage::RequestChecks` on schedule; server responds with `ServerMessage::ChecksPayload` containing all enabled checks with pre-resolved script bodies. No separate "fetch" HTTP call needed.

### Configuration Changes

**Modified (by Coding Agent — worktree, not yet on main):**
- `server/src/ws/mod.rs` — Added `ScriptResult`, `RequestChecks`, `CheckResult` to `AgentMessage`; added `RunScript`, `RunChecks`, `ChecksPayload` to `ServerMessage`; added `CheckPayload` struct
- `server/src/api/mod.rs` — Added `pub mod scripts;`, `pub mod checks;`, all script + check routes

**To be created by Coding Agent (worktree):**
- `server/migrations/017_scripts.sql`
- `server/migrations/018_checks.sql`
- `server/migrations/019_check_alerts.sql`
- `server/src/db/scripts.rs`
- `server/src/db/checks.rs`
- `server/src/api/scripts.rs`
- `server/src/api/checks.rs`
- `server/src/alerts/check_alerts.rs`
- `agent/src/scripts.rs`
- `agent/src/checks.rs`
- `agent/src/transport/mod.rs` — mirrored protocol additions

**Created this session:**
- `D:\trmm-research\tacticalrmm\` — shallow clone (25MB), TRMM Django server + Go NATS bridge
- `D:\trmm-research\rmmagent\` — shallow clone (575KB), TRMM Go agent
- `projects/msp-tools/guru-rmm/PROJECT_STATE.md` — session lock added for Phase 1 Coding Agent

### Infrastructure & Servers

| Component | Value |
|---|---|
| GuruRMM server | 172.16.3.30:3001 (Rust/Axum) |
| TRMM research repos | D:\trmm-research\ (local only, not in any repo) |
| Coding Agent worktree | git worktree off main branch (auto-cleanup if no changes) |

### Commands & Outputs

```bash
# TRMM source clones
git clone --depth 1 https://github.com/amidaware/tacticalrmm.git D:/trmm-research/tacticalrmm
git clone --depth 1 https://github.com/amidaware/rmmagent.git D:/trmm-research/rmmagent
# Result: tacticalrmm=25MB, rmmagent=575KB

# TRMM Django apps found (tacticalrmm/api/tacticalrmm/):
# agents/ alerts/ automation/ autotasks/ checks/ clients/ core/ ee/
# logs/ scripts/ services/ software/ winupdate/

# TRMM Go agent files found (rmmagent/agent/):
# checks.go  tasks_windows.go  patches_windows.go  choco_windows.go
# services_windows.go  wua_windows.go  rpc.go  checkin.go
```

### Pending / Incomplete Tasks

| Task | Status | Notes |
|------|--------|-------|
| Coding Agent: Phase 1 implementation | IN PROGRESS | Worktree; `cargo check` verification required on completion |
| Code Review Agent: Phase 1 review | BLOCKED | Waiting for Coding Agent to finish |
| Merge Phase 1 worktree → main | BLOCKED | After code review passes |
| Deploy migrations 017-019 to Jupiter | BLOCKED | After merge |
| Dashboard: Scripts page (list, create, run) | NOT STARTED | Phase 1 UI |
| Dashboard: Checks tab on AgentDetail | NOT STARTED | Phase 1 UI |
| Dashboard: Alerts panel for check failures | NOT STARTED | Phase 1 UI |
| Release PROJECT_STATE lock after merge | PENDING | Remove Coding Agent row from Active Locks |

### Reference Information

- TRMM check types: cpu, memory, disk, ping, port, script, service (eventlog omitted from Phase 1 for simplicity)
- TRMM NATS message taxonomy: 40+ commands documented in 2026-05-12 deep-explore session output
- fails_b4_alert pattern: `fail_count` increments on fail, resets to 0 on pass; alert fires when `fail_count >= fails_b4_alert`
- Rolling average: last 15 CPU/memory readings stored in `value_history DOUBLE PRECISION[]`; server computes `mean()` for threshold evaluation
- Alert dedup: query `WHERE check_id=$1 AND agent_id=$2 AND resolved=false`; `hidden=false` on creation
- Coding Agent run_id: a2c541a89b2ed6cc8 (internal)
- TRMM license: Tactical RMM License v1.0, source-available, MSP use permitted, no SaaS resale
- TRMM repos: github.com/amidaware/tacticalrmm (Python/Vue), github.com/amidaware/rmmagent (Go)
- Commit SHA: `0a7521b`

---

## Update: 09:50 MST — Code Review, Post-Review Fixes, Migration Deploy, Phase 1 Server Deploy

### Summary

Ran the mandatory Code Review Agent on the Coding Agent Phase 1 output (commit `f6a9a5d` — Script Library, Check System, Check-based Alerts). The review identified two bugs requiring immediate fix before merge: disk threshold evaluation was inverted (checking FREE percent with a "greater than" comparator instead of "less than"), and the background check runner in `main.rs` held a Tokio `RwLock` read guard across async `db::get_script()` calls, blocking all writer paths (agent connect/disconnect) for the full duration of DB fetches.

Both bugs were fixed in commit `ed3b797`. The disk fix added an `is_disk` boolean and an `exceeds` closure in `server/src/ws/mod.rs` — disk alerts fire when free space falls below threshold, all other metric types alert when usage rises above threshold. The RwLock fix restructured the check runner loop into three phases: collect connected agent IDs under a short lock scope, drop the lock, fetch script bodies via DB, re-acquire for message dispatch. This pattern was already used correctly in `api/checks.rs::trigger_run_checks`.

A build failure followed: the Windows agent (`service.rs`) did not compile because `AppState` gained a new `agent_id` field in `main.rs` during Phase 1 but `service.rs` creates `AppState` independently and was not updated. Fixed in commit `f1e1e35` by adding `agent_id: tokio::sync::RwLock::new(None)` to the `AppState` struct literal in `service.rs`. Also removed an unused `CheckPayload` import warning in `agent/src/transport/websocket.rs`.

All three fix commits were pushed; the gururmm submodule pointer in claudetools was advanced and pushed. Build pipeline completed in 310 seconds with all 6 agent variants (linux-x86_64, linux-aarch64, windows-x86_64, windows-x86, macos-x86_64, macos-aarch64) plus the server binary. Phase 1 server binary (v0.6.2, 11MB) was deployed to Jupiter.

Migrations 017-019 were applied to the live PostgreSQL database on Jupiter. Application required a Python helper script (`/tmp/apply_migrations.py`) because the normal sqlx CLI path failed (peer auth). The script ran each `.sql` file via `psql -h localhost` and inserted checksum records into `_sqlx_migrations` manually. After server startup, a critical issue emerged: sqlx's `migrate!()` proc macro, when `DATABASE_URL` is set at compile time, queries `_sqlx_migrations` during compilation and excludes already-applied migrations from the binary's embedded resolved set. The compiled binary contained only migrations 1-16; finding rows 17-19 in `_sqlx_migrations` at startup caused a fatal error: "migration N was previously applied but is missing in the resolved migrations." After extensive diagnosis (cargo clean, touching files, 3m40s forced recompile), confirmed the binary definitively has only 1-16 embedded. Workaround: deleted `_sqlx_migrations` rows 17-19 (tables remain). Server starts cleanly. Future fix requires running `cargo sqlx prepare` to generate `.sqlx` offline query cache, then building with `SQLX_OFFLINE=true` so the proc macro reads from files only.

Coordination protocol internalized: PROJECT_STATE.md files are now archived and read-only. All live state uses the ClaudeTools coordination API at `http://172.16.3.30:8001/api/coord/`. Component states for `gururmm/server` and `gururmm/agents` were updated via PUT requests after the deploy.

### Key Decisions

- **Disk threshold direction**: disk check reports FREE percent, not usage. Alert fires when free falls BELOW threshold. CPU/memory report usage, alert fires when usage RISES ABOVE threshold. A single `is_disk` branch and `exceeds` closure handles both cases cleanly without duplicating the pass/warn/fail evaluation tree.
- **RwLock scope discipline**: collect data under a minimal lock window, release, do all async work, re-acquire for writes. Holding a read lock across DB awaits prevents agent connect/disconnect (which need write locks) for the entire DB round-trip.
- **service.rs must mirror main.rs AppState**: On Windows the agent runs as a Windows Service via a separate entry point in `service.rs` that constructs `AppState` independently. Any field added to `AppState` must be added in both places. This is a structural gotcha to document for future phases.
- **sqlx proc macro workaround**: deleting rows 17-19 from `_sqlx_migrations` is acceptable because the tables exist and the data is live. The proper fix (SQLX_OFFLINE=true build) is deferred but must happen before the next binary build that includes migrations >= 017. If rows 17-19 are missing when SQLX_OFFLINE=true binary deploys, those migrations will re-run and fail (table already exists). Sequence: `cargo sqlx prepare`, build, then re-insert rows 17-19 before deploying.
- **_sqlx_migrations manual insert format**: `(version BIGINT, description TEXT, installed_on TIMESTAMPTZ, success BOOL, checksum BYTEA, execution_time BIGINT)`. Checksum is the SHA-384 of the migration file content as bytes, stored as `decode(hex_string, 'hex')`.

### Problems Encountered

- **Code Review: disk threshold inverted** — `server/src/ws/mod.rs` used `mean >= threshold` for disk (which reports free percent). Fix: `is_disk` flag + `exceeds` closure. Caught before deploy.
- **Code Review: RwLock held across async DB calls** — Check runner held agents read lock during `db::get_script()` fetches. Fix: short lock scope for ID collection, separate re-acquire for dispatch.
- **agent/src/service.rs missing `agent_id` field** — Windows build broke because `service.rs` constructs `AppState` separately from `main.rs`. Fix: add field to both `AppState` initializers.
- **psql peer auth failure on Jupiter** — `psql -U gururmm -d gururmm` failed with peer auth. Fix: add `-h localhost` to force TCP, use `PGPASSWORD` env var.
- **Migration 017 partial apply** — First `apply_migrations.py` run applied the SQL (CREATE TABLE succeeded) but exited before recording the checksum due to a quoting error in the Python heredoc on the shell. Fixed by rewriting the script with explicit error handling and "table already exists" detection to skip re-running SQL while still inserting the checksum row.
- **Stale zombie build lock** — After the first (failed) build attempt, `/var/run/gururmm-build.lock` contained PID 524863 (zombie). `os.kill(pid, 0)` returns 0 for zombies so the webhook handler believed a build was still running. Fix: `sudo rm /var/run/gururmm-build.lock` manually.
- **sqlx proc macro excludes pre-applied migrations from compiled binary** — The most time-consuming issue. With `DATABASE_URL` set at compile time, `sqlx::migrate!()` queries `_sqlx_migrations` during the proc macro expansion phase and excludes rows already present. Result: compiled binary has only migrations 1-16 embedded; finding rows 17-19 in `_sqlx_migrations` at runtime causes a fatal startup error. Attempted fixes that did not work: `cargo clean -p gururmm-server`, deleting fingerprints, touching migration files, touching `Cargo.toml`, modifying `main.rs` comment (forced full 3m40s recompile — same result), `SQLX_OFFLINE=true` (no `.sqlx` cache exists). Workaround: deleted rows 17-19 from `_sqlx_migrations`. Tables remain live. Server starts cleanly.

### Configuration Changes

**gururmm submodule (git.azcomputerguru.com/azcomputerguru/gururmm) — 3 new commits:**

- `ed3b797` — fix(checks): correct disk threshold direction and narrow RwLock scope in check runner
  - `server/src/ws/mod.rs` — `is_disk` flag + `exceeds` closure for correct threshold direction
  - `server/src/main.rs` — restructured check runner: short lock for ID collection, DB work without lock, re-acquire for dispatch
- `f1e1e35` — fix(agent): add missing agent_id to service.rs AppState; remove unused CheckPayload import
  - `agent/src/service.rs` — `agent_id: tokio::sync::RwLock::new(None)` added to AppState literal
  - `agent/src/transport/websocket.rs` — removed `CheckPayload` from use statement

**Live database on Jupiter (172.16.3.30, db: gururmm):**
- Tables created: `scripts`, `script_runs`, `checks`, `check_results`, `check_history`, `check_alerts` (via migrations 017-019)
- `_sqlx_migrations` rows 17, 18, 19 — DELETED (sqlx proc macro workaround; tables remain)

**Claudetools repo:**
- `projects/msp-tools/guru-rmm` submodule pointer advanced to commit `f1e1e35`

### Credentials & Secrets

No new credentials this session.

### Infrastructure & Servers

| Component | Value |
|---|---|
| GuruRMM server | 172.16.3.30:3001 (Rust/Axum, Phase 1 binary v0.6.2) |
| Build host (Linux/Jupiter) | 172.16.3.30 |
| Build host (Windows/Pluto) | 172.16.3.36 |
| PostgreSQL | 172.16.3.30, db: gururmm |
| Webhook trigger | POST localhost:9000/webhook/build (HMAC-SHA256, secret: gururmm-build-secret) |
| Build log | /var/log/gururmm-build.log |
| Build lock file | /var/run/gururmm-build.lock |

### Commands & Outputs

```bash
# Trigger build pipeline after Phase 1 merge
# (HMAC-SHA256 signature required)
# Build completed in 310s; 6 agent variants + server binary

# Apply migrations on Jupiter — final working command sequence
PGPASSWORD=<from vault> psql -h localhost -U gururmm -d gururmm -v ON_ERROR_STOP=1 -f /tmp/017_scripts.sql
PGPASSWORD=<from vault> psql -h localhost -U gururmm -d gururmm -v ON_ERROR_STOP=1 -f /tmp/018_checks.sql
PGPASSWORD=<from vault> psql -h localhost -U gururmm -d gururmm -v ON_ERROR_STOP=1 -f /tmp/019_check_alerts.sql
# Then insert into _sqlx_migrations for each — later DELETED as sqlx workaround

# Delete sqlx rows to fix fatal startup error
PGPASSWORD=<from vault> psql -h localhost -U gururmm -d gururmm \
  -c "DELETE FROM _sqlx_migrations WHERE version IN (17, 18, 19);"

# Confirm server starts cleanly
sudo systemctl restart gururmm-server
# journalctl output: "Migrations complete" -> "Server listening on 0.0.0.0:3001"

# Update component states in coordination API
curl -s -X PUT http://172.16.3.30:8001/api/coord/components \
  -H "Content-Type: application/json" \
  -d '{"project_key":"gururmm","component":"server","state":"deployed","version":"0.6.2","notes":"Phase 1 live: scripts, checks, check_alerts. sqlx workaround: _sqlx_migrations rows 17-19 deleted.","updated_by":"DESKTOP-0O8A1RL/claude-main"}'

curl -s -X PUT http://172.16.3.30:8001/api/coord/components \
  -H "Content-Type: application/json" \
  -d '{"project_key":"gururmm","component":"agents","state":"built","version":"0.6.2","notes":"All 6 variants built. service.rs AppState fix included.","updated_by":"DESKTOP-0O8A1RL/claude-main"}'
```

### Pending / Incomplete Tasks

| Task | Status | Notes |
|------|--------|-------|
| Fix sqlx proc macro embed for migrations 017-019 | **CRITICAL/PENDING** | Run `cargo sqlx prepare` on Jupiter, build with `SQLX_OFFLINE=true`. Re-insert _sqlx_migrations rows 17-19 AFTER building that binary, BEFORE deploying it. Do NOT deploy new binary until this is done or migration 017+ will re-run and fail. |
| Dashboard: Scripts page | NOT STARTED | List, create, edit, run scripts on agents |
| Dashboard: Checks tab on AgentDetail | NOT STARTED | View/create/manage checks, results, history |
| Dashboard: Alerts panel | NOT STARTED | Check failure alerts, ack/resolve |
| Email alerts wiring | NOT STARTED | check_alerts.rs logs intent only; needs Graph API integration |
| BUG-3 end-to-end test | NOT STARTED | Install legacy agent on Win7/Server 2008 R2, confirm auto-update |
| First deployment: Len's | NOT STARTED | 10 endpoints, GPO |

### Reference Information

- sqlx proc macro behavior: with `DATABASE_URL` at compile time, proc macro excludes rows already in `_sqlx_migrations` from the embedded resolved set. Fix: `cargo sqlx prepare` generates `.sqlx/` cache; `SQLX_OFFLINE=true` build reads from files only, ignoring DB state.
- _sqlx_migrations insert format: `(version, description, installed_on, success, checksum, execution_time)` where checksum = `decode(sha384_hex_of_file_bytes, 'hex')`, execution_time = 0 (bigint, microseconds)
- Webhook trigger: `POST localhost:9000/webhook/build` with `X-Hub-Signature-256: sha256=<hmac>` header; secret = `gururmm-build-secret`
- Build log: `/var/log/gururmm-build.log` on Jupiter
- Build lock: `/var/run/gururmm-build.lock` — contains PID; zombie check: `os.kill(pid, 0)` returns 0 for zombies, lock may be stale even when build is done
- service.rs AppState: must be manually kept in sync with main.rs AppState — no shared constructor
- Phase 1 gururmm commits: `f6a9a5d` (Coding Agent output), `ed3b797` (disk+RwLock fixes), `f1e1e35` (service.rs build fix)

---

## Update: 10:15 MST — Phase 1 Deploy Fix + sqlx-cli + Offline Cache

### Summary

This update resolved the root cause of Phase 1 never being fully live, installed sqlx-cli, and established a permanent SQLX_OFFLINE build workflow.

Diagnosing the deployment revealed a second problem beyond the sqlx proc macro embed issue: the running gururmm-server service was using the PRE-Phase 1 binary at `/opt/gururmm/gururmm-server` (10MB, built before 017-019 existed). The Phase 1 binary compiled in the prior update had been placed at `/usr/local/bin/gururmm-server` (wrong path) and never deployed to the service. That binary also had the embed bug since it was compiled while `_sqlx_migrations` rows 17-19 existed.

With rows 17-19 already deleted from `_sqlx_migrations`, a fresh server build was triggered. `cargo clean -p gururmm-server` removed 0 files (package was clean), but running `cargo build --release` again with the DB in the correct state produced a new binary at 17:04 (same size, different timestamp — the proc macro re-evaluated with rows 17-19 absent and embedded all 19 migration files). The SHA-384 checksums for migration files 017-019 were computed via Python hashlib.sha384 and inserted into `_sqlx_migrations` as bytea via `decode(hex, 'hex')`. The new binary was deployed to `/opt/gururmm/gururmm-server` and the service restarted. Server logged "Migrations complete" — all 19 rows matched the binary's resolved set.

sqlx-cli v0.8.6 was installed on Jupiter via `cargo install sqlx-cli --no-default-features --features native-tls,postgres` (44 seconds). `cargo sqlx prepare` was run in `/home/guru/gururmm/server/`, generating 8 query JSON files in `server/.sqlx/`. These were committed to gururmm as `4b43878` and pushed. `SQLX_OFFLINE=true` was appended to `/home/guru/.cargo/env`, making it permanent for all cargo builds run as the guru user. Agent builds are unaffected (agent has no sqlx dependencies). `/opt/gururmm/build-server.sh` was created to document and automate future server build+deploy cycles, including stop/copy/start with failure detection.

### Key Decisions

- **Service binary path is `/opt/gururmm/gururmm-server`, not `/usr/local/bin/`**: The systemd service ExecStart points to `/opt/gururmm/gururmm-server`. Future deploys must target that path. `/usr/local/bin/gururmm-server` is a stale copy with no service backing.
- **Build before inserting `_sqlx_migrations` rows, deploy after**: The correct sequence for all future migrations is (1) delete new rows from `_sqlx_migrations`, (2) run `cargo sqlx prepare` + commit `.sqlx/`, (3) build with `SQLX_OFFLINE=true`, (4) insert rows, (5) deploy. With `SQLX_OFFLINE=true` now permanent, step 1 is no longer needed — new migrations simply won't be in `_sqlx_migrations` yet when first built, so sqlx will apply them naturally at startup, and `CREATE TABLE IF NOT EXISTS`-style SQL should be used.
- **`SQLX_OFFLINE=true` in `~/.cargo/env` vs. build script**: Added globally to `~/.cargo/env` rather than only in `build-server.sh` so that ad-hoc `cargo build` runs by guru also use the cache. Safe because agent builds have no sqlx macros.
- **`cargo sqlx prepare` must be re-run when schema changes**: Any `query!()` macro that references a new table/column will break with stale `.sqlx/` cache. Procedure documented in `build-server.sh` comments.

### Problems Encountered

- **Phase 1 binary was deployed to wrong path**: `/usr/local/bin/gururmm-server` has no systemd backing. The service reads from `/opt/gururmm/gururmm-server`. Discovered by reading `systemctl cat gururmm-server`.
- **`cargo clean -p gururmm-server` removed 0 files**: The package was already in a clean state (prior build had completed). Running `cargo build --release` anyway triggered recompilation because the DB state had changed and the proc macro re-evaluated.

### Configuration Changes

**On Jupiter (172.16.3.30):**
- `/home/guru/.cargo/env` — appended `export SQLX_OFFLINE=true`
- `/opt/gururmm/gururmm-server` — replaced with Phase 1 binary (11005560 bytes, built 2026-05-12 17:04)
- `/opt/gururmm/build-server.sh` — new file, server build+deploy script (chmod +x)
- `/home/guru/.cargo/bin/sqlx` and `cargo-sqlx` — installed sqlx-cli v0.8.6

**gururmm repo (commit `4b43878`):**
- `server/.sqlx/` — 8 new query JSON files (offline cache for SQLX_OFFLINE builds)

**claudetools repo (commit `c13947e`):**
- `projects/msp-tools/guru-rmm` submodule pointer advanced to `4b43878`

**PostgreSQL `_sqlx_migrations` (gururmm DB on Jupiter):**
- Rows 17 (`scripts`), 18 (`checks`), 19 (`check alerts`) re-inserted with SHA-384 checksums

### Credentials & Secrets

No new credentials. DB password used: `43617ebf7eb242e814ca9988cc4df5ad` (already in CONTEXT.md).

### Infrastructure & Servers

| Component | Value |
|---|---|
| GuruRMM server | 172.16.3.30:3001 — Phase 1 binary live as of 17:06 |
| Service binary path | `/opt/gururmm/gururmm-server` (NOT /usr/local/bin) |
| Server build script | `/opt/gururmm/build-server.sh` |
| Build env | `SQLX_OFFLINE=true` in `/home/guru/.cargo/env` |
| sqlx offline cache | `server/.sqlx/` (8 files, committed `4b43878`) |

### Commands & Outputs

```bash
# Force fresh server build on Jupiter
source ~/.cargo/env && cd /home/guru/gururmm/server && cargo clean -p gururmm-server && cargo build --release
# Result: Finished release profile in 2m 50s

# Re-insert _sqlx_migrations rows 17-19 (Python, run on Jupiter)
python3 -c "
import hashlib, subprocess, os
os.environ['PGPASSWORD'] = '43617ebf7eb242e814ca9988cc4df5ad'
PG = ['psql', '-h', 'localhost', '-U', 'gururmm', '-d', 'gururmm']
for version, filename, description in [(17,'017_scripts.sql','scripts'),(18,'018_checks.sql','checks'),(19,'019_check_alerts.sql','check alerts')]:
    content = open(f'/home/guru/gururmm/server/migrations/{filename}','rb').read()
    checksum_hex = hashlib.sha384(content).hexdigest()
    sql = f\"INSERT INTO _sqlx_migrations (version, description, installed_on, success, checksum, execution_time) VALUES ({version}, '{description}', NOW(), true, decode('{checksum_hex}', 'hex'), 0) ON CONFLICT (version) DO NOTHING;\"
    subprocess.run(PG + ['-c', sql])
"

# Deploy Phase 1 binary to service path
sudo systemctl stop gururmm-server
sudo cp /home/guru/gururmm/server/target/release/gururmm-server /opt/gururmm/gururmm-server
sudo systemctl start gururmm-server
# journalctl result: "Migrations complete" -> "Starting server on 0.0.0.0:3001"

# Install sqlx-cli
cargo install sqlx-cli --no-default-features --features native-tls,postgres
# Result: Installed sqlx-cli v0.8.6 in 43.60s

# Generate offline cache
cd /home/guru/gururmm/server && cargo sqlx prepare
# Result: query data written to .sqlx in the current directory

# Commit and push .sqlx cache
cd /home/guru/gururmm && git add server/.sqlx && git commit -m 'build: add sqlx offline query cache for SQLX_OFFLINE=true builds'
git push origin main
# Commit: 4b43878

# Add SQLX_OFFLINE to cargo env
echo 'export SQLX_OFFLINE=true' >> ~/.cargo/env
```

### Pending / Incomplete Tasks

| Task | Status | Notes |
|------|--------|-------|
| Dashboard: Scripts page | NOT STARTED | List, create, edit, run scripts on agents |
| Dashboard: Checks tab on AgentDetail | NOT STARTED | View/create/manage checks, results, history |
| Dashboard: Alerts panel | NOT STARTED | Check failure alerts, ack/resolve |
| Email alerts wiring | NOT STARTED | check_alerts.rs logs intent only; needs Graph API integration |
| BUG-3 end-to-end test | NOT STARTED | Install legacy agent on Win7/Server 2008 R2, confirm auto-update |
| First deployment: Len's | NOT STARTED | 10 endpoints, GPO |
| Re-run `cargo sqlx prepare` when new query!() macros added | ONGOING | Must keep .sqlx/ cache current; commit after each schema change |

### Reference Information

- sqlx-cli version: 0.8.6
- sqlx offline cache: `server/.sqlx/` (8 files) — commit `4b43878`
- Future migration procedure: add SQL file → apply to DB → `cargo sqlx prepare` → commit `.sqlx/` → `sudo /opt/gururmm/build-server.sh`
- Service binary: `/opt/gururmm/gururmm-server` (systemd ExecStart, EnvironmentFile=/opt/gururmm/.env)
- Server build script: `/opt/gururmm/build-server.sh` (root, stops service, builds with SQLX_OFFLINE, deploys, verifies)
- SQLX_OFFLINE env: `/home/guru/.cargo/env` — applies to all guru cargo builds on Jupiter
- gururmm commit `4b43878`: sqlx offline cache

---

## Update: 22:00–00:05 PT — Phase 2 complete: code review fixes, policy-to-checks, RBAC

### User
- **User:** Mike Swanson (mike)
- **Machine:** DESKTOP-0O8A1RL
- **Role:** admin
- **Session span:** ~2026-05-12 22:00 PT – 2026-05-13 00:05 PT

### Session Summary

The session resumed mid-crisis: the GuruRMM server was crash-looping with "migration 22 was previously applied but has been modified." Root cause was two files both prefixed `022_` in `server/migrations/` — `022_alert_templates.sql` and `022_asset_inventory.sql` — causing `migrate!()` to embed the wrong migration 22 checksum at compile time. The fix was to `git rm` the stale duplicate, commit `872b192`, and trigger a rebuild. Server recovered in under 4 minutes.

With the server stable, a formal code review of the entire Phase 2 implementation (batches 1-3: maintenance mode, resolved notifications, webhook dispatch, alert templates, asset inventory) was performed by the Code Review Agent. The review returned a NO-SHIP verdict with 5 required fixes: missing reqwest timeout, resolved notifications firing even when no alert was open, no role guards on mutation endpoints, missing target_type validation in remove-assignment, and GET webhook requests sending a body. All 5 were applied in a fresh worktree off the now-current local clone (which required a `git stash && git fetch && git rebase` to bring it up from a stale state), then merged and pushed as commit `90e8ae6` followed by a rebuild.

Policy-to-Checks was implemented next: a new `policy_checks` table (migration 024) stores check templates owned by a policy, and a `sync_policy_checks()` function materializes those templates as real agent-specific `checks` rows for every agent in scope via a JOIN across `policy_assignments/agents/sites`. Auto-sync fires as a `tokio::spawn` after any policy assign or unassign. The Coding Agent did all work directly on Jupiter via SSH (the worktree isolation was bypassed). A manual bug fix was applied after review: `delete_policy_check` was patched to explicitly DELETE derived agent checks before deleting the template, preventing NULL orphans from the `ON DELETE SET NULL` FK behavior. A second Coding Agent created the dashboard Policies page with full CRUD for policies, assignments, and check templates. Committed as `302e605`, pushed, rebuilt.

RBAC enforcement was the final item. The foundation (AuthContext, OrgAccess, user_organizations) was already in place but unenforced. The session added an `is_admin()` helper to `AuthUser` (covers both "admin" legacy role and "dev_admin"), replaced all `auth.role != "admin"` string guards across 6 API files, and added org-scoped filtering to the main list endpoints (agents, clients, sites, alerts) using `accessible_client_ids()` branching. Per-resource 403 checks were added to detail endpoints. A Users management dashboard page was created for admin users to manage system roles and org memberships. Additionally, `023_asset_inventory.sql` — which had been applied to the DB but never committed to git — was added to the repo in this commit to prevent fresh-checkout build failures. Committed as `e37679b`, rebuilt to `v0.6.4`, dashboard deployed.

### Key Decisions

- **Discarded worktree for policy-to-checks**: The Coding Agent bypassed worktree isolation and SSH'd directly to Jupiter. Rather than fight this, all file review and the delete fix were done directly on Jupiter's local repo before committing. Worktree isolation is enforced at the agent-invocation level but cannot prevent SSH access.
- **Reverted out-of-scope ws/mod.rs enrollment flow**: The Coding Agent added WebSocket enrollment key authentication to ws/mod.rs and helpers to enroll.rs — useful functionality but not requested. Reverted via `git checkout -- server/src/ws/mod.rs server/src/db/enroll.rs` before commit.
- **Reverted agent/Cargo.toml winres dep**: Another out-of-scope addition from the Coding Agent (Windows resource file embedding). Reverted.
- **`delete_policy_check` cleanup order**: ON DELETE SET NULL means deleting a template NULLs the `policy_check_id` on derived checks, making the `sync_policy_checks` cleanup query miss them (it filters `IS NOT NULL`). Fixed by adding an explicit DELETE of derived checks before deleting the template — more predictable than changing the FK to CASCADE.
- **`is_admin()` covers both "admin" and "dev_admin"**: Legacy "admin" role and new "dev_admin" role coexist. Rather than migrating all users, the helper covers both so existing admin accounts don't lose access to mutation endpoints.
- **023_asset_inventory.sql committed now**: The migration file had been applied to the DB and was present on disk (causing the binary to embed it via `migrate!()`), but was never in git. Added alongside the RBAC commit to prevent future fresh-checkout build failures.

### Problems Encountered

- **Server crash loop on session start**: Binary embedded wrong migration 22 due to duplicate `022_` files. Fixed by deleting `022_asset_inventory.sql`, rebuilding.
- **Local dev clone stale by ~15 commits**: Phase 2 work had been done entirely on Jupiter and never pulled locally. Required `git stash && git fetch && git rebase` before the code review fix worktree could be created from current base.
- **Code review worktree created off stale base**: The first Code Review fix Coding Agent run created its worktree from the stale local clone and re-implemented all Phase 2 code from scratch. Discarded. Synced local clone, re-ran agent against current base.
- **Policies.tsx missing after policy-to-checks agent**: Agent worked on Jupiter directly but the dashboard files were not created. A second agent was spawned specifically for the dashboard pieces.

### Configuration Changes

**New files:**
- `server/migrations/023_asset_inventory.sql` — added to git (was on disk, applied to DB, but not committed)
- `server/migrations/024_policy_checks.sql` — policy_checks table + policy_check_id FK on checks
- `server/src/db/policy_checks.rs` — CRUD + sync_policy_checks()
- `server/src/api/policy_checks.rs` — 6 REST handlers for policy check templates
- `dashboard/src/pages/Policies.tsx` — full policy/assignment/check-template management UI
- `dashboard/src/pages/Users.tsx` — admin-only user and org membership management UI

**Modified (server):**
- `server/src/auth/mod.rs` — added `is_admin()` helper
- `server/src/api/agents.rs` — org-scoped list + 403 on detail
- `server/src/api/clients.rs` — org-scoped list + 403 on detail
- `server/src/api/sites.rs` — org-scoped list + 403 on detail
- `server/src/api/alerts.rs` — org-scoped list
- `server/src/api/maintenance.rs` — `!auth.is_admin()` guards
- `server/src/api/alert_templates.rs` — `!auth.is_admin()` guards, target_type validation in remove-assign
- `server/src/api/policy_checks.rs` — admin guards, sync on create/update/delete
- `server/src/api/users.rs` — `!auth.is_admin()` guards, dev_admin in valid_roles
- `server/src/api/policies.rs` — tokio::spawn sync after assign and remove_assignment
- `server/src/api/mod.rs` — policy_checks module + 6 new routes
- `server/src/db/mod.rs` — policy_checks module
- `server/src/db/agents.rs` — list_agents_by_clients()
- `server/src/db/clients.rs` — list_clients_by_ids()
- `server/src/db/sites.rs` — list_sites_by_clients()
- `server/src/alerts/check_alerts.rs` — resolve returns bool, Ok(true) gates resolved notifications
- `server/src/webhook.rs` — suppress body on GET, accurate doc comment
- `server/src/main.rs` — reqwest::Client built with 10s/5s timeout

**Modified (dashboard):**
- `dashboard/src/App.tsx` — /policies and /users routes
- `dashboard/src/components/Layout.tsx` — Policies + Users (admin-only) nav entries
- `dashboard/src/api/client.ts` — PolicyCheck interfaces and policyChecksApi

### Credentials & Secrets

No new credentials created this session. Existing DB credentials unchanged:
- DB user: gururmm / 43617ebf7eb242e814ca9988cc4df5ad @ localhost:5432/gururmm (on Jupiter 172.16.3.30)

### Infrastructure & Servers

- Jupiter (172.16.3.30): gururmm-server v0.6.4, systemd active, migrations 1-24 applied
- Dashboard: /var/www/gururmm/dashboard/ (nginx), https://rmm.azcomputerguru.com
- Build log: /tmp/gururmm-build-rbac-*.log, /tmp/gururmm-build-policy-*.log

### Commands & Outputs

```bash
# Fix duplicate migration
ssh guru@172.16.3.30 "cd /home/guru/gururmm && git rm server/migrations/022_asset_inventory.sql && git commit -m '...' && git push 172.16.3.20:azcomputerguru/gururmm.git main"

# Apply migration 024
ssh guru@172.16.3.30 "PGPASSWORD=43617ebf7eb242e814ca9988cc4df5ad psql -U gururmm -d gururmm -h localhost -f /dev/stdin" < server/migrations/024_policy_checks.sql

# Migration checksum insert (python3 on Jupiter)
python3 -c "import hashlib; data=open('server/migrations/024_policy_checks.sql','rb').read(); print('\\x' + hashlib.sha384(data).hexdigest())"
# → insert into _sqlx_migrations (version 24)

# Rebuild server
ssh guru@172.16.3.30 "nohup sudo bash /opt/gururmm/build-server.sh > /tmp/gururmm-build-XYZ.log 2>&1 &"
# Build time: ~3m50s each run

# Deploy dashboard
ssh guru@172.16.3.30 "cd /home/guru/gururmm/dashboard && npm run build && cp -r dist/* /var/www/gururmm/dashboard/"

# Sync stale local clone
git stash && git fetch http://172.16.3.20:3000/azcomputerguru/gururmm.git main && git rebase FETCH_HEAD
```

**Key build outputs:**
- `Finished release profile [optimized] target(s) in 3m 49s–3m 58s` (all builds clean)
- `=== Server build complete: v0.3.0 ===` (version field in binary still 0.3.0 — coordination API tracks 0.6.4)
- All cargo check runs: 0 errors, 69-70 pre-existing warnings

### Pending / Incomplete Tasks

- **Minor deferred from Phase 2 review**: `alert_id` in webhook payload still empty string (create_check_alert return value not captured); SQL clarity in `get_effective_alert_template_for_agent` (cross-join style without explicit agent constraint); macOS inventory uses blocking `std::process::Command`; PowerShell service enum may return integer strings on older PS versions
- **Pre-commit hook not executable**: `/home/guru/gururmm/scripts/hooks/pre-commit` — hook is ignored every commit. Should `chmod +x` if the hook is intended to run
- **Enrollment key WS auth**: Reverted out-of-scope addition. The enrolled agent flow (first WS connect after enrollment) is not yet wired — agents enrolled via POST /api/enroll cannot connect via WS with their enrollment key. Tracked for a future session
- **Code chunk size warning**: Dashboard bundle >500KB. Vite suggests dynamic import() / manualChunks. Not blocking but worth addressing before go-live
- **`auth.role != "admin"` in authz/permissions.rs tests**: Tests use `roles::ADMIN` string — those should be updated to use `is_admin()` if tests are run
- **Users page org-membership lookup**: The current implementation scans all orgs to find which ones a user belongs to — O(users × orgs). Acceptable for small teams, but a dedicated `/api/users/:id/organizations` endpoint would be cleaner

### Reference Information

- Gitea repo: http://172.16.3.20:3000/azcomputerguru/gururmm (internal, not git.azcomputerguru.com)
- Commits this session:
  - `872b192` — fix(migrations): remove duplicate 022_asset_inventory.sql
  - `90e8ae6` — fix(server): Phase 2 code review fixes (5 items)
  - `302e605` — feat(server+dashboard): policy-to-checks
  - `e37679b` — feat(server+dashboard): RBAC enforcement + Users UI + 023 migration to git
- Coord lock IDs used: `156d8e21` (Phase 2, released), `7ef71fd8` (policy-to-checks, released), `7968ca68` (RBAC, released)
- Migration 024 applied: policy_checks + checks.policy_check_id FK + UNIQUE(agent_id, policy_check_id)
- DB _sqlx_migrations rows: 1-24 all present, checksums matching compiled binary
- gururmm-server binary: /opt/gururmm/gururmm-server (11.5MB stripped release build)
- Dashboard: /var/www/gururmm/dashboard/ (1.07KB HTML + 57.7KB CSS + 1.07MB JS, gzipped 308KB)
- claudetools commit `c13947e`: submodule pointer at `4b43878`