azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f4fb1315297a01acfc95874d503871382c05a863
claudetools/session-logs/2026-05-24-wiki-layer.md
Mike Swanson 5b82b1d15f sync: auto-sync from GURU-5070 at 2026-05-24 19:43:29 
Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-05-24 19:43:29
2026-05-24 19:43:32 -07:00

22 KiB
Raw Blame History

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

Update: ~17:30 PT — Wiki seeding continued (Dataforth, 11 more clients)

Session Summary

Continued wiki seeding pass. Verified all previously seeded articles against live data and Mike's corrections, then seeded 13 additional articles across clients and projects.

Dataforth Corporation and the dataforth-dos project were seeded together via a single agent that read 23 client session logs, 15 docs, 10 project session logs, CONTEXT.md, and 7 memory files. The resulting articles are among the most detailed in the wiki: 278 lines for the client (64 DOS test stations, full contact table, all server IPs, M365/CA policy IDs, security incident history, GuruRMM enrollment workaround) and 474 lines for the project (pipeline architecture diagram, PostgreSQL schema, FAIL→PASS retest rule, H-prefix decode table, full security incident timeline with IC3 submission ID, D2TESTNAS role, Neptune SBR routing, Hoffman API endpoints). Mike reviewed both and confirmed they looked correct.

Instrumental Music Center and Valley Wide Plastering were seeded in parallel. IMC surfaced a critical SQL instance naming trap (SQL Server 2019 Standard installed as SQLEXPRESS — not the Express edition) and a phantom DC (ServerIMC 192.168.0.63) causing intermittent slow logons. Valleywide surfaced a VB6/Access 97 app modernization project with 130 tables and 791 Crystal Reports, plus a certified payroll legal requirement that constrains the rewrite approach.

Nine more client articles were seeded in a second parallel batch: internal-infrastructure, peaceful-spirit, cryoweave, glaztech, pavon, grabb-durando, stamback-septic, sombra-residential, birth-biologic. Several critical findings emerged: Neptune's Let's Encrypt cert expires 2026-05-31 and DkimSigner is currently disabled (unsigned outbound mail). Grabb & Durando's README contains a plaintext database password. Sombra Residential's "Server2013" is actually Windows Server 2012 (EOL Oct 2023), unpatched and on the network. Glaz-Tech had two phishing campaigns bypass MailProtector via a secondary MX record — both fixed, but no MFA enforcement is in place.

Key Decisions

  • Live API verification before documenting fleet state — queried GET /api/agents with JWT to get the authoritative agent list. Confirmed BB-SERVER and RECEPTIONIST-PC are on 0.6.38 (laggard note was stale within the same day). Full 12-client list written to gururmm.md from live data.
  • Batch small clients into parallel agent runs — clients with 1-3 session logs were grouped (3-4 per agent) to minimize total wall-clock time while keeping article quality high.
  • Dataforth + dataforth-dos seeded as a single agent pass — the two articles share heavy source overlap (same session logs, same memory files). One agent reading everything once is cheaper than two agents redundantly reading the same files.
  • Neptune cert urgency flagged in commit message — expiry 2026-05-31 is days away; surfaced in commit subject so it appears in git log without needing to open the article.

Problems Encountered

  • Push rejected (fetch first) — 3 occurrences — remote had incoming commits between local commit and push each time (sync from another session or machine). Resolved with git pull --rebase && git push each time.
  • Coord message parse failure on em dash — inline JSON with — in subject field caused "error parsing body". Resolved by writing JSON to /tmp/coord_msg.json and using -d @/tmp/coord_msg.json.

Configuration Changes

Created (wiki articles):

  • wiki/clients/dataforth.md (278 lines)
  • wiki/projects/dataforth-dos.md (474 lines)
  • wiki/clients/instrumental-music-center.md
  • wiki/clients/valleywide.md
  • wiki/clients/internal-infrastructure.md
  • wiki/clients/peaceful-spirit.md
  • wiki/clients/cryoweave.md
  • wiki/clients/glaztech.md
  • wiki/clients/pavon.md
  • wiki/clients/grabb-durando.md
  • wiki/clients/stamback-septic.md
  • wiki/clients/sombra-residential.md
  • wiki/clients/birth-biologic.md

Modified:

  • wiki/index.md — Clients and Projects tables expanded; Cross-Reference expanded; compilation queue updated
  • wiki/projects/gururmm.md — Fleet state corrected; enrolled client list expanded from 4 to 12 clients
  • wiki/overview.md — Fleet count and client table updated
  • wiki/clients/cascades-tucson.md — Syncro contact rule globalized
  • .claude/memory/feedback_syncro_cascades_contact.md — narrowed to incident detail only
  • .claude/memory/MEMORY.md — index entry updated

Credentials & Secrets

  • GuruRMM API JWT obtained from vault (infrastructure/gururmm-server.sops.yaml) for fleet verification. Not stored. No new credentials created.
  • [ACTION] Grabb & Durando: plaintext DB password found in clients/grabb-durando/website-migration/README.md — needs to be moved to vault.

Infrastructure & Servers

Dataforth (verified from session logs):

  • AD1 192.168.0.27 (primary DC, C: at 90% — critical)
  • AD2 192.168.0.6 (testdatadb, PostgreSQL, firewall disabled)
  • D2TESTNAS 192.168.0.9 (SMB1 bridge, Neptune host)
  • SAGE-SQL 192.168.0.153 (Sage ERP + RDS)
  • UDM 192.168.0.254 (C2 iptables not persistent)
  • M365 tenant: dataforth.com, ID 7dfa3ce8-c496-4b51-ab8d-bd3dcd78b584

ACG Internal (from internal-infrastructure article):

  • Neptune Exchange cert (Let's Encrypt) expires 2026-05-31 — urgent
  • Neptune DkimSigner currently DISABLED — outbound mail unsigned
  • Cloudflare tunnel deployed on Jupiter (Cox BGP workaround) — 9 hostnames tunneled
  • rmm-api.azcomputerguru.com must remain grey-cloud (WebSocket)

Peaceful Spirit: PST-SERVER 192.168.0.2, UCG WAN 98.190.129.150 Glaztech: M365 tenant ID 82931e3c-de7a-4f74-87f7-fe714be1f160, Syncro ID 143932

Pending / Incomplete Tasks

  • Neptune cert renewal — URGENT — Let's Encrypt cert expires 2026-05-31. Days away.
  • Neptune DkimSigner — currently disabled; outbound mail unsigned. Re-enable after cert renewal.
  • Grabb & Durando plaintext password — vault it from clients/grabb-durando/website-migration/README.md
  • C2 iptables on Dataforth UDM — not persistent; add 80.76.49.18 and 45.88.91.99 to UniFi UI permanently
  • Glaztech MFA rollout — service account auth audit required first; do not enable Security Defaults yet
  • Sombra Residential Server2013 — actually WS2012 EOL; present EOL recommendation to client
  • Stamback Septic Syncro duplicate — possible second record 34021422; investigate
  • BirthBiologic SharePoint migration — SPMT completion unconfirmed; check status
  • Pavon Nextcloud migration — deferred to 3–6 month window; OwnCloud data dir at 74% capacity
  • NPM stale proxy — rmm-api.azcomputerguru.com → 172.16.3.20:3001 should be .30:3001
  • Wiki — remaining unseeded clients: kittle, anaise, khalsa, bg-builders, evs, furrier, horseshoe-management, kittle-design, scileppi-law, western-tire, lens-auto-brokerage, at-trebesch, sandteko-machinery, mvan-inc
  • Wiki — unseeded projects: discord-bot, radio-show, msp-pricing
  • Wiki — systems: neptune, d2testnas still in compilation queue

Reference Information

  • Commits this update: 85e8342/63109d9 (Dataforth), da40eeb/b583aee (IMC + Valleywide), 32f64a9 (9 clients)
  • GuruRMM live fleet: 55 agents, 12 clients, 40/55 on v0.6.38
  • Dataforth DOS pipeline stats: 469K records, 458.5K live, daily task 02:30 AM
  • Dataforth IC3 submission: 1c32ade367084be9acd548f23705736f
  • Neptune cert expiry: 2026-05-31 (Let's Encrypt)
Reference in New Issue View Git Blame Copy Permalink