azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add wiki knowledge layer (Phase 0 + Phase 1 seed)

Browse Source 
Implements LLM-compiled wiki layer between raw session logs and live
CONTEXT.md, inspired by Karpathy's knowledge base workflow. Adds wiki/
directory structure, article templates, spec docs, and seeds first two
articles (Cascades of Tucson, GuruRMM) from 60+ session logs.

Updates CLAUDE.md to check wiki first on all context-loading triggers.
Captures verified ACG IP/hostname map and Neptune physical-location
clarification (Dataforth D2, subnet overlap TODO) in memory.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Mike Swanson
2026-05-24 15:42:38 -07:00
parent 435e921300
commit cd80f5e447
19 changed files with 1533 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
.claude/CLAUDE.md
View File

@@ -119,12 +119,15 @@ Load context **before responding** when any trigger fires. Never ask for info th
| Trigger | Action |
|---------|--------|
| GuruRMM / Dataforth / project keywords | Read `projects/<project>/CONTEXT.md`, query coord API status + components |
| "continue", "resume", "back to", "finish" | Read project CONTEXT.md, check coord API for locks + unread messages |
| Servers, IPs, credentials, deploy questions | Read CONTEXT.md — answer from it, never ask |
| Uncertainty >5% about infra or recent work | Read CONTEXT.md before asking the user |
| Client name mentioned | Read `wiki/clients/<slug>.md` FIRST, then `clients/<name>/session-logs/` for recent detail |
| GuruRMM / Dataforth / project keywords | Read `wiki/projects/<slug>.md` FIRST, then `projects/<project>/CONTEXT.md`, query coord API status + components |
| Server/hostname/IP mentioned | Read `wiki/systems/<slug>.md` FIRST for synthesized knowledge |
| "continue", "resume", "back to", "finish" | Read project wiki article + CONTEXT.md, check coord API for locks + unread messages |
| Servers, IPs, credentials, deploy questions | Check wiki/systems first, then CONTEXT.md — answer from it, never ask |
| Uncertainty >5% about infra or recent work | Check wiki first, then CONTEXT.md before asking the user |
CONTEXT.md locations: `projects/msp-tools/guru-rmm/CONTEXT.md`, `projects/dataforth-dos/CONTEXT.md`, `CONTEXT.md` (root).
Wiki location: `wiki/` (root) — `wiki/clients/`, `wiki/projects/`, `wiki/systems/`, `wiki/patterns/`. Index: `wiki/index.md`.
---
@@ -212,6 +215,7 @@ Also scan session logs pulled during `/sync` for legacy `## Note for <user>` sec
## Context Recovery
When user references previous work, use `/context` command. Never ask for info in:
- `wiki/` — **Check first.** LLM-compiled synthesized knowledge by client/project/system. Index: `wiki/index.md`
- `credentials.md` — Infrastructure reference (being migrated to SOPS vault)
- `session-logs/` — Daily work logs (also in `projects/*/session-logs/` and `clients/*/session-logs/`)
- **Coordination API** — current locks, component states, workflows, messages: `GET http://172.16.3.30:8001/api/coord/status`
@@ -246,7 +250,9 @@ Vault structure: `infrastructure/`, `clients/`, `services/`, `projects/`, `msp-t
|---------|---------|
| `/checkpoint` | Dual checkpoint: git commit + database context |
| `/save` | Comprehensive session log |
| `/context` | Search session logs, credentials.md, and 1Password |
| `/context` | Search wiki first, then session logs, credentials.md, and 1Password |
| `/wiki-compile` | Compile session logs into wiki articles for a client/project/system/all |
| `/wiki-lint` | Health-check wiki for stale IPs, broken backlinks, orphaned articles |
| `/1password` | 1Password secrets management |
| `/sync` | Sync config from Gitea repository |
| `/create-spec` | Create app specification for AutoCoder |

1
.claude/FILE_PLACEMENT_GUIDE.md
View File

@@ -20,6 +20,7 @@
| GuruRMM Session Logs | RMM work | `session-logs/YYYY-MM-DD-session.md` (root — NOT in gururmm submodule) |
| General Session Logs | Mixed work | `session-logs/YYYY-MM-DD-session.md` |
| Credentials | All credentials | `credentials.md` (root - shared) |
| **Wiki articles** | Compiled knowledge | `wiki/clients/`, `wiki/projects/`, `wiki/systems/`, `wiki/patterns/` — LLM-maintained, do not edit manually |
---

9
.claude/memory/infra_office_network.md
View File

@@ -27,4 +27,11 @@ ACG office LAN is 172.16.0.0/22, routed via Tailscale through pfSense node `pfse
**VMs on Jupiter (virsh):** GuruRMM, Unifi, OwnCloud, Claude-Builder (running); Windows 7, Windows Server 2016, Windows Server 2016_Template (shut off).
**Why:** How to apply: see [[power-failure-runbook]] for full post-outage recovery steps.
**Neptune (ACG infra, physically at Dataforth D2):**
- neptune.acghosting.com | internal 172.16.3.11 | external 67.206.163.124
- Exchange Server 2016 — active mail server for multiple ACG-hosted clients
- Physically colocated at Dataforth's D2 facility, NOT at ACG office
- Access from ACG office: must route through D2TESTNAS (192.168.0.9) because Dataforth's UDM runs a subnet overlapping ACG office LAN (both use 172.16.x.x range), making direct routing ambiguous
- **TODO:** Resubnet Dataforth UDM to a non-overlapping range to fix routing and simplify Neptune access
**Why:** How to apply: see [[power-failure-runbook]] for full post-outage recovery steps. Neptune is NOT on ACG office LAN despite the 172.16.x.x IP — always route via D2TESTNAS or Dataforth VPN.

197
.claude/specs/wiki-layer/plan.md Normal file
View File

@@ -0,0 +1,197 @@
# Wiki Layer — Implementation Plan
**Status:** Phase 1 in progress (Cascades + GuruRMM seeded 2026-05-24)
---
## Phase 0 — Structure (no code, low effort, high foundation value)
**Goal:** Create the directory skeleton and article templates. Nothing else runs yet.
### Tasks
- [ ] Create `wiki/` root with `index.md` stub
- [ ] Create `wiki/clients/`, `wiki/projects/`, `wiki/systems/`, `wiki/patterns/` directories
- [ ] Write article templates (see `standards.md`)
- [ ] Add `.gitkeep` files so empty dirs commit
- [ ] Verify GrepAI watcher picks up `wiki/` automatically (it should — it watches the repo root)
- [ ] Add `wiki/` mention to `CLAUDE.md` context-loading section (read `wiki/<topic>.md` when topic is known)
**Done when:** Directory exists, templates written, GrepAI indexes it.
---
## Phase 1 — Seed Pass (high effort, immediate ROI)
**Goal:** Compile first-pass wiki articles for the two highest-value targets: GuruRMM and Cascades.
### Approach
Run `/wiki-compile` manually, read and correct output, commit. This is a supervised pass — we're validating the compilation quality before automating.
### Tasks
- [ ] Compile `wiki/projects/gururmm.md` from `projects/msp-tools/guru-rmm/session-logs/` + root session logs mentioning GuruRMM
- [ ] Compile `wiki/clients/cascades.md` from `clients/cascades/session-logs/` + root logs mentioning Cascades
- [ ] Compile `wiki/systems/` entries for Neptune, Jupiter, Pluto, Saturn (from session logs + credentials.md)
- [ ] Mike reviews each article, corrects factual errors, commits
- [ ] Run second seed pass for remaining active clients and projects
**Done when:** All active clients and systems have wiki articles. Mike has reviewed at least Cascades + GuruRMM.
---
## Phase 2 — `/wiki-compile` Command
**Goal:** Implement the compile command as a repeatable skill.
### Command behavior
```
/wiki-compile [scope]
Scopes:
client:<name> Compile from clients/<name>/session-logs/ + matching root logs
project:<name> Compile from projects/<name>/session-logs/ + matching root logs
system:<name> Compile from all logs mentioning the system name or hostname
all Full pass — all articles, oldest-first by last_compiled date
Without scope: prompt user to select
```
### Steps Claude takes when `/wiki-compile` is invoked
1. Identify scope from argument
2. Find relevant session logs (by directory + GrepAI keyword search)
3. Read existing wiki article if it exists (note `last_compiled` date)
4. Read session logs newer than `last_compiled` (or all if new article)
5. Read relevant CONTEXT.md and memory entries for cross-reference
6. Call Ollama (qwen3:8b) to generate/update the article
- Summarize new information, merge with existing
- Update backlinks section
- Update `last_compiled` frontmatter
7. Present diff to user for review before writing
8. On approval: write article, update `wiki/index.md`
### Tasks
- [ ] Write `.claude/commands/wiki-compile.md` (the skill file)
- [ ] Write Ollama prompt template for article compilation
- [ ] Implement index.md update logic
- [ ] Test with GuruRMM and Cascades
**Done when:** `/wiki-compile client:cascades` runs end-to-end, produces correct article, updates index.
---
## Phase 3 — `/context` Integration
**Goal:** `/context` checks wiki before raw logs.
### Updated `/context` flow
```
1. Search wiki/index.md for topic mentions
2. Read matching wiki/<type>/<name>.md articles (synthesized knowledge)
3. THEN search session logs for recent/specific detail not yet compiled
4. Check credentials.md for access details
5. Return synthesized answer: wiki content + relevant log excerpts
```
### Tasks
- [ ] Update `.claude/commands/context.md` with wiki-first search step
- [ ] Add "Check wiki/index.md" as Step 1 in context command
- [ ] Add note: if topic has a wiki article, read it first; use logs only for recency
**Done when:** Running `/context cascades` returns the wiki article summary + any recent-session additions.
---
## Phase 4 — `/wiki-lint` Command
**Goal:** Health-check the wiki for staleness and integrity issues.
### Lint rules
| Rule | What It Checks | Action |
|---|---|---|
| Stale IPs | IPs in wiki vs CONTEXT.md + credentials.md | Flag discrepancies |
| Rate conflicts | Billing rates in wiki vs memory entries | Flag conflicts |
| Orphaned articles | Wiki articles with no session log activity in 90+ days | Flag for review/archive |
| Missing articles | Clients/projects mentioned in recent logs with no wiki article | Suggest compile |
| Broken backlinks | `[[links]]` pointing to non-existent articles | Flag |
| Memory conflicts | Memory entries contradicting wiki facts | Flag with both versions |
### Tasks
- [ ] Write `.claude/commands/wiki-lint.md`
- [ ] Implement lint checks
- [ ] Decide: run as scheduled cron or manual-only? (recommend: manual initially, cron after 30 days)
**Done when:** `/wiki-lint` runs, produces a report with actionable issues.
---
## Phase 5 — `/save` Integration (optional, lower priority)
After writing session log, detect which clients/projects/systems were mentioned, prompt:
```
Session log saved. Detected topics: GuruRMM, Cascades.
Update wiki for these topics? [y/n]
```
If y: run `/wiki-compile` for each detected topic before sync.
### Tasks
- [ ] Add topic detection to `/save` (regex on session log content)
- [ ] Add post-save wiki update prompt
- [ ] Wire through to `/wiki-compile`
---
## Migration Strategy
| What | Risk | How |
|---|---|---|
| Session logs | None | Not touched, wiki reads from them |
| CONTEXT.md | None | Not touched, wiki reads from it |
| Memory entries | Low | Wiki links to memory; memory links to wiki |
| `/context` command | Low | Additive — wiki step added before log search |
| GrepAI index | None | Automatic — picks up `wiki/` files on next index cycle |
| Cross-machine sync | None | Wiki is tracked in Git, syncs via normal `sync.sh` |
**No existing functionality is removed or broken.** All changes are additive.
---
## Recommended Start Order
1. ~~Phase 0 (structure)~~ — DONE 2026-05-24
2. Phase 1 seed:
- [x] Cascades of Tucson — `wiki/clients/cascades-tucson.md` — DONE 2026-05-24
- [x] GuruRMM — `wiki/projects/gururmm.md` — DONE 2026-05-24
- [ ] Systems: neptune, jupiter, pluto, saturn
- [ ] `wiki/overview.md` — compile AFTER systems are seeded (reads other wiki articles)
3. Phase 2 command — implement and test — 2-3 hours
4. Phase 3 context integration — 30 minutes
5. Phase 4 lint — schedule for after 30 days of real wiki use
6. Phase 5 save integration — nice-to-have, do if Phase 1-4 prove value
## Overview Article (added 2026-05-24)
`wiki/overview.md` — scope `/wiki-compile overview`
The "cold-start" doc. Compiles from other wiki articles (not raw logs directly), so it is cheap to maintain.
Sections:
- **Team** — Mike (admin/owner), Howard (tech/employee), machines, roles
- **Active Clients** — one-liner per client with billing type, hours, primary open project, link to wiki article
- **Active Projects** — one-liner per project with version/status, link to wiki article
- **Key Infrastructure** — what runs where (Neptune, Jupiter, Pluto, Saturn, plus client-side infra)
- **Tooling Stack** — coord API, GrepAI, Ollama, SOPS vault, Gitea, Syncro PSA, GuruRMM
- **State of the Business** — current snapshot: active projects, open billing, near-term priorities
This article is the one Howard reads on a new machine before touching anything else.

75
.claude/specs/wiki-layer/references.md Normal file
View File

@@ -0,0 +1,75 @@
# Wiki Layer — References
## Files This Feature Reads From
| File / Path | Role |
|---|---|
| `session-logs/*.md` | Raw source — root general logs |
| `projects/*/session-logs/*.md` | Raw source — project-specific logs |
| `clients/*/session-logs/*.md` | Raw source — client logs |
| `projects/*/CONTEXT.md` | Cross-reference for live state facts |
| `.claude/memory/*.md` | Cross-reference for discrete facts |
| `credentials.md` | Cross-reference for access details |
## Files This Feature Writes To
| File / Path | Role |
|---|---|
| `wiki/index.md` | LLM-maintained master index |
| `wiki/clients/<slug>.md` | Per-client synthesized knowledge |
| `wiki/projects/<slug>.md` | Per-project synthesized knowledge |
| `wiki/systems/<slug>.md` | Per-system synthesized knowledge |
| `wiki/patterns/<slug>.md` | Cross-cutting pattern articles |
## Commands This Feature Touches
| Command | Change |
|---|---|
| `.claude/commands/context.md` | Add wiki-first search step (Phase 3) |
| `.claude/commands/save.md` | Add post-save wiki update prompt (Phase 5) |
| `.claude/commands/wiki-compile.md` | New — created in Phase 2 |
| `.claude/commands/wiki-lint.md` | New — created in Phase 4 |
## Integration Points
### GrepAI
- `wiki/` is under the repo root — GrepAI watcher picks it up automatically
- No config change needed
- Wiki articles get full semantic search immediately after creation
- CLI: `D:/claudetools/grepai.exe search "cascades billing rate" --json -c -n 5`
### Ollama (Compilation Engine)
- Model: `qwen3:8b` on DESKTOP-0O8A1RL (86 tok/s, fits in 12GB VRAM)
- Model: `qwen3:14b` on other machines
- Prompt style: structured-format, JSON frontmatter first, then article body
- Endpoint: `http://localhost:11434` (DESKTOP-0O8A1RL) | `http://100.92.127.64:11434` (others)
- See `.claude/OLLAMA.md` for full routing table
### Git / Gitea Sync
- `wiki/` is tracked in Git — syncs via `sync.sh` on every `/save` and `/sync`
- Cross-machine sync is automatic: Mike compiles on DESKTOP, Howard gets it on next pull
- No special handling needed
### Coord API
- Wiki does NOT replace coord API — they serve different purposes
- Coord API: real-time state (locks, messages, component state)
- Wiki: synthesized historical knowledge
- `/wiki-compile` may read coord API component state for currency checks but does not write to it
## Existing Relevant Docs
| Doc | Why Relevant |
|---|---|
| `.claude/CLAUDE.md` | Auto-context-loading section needs updating to reference wiki |
| `.claude/OLLAMA.md` | Compilation uses Ollama — routing table and examples |
| `.claude/FILE_PLACEMENT_GUIDE.md` | `wiki/` placement is new — add section |
| `.claude/memory/MEMORY.md` | Memory entries should link to wiki articles where applicable |
| `CONTEXT.md` (root) | Add wiki to "Where to Find Things" section |
## Karpathy Reference
Original post: https://x.com/karpathy/status/2039805659525644595
Posted: 2026-04-02
Key insight adopted: raw data → LLM-compiled wiki → Q&A against wiki → outputs filed back into wiki
Key insight NOT adopted: Obsidian IDE, RAG pipelines, finetuning (unnecessary at our scale)
Key divergence: We already have GrepAI (replaces his naive search engine) and coord API (real-time comms he lacks)

70
.claude/specs/wiki-layer/shape.md Normal file
View File

@@ -0,0 +1,70 @@
# Wiki Layer — Shape Spec
**Project:** ClaudeTools Internal Tooling
**Author:** Mike Swanson
**Date:** 2026-05-24
**Status:** Specced, awaiting implementation
---
## Problem
Session logs accumulate as raw chronological records but are never synthesized. Every session start requires re-reading 5-15 logs to reconstruct institutional knowledge about a client, project, or system. This is:
1. Slow — GrepAI helps but synthesis still happens in-session
2. Lossy — patterns and connections that span multiple logs don't surface naturally
3. Non-durable — synthesized understanding lives only in the current context window
4. Howard-unfriendly — he can't benefit from what Mike's sessions discovered without reading raw logs
The coord API handles live state (locks, messages). CONTEXT.md handles live project state. Memory handles isolated facts. Nothing handles **synthesized knowledge** — the compiled, connected, queryable layer between raw logs and live state.
## Solution: A Wiki Layer
A `wiki/` directory of LLM-compiled Markdown articles organized by topic (clients, projects, systems, patterns). The LLM writes and maintains these articles from session logs. Humans rarely touch them directly.
Key properties:
- Plain `.md` files — no new tooling, syncs via Git, indexed by GrepAI automatically
- LLM-maintained — compiled from session logs, not written by hand
- Cross-linked — backlinks between clients, projects, systems
- Queryable — `/context` checks wiki first; much faster signal than raw logs
- Auditable — compilation metadata tracks what was read and when
## Analogy to Current System
| Layer | What It Is | Purpose |
|---|---|---|
| `session-logs/` | Raw chronological records | Audit trail, raw source of truth |
| `wiki/` | **[NEW]** LLM-compiled knowledge articles | Synthesized, queryable knowledge |
| `.claude/memory/` | Isolated discrete facts | Fast-access facts (links into wiki) |
| `CONTEXT.md` | Live project state | Current state, not knowledge |
| Coord API | Real-time inter-session comms | Locks, messages, component state |
## Scope
### In Scope (Phase 1)
- `wiki/` directory structure and templates
- `/wiki-compile` command — compiles session logs into wiki articles for a given scope
- `/context` update — checks wiki before raw logs
- Seed pass: GuruRMM + Cascades as pilot (most logs, highest value)
### In Scope (Phase 2)
- `/wiki-lint` command — health-checks wiki for stale IPs, broken backlinks, orphaned articles
- `/save` integration — prompt after save: "Update wiki for [detected topics]?"
- Additional seeds: all active clients, all known systems
### Out of Scope
- Obsidian or any special viewer — editors + GrepAI are sufficient
- RAG pipelines — flat files at our scale, GrepAI handles search
- Automated compilation without review — human spot-check required
- Finetuning on wiki content — not worth the complexity
- Replacing session logs, CONTEXT.md, memory, or coord API — additive only
## Success Criteria
- Starting work on GuruRMM or Cascades takes one wiki read instead of 10 log reads
- Howard can get full context on any active client by reading one file
- A stale IP or rate change gets caught by lint before causing a session failure
- `/context` returns synthesized answers in seconds, not minutes of log spelunking

243
.claude/specs/wiki-layer/standards.md Normal file
View File

@@ -0,0 +1,243 @@
# Wiki Layer — Standards & Templates
## Article Frontmatter (all types)
```yaml
---
type: client | project | system | pattern
name: <slug>
display_name: <Human Readable Name>
last_compiled: YYYY-MM-DD
compiled_by: <session_id>
sources:
- session-logs/YYYY-MM-DD-session.md
- clients/<name>/session-logs/YYYY-MM-DD-session.md
backlinks:
- projects/<name>
- systems/<name>
---
```
`last_compiled` is used by `/wiki-compile` to find session logs newer than this date. Never edit manually.
---
## Article Template: Client
File: `wiki/clients/<slug>.md`
```markdown
---
[frontmatter]
---
# <Client Display Name>
## Profile
- **Contract type:** Managed / Break-fix / Project / Prepaid block
- **Key contacts:** Name (title, email/phone)
- **Billing rate:** $X/hr | notes on exceptions
- **Hours remaining (if prepaid):** N hrs as of YYYY-MM-DD
- **Ticket system:** Syncro ticket #XXXXX (most recent active)
## Infrastructure
### Servers & Services
| Host | IP | Role | OS | Notes |
|---|---|---|---|---|
### Email & Identity
- **M365 tenant:** tenant.onmicrosoft.com
- **MX / mail flow:** ...
- **MFA status:** ...
### Network
- **ISP / WAN:** ...
- **Firewall:** ...
- **VPN:** ...
## Access
- SSH: `ssh user@IP` (key in vault: `clients/<name>/...`)
- RDP: IP:port
- Admin URL: ...
- Vault path: `clients/<name>/`
## Patterns & Known Issues
<!-- Recurring ticket types, common failure modes, things that always come up -->
## Active Work
<!-- Current open projects or tickets — brief, link to CONTEXT.md or ticket# for detail -->
## History Highlights
<!-- Major incidents, big projects, key decisions — one-liners with dates -->
## Backlinks
<!-- [[projects/name]] [[systems/name]] -->
```
---
## Article Template: Project
File: `wiki/projects/<slug>.md`
```markdown
---
[frontmatter]
---
# <Project Display Name>
## Summary
<!-- What it is, current maturity, who uses it -->
## Architecture
### Components
| Component | Location | Tech | State |
|---|---|---|---|
### Key Files & Repos
- Repo: gitea link
- Config: path
- Logs: path
## Development
### Current Focus
<!-- Active dev areas, recent decisions -->
### Patterns & Anti-Patterns
<!-- Code patterns enforced, anti-patterns discovered, reasons -->
### Build & Deploy
<!-- How to build, how to deploy, what to watch -->
## Active State
<!-- Brief — link to CONTEXT.md for live state detail -->
## History Highlights
<!-- Major milestones, pivots, incident resolutions -->
## Backlinks
<!-- [[clients/name]] [[systems/name]] -->
```
---
## Article Template: System
File: `wiki/systems/<slug>.md`
```markdown
---
[frontmatter]
---
# <Hostname>
## Identity
- **Hostname:** ...
- **IP:** ...
- **Role:** ...
- **Location:** Physical / VM on <host>
- **OS:** ...
## Specs
<!-- CPU, RAM, disk, NIC — or VM config -->
## Services
| Service | Port | Notes |
|---|---|---|
## Access
- SSH: `ssh user@IP`
- RDP: ...
- Console: ...
- Vault: `infrastructure/<name>/`
## Known Issues & Quirks
<!-- Historical problems, workarounds, things that surprised us -->
## Backlinks
<!-- [[projects/name]] [[clients/name]] -->
```
---
## Article Template: Pattern
File: `wiki/patterns/<slug>.md`
```markdown
---
[frontmatter]
---
# <Pattern Name>
## Rule
<!-- One-sentence statement of the pattern -->
## Why
<!-- Why this rule exists — incident, constraint, strong preference -->
## How to Apply
<!-- When and where this applies; edge cases -->
## Examples
<!-- Session log references where this played out -->
## Backlinks
<!-- [[projects/name]] [[clients/name]] -->
```
---
## Index File: `wiki/index.md`
LLM-maintained. Do not edit manually except to bootstrap.
```markdown
# Wiki Index
Last updated: YYYY-MM-DD
## Clients
| Article | Summary | Last Compiled |
|---|---|---|
| [Cascades](clients/cascades.md) | Prepaid block, $175/hr, ~37.5 hrs remaining | 2026-05-24 |
## Projects
| Article | Summary | Last Compiled |
|---|---|---|
| [GuruRMM](projects/gururmm.md) | RMM platform, Rust/Axum, active development | 2026-05-24 |
## Systems
| Article | Summary | Last Compiled |
|---|---|---|
| [Neptune](systems/neptune.md) | Primary server, 172.16.3.30, MariaDB + API | 2026-05-24 |
## Patterns
| Article | Summary | Last Compiled |
|---|---|---|
## Cross-Reference
<!-- Which clients use which systems, which projects run on which systems -->
```
---
## Naming Conventions
- Slugs: lowercase, hyphens, no spaces (`az-computer-guru`, `guru-rmm`, `cascades`)
- System slugs match hostname exactly (`neptune`, `jupiter`, `pluto`)
- Pattern slugs describe the rule (`no-mock-db-tests`, `labor-not-taxable`)
## Linking Convention
Use `[[slug]]` for cross-references within wiki. Full relative path in frontmatter `backlinks` field.
## What the LLM Should NOT Put in Wiki Articles
- Credentials or passwords (vault paths only)
- Full session log transcripts (summaries and highlights only)
- Speculative or uncertain facts (mark with `[unverified]` if uncertain)
- Real-time state (IPs are OK, but current ticket status belongs in coord API)