wiki: add capability synthesis to wiki-compile; recompile GuruRMM

Skill + template:
- wiki-compile Phase 2P: type-aware authoritative-artifact discovery for
  projects (migrations, API routes, agent modules, roadmap-done, commit log),
  with a stale-submodule guard that reads origin/main when the pinned
  submodule lags. Changelogs treated as incomplete, not authoritative.
- project template: add a Capabilities / Feature Set section.

GuruRMM recompile (from live main artifacts, not session logs):
- Added Capabilities / Feature Set section covering monitoring, remote
  execution (incl. system vs user_session contexts), inventory/discovery,
  update mgmt, policy, alerting/watchdog, backup, tunnel, identity/security.
- Fixed the misleading "runs as LocalSystem" command-fields line (the gap
  that started this) and the stale BUG-001 temperature claim (now shipped).
- Qualified Entra-only SSO; noted safe-rollout is unwired scaffolding.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.claude/commands/wiki-compile.md

@@ -167,6 +167,48 @@ Only the count is used — individual asset details go in session logs and clien
 
 ---
 
+## Phase 2P — Authoritative Artifact Discovery (projects only)
+
+**Applies when `TARGET_TYPE == project`.** Skip for clients/systems.
+
+Session logs narrate *work done and why* — they are a structurally incomplete record of *what a product can do*. For a code-bearing project, the authoritative capability record is the **code, migrations, API routes, and roadmap**, not the logs. Compiling a project from logs alone WILL miss shipped features (this is exactly how the GuruRMM `user_session` command context was missed). So for projects, dig into the artifacts directly.
+
+### 2P-a — Locate the repo and guard against a stale submodule
+
+Many projects are tracked as a **pinned git submodule** whose commit deliberately lags the live repo. Reading the working tree alone gives stale artifacts. Always check:
+
+```bash
+REPO="$CLAUDETOOLS_ROOT/projects/<path-to-submodule-or-repo>"
+cd "$REPO"
+git fetch origin main 2>/dev/null
+PINNED=$(git rev-parse --short HEAD)
+LIVE=$(git rev-parse --short origin/main)
+echo "pinned=$PINNED live=$LIVE"
+# If they differ, read artifacts from origin/main, NOT the working tree.
+REF="origin/main"   # use this ref for all artifact reads below; falls back to HEAD if no remote
+```
+
+Read live artifacts without disturbing the pinned pointer, either via `git show $REF:<path>` / `git ls-tree -r --name-only $REF -- <dir>`, or by creating a throwaway worktree: `git worktree add /tmp/<proj>-live $REF` (remove with `git worktree remove` when done).
+
+### 2P-b — Gather authoritative artifacts (priority order)
+
+1. **DB migrations** — `git ls-tree -r --name-only $REF -- <migrations-dir>`. Each migration is a feature/schema checkpoint; the filenames alone are a capability timeline (e.g. `041_add_command_context`). This is the most reliable signal and is usually current even when changelogs are not.
+2. **API routes** — the real server surface. Read the route-registration file(s) (e.g. `server/src/api/mod.rs`) and the per-resource handler modules. Enumerate endpoints + notable request options (auth modes, contexts, scopes).
+3. **Agent / client capabilities** — module tree of the agent/client (e.g. `agent/src/`): metrics, checks, command execution, updater, tunnel, watchdog, inventory, registry ops. Note **per-platform coverage**.
+4. **Completed roadmap items** — `docs/FEATURE_ROADMAP.md` checked/done items.
+5. **Specs** — `docs/specs/` (shipped vs proposed).
+6. **Commit log** — `git log --oneline $REF` filtered for `feat`/`perf` since the article's `last_compiled`. Fuller and more current than changelogs.
+7. **Changelogs** — read if present, but treat as **incomplete** (they are frequently stale — verified on GuruRMM: committed changelogs stopped at v0.6.22 while the fleet ran 0.6.39+). Never rely on them as the sole capability source.
+8. **README / DESIGN / ARCHITECTURE docs** — for framing and locked decisions.
+
+### 2P-c — Synthesize the Capabilities / Feature Set section
+
+From the artifacts above, produce the **Capabilities / Feature Set** section (see project template). Organize by surface (monitoring, remote execution, management, integrations, security). Explicitly capture **execution modes and important options** — e.g. command contexts (`system` vs `user_session`), auth modes, policy scopes, platform coverage. Cross-check the existing article (full recompile) and **correct any capability statement that is now incomplete or wrong** (e.g. "runs as LocalSystem" without the user-session context).
+
+For large repos, delegate the artifact read + synthesis to an agent (general-purpose) pointed at the live ref/worktree, and integrate the returned section after review — don't flood the main context with the full code/migration dump.
+
+---
+
 ## Phase 3 — Session Log Discovery
 
 Find all session logs that mention this client: