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

wiki: seed remaining clients and projects (batch 3)

Browse Source 
Adds 11 client articles and 5 project articles:

Clients: kittle, khalsa, anaise, azcomputerguru.com, bg-builders,
evs, furrier, horseshoe-management, kittle-design, scileppi-law,
western-tire

Projects: discord-bot, radio-show, msp-pricing, wrightstown-smarthome,
wrightstown-solar

Updates wiki/index.md with all new entries, cross-references, and
removes seeded client:birthbiologic from compilation queue.

Critical findings surfaced:
- Kittle: WS2025 EVAL license, no backups, 3 plaintext creds in Syncro
- Western Tire: SSL cert *.westerntire.com expires 2026-05-30
- Kittle Design: active compromise (Ken inbox rule unresolved)
- Horseshoe Mgmt: plaintext creds for 5+ users in Syncro notes

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Mike Swanson
2026-05-24 19:59:40 -07:00
parent 30b8020edf
commit f4fb131529
17 changed files with 2426 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

166
wiki/projects/discord-bot.md Normal file
View File

@@ -0,0 +1,166 @@
---
type: project
name: discord-bot
display_name: ClaudeTools Discord Bot
last_compiled: 2026-05-24
compiled_by: DESKTOP-0O8A1RL/claude-main
sources:
- projects/discord-bot/README.md
- projects/discord-bot/DISCORD_CLAUDE.md
- projects/discord-bot/session-logs/2026-04-30-session.md
- projects/discord-bot/session-logs/2026-05-20-session.md
---
# ClaudeTools Discord Bot
## Overview
Discord bot that gives the ACG MSP team access to the ClaudeTools database, M365 remediation-tool, and Claude AI assistance through Discord channels. Each Discord thread is a persistent Claude Code agent session — the bot is effectively "Claude Code in a Discord channel." Responses stream in real time.
**Status:** Active. Running as a Windows service on GURU-BEAST-ROG. Core architecture complete; Phases 2–4 (tool execution, remediation integration, UX polish) are pending.
---
## Tech Stack
| Layer | Technology |
|---|---|
| Language | Python 3.11+ |
| Discord library | discord.py 2.3.2 |
| AI SDK | Anthropic Claude Agent SDK (claude-sonnet-4-6) |
| HTTP client | httpx 0.27.0 |
| Config | Pydantic Settings 2.7.0 |
| Service manager | NSSM (Windows) |
| Headless browser (fallback) | Playwright, Chrome channel — for bot-blocked sites only |
---
## Architecture
As of Phase 1.5, the bot is a Claude Agent SDK deployment. Hand-written tool definitions from Phase 1 were removed. The agent uses native SDK tools (Read, Edit, Write, Bash, Glob, Grep, etc.) with the ClaudeTools repo as its working directory and `DISCORD_CLAUDE.md` as its system prompt.
```
Discord thread --> MessageHandler --> ClaudeAgentManager
|
v
ClaudeSDKClient (one per thread_id)
cwd = C:/Users/guru/ClaudeTools
system_prompt = DISCORD_CLAUDE.md
|
v
Native SDK tools:
Read / Edit / Write / Bash / Glob / Grep / ...
```
- System prompt (`DISCORD_CLAUDE.md`) is loaded ONCE at startup in `ClaudeAgentManager.__init__`. Editing it requires a bot restart to take effect.
- One persistent `ClaudeSDKClient` (ThreadAgent) is kept per `thread_id`. Follow-up messages within a thread reuse the same client, preserving full conversation history.
- Caller identity is injected as a `[DISCORD_CONTEXT]` block in `message_handler.py` so the agent knows who is asking.
### Access Control
| Identity | Access Level |
|---|---|
| Mike Swanson (ID: 264814939619721216) | Full — all tools, M365, vault, git |
| Howard Enos (ID: 624667664501178379) | Full |
| Winter (ID: 624666486362996755) | Full. Syncro SME — route Syncro questions to her |
| Rob Williams (ID: 261978810713505792) | Limited operator — remediation-tool, IX hosting, Syncro; NO bot config changes, vault writes, GuruRMM, ACG tenant actions |
| Unknown users | Read-only / informational only |
### Task Loop (per request)
1. Identify requester from `[DISCORD_CONTEXT]` block.
2. Do the work; ask clarifying questions in-thread as needed.
3. Ask "Anything else?"
4. Offer to log in Syncro.
5. Run `/save` to write session log and sync repo.
---
## Deployment / Hosting
| Item | Value |
|---|---|
| Host | GURU-BEAST-ROG (Windows 11 Pro) |
| Service name | `ClaudeToolsDiscordBot` (NSSM, StartType: Automatic) |
| Working directory | `C:/Users/guru/ClaudeTools` |
| nssm binary | `C:\Users\guru\AppData\Local\Microsoft\WinGet\Links\nssm.exe` |
| Stdout log | `projects/discord-bot/logs/stdout.log` |
| Stderr log | `projects/discord-bot/logs/stderr.log` |
| Discord guild | Arizona Computer Guru (id `624663750603046913`), 11 channels |
Restart command: `nssm restart ClaudeToolsDiscordBot`
The bot requires restart after any change to `DISCORD_CLAUDE.md` (system prompt is loaded once at startup).
---
## Configuration / Credentials
Secrets live in a `.env` file at `projects/discord-bot/.env` (gitignored on BEAST). Required variables:
- `DISCORD_TOKEN` — Discord bot token (Discord Developer Portal)
- `DISCORD_GUILD_ID` — ACG Discord server ID
- `ANTHROPIC_API_KEY` — or use the local Claude Code OAuth credential
- `CLAUDETOOLS_API_KEY` — JWT token for ClaudeTools API (not yet active — Phase 2)
- `VAULT_PATH` — path to SOPS vault on BEAST (`D:\vault`)
- `CLAUDETOOLS_ROOT` — `D:\claudetools`
Vault access (for remediation-tool): `msp-tools/computerguru-*.sops.yaml`, `clients/<slug>/m365*.sops.yaml`. Use the vault wrapper at `C:/Users/guru/ClaudeTools/.claude/scripts/vault.sh`.
---
## Active Work / Open Items
**Phase 2 — ClaudeTools API Integration (not started)**
- HTTP client with JWT auth (`bot/services/claudetools_api.py`)
- Implement `query_claudetools_api` tool executor
- User role mapping (Discord ID -> ClaudeTools user)
- Audit logging to `/api/security-incidents`
**Phase 3 — Remediation-Tool Integration (not started)**
- Bash subprocess runner (Git Bash on Windows)
- Implement `run_breach_check` and `run_tenant_sweep` executors
- Progress streaming to Discord
- Artifact upload
**Phase 4 — Polish (not started)**
- Confirmation buttons for remediation actions
- Rich embeds for structured data
- Slash commands (`/breach-check`, `/query`, `/status`)
- Ephemeral messages for sensitive data
---
## Key Events / History
| Date | Event |
|---|---|
| 2026-04-30 | Phase 1 MVP implemented on Mac (Mike). Project structure, discord.py handler, streaming Claude client, tool definitions (placeholder), README. Commit `777ad52`. |
| 2026-04-30 | Architecture decision: Python over Node.js; Claude Agent SDK instead of raw Anthropic SDK; thread-based conversations. |
| 2026-05-20 | On BEAST (Mike). Reviewed and corrected bot operating rules in `DISCORD_CLAUDE.md`: reversed no-interaction rule, added headless constraint, defined task loop. Service restarted twice; reconnected clean. No code changes — instructions only. |
| 2026-05-20 | Confirmed bot model is `claude-sonnet-4-6` (per `bot/config.py`). Phase 1.5 architecture confirmed: `ClaudeAgentManager` with persistent per-thread `ClaudeSDKClient`. |
---
## Anti-Patterns / Warnings
[WARNING] The system prompt (`DISCORD_CLAUDE.md`) is loaded ONCE at startup. Any edit is silently ineffective until `nssm restart ClaudeToolsDiscordBot` is run.
[WARNING] The bot is headless — no human is at the BEAST console. Never attempt: visible/interactive browser windows, OAuth flows that need a browser, Windows credential prompts, UAC dialogs, or any interactive GUI. These will hang the service forever. Credentials must come from the SOPS vault non-interactively.
[WARNING] Headless Chrome (`web-fetch-chrome.py`) is the ONLY sanctioned browser use — it never opens a visible window and uses an isolated profile. Do not drive the human's interactive Chrome session.
[WARNING] Unknown Discord users get read-only/informational responses only. Do not grant file writes, git ops, system changes, M365 actions, or vault access to unrecognized IDs.
[WARNING] The `AskUserQuestion` SDK tool does not render in Discord. Ask clarifying questions as plain text messages only.
[INFO] Phase 2 tool execution is still placeholder. `execute_tool()` in `message_handler.py` is a stub. The bot cannot currently query the ClaudeTools API or run remediation scripts programmatically — it relies on the Claude agent using native file/bash tools against the repo.
---
## Backlinks
- `wiki/systems/beast.md` [unverified — may not exist yet] — GURU-BEAST-ROG host spec
- `wiki/projects/gururmm.md` — related ACG internal project
- `.claude/CLAUDE.md` — system prompt source for the main ClaudeTools coordinator session
- `projects/discord-bot/DISCORD_CLAUDE.md` — bot's own operating instructions / system prompt

196
wiki/projects/msp-pricing.md Normal file
View File

@@ -0,0 +1,196 @@
---
type: project
name: msp-pricing
display_name: MSP Pricing & Marketing
last_compiled: 2026-05-24
compiled_by: DESKTOP-0O8A1RL/claude-main
sources:
- projects/msp-pricing/session-logs/2026-02-01-project-import.md
- projects/msp-pricing/session-logs/2026-02-03-buyers-guide-refinements.md
---
# MSP Pricing & Marketing
## Overview
Pricing structure documentation, calculators, and marketing materials for Arizona Computer Guru's managed services offerings (GPS — Guru Protection Services). Covers GPS Endpoint Monitoring, Support Plans, Block Time, Web Hosting, Email Hosting (WHM + M365), Email Security, and VoIP.
Also includes the MSP Buyers Guide — a marketing document that helps prospects evaluate MSPs, with ACG's GPS plans as the reference example.
**Status:** Active reference project. Core pricing documentation and Python calculators exist. Buyers Guide exists in HTML (paginated and continuous-scroll versions). Further development (customer-facing web calculator, proposal templates, ROI calculator) is pending.
**Location:** `projects/msp-pricing/` in the ClaudeTools repo.
---
## Tech Stack
| Item | Technology |
|---|---|
| Pricing calculators | Python (py, not python3) |
| Marketing documents | HTML (hand-crafted, dual versions: paginated + continuous-scroll) |
| Content source | Markdown (`docs/*.md`, `marketing/*-Content.md`) |
---
## Architecture
The project is a documentation and tooling repository, not a running application.
```
projects/msp-pricing/
README.md
docs/
gps-pricing-structure.md
web-email-hosting-pricing.md
voip-pricing-structure.md
calculators/
gps-calculator.py
complete-pricing-calculator.py
marketing/
MSP-Buyers-Guide.html -- original paginated
MSP-Buyers-Guide-NoPagination.html -- continuous-scroll (1,100+ lines)
MSP-Buyers-Guide-Content.md
Service-Overview-OnePager-Content.md
GPS_Price_Sheet_12.html
GPS_VoIP_Pricing.html
GPS_VoIP_Tier_Comparison.html
session-logs/
```
### Calculators
- `gps-calculator.py` — GPS-only quotes (endpoints, tiers, equipment, support).
- `complete-pricing-calculator.py` — Full integrated quote: GPS + web hosting + email + security. Key functions: `calculate_whm_email()`, `calculate_m365_email()`, `calculate_web_hosting()`, `calculate_complete_quote()`, `print_complete_quote()`.
---
## Deployment / Hosting
*(not documented)* — This is a local documentation/tooling project. No deployed service. The Buyers Guide HTML files are intended as print handouts or web-viewable documents, not hosted web pages.
---
## Configuration / Credentials
*(not documented)* — No secrets or credentials are associated with this project. Pricing data is maintained directly in markdown and HTML files.
---
## Active Work / Open Items
- [ ] Create printable quote templates (Word/PDF)
- [ ] Add competitor comparison calculator
- [ ] Create ROI calculator for prospects
- [ ] Add internal margin calculator
- [ ] Build customer-facing web calculator
- [ ] Create proposal templates
- [ ] Add cost-of-breach calculator for security justification
- [ ] Buyers Guide: add professional logo image
- [ ] Buyers Guide: add icons for red flags
- [ ] Buyers Guide: add table of contents with jump links (web version)
- [ ] Buyers Guide: add page numbers (print version)
- [ ] Buyers Guide: professional photography (Tucson, office, team)
- [ ] Buyers Guide: infographics for pricing comparisons
---
## Key Events / History
| Date | Event |
|---|---|
| 2026-02-01 | Project created. Imported GPS Endpoint Monitoring, Support Plans, Web/Email Hosting pricing from web-chat session. Created Python calculators. Documented 4 example scenarios (Small Office, Modern Business, E-Commerce, Web/Email Only). |
| 2026-02-01 | VoIP pricing imported (from November 2025 web chat). GPS-Voice tiers + OIT white-label platform wholesale costs documented. |
| 2026-02-03 | Buyers Guide refinements (Mac session). Created continuous-scroll HTML version (`MSP-Buyers-Guide-NoPagination.html`). Content improvements: checklist reorder, GPS acronym explanation, Red Flag 2 rewrite (high-pressure sales), block time section added, cost justification notes, contact info updated (info@, $175/hr, 9am–5pm office hours). Next Steps section rewritten. Commit `3c673fd`. |
---
## Pricing Reference (as documented — verify before quoting)
### GPS Endpoint Monitoring
| Tier | Price |
|---|---|
| GPS-BASIC | $19/endpoint/month |
| GPS-PRO | $26/endpoint/month (most popular) |
| GPS-ADVANCED | $39/endpoint/month |
| Equipment Pack | $25/month (up to 10 devices) |
### GPS Support Plans
| Plan | Price | Hours Included |
|---|---|---|
| Essential | $200/month | 2 hrs |
| Standard | $380/month | 4 hrs (most popular) |
| Premium | $540/month | 6 hrs |
| Priority | $850/month | 10 hrs |
Support plan hours are use-it-or-lose-it (do not roll over).
### Block Time (never expires)
| Block | Price |
|---|---|
| 10 hours | $1,500 |
| 20 hours | $2,600 |
| 30 hours | $3,000 |
### Web Hosting
| Tier | Price | Storage | Sites |
|---|---|---|---|
| Starter | $15/month | 5 GB | 1 |
| Business | $35/month | 25 GB | 5 (most popular) |
| Commerce | $65/month | 50 GB | Unlimited |
### Email Hosting
**WHM Email:** $2/mailbox/month base (5 GB included); +$2 per additional 5 GB block. Legacy "unlimited" clients converting to metered billing — 60–90 day notice before changes.
**Microsoft 365:**
| SKU | Price |
|---|---|
| Business Basic | $7/user/month |
| Business Standard | $14/user/month (most popular) |
| Business Premium | $24/user/month |
| Exchange Online | $5/user/month |
**Email Security Add-on:** $3/mailbox/month (MailProtector / migrating to INKY via Kaseya). Works with WHM or M365.
### VoIP (GPS-Voice — OIT White Label)
| Tier | Price | Margin |
|---|---|---|
| GPS-Voice Basic | $22/user | 68% |
| GPS-Voice Standard | $28/user | 70% (most popular) |
| GPS-Voice Pro | $35/user | 69% |
| GPS-Voice Call Center | $55/user | 76% |
OIT wholesale: $4/seat/month (regular), $6/seat (call center). Platform fees: $199–299/month billing platform + $500/month PBX minimum + $2,500 one-time onboarding.
### ACG Hourly Rate
$175/hour (full rate as of 2026-02-03). GPS Support effective rate: $85–100/hour.
---
## Anti-Patterns / Warnings
[WARNING] Always fetch live rates from Syncro (`GET /products/<id> price_retail`) before quoting. Never use hardcoded rate tables — proven wrong in practice (2026-05-20 memory entry).
[WARNING] Arizona labor is never taxable. Set `taxable=false` on all labor line items in Syncro.
[INFO] Email Security platform is in transition: currently MailProtector (Emailservice.io), migrating to INKY via Kaseya bundle. Verify current platform before customer communications.
[INFO] In-house Exchange Server is discontinued. Recommend M365 for any Exchange-level needs.
[INFO] The Buyers Guide contact email was updated to `info@azcomputerguru.com` (not `mike@`) and office hours to 9:00 AM–5:00 PM. Earlier versions of the document have stale info.
---
## Backlinks
- `wiki/clients/` — individual client billing records may reference GPS tiers
- `.claude/memory/feedback_syncro_live_rates.md` — memory entry: never use hardcoded rate table
- `.claude/memory/feedback_syncro_labor_tax.md` — memory entry: Arizona labor is non-taxable

205
wiki/projects/radio-show.md Normal file
View File

@@ -0,0 +1,205 @@
---
type: project
name: radio-show
display_name: The Computer Guru Show
last_compiled: 2026-05-24
compiled_by: DESKTOP-0O8A1RL/claude-main
sources:
- projects/radio-show/post-show-workflow.md
- projects/radio-show/audio-processor/README.md
- projects/radio-show/session-logs/2026-04-27-qa-extraction-cohost-indexing.md
- projects/radio-show/session-logs/2026-05-01-ui-redesign-recovery.md
---
# The Computer Guru Show
## Overview
"The Computer Guru Show" is Mike Swanson's radio program. The project covers two distinct workstreams:
1. **Audio Processor** — Automated pipeline that processes raw broadcast recordings (with commercials) into podcast-ready audio, transcripts, speaker-diarized segments, and a searchable SQLite archive.
2. **Post-Show Content Workflow** — Process for turning each episode into an episode page (website), forum discussion thread (Flarum), and 1–3 deep-dive blog posts within 48 hours of air.
**Status:** Active development. Audio processor pipeline functional with 572 episodes indexed locally on BEAST. FastAPI browse/search UI redesigned (2026-05-01). Jupiter deployment has a known audio-file gap (open). Post-show workflow documented but not yet fully automated.
Archive spans 2010–2018 (no 2013 season), 579 MP3s, ~30–40 GB.
---
## Tech Stack
| Layer | Technology |
|---|---|
| Transcription | faster-whisper (`large-v3`, CTranslate2 + CUDA), int8_float16, batched |
| Speaker diarization | pyannote.audio 3.1 (WavLM embeddings) |
| Audio processing | ffmpeg, pydub, librosa |
| Audio fingerprinting | chromaprint |
| Voice activity detection | silero-vad |
| ML / classification | scikit-learn (break pattern classifier) |
| Content analysis | Ollama — `qwen3:14b` (narrative/summary), local LLM |
| Archive database | SQLite with FTS5 (segments, Q&A pairs) |
| Web server | FastAPI + uvicorn (embedded HTML templates) |
| Hardware (primary) | DESKTOP-0O8A1RL — RTX 5070 Ti Laptop GPU |
| Hardware (secondary) | GURU-BEAST-ROG — RTX 4090 (benchmark pending) |
---
## Architecture
### Audio Processor Pipeline
```
Raw MP3 (full broadcast with commercials)
|
+-- 1. Transcription: faster-whisper large-v3 (63.8x realtime on 5070 Ti)
| Output: word-level timestamps, language detection
|
+-- 2. Speaker Diarization: pyannote.audio 3.1 (209.7x realtime on 5070 Ti)
| 10s windows / 5s hop, midpoint boundary resolution at load time
| Speaker profiles: host (Mike, era-specific embeddings), co-hosts, callers
|
+-- 3. Segment Detection: Multi-signal classifier (6 signals, combined weighted score)
| Signals: fingerprint match (0.30), speaker identity (0.25),
| audio characteristics (0.20), break pattern (0.15), structural heuristics (0.10)
| Element library: SQLite fingerprints.db + learning/discovery system
|
+-- 4. Commercial Removal: ffmpeg — stitch segments, EBU R128 normalize
|
+-- 5. Segment Splitting: ffmpeg — individual MP3s per segment, ID3 tags, chapter markers
|
+-- 6. Content Analysis: Ollama qwen3:14b
Output: episode summary, per-segment summaries, key quotes, topic tags,
suggested blog post topics, auto-filled post-show debrief
```
### Key Thresholds
| Parameter | Value |
|---|---|
| Host/co-host match threshold | 0.85 cosine similarity (WavLM) |
| Tara (co-host) vs Mike separation | 0.698 cosine similarity |
| CALLER minimum coverage in transcript segment | 4.0 seconds |
| Promo score threshold | 2 (weighted signatures) |
| Min Q&A question duration | 5.0s |
| Min Q&A answer duration | 15.0s |
| Max gap between Q and A | 30.0s |
| Commercial break: min/max duration | 30s / 300s |
| Combined confidence threshold (commercial) | 0.70 |
### Voice Profile System
Bootstrapped from the 579-episode archive. Host (Mike) has era-specific embeddings (2010, 2014, 2018, 2026). Co-host Tara has 44 embeddings from 2 episodes. Unknown repeat voices are clustered and held for host review.
```
voice-profiles/
host-mike-swanson/ -- composite + era embeddings
guests/<name>.npy -- named guest embeddings (built over time)
callers/regular-NNN.npy -- unnamed repeat callers
unknown/cluster-NNN.npy -- unidentified voices appearing multiple times
```
### Archive Index (SQLite)
`archive.db` schema: `episodes`, `segments`, `segments_fts` (FTS5), `qa_pairs`, `qa_fts`. As of 2026-05-01 on BEAST: 572 episodes indexed.
FTS5 search supports: segment text search, Q&A pair search, speaker filter.
### FastAPI Browse/Search UI
Single-file server at `projects/radio-show/audio-processor/server/main.py`. Two embedded HTML templates:
- `INDEX_HTML` — search/browse page with CSS custom property theme (`#c39733` accent), browse-mode toggle, Q&A pill badges.
- `EPISODE_HTML` — episode detail page with sticky `<audio>` player, active-Q&A highlight that follows playhead via `timeupdate` listener, `preload="metadata"`.
Env vars: `ARCHIVE_DB`, `EPISODES_DIR`, `PORT`.
### Post-Show Content Workflow
Three content tiers produced within 48 hours of each episode:
| Tier | Target | Output |
|---|---|---|
| 1 | Radio show website | Episode page (`website/src/content/episodes/sXXeYY-slug.md`) with summary, chapters, links |
| 2 | Flarum forum | Discussion thread (tag: Show Discussion, ID 8) at community.azcomputerguru.com |
| 3 | Radio show website | 1–3 deep-dive blog posts (`website/src/content/blog/<slug>.md`) |
Claude handles: generating all content from show-prep + debrief, posting to Flarum via DB insert, building and deploying the Astro website.
---
## Deployment / Hosting
| Item | Value |
|---|---|
| Jupiter (primary archive host) | `172.16.3.20:8765` — uvicorn, FastAPI |
| Local dev (BEAST) | `127.0.0.1:8765` — same port as Jupiter for bookmark parity |
| Archive source (IX server) | `172.16.3.10` — `gurushow@`, `/home/gurushow/public_html/archive/Radio/` |
| Archive local copy (BEAST) | `projects/radio-show/audio-processor/archive-data/` |
| Forum | community.azcomputerguru.com (Flarum) |
| Radio show website | Astro site, deployed via rsync |
[WARNING] Jupiter's `/data/episodes` tree is EMPTY. `GET /api/audio/{id}` returns HTTP 404 for all episode IDs on Jupiter. Audio works locally on BEAST only (full archive in `archive-data/episodes/`). Fix decision is pending — see Open Items.
---
## Configuration / Credentials
| Secret | Location |
|---|---|
| IX server SSH (gurushow) | SOPS vault — search `gurushow` or `ix server` |
| HuggingFace token (pyannote license) | `huggingface-cli login` — required for pyannote.audio |
| Forum DB access (Flarum insert) | SOPS vault — search `flarum` or `community forum` |
IX server access: paramiko with `look_for_keys=False, allow_agent=False`. Tailscale required for `172.16.3.10`.
---
## Active Work / Open Items
- [ ] **Jupiter audio fix (open, unresolved).** Three options, no pick made:
1. rsync full archive (~30–40 GB) to Jupiter at `/data/episodes/`
2. Proxy `/api/audio/{id}` from Jupiter to IX on demand (~5 lines)
3. Point `<audio src>` at IX directly via public HTTPS endpoint
- [ ] **Commit intro/QA sort tie-break fix** (`server/main.py` lines 551, 597 — `key=lambda x: x[0]`). Two-line fix, uncommitted as of end of 2026-05-01 session. Mike had not yet OK'd the commit.
- [ ] **RTX 4090 benchmark on BEAST** — establish diarization RTF baseline (expected ~250–300x vs 209.7x on laptop 5070 Ti).
- [ ] **Download full archive from IX to BEAST** for batch training (paramiko script skeleton exists in prior session log `2026-04-27-diarization-pipeline.md`).
- [ ] **Verify Tara profile generalizes across 2015/2016 episodes** — re-run `build_cohost_profile.py` with additional windows if false positives appear.
- [ ] **Post-show workflow automation** — social media, email newsletter, podcast RSS still need platform setup.
---
## Key Events / History
| Date | Event |
|---|---|
| 2010–2018 | Show original run. 579 episodes archived. No 2013 season. |
| 2026-04-27 | Q&A extraction + co-host profile session (DESKTOP-0O8A1RL). Built Tara co-host voice profile (44 embeddings, 0.698 cosine vs Mike). Fixed false-positive Q&A extraction for co-host episodes. Created `archive.db` with FTS5. Indexed 6 test episodes: 762 segments, 10 Q&A pairs. Transcription benchmarked at 63.8x realtime; diarization at 209.7x realtime. |
| 2026-04-30 | UI redesign done on BEAST (mid-session, uncommitted before reboot). |
| 2026-05-01 | Session recovery after BEAST reboot. Found 820-line uncommitted diff to `server/main.py`. Committed as `d7ce9cb` (rebased to `296d157`). Diagnosed Jupiter audio-404 (pre-existing deployment gap, not a regression). Deployed locally on BEAST — confirmed 572 episodes, working audio. Fixed episode-500 sort bug (episode 479). |
| 2026-05-01 | Co-host name corrected: previously labeled "Tom" in session log, Mike confirmed it is "Tara." All references updated. |
---
## Anti-Patterns / Warnings
[WARNING] Do NOT attempt interactive SSH to `gurushow@172.16.3.10` from scripts. Use paramiko with `look_for_keys=False, allow_agent=False`. Key-based auth is disabled on this host.
[WARNING] Tailscale must be active to reach `172.16.3.10` (IX server) or `172.16.3.20` (Jupiter).
[WARNING] The Ollama `/save` protocol has a known stale-prompt-file bug: `save_narrative_prompt.txt` at `C:/Users/guru/AppData/Local/Temp/` is reused across sessions and can cause qwen3 to produce a narrative about the WRONG session. Recovery: write narrative directly. Fix: delete prompt file before re-writing, or use a unique per-session filename.
[WARNING] `sorted()` over `(timestamp, sqlite3.Row)` tuples without `key=` will raise `TypeError` when two rows share the same timestamp. Always use `key=lambda x: x[0]`. This bit `_episode_html` at lines 551 and 597 (2026-05-01 bug).
[INFO] Co-host voice profiles must be built from the first 60 minutes of co-host episodes. Real callers do not call in during the first hour — those CALLER-labeled windows are safely all co-host speech.
[INFO] Tara's exact tenure as co-host is unverified. Do not assume her profile applies across all 2013–2016 episodes without spot-checking.
---
## Backlinks
- `wiki/systems/jupiter.md` [unverified — may not exist yet] — Jupiter server spec
- `wiki/systems/ix-server.md` [unverified — may not exist yet] — IX hosting server spec
- `wiki/projects/gururmm.md` — related ACG project
- `projects/radio-show/audio-processor/README.md` — full pipeline spec and configuration reference
- `projects/radio-show/post-show-workflow.md` — full post-show content workflow spec

116
wiki/projects/wrightstown-smarthome.md Normal file
View File

@@ -0,0 +1,116 @@
---
type: project
name: wrightstown-smarthome
display_name: Wrightstown Smart Home
last_compiled: 2026-05-24
compiled_by: DESKTOP-0O8A1RL/claude-main
sources:
- projects/wrightstown-smarthome/session-logs/2026-02-09-session.md
---
# Wrightstown Smart Home
## Overview
A privacy-first smart home automation project for the Wrightstown residence. The goal is a fully local-first home automation system with no dependency on Google, Amazon Alexa, or other cloud platforms for core functionality. A hybrid LLM bridge allows selective use of cloud AI for reasoning and search while keeping private data (cameras, sensors, presence) entirely local.
- **Status:** Planning / initial research phase as of 2026-02-09. No hardware deployed yet.
- **Scope:** Home Assistant Yellow setup, local LLM server build, hybrid AI bridge, VLAN network security.
- **Related project:** [[wrightstown-solar]] — planned future crossover via Victron Modbus TCP integration.
## Tech Stack
- **Home automation platform:** Home Assistant (open source, local-first)
- **Hardware:** Home Assistant Yellow (already owned, CM4/CM5 module needed)
- **Connectivity:** Built-in Zigbee 3.0 radio; M.2 NVMe slot
- **Local voice:** Wyoming + Whisper + Piper (fully local, no cloud)
- **LLM inference:** Ollama (primary local runtime)
- **LLM interface:** Open WebUI
- **LLM routing layer:** LiteLLM proxy (unified API, cost tracking, fallbacks)
- **Cloud AI — reasoning:** Claude API (Anthropic)
- **Cloud AI — search:** Grok API (xAI, 2M context, internet access)
- **HA integration:** Extended OpenAI Conversation (connects HA to LiteLLM)
- **Remote access:** Tailscale or WireGuard [unverified — not yet selected]
## Architecture
### Home Automation Core
- Home Assistant Yellow as the central hub
- Zigbee 3.0 radio built-in for device connectivity
- All automations, sensors, and local voice run entirely on-device
### Hybrid LLM Bridge
- LiteLLM proxy as unified routing layer with OpenAI-compatible API
- Estimated routing split: 80% local (Ollama) / 15% Claude API / 5% Grok API
- Estimated cloud cost: ~$5/month
- Routing progression: manual → keyword-based → semantic (eventual)
- PII sanitization pipeline for any cloud-bound queries
- Private data (cameras, sensors, presence) stays local only
### Local LLM Server (Planned Build)
- **Recommended GPU:** RTX 4090 24GB ($1,940–2,240)
- **Alternative builds researched:** budget build (~$580), flagship ($4,000+), Mac Mini M4
- **Primary model (fast/voice):** Qwen 2.5 7B
- **Primary model (reasoning):** Llama 3.1 70B Q4
### Network Security
- 4-VLAN architecture: Trusted / Infrastructure / IoT / Guest
- IoT VLAN isolation: devices cannot reach trusted network
- VLAN hardware decision pending: TP-Link Omada vs Ubiquiti UniFi [unverified]
## Deployment / Hosting
- Runs entirely on-premises at Wrightstown residence
- No cloud hosting; cloud APIs used selectively via LiteLLM proxy
- Remote access via Tailscale or WireGuard (not yet configured)
## Configuration / Credentials
- **Claude API key:** [unverified — account not yet created as of 2026-02-09]
- **Grok API key:** [unverified — account not yet created as of 2026-02-09]
- When created, store in SOPS vault under `clients/wrightstown/` or `projects/wrightstown-smarthome/`
## Active Work / Open Items
All items were pending as of the 2026-02-09 initial research session:
- [ ] Confirm whether CM4 or CM5 compute module is already owned or needs purchasing
- [ ] Set up HA Yellow (basic install, Zigbee, first automations)
- [ ] Research specific Zigbee devices to purchase
- [ ] Finalize LLM server GPU budget (budget 3060 vs sweet-spot 4090)
- [ ] Purchase and build LLM server hardware
- [ ] Decide on VLAN hardware (TP-Link Omada vs Ubiquiti UniFi)
- [ ] Set up Ollama + Open WebUI
- [ ] Create Anthropic API account + Grok API account
- [ ] Configure LiteLLM proxy
- [ ] Integrate HA with LiteLLM via Extended OpenAI Conversation
- [ ] Plan and implement Victron Modbus TCP crossover with [[wrightstown-solar]]
## Key Events / History
### 2026-02-09 — Initial Research and Planning Session
- Session run on machine: ACG-M-L5090
- Defined project scope: privacy-first, no Google/Alexa, HA Yellow as hub
- Researched and selected all major components (HA Yellow, LiteLLM, Ollama, voice stack)
- Designed hybrid LLM bridge architecture with 80/15/5 routing split
- Designed 4-VLAN network security model
- Researched local LLM server hardware options; recommended RTX 4090 24GB build
- Created project documentation structure:
- `projects/wrightstown-smarthome/PROJECT_INDEX.md`
- `projects/wrightstown-smarthome/documentation/ha-yellow-setup.md`
- `projects/wrightstown-smarthome/documentation/llm-server-build.md`
- `projects/wrightstown-smarthome/documentation/hybrid-bridge.md`
- `projects/wrightstown-smarthome/documentation/network-security.md`
- No hardware purchased or deployed this session. All work was research and planning.
## Anti-Patterns / Warnings
- [WARNING] **HA Yellow requires a CM4 or CM5 compute module — it does not include one.** Verify ownership before ordering other hardware.
- [WARNING] **JK BMS CAN pinout is reversed** (noted in [[wrightstown-solar]] research, relevant to future crossover). Use USB-UART path with dbus-serialbattery driver, not CAN direct.
- **Do not use Google Home or Amazon Alexa integrations** — privacy-first constraint is a hard project requirement.
- **PII sanitization is mandatory** before any data leaves the local network to cloud APIs.
- **Cloud API credentials must go in the SOPS vault** when created — do not hardcode in HA configuration files.
## Backlinks
- [[wrightstown-solar]] — Related project at same residence; planned Victron Modbus TCP crossover

117
wiki/projects/wrightstown-solar.md Normal file
View File

@@ -0,0 +1,117 @@
---
type: project
name: wrightstown-solar
display_name: Wrightstown Solar Battery System
last_compiled: 2026-05-24
compiled_by: DESKTOP-0O8A1RL/claude-main
sources:
- projects/wrightstown-solar/session-logs/2026-02-09-session.md
---
# Wrightstown Solar Battery System
## Overview
A DIY home solar battery storage project at the Wrightstown residence. The system adds battery storage and whole-house UPS capability to an existing grid-tie solar installation (Fronius IG Plus inverter). The design uses LiFePO4 cylindrical cells assembled into modular 5kWh packs, a Victron MultiPlus II inverter/charger, and a Victron Cerbo GX for system management.
- **Status:** Planning / initial research phase as of 2026-02-09. No hardware purchased yet.
- **Existing solar:** Fronius IG Plus (grid-tie only, no battery port)
- **Goal:** Add battery backup, whole-house UPS with <20ms transfer, generator failover capability
- **Expansion target:** Up to 20kWh (4 packs of 5kWh each)
- **Related project:** [[wrightstown-smarthome]] — planned future integration via Victron Modbus TCP
## Tech Stack
- **Cell chemistry:** LiFePO4 (Lithium Iron Phosphate) — EVE C40 (IFR40135) cylindrical cells
- **Pack configuration:** 16S5P per pack (80 cells per 5kWh pack)
- **BMS:** JK BMS B2A8S20P 150A (recommended)
- **Inverter/charger:** Victron MultiPlus II 48/5000
- **GX device (system manager):** Victron Cerbo GX
- **BMS integration method:** dbus-serialbattery driver via USB-UART cable (not CAN direct)
- **Existing inverter:** Fronius IG Plus (grid-tie, retained — MultiPlus creates micro-grid for Fronius to sync during outages)
## Architecture
### Battery Pack Design
- Cell: EVE C40 (IFR40135) — 3.2V nominal, 20Ah, 64Wh per cell, 366g, 50–60A continuous discharge
- Configuration: 16S5P = 16 cells in series × 5 in parallel
- Voltage: 51.2V nominal (48V system)
- Capacity: 5kWh per pack (100Ah)
- Modular: build in 5kWh increments; target up to 4 packs (20kWh)
- 5kWh chosen over 10kWh for: cost spreading, manageable builds, fault isolation, single-person liftable weight
### Power Architecture
- Victron MultiPlus II as central inverter/charger: AC-coupled to Fronius IG Plus
- MultiPlus creates a micro-grid so Fronius can continue producing during grid outages
- <20ms transfer time (UPS-grade seamless switchover)
- Physical relay disconnect ensures zero backfeed to grid
- Generator input supported as third source
- Cerbo GX manages BMS-inverter communication and system telemetry
### BMS Integration
- JK BMS B2A8S20P 150A: 2A active balancing (critical for cylindrical cells)
- Integration path: USB-UART cable → dbus-serialbattery driver → Cerbo GX
- [WARNING] JK BMS CAN bus pinout is reversed — do NOT use CAN direct; use USB-UART path
### Alternative BMS Options (Researched)
| BMS | Notes |
|---|---|
| SEPLOS V4 ($150–250) | Native CAN, no pinout issue |
| REC Q16 ($559) | Plug-and-play Victron integration |
| Daly | Not recommended (no active balancing) |
## Deployment / Hosting
- Entirely on-premises at Wrightstown residence
- No cloud services involved in core system operation
- Future: Victron Modbus TCP integration with [[wrightstown-smarthome]] Home Assistant for monitoring
## Configuration / Credentials
*(not documented)* — No credentials or cloud accounts required for this project. Victron Cerbo GX may use VRM portal (Victron Remote Monitoring); if configured, store VRM account credentials in SOPS vault under `projects/wrightstown-solar/`.
## Active Work / Open Items
All items pending as of the 2026-02-09 initial research session:
- [ ] Finalize BMS selection (JK BMS B2A8S20P confirmed as recommendation; alternatives noted)
- [ ] Source EVE C40 cells — Grade A, matched, with test data (required for 16S5P pack)
- [ ] Order Victron MultiPlus II 48/5000 + Cerbo GX
- [ ] Design physical cell holder and bus bar layout for 16S5P cylindrical pack
- [ ] Plan sub-panel / transfer switch wiring
- [ ] Build Pack 1, run for 1 month before expanding to additional packs
- [ ] Plan Victron Modbus TCP crossover with [[wrightstown-smarthome]] Home Assistant
## Key Events / History
### 2026-02-09 — Initial Research and Planning Session
- Session run on machine: ACG-M-L5090
- Researched and selected EVE C40 (IFR40135) LiFePO4 cells over salvaged EV battery packs
- Determined 16S5P / 5kWh modular pack design
- Selected Victron MultiPlus II 48/5000 as inverter/charger for UPS-grade seamless transfer
- Evaluated 8 BMS models; recommended JK BMS B2A8S20P 150A ($80–150)
- Selected Cerbo GX ($320–350) as GX device over Raspberry Pi
- Analyzed salvaged EV battery options (Tesla LFP, Chevy Bolt, Nissan Leaf) — rejected due to cost and complexity
- Budget estimates established:
- Phase 1 (5kWh + full Victron system): $2,175–2,945
- Full 20kWh system: $3,635–5,750
- Battery-only cost: $86–153/kWh
- Created project documentation structure:
- `projects/wrightstown-solar/PROJECT_INDEX.md`
- `projects/wrightstown-solar/documentation/system-design.md`
- `projects/wrightstown-solar/documentation/bms-comparison.md`
- `projects/wrightstown-solar/documentation/ev-salvage-analysis.md`
- `projects/wrightstown-solar/documentation/parts-list.md`
- No hardware purchased or deployed this session. All work was research and planning.
## Anti-Patterns / Warnings
- [WARNING] **JK BMS CAN bus pinout is reversed.** Use USB-UART path with dbus-serialbattery driver. Do NOT attempt CAN direct connection.
- [WARNING] **Salvaged EV packs were explicitly rejected.** Most salvage is NMC chemistry (less safe than LFP for home use), unknown state of health, requires voltage conversion and custom BMS. New EVE C40 cells are cheaper and simpler.
- **The Fronius IG Plus cannot directly interface with batteries** — it is grid-tie only. The MultiPlus II creates the micro-grid; do not try to connect batteries to the Fronius directly.
- **Buy Grade A matched cells with test data.** Mismatched cells in a 16S5P pack will cause balancing problems even with active balancing.
- **Build Pack 1 first and run for 1 month before ordering materials for additional packs.** This is an explicit project decision to validate the design before scaling.
## Backlinks
- [[wrightstown-smarthome]] — Related project at same residence; planned Victron Modbus TCP crossover for Home Assistant monitoring