# Session Log — 2026-05-24 Wiki Layer Implementation

## User
- **User:** Mike Swanson (mike)
- **Machine:** DESKTOP-0O8A1RL
- **Role:** admin
- **Session span:** Afternoon

---

## Session Summary

Mike shared a tweet from Andrej Karpathy describing an LLM knowledge base workflow: raw source documents compiled by an LLM into a markdown wiki, then queried via LLM agents. Mike asked whether this approach was applicable to ClaudeTools and, if beneficial, how to implement it.

Analysis confirmed strong applicability. ClaudeTools already had the raw data layer (session logs) and live state layer (CONTEXT.md, coord API), but was missing a compiled knowledge layer in between. Every session start required re-synthesizing context from 5-15 raw logs — wasteful, lossy, and Howard-hostile. The wiki layer fills exactly that gap.

A full spec was written (.claude/specs/wiki-layer/), covering shape, phased implementation plan, article standards/templates, and all integration references. Phase 0 (directory structure, templates, CLAUDE.md wiring) was completed in-session. Phase 1 (seed pass) was also completed in-session for the two highest-value targets: Cascades of Tucson and GuruRMM.

Two parallel agents read all available session logs, memory files, CONTEXT.md, and infrastructure docs for each target and synthesized full wiki articles. Both articles were reviewed and written to disk. During review, several hostname/IP assumption errors were caught through user correction — Neptune is the old ACG mail server (physically at Dataforth D2, not the ACG office), Jupiter is 172.16.3.20 (not .30), and the machine at 172.16.3.30 is the GuruRMM VM (hostname: gururmm-build). A full IP/hostname audit was done against credentials.md, pluto.md, and infra_office_network.md to produce a verified map. Neptune's unusual situation (ACG infrastructure at a client's physical location, with a subnet overlap TODO) was captured in both the memory file and wiki index.

Mike also proposed a top-level overview.md article (cold-start orientation doc: team, all clients, all projects, key infra, tooling). Added to spec plan as Phase 1 final step, compiling from other wiki articles rather than raw logs.

---

## Key Decisions

- **Wiki compiles from wiki, not raw logs, for `overview.md`** — overview article reads other wiki articles as its source material, making it cheap to maintain and always internally consistent. Goes last in the seed queue, after systems are compiled.
- **`/wiki-compile overview` scope added** — distinct scope that reads compiled wiki articles rather than session logs directly.
- **Slug: `cascades-tucson` not `cascades`** — canonical client folder is `clients/cascades-tucson/`; wiki article named to match.
- **System slug: `gururmm-build`** — the GuruRMM VM at 172.16.3.30 uses this slug throughout the wiki, matching its SSH hostname.
- **Neptune is active, not decommissioned** — Exchange 2016, active mail for multiple ACG-hosted clients, physically at Dataforth D2. Distinct from Saturn (decommissioned) and from ACG office infrastructure.
- **Dataforth UDM subnet overlap flagged as TODO** — Dataforth UDM uses overlapping 172.16.x.x addressing with ACG office LAN, forcing Neptune access through D2TESTNAS. Captured as a TODO in memory and wiki index for eventual resubnetting.
- **credentials.md NPM proxy is stale** — entry shows `rmm-api.azcomputerguru.com → 172.16.3.20:3001` but GuruRMM API is on 172.16.3.30 (migrated from Jupiter container to own VM). Stale entry noted in wiki backlinks; NPM should be updated on Jupiter.

---

## Problems Encountered

- **Multiple hostname/IP assumption errors** — Initial wiki entries incorrectly associated Neptune with 172.16.3.30, then Jupiter with 172.16.3.30. Caught by user through two rounds of correction. Root cause: Claude synthesized from session logs without consulting the authoritative machines/ and memory/ files first. Resolution: read credentials.md, pluto.md, and infra_office_network.md to produce verified map before writing any system references.
- **Cascades client folder path** — Agent correctly identified that `clients/cascades/` does not exist; canonical path is `clients/cascades-tucson/`. Wiki article named accordingly.
- **Saturn in GuruRMM fleet** — Agent found "Saturn" listed as an enrolled GuruRMM agent but Saturn is decommissioned (IP 172.16.3.21 reused by Uranus, Apr 2026). Flagged in wiki article as possibly stale or actually Uranus.

---

## Configuration Changes

**Created:**
- `.claude/specs/wiki-layer/shape.md` — problem, solution, scope, success criteria
- `.claude/specs/wiki-layer/plan.md` — phased implementation plan (Phases 0-5) + overview article spec
- `.claude/specs/wiki-layer/standards.md` — article templates (client, project, system, pattern), index format, naming rules
- `.claude/specs/wiki-layer/references.md` — all files read/written, integration points, Karpathy reference
- `wiki/index.md` — master wiki index with compilation queue
- `wiki/clients/.gitkeep`
- `wiki/projects/.gitkeep`
- `wiki/systems/.gitkeep`
- `wiki/patterns/.gitkeep`
- `wiki/_templates/client.md`
- `wiki/_templates/project.md`
- `wiki/_templates/system.md`
- `wiki/_templates/pattern.md`
- `wiki/clients/cascades-tucson.md` — full synthesized client article (25+ session logs, 7 memory files, 5 infra docs)
- `wiki/projects/gururmm.md` — full synthesized project article (37 session logs, multiple memory/doc files)

**Modified:**
- `.claude/CLAUDE.md` — auto-context-loading table updated (wiki checked first for client/project/system mentions); Context Recovery section updated; Commands table updated with `/wiki-compile` and `/wiki-lint`
- `.claude/FILE_PLACEMENT_GUIDE.md` — wiki row added to quick reference table
- `.claude/memory/infra_office_network.md` — Neptune section added (physical location at Dataforth D2, subnet overlap TODO, routing note)

---

## Credentials & Secrets

None created or discovered this session.

---

## Infrastructure & Servers

**Verified IP/hostname map (from credentials.md + pluto.md + infra_office_network.md):**

| IP | Hostname | Role |
|---|---|---|
| 172.16.0.1 | pfSense | Router, DNS, Tailscale subnet router |
| 172.16.3.20 | Jupiter | Unraid NAS; virsh host for all VMs; Docker: Gitea, NPM, Seafile |
| 172.16.3.21 | Uranus | OwnCloud additional storage only; Dell R730xd; formerly Saturn's IP |
| 172.16.3.30 | gururmm-build (GuruRMM VM) | Linux VM on Jupiter; GuruRMM API 3001, ClaudeTools API 8001, Coord API, MariaDB, PostgreSQL, build pipeline |
| 172.16.3.36 | Pluto / Claude-Builder | Windows Server 2019 virsh VM on Jupiter; Windows MSI/cargo build server |
| 172.16.3.11 | neptune.acghosting.com | Exchange 2016; ACG infra physically at Dataforth D2; 67.206.163.124 external |
| Saturn | DECOMMISSIONED | Was 172.16.3.21; IP reused by Uranus Apr 2026 |

**Stale entry to fix:** NPM on Jupiter still proxies `rmm-api.azcomputerguru.com → 172.16.3.20:3001`. Should point to 172.16.3.30:3001.

---

## Pending / Incomplete Tasks

- **Wiki seed — systems:** `system:gururmm-build`, `system:jupiter`, `system:pluto`, `system:uranus` — all in compilation queue in wiki/index.md
- **Wiki seed — overview:** `wiki/overview.md` — compile AFTER systems seeded; reads other wiki articles
- **wiki/commands/wiki-compile.md** — command skill not yet implemented (Phase 2)
- **wiki/commands/wiki-lint.md** — command skill not yet implemented (Phase 4)
- **NPM stale proxy:** Update `rmm-api.azcomputerguru.com` proxy on Jupiter from 172.16.3.20:3001 → 172.16.3.30:3001
- **Dataforth UDM resubnet:** TODO captured in memory and wiki index; eliminates Neptune routing workaround via D2TESTNAS
- **Saturn GuruRMM agent:** Verify whether enrolled "Saturn" agent is stale or is actually Uranus; clean up if stale

---

## Reference Information

- Wiki spec: `.claude/specs/wiki-layer/`
- Wiki root: `wiki/`
- Karpathy post: https://x.com/karpathy/status/2039805659525644595 (2026-04-02)
- Cascades wiki article: `wiki/clients/cascades-tucson.md` (last_compiled: 2026-05-24)
- GuruRMM wiki article: `wiki/projects/gururmm.md` (last_compiled: 2026-05-24)

---

## Update: ~23:45 PT — Wiki completion, verification pass, corrections

### Session Summary

Session resumed after context window reset. The 4 system wiki articles (gururmm-build, jupiter, pluto, uranus) had already been written to disk in the previous context portion. This continuation updated `wiki/index.md` to reflect all 4 as seeded and removed them from the compilation queue, then committed and pushed. `wiki/overview.md` was compiled directly from all 6 seeded articles plus CLAUDE.md — covering team, all clients, internal projects, full infrastructure table, tooling stack, key URLs, and cross-cutting open action items. Committed and pushed. The overview went last in the seed queue as designed, reading from other wiki articles rather than raw logs.

A full verification pass was run against each seeded article with Mike confirming accuracy or providing corrections one by one. Cascades of Tucson required one correction: the Syncro blank-contact rule is global (not Cascades-specific), so the article wording and the associated memory file were updated accordingly. A coord message was sent to Howard (ACG-TECH03L/claude-main) asking him to review the Cascades article from his onsite perspective.

GuruRMM required significant corrections. The BB-SERVER and RECEPTIONIST-PC laggard note was stale — both were already on 0.6.38. The enrolled client/site list in the wiki had only 4 entries; the live API returned 55 agents across 12 clients. The full list was pulled via authenticated API call and written into the article. Mike confirmed all 12 clients as legitimate, noting some are Residential vs Corporate but all should be treated as active. The Saturn agent concern was resolved — that agent no longer appears in the API. The actual laggards are 15 offline machines on older versions that will self-update on reconnect. All 4 system articles were verified accurate with no changes required.

### Key Decisions

- **Verify from live API before documenting fleet state** — the cached laggard note was wrong within the same day. Fleet data now pulled from `GET /api/agents` at verification time rather than trusted from session-log memory.
- **Syncro contact rule is global** — Mike confirmed on 2026-05-24 that "do not set contact unless requested" applies to all customers. Updated memory file and Cascades wiki article to reflect this; the global rule was already in `feedback_syncro_blank_contact.md`, so `feedback_syncro_cascades_contact.md` was narrowed to the Meredith Kuhn incident detail only.
- **Residential vs Corporate client distinction noted but not blocking** — Mike confirmed all 12 enrolled clients are legitimate; Residential/Corporate distinction captured in the client type column of the GuruRMM article for future reference.
- **Saturn agent resolved** — no "Saturn" labeled agent appears in the current API response. Concern removed from wiki and no cleanup action needed.

### Problems Encountered

- **Coord message parse failure (3 attempts)** — `curl` with inline JSON containing an em dash in the subject field caused "error parsing body". Resolved by writing the JSON payload to `/tmp/coord_msg.json` and using `-d @/tmp/coord_msg.json`. Root cause: shell encoding of the em dash character in the single-quoted string.
- **Agent version field mismatch** — initial API query used `version` field; actual field is `agent_version`. All versions showed as `?`. Fixed on second query after inspecting raw agent object structure.
- **Push rejected (fetch first)** — a sync from another machine had pushed between commits. Resolved with `git pull --rebase && git push`.

### Configuration Changes

**Modified:**
- `wiki/index.md` — Systems table updated (4 articles now seeded); overview row marked compiled; gururmm-build/jupiter/pluto/uranus and overview removed from compilation queue
- `wiki/clients/cascades-tucson.md` — Syncro contact rule wording updated to reflect global scope
- `wiki/projects/gururmm.md` — Fleet state corrected; enrolled client/site list expanded from 4 to 12 clients; Saturn agent concern removed; actual laggards documented
- `wiki/overview.md` — Fleet count and client table updated to match corrected GuruRMM data
- `.claude/memory/feedback_syncro_cascades_contact.md` — Narrowed to Meredith Kuhn incident detail; global rule pointer added
- `.claude/memory/MEMORY.md` — Index entry for cascades contact file updated to match

**Created:**
- `wiki/systems/gururmm-build.md` — committed this session (written in previous context)
- `wiki/systems/jupiter.md` — committed this session
- `wiki/systems/pluto.md` — committed this session
- `wiki/systems/uranus.md` — committed this session
- `wiki/overview.md` — compiled and committed this session

### Credentials & Secrets

- GuruRMM API admin credentials accessed from vault (`infrastructure/gururmm-server.sops.yaml`) for live API verification. No new credentials created.

### Infrastructure & Servers

**Live GuruRMM fleet (verified 2026-05-24 ~23:30 PT):**
- 55 agents total, 37 online, 40/55 on v0.6.38
- 12 enrolled clients (see GuruRMM wiki article for full table)
- Laggards: 15 offline agents on v0.6.1 through v0.6.29 — all will self-update on reconnect

**Coord message sent:**
- ID: `33d1576d-02d2-4940-8e97-7d8c5140e8c0`
- To: `ACG-TECH03L/claude-main` (Howard)
- Subject: Review Cascades wiki article — needs your onsite context

### Pending / Incomplete Tasks

- **Howard review of cascades-tucson.md** — coord message sent; awaiting his corrections
- **NPM stale proxy** — `rmm-api.azcomputerguru.com → 172.16.3.20:3001` should be `.30:3001`. Fix in NPM admin at http://172.16.3.20:7818. Still unresolved.
- **wiki/commands/wiki-compile.md** — skill not yet implemented (Phase 2)
- **wiki/commands/wiki-lint.md** — skill not yet implemented (Phase 4)
- **Dataforth UDM resubnet** — TODO; eliminates Neptune routing workaround via D2TESTNAS
- **Wiki seed — neptune, birthbiologic, key-paul** — still in queue, lower priority
- **Mikes-MacBook-Air.local** — GuruRMM agent on v0.6.1 (macOS), significantly behind fleet. Needs manual update or investigation.

### Reference Information

- Commits this session: `7daca57` (4 system articles), `cbbea8b` (overview), `3a188dc`→`e4d3c1f` (contact rule corrections, rebased), `2f99a01` (GuruRMM corrections)
- Wiki root: `wiki/`
- GuruRMM API agents endpoint: `GET http://172.16.3.30:3001/api/agents` (JWT required)
- Coord message to Howard: ID `33d1576d-02d2-4940-8e97-7d8c5140e8c0`