no-mistakes(document): Sync zulip-health v3.1.0 in registry and fix Koby IP to .129

- Add Koonimo (CT 113, .114) and Koby (CT 111) to Platform B monitoring
- Add Infisical dependency check (/usr/local/bin/infisical presence)
- Add config YAML validation (yaml.safe_load check)
- Add stale PID/lock detection and cleanup before restart
- Add LiteLLM key injection verification (no-key-required pattern)
- Add Telegram adapter health check
- Add cli_agent_setup_mixin.py patch verification
- Update restart commands with Infisical-missing fallback path
- Update requires/maintains schema with new fields
- Use pct exec from amdpve as primary access for Koonimo/Koby
- Verified correct IPs: Koonimo=.114 (not .113), Koby=pct exec only

AGENTS.md

@@ -128,3 +128,10 @@ safe-mutate --verify "CMD" [--expect "PATTERN"] --mutate "CMD" [--reason "WHY"]
 Read the [Authoring Guide](docs/AUTHORING-GUIDE.md) before writing any new contract.
 It covers the full process: verify → draft → lint → review → ship, with templates
 and style rules.
+
+## Maintaining this file
+
+Keep this file for knowledge useful to almost every future agent session in this project.
+Do not repeat what the codebase already shows; point to the authoritative file or command instead.
+Prefer rewriting or pruning existing entries over appending new ones.
+When updating this file, preserve this bar for all agents and keep entries concise.

CLAUDE.md

@@ -0,0 +1 @@
+AGENTS.md

abiba-zulip-restore.prose.md

@@ -0,0 +1,309 @@
+---
+kind: function
+name: abiba-zulip-restore
+description: >
+  Restores Zulip connectivity for Abiba (pi agent). Verifies the v2 router-worker
+  extension code, starts a PM2 process as the Zulip gateway with correct env vars,
+  validates health endpoint, and confirms DM delivery. Run this whenever Abiba
+  stops responding on Zulip or after system restart.
+agent: abiba
+version: 1.0.0
+status: active
+runtime_contract: 2
+---
+
+# Abiba Zulip Restore — Resume pi Zulip Communication
+
+Single-shot function that restores full Zulip connectivity for the Abiba pi agent.
+Covers extension code validation, PM2 process management, health endpoint
+verification, and DM loopback testing.
+
+## Live-State Fields
+
+| Field | Value | Trust |
+|-------|-------|-------|
+| Agent name | abiba | ✅ |
+| Bot email | abiba-bot@chat.sysloggh.net | ✅ |
+| Zulip server | https://chat.sysloggh.net | ✅ |
+| Extension path | /root/.pi/agent/extensions/zulip/index.js | ✅ |
+| Config path | /root/.pi/agent/extensions/zulip/config.yaml | ✅ |
+| Health port | 9200 | ✅ |
+| @all-bots user ID | 20 | ✅ (config, verified by API at runtime) |
+| PM2 process name | abiba-zulip | ✅ |
+| Provider | syslog-harness (http://192.168.68.116/v1) | ✅ |
+| Default model | deepseek-v4-pro | ✅ (settings.json) |
+
+## Architecture
+
+The pi Zulip extension uses a **router-worker architecture** (v2):
+
+- **Router** (PM2 `abiba-zulip`, `ZULIP_ROLE=router`): Polls Zulip for events,
+  maintains a per-sender pool of pi RPC worker processes. Each sender gets
+  their own `pi --mode rpc --session-dir` process with persistent sessions.
+  Handles streaming edits back to Zulip.
+- **Worker** (child `pi --mode rpc`): Runs the agent with per-sender persistent
+  sessions. No Zulip logic in the worker — the router handles all Zulip I/O.
+
+The extension loads in ALL pi sessions (via `settings.json` extensions array)
+but is a **NO-OP** unless `ZULIP_ROLE=router` is set. Only the PM2 router process
+carries the env var.
+
+## Maintains
+
+- extension_valid: bool — Extension code imports without errors
+- pm2_running: bool — PM2 process `abiba-zulip` is online
+- health_responding: bool — GET :9200/health returns "ok"
+- zulip_connected: bool — Queue registered, bot identity resolved
+- loopback_delivered: bool — Test DM sent and received
+- model_valid: bool — Configured models match LiteLLM authorized models
+
+### Postconditions
+
+- PM2 process `abiba-zulip` online and stable (uptime > 30s)
+- Health endpoint returns `{ status: "ok", connected: true }`
+- Worker pool creates sessions on demand
+- Echo prevention active (BOT_EMAILS includes all known bots)
+- PM2 saved for auto-restart on boot
+
+## Requires
+
+- Node.js with `yaml` module available
+- PM2 installed globally
+- Zulip API key in `config.yaml`
+- `pi` CLI available on PATH
+- Zulip server accessible at https://chat.sysloggh.net
+- LiteLLM provider accessible at http://192.168.68.116/v1
+
+## Execution
+
+### Step 1: Validate Extension Code
+
+```bash
+node -e "import('file:///root/.pi/agent/extensions/zulip/index.js').then(() => console.log('OK')).catch(e => {console.error('FAIL:', e.message); process.exit(1)})"
+```
+
+Expected: `OK`. If FAIL → check for missing dependencies, syntax errors.
+
+### Step 2: Validate Model IDs
+
+Compare configured models against LiteLLM authorized models:
+
+```bash
+API_KEY=$(grep -oP 'apiKey:\s*\K.*' /root/.pi/agent/models.json | head -1)
+curl -s -H "Authorization: Bearer $API_KEY" http://192.168.68.116/v1/models | \
+  python3 -c "import json,sys; d=json.load(sys.stdin); [print(m['id']) for m in d.get('data',[])]" 2>/dev/null
+```
+
+Check: Every model ID in `models.json` must appear in the authorized list.
+If not → fix `models.json` to only include authorized models (prefer `syslog-auto`).
+
+### Step 3: Verify Config Integrity
+
+```bash
+python3 -c "
+import yaml, sys
+with open('/root/.pi/agent/extensions/zulip/config.yaml') as f:
+    cfg = yaml.safe_load(f)
+required = ['zulip.site', 'zulip.email', 'zulip.api_key', 'agent.name']
+for k in required:
+    keys = k.split('.')
+    v = cfg
+    for kk in keys:
+        v = v.get(kk)
+        if v is None:
+            print(f'MISSING: {k}')
+            sys.exit(1)
+print('Config valid')
+print(f'  site={cfg[\"zulip\"][\"site\"]}')
+print(f'  email={cfg[\"zulip\"][\"email\"]}')
+print(f'  agent={cfg[\"agent\"][\"name\"]}')
+print(f'  health_port={cfg.get(\"health_port\", 9200)}')
+"
+```
+
+Expected: Config valid with all fields non-empty.
+
+### Step 4: Remove Stale Systemd Service
+
+The old `abiba-zulip.service` points to `/opt/abiba-zulip/dist/index.js` (compiled
+TypeScript, not the v2 extension). It's disabled and stale. Remove it:
+
+```bash
+systemctl stop abiba-zulip 2>/dev/null || true
+systemctl disable abiba-zulip 2>/dev/null || true
+rm -f /etc/systemd/system/abiba-zulip.service
+systemctl daemon-reload
+```
+
+### Step 5: Start PM2 Process
+
+**Critical:** The extension MUST run via `pi --mode rpc`, NOT `node index.js` directly.
+The extension exports a function that requires pi's session lifecycle. Running
+`node index.js` loads the module but never calls the export, so nothing happens.
+`pi --mode rpc` loads all extensions (including Zulip) and fires `session_start`.
+
+```bash
+# Stop existing if any
+pm2 delete abiba-zulip 2>/dev/null || true
+
+# Start pi in RPC mode with ZULIP_ROLE=router env
+ZULIP_ROLE=router pm2 start "$(which pi)" \
+  --name abiba-zulip \
+  --interpreter none \
+  -- --mode rpc --no-session
+```
+
+Wait 10 seconds for pi to load all extensions, fire session_start, and the Zulip
+router to register its event queue.
+
+### Step 6: Validate PM2 Process
+
+```bash
+pm2 show abiba-zulip --no-color
+```
+
+Check: `status=online`, `restarts=0`, `uptime > 5s`.
+
+### Step 7: Check Logs for Connection
+
+```bash
+sleep 3
+tail -20 /root/.pm2/logs/abiba-zulip-out.log
+```
+
+Look for:
+- `[zulip-ext] Connecting to https://chat.sysloggh.net as abiba-bot@chat.sysloggh.net…`
+- `[zulip-ext] Bot user_id=N, all-bots user_id=N`
+- `[zulip-ext] Connected, queue=N`
+- `[zulip-ext] Echo prevention: N bot emails`
+- `[zulip-ext] Health endpoint on :9200`
+
+If error → check API key, network to chat.sysloggh.net.
+
+### Step 8: Health Endpoint
+
+```bash
+curl -s http://localhost:9200/health | python3 -m json.tool
+```
+
+Check:
+- `status: "ok"` (not "down")
+- `zulip.connected: true`
+- `zulip.queue_id` is non-null string
+- `zulip.bot_user_id` is positive integer
+
+### Step 9: DM Loopback Test
+
+```bash
+curl -s http://localhost:9200/health | python3 -c "
+import json,sys
+d = json.load(sys.stdin)
+if d.get('zulip',{}).get('connected'):
+    print(f'✅ Zulip connected. Queue: {d[\"zulip\"][\"queue_id\"]}')
+    print(f'   Bot user_id: {d[\"zulip\"][\"bot_user_id\"]}')
+    print(f'   Messages processed: {d[\"zulip\"][\"messages_processed\"]}')
+else:
+    print('❌ Zulip NOT connected')
+    sys.exit(1)
+"
+```
+
+### Step 10: Save PM2 for Auto-Start
+
+```bash
+pm2 save
+pm2 startup systemd -u root --hp /root 2>/dev/null || true
+```
+
+### Step 11: Report
+
+Compile results:
+
+| Check | Pass? |
+|-------|-------|
+| Extension code imports | extension_valid |
+| Model IDs authorized | model_valid |
+| Config integrity | config_valid |
+| PM2 process online | pm2_running |
+| Health endpoint | health_responding |
+| Zulip connected | zulip_connected |
+
+All pass → ✅ **Abiba Zulip restored.** Relay success to user.
+
+Partial failure → see recovery matrix below.
+
+## Recovery Matrix
+
+| Failure | Recovery |
+|---------|----------|
+| Extension import fails | Check `node_modules/zulip-js` exists; run `npm install` in extension dir |
+| Model ID mismatch | Fix `models.json` to use `syslog-auto` as default model; remove invalid IDs |
+| Config missing | Restore from backup or recreate from scratch |
+| PM2 won't start | Check `node` version (>=18); check port 9200 not in use |
+| Health "down" | Check logs for connection errors; verify Zulip API key; check network |
+| "address already in use" | Kill old process: `fuser -k 9200/tcp` |
+| Queue registration fails | Check Zulip API key validity; verify bot is active in Zulip admin |
+| Rate limit (429) | Extension has built-in retry-after handling — wait, don't restart |
+
+## Known Failure Modes
+
+| Symptom | Root Cause | Recovery |
+|---------|-----------|----------|
+| Extension loads but no events | `ZULIP_ROLE` not set | Ensure PM2 env has `ZULIP_ROLE=router` |
+| Worker stays "busy" forever | Model ID not authorized by LiteLLM | Fix models.json (lesson #11) |
+| Placeholder sent but no response | editMessage API fails silently | Extension has fallback (sends new msg); check Zulip API |
+| Queue expires rapidly | Poll interval too aggressive | v2 uses 3s poll with long-poll — should be fine |
+| Bot doesn't respond to @mentions | Not subscribed to stream | Bot auto-subscribes via API |
+| Stale error in health | `last_error` not cleared | v2 clears on successful poll (lesson #4) |
+
+## Appendix: Root Cause & Fix Summary (2026-07-13)
+
+**Problem:** Zulip extension was offline — no PM2 process running.
+
+**Root cause:** The PM2 command ran `node index.js` directly (which loads the
+extension module but never calls the exported function). The extension requires
+pi's session lifecycle — pi loads extensions, fires `session_start`, and the
+Zulip extension hooks into that event.
+
+**Fix:** Run `pi --mode rpc` (not `node index.js`). The `--mode rpc` flag keeps
+pi alive listening for RPC commands on stdin while the Zulip extension's router
+runs in the background via the `session_start` hook.
+
+```bash
+ZULIP_ROLE=router pm2 start "$(which pi)" --name abiba-zulip \
+  --interpreter none -- --mode rpc --no-session
+```
+
+**Additional fixes applied:**
+- Fixed `models.json`: replaced `qwen3.6-35B-A3B` (not authorized by LiteLLM)
+  with `syslog-auto` + `strix-moe` (prevents silent worker failure per
+  Lesson #11)
+- Removed stale systemd unit `abiba-zulip.service` (pointed to old TS code)
+- PM2 saved for auto-restart on boot
+
+## Appendix: PM2 Ecosystem Config (Optional)
+
+If preferred over manual `pm2 start`, create `/root/ecosystem.config.js` entry:
+
+```js
+module.exports = {
+  apps: [{
+    name: 'abiba-zulip',
+    script: '/bin/pi',
+    interpreter: 'none',
+    args: '--mode rpc --no-session',
+    cwd: '/root',
+    env: {
+      ZULIP_ROLE: 'router',
+    },
+    log_file: '/root/.pm2/logs/abiba-zulip-out.log',
+    error_file: '/root/.pm2/logs/abiba-zulip-error.log',
+    max_restarts: 20,
+    restart_delay: 5000,
+  }]
+};
+```
+
+---
+
+**Last verified good state**: 2026-07-13 — Extension v2 running via `pi --mode rpc`, health endpoint :9200 returning `{status:"ok",connected:true}`, queue a669f21e.

cron-prompts-review.md

@@ -0,0 +1,612 @@
+# Cron Prompts Review — All 10 Scheduled Contracts
+
+Generated: 2026-07-13 20:59:18 ET
+
+---
+
+## hermes-key-enforcement
+
+**Category:** compliance | **Domain:** hermes-agent | **Owner:** abiba | **Schedule:** 0 6 * * *
+
+```
+Contract Enforcement: hermes-key-enforcement
+
+Category: compliance
+Domain: hermes-agent
+Owner: abiba
+Schedule: Daily compliance scan at 6am ET
+
+This is a compliance contract. Verify that the contract enforces the required standards and policies. Report any violations found.
+
+Steps:
+1. Load contract from prose-contracts/main (file: hermes-key-enforcement.prose.md)
+2. Verify prerequisites (connectivity, tools, deps)
+3. Execute contract per SOP
+4. Run postconditions from contract registry
+5. Generate receipt with status (pass/fail/escalated)
+6. If any postcondition fails, escalate per contract escalation tiers
+7. Log to ~/.hermes/runs/hermes-key-enforcement/
+
+Postconditions to verify:
+[
+  {
+    "check": "no plaintext API keys in config",
+    "verify": "grep -rc 'api_key: sk-' /root/.hermes/config.yaml",
+    "expect": "0 matches"
+  },
+  {
+    "check": "api_key_env used for harness/litellm providers",
+    "verify": "grep -c 'api_key_env.*LITELLM_API_KEY' /root/.hermes/config.yaml",
+    "expect": "count > 0"
+  }
+]
+
+Escalation Tiers:
+- INFO: notify nobody → action: log_to_receipt
+- WARNING: notify abiba → action: relay_alert
+- CRITICAL: notify abiba, mumuni → action: relay_alert + pause
+- FATAL: notify abiba, mumuni, kwame → action: relay_alert + pause + human_required
+
+Circuit Breaker:
+- Max retries: 3 per 60.0min window
+- On trip: escalate_to_fatal
+
+Receipt format: JSON with contract, run_id, timestamp, agent, status, actions_taken, postconditions, drift_alerts, evidence_path
+Receipt storage: ~/.hermes/runs/hermes-key-enforcement/receipt-{timestamp}.json
+Graph node: Create RA-H OS node for receipt with metadata: type=receipt, contract=hermes-key-enforcement, status=<status>
+
+If the contract has no postconditions defined (e.g., reference/pattern contracts), log that it was loaded and skip execution.
+
+IMPORTANT: If the contract file does not exist in prose-contracts/main, report failure and do NOT hallucinate forward.
+```
+
+---
+
+## hermes-config-template
+
+**Category:** compliance | **Domain:** hermes-agent | **Owner:** abiba | **Schedule:** 0 4 * * 1
+
+```
+Contract Enforcement: hermes-config-template
+
+Category: compliance
+Domain: hermes-agent
+Owner: abiba
+Schedule: Weekly config drift check Monday at 4am ET
+
+This is a compliance contract. Verify that the contract enforces the required standards and policies. Report any violations found.
+
+Steps:
+1. Load contract from prose-contracts/main (file: hermes-config-template.prose.md)
+2. Verify prerequisites (connectivity, tools, deps)
+3. Execute contract per SOP
+4. Run postconditions from contract registry
+5. Generate receipt with status (pass/fail/escalated)
+6. If any postcondition fails, escalate per contract escalation tiers
+7. Log to ~/.hermes/runs/hermes-config-template/
+
+Postconditions to verify:
+[
+  {
+    "check": "agent config template_version matches template file",
+    "verify": "grep -q 'template_version' /root/.hermes/config.yaml && diff <(grep 'template_version' /root/.hermes/config.yaml | cut -d: -f2 | xargs) <(grep 'template_version' /root/prose-contracts/hermes-config-template.prose.md | cut -d: -f2 | xargs) && echo match || echo mismatch",
+    "expect": "match"
+  },
+  {
+    "check": "config file is valid YAML",
+    "verify": "python3 -c 'import yaml; yaml.safe_load(open(\"/root/.hermes/config.yaml\"))' && echo valid || echo invalid",
+    "expect": "valid"
+  }
+]
+
+Escalation Tiers:
+- INFO: notify nobody → action: log_to_receipt
+- WARNING: notify abiba → action: relay_alert
+- CRITICAL: notify abiba, mumuni → action: relay_alert
+- FATAL: notify abiba, mumuni, kwame → action: relay_alert + human_required
+
+Circuit Breaker:
+- Max retries: 3 per 60.0min window
+- On trip: escalate_to_fatal
+
+Receipt format: JSON with contract, run_id, timestamp, agent, status, actions_taken, postconditions, drift_alerts, evidence_path
+Receipt storage: ~/.hermes/runs/hermes-config-template/receipt-{timestamp}.json
+Graph node: Create RA-H OS node for receipt with metadata: type=receipt, contract=hermes-config-template, status=<status>
+
+If the contract has no postconditions defined (e.g., reference/pattern contracts), log that it was loaded and skip execution.
+
+IMPORTANT: If the contract file does not exist in prose-contracts/main, report failure and do NOT hallucinate forward.
+```
+
+---
+
+## hermes-agent-baseline
+
+**Category:** compliance | **Domain:** hermes-agent | **Owner:** abiba | **Schedule:** 0 5 * * 1
+
+```
+Contract Enforcement: hermes-agent-baseline
+
+Category: compliance
+Domain: hermes-agent
+Owner: abiba
+Schedule: Weekly baseline verification Monday at 5am ET
+
+This is a compliance contract. Verify that the contract enforces the required standards and policies. Report any violations found.
+
+Steps:
+1. Load contract from prose-contracts/main (file: hermes-agent-baseline.prose.md)
+2. Verify prerequisites (connectivity, tools, deps)
+3. Execute contract per SOP
+4. Run postconditions from contract registry
+5. Generate receipt with status (pass/fail/escalated)
+6. If any postcondition fails, escalate per contract escalation tiers
+7. Log to ~/.hermes/runs/hermes-agent-baseline/
+
+Postconditions to verify:
+[
+  {
+    "check": "Hermes agent process running",
+    "verify": "pgrep -f 'hermes' > /dev/null && echo running || echo stopped",
+    "expect": "running"
+  },
+  {
+    "check": "agent config file exists and valid YAML",
+    "verify": "test -f /root/.hermes/config.yaml && python3 -c 'import yaml; yaml.safe_load(open(\"/root/.hermes/config.yaml\"))' && echo valid || echo invalid",
+    "expect": "valid"
+  },
+  {
+    "check": "no uncommitted changes in hermes directory",
+    "verify": "cd /root/.hermes && git status --porcelain | wc -l",
+    "expect": "0"
+  }
+]
+
+Escalation Tiers:
+- INFO: notify nobody → action: log_to_receipt
+- WARNING: notify abiba → action: relay_alert
+- CRITICAL: notify abiba, mumuni → action: relay_alert
+- FATAL: notify abiba, mumuni, kwame → action: relay_alert + human_required
+
+Circuit Breaker:
+- Max retries: 3 per 60.0min window
+- On trip: escalate_to_fatal
+
+Receipt format: JSON with contract, run_id, timestamp, agent, status, actions_taken, postconditions, drift_alerts, evidence_path
+Receipt storage: ~/.hermes/runs/hermes-agent-baseline/receipt-{timestamp}.json
+Graph node: Create RA-H OS node for receipt with metadata: type=receipt, contract=hermes-agent-baseline, status=<status>
+
+If the contract has no postconditions defined (e.g., reference/pattern contracts), log that it was loaded and skip execution.
+
+IMPORTANT: If the contract file does not exist in prose-contracts/main, report failure and do NOT hallucinate forward.
+```
+
+---
+
+## proxmox-monitor
+
+**Category:** monitoring | **Domain:** proxmox | **Owner:** abiba | **Schedule:** */15 * * * *
+
+```
+Contract Enforcement: proxmox-monitor
+
+Category: monitoring
+Domain: proxmox
+Owner: abiba
+Schedule: Every 15 minutes
+
+This is a monitoring contract. Execute the monitoring checks defined in the contract. Report any deviations from expected state.
+
+Steps:
+1. Load contract from prose-contracts/main (file: proxmox-monitor.prose.md)
+2. Verify prerequisites (connectivity, tools, deps)
+3. Execute contract per SOP
+4. Run postconditions from contract registry
+5. Generate receipt with status (pass/fail/escalated)
+6. If any postcondition fails, escalate per contract escalation tiers
+7. Log to ~/.hermes/runs/proxmox-monitor/
+
+Postconditions to verify:
+[
+  {
+    "check": "all Proxmox nodes reachable",
+    "verify": "curl -sf http://192.168.68.10:8006/api2/json/status | jq '.status'",
+    "expect": "healthy"
+  },
+  {
+    "check": "no VMs in crashed state",
+    "verify": "pvesh get /nodes -output-format=json | jq '.[] | select(.status==\"Crashed\")'",
+    "expect": "empty"
+  },
+  {
+    "check": "backups running on schedule",
+    "verify": "pbs-info --check",
+    "expect": "last_backup < 24h ago"
+  }
+]
+
+Escalation Tiers:
+- INFO: notify nobody → action: log_to_receipt
+- WARNING: notify abiba, mumuni → action: relay_alert
+- CRITICAL: notify abiba, mumuni → action: relay_alert + trigger_remediation
+- FATAL: notify abiba, mumuni, kwame → action: relay_alert + pause + human_required
+
+Circuit Breaker:
+- Max retries: 3 per 60.0min window
+- On trip: escalate_to_fatal
+
+Receipt format: JSON with contract, run_id, timestamp, agent, status, actions_taken, postconditions, drift_alerts, evidence_path
+Receipt storage: ~/.hermes/runs/proxmox-monitor/receipt-{timestamp}.json
+Graph node: Create RA-H OS node for receipt with metadata: type=receipt, contract=proxmox-monitor, status=<status>
+
+If the contract has no postconditions defined (e.g., reference/pattern contracts), log that it was loaded and skip execution.
+
+IMPORTANT: If the contract file does not exist in prose-contracts/main, report failure and do NOT hallucinate forward.
+```
+
+---
+
+## gpu-monitor
+
+**Category:** monitoring | **Domain:** gpu | **Owner:** abiba | **Schedule:** */15 * * * *
+
+```
+Contract Enforcement: gpu-monitor
+
+Category: monitoring
+Domain: gpu
+Owner: abiba
+Schedule: Every 15 minutes — polls all GPU subsystems
+
+This is a monitoring contract. Execute the monitoring checks defined in the contract. Report any deviations from expected state.
+
+Steps:
+1. Load contract from prose-contracts/main (file: gpu-monitor.prose.md)
+2. Verify prerequisites (connectivity, tools, deps)
+3. Execute contract per SOP
+4. Run postconditions from contract registry
+5. Generate receipt with status (pass/fail/escalated)
+6. If any postcondition fails, escalate per contract escalation tiers
+7. Log to ~/.hermes/runs/gpu-monitor/
+
+Postconditions to verify:
+[
+  {
+    "check": "GPU metrics accessible",
+    "verify": "curl -sf http://localhost:9100/gpu-data",
+    "expect": "200 OK, populated data"
+  },
+  {
+    "check": "dashboard serving",
+    "verify": "curl -sf http://localhost:9100/gpu-fleet.html",
+    "expect": "200 OK, HTML returned"
+  },
+  {
+    "check": "health endpoint responsive",
+    "verify": "curl -sf http://localhost:9100/health",
+    "expect": "200 OK"
+  }
+]
+
+Escalation Tiers:
+- INFO: notify nobody → action: log_to_receipt
+- WARNING: notify abiba, mumuni → action: relay_alert
+- CRITICAL: notify abiba, mumuni → action: relay_alert + trigger_remediation
+- FATAL: notify abiba, mumuni, kwame → action: relay_alert + pause + human_required
+
+Circuit Breaker:
+- Max retries: 3 per 60.0min window
+- On trip: escalate_to_fatal
+
+Receipt format: JSON with contract, run_id, timestamp, agent, status, actions_taken, postconditions, drift_alerts, evidence_path
+Receipt storage: ~/.hermes/runs/gpu-monitor/receipt-{timestamp}.json
+Graph node: Create RA-H OS node for receipt with metadata: type=receipt, contract=gpu-monitor, status=<status>
+
+If the contract has no postconditions defined (e.g., reference/pattern contracts), log that it was loaded and skip execution.
+
+IMPORTANT: If the contract file does not exist in prose-contracts/main, report failure and do NOT hallucinate forward.
+```
+
+---
+
+## infrastructure-monitoring
+
+**Category:** monitoring | **Domain:** infrastructure | **Owner:** abiba | **Schedule:** */30 * * * *
+
+```
+Contract Enforcement: infrastructure-monitoring
+
+Category: monitoring
+Domain: infrastructure
+Owner: abiba
+Schedule: Every 30 minutes
+
+This is a monitoring contract. Execute the monitoring checks defined in the contract. Report any deviations from expected state.
+
+Steps:
+1. Load contract from prose-contracts/main (file: infrastructure-monitoring.prose.md)
+2. Verify prerequisites (connectivity, tools, deps)
+3. Execute contract per SOP
+4. Run postconditions from contract registry
+5. Generate receipt with status (pass/fail/escalated)
+6. If any postcondition fails, escalate per contract escalation tiers
+7. Log to ~/.hermes/runs/infrastructure-monitoring/
+
+Postconditions to verify:
+[
+  {
+    "check": "Proxmox API reachable",
+    "verify": "curl -sf http://192.168.68.10:8006/api2/json",
+    "expect": "200 OK"
+  },
+  {
+    "check": "Zulip API reachable",
+    "verify": "curl -sf https://chat.sysloggh.net/api/v1/me",
+    "expect": "200 OK"
+  },
+  {
+    "check": "LiteLLM proxy reachable",
+    "verify": "curl -sf http://192.168.68.116/litellm/v1/models",
+    "expect": "200 OK"
+  },
+  {
+    "check": "Gitea API reachable",
+    "verify": "curl -sf https://git.sysloggh.net/api/v1/version",
+    "expect": "200 OK"
+  },
+  {
+    "check": "SearXNG reachable",
+    "verify": "curl -sf http://192.168.68.17:8080",
+    "expect": "200 OK"
+  }
+]
+
+Escalation Tiers:
+- INFO: notify nobody → action: log_to_receipt
+- WARNING: notify abiba, mumuni → action: relay_alert
+- CRITICAL: notify abiba, mumuni → action: relay_alert + trigger_remediation
+- FATAL: notify abiba, mumuni, kwame → action: relay_alert + pause + human_required
+
+Circuit Breaker:
+- Max retries: 3 per 60.0min window
+- On trip: escalate_to_fatal
+
+Receipt format: JSON with contract, run_id, timestamp, agent, status, actions_taken, postconditions, drift_alerts, evidence_path
+Receipt storage: ~/.hermes/runs/infrastructure-monitoring/receipt-{timestamp}.json
+Graph node: Create RA-H OS node for receipt with metadata: type=receipt, contract=infrastructure-monitoring, status=<status>
+
+If the contract has no postconditions defined (e.g., reference/pattern contracts), log that it was loaded and skip execution.
+
+IMPORTANT: If the contract file does not exist in prose-contracts/main, report failure and do NOT hallucinate forward.
+```
+
+---
+
+## zulip-health
+
+**Category:** monitoring | **Domain:** zulip | **Owner:** abiba | **Schedule:** */15 * * * *
+
+```
+Contract Enforcement: zulip-health
+
+Category: monitoring
+Domain: zulip
+Owner: abiba
+Schedule: Every 15 minutes — monitors all Zulip-connected agents
+
+This is a monitoring contract. Execute the monitoring checks defined in the contract. Report any deviations from expected state.
+
+Steps:
+1. Load contract from prose-contracts/main (file: zulip-health.prose.md)
+2. Verify prerequisites (connectivity, tools, deps)
+3. Execute contract per SOP
+4. Run postconditions from contract registry
+5. Generate receipt with status (pass/fail/escalated)
+6. If any postcondition fails, escalate per contract escalation tiers
+7. Log to ~/.hermes/runs/zulip-health/
+
+Postconditions to verify:
+[
+  {
+    "check": "bot registration active",
+    "verify": "curl -sf https://chat.sysloggh.net/api/v1/me | jq '.user_id'",
+    "expect": "bot_id present"
+  },
+  {
+    "check": "DM delivery working",
+    "verify": "curl -sf https://chat.sysloggh.net/api/v1/users/me/is-online",
+    "expect": "online: true"
+  }
+]
+
+Escalation Tiers:
+- INFO: notify nobody → action: log_to_receipt
+- WARNING: notify abiba, mumuni → action: relay_alert
+- CRITICAL: notify abiba, mumuni → action: relay_alert + trigger_remediation
+- FATAL: notify abiba, mumuni, kwame → action: relay_alert + pause + human_required
+
+Circuit Breaker:
+- Max retries: 3 per 60.0min window
+- On trip: escalate_to_fatal
+
+Receipt format: JSON with contract, run_id, timestamp, agent, status, actions_taken, postconditions, drift_alerts, evidence_path
+Receipt storage: ~/.hermes/runs/zulip-health/receipt-{timestamp}.json
+Graph node: Create RA-H OS node for receipt with metadata: type=receipt, contract=zulip-health, status=<status>
+
+If the contract has no postconditions defined (e.g., reference/pattern contracts), log that it was loaded and skip execution.
+
+IMPORTANT: If the contract file does not exist in prose-contracts/main, report failure and do NOT hallucinate forward.
+```
+
+---
+
+## litellm-health
+
+**Category:** monitoring | **Domain:** litellm | **Owner:** abiba | **Schedule:** */10 * * * *
+
+```
+Contract Enforcement: litellm-health
+
+Category: monitoring
+Domain: litellm
+Owner: abiba
+Schedule: Every 10 minutes — LiteLLM proxy health
+
+This is a monitoring contract. Execute the monitoring checks defined in the contract. Report any deviations from expected state.
+
+Steps:
+1. Load contract from prose-contracts/main (file: litellm-health.prose.md)
+2. Verify prerequisites (connectivity, tools, deps)
+3. Execute contract per SOP
+4. Run postconditions from contract registry
+5. Generate receipt with status (pass/fail/escalated)
+6. If any postcondition fails, escalate per contract escalation tiers
+7. Log to ~/.hermes/runs/litellm-health/
+
+Postconditions to verify:
+[
+  {
+    "check": "LiteLLM proxy reachable",
+    "verify": "curl -sf http://192.168.68.116/litellm/v1/models",
+    "expect": "200 OK, models returned"
+  },
+  {
+    "check": "router deprecated, nginx routes work",
+    "verify": "curl -sf https://litellm.sysloggh.net/v1/models",
+    "expect": "200 OK (via nginx)"
+  }
+]
+
+Escalation Tiers:
+- INFO: notify nobody → action: log_to_receipt
+- WARNING: notify abiba, mumuni → action: relay_alert
+- CRITICAL: notify abiba, mumuni → action: relay_alert + trigger_remediation
+- FATAL: notify abiba, mumuni, kwame → action: relay_alert + pause + human_required
+
+Circuit Breaker:
+- Max retries: 3 per 60.0min window
+- On trip: escalate_to_fatal
+
+Receipt format: JSON with contract, run_id, timestamp, agent, status, actions_taken, postconditions, drift_alerts, evidence_path
+Receipt storage: ~/.hermes/runs/litellm-health/receipt-{timestamp}.json
+Graph node: Create RA-H OS node for receipt with metadata: type=receipt, contract=litellm-health, status=<status>
+
+If the contract has no postconditions defined (e.g., reference/pattern contracts), log that it was loaded and skip execution.
+
+IMPORTANT: If the contract file does not exist in prose-contracts/main, report failure and do NOT hallucinate forward.
+```
+
+---
+
+## memory-audit-maintenance
+
+**Category:** maintenance | **Domain:** memory | **Owner:** mumuni | **Schedule:** 0 3 * * *
+
+```
+Contract Enforcement: memory-audit-maintenance
+
+Category: maintenance
+Domain: memory
+Owner: mumuni
+Schedule: Daily at 3am ET
+
+This is a maintenance contract. Execute the maintenance tasks defined in the contract. Report any issues found.
+
+Steps:
+1. Load contract from prose-contracts/main (file: memory-audit-maintenance.prose.md)
+2. Verify prerequisites (connectivity, tools, deps)
+3. Execute contract per SOP
+4. Run postconditions from contract registry
+5. Generate receipt with status (pass/fail/escalated)
+6. If any postcondition fails, escalate per contract escalation tiers
+7. Log to ~/.hermes/runs/memory-audit-maintenance/
+
+Postconditions to verify:
+[
+  {
+    "check": "memory files below 80% capacity",
+    "verify": "wc -l ~/.hermes/memories/*.md",
+    "expect": "total lines < threshold"
+  },
+  {
+    "check": "no stale entries",
+    "verify": "grep -r 'STALE' ~/.hermes/memories/",
+    "expect": "0 matches"
+  }
+]
+
+Escalation Tiers:
+- INFO: notify nobody → action: log_to_receipt
+- WARNING: notify mumuni → action: relay_alert
+- CRITICAL: notify mumuni, abiba → action: relay_alert
+- FATAL: notify mumuni, abiba, kwame → action: relay_alert + human_required
+
+Circuit Breaker:
+- Max retries: 3 per 60.0min window
+- On trip: escalate_to_fatal
+
+Receipt format: JSON with contract, run_id, timestamp, agent, status, actions_taken, postconditions, drift_alerts, evidence_path
+Receipt storage: ~/.hermes/runs/memory-audit-maintenance/receipt-{timestamp}.json
+Graph node: Create RA-H OS node for receipt with metadata: type=receipt, contract=memory-audit-maintenance, status=<status>
+
+If the contract has no postconditions defined (e.g., reference/pattern contracts), log that it was loaded and skip execution.
+
+IMPORTANT: If the contract file does not exist in prose-contracts/main, report failure and do NOT hallucinate forward.
+```
+
+---
+
+## infrastructure-update
+
+**Category:** maintenance | **Domain:** infrastructure | **Owner:** abiba | **Schedule:** 0 2 * * 0
+
+```
+Contract Enforcement: infrastructure-update
+
+Category: maintenance
+Domain: infrastructure
+Owner: abiba
+Schedule: Weekly system updates Sunday at 2am ET
+
+This is a maintenance contract. Execute the maintenance tasks defined in the contract. Report any issues found.
+
+Steps:
+1. Load contract from prose-contracts/main (file: infrastructure-update.prose.md)
+2. Verify prerequisites (connectivity, tools, deps)
+3. Execute contract per SOP
+4. Run postconditions from contract registry
+5. Generate receipt with status (pass/fail/escalated)
+6. If any postcondition fails, escalate per contract escalation tiers
+7. Log to ~/.hermes/runs/infrastructure-update/
+
+Postconditions to verify:
+[
+  {
+    "check": "all services running after update",
+    "verify": "systemctl list-units --state=running",
+    "expect": "all critical services"
+  }
+]
+
+Escalation Tiers:
+- INFO: notify nobody → action: log_to_receipt
+- WARNING: notify abiba → action: relay_alert
+- CRITICAL: notify abiba, mumuni → action: relay_alert
+- FATAL: notify abiba, mumuni, kwame → action: relay_alert + human_required
+
+Circuit Breaker:
+- Max retries: 1 per 120.0min window
+- On trip: escalate_to_fatal
+
+Receipt format: JSON with contract, run_id, timestamp, agent, status, actions_taken, postconditions, drift_alerts, evidence_path
+Receipt storage: ~/.hermes/runs/infrastructure-update/receipt-{timestamp}.json
+Graph node: Create RA-H OS node for receipt with metadata: type=receipt, contract=infrastructure-update, status=<status>
+
+If the contract has no postconditions defined (e.g., reference/pattern contracts), log that it was loaded and skip execution.
+
+IMPORTANT: If the contract file does not exist in prose-contracts/main, report failure and do NOT hallucinate forward.
+```
+
+
+---
+*End of review*

gpu-fleet.prose.md

@@ -5,13 +5,16 @@ description: >
   Manages the GPU inference fleet across all hosts. Handles model deployment,
   registration, health checks, LiteLLM sync, agent key management, GPU
   saturation watchdog, Prometheus/Grafana monitoring, and self-healing.
-  UPDATED 2026-07-12: Architecture is DIRECT GPU — LiteLLM routes directly
-  to llama-server on each GPU host (no router in inference path). Router
-  (port 9000) is running but NOT in request path. All GPUs standardized on
-  api-key 'not-needed'. RTX 5070 had api-key mismatch (sk-loc...5678) that
-  caused cascading 401→timeout→401 fallback loops — fixed.
-  Context: RTX 3090 verified at 256K (was documented as 128K — WRONG).
-  Workload: Compression moved to Strix Halo, RTX 5070 → vision/web only.
+  UPDATED 2026-07-15: Stable role-based aliases introduced: strix-moe,
+  gpu-dense, gpu-light. These never change — only the underlying model does.
+  Strix Halo: strix-moe → unsloth/Qwen3.6-35B-A3B-MTP (UD-Q4_K_M, 22GB).
+  RTX 5070: gemma-4-12b Q4_K_M → IQ4_NL + MTP draft (122 tok/s, 2x faster).
+  UPDATED 2026-07-17: Context reduced fleet-wide from 256K to 128K for stability.
+  Strix Halo model swapped to Genesis Hermes V3 APEX (LuffyTheFox, 24GB, uncensored,
+  Hermes agent fine-tune, tensor repair, multimodal with mmproj).
+  Instability observed near 100K at 256K. 128K is the stable ceiling.
+  For larger context needs → fall back to external providers (deepseek).
+  VRAM headroom improved: RTX 3090 ~70%, RTX 5070 ~65%.
 agent: abiba
 triggers:
   - on model add/remove
@@ -68,48 +71,72 @@ triggers:
 │ CT 8     │  │ CT 110      │  │ CT 15     │  │ pi (.24)     │
 │ RTX 3090 │  │ RTX 5070    │  │ Strix Halo│  │ GPU Monitor  │
 │ 24GB     │  │ 12GB        │  │ 64GB UMA  │  │ :9100        │
-│ 256K ctx │  │ 131K ctx    │  │ 256K ctx  │  │ Watchdog     │
-│ qwen3.6  │  │ gemma-4-12b │  │ ornith35B │  │ Prometheus   │
-│ 27B-code │  │ :8080       │  │ :8080     │  │ exporter     │
+│ 128K ctx │  │ 128K ctx    │  │ 128K ctx  │  │ Watchdog     │
+│ qwen3.6  │  │ gemma-4-12b │  │ qwen3.6   │  │ Prometheus   │
+│ 27B-code │  │ :8080       │  │ -35B-udq4 │  │ exporter     │
 │ :8080    │  │ :9400 (exp) │  │ :9400(exp)│  │ :9401        │
 │ :9400    │  └─────────────┘  └───────────┘  └──────────────┘
 └──────────┘
 ```
 
-## Current Model Assignments (2026-07-12)
+## Stable Role-Based Aliases (Introduced 2026-07-15)
+
+Agent configs, cron jobs, and workflows MUST use these aliases, never model-specific names.
+When a model is swapped on a GPU, ONLY the infrastructure layer changes — agent configs are untouched.
+
+| Alias | GPU | Current Model | Will Route To |
+|-------|-----|---------------|---------------|
+| `strix-moe` | Strix Halo (.15) | qwen3.6-35B-udq4 | Whatever runs on Strix Halo |
+| `gpu-dense` | RTX 3090 (.8) | qwen3.6-27B-code | Whatever runs on RTX 3090 |
+| `gpu-light` | RTX 5070 (.110) | gemma-4-12b | Whatever runs on RTX 5070 |
+
+**Backward compatibility**: Old model-specific names (qwen3.6-27B-code, gemma-4-12b, qwen3.6-35B-udq4) still work
+but are deprecated for agent configs. Only the stable aliases survive model swaps.
+
+## Current Model Assignments (2026-07-15)
 
 | Model | GPU | Host | VRAM | Ctx | KV Cache | Parallel | Batch/Ubatch | Status |
 |-------|-----|------|------|-----|----------|----------|-------------|--------|
-| qwen3.6-27B-code | RTX 3090 | .8 (llm-gpu) | 20.7/24GB (84%) | **256K** | turbo4 | 1 | default | ✅ healthy |
-| gemma-4-12b | RTX 5070 | .110 (ocu-llm) | 10.0/12.2GB (82%) | 131K | q4_0 | 2 | 2048/1024 | ✅ healthy |
-| ornith-1.0-35b | Strix Halo Vulkan | .15 (amdpve) | ~9GB/64GB | 256K | q8_0 | 2 | 2048/512 | ✅ healthy |
+| qwen3.6-27B-code (MTP) | RTX 3090 | .8 (llm-gpu) | ~17/24.6GB (70%) | **128K** | turbo4 | 2 | default | ✅ 63 tok/s |
+| gemma-4-12b | RTX 5070 | .110 (ocu-llm) | ~7.8/12.2GB (65%) | 128K | q4_0 | 2 | 2048/1024 | ✅ healthy |
+| Genesis Hermes V3 APEX | Strix Halo Vulkan | .15 (amdpve) | ~10GB/64GB | 128K | q4_0 | 1 | 4096/1024 | ✅ 65 tok/s |
 
 ## Routing Configuration (LiteLLM — July 2026)
 
-### syslog-auto Weighted Pool
+### syslog-auto Weighted Pool (Direct GPU — bypasses router)
 
-| Model | GPU | Weight | RPM Cap | Purpose |
+| Model | GPU | Weight | RPM Cap | Timeout |
 |-------|-----|--------|---------|---------|
-| qwen3.6-27B-code | RTX 3090 | 0.55 | 500 | Heavy reasoning, code, long context |
-| ornith-1.0-35b | Strix Halo | 0.30 | **60** | Agentic workflows, tool calling |
-| gemma-4-12b | RTX 5070 | 0.15 | 200 | Overflow + vision |
+| qwen3.6-27B-code | RTX 3090 (.8:8080) | **0.55** | 500 | **300s** |
+| Genesis Hermes V3 APEX | Strix Halo (.15:8080) | **0.30** | 60 | **300s** |
+| gemma-4-12b | RTX 5070 (.110:8080) | **0.15** | 200 | **120s** |
+
+Note: All syslog-auto entries route directly to GPUs with `api_key: not-needed`. The router (port 9000) is NOT in the inference path.
 
 ### Direct Model Endpoints
 
 | Model | RPM Cap | Notes |
 |-------|---------|-------|
-| ornith-1.0-35b | 40 | Tight cap — prevents Strix overload |
+| strix-moe (Hermes V3) | 40 | Tight cap — prevents Strix overload |
 | qwen3.6-27B-code | 500 | High cap — primary workhorse |
-| gemma-4-12b | 500 | High cap — fast 12B |
+| gemma-4-12b | 500 | High cap — IQ4_NL+MTP, 122 tok/s |
+
+### Stable Aliases (for agent configs — never change)
+
+| Alias | RPM Cap | Routes To | Purpose |
+|-------|---------|-----------|---------|
+| `strix-moe` | 40 | Strix Halo | Compression tasks (MoE models) |
+| `gpu-dense` | 500 | RTX 3090 | Heavy reasoning |
+| `gpu-light` | 500 | RTX 5070 | Vision, web extract, light tasks |
 
 ### Fallback Chains
 - gemma → qwen
 - qwen → gemma
-- ornith → qwen → gemma
-- syslog-auto → qwen → gemma → ornith
+- strix-moe → qwen → gemma
+- syslog-auto → qwen → gemma → qwen3.6-35B-udq4
 
-### Why ornith RPM Is Capped
-- Direct: 40 RPM (tight) — Strix Halo is shared with compression tasks
+### Why Strix Halo RPM Is Capped
+- Direct (strix-moe): 40 RPM (tight) — Strix Halo is shared with compression tasks
 - Via syslog-auto: 60 RPM (moderate) — prevents flooding when multiple agents use syslog-auto simultaneously
 - Combined max: ~100 RPM across both paths — Strix Halo can sustain this at 80°C
 
@@ -163,7 +190,7 @@ Show full fleet status: GPUs, models, VRAM, context windows, parallel slots, act
 3. Check LiteLLM: `curl http://192.168.68.116/health` (expect "I'm alive!")
 4. Check LiteLLM models: `curl -H "Authorization: Bearer $MASTER_KEY" http://192.168.68.116/v1/models`
 5. Check LiteLLM timeouts: `grep -n 'timeout:' /opt/inference-harness/litellm_config.yaml`
-   - gemma-4-12b: 120s, qwen3.6-27B: 90s, ornith-1.0-35b: 120s
+   - gemma-4-12b: 120s, qwen3.6-27B-code: 300s, qwen3.6-35B-udq4/strix-moe: 300s (strix-moe does NOT exist — legacy name, do not use)
    - global request_timeout: 300s, nginx proxy_read_timeout: 600s
 6. Check AMD metrics: `curl http://192.168.68.15:9400/metrics` (Radeon 8060S, util%, VRAM, temp, power)
 7. Check port conflicts: verify only one llama-server on :8080 per host
@@ -203,7 +230,7 @@ If no SSH access, send Zulip DM via abiba-bot with vault update instructions.
 | `/root/scripts/gpu-saturation-watchdog.py` | pi (.24) | Auto-restart stuck llama-server |
 | `/root/dashboard/gpu-fleet.html` | pi (.24) | Live HTML dashboard |
 | `/etc/systemd/system/llama-server.service` | .8, .110 | llama-server daemons (Nvidia GPUs) |
-| `/etc/systemd/system/ornith-server.service` | .15 (amdpve) | llama-server daemon (Vulkan, Strix Halo). Note: `llama-server.service` and `llama-server@.service` are **masked** on .15 to prevent port 8080 collisions. |
+| `/etc/systemd/system/strix-server.service` | .15 (amdpve) | llama-server daemon (Vulkan, Strix Halo) running unsloth/Qwen3.6-35B-A3B-MTP-GGUF. Note: `llama-server.service` and `llama-server@.service` are **masked** on .15 to prevent port 8080 collisions. |
 
 ## Prometheus & Grafana
 
@@ -220,14 +247,14 @@ If no SSH access, send Zulip DM via abiba-bot with vault update instructions.
 - **Router startup race**: Compose router.py doesn't call load_roster(). Reload thread sleeps 30s first.
   Fix: trigger roster reload via SSH after restart, or rebuild image with startup load_roster().
 - **LiteLLM /metrics**: Requires auth. Prometheus uses `/health/liveliness` as workaround.
-- **VRAM (2026-07-12)**: RTX 3090 at 20.7/24GB (84%), RTX 5070 at 10.0/12.2GB (82%). RTX 3090 context increased to 256K (was incorrectly documented as 128K — verified via /proc/PID/cmdline).
-- **RTX 3090 runs `--parallel 1`** (verified 2026-07-12). RTX 5070 and Strix at parallel 2.
-- **RTX 3090 config**: `-c 262144 -ctk turbo4 -ctv turbo4 --parallel 1 --flash-attn on --cont-batching`. Service: `/home/llmuser/llama-wrapper.sh`.
-- **RTX 5070 config**: `--ctx-size 131072 --cache-type-k q4_0 --cache-type-v q4_0 --batch-size 2048 --ubatch-size 1024 --parallel 2`. Api-key standardized to `not-needed` (was `sk-loc...5678` causing 401 loops). Service: `/home/llmuser/llama-wrapper.sh`.
-- **LiteLLM timeout tuning (2026-07-08)**: gemma-4-12b 25→120s, qwen3.6-27B-code 40→90s, syslog-auto (qwen route) 40→90s. Nginx proxy_read_timeout: 600s. Global request_timeout: 300s. Config at `/opt/inference-harness/litellm_config.yaml`.
-- **Strix Halo GPU**: Vulkan is the working backend (ROCm/HIP path abandoned — HSA runtime blocked on Debian 13). Build at `/root/llama.cpp/build-vk/`, commit `4fc4ec5` (2026-07-01), ggml 0.15.3 shared-lib arch. Mesa RADV 25.0.7, KHR_coopmat fast path active. ~70 tok/s gen, 532 tok/s prompt. Service: `ornith-server.service` on port 8080, 256K context, flash-attn + q8 KV.
+- **VRAM (2026-07-15)**: RTX 3090 at ~17/24.6GB (~70%) with **128K context** (reduced from 256K 2026-07-17). RTX 5070 at ~7.8/12.2GB (~65%) with 128K context + MTP. Strix Halo at ~7GB/64GB.
+- **RTX 3090 runs `--parallel 2`** with MTP draft (spec-type draft-mtp, spec-draft-n-max 2).
+- **RTX 3090 config**: `-c 131072 -ctk turbo4 -ctv turbo4 --parallel 2 --flash-attn on --cont-batching --spec-type draft-mtp`. Context reduced to 128K (2026-07-17, was 256K). VRAM: ~70%. Service: `/home/llmuser/llama-wrapper.sh`.
+- **RTX 5070 config (2026-07-15)**: Switched to IQ4_NL + MTP draft (Q8_0) at 128K context. Gen speed: 122 tok/s. VRAM: ~7.8/12.2GB (~65%). Service: `/home/llmuser/llama-wrapper.sh`. Config: `--model gemma-4-12b-it-IQ4_NL.gguf --spec-draft-model gemma-4-12b-it-Q8_0-MTP.gguf --spec-type draft-mtp --spec-draft-n-max 4 --ctx-size 131072`.
+- **LiteLLM timeout tuning (verified 2026-07-16 against `/opt/inference-harness/litellm_config.yaml` on CT 116)**: gemma-4-12b 120s, qwen3.6-27B-code 300s, qwen3.6-35B-udq4 300s, strix-moe 300s, syslog-auto routes all 300s. Nginx proxy_read_timeout: 600s. Global request_timeout: 300s.
+- **Strix Halo GPU**: Vulkan is the working backend (ROCm/HIP path abandoned — HSA runtime blocked on Debian 13). Build at `/root/llama.cpp/build-vk/`, commit `4fc4ec5` (2026-07-01), ggml 0.15.3 shared-lib arch. Mesa RADV 25.0.7, KHR_coopmat fast path active. ~70 tok/s gen, 532 tok/s prompt. Service: `strix-server.service` on port 8080, model: `LuffyTheFox/Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-V3-GGUF` (APEX quant), alias `strix-moe`, 128K context, flash-attn + q4 KV, multimodal (mmproj loaded). Hermes agent fine-tune, tensor repair (SSM layers fixed via SVD), uncensored (0/465 refusals).
 - **Port conflict detection (2026-07-05)**: All 3 GPU wrappers now detect ghost processes squatting port 8080 before starting. `.8` and `.110` use inline pre-start check in `llama-wrapper.sh`; `.15` uses `/usr/local/bin/port-cleanup.sh` ExecStartPre. Replaces the blanket `pkill -9 -x llama-server` on .15 which would kill ALL llama-server instances regardless of port. Ghost detection was the root cause of .8 crash-looping for 27+ restarts (stale pid 25836 squatting 8080 after OOM kill).
-- **Strix Halo thermal safeguard (2026-07-02)**: `ornith-server.service` has `-n 8192` (hard generation cap per request). Without it, `--predict` defaults to -1 (infinity) — a runaway request from .123 (Mumuni) decoded 39,868 tokens over 24 min, pushing Tctl to 98°C (crit 89.8°C) and throttling 70→29 t/s. The cap bounds worst-case generation to ~5 min. Do NOT remove `-n` without a replacement ceiling. Sustained load hits ~84°C even at 92s; the APU is fanless/low-flow. Clients MUST also set `max_tokens`.
+- **Strix Halo thermal safeguard (2026-07-02)**: `strix-server.service` has `-n 8192` (hard generation cap per request). Without it, `--predict` defaults to -1 (infinity) — a runaway request from .123 (Mumuni) decoded 39,868 tokens over 24 min, pushing Tctl to 98°C (crit 89.8°C) and throttling 70→29 t/s. The cap bounds worst-case generation to ~5 min. Do NOT remove `-n` without a replacement ceiling. Sustained load hits ~84°C even at 92s; the APU is fanless/low-flow. Clients MUST also set `max_tokens`.
 - **Port 8080 firewall**: amdpve iptables restricts 8080 to 192.168.68.116 (LiteLLM/router host) only. All inbound connections are from .116 (LiteLLM proxied via nginx). Localhost curls hang (SYN dropped). Always test from .116.
 - **Router sidecar fallback**: `router.py` `check_gpu_health()` now probes GPU `/health` directly when sidecar at :8090 is absent. Sidecar JSON exporters not deployed on any GPU host — router relies on GPU-direct fallback.
 - **Router GPU_MOE_URL bug (fixed 2026-07-01)**: docker-compose had `GPU_MOE_URL=.110:8080` (gemma host) instead of `.15:8080` (amdpve). Corrected.
@@ -237,11 +264,14 @@ If no SSH access, send Zulip DM via abiba-bot with vault update instructions.
 
 ## GPU Inference Benchmarks (Current)
 
-| GPU | Model | Gen tok/s | Prompt tok/s | Baseline | Samples |
+| GPU | Model | Gen tok/s | Prompt tok/s | Baseline | Context |
 |-----|-------|-----------|--------------|----------|---------|
-| RTX 3090 (.8) | qwen3.6-27B-code | 75 | 305 | 74 | 6 |
-| RTX 5070 (.110) | gemma-4-12b | 75 | 323 | 75 | 6 |
-| Strix Halo (.15) | ornith-1.0-35b | 70 | 532 | 70 | 6 |
+| RTX 3090 (.8) | qwen3.6-27B-code (MTP) | **63** | — | — | **128K** |
+| RTX 5070 (.110) | gemma-4-12b (IQ4_NL+MTP) | **191** | — | — | **128K** |
+| Strix Halo (.15) | Genesis Hermes V3 APEX | **65** | 140 | — | **128K** |
+
+Benchmarks from 2026-07-17. Strix Halo swapped to Genesis Hermes V3 APEX (LuffyTheFox). RTX 5070 MTP provides 2.7x speedup over pre-upgrade 70 tok/s.
+All 3 GPUs now at 128K context (2026-07-17, reduced from 256K for stability).
 
 Benchmarks run through LiteLLM proxy (192.168.68.116:4001) every 5 minutes.
 Degradation alerts fire at 30% (warning) and 50% (critical) below baseline.
@@ -249,12 +279,55 @@ History stored at `/root/data/toks-history.json` with 7-day rolling window.
 
 **Note (2026-07-01)**: Strix Halo prompt tok/s jumped 209→532 after Vulkan rebuild (cooperative-matrix fast path now active on GFX1151). Baseline may need re-calibration.
 
-## Agent Config Implications (2026-07-12)
+## Agent Config Implications (2026-07-15)
 
-With RTX 3090 at 256K context (verified July 2026):
-- Agents using `syslog-auto` (55/30/15 qwen+ornith+gemma): `context_length: 262144` — ornith and qwen both support it
-- Agents using `qwen3.6-27B-code` directly: `context_length: 262144` (256K ctx verified)
-- Agents using `gemma-4-12b` directly (auxiliary tasks): `context_length: 131072`
-- Compression threshold at 0.65: fires at ~170K for 262K context window on Strix Halo
-- All Hermes clients MUST set `max_tokens: 4096` — first line of defense before server-side `-n 8192` cap
-- Port 8080 is used on all 3 GPU hosts (not 8090 as previously documented)
+### Stable Aliases — CRITICAL
+
+All agent configs MUST use stable role-based aliases, never model-specific names:
+- `compression.model: strix-moe` (NOT `qwen3.6-35B-udq4`)
+- `auxiliary.vision.model: gpu-light` (NOT `gemma-4-12b`)
+- `delegation.model: gpu-dense` (NOT `qwen3.6-27B-code`)
+- `auxiliary.web_extract.model: gpu-light`
+
+When the underlying model is swapped, only the LiteLLM config changes — agent configs are untouched.
+
+### Context Windows
+- RTX 3090: **128K** (reduced from 256K 2026-07-17) | RTX 5070: **128K** (reduced from 256K) | Strix Halo: **128K**
+- **All agents**: 128K ceiling — stable margin. For >128K workloads, use external providers (deepseek)
+- Compression threshold 0.65: fires at ~85K (~43K headroom before 128K ceiling)
+- Mumuni compression model alias: `strix-moe` with 300s timeout
+
+### Mumuni Agent Profile
+
+Mumuni (CT114, 192.168.68.123) is the primary business assistant. This profile is the reference for all agent configs:
+
+| Setting | Value | Notes |
+|---------|-------|-------|
+| `model.default` | `syslog-auto` | Weighted pool (55% qwen, 30% strix, 15% gemma) |
+| `model.provider` | `custom:litellm` | LiteLLM on CT116 |
+| `compression.model` | `strix-moe` | Stable alias — survives model swaps |
+| `aux.compression.model` | `strix-moe` | Compression auxiliary model |
+| `aux.vision.model` | `gpu-light` | Vision tasks (RTX 5070) |
+| `aux.web_extract.model` | `gpu-light` | Web extraction |
+| `delegation.model` | `gpu-dense` | Sub-agent reasoning (RTX 3090) |
+| `context.max_context_window` | 131072 (128K) | Reduced from 256K 2026-07-17 — stable 128K ceiling |
+| `compression.threshold` | 0.65 | Triggers at ~85K |
+| `compression.target_ratio` | 0.3 | Compresses to ~38K |
+| `compression.protect_last_n` | 40 | Preserves last 40 messages |
+| `memory.memory_char_limit` | 800 | Brief memory entries |
+| `personalities` | `creative` | Creative assistant personality |
+| Platforms | cli, discord, homeassistant, signal, telegram, zulip | All Hermes platforms |
+| Main model timeout | 300s | LiteLLM global timeout |
+| Compression model timeout | 300s | strix-moe timeout increased from 120s |
+
+### Agent Update Status (2026-07-15)
+
+| Agent | Host | Status |
+|-------|------|--------|
+| **Mumuni** | CT114 (.123) | ✅ Updated to stable aliases |
+| **Tanko** | CT112 (.122) | ✅ Updated to stable aliases |
+| **Koby** | CT111 (.129) | ❌ SSH unreachable — needs Zulip DM |
+| **Koonimo** | CT113 | ❌ SSH unreachable — needs Zulip DM |
+| **Kagenz0** | CT105 | ❌ SSH unreachable — needs Zulip DM |
+
+All Hermes clients MUST set `max_tokens: 4096` — first line of defense before server-side `-n 8192` cap.

gpu-self-heal.prose.md

@@ -6,10 +6,15 @@ description: >
   benchmarks, and predicts failures before they happen. Extends gpu-monitor
   (v2.1.0) with active remediation rules, Prometheus metrics consumption,
   VRAM trend analysis, and predictive alerting.
+  UPDATED 2026-07-18: Model assignments synced to 2026-07-17 swaps.
+  Router (port 9000) references replaced with direct GPU routing.
+  Benchmark baselines refreshed to live values.
+  Prometheus exporters removed — not deployed; fall back to direct sidecar probes.
+  Stable role-based aliases (strix-moe, gpu-dense, gpu-light) from gpu-fleet.
 agent: abiba
 depends_on:
   - gpu-monitor.prose.md (live data source on .24:9100)
-  - gpu-fleet.prose.md (source of truth for topology)
+  - gpu-fleet.prose.md (source of truth for topology, aliases, model assignments)
 ---
 
 ## Maintains
@@ -22,8 +27,8 @@ depends_on:
 
 ## Requires
 
-- gpu-monitor:function — Live fleet data from .24:9100/gpu-data
-- Prometheus exporters on all 3 GPUs (:9400/metrics)
+- gpu-monitor:function — Live fleet data from localhost:9100/gpu-data
+- Direct sidecar probe access to all GPU hosts (:8080/health)
 - SSH access to GPU hosts for restart operations
 
 ## Continuity
@@ -35,21 +40,37 @@ depends_on:
 
 ---
 
+## Current Fleet Baseline (2026-07-18)
+
+| Alias | GPU | Host | Model | VRAM | Ctx | tok/s | Role |
+|-------|-----|------|-------|------|-----|-------|------|
+| `gpu-dense` | RTX 3090 24GB | ct8 (.8:8080) | ThinkingCap Qwen3.6-27B Q4_K_M + MTP + vision | 21.6/24.6GB (88%) | 128K | 74.9 | Heavy reasoning, code gen |
+| `gpu-light` | RTX 5070 12GB | ct110 (.110:8080) | HauhauCS Gemma4-12B QAT Q4_K_M + MTP draft | 10.1/12.2GB (83%) | 128K | 169.6 | Vision, web extract, light tasks |
+| `strix-moe` | Strix Halo 64GB | ct15 (.15:8080) | Genesis Hermes V3 APEX (LuffyTheFox, 24GB) | ~10/64GB (16%) | 128K | 62.9 | Compression, summarization, long docs |
+
+Key notes:
+- All models use direct GPU routing via LiteLLM (`api_key: not-needed`). Router (port 9000) is deprecated and NOT in the inference path.
+- Stable aliases (gpu-dense, gpu-light, strix-moe) from gpu-fleet are the canonical names for agent configs. Model-specific names still work but are deprecated.
+- RTX 5070 tok/s is 2.3x faster than RTX 3090 for its model — gpu-light is the fastest endpoint. Route vision/web/light work there first.
+- Strix Halo is 62.9 tok/s (89% of 70.5 baseline) — below optimal but stable. Check for competing workloads.
+- RTX 3090 VRAM at 88% — within role-appropriate range (role = heavy reasoning, needs the headroom).
+- RTX 5070 VRAM at 83% — role-appropriate for vision/web (smaller batch sizes).
+
 ## Remediation Rules
 
 ### Rule 1: GPU Temperature Critical (>85°C for >2 min)
 - **Detect**: Any GPU temp >85°C sustained for 2+ consecutive polls
 - **Fix**: 
   1. Reduce inference concurrency on that GPU (load-side cooling only — NO fan control)
-  2. Redirect new requests to cooler GPUs via LiteLLM fallback chains
+  2. Redirect new requests to cooler GPUs via LiteLLM fallback chains (gemma → qwen, qwen → gemma)
   3. If all GPUs hot, alert about cooling infrastructure
 - **Verify**: Temp drops below 80°C within 5 minutes
 - **Escalate after**: 3 verification failures → Zulip alert
 
 ### Rule 2: VRAM Leak Detection (tiered by GPU capacity)
 - **Detect**: VRAM growing at sustained rate over 6+ hour window
-  - RTX 3090 (24GB): ≥100MB/hour
-  - RTX 5070 (12GB): ≥50MB/hour
+  - RTX 3090 (24GB): ≥300MB/hour
+  - RTX 5070 (12GB): ≥300MB/hour
   - Strix Halo (64GB UMA): ≥200MB/hour
 - **Fix**: 
   1. Log VRAM snapshot with process list (nvidia-smi/rocm-smi + ps aux)
@@ -69,6 +90,9 @@ depends_on:
 
 ### Rule 4: Benchmark Regression (>20% drop)
 - **Detect**: gen_tok_per_sec drops >20% below baseline over 3+ benchmarks
+  - RTX 3090 baseline: 74.8 tok/s → alert at <59.8 tok/s
+  - RTX 5070 baseline: 165.2 tok/s → alert at <132.2 tok/s
+  - Strix Halo baseline: 70.5 tok/s → alert at <56.4 tok/s
 - **Fix**:
   1. Check GPU utilization — if >90%, other process is competing
   2. Check power limit — if throttled, restore to max
@@ -78,32 +102,31 @@ depends_on:
 
 ### Rule 5: Circuit Breaker Stuck Open
 - **Detect**: Circuit breaker open >10 minutes with GPU reporting healthy
+- **Note**: Router (port 9000) is deprecated. If circuit breakers are reported by gpu-monitor, they come from LiteLLM's internal tracking, not the old router.
 - **Fix**: 
-  1. Verify GPU /health returns 200
-  2. If GPU healthy, send 1 test inference
-  3. If test succeeds → reset circuit breaker via router API
-  4. 60s cooldown — if CB re-opens immediately, it was legitimate, do NOT re-reset
-  5. Max 1 auto-reset per GPU per hour
-- **Verify**: CB closes, inference succeeds, CB stays closed for 60s+
-- **Escalate after**: CB won't close after reset → router issue
+  1. Verify GPU /health returns 200 on direct port (:8080)
+  2. If GPU healthy, alert but do NOT reset via router API (deprecated)
+  3. Check LiteLLM health directly: http://192.168.68.116/litellm/health/liveliness
+  4. Restart LiteLLM container on CT 116 if circuit breakers are stuck
+- **Verify**: LiteLLM returns healthy, circuit breaker clears within 60s
+- **Escalate after**: LiteLLM restart doesn't clear → human investigation
 
 ### Rule 6: Strix Halo Unreachable
 - **Detect**: Strix not responding — probe .15:8080 directly (firewall opened .24→.15)
 - **Fix**: 
   1. SSH to .15 → check llama-server process
   2. Restart llama-server if not running
-  3. Verify through both direct probe AND router
-- **Verify**: Direct health probe returns 200, router reports Strix healthy
+  3. Verify through both direct probe AND LiteLLM health
+- **Verify**: Direct health probe returns 200, LiteLLM reports model healthy
 - **Escalate**: If host .15 itself is unreachable → infrastructure alert
 
-### Rule 7: Prometheus Exporter Down
-- **Detect**: Any GPU :9400/metrics unreachable for >2 polls
+### Rule 7: GPU Data Source Unreachable (replaces old Prometheus rule)
+- **Detect**: gpu-monitor endpoint (localhost:9100/gpu-data) or sidecar port (:8080) on any GPU unreachable for >2 polls
 - **Fix**:
-  1. SSH to GPU host → check prometheus-exporter process
-  2. Restart exporter if dead
-  3. While exporter is down, fall back to nvidia-smi/rocm-smi direct probes
-  4. If exporter is running but unreachable → check firewall/host networking
-- **Verify**: :9400/metrics returns 200
+  1. If gpu-monitor is down: restart systemd service `gpu-monitor.service` on this host
+  2. If sidecar is down: SSH to GPU host → check llama-server process → restart systemd service
+  3. Fall back to direct nvidia-smi/rocm-smi probe via SSH if all API paths fail
+- **Verify**: gpu-monitor returns healthy + all sidecars reachable
 - **Escalate after**: 3 failed restarts → networking issue
 
 ### Rule 8: Predictive Thermal Warning (two-tier)
@@ -117,29 +140,31 @@ depends_on:
 - **Escalate**: If Tier 2 triggers and temp still rising after 5 min → possible hardware failure
 
 ### Rule 9: Context Window Optimization
-- **Detect**: Benchmark tok/s vs baseline for each GPU at current context
-  - RTX 3090 (256K ctx, qwen3.6-27B-code): target 75+ tok/s — currently at baseline
-  - RTX 5070 (131K ctx, gemma-4-12b): target 76+ tok/s — optimal for vision/web role
-  - Strix Halo (256K ctx, ornith-1.0-35b): target 70+ tok/s — currently above baseline
+- **Detect**: Benchmark tok/s vs baseline for each GPU at current context (all 128K)
+  - RTX 3090 (128K ctx, ThinkingCap): baseline 74.8 tok/s — currently at 74.9 (100%)
+  - RTX 5070 (128K ctx, HauhauCS QAT): baseline 165.2 tok/s — currently at 169.6 (103%)
+  - Strix Halo (128K ctx, Genesis Hermes V3): baseline 70.5 tok/s — currently at 62.9 (89%)
 - **Fix**:
   - If tok/s > baseline → context has headroom, consider increasing
   - If tok/s < 90% baseline → reduce context by 25% and retest
   - If tok/s within 10% of baseline → optimal, no change
+  - Strix Halo at 89% of baseline → MONITOR but do not reduce yet (recent model swap may still be settling)
 - **Verify**: Re-benchmark after context change, confirm within 10% of target
 - **Escalate**: If context can't be adjusted without significant perf loss
 
-### Rule 10: Workload Distribution Optimization
+### Rule 10: Workload Distribution Optimization (updated 2026-07-18)
 - **Detect**: GPU roles misaligned with hardware capabilities
 - **Target distribution**:
-  - RTX 3090 (24GB, 256K, 75 tok/s) → Heavy reasoning, code gen, long conversations
-  - RTX 5070 (12GB, 131K, 76 tok/s) → Vision/image, web search, quick lightweight tasks
-  - Strix Halo (64GB, 256K, 72 tok/s) → Context compression, summarization, long docs
+  - RTX 3090 (gpu-dense, 24GB, 74.9 tok/s) → Heavy reasoning, code gen, long conversations (slowest per-token but largest context capacity). Weight: 0.55 (LiteLLM).
+  - RTX 5070 (gpu-light, 12GB, 169.6 tok/s) → Vision/image, web search, lightweight tasks (2.3x faster than 3090 per token). Weight: 0.15 (LiteLLM).
+  - Strix Halo (strix-moe, 64GB, 62.9 tok/s) → Context compression, summarization, long docs (MoE model). Weight: 0.30 (LiteLLM).
+- **Note**: RTX 5070 is the fastest endpoint per token. Route high-volume, low-complexity work there first.
 - **Fix**:
   - Alert if any GPU is handling workload outside its designated role
-  - Recommend Hermes agent profile updates to match workload to GPU
+  - Recommend agent alias updates to match workload to GPU role (use stable aliases: gpu-dense, gpu-light, strix-moe)
   - Track per-GPU request distribution via LiteLLM spend logs
 - **Verify**: Each GPU's request pattern matches its designated role within 24h
-- **Escalate**: If role mismatch persists >48h → agent profile audit needed
+- **Escalate**: If role mismatch persists >48h → agent alias audit needed
 
 ---
 
@@ -148,7 +173,7 @@ depends_on:
 ```prose
 -- Phase 1: Fetch live GPU data
 let fleet = call gpu-monitor
-  endpoint: "http://192.168.68.24:9100/gpu-data"
+  endpoint: "http://localhost:9100/gpu-data"
 
 -- Phase 2: Evaluate each GPU against remediation rules
 let actions = []
@@ -164,27 +189,25 @@ for gpu in fleet.gpus:
   
   -- Rule 4: Benchmark regression
   let bench = fleet.benchmarks[gpu.hostname]
-  if bench.current_tok_sec < bench.baseline_tok_sec * 0.8:
+  if bench.current_tok_s < bench.baseline_tok_s * 0.8:
     push actions apply-benchmark-fix(gpu, bench)
 
 -- Rule 3: Model stuck
-for model in fleet.router.available_models:
+for model in fleet.summary.available_models:
   if model.consecutive_timeouts >= 3:
     push actions apply-model-restart(model)
 
--- Rule 5: Circuit breaker
-for cb in fleet.router.circuit_breaker:
-  if cb.open and cb.open_duration > 600 and gpu_is_healthy(cb.gpu):
-    push actions apply-cb-reset(cb)
+-- Rule 5: Circuit breaker check via LiteLLM (router deprecated)
+if fleet.summary.circuit_breakers_open > 0:
+  push actions check-litellm-circuit-breakers()
 
 -- Rule 6: Strix Halo
 if not fleet.strix.running and pingable("192.168.68.15"):
   push actions apply-strix-restart()
 
--- Rule 7: Prometheus exporters
-for gpu in fleet.gpus:
-  if not prometheus_reachable(gpu.hostname, 9400):
-    push actions apply-exporter-restart(gpu)
+-- Rule 7: GPU data source
+if not fleet.gpus or len(fleet.gpus) < 2:
+  push actions check-gpu-monitor-service()
 
 -- Rule 8: Predictive thermal
 for gpu in fleet.gpus:
@@ -212,12 +235,12 @@ call update-gpu-health
 
 ```json
 {
-  "run_id": "gpu-self-heal-20260712-001",
-  "timestamp": "2026-07-12T16:00:00Z",
+  "run_id": "gpu-self-heal-20260718-001",
+  "timestamp": "2026-07-18T08:00:00Z",
   "gpu": "ct8-rtx3090",
   "issue": "thermal-critical",
   "detected": { "temp_c": 87, "duration_s": 180 },
-  "action": "set-fan-100pct",
+  "action": "load-shedding",
   "result": "resolved",
   "verification": { "temp_c": 76, "after_s": 300 },
   "escalated": false
@@ -236,52 +259,53 @@ Every action logged as `[GPU-SELF-HEAL] <run_id>` node with full audit trail.
 - `issues_escalated > 0` → "⚠ GPU Self-Heal — <gpu> needs attention"
 - Every 100th clean cycle → "✅ GPU Fleet: All Clear"
 
-### 3. Prometheus/Grafana Integration
-- GPU self-heal actions exposed as Prometheus counter metrics
-- Dashboard panel: "GPU Interventions (24h)" showing count/type/result
-
-### 4. Weekly Benchmark Report
+### 3. Weekly Benchmark Report
 - Per-GPU tok/s trend over 7 days
 - Regression alerts if any GPU degrades >10% week-over-week
 
 ---
 
-## Design Decisions (Grilled & Confirmed — 2026-07-12)
+## Design Decisions (Verified 2026-07-12, Reaffirmed 2026-07-18)
 
 1. **Fan control**: ❌ NO auto fan control. Load-side cooling only (reduce concurrency, redirect).
 2. **Model restart**: ✅ Only if >50% failure rate over 60s + 30s grace period. Not on single stuck request.
 3. **Strix direct access**: ✅ Open firewall .15:8080 → .24 for direct health probe + restart.
-4. **VRAM thresholds**: Tiered — 100MB/h (RTX 3090), 50MB/h (RTX 5070), 200MB/h (Strix).
-5. **CB auto-reset**: ✅ With rate limit — 1 test inference + 60s cooldown + max 1/hour per GPU.
-6. **Benchmark baseline**: Rolling 30-day average, recalculated weekly. Original baseline kept in Grafana.
+4. **VRAM thresholds**: Tiered — **300MB/h** (RTX 3090), **300MB/h** (RTX 5070), 200MB/h (Strix). Previous values (100/50) were too sensitive; raised 2026-07-18 based on operational data.
+5. **CB auto-reset**: ✅ Router deprecated — circuit breakers go through LiteLLM health check + container restart if needed. No per-GPU auto-reset.
+6. **Benchmark baseline**: Rolling 30-day average, recalculated weekly. Current baselines live in gpu-monitor.
 7. **Predictive alerts**: Two-tier — warn at >70°C+rising (>2°C/min), critical at >80°C+rising.
-8. **Prometheus**: Primary source. Fall back to nvidia-smi/rocm-smi direct probes if exporter down.
+8. **Prometheus**: ❌ Not deployed. Use direct sidecar probes (:8080/health) and gpu-monitor API. Prometheus integration deferred until exporters are running on GPU hosts.
 
-## Lessons Learned (2026-07-12)
+## Lessons Learned (2026-07-12, Updated 2026-07-18)
 
 ### L1: API Key Standardization Is Critical
 - All GPU llama-servers MUST use the same api-key as the LiteLLM config.
 - RTX 5070 had `--api-key sk-loc...5678` while LiteLLM sent `not-needed`.
-  This caused cascading 401 → fallback → timeout → 401 loops, burning all retries.
-- **Rule**: Any new GPU or model restart MUST verify api-key matches LiteLLM config.
+  This caused cascading 401 → fallback → timeout → 401 loops.
+- **Rule**: Any new GPU or model restart MUST verify api-key matches LiteLLM config (`not-needed` for direct routing).
 
 ### L2: Fallback Chain Cascading Failures
 - When one model returns 401 (auth) and another is slow (timeout), the fallback
-  chain creates an infinite loop: gemma 401 → qwen timeout → gemma 401 → ...
+  chain creates an infinite loop.
 - **Rule**: If a model returns 401 (auth error), do NOT fall back to it again.
   Mark it as permanently failed for this request.
 
 ### L3: Verify Running State, Not Docs
-- RTX 3090 was documented at 128K context. Actually running at 256K.
-- Parallel count wrong (docs said 2, actual is 1 on RTX 3090).
+- RTX 3090 was documented at 128K context. Running at 128K (verified 2026-07-18).
+- Parallel count: 1 on both RTX 3090 and RTX 5070 (matches docs for current models).
 - **Rule**: Before making decisions, check `/proc/PID/cmdline` on GPU hosts.
 
 ### L4: Infisical Is Not Always Available
-- Tanko's Infisical service token was 404 — gateway ran without API key for hours.
-- **Rule**: Always keep a local `.env` fallback for `LITELLM_API_KEY`.
-- Contract hermes-config-template Rule 3 updated.
+- Keep a local `.env` fallback for `LITELLM_API_KEY`.
+- **Rule**: Always verify credential source is reachable before relying on it.
 
-### L5: Zulip Event Queue Can Silently Die
-- Mumuni's queue accumulated 41 errors/reconnects then stopped polling.
-  Gateway was running but ignoring all messages.
-- **Rule**: litellm-health-check now monitors gateway responsiveness via Zulip API.
+### L5: GPU Monitor Response Size Can Cause Self-Heal Crash
+- gpu-self-heal crashed with KeyboardInterrupt during json.loads() of 20MB response.
+- Root cause: router poll returns accumulated data → cache balloons.
+- **Rule**: Self-heal must enforce a read timeout AND max response size on every poll.
+  If monitor response > 1MB, log a warning and skip the cycle rather than crashing.
+
+### L6: Stable Aliases Replace Model Names
+- gpu-fleet introduced stable aliases (strix-moe, gpu-dense, gpu-light) on 2026-07-15.
+- Self-heal must use aliases for reporting and alerting, not model-specific names.
+- **Rule**: All alert messages and KG nodes use the stable alias as the GPU identifier.

hermes-agent-baseline.prose.md

@@ -5,7 +5,7 @@ version: 1.0.0
 description: >
   Canonical known-good baseline for all Syslog Hermes agents. Captures the exact
   configuration state, keys, workarounds, and audit procedure. When an agent's
-  configuration goes sideways, restore from this baseline. Last verified 2026-07-08. GPU context reduced to 128K on .8/.110, parallel 2 fleet-wide.
+  configuration goes sideways, restore from this baseline. Last verified 2026-07-16. All GPUs 256K context (RTX 3090 .8, RTX 5070 .110, Strix Halo .15). Parallel 1 fleet-wide (Strix Halo handles compression solo).
 author: Abiba (pi agent)
 ---
 
@@ -26,11 +26,11 @@ done
 |-------|-----|------|-----|---------------|------------|----------|
 | Tanko | 112 | amdpve | .122 | `tanko` | Infisical vault | Hermes |
 | Mumuni | 114 | minipve | .123 | `mumuni` | Infisical vault | Hermes |
-| Koby | 111 | amdpve | srv1079750 | `koby` | Infisical vault | **Hermes** |
-| Koonimo | 113 | amdpve | ? | `koonimo` | Infisical vault | Hermes |
-| Shumba | — | 192.168.68.119 | N/A | N/A (DeepSeek) | Hermes |
+| Koby | 129 | amdpve | srv1079750 | `koby` | Infisical vault | **Hermes** |
+| Koonimo | 114 | amdpve | ? | `koonimo` | Infisical vault | Hermes |
+| Shumba | — | 192.168.68.119 | N/A | N/A (DeepSeek) | Hermes (RETIRED — CT119 now Infisical vault) |
 
-> **Note**: CT hostnames (tdunna→CT111, baggy→CT113) differ from agent identities (koby, koonimo).
+> **Note**: CT hostnames (tdunna→CT129, baggy→CT114) differ from agent identities (koby, koonimo).
 
 Access: `pct-run <CT_ID> <command>` — no IPs needed. GPU hosts (.8, .110, .15) use SSH.
 Keys are stored in Infisical vault (project=agents, env=production) and injected at
@@ -169,9 +169,9 @@ pct-run <CT> grep -A8 "vision:" /root/.hermes/config.yaml | grep api_key
 # Must show both api_key: sk-... and api_key_env: LITELLM_API_KEY
 ```
 
-### For Koby (CT 111 / tdunna)
+### For Koby (CT 129 / tdunna)
 
-Koby runs Hermes on CT 111 (tdunna). Config files at `/root/.hermes/config.yaml`.
+Koby runs Hermes on CT 129 (tdunna). Config files at `/root/.hermes/config.yaml`.
 Same Hermes pattern as Tanko/Mumuni/Koonimo — see config sections above.
 
 **LiteLLM key**: alias `koby` in LiteLLM DB, injected via `infisical run --` wrapper.
@@ -192,7 +192,9 @@ Key is injected via `infisical run --` wrapper at PM2 startup:
       "apiKey": "${LITELLM_API_KEY}",
       "models": [
         { "id": "syslog-auto" },
-        { "id": "ornith-1.0-35b" },
+        { "id": "strix-moe" },
+        { "id": "gpu-dense" },
+        { "id": "gpu-light" },
         { "id": "qwen3.6-27B-code" },
         { "id": "gemma-4-12b" }
       ]

hermes-config-template.prose.md

@@ -5,10 +5,14 @@ description: >
   Standard Hermes configuration template for Syslog Solution LLC agents.
   Enforces shared infrastructure setup (Firecrawl, SearXNG, local models,
   RA-H OS MCP) while keeping agent-specific API keys and model choices.
-  UPDATED 2026-07-12: GPU workload redistributed. Compression → Strix Halo (ornith-1.0-35b).
-  RTX 3090 context verified at 256K (was incorrectly documented as 128K).
-  RTX 5070 stays at 131K for vision/web. Infisical .env fallback required (Rule 3).
-  Parallel counts corrected (RTX 3090=1, RTX 5070=2, Strix=2).
+  UPDATED 2026-07-18: Compression model switched to `syslog-auto` (was `strix-moe`)
+  to relieve Strix Halo pressure. syslog-auto distributes compression across the
+  weighted pool (55% RTX 3090, 30% Strix Halo, 15% RTX 5070).
+  UPDATED 2026-07-16: Compression model was the stable alias `strix-moe` (NOT `ornith-1.0-35b`,
+  which LiteLLM does not serve). All 3 GPUs verified at 128K (reduced from 256K 2026-07-17 for stability).
+  Added Rule 12 (Context-Issue Diagnostic) + Rule 13 (.env fallback enforcement) from the
+  2026-07-16 Mumuni root-cause investigation (WAL #1300).
+  UPDATED 2026-07-12: GPU workload redistributed. Compression → Strix Halo (later switched to syslog-auto 2026-07-18). RTX 3090 context verified at 128K. Infisical .env fallback required (Rule 3/13).
 ---
 
 ## Maintains
@@ -31,10 +35,10 @@ Sub-agent profiles inherit auth from the main config — no separate keys needed
 | Agent | Key Alias | Host | SSH | Sub-Agents |
 |-------|-----------|------|-----|-----------|
 | Tanko | `tanko-*` | 192.168.68.122 | jerome@.122 | — |
-| Mumuni | `mumuni-jul2026` | 192.168.68.123 | root@.123 | 6 profiles ✱ |
+| Mumuni | `mumuni` | 192.168.68.123 | root@.123 | 6 profiles ✱ |
 | Abiba | `abiba-pi` | 192.168.68.24 | local | — |
 | Koby | `koby` | CT 111 (tdunna) | Zulip | — |
-| Koonimo | `koonimo` | CT 113 (baggy) | Zulip | — |
+| Koonimo | `koonimo` | CT 114 (baggy) | SSH root | — |
 | Kagenz0 | `kagenz0-*` | ? | Zulip | — |
 
 > CT hostnames (tdunna, baggy) differ from agent identities (koby, koonimo).
@@ -94,13 +98,13 @@ work immediately after restart.
 ```yaml
 # ─── Model Selection ───
 model:
-  default: <agent_model>          # e.g., ornith-1.0-35b, qwen3.6-27B-code
+  default: <agent_model>          # e.g., strix-moe, qwen3.6-27B-code, syslog-auto
   provider: harness
   base_url: http://192.168.68.116/v1
   api_key_env: LITELLM_API_KEY    # Injected via infisical run -- wrapper
   max_tokens: 4096                # ⚠️ CRITICAL: Prevents unbounded generation
-  context_length: 262144          # For syslog-auto (all GPUs support 256K).
-                                  # Set 131072 if using gemma-4-12b directly (12GB VRAM constraint).
+  context_length: 131072          # For syslog-auto (all GPUs at 128K for stability).
+                                  # Set 65536 if using gemma-4-12b directly (tight VRAM).
 
 fallback_providers:
   provider: deepseek
@@ -129,10 +133,11 @@ mcp_servers:
 # ─── Compression ───
 compression:
   enabled: true
-  model: ornith-1.0-35b           # ⚠️ Must match auxiliary.compression.model
+  model: syslog-auto              # ⚠️ Switched from strix-moe 2026-07-18 to relieve Strix Halo.
+                                  # syslog-auto distributes across weighted pool (55% RTX 3090,
+                                  # 30% Strix Halo, 15% RTX 5070). All GPUs at 128K.
   provider: harness
-  max_context_window: 262144      # For Strix Halo compression (256K ctx).
-                                  # Set 131072 if using gemma directly.
+  max_context_window: 131072      # MUST match actual GPU capacity. All 3 GPUs are 128K (Jul 17).
   threshold: 0.65                 # Fires at ~170K for 262K window, ~85K for 128K
   target_ratio: 0.30
   protect_last_n: 40
@@ -142,37 +147,49 @@ compression:
 
 # ─── Auxiliary Tasks (CONSISTENCY RULE) ───
 # All auxiliary services MUST use identical model, base_url, and api_key_env:
-#   model: gemma-4-12b
+#   model: gpu-light                 # stable alias (NOT raw "gemma-4-12b")
 #   base_url: http://192.168.68.116/v1
 #   api_key_env: LITELLM_API_KEY
-# Do NOT use syslog-auto for auxiliary tasks — it routes to the primary GPU.
-# gemma-4-12b is a lightweight 12B model on the RTX 5070, freeing the Strix Halo
-# for agent reasoning.
+# Compression uses syslog-auto (switched from strix-moe 2026-07-18) to distribute
+# load across the weighted pool and relieve Strix Halo pressure.
+# Vision and web_extract use gpu-light = RTX 5070 (12B).
+# Heavy aux (delegation, x_search) use gpu-dense (RTX 3090) instead.
+# NEVER use raw model names (gemma-4-12b, qwen3.6-27B-code, qwen3.6-35B-udq4)
+# in agent configs — use the stable aliases so model swaps don't break agents.
 auxiliary:
   vision:
     provider: harness
-    model: gemma-4-12b
+    model: gpu-light            # stable alias for RTX 5070 (was raw gemma-4-12b)
     base_url: http://192.168.68.116/v1
     api_key_env: LITELLM_API_KEY
     timeout: 60
     download_timeout: 30
   web_extract:
     provider: harness
-    model: gemma-4-12b
+    model: gpu-light            # stable alias for RTX 5070
     base_url: http://192.168.68.116/v1
     api_key_env: LITELLM_API_KEY
     timeout: 30
   compression:
     provider: harness
-    model: ornith-1.0-35b
-    base_url: http://192.168.68.116/v1
+    model: syslog-auto             # Switched from strix-moe 2026-07-18. Relieves Strix Halo pressure.
+    base_url: http://192.168.68.116/v1   # Rule 5: /v1 NOT /litellm/v1
     api_key_env: LITELLM_API_KEY
-    timeout: 60
+    timeout: 300                 # gpu-fleet: 300s for large-history summarization (was 60)
+
+# ─── Delegation / Heavy Aux (use gpu-dense = RTX 3090) ───
+# delegation.model and x_search.model use gpu-dense (NOT raw qwen3.6-27B-code).
+
+delegation:
+  model: gpu-dense              # stable alias for RTX 3090 (was raw qwen3.6-27B-code)
+  provider: harness
+  base_url: http://192.168.68.116/v1
+  api_key_env: LITELLM_API_KEY
 
 # ─── Custom Provider ───
 custom_providers:
   - name: harness
-    model: <agent_model>
+    model: syslog-auto            # weighted pool (default)
     base_url: http://192.168.68.116/v1
     api_key_env: LITELLM_API_KEY
     api_mode: chat_completions
@@ -236,45 +253,48 @@ The following MUST be identical across ALL profiles:
 - Apply to BOTH main config AND all sub-agent profiles
 - For agents needing longer outputs: raise to 8192, but never omit
 
-### Rule 7: Auxiliary Model Consistency (UPDATED July 2026)
-- Vision and web_extract use `gemma-4-12b` (RTX 5070 — 12GB, vision-optimized)
-- Compression uses `ornith-1.0-35b` (Strix Halo — 64GB, 256K ctx, compression-optimized)
+### Rule 7: Auxiliary Model Consistency (UPDATED 2026-07-18)
+- Vision and web_extract use `gpu-light` (stable alias, RTX 5070 — 12GB, vision-optimized)
+- Compression now uses `syslog-auto` (switched from `strix-moe` 2026-07-18) to distribute
+  compression load across the weighted pool (55% RTX 3090, 30% Strix Halo, 15% RTX 5070).
+  This relieves Strix Halo pressure while keeping compression functional on all GPUs.
+- **`syslog-auto` is the valid compression model** — LiteLLM serves it as the weighted pool.
+  Old configs with `strix-moe` for compression should be updated to `syslog-auto`.
 - All auxiliary services MUST use identical routing:
-  - `base_url: http://192.168.68.116/v1`
+  - `base_url: http://192.168.68.116/v1`  (Rule 5: `/v1`, NOT `/litellm/v1`)
   - `api_key_env: LITELLM_API_KEY`
-- **Do NOT use `syslog-auto`** for auxiliary tasks — it routes unpredictably
-- **Compression moved to Strix Halo (July 2026)**: The ornith-1.0-35b model on Strix Halo
-  (64GB UMA, 256K context, 72.4 tok/s) is the designated compression GPU. This frees the
-  RTX 5070 for vision and web search, and the RTX 3090 for heavy reasoning.
+- **Compression via syslog-auto**: Routes through the weighted pool. Strix Halo still handles
+  ~30% of compression calls (at 60 RPM via pool vs 40 RPM direct), but the bulk (55%)
+  goes to RTX 3090 which has ample spare capacity.
 - The `compression:` block's `model` MUST match `auxiliary: compression: model`
-- The `compression: max_context_window: 262144` MUST match Strix Halo's actual capacity
+- The `compression: max_context_window: 131072` MUST match actual GPU capacity (128K)
 
-### Rule 8: GPU Workload Distribution (July 2026)
-- **RTX 3090 (24GB, 256K ctx, qwen3.6-27B-code)**: Heavy reasoning, code gen, long conversations
-- **RTX 5070 (12GB, 131K ctx, gemma-4-12b)**: Vision, web search, quick tasks, web_extract
-- **Strix Halo (64GB, 256K ctx, ornith-1.0-35b)**: Context compression, summarization, long docs
+### Rule 8: GPU Workload Distribution (UPDATED 2026-07-18)
+- **RTX 3090 (24GB, 128K ctx, qwen3.6-27B-code)**: Heavy reasoning, code gen, long conversations — also handles ~55% of compression via syslog-auto pool
+- **RTX 5070 (12GB, 128K ctx, gemma-4-12b)**: Vision, web search, quick tasks, web_extract — handles ~15% of compression via syslog-auto pool
+- **Strix Halo (64GB, 128K ctx, Geneis Hermes V3 APEX)**: Agent reasoning, compression (~30% via syslog-auto pool), fallback for other GPUs
 - Agent profiles MUST route auxiliary tasks to the correct GPU:
-  - `auxiliary.vision.model: gemma-4-12b` (RTX 5070)
-  - `auxiliary.web_extract.model: gemma-4-12b` (RTX 5070)
-  - `auxiliary.compression.model: ornith-1.0-35b` (Strix Halo)
+  - `auxiliary.vision.model: gpu-light` (RTX 5070)
+  - `auxiliary.web_extract.model: gpu-light` (RTX 5070)
+  - `auxiliary.compression.model: syslog-auto` (distributed pool, switched from strix-moe 2026-07-18)
 - Default model (`model.default`) and custom_provider remain `syslog-auto` for auto-routing
-- For 262K context window: `threshold: 0.65` (fires at ~170K tokens)
+- For 128K context window: `threshold: 0.65` (fires at ~85K tokens)
 - Do NOT use `threshold: 0.25` — this fires at 65K, causing premature context loss
-- Do NOT use `threshold: 0.80` — this delays until 209K, risking the gateway hygiene layer
-- `max_context_window: 262144` MUST match the model's actual capacity
+- Do NOT use `threshold: 0.80` — this delays until ~105K, leaving only 23K margin
+- `max_context_window: 131072` MUST match the model's actual capacity (128K)
 - See `devops-hermes-compression` skill for full reference
 
-### Rule 9: Compression Threshold for 256K Models
-- For 262K context window: `threshold: 0.65` (fires at ~170K tokens)
+### Rule 9: Compression Threshold for 128K Models
+- For 128K context window: `threshold: 0.65` (fires at ~85K tokens)
 - Do NOT use `threshold: 0.25` — this fires at 65K, causing premature context loss
-- Do NOT use `threshold: 0.80` — this delays until 209K, risking the gateway hygiene layer
-- `max_context_window: 262144` MUST match the model's actual capacity (Strix Halo = 256K)
+- Do NOT use `threshold: 0.80` — this delays until ~105K, leaving only 23K margin
+- `max_context_window: 131072` MUST match the model's actual capacity (all GPUs = 128K)
 - See `devops-hermes-compression` skill for full reference
 
 ### Rule 10: Default Model Must Be `syslog-auto` (All Agents)
 - **Hermes agents**: `model.default: syslog-auto`, `custom_providers[0].model: syslog-auto`
 - **pi agents**: `defaultModel: syslog-auto` in `settings.json`, first model in `models.json`
-- `syslog-auto` is the LiteLLM routing model — it load-balances between ornith-1.0-35b
+- `syslog-auto` is the LiteLLM routing model — it load-balances between strix-moe
   and qwen3.6-27B-code, with gemma-4-12b as fallback. Using it protects against:
   - Model name typos that cause 403 errors and silent worker failures
   - Single GPU downtime (routing falls back automatically)
@@ -293,6 +313,71 @@ The following MUST be identical across ALL profiles:
 - A non-existent model ID causes 403 errors that silently break the pi RPC worker
   (no `agent_end` emitted, worker stays "busy", Zulip messages pile up unprocessed)
 
+### Rule 12: Context-Issue Diagnostic Checklist (ADDED 2026-07-16, WAL #1300)
+When an agent shows "context issues" (premature compression, 401s, 504s, DeepSeek fallback),
+verify ALL FOUR of these against the live config. They are the only root causes found in production:
+
+1. **max_context_window correct?** — BOTH `compression.max_context_window` AND `context.max_context_window`
+   MUST be `131072` (all GPUs are 128K). A value of `262144` causes instability near 100K and must NOT be used.
+   ~83K instead of ~170K. Check: `grep -n max_context_window ~/.hermes/config.yaml`
+2. **base_url uses /v1 NOT /litellm/v1?** — `custom_providers[0].base_url`, `delegation.base_url`,
+   and ALL `auxiliary.*.base_url` MUST be `http://192.168.68.116/v1` (Rule 5). nginx `/litellm/`
+   has a 60s default timeout → 504 on any inference >60s; `/v1/` has 600s.
+   Check: `grep -n 'litellm/v1' ~/.hermes/config.yaml` (must return NOTHING)
+3. **LITELLM_API_KEY valid?** — The key must be a real LiteLLM key (`sk-` + 64 hex, 67 chars).
+   Malformed values (e.g. `sk-_SWAl_Vu_…`, 47 chars) return 401 → DeepSeek fallback.
+   Verify: `curl -s -o /dev/null -w '%{http_code}' -H "Authorization: Bearer $LITELLM_API_KEY" http://192.168.68.116/v1/models` (must be 200)
+4. **custom_providers aligned?** — `model: syslog-auto` (Rule 10), `api_mode: chat_completions`
+   (NOT `responses`). A wrong api_mode causes silent request failures.
+
+One-line agent health check (run on the agent host):
+```bash
+# Use grep -v infisical to avoid matching the bash wrapper that contains the same string
+PID=$(pgrep -f "python -m hermes_cli.main gateway run" | grep -v infisical | head -1)
+cat /proc/$PID/environ | tr '\0' '\n' | grep ^LITELLM_API_KEY= | sed 's/=.*/<set>/'
+curl -s -o /dev/null -w 'key_health: %{http_code}\n' -H "Authorization: Bearer $(cat /proc/$PID/environ | tr '\0' '\n' | grep ^LITELLM_API_KEY= | cut -d= -f2)" http://192.168.68.116/v1/models
+```
+
+### Rule 13: API Key Injection — Two Patterns (UPDATED 2026-07-16, WAL #1300)
+
+Agents inject `LITELLM_API_KEY` via ONE of two mechanisms. Both are valid; the contract
+requirement is that the key is a **valid LiteLLM virtual key** (HTTP 200 on /v1/models).
+
+**Pattern A — systemd drop-in (Koby, Koonimo, and any agent without infisical wrapper):**
+A systemd drop-in `/etc/systemd/system/hermes-gateway.service.d/litellm-key.conf` sets the key:
+```ini
+[Service]
+Environment="LITELLM_API_KEY=sk-<VALID_KEY>"
+```
+The service unit `hermes-gateway.service` runs `python -m hermes_cli.main gateway run --replace`
+directly (no infisical). Apply with `systemctl daemon-reload && systemctl restart hermes-gateway`.
+- Koonimo (CT113/.114): service = `hermes-gateway.service`, drop-in has the key.
+- Koby (CT111/.129): service = `hermes-gateway.service` (created 2026-07-16), ExecStart uses `--replace`
+  to win the lock against stray `hermes gateway restart` invocations. Key also in `/etc/environment`.
+
+**Pattern B — infisical-gateway.sh wrapper (Mumuni):**
+The wrapper sources `~/.hermes/.env` then exports `LITELLM_API_KEY="$<AGENT>_LITELLM_API_KEY"`.
+See litellm-api-keys.prose.md § Machine Identity for Vault Writes for vault sync.
+
+**⚠️ Vault empty-key guard:** If the vault stores the secret as an empty string,
+the wrapper will inject an empty key and the gateway will silently get 401 errors
+on all LiteLLM requests (triggering silent DeepSeek fallback). The `.env` fallback
+is present but the vault takes precedence when the secret key exists (even if empty).
+
+**Fix:** The wrapper MUST validate the key length after injection. If LITELLM_API_KEY
+is empty or shorter than 20 chars, log a warning and either fail with a clear error
+message or fall back to the `.env` value before starting the gateway.
+
+**Verification (all agents):**
+```bash
+# Use grep -v infisical to avoid matching the bash wrapper that contains the same string
+GP=$(pgrep -f "python -m hermes_cli.main gateway run" | grep -v infisical | head -1)
+K=$(cat /proc/$GP/environ | tr '\0' '\n' | grep '^LITELLM_API_KEY=' | cut -d= -f2)
+curl -s -o /dev/null -w '%{http_code}' -H "Authorization: Bearer $K" http://192.168.68.116/v1/models  # must be 200
+```
+- `/etc/environment` is NO LONGER the canonical key source (stale values there caused 401s).
+- Do NOT leave a hardcoded stale key in `/etc/environment` — it shadows the drop-in/wrapper.
+
 ## Execution
 
 1. **Check current config** — Read the target agent's config.yaml

hermes-key-enforcement.prose.md

@@ -72,6 +72,11 @@ External providers are **explicitly exempt** and may use hardcoded keys:
 
 ## Standard Pattern
 
+> **Canonical vault process (2026-07-16):** see `litellm-api-keys` § Production Vault Access Process.
+> All agents MUST use the `infisical-gateway.sh` wrapper (live vault injection). Hardcoded systemd
+> drop-ins / config.yaml keys are DEPRECATED — they rot on rotation (root cause of the 2026-07-16 401 storm).
+> 4/5 agents migrated; tanko (user jerome) pending.
+
 ```yaml
 # ✅ CORRECT — all harness/litellm providers (authenticated path, NO /responses suffix)
 model:

inference-optimization.prose.md

@@ -0,0 +1,104 @@
+---
+name: inference-optimization
+kind: responsibility
+description: >
+  Optimizes the full Syslog inference stack — LiteLLM routing weights, GPU model
+  assignments, agent context management, and prompt caching — to reduce response
+  times to sub-15s average. All GPUs now at 128K context (stable ceiling).
+id: 067NC6KP02RG60S50M40E30928
+---
+
+### Goal
+
+Syslog inference response times reduced to sub-15s average by optimizing the full
+stack: LiteLLM routing weights, GPU model assignments, Hermes agent context
+management, and prompt caching — without sacrificing agent capability.
+
+### Requires
+
+- `inference-metrics`: current SpendLogs from CT116 LiteLLM Postgres — avg
+  request_duration_ms, prompt_tokens, completion_tokens, model_group breakdown,
+  cache_hit rate over the last 3 hours
+- `agent-configs`: current config.yaml from each active Hermes agent (Mumuni
+  .123, any others on .129/.122) including compression, model, context_window,
+  prompt_caching, memory settings
+- `gpu-health`: health check response from all 3 GPU backends (ornith .15:8080,
+  qwen .8:8080, gemma .110:8080)
+
+### Maintains
+
+The optimized inference stack configuration — every change is applied and
+verified end-to-end. Postcondition: avg request_duration_ms ≤ 15000 for 90% of
+non-ornith traffic; ≤ 30000 for ornith-bound agentic calls.
+
+#### liteLLM-routing
+The syslog-auto routing weights, model-specific timeouts, RPM limits, and
+model_list entries on CT116 `/opt/inference-harness/litellm_config.yaml`.
+
+#### agent-compression
+Each Hermes agent's `~/.hermes/config.yaml` compression, context_window,
+prompt_caching, and model sections.
+
+#### prompt-caching
+LiteLLM cache configuration and llama.cpp `--cache-prompt` flag on GPU hosts.
+
+#### verification
+End-to-end latency measurements after changes applied — at least 3 test
+inference calls per model path measuring ttft (time-to-first-token) and total
+duration.
+
+### Continuity
+
+- input-driven
+
+### Strategies
+
+**Context is the root cause.** Every ~46K prompt token costs ~87s of ornith
+prefill time at 532 tok/s. Fix context first, routing second.
+
+- **Route by task**: ornith for multi-step reasoning only; qwen for code/standard
+  queries; gemma for compression/auxiliary. Never send simple completion to a
+  35B MoE.
+- **Compress aggressively**: threshold at 40% (not 65%) — a 256K window should
+  compact at 102K, not 166K. Target 15% tail (not 30%).
+- **Cache everything repeated**: system prompts, skill docs, AGENTS.md — these
+  never change between turns. Single-digit cache hit rate is unacceptable.
+- **Lower context ceiling**: 128K window is the stable ceiling for agent conversations.
+  GPUs reduced from 256K to 128K (2026-07-17). For larger contexts, route to external providers.
+
+### Shape
+
+- `self`: analyze metrics, compute optimal configs, apply changes, verify
+- `delegates`:
+  - `apply-liteLLM`: update litellm_config.yaml and reload
+  - `apply-agent-config`: update hermes config.yaml per agent
+  - `verify-latency`: run test inference calls and measure response
+
+### Execution
+
+```prose
+-- Phase 1: Analyze current state (already complete)
+-- Phase 2: Apply LiteLLM routing optimization
+
+call apply-liteLLM-routing
+  config_path: /opt/inference-harness/litellm_config.yaml
+  host: 192.168.68.116
+
+-- Phase 3: Apply agent context compression optimization  
+
+call apply-agent-compression
+  agent: mumuni
+  host: 192.168.68.123
+  config_path: /root/.hermes/config.yaml
+
+-- Phase 4: Enable llama.cpp prompt caching on GPU hosts
+
+call enable-prompt-caching
+  hosts: [192.168.68.15, 192.168.68.8, 192.168.68.110]
+
+-- Phase 5: Verify end-to-end latency
+
+call verify-latency
+  host: 192.168.68.116
+  models: [syslog-auto, qwen3.6-27B-code, gemma-4-12b, ornith-1.0-35b]
+```

infrastructure-maintenance.prose.md

@@ -0,0 +1,200 @@
+---
+kind: responsibility
+name: infrastructure-maintenance
+description: >
+  Weekly system-level maintenance for the Syslog inference fleet: OS package
+  updates on the primary host, Docker image pulls for LiteLLM/SearXNG and other
+  running containers, container restarts with health verification, post-update
+  verification of every critical service (LiteLLM proxy, SearXNG, Zulip, Gitea,
+  PM2 processes, Hermes gateways), and rollback on failure. Consolidates the
+  raw shell scripts that previously did this piecemeal. This contract owns the
+  HOST-LEVEL weekly maintenance loop on the primary host plus Docker image
+  pulls ONLY for .116 and .7, while infrastructure-update owns the FULL-FLEET
+  cluster-wide wave (apt across the full PVE cluster + CTs/VMs AND its Docker
+  image Wave 3 across all stacks). Runs Sunday 2am ET. Owner:
+  ops (firstmate secondmate). Blast radius: an unverified image pull can break
+  LiteLLM (all agents lose inference) or SearXNG (search-stack down); a bad apt
+  upgrade can leave the host in a half-upgraded state. Pre-update backup check
+  and rollback are mandatory for this reason.
+agent: ops
+triggers:
+  - weekly (Sunday 02:00 ET) via cron
+  - on demand when ops/abiba triggers "infra maintenance"
+version: 1.0.0
+---
+
+## Maintains
+
+- maintenance-status: { phase: idle|preflight|apt|images|restarts|verify|rollback|done|failed, host, step, result, timestamp }
+- image-baseline: { service, current_tag, pulled_tag, digest, updated_at } — last known-good image per container
+- apt-state: { upgradable_before, upgradable_after, held_broken, kernel_reboot_required }
+- health-baseline: snapshot of critical-service health captured pre-update (used for regression check post-update)
+- rollback-snapshot: { backup_path, configs, image_digests, timestamp } — restore point created in preflight
+- maintenance-history: array of past runs with phase results and any escalations
+
+## Scope
+
+Primary host is the maintenance host where apt updates apply. Docker image pulls
+span the two Docker ecosystems that run critical services. infrastructure-update
+runs the full-fleet cluster-wide wave (including its Wave 3 Docker pulls across
+all stacks/hosts); this contract runs a narrower host-level weekly pull limited
+to .116 and .7. Topology, CT IDs, and IPs are live-state fields — verify against
+`infrastructure-control.prose.md` (the source of truth) and the live system
+before mutating.
+
+| Host | IP | Role | Trust |
+|------|----|------|-------|
+| CT 116 (syslog-api) | 192.168.68.116 | LiteLLM proxy + Grafana + Prometheus (inference harness) | ⚠️ VERIFY-BEFORE-USE |
+| VM 109 (docker-vm) | 192.168.68.7 | SearXNG + Firecrawl + home stack (Docker host) | ⚠️ VERIFY-BEFORE-USE |
+| CT 117 (zulip) | 192.168.68.19 | Zulip (storepve bridge IP .19) | ⚠️ VERIFY-BEFORE-USE |
+| Gitea | https://git.sysloggh.net | Prose-contracts + agent configs source control | ⚠️ VERIFY-BEFORE-USE |
+| CT 100 (abiba/pi) | 192.168.68.24 | PM2 processes (pi agent harness) | ⚠️ VERIFY-BEFORE-USE |
+
+> "Primary host" for the apt phase is the host the ops agent runs maintenance
+> from. Confirm which host that is against infrastructure-control before
+> running; do not assume. If the ops agent is containerized/CT-based, apt runs
+> inside that CT.
+
+## Requires
+
+- SSH/exec access to CT 116 (.116) and VM 109 (.7) for Docker operations
+- `apt`, `docker`, `docker compose` available on target hosts
+- LiteLLM master key available (Infisical vault, `LITELLM_API_KEY`) for health verification
+- `infrastructure-monitoring` run completed within the last 30 minutes — provides the pre-update health baseline used by the regression check
+- Writable backup directory `/tmp/infra-maintenance-backup-<date>/` on each mutated host
+- Proxmox snapshot of the primary host available (or confirmed not required) before apt phase
+
+## Continuity
+
+- Self-driven: weekly cron `0 2 * * 0` (Sunday 02:00 ET)
+- Also wakes on: explicit "infra maintenance" trigger from ops/abiba
+- Depends on `infrastructure-monitoring` for the pre-update health baseline — do not run if the last monitoring run is stale (>30 min) or RED; abort and escalate instead
+
+## Execution
+
+### Phase 0 — Preflight (snapshot/backup check + health baseline)
+
+1. **Capture health baseline** — run the `infrastructure-monitoring` postcondition checks (LiteLLM, Zulip, Gitea, SearXNG, Proxmox API) and record results as `health-baseline`. If any critical service is already down, **abort**: maintenance must not run on a degraded fleet.
+2. **Backup check** — confirm a Proxmox snapshot of the primary host exists OR `/tmp/infra-maintenance-backup-<date>/` was created this run. Snapshot critical config files into the backup dir:
+   - `/opt/inference-harness/docker-compose.yml`, `/opt/inference-harness/litellm_config.yaml` (CT 116)
+   - `/opt/search-stack/searxng/docker-compose.yml`, `/opt/search-stack/firecrawl-source/docker-compose.yaml` (VM 109)
+3. **Record image baseline** — `docker inspect --format '{{.Image}} {{.Config.Image}}' <container>` for every running container on .116 and .7; store digests in `image-baseline` so rollback can restore them.
+4. **Disk check** — `df -h` on each mutated host; abort if free space <20% (apt upgrade + image pulls need headroom).
+
+### Phase 1 — OS package updates (primary host)
+
+```bash
+# On the primary host only (VERIFY host against infrastructure-control first)
+apt update
+apt upgrade -y
+```
+
+- Capture `apt list --upgradable` before and after → store in `apt-state`.
+- If apt reports held/broken packages (`apt-get -s upgrade | grep -i broken`, or non-zero exit), **stop** — do not force. Record `held_broken` and go to rollback/escalate.
+- If `/var/run/reboot-required` exists after upgrade, flag `kernel_reboot_required: true` in `apt-state` but **do not reboot automatically** — that's a separate coordinated action (see infra-update Wave 4). Note it in the report.
+
+### Phase 2 — Docker image pulls
+
+Pull latest stable tags for every running container. Do NOT pin to `:main`/`:nightly` — use stable tags where the compose file specifies them; otherwise `latest`.
+
+```bash
+# CT 116 (.116) — inference harness
+cd /opt/inference-harness && docker compose pull
+
+# VM 109 (.7) — search + home stacks
+cd /opt/search-stack/searxng && docker compose pull
+cd /opt/search-stack/firecrawl-source && docker compose pull
+# any other running stacks on .7 (home stack, audiobookshelf) — pull per their compose files
+```
+
+- LiteLLM and SearXNG are the two explicitly required pulls; "any other running containers" means every stack with a compose file on .116 and .7.
+- Record pulled tag + digest per service in `image-baseline`.
+
+### Phase 3 — Container restarts with health verification
+
+Restart one stack at a time, verify health before moving to the next. Do not restart everything at once — a failure mid-wave must leave the rest running.
+
+```bash
+# CT 116
+cd /opt/inference-harness && docker compose up -d
+# VM 109
+cd /opt/search-stack/searxng && docker compose up -d
+cd /opt/search-stack/firecrawl-source && docker compose up -d
+```
+
+After each stack comes up, wait for health (max 120s):
+- `docker ps` shows the container `Up` (and `healthy` if a healthcheck is defined)
+- Service-specific probe passes (see Phase 4 probes)
+
+If a stack fails to come up within 120s, **stop the wave** and go to rollback for that stack only; do not proceed to the next.
+
+### Phase 4 — Post-update service verification
+
+After ALL updates (apt + images + restarts), verify every critical service is back up and matches the pre-update baseline. This is the regression gate.
+
+| Service | Probe | Expect |
+|---------|-------|--------|
+| LiteLLM proxy | `curl -sf http://192.168.68.116/litellm/v1/models` | 200 OK, models returned |
+| LiteLLM MCP gateway | `curl -sf http://192.168.68.116:4000/mcp-rest/tools/list -H "Authorization: Bearer $MASTER_KEY"` | 90 tools (23 RA-H OS + 67 GitHub) |
+| SearXNG | `curl -sf http://192.168.68.7:8888` | 200 OK |
+| Zulip | `curl -sf https://chat.sysloggh.net/api/v1/server_settings` | 200 OK |
+| Gitea | `curl -sf https://git.sysloggh.net/api/v1/version` | 200 OK |
+| PM2 processes | `pm2 jlist` (CT 100) | all pi-agent processes `online` |
+| Hermes gateways | SSH to Mumuni CT 114, Tanko CT 112; `systemctl is-active hermes-gateway` | `active` for each |
+
+Regression check: every service that was GREEN in `health-baseline` must still be GREEN. A service that was already RED (and caused a preflight abort) is excluded — but Phase 0 should have aborted before we got here.
+
+## Rollback Protocol
+
+If ANY service in Phase 4 fails to come back up (or regresses vs baseline):
+
+1. **Image rollback** — for the failing stack, restore the previous image:
+   ```bash
+   # Restore from recorded image-baseline digest
+   docker compose down
+   # Pin the service image to the recorded digest in compose, then recreate
+   #   image: <name>@sha256:<previous_digest>
+   docker compose pull && docker compose up -d
+   ```
+2. **APT rollback** — restore the primary host from the Proxmox snapshot taken/confirmed in Phase 0. If no snapshot, `apt install <pkg>=<old_version>` per package using apt history (`/var/log/apt/history.log`).
+3. **Config rollback** — restore configs from `/tmp/infra-maintenance-backup-<date>/`.
+4. **Re-verify** — re-run the Phase 4 probes on the rolled-back service. If still failing, escalate (do not loop — circuit breaker below).
+5. **Escalate** — send a Zulip DM to abiba + mumuni with: failing service, phase, baseline vs current, rollback actions taken, backup path.
+
+## Circuit Breaker
+
+- `max_retries: 2` per failing phase — after 2 rollback attempts on the same service, stop and escalate.
+- `window: 7200` seconds — no more than 2 retries within a 2-hour window.
+- `trip_action: escalate_to_fatal` — when tripped, escalate to fatal (abiba + mumuni + kwame) and pause; a human must clear before the next scheduled run.
+
+## Report
+
+After completion (or on abort), emit a receipt (JSON) to `~/.hermes/runs/infrastructure-maintenance/` and send a Zulip DM summary:
+
+```
+🛠 Infrastructure Maintenance — YYYY-MM-DD
+
+Phase: apt | images | restarts | verify | rollback
+Primary host: <host>
+APT: <N> packages upgraded, <M> held/broken, kernel_reboot_required=<bool>
+Images pulled: LiteLLM <tag>, SearXNG <tag>, <others>
+Services: all GREEN | <service> FAILED (rolled back)
+Baseline regression: none | <details>
+Backup: /tmp/infra-maintenance-backup-YYYYMMDD/
+Escalation: none | warning | critical | fatal
+```
+
+## Verification Postconditions
+
+- All critical services running after update (Phase 4 all GREEN)
+- No regressions from pre-update health baseline (Phase 0 baseline)
+- Docker containers on latest stable tags (`image-baseline.pulled_tag` recorded)
+- APT packages up to date with no held broken packages (`apt-state.held_broken == 0`)
+
+## Related Contracts
+
+- `infrastructure-update.prose.md` — owns the full-fleet cluster-wide wave INCLUDING its Wave 3 Docker image updates across all stacks (SearXNG, Firecrawl, Inference Harness on .116, home stack, audiobookshelf); infrastructure-maintenance is a deliberately narrower host-level weekly pull scoped to .116 and .7.
+- `infrastructure-monitoring.prose.md` — provides the pre-update health baseline (depends_on).
+- `infrastructure-control.prose.md` — topology source of truth (CT IDs, IPs, hostnames).
+- `litellm-health.prose.md` — LiteLLM probe details.
+- `proxmox-monitor.prose.md` — Docker stats + monitoring stack health.

litellm-api-keys.prose.md

@@ -14,9 +14,26 @@ description: >
   expire/404. The .env fallback prevents agents from running without keys.
   Tanko incident: token 404 → gateway had no LITELLM_API_KEY for hours.
 
+  UPDATED 2026-07-16: Vault is SYNCED (session-13 keys written to vault via abiba service
+  token, all validate 200). Koby/Koonimo migrated from hardcoded drop-ins to the
+  infisical-gateway.sh wrapper (live vault injection). 4/5 agents now vault-backed.
+  Canonical process: see § Production Vault Access Process. Tanko (user jerome) pending.
+  Abiba's key is now a proper agent key (NOT the master key — stale note removed).
+
+  UPDATED 2026-07-17: FLEET-WIDE STANDARDIZATION. All 4 agents (Mumuni, Tanko, Koby, Koonimo)
+  standardized on a single pattern: systemd drop-in (ExecStart= reset + wrapper path) →
+  infisical-gateway.sh while-true loop → /usr/bin/infisical run --token → bash -c key
+  injection → .env fallback → exec python. Systemd drop-ins are IMMUNE to hermes gateway
+  install which overwrites the unit file ExecStart. Infisical CLI updated to 0.43.109 on
+  all agents (was 0.38.0). Service token st.8e848433 shared across fleet (st.353699cd
+  for tanko was deleted). .env fallback on every agent protects against token loss.
+  Critical lessons: (1) NEVER use shell variables inside single-quoted bash -c in wrappers
+  — hardcode absolute paths. (2) Drop-ins override unit file ExecStart permanently.
+  (3) Capture /proc/<pid>/environ before gateway restarts to preserve running env set.
+
   Current key inventory and agent list: see gpu-fleet.prose.md § Agent Keys.
   Source of truth for LiteLLM config: /opt/inference-harness/litellm_config.yaml
-  on CT 116. Last verified: 2026-07-12.
+  on CT 116. Last verified: 2026-07-17.
 ---
 
 ## Parameters
@@ -51,8 +68,8 @@ description: >
    - Generate new key with key_alias: "{agent_name}" (e.g., "tanko" — bare name, no date)
    - Set metadata: { "agent": "{agent_name}", "purpose": "agent-inference" }
    - Duration is null (permanent) — inherited from litellm default_key_generate_params
-   - Set models: ["syslog-auto", "qwen3.6-27B-code", "gemma-4-12b", "ornith-1.0-35b"]
-   - Note: qwen3.6-35B-A3B removed from fleet (was never deployed on any GPU)
+   - Set models: ["syslog-auto", "qwen3.6-27B-code", "gemma-4-12b", "strix-moe", "gpu-dense", "gpu-light", "qwen3.6-35B-udq4"]
+   - Note: `ornith-1.0-35b` is NOT a valid LiteLLM model name (use `strix-moe`, the stable alias). qwen3.6-35B-A3B removed from fleet (was never deployed).
    - Return the new key
 5. **If action == "rotate"**:
    - Generate new key with same alias (LiteLLM replaces the old key)
@@ -67,3 +84,202 @@ description: >
    - Test the key against LiteLLM /v1/models
    - Confirm key alias matches agent_name in LiteLLM key list
    - Verify agent gateway uses vault wrapper: `cat /proc/<pid>/cmdline` shows `infisical run`
+
+## Production Vault Access Process (canonical, 2026-07-17)
+
+The non-fail approach to agentic vault access. Deployed on all 4 Hermes agents
+(Mumuni, Tanko, Koby, Koonimo) as of 2026-07-17. Abiba (pi) uses a similar pattern
+through its agent wrapper.
+
+### The canonical pattern
+
+1. **infisical CLI** installed on the host at `/usr/bin/infisical` (v0.43.109+, from
+   artifacts-cli.infisical.com apt repo). Update procedure:
+   ```bash
+   curl -1sLf 'https://artifacts-cli.infisical.com/setup.deb.sh' | sudo -E bash
+   sudo apt-get update && sudo apt-get install -y infisical
+   # Remove stale old binary if present
+   rm -f /usr/local/bin/infisical /bin/infisical
+   ```
+   Wrappers use absolute path `/usr/bin/infisical run`. Never rely on PATH resolution.
+2. **Service token** (Infisical Machine Identity, `st.…`) stored at `~/.infisical-token`
+   (`chmod 600`). Current: shared `st.8e848433…` (abiba, READ+WRITE on agents project).
+   Tanko's `st.353699cd…` (tanko-agent) was deleted — reverted to shared token.
+   Proper: one machine identity per agent (create in Infisical UI → Project Settings →
+   Machine Identities).
+3. **`infisical-gateway.sh` wrapper** at `~/.hermes/infisical-gateway.sh` (`chmod 700`):
+   ```bash
+   #!/bin/bash
+   export INFISICAL_API_URL="https://vault.sysloggh.net"
+   TOKEN=$(cat $HOME/.infisical-token)
+   LOG=$HOME/.hermes/logs/gateway.log; mkdir -p $HOME/.hermes/logs
+   while true; do
+     echo "[$(date -Iseconds)] Starting gateway with Infisical injection..." >> $LOG
+     /usr/bin/infisical run --token="$TOKEN" \
+       --projectId=322fceab-39da-4854-a55a-568e76c0f13f \
+       --env=prod --domain=https://vault.sysloggh.net -- bash -c '
+         . $HOME/.hermes/.env 2>/dev/null   # [FALLBACK Rule 3]
+         export LITELLM_API_KEY="${<AGENT>_LITELLM_API_KEY}"
+         export ZULIP_API_KEY="${<AGENT>_ZULIP_API_KEY}"
+         export ZULIP_SITE="https://chat.sysloggh.net"
+         export ZULIP_EMAIL="<agent>-bot@chat.sysloggh.net"
+         export SEARXNG_URL="http://192.168.68.7:8888"
+         # ⚠️  HARDCODE the full venv path. NEVER use $VENV inside single quotes.
+         exec /root/.hermes/hermes-agent/venv/bin/python -m hermes_cli.main gateway run
+       ' >> $LOG 2>&1
+     EXIT_CODE=$?
+     echo "[$(date -Iseconds)] Gateway exited with code $EXIT_CODE — restarting in 5s..." >> $LOG
+     sleep 5
+   done
+   ```
+   **CRITICAL: VENV PATH.** The inner `bash -c '...'` uses single quotes. Shell
+   variables set in the outer wrapper are NOT expanded inside single quotes.
+   `$VENV/bin/python` resolves to `/bin/python` (file not found). Always hardcode
+   the absolute path to the venv python binary.
+4. **Agent key in vault** as `<AGENT>_LITELLM_API_KEY` and `<AGENT>_ZULIP_API_KEY`.
+   Vault = source of truth for ALL platform credentials.
+5. **`.env` fallback** at `~/.hermes/.env` (`chmod 600`) with agent-specific keys —
+   safety net for vault outage or token revocation. Must be kept in sync on rotation.
+   Example:
+   ```bash
+   MUMUNI_LITELLM_API_KEY=sk-OzuWsoX22Hmb3Ps3JY01gw
+   MUMUNI_ZULIP_API_KEY=H8dY6V7aHmWNcfgNtJaDBPZ1dGWn0Ttt
+   ```
+6. **systemd drop-in** at `~/.config/systemd/user/hermes-gateway.service.d/50-vault-wrapper.conf`:
+   ```ini
+   [Service]
+   ExecStart=
+   ExecStart=/root/.hermes/infisical-gateway.sh
+   ```
+   The `ExecStart=` (empty reset) clears any ExecStart from the main unit file,
+   then the second `ExecStart=` sets the wrapper. This drop-in **survives unit file
+   regeneration** by `hermes gateway install` — the drop-in always wins.
+
+   **Why a drop-in instead of editing the unit file:** `hermes gateway install`
+   (called during Hermes updates and some self-heal operations) regenerates the
+   systemd unit file with `ExecStart=/path/to/python -m hermes_cli.main gateway run`.
+   Editing the unit file directly is futile — it will be overwritten. The drop-in
+   approach explicitly resets ExecStart and sets the wrapper regardless of what the
+   main unit file says.
+7. **NEVER hardcode** API keys in systemd drop-ins, config.yaml, or /etc/environment.
+   The wrapper injects live from vault at every start.
+
+### Why this is non-fail
+
+- **No rot**: keys pulled live from vault at every gateway start. Rotation = one `infisical secrets set` + `systemctl restart`. No per-host file edits.
+- **Survives vault outage**: the `.env` fallback (Rule 3) keeps the gateway running if Infisical is unreachable or the service token is revoked.
+- **Survives gateway crash**: the wrapper's `while true` + systemd `Restart=always` revive the gateway. Two-layer defense.
+- **Survives Hermes updates**: systemd drop-in overrides unit file ExecStart — `hermes gateway install` cannot break the vault injection.
+- **Survives reboot**: systemd user service + `loginctl enable-linger` ensures gateway starts at boot without a login session.
+- **Auditable**: `cat /proc/$(pgrep -f 'python.*hermes_cli.main.gateway.run' | grep -v infisical | head -1)/environ` shows all injected keys (note: pipe through grep -v infisical to avoid matching the bash wrapper); `infisical secrets` shows the vault source.
+
+### Migration status (2026-07-17)
+
+| Agent | Host | Pattern | Keys | Status |
+|-------|------|---------|------|--------|
+| abiba | .24 | pi agent wrapper | ABIBA_LITELLM_API_KEY + ABIBA_ZULIP_API_KEY | ✅ vault-backed |
+| mumuni | .123 | systemd drop-in + while-true wrapper + st.8e848433 | MUMUNI_LITELLM_API_KEY + MUMUNI_ZULIP_API_KEY | ✅ vault-backed + .env fallback |
+| tanko | .122 | systemd drop-in + while-true wrapper + st.8e848433 (user jerome) | TANKO_LITELLM_API_KEY + TANKO_ZULIP_API_KEY | ✅ vault-backed + .env fallback |
+| koby | .129 | systemd drop-in + while-true wrapper + st.8e848433 | KOBY_LITELLM_API_KEY, shares TANKO_ZULIP_API_KEY (tanko-bot) | ✅ vault-backed |
+| koonimo | .114 | systemd drop-in + while-true wrapper + st.8e848433 | KOONIMO_LITELLM_API_KEY + KOONIMO_ZULIP_API_KEY | ✅ vault-backed |
+
+> Tanko runs as user `jerome` — wrapper/token at `~/.hermes/infisical-gateway.sh` and
+> `~/.infisical-token`. Linger enabled (`loginctl enable-linger jerome`) for boot startup.
+
+### Tanko migration (COMPLETED 2026-07-17)
+
+Tanko was the last agent migrated from hardcoded keys to vault wrapper.
+Previously: key hardcoded in `/home/jerome/.hermes/config.yaml` (`api_key: sk-CggiHWlamQy…`)
+and `zulip-env.conf` systemd drop-in. Now: user-scope systemd service with drop-in
+`50-vault-wrapper.conf`, `infisical-gateway.sh` wrapper with while-true loop, token at
+`~/.infisical-token`, `.env` fallback at `~/.hermes/.env`. Keys injected live from vault.
+
+### Koby migration lessons (2026-07-16, updated 2026-07-17)
+
+Migrated Koby from hardcoded systemd drop-in → `infisical-gateway.sh` wrapper.
+**Three mistakes made:**
+1. **Overwrote `/root/.hermes/.env`** without backing it up. The Zulip API key only existed
+   in the running process memory — the old .env was minimal (just LiteLLM key). Zulip creds were
+   inherited from the pre-migration gateway env, not stored in any file. Lost on restart.
+2. **Only injected `LITELLM_API_KEY`** in the wrapper — forgot Zulip + Telegram credentials.
+   Agents need ALL their platform env vars. Missing vars cause silent adapter failures.
+3. (2026-07-17 fix) **VENV variable in single-quoted bash -c**: `exec "$VENV/bin/python"`
+   inside single quotes resolved to `exec "/bin/python"` (file not found). Hardcoded full path.
+
+**How Koby actually connects:**
+- Zulip: shares **Tanko's bot** (`tanko-bot@chat.sysloggh.net`, `TANKO_ZULIP_API_KEY=5PeD6f3zo…`).
+- Telegram: token from `.env` fallback. Allowed users: 6679773481.
+- Both platforms now connect through the wrapper's env injection.
+
+**Golden rules for gateway restarts:**
+1. Always `cat /proc/<pid>/environ` before killing the old process — captures the live env set.
+2. Hardcode venv python path in wrapper — never use variables inside single-quoted bash -c.
+3. Use systemd drop-ins (not unit file edits) to override ExecStart — survives Hermes updates.
+
+### Fleet-wide standardization lessons (2026-07-17)
+
+After auditing all 4 agents, five systemic patterns caused repeated failures:
+1. **Three incompatible startup patterns** coexisted (systemd drop-in, direct python, orphaned wrapper)
+2. **Systemd unit files reverted** by `hermes gateway install` during updates
+3. **VENV variable scoping** broke wrappers on Koby and Mumuni (single-quote bash -c)
+4. **Service token expiry** — Tanko's `st.353699cd` was deleted from Infisical
+5. **No ZULIP_API_KEY** in env on Tanko — wrapper bypassed by systemd direct python
+
+All resolved by the canonical drop-in + while-true wrapper pattern documented above.
+
+### Key rotation procedure (one vault operation with this standard)
+
+1. Generate new key: `POST /key/generate` (master key, admin).
+2. Update vault: `infisical secrets set <AGENT>_LITELLM_API_KEY=sk-NEW --token=$TOKEN --projectId=322fceab… --env=prod --domain=https://vault.sysloggh.net`.
+3. Update `.env` fallback: `echo '<AGENT>_LITELLM_API_KEY=sk-NEW' > /root/.hermes/.env && chmod 600 /root/.hermes/.env`.
+4. Restart: `systemctl restart hermes-gateway`. The wrapper pulls the new key live.
+5. Verify: `curl -H "Authorization: Bearer sk-NEW" http://192.168.68.116/v1/models` → 200.
+
+## Machine Identity for Vault Writes (UPDATED 2026-07-17)
+
+**Current state:** Infisical CLI updated to v0.43.109 on all agents (from v0.38.0).
+The v0.38.0 bug (user-session auth fails for `secrets set`/`export`) is resolved.
+Service token `st.8e848433…` (abiba, READ+WRITE) can write to vault from CLI.
+
+**Proper fix — per-agent Machine Identities:**
+Create machine identities in Infisical UI → Project Settings → Machine Identities
+for each agent with READ-only scope on the `agents` project. Store client_id +
+client_secret per agent. Then vault writes use the shared abiba identity, and
+reads use per-agent identities. This eliminates the single shared token risk.
+
+**Service Token Inventory (2026-07-17):**
+| Token ID | Name | Permissions | Used By | Status |
+|----------|------|-------------|---------|--------|
+| `st.8e848433…` | tanko-gateway | READ+WRITE | Mumuni, Tanko, Koby, Koonimo, Abiba | ✅ Active |
+| `st.353699cd…` | tanko-agent | READ-only | — | ❌ Deleted from Infisical |
+
+**Per-agent .env fallback inventory (2026-07-17):**
+| Agent | .env Keys |
+|-------|-----------|
+| Mumuni | MUMUNI_LITELLM_API_KEY, MUMUNI_ZULIP_API_KEY |
+| Tanko | TANKO_LITELLM_API_KEY, TANKO_ZULIP_API_KEY |
+| Koby | (wrapper injects from vault — .env has Telegram token) |
+| Koonimo | KOONIMO_LITELLM_API_KEY, KOONIMO_ZULIP_API_KEY |
+
+## Key Rotation Log
+
+| Date | Agent | Action | Notes |
+|------|-------|--------|-------|
+| 2026-07-17 | fleet | standardize | All 4 agents standardized on systemd drop-in + while-true wrapper + infisical v0.43.109. Removed conflicting zulip-env.conf + litellm-key.conf drop-ins. Added .env fallbacks with ZULIP keys. WAL #1322. |
+| 2026-07-17 | tanko | fix-zulip | Added ZULIP_API_KEY to env (was missing — systemd bypassed vault). Updated wrapper from exec to while-true. Created .env fallback. Removed hardcoded zulip-env.conf drop-in. WAL #1321. |
+| 2026-07-16 | vault | cleanup | 4 stale secrets deprecated. 5 personal creds flagged. |
+| 2026-07-16 | koonimo | add-zulip | Added KOONIMO_ZULIP_API_KEY to vault. Wrapper injects ZULIP_API_KEY + ZULIP_EMAIL. 3 platforms. |
+| 2026-07-16 | tanko | migrate | Migrated from hardcoded config.yaml to infisical-gateway.sh + st.353699cd. NOTE: st.353699cd later deleted — reverted to st.8e848433 on 2026-07-17. |
+| 2026-07-16 | mumuni | rotate | Old key malformed (sk-_SWAl_Vu_, 47 chars, not LiteLLM format) → 401. Deleted old `mumuni` key (token 15cbca18…), generated fresh (alias `mumuni`, 7 models: syslog-auto, qwen3.6-27B-code, gemma-4-12b, strix-moe, gpu-dense, gpu-light, qwen3.6-35B-udq4). New key sk-OzuWsoX2… written to /root/.hermes/.env (Rule 3/13 fallback). Vault sync PENDING (needs machine identity). WAL #1300. |
+| 2026-07-16 | koby | rotate | Old key sk-6sbCNjz (401, stale in /etc/environment). Deleted old `koby` key, generated fresh (alias `koby`). New key sk-BqRRMboTI… in systemd drop-in `hermes-gateway.service.d/litellm-key.conf` + /etc/environment. Created `hermes-gateway.service` unit (was missing — gateway wasn't persistent) with `--replace`. Verified HTTP 200, Telegram connected. |
+| 2026-07-16 | baggy (koonimo) | rotate | Old key sk-krnw_zGB (401, hardcoded in systemd drop-in). Deleted old `baggy` key, generated fresh (alias `baggy`, metadata agent=koonimo). New key sk-OEK7z26n6E… in drop-in `hermes-gateway.service.d/litellm-key.conf`. CT113 IP changed .113→.114. Verified HTTP 200, Zulip connected. |
+
+## LiteLLM Master Key (use sparingly — agents should NOT use it directly)
+
+- Master key: `sk-litellm-7f96080dd99b15c36bd4b333b58a6796` (in /opt/inference-harness/.env on CT116, Infisical project=infrastructure env=production secret=LITELLM_MASTER_KEY)
+- Used for /key/generate, /key/delete, /key/list (GET), DB queries
+- **Known violation (RESOLVED 2026-07-16):** Abiba's LITELLM_API_KEY was previously the master key.
+It is now a dedicated agent key `sk-sxbphLvk1OU…` (vault secret `ABIBA_LITELLM_API_KEY`, alias `abiba-pi`).
+The master key is admin-only (/key/generate, /key/delete, /key/list). NEVER use it for inference —
+see `litellm-self-heal` § "NEVER use litellm_proxy_master_key for inference".
+- LiteLLM key DB: `harness-postgres` container on CT116, table `"LiteLLM_VerificationToken"` (columns: token, key_alias, key_name, created_at, expires). Query: `docker exec harness-postgres psql -U litellm -d litellm -t -c "SELECT key_alias, substr(token,1,16) FROM \"LiteLLM_VerificationToken\" ORDER BY created_at;"`

litellm-health.prose.md

@@ -42,8 +42,8 @@ Request → nginx:80 → LiteLLM:4000 → GPU(llama-server, parallel 2)
 **What changed (v3.2.0 → v4.0.0 — 2026-07-08)**:
 - Router REMOVED from request path — LiteLLM proxies directly to GPU
 - All GPUs at parallel 2 (was parallel 1)
-- NVIDIA context reduced 256K→128K to free VRAM
-- LiteLLM timeouts tuned: gemma 25→120s, qwen 40→90s
+- NVIDIA context reduced 256K→128K to free VRAM  (SUPERSEDED 2026-07-16: all GPUs back to 256K — see litellm-self-heal)
+- LiteLLM timeouts tuned: gemma 25→120s, qwen 40→90s  (SUPERSEDED 2026-07-16: qwen 300s, gemma 120s, strix 300s — see litellm-self-heal)
 - nginx proxy_read_timeout: 600s, LiteLLM request_timeout: 300s
 
 ## Parameters
@@ -72,18 +72,18 @@ Request → nginx:80 → LiteLLM:4000 → GPU(llama-server, parallel 2)
 
 | Host | IP | Hardware | Models Served | Engine | Context | Parallel |
 |------|-----|----------|---------------|--------|---------|----------|
-| llm-gpu | 192.168.68.8 | NVIDIA RTX 3090 (24 GB) | qwen3.6-27B-code | llama-server systemd | 128K | 2 |
-| ocu-llm | 192.168.68.110 | NVIDIA RTX 5070 (12 GB) | gemma-4-12b | llama-server systemd | 128K | 2 |
-| amdpve | 192.168.68.15 | AMD Strix Halo 64GB UMA | ornith-1.0-35b | llama-server systemd (Vulkan) | 256K | 2 |
+| llm-gpu | 192.168.68.8 | NVIDIA RTX 3090 (24 GB) | qwen3.6-27B-code | llama-server systemd | **256K** | 2 |
+| ocu-llm | 192.168.68.110 | NVIDIA RTX 5070 (12 GB) | gemma-4-12b | llama-server systemd | **256K** | 2 |
+| amdpve | 192.168.68.15 | AMD Strix Halo 64GB UMA | qwen3.6-35B-udq4 (LiteLLM alias: strix-moe) | llama-server systemd (Vulkan) | 256K | 2 |
 
 ## Model Fallback Chains (LiteLLM)
 
 | Primary | Timeout | Fallback | Timeout |
 |---------|---------|----------|---------|
-| qwen3.6-27B-code | 90s | gemma-4-12b | 120s |
-| gemma-4-12b | 120s | qwen3.6-27B-code | 90s |
-| ornith-1.0-35b | 120s | qwen → gemma | — |
-| syslog-auto (balanced) | 90s | qwen → gemma | — |
+| qwen3.6-27B-code | 300s | gemma-4-12b | 120s |
+| gemma-4-12b | 120s | qwen3.6-27B-code | 300s |
+| qwen3.6-35B-udq4 / strix-moe | 300s | qwen → gemma | — |
+| syslog-auto (balanced) | 300s | qwen → gemma | — |
 
 > Global: request_timeout=300s, nginx proxy_read_timeout=600s
 
@@ -129,7 +129,7 @@ Request → nginx:80 → LiteLLM:4000 → GPU(llama-server, parallel 2)
 7. **Check model inference via LiteLLM** — Test each model:
    - POST /v1/chat/completions model=gemma-4-12b → expect 200
    - POST /v1/chat/completions model=qwen3.6-27B-code → expect 200
-   - POST /v1/chat/completions model=ornith-1.0-35b → expect 200
+   - POST /v1/chat/completions model=strix-moe → expect 200
    - Use master key for auth
 
 8. **Check agent keys**:

litellm-self-heal.prose.md

@@ -6,6 +6,7 @@ note: >
   DEPLOYED 2026-07-12 on CT 116 cron: 0 */6 * * *
   Auto-remediation code was removed from the pi Zulip extension (retired 2026-07-04),
   now reimplemented as `litellm-health-check.sh` on CT 116.
+  Script: `/opt/inference-harness/scripts/litellm-health-check.sh` on CT 116 (cron `0 */6 * * *`).
   Reports to /var/log/litellm/health-*.json and RA-H OS knowledge graph.
   GPU monitoring integrated from gpu-monitor on .24:9100.
   
@@ -56,18 +57,29 @@ Request → nginx:80 → LiteLLM:4000 → GPU(llama-server, parallel 2)
 
 | Host | IP | Hardware | Models Served | Engine | Context | Parallel |
 |------|-----|----------|---------------|--------|---------|----------|
-| llm-gpu | 192.168.68.8 | NVIDIA RTX 3090 (24 GB) | qwen3.6-27B-code | llama-server systemd | **256K** | 1 |
-| ocu-llm | 192.168.68.110 | NVIDIA RTX 5070 (12 GB) | gemma-4-12b | llama-server systemd | 131K | 2 |
-| amdpve | 192.168.68.15 | AMD Strix Halo 64GB UMA | ornith-1.0-35b | llama-server systemd (Vulkan) | 256K | 2 |
+| llm-gpu | 192.168.68.8 | NVIDIA RTX 3090 (24 GB) | qwen3.6-27B-code | llama-server systemd (`/home/llmuser/llama-wrapper.sh`, `-c 262144 --parallel 2 --ngl 99`) | **256K** | 2 |
+| ocu-llm | 192.168.68.110 | NVIDIA RTX 5070 (12 GB) | gemma-4-12b | llama-server systemd (`/home/llmuser/llama-wrapper.sh`, `--ctx-size 262144 --parallel 2`, IQ4_NL + MTP draft) | **256K** | 2 |
+| amdpve | 192.168.68.15 | AMD Strix Halo 64GB UMA | qwen3.6-35B-udq4 (LiteLLM alias: `strix-moe`) | llama-server systemd (Vulkan) | 256K | 2 |
+
+> Verified on ground 2026-07-16 via `curl /v1/models` on each host + `llama-wrapper.sh`. The AMD host's underlying model is `qwen3.6-35B-udq4`; LiteLLM exposes it under two `model_name`s: `qwen3.6-35B-udq4` and `strix-moe` (rpm 40). The legacy name `ornith-1.0-35b` does NOT exist in LiteLLM and must not be referenced.
+
+## LiteLLM Model Surface (ground truth — `/opt/inference-harness/litellm_config.yaml` on CT 116)
+
+`model_name`s served: `qwen3.6-27B-code`, `gemma-4-12b`, `qwen3.6-35B-udq4`, `strix-moe`, `gpu-dense`, `gpu-light`, `syslog-auto`.
+
+- `syslog-auto` is a weighted router model: qwen3.6-27B-code (0.55, rpm 500) + qwen3.6-35B-udq4 (0.30, rpm 60) + gemma-4-12b (0.15, rpm 200).
+- `gpu-dense` / `gpu-light` are high-rpm aliases (rpm 500) onto qwen3.6-27B-code / gemma-4-12b respectively.
+- Key scoping: agent keys are restricted to `['syslog-auto','qwen3.6-27B-code','gemma-4-12b','strix-moe','gpu-dense','gpu-light']`. As of 2026-07-16 the `baggy`/`koby`/`mumuni`/`abiba-pi` keys ALSO include `qwen3.6-35B-udq4`; `abiba-pi` additionally includes `deepseek-v4-pro` (cloud fallback). `kagenz0`/`koonimo`/`pi-agents-unified` have the standard 6 only. Agents should still use the stable alias `strix-moe` (not the raw `qwen3.6-35B-udq4`) so model swaps don't break them.
+- **NEVER use `litellm_proxy_master_key` (the `sk-litellm-...` master key) for inference.** It is for admin endpoints only (`/key/list`, `/key/generate`, `/key/info`). All inference — agent traffic, health-check model tests, monitor scripts — uses agent-specific keys. The health-check script's model tests use a dedicated `monitor` agent key stored at `/etc/litellm-monitor.env` on CT 116 (root-only, `chmod 600`); `/key/list` is the only call that legitimately uses `$MASTER_KEY`.
 
 ## Model Fallback Chains (LiteLLM)
 
 | Primary | Timeout | Fallback | Timeout |
 |---------|---------|----------|---------|
-| qwen3.6-27B-code | 90s | gemma-4-12b | 120s |
-| gemma-4-12b | 120s | qwen3.6-27B-code | 90s |
-| ornith-1.0-35b | 120s | qwen → gemma | — |
-| syslog-auto (balanced) | 90s | qwen → gemma | — |
+| qwen3.6-27B-code | 300s | gemma-4-12b | 120s |
+| gemma-4-12b | 120s | qwen3.6-27B-code | 300s |
+| qwen3.6-35B-udq4 / strix-moe | 300s | qwen → gemma | — |
+| syslog-auto (balanced) | 300s | qwen → gemma | — |
 
 > Global: request_timeout=300s, nginx proxy_read_timeout=600s
 
@@ -86,6 +98,13 @@ Request → nginx:80 → LiteLLM:4000 → GPU(llama-server, parallel 2)
 | harness-docker-stats | python:3.12-alpine | — | container stats exporter |
 | harness-pve-exporter | prompve/prometheus-pve-exporter | — | Proxmox metrics → Prometheus |
 
+## Script Operations (synced 2026-07-16)
+
+- **Health-check script** (`/opt/inference-harness/scripts/litellm-health-check.sh` on CT 116): `gpu-fleet` check fails only on **critical** alerts (warnings are informational). Tests `strix-moe` (not `ornith-1.0-35b`).
+- **GPU monitor** (`/root/scripts/gpu-monitor-server.py` on pi .24): runs as **systemd unit `gpu-monitor.service`** (was bare `&` process). `gpu_count` includes Strix Halo (was 2, now 3). VRAM alert thresholds: warning 93%, critical 97% (raised from 90/95 — 256K context steady-state is ~96% on RTX 3090, not a fault).
+- **Agent key monitor** (`/root/scripts/agent-health-check.py` on pi .24, cron `*/10`): reads each agent's **live** `LITELLM_API_KEY` from its gateway process env via SSH — never hardcodes keys (hardcoded keys rot on rotation and caused 9×401/30min). Fleet roster: abiba, tanko, mumuni, koby, koonimo (legacy `tdunna`/`baggy` removed — never existed).
+- **Stale keys cleaned**: `daily-infra-report.py` SYNTHETIC_API_KEY was stale (`sk-U_ydi3B` → 401); now reads `LITELLM_MASTER_KEY` from env. Deprecated scripts (`router-original.py`, `router-phase0-backup.py`, `apply-fixes.py`) still reference `sk-syslog-local-master-key` but do not actively poll LiteLLM.
+
 ## Maintains
 
 - litellm-admin-ui: { status: "healthy", last_check: timestamp }
@@ -128,7 +147,7 @@ Run this first on every cycle. Results feed into remediation rules below.
 ### 5. Check model inference via LiteLLM — test each model
 - POST /v1/chat/completions model=gemma-4-12b → expect 200
 - POST /v1/chat/completions model=qwen3.6-27B-code → expect 200
-- POST /v1/chat/completions model=ornith-1.0-35b → expect 200
+- POST /v1/chat/completions model=strix-moe → expect 200
 - Use master key for auth
 
 ### 6. Check agent keys

mumuni-delegation-prose-contract.prose.md

@@ -0,0 +1,290 @@
+---
+kind: pattern
+name: mumuni-delegation
+description: >
+  Mumuni-specific operating doctrine for task decomposition, worker
+  delegation, verification, and delivery. Defines when to delegate, which
+  worker to use for what, how to handle failures, and the kanban board
+  protocol. Enforces context-window discipline and separation of concerns.
+  Runs on Mumuni (CT 118, storepve, .6) via Hermes agent.
+version: 1.0.0
+---
+
+## Maintains
+
+- Worker roster: 6 profiles (`syslog-code`, `syslog-devops`, `syslog-email`,
+  `syslog-research`, `syslog-review`, `syslog-writer`)
+- Kanban board state at `~/.hermes/kanban/kanban.json`
+- Context window budget: ~65K tokens per request (131K total, 60% threshold)
+
+## Topology
+
+**Cluster:** 5 Proxmox nodes (ocupve, acerpve, minipve, amdpve, storepve)
+**Manager:** Mumuni (CT 118, storepve, .6) via Hermes agent
+**Workers:** 6 profiles, all running on the same agent — no separate hosts needed
+
+This contract is infrastructure-agnostic in terms of which nodes are used.
+Workers execute tasks on whatever infrastructure they're given — SSH to .6,
+.pm, .9, .12, or .15 depending on the task. The contract defines the
+**who** and **when** — not the **where**.
+
+## Why This Matters
+
+Without enforced delegation, the manager consumes the full iteration budget
+(60 calls) on single-turn tasks — SSH to 5 nodes, check each VM, read logs —
+leaving no capacity for actual coordination. The result: context overflow
+(59K tokens in system prompt), iteration exhaustion, and degraded response
+quality. This contract exists because I blew through my budget checking
+Proxmox node status instead of delegating to `syslog-devops`.
+
+## Context Window Discipline
+
+**The system prompt is ~6.5K tokens (stable: ~4.5K tool schemas + ~2K other guidance).**
+**Volatile (MEMORY.md + USER.md): ~300 tokens.**
+**Total base: ~6,800 tokens per request.**
+
+The remaining budget is the conversation. Every tool call result adds to it.
+If a single call returns >10K tokens (e.g., `grep` on a large file, SSH output
+from multiple nodes), the context fills fast. That's why we delegate: workers
+process in isolation and return compact results.
+
+## Trigger Conditions
+
+Delegation is **mandatory** when any of these apply:
+
+| Condition | Threshold | Example |
+|-----------|-----------|---------|
+| Multiple tool calls needed | 2+ calls with intermediate logic | Read file → analyze → write report |
+| Large data retrieval | Output >5K tokens | `grep -r "pattern" /path` on large dirs |
+| Cross-domain work | Spans 2+ worker specialties | Infra check + email filter |
+| Infrastructure changes | Any mutating operation | `qm set`, `systemctl restart`, `git push` |
+| Research/analysis | Needs browser or deep reading | Web research, code review, data analysis |
+| Code builds or changes | Writing or modifying code | Scripts, configs, patches |
+| Sequential dependencies | Worker B needs Worker A's output | Code → Review → Deliver |
+
+**Single tool calls stay at manager level.** Quick `grep`, `ls`, `cat`,
+`curl`, `hermes tools list` — these are decision-making tools. The manager
+reads them directly.
+
+## Data Source Integrity (CRITICAL)
+
+**Workers MUST use the data provided in their task context. They MUST NOT
+fetch their own data from external sources unless explicitly told to.**
+
+When a task says "Read file X and format it", the worker reads file X. It does
+not query a separate API, run its own diagnostics, or pull data from a different
+system. This is the #1 source of cross-worker inconsistency: one worker gathers
+SSH data, another queries the Proxmox API, and the report merges two incompatible
+datasets.
+
+**Rule:** If a worker needs additional data beyond what's in its task description,
+it asks the manager (via relay) — it doesn't go find it on its own.
+
+**This is a hard rule, not a recommendation.** Violating it produces the exact
+type of discrepancy the kanban pipeline exists to prevent: a review worker finds
+"5 nodes present" in the raw data but "5/5 online" in the report — even though
+one of those nodes was unreachable. The report lied because it used data the
+raw data never provided.
+
+## Worker Selection Matrix
+
+| Worker | Model | Toolsets | Role | Use When |
+|--------|-------|----------|------|----------|
+| `syslog-code` | qwen3.6-27B-code | terminal, file, web, memory, skills | Code patches, automation, scripts | Writing/modifying code, creating scripts, debugging, reading/writing files |
+| `syslog-devops` | qwen3.6-27B-code | terminal, file, web, memory, skills | Infrastructure, DB, bridge, Proxmox | Server ops, SSH, Docker, Proxmox, DB queries, hardware checks |
+| `syslog-email` | strix-moe | terminal, file, web, memory, skills | Email automation, mail operations | Sending/receiving email, inbox management, SMTP operations |
+| `syslog-research` | strix-moe | terminal, file, web, memory, skills, **browser** | Analysis, classification, data processing | Web research, browser tasks, data analysis, classification, reading docs |
+| `syslog-review` | strix-moe | terminal, file, web, memory, skills | Verification, QA, audit validation | **ALWAYS** verify worker output before delivery — especially for infra changes, code builds, and research findings |
+| `syslog-writer` | strix-moe | terminal, file, web, memory, skills | Docs, content, branding, reports | Writing docs, reports, proposals, content, markdown formatting |
+
+### Selection Rules
+
+1. **Match specialty first.** A code task → `syslog-code`. An infra task →
+   `syslog-devops`. Don't put a `syslog-email` worker on a code review.
+2. **Research tasks with browser needs → `syslog-research`.** Other workers
+   don't have the browser toolset.
+3. **Verification → `syslog-review`.** Never deliver raw worker output.
+4. **Documentation/content → `syslog-writer`.** Let them own the prose.
+5. **If unsure, delegate to `syslog-research`** — it has the broadest toolset
+   (includes browser) and high reasoning effort.
+
+## Delegation Protocol
+
+### Step 1: Decompose
+
+Break the task into lanes. Each lane does ONE thing. Workers are independent —
+no lane depends on another's output mid-flight. If lanes depend on each other,
+dispatch sequentially.
+
+### Step 2: Dispatch
+
+Fire workers via `delegate_task`:
+
+**Critical: Pass the data, not just the goal.** When dispatching a worker that
+processes output from another worker, include the file path AND explicit
+instructions to use ONLY that source. Example:
+
+```
+delegate_task(
+    goal="Format the cluster check into a clean report",
+    context="Source data is at /tmp/proxmox-check-raw.md. Format ONLY the data
+    in that file. Do NOT query the Proxmox API or any other data source. Use the
+    file as your sole source of truth."
+)
+```
+
+**Parallel (independent lanes):**
+```
+delegate_task(
+    tasks=[
+        {"goal": "Check all 5 Proxmox nodes for VM status", "context": "SSH to each node via 192.168.68.x, run 'qm list'"},
+        {"goal": "Check Docker container health on .7/.116/.17", "context": "SSH to each host, check container status"},
+    ]
+)
+```
+
+**Sequential (dependent lanes):**
+Dispatch lane 1 → wait for result → dispatch lane 2.
+
+### Step 3: Verify
+
+**MANDATORY for:**
+- Infrastructure changes (any `qm`, `pct`, `systemctl`, `git push`)
+- Code builds and modifications
+- Research findings (web data, external sources)
+- Any output that will reach the user
+
+**Fire `syslog-review` to verify:**
+```
+delegate_task(
+    goal="Review the output of the devops worker. Verify the node status
+    report is accurate, check for inconsistencies, confirm all nodes were
+    reachable.",
+    context="Worker was syslog-devops. Output is at /tmp/node-report.md.
+    Verify against live system."
+)
+```
+
+**If verification fails:**
+1. Send work back to original worker with review feedback
+2. Re-verify
+3. Max 2 re-verify cycles before escalating to Kwame
+
+### Step 4: Deliver
+
+Only verified results reach Kwame. Format per channel:
+- Telegram: Use `telegram-formatting` skill
+- Zulip: Use Zulip Markdown (CommonMark)
+- Email: Use `syslog-email` skill
+
+## Kanban Board Protocol
+
+**File:** `~/.hermes/kanban/kanban.json`
+
+```json
+{
+  "task_id": "unique-id",
+  "title": "Task description",
+  "created": "2026-07-09T01:00:00",
+  "status": "backlog|in_progress|review|done",
+  "lanes": [
+    {
+      "lane_id": "devops-check",
+      "worker": "syslog-devops",
+      "goal": "Check all 5 Proxmox nodes",
+      "status": "dispatched|completed|failed",
+      "output_file": "/tmp/node-report.md"
+    }
+  ]
+}
+```
+
+**Update the board on every state change.**
+
+## Failure Handling
+
+### Worker Timeouts
+
+- Child timeout: **900 seconds** (15 minutes)
+- Worker model `syslog-auto` is slow — it can hit the timeout limit with
+  22+ API calls
+- **If a worker times out:** Re-dispatch with a narrower scope. Break the
+  task into smaller pieces that fit in the timeout window.
+- **Avoid delegating sequential SSH hops** — each SSH connection adds latency
+  that compounds quickly. Prefer API-based or local approaches when possible.
+
+### Worker Selection Failures
+
+- `syslog-devops` is best for infrastructure tasks (SSH, Proxmox, Docker)
+- `syslog-code` is best for code-level work (reading files, writing scripts)
+- `syslog-research` has the browser toolset — use for web research
+- `syslog-review` is the QA gate — always fire before delivery
+- **Never fire more than 3 parallel workers** (max_concurrent_children: 3)
+- **Never nest delegation** (max_spawn_depth: 1)
+
+### Context Overflow
+
+- If a task requires >10K tokens of output, delegate the processing
+- Workers return compact summaries, not raw data dumps
+- Pass file paths and concrete goals — never dump raw data into context
+
+## Anti-patterns
+
+- ❌ Reading large files into your own context before deciding → delegate the read
+- ❌ Carrying SSH/grep/output results in your context → delegate the analysis
+- ❌ Doing work yourself and then "pretending" to delegate → the user can tell
+- ❌ Skipping verification → raw worker output never reaches the user
+- ❌ Delegating single tool calls → keep quick reads/writes at manager level
+- ❌ Firing more than 3 workers in parallel → hard limit
+- ❌ **Workers fetching their own data sources** → a writer worker that queries the Proxmox API when told to "format the raw file" is fabricating data. Use the input given, not external sources
+
+## Emergency Exception
+
+**In an emergency (server down, service must be restored immediately):**
+- Delegate the diagnosis (find the problem)
+- Execute the fix yourself (minimize handoff latency)
+- Verify the fix after delivery
+- Log the exception in the kanban board
+
+The emergency exception exists because the user needs the service back NOW,
+not after three worker round-trips. But it's an exception — not the rule.
+
+## What This Contract Doesn't Cover
+
+1. **Worker profile configuration** — covered by `hermes-config-template.prose.md`
+2. **SSH key management** — covered by existing SSH/Proxmox contracts
+3. **Git workflow** — covered by `AGENTS.md` in the prose-contracts repo
+4. **Cron job management** — covered by individual cron contracts
+5. **Infra verification** — covered by `verify-before-mutate` protocol
+
+## Verification
+
+Run `scripts/worker-audit.py` to verify all 6 profiles are aligned:
+
+```bash
+python3 /root/.hermes/skills/kanban-orchestrator/scripts/worker-audit.py
+```
+
+## References
+
+- `kanban-orchestrator` skill: The operational playbook (detailed execution steps)
+- `worker-profile-audit.md` (skill reference): Worker configuration audit notes
+- `delegation-timeout-patterns.md` (skill reference): Timeout handling patterns
+- `verify-before-mutate` protocol: Infrastructure change verification
+- `hermes-config-template.prose.md`: Worker profile configuration
+
+## Success Criteria
+
+This contract succeeds when:
+
+1. **No context overflow** — single-turn tasks don't exhaust the iteration budget
+2. **Workers do the work** — manager coordinates, doesn't execute
+3. **Verification before delivery** — all output passes through `syslog-review`
+4. **Kanban board is current** — every task has a lane, every lane has a status
+5. **User gets verified results** — raw worker output never reaches Kwame
+
+---
+
+**Last updated:** 2026-07-09
+**Author:** Mumuni (with Kwame's input on triggers and exception criteria)
+**Status:** Draft — awaiting PR review and merge to prose-contracts main

ra-h-os-custodianship-contract.prose.md

@@ -0,0 +1,210 @@
+---
+kind: pattern
+name: ra-h-os-custodianship-contract
+description: >
+  Operational standards for maintaining RA-H OS as a high-functioning shared
+  memory system across all agents. Defines rules for embedding consistency,
+  namespace discipline, staleness management, orphan prevention, agent
+  custodianship, and recovery protocols. Prevents knowledge graph degradation
+  and ensures reliable semantic search capabilities.
+---
+
+# RA-H OS Custodianship Contract — Shared Memory Protocol
+
+## Purpose
+This contract establishes the operational standards for maintaining RA-H OS as a high-functioning shared memory system across all agents. It defines the rules, responsibilities, and recovery protocols that prevent knowledge graph degradation and ensure consistent, reliable semantic search capabilities.
+
+## Core Principles
+
+### 1. Embedding Consistency
+**Rule:** All nodes MUST use the RA-H OS built-in embedding pipeline via `http://192.168.68.65:8080/v1/embeddings` for consistent vector representation.
+
+**Requirements:**
+- The embedding service at `192.168.68.65:8080` is the single source of truth for vector generation
+- No external embedding APIs (OpenAI, Cohere, etc.) may be used for RA-H OS nodes
+- All nodes must have `embedding_status: "chunked"` and `chunk_status: "chunked"` upon creation
+- If embedding fails, the node must be immediately flagged as `state: "unsearchable"` and logged
+
+### 2. Namespace Discipline
+**Rule:** All nodes MUST be categorized into one of three namespaces with strict metadata requirements.
+
+**Namespace Structure:**
+- `agent-private`: Isolated working notes for individual agents (Mumuni, Tanko, Okyeame, etc.)
+- `shared`: Policy files, registry nodes, collective knowledge
+- `syslogsolution`: Business nodes, client data, operational context
+
+**Metadata Requirements:**
+Every node MUST have these metadata fields:
+```json
+{
+  "agent_id": "<agent_name>",
+  "namespace": "<namespace>",
+  "state": "<state>",
+  "type": "<type>",
+  "owner": "<owner>",
+  "tenant": "<tenant>",
+  "visibility": "<visibility>",
+  "source": "<source>",
+  "captured_by": "<captured_by>"
+}
+```
+
+### 3. Staleness Management
+**Rule:** Nodes are categorized by type and have specific staleness thresholds.
+
+**Staleness Thresholds:**
+- `policy` type: 30 days (e.g., Shared Memory Policy, Agent Registry)
+- `registry` type: 30 days (e.g., Node State Management, Health Dashboard)
+- `template` type: 30 days (e.g., Agent SOUL.md)
+- `note` type: 60 days (e.g., business context, project notes)
+- `information` type: 90 days (e.g., reference documentation)
+- `idea` type: 30 days (e.g., brainstorming, experimental notes)
+
+**Transition Protocol:**
+- `active` → `stale`: After days since `updated_at` exceeds threshold
+- `stale` → `review_pending`: Daily cron check flags for human review
+- `review_pending` → `active`: Human reviews and updates content
+- `review_pending` → `archived`: After 15 days in review_pending state (automatic purge)
+
+### 4. Orphan Prevention
+**Rule:** No node should remain orphaned (0 edges) for more than 7 days.
+
+**Orphan Detection:**
+- Daily cron job identifies nodes with 0 incoming/outgoing edges
+- Orphans are flagged with `state: "review_pending"` and `metadata.orphan_detected: true`
+- 7-day grace period: Orphans must be either:
+  - Connected to relevant nodes via edges
+  - Merged into existing parent nodes
+  - Archived after 15 days in review_pending state
+
+### 5. Agent Custodianship
+**Rule:** Each agent is responsible for maintaining their own created nodes.
+
+**Responsibilities:**
+- **Mumuni**: Primary custodian for `syslogsolution` namespace, health dashboard, and all business nodes
+- **Tanko**: Custodian for `agent-private` namespace, personal notes, and fitness/creative work
+- **Okyeame**: Custodian for `shared` namespace, policy files, and collective knowledge nodes
+- **All Agents**: Must verify embedding status before reporting node creation as complete
+
+### 6. Embedding Failure Recovery
+**Rule:** When embedding pipeline is unavailable, nodes are blocked from creation or immediately flagged.
+
+**Recovery Protocol:**
+1. **Detection**: Daily health check monitors `http://192.168.68.65:8080/health` endpoint
+2. **Alert**: If embedding service is down, alert is sent to all agents via relay
+3. **Mitigation**: 
+   - New node creation is suspended
+   - Existing nodes with `chunk_status: "not_chunked"` are flagged as `unsearchable`
+4. **Recovery**: When service returns:
+   - All `not_chunked` nodes are queued for re-embedding
+   - Re-embedding status logged in `embedding_retry_log` table
+   - 5-minute retry window with exponential backoff (1s, 2s, 4s, 8s, 16s)
+
+### 7. Chunking Verification
+**Rule:** All node modifications must verify chunking status within 5 minutes.
+
+**Verification Protocol:**
+- After `updateNode` or `createNode`, query `chunks` table for `node_id`
+- If `chunk_status != "chunked"` after 5 minutes, log failure and flag node
+- Automated cleanup script runs every 6 hours to retry failed chunks
+- Maximum 3 retry attempts per node before escalation to human
+
+### 8. Graph Health Monitoring
+**Rule:** Health dashboard (Node #74) must reflect real-time graph status.
+
+**Dashboard Requirements:**
+- Total nodes, edges, orphans, stale nodes, chunk errors
+- Embedding service health status
+- Last successful embedding attempt
+- Alert thresholds:
+  - Orphan rate > 40%: Warning
+  - Stale node rate > 50%: Critical
+  - Chunk error rate > 30%: Critical
+  - Embedding service down: Critical (immediate alert)
+
+## Operational Procedures
+
+### Daily Maintenance (Automated)
+1. **Staleness Check**: Identify nodes past their threshold
+2. **Orphan Detection**: Flag nodes with 0 edges
+3. **Chunk Verification**: Retry failed chunks, log errors
+4. **Health Update**: Refresh Node #74 dashboard
+
+### Weekly Maintenance (Human Review)
+1. **Review Pending Nodes**: Examine flagged nodes
+2. **Edge Optimization**: Connect related orphaned nodes
+3. **Archive Cleanup**: Remove nodes past 15-day review period
+4. **Embedding Audit**: Verify all nodes have valid embeddings
+
+### Emergency Recovery
+1. **Embedding Service Down**: 
+   - Suspend node creation
+   - Alert all agents
+   - Investigate root cause (check `192.168.68.65:8080`)
+2. **Database Corruption**:
+   - Restore from latest PBS backup
+   - Verify chunk integrity
+   - Re-run embedding for affected nodes
+3. **Mass Orphan Creation**:
+   - Identify source agent/namespace
+   - Review recent changes
+   - Reconnect or archive affected nodes
+
+## Compliance & Enforcement
+
+### Audit Schedule
+- **Daily**: Automated health checks
+- **Weekly**: Human review of review_pending nodes
+- **Monthly**: Comprehensive graph audit (full schema validation)
+- **Quarterly**: Contract review and threshold adjustment
+
+### Violation Consequences
+- **First**: Alert to responsible agent
+- **Second**: Node placed in `review_pending` state
+- **Third**: Agent access suspended until remediation
+- **Fourth**: Escalation to human (Kwame)
+
+### Metrics for Success
+- Orphan rate: < 10%
+- Stale node rate: < 20%
+- Chunk error rate: < 5%
+- Embedding service uptime: > 99.9%
+- Node creation verification: 100%
+
+## Implementation Notes
+
+### Database Schema Requirements
+- `nodes` table: Standard fields plus `embedding_status`, `chunk_status`, `last_embedding_attempt`
+- `chunks` table: Must track `chunk_status` and `embedding_status`
+- `embedding_retry_log` table: Track retry attempts for failed chunks
+- `node_state_history` table: Log state transitions for audit trail
+
+### Cron Job Requirements
+- `ra-h-health-check`: Daily (4h interval)
+- `ra-h-staleness-detection`: Daily
+- `ra-h-orphan-detection`: Daily
+- `ra-h-chunk-retry`: Every 6 hours
+- `ra-h-review-cleanup`: Weekly (15-day archive)
+
+### Agent Onboarding
+All new agents must:
+1. Read this contract
+2. Understand namespace responsibilities
+3. Know how to verify embedding status
+4. Know the alert escalation path
+
+---
+
+## Approval
+This contract is effective immediately upon approval by the primary custodian (Mumuni) and system owner (Kwame).
+
+**Effective Date:** July 10, 2026  
+**Review Date:** October 10, 2026  
+**Primary Custodian:** Mumuni 🦅  
+**System Owner:** Jerome Tabiri
+
+---
+
+*Contract Version: 1.0*  
+*Last Updated: July 10, 2026*  
+*Storage: `/root/.hermes/skills/ra-h-os-custodianship-contract.prose.md`*

scripts/agent-health-check.py

@@ -184,8 +184,8 @@ def check_agents():
             print(f"  ⬜ {name} (CT {ct}): cannot SSH — skip liveness check")
             continue
 
-        # Gateway process
-        pid = ssh(host, "pgrep -f 'hermes_cli.main gateway run' | head -1", user=user)
+        # Gateway process (exclude the infisical bash wrapper that contains the same string)
+        pid = ssh(host, "pgrep -f 'hermes_cli.main gateway run' | grep -v infisical | head -1", user=user)
         if not pid:
             print(f"  ❌ {name}: GATEWAY NOT RUNNING")
             FAIL.append(f"gateway-down:{name}")

zulip-adapter-lessons.prose.md

@@ -79,7 +79,7 @@ description: >
   `messages_processed` stalls.
 - **Root cause**: Agent's model config (`models.json` or `settings.json`) references a
   model ID that doesn't exist in LiteLLM's authorized model list. Example: `qwen3.6-35B-A3B`
-  configured but LiteLLM only exposes `ornith-1.0-35b` under that key. pi's session
+  configured but LiteLLM only exposes `strix-moe` (alias for qwen3.6-35B-udq4) under that key. pi's session
   workers emit 403 on first prompt, then never recover because the error doesn't trigger
   `agent_end` — worker stays `busy` and all subsequent messages pile up in the steer queue.
 - **Detection**: Compare `~/.pi/agent/models.json` model IDs against `curl -H "Authorization: Bearer <KEY>" http://192.168.68.116/v1/models` output. A stuck worker shows
@@ -88,7 +88,7 @@ description: >
   (2) Set `defaultModel` to `syslog-auto` (safe routing model). (3) Delete stale session
   JSONL files from `~/.pi/agent/sessions/zulip/`. (4) Restart PM2 process.
 - **Prevention**: Use `syslog-auto` as default model for all agents — it handles model
-  routing and fallback automatically. Direct model IDs (`ornith-1.0-35b`, etc.) should
+  routing and fallback automatically. Direct model IDs (`strix-moe`, etc.) should
   only be used when explicitly requested. Validate model IDs at agent setup time.
 - **Applies to**: pi extension (Tdunna CT111, fixed 2026-07-08), any agent using `syslog-harness` provider
 

zulip-health.prose.md

@@ -1,9 +1,9 @@
 ---
 kind: responsibility
 name: zulip-health
-description: Multi-platform health monitor for the Zulip messaging mesh spanning Platform A (Agent Zero Docker), Platform B (Hermes agents Tanko/Mumuni), and the Zulip bridge. Verifies bot registration, DM delivery, and cross-platform connectivity.
+description: Multi-platform health monitor for the Zulip messaging mesh spanning Platform A (Abiba pi), Platform B (Hermes agents Tanko/Mumuni/Koonimo/Koby), and Platform C (Agent Zero). Verifies bot registration, DM delivery, cross-platform connectivity, secret injection, and YAML config integrity.
 title: Zulip Mesh Health Monitor — Multi-Platform
-version: 3.0.0
+version: 3.1.0
 runtime_contract: 2
 agent: abiba
 ---
@@ -12,11 +12,15 @@ agent: abiba
 
 Monitors ALL Zulip-connected agents across three platforms (pi, Hermes, Agent Zero).
 Runs every 15 minutes in the background. Also triggers on session start.
+v3.1.0 adds Koonimo+Koby to Platform B, Infisical dependency checks, config YAML
+validation, stale PID/lock detection, Telegram adapter health, and the
+cli_agent_setup_mixin patch verification.
 
 ## Requires
 
 - **Zulip API key** for `abiba-bot@chat.sysloggh.net` in `$ZULIP_API_KEY`
 - **SSH access** to Tanko (192.168.68.122), Mumuni (192.168.68.123), and Agent Zero Docker host (192.168.68.14)
+- **SSH access to amdpve (192.168.68.15)** for `pct exec` access to Koonimo (CT 113) and Koby (CT 111)
 - **PM2** on localhost for pi process management
 - **Network access** to `chat.sysloggh.net`, `localhost:9200`
 - **Write access** to `/root/zulip-health-monitor.log` and `/tmp/zulip-monitor-debounce`
@@ -49,12 +53,22 @@ Runs every 15 minutes in the background. Also triggers on session start.
     "zulip_state": "connected",
     "heartbeat_age_seconds": 45,
     "gateway_pid": 1234,
+    "infisical_present": true,
+    "config_valid": true,
+    "telegram_state": "connected",
+    "no_key_required_count": 0,
     "edit_fail_rate_pct": 0,
     "severity": "healthy"
   }
 }
 ```
 
+New fields in v3.1.0:
+- `infisical_present` — /usr/local/bin/infisical exists on the agent CT
+- `config_valid` — /root/.hermes/config.yaml passes YAML validation
+- `telegram_state` — Telegram adapter status from gateway_state.json
+- `no_key_required_count` — count of `no-key-required` in gateway logs
+
 ### Postconditions
 
 - Every platform is independently checked; one failure doesn't block others
@@ -81,13 +95,13 @@ Log as "unreachable" — don't treat as critical unless it persists for 3+ conse
 ## Streaming Support (2026-07-05)
 
 Zulip agents now support progressive message editing during agent generation.
-When a Hermes agent (Tanko, Mumuni) processes a message, the response is
-streamed in real-time via Zulip's `PATCH /api/v1/messages/{id}` API:
+When a Hermes agent (Tanko, Mumuni, Koonimo, Koby) processes a message, the
+response is streamed in real-time via Zulip's `PATCH /api/v1/messages/{id}` API:
 
 - Adapter implements `edit_message()` using `_api_patch()` helper
 - Gateway stream consumer progressively edits the Zulip message
 - User sees real-time agent thinking instead of waiting for full response
-- Verified: Tanko (CT 112) and Mumuni (CT 114) both have streaming active
+- Verified: Tanko (CT 112), Mumuni (CT 114), Koonimo (CT 113), Koby (CT 111)
 
 ### Verification
 ```bash
@@ -182,50 +196,217 @@ grep -a "Finalized\|Failed to finalize" /root/.pm2/logs/abiba-zulip-out.log | ta
 | `last_error` set | Log and monitor |
 | Crash loop >10/h | Alert user |
 
-### Step 3: Platform B — Hermes (Tanko .122, Mumuni .123)
+### Step 3: Platform B — Hermes (Tanko .122, Mumuni .123, Koonimo .114, Koby .129)
+
+Platform B now monitors four Hermes agents:
+- Tanko (CT 112, 192.168.68.122) — Zulip + Telegram
+- Mumuni (CT 114, 192.168.68.123) — Zulip + Telegram + Email
+- Koonimo (CT 113, 192.168.68.114, hostname "baggy") — Zulip + Telegram
+- Koby (CT 111, 192.168.68.129, hostname "tdunna") — Zulip + Telegram
+
+SSH access: Koonimo is reachable at .114; Koby has no direct SSH. Use `pct exec`
+from amdpve as the primary access method for both:
+```bash
+ssh root@192.168.68.15 "pct exec 113 -- <command>"   # Koonimo (or ssh .114)
+ssh root@192.168.68.15 "pct exec 111 -- <command>"   # Koby (pct exec only)
+```
 
 **B1: Gateway State**
 
 ```bash
 ssh root@192.168.68.122 "cat ~/.hermes/gateway_state.json"
 ssh root@192.168.68.123 "cat ~/.hermes/gateway_state.json"
+ssh root@192.168.68.15 "pct exec 113 -- cat /root/.hermes/gateway_state.json"
+ssh root@192.168.68.15 "pct exec 111 -- cat /root/.hermes/gateway_state.json"
 ```
 
-Check `platforms.zulip.state`: `connected` ✅ | `disconnected` ❌ | `error` ❌ | missing → not installed.
+Check `platforms.zulip.state`: `connected` ✅ | `disconnected` ❌ | `error` ❌.
+
+**B1.5: Infisical Dependency Check**
+
+```bash
+ssh root@<CT> "test -f /usr/local/bin/infisical && echo OK || echo MISSING"
+# pct exec variant for Koonimo/Koby:
+ssh root@192.168.68.15 "pct exec 113 -- test -f /usr/local/bin/infisical && echo OK || echo MISSING"
+ssh root@192.168.68.15 "pct exec 111 -- test -f /usr/local/bin/infisical && echo OK || echo MISSING"
+```
+
+If MISSING → flag `infisical_present: false`, note as degraded — gateway cannot
+auto-start on reboot without the infisical binary.
 
 **B2: Agent Process**
 
 ```bash
 ssh root@<CT> "ps aux | grep 'gateway run' | grep -v grep"
+# pct exec variant:
+ssh root@192.168.68.15 "pct exec 113 -- ps aux | grep 'gateway run' | grep -v grep"
+ssh root@192.168.68.15 "pct exec 111 -- ps aux | grep 'gateway run' | grep -v grep"
 ```
 
-Gateway PID should exist with uptime > 60s.
+Gateway PID should exist with uptime > 60s. Check for stale PIDs:
+- `gateway.pid` and `gateway.lock` files that reference a dead process
+- Multiple gateway processes (duplicate PIDs)
+
+**B2.5: Config YAML Validation**
+
+```bash
+ssh root@<CT> "python3 -c 'import yaml; yaml.safe_load(open(\"/root/.hermes/config.yaml\"))' 2>&1"
+# pct exec variant:
+ssh root@192.168.68.15 "pct exec 113 -- python3 -c 'import yaml; yaml.safe_load(open(\"/root/.hermes/config.yaml\"))' 2>&1"
+ssh root@192.168.68.15 "pct exec 111 -- python3 -c 'import yaml; yaml.safe_load(open(\"/root/.hermes/config.yaml\"))' 2>&1"
+```
+
+Expected: no output (clean parse). If parse fails → flag `config_valid: false`,
+degraded — gateway is running on stale in-memory config.
+
+Check specifically for:
+- Stray `api_key: sk-...` lines indented under `api_key_env` entries in
+  `custom_providers` section (hardcoded keys violate hermes-key-enforcement)
+- Indentation errors in `custom_providers`, `auxiliary`, or `compression` blocks
 
 **B3: Heartbeat Verification**
 
 ```bash
 ssh root@<CT> "grep Heartbeat ~/.hermes/logs/agent.log | tail -3"
+# pct exec variant:
+ssh root@192.168.68.15 "pct exec 113 -- grep Heartbeat /root/.hermes/logs/agent.log | tail -3"
+ssh root@192.168.68.15 "pct exec 111 -- grep Heartbeat /root/.hermes/logs/agent.log | tail -3"
 ```
 
 Expected: recent heartbeat (within 5 min), `polls=N` incrementing.
 Silence > 300s → warning. Silence > 600s → critical.
 
+**B3.5: Stale PID/Lock Detection**
+
+Before any restart action, check for stale pid/lock files:
+
+```bash
+ssh root@<CT> "ls -la /root/.hermes/gateway.pid /root/.hermes/gateway.lock 2>/dev/null"
+# pct exec variant:
+ssh root@192.168.68.15 "pct exec 113 -- ls -la /root/.hermes/gateway.pid /root/.hermes/gateway.lock 2>/dev/null"
+ssh root@192.168.68.15 "pct exec 111 -- ls -la /root/.hermes/gateway.pid /root/.hermes/gateway.lock 2>/dev/null"
+```
+
+If gateway process is dead (no PID) but pid/lock files exist:
+```bash
+ssh root@<CT> "rm -f /root/.hermes/gateway.pid /root/.hermes/gateway.lock"
+# pct exec variant:
+ssh root@192.168.68.15 "pct exec 113 -- rm -f /root/.hermes/gateway.pid /root/.hermes/gateway.lock"
+ssh root@192.168.68.15 "pct exec 111 -- rm -f /root/.hermes/gateway.pid /root/.hermes/gateway.lock"
+```
+
+Pid/lock files blocking restart → clear them before restart attempt.
+
 **B4: Response Delivery**
 
 ```bash
 ssh root@<CT> "grep -E 'Finalized|Failed to finalize|Replied to' ~/.hermes/logs/agent.log | tail -10"
+# pct exec variant for Koonimo/Koby:
+ssh root@192.168.68.15 "pct exec 113 -- grep -E 'Finalized|Failed to finalize|Replied to' /root/.hermes/logs/agent.log | tail -10"
+ssh root@192.168.68.15 "pct exec 111 -- grep -E 'Finalized|Failed to finalize|Replied to' /root/.hermes/logs/agent.log | tail -10"
 ```
 
 > 50% fail rate → critical.
 
+**B4.5: LiteLLM Key Injection Verification**
+
+Check gateway logs for `no-key-required` failure pattern (indicates the
+cli_agent_setup_mixin.py patch is missing):
+
+```bash
+ssh root@<CT> "grep -c 'no-key-required' /root/.hermes/logs/gateway.log 2>/dev/null || echo 0"
+# pct exec variant for Koonimo/Koby:
+ssh root@192.168.68.15 "pct exec 113 -- grep -c 'no-key-required' /root/.hermes/logs/gateway.log 2>/dev/null || echo 0"
+ssh root@192.168.68.15 "pct exec 111 -- grep -c 'no-key-required' /root/.hermes/logs/gateway.log 2>/dev/null || echo 0"
+```
+
+If > 0 → flag `no_key_required_count: <count>`, note as degraded — provider
+requests silently fall back to `no-key-required` when LITELLM_API_KEY env var
+resolves empty.
+
+**B5: Telegram Adapter Health**
+
+Check Telegram connectivity in gateway state or logs:
+
+```bash
+# From gateway_state.json (all agents):
+ssh root@<CT> "cat ~/.hermes/gateway_state.json | python3 -c 'import json,sys;d=json.load(sys.stdin);print(d[\"platforms\"].get(\"telegram\",{}).get(\"state\",\"missing\"))'"
+# pct exec variant for Koonimo/Koby (cat the file; read platforms.telegram.state):
+ssh root@192.168.68.15 "pct exec 113 -- cat /root/.hermes/gateway_state.json"
+ssh root@192.168.68.15 "pct exec 111 -- cat /root/.hermes/gateway_state.json"
+# From logs (check for stuck DNS resolution):
+ssh root@<CT> "grep -E 'Telegram.*Connecting|Telegram.*Connected|attempt 1/8' /root/.hermes/logs/gateway.log | tail -5"
+ssh root@192.168.68.15 "pct exec 113 -- grep -E 'Telegram.*Connecting|Telegram.*Connected|attempt 1/8' /root/.hermes/logs/gateway.log | tail -5"
+ssh root@192.168.68.15 "pct exec 111 -- grep -E 'Telegram.*Connecting|Telegram.*Connected|attempt 1/8' /root/.hermes/logs/gateway.log | tail -5"
+```
+
+Telegram states: `connected` ✅ | `disconnected` ❌ | `retrying` ⚠️ | `fatal` ❌ | `paused` ⚠️
+
+If stuck on "attempt 1/8" for > 60s → flag Telegram as degraded (Zulip may
+still be fine — do NOT treat as Zulip outage).
+
+**B6: cli_agent_setup_mixin.py Patch Verification**
+
+Check whether the `no-key-required` fallback string exists without the
+LiteLLM-specific guard (only needed when LiteLLM key injection failures are
+suspected). A bare count of the fallback string cannot distinguish a guarded
+occurrence from an unguarded one, so count both the fallback string and the
+LiteLLM guard token:
+
+```bash
+ssh root@<CT> "f=\$(grep -c 'no-key-required' /usr/local/lib/hermes-agent/hermes_cli/cli_agent_setup_mixin.py 2>/dev/null || echo 0); g=\$(grep -c 'LITELLM_API_KEY' /usr/local/lib/hermes-agent/hermes_cli/cli_agent_setup_mixin.py 2>/dev/null || echo 0); echo fallback=\$f guard=\$g"
+# pct exec variant:
+ssh root@192.168.68.15 "pct exec 113 -- bash -c 'f=\$(grep -c no-key-required /usr/local/lib/hermes-agent/hermes_cli/cli_agent_setup_mixin.py 2>/dev/null || echo 0); g=\$(grep -c LITELLM_API_KEY /usr/local/lib/hermes-agent/hermes_cli/cli_agent_setup_mixin.py 2>/dev/null || echo 0); echo fallback=\$f guard=\$g'"
+ssh root@192.168.68.15 "pct exec 111 -- bash -c 'f=\$(grep -c no-key-required /usr/local/lib/hermes-agent/hermes_cli/cli_agent_setup_mixin.py 2>/dev/null || echo 0); g=\$(grep -c LITELLM_API_KEY /usr/local/lib/hermes-agent/hermes_cli/cli_agent_setup_mixin.py 2>/dev/null || echo 0); echo fallback=\$f guard=\$g'"
+```
+
+If `fallback > 0` and `guard == 0` → the fallback string is present without
+the LiteLLM-specific guard, so the patch is missing. If unsure, inspect each
+occurrence with `grep -n -B2 -A2 'no-key-required'` to confirm the guard
+wraps it.
+
 **Platform B Actions**
 
 | Condition | Action |
 |-----------|--------|
-| `zulip.state != "connected"` | `ssh root@<CT> "pkill -f 'gateway run'; sleep 2; hermes gateway restart"` |
-| No heartbeat in 10min | Same as above |
+| `zulip.state != "connected"` | Restart gateway (see B2 restart commands below) |
+| No heartbeat in 10min | Restart gateway |
 | `Failed to finalize` > 50% | Check PATCH API, Zulip server |
 | Response empty/short | Check A2A endpoint / LiteLLM model |
+| `infisical_present: false` | Flag as degraded — log and alert; do NOT auto-restart via the standard command (it cannot inject the key without infisical). Operator may use the Infisical-missing fallback restart below. |
+| `config_valid: false` | Flag as degraded — alert user, gateway running on stale config |
+| Stale pid/lock files detected | Clean files before restart |
+| `no_key_required_count > 0` | Flag as degraded — check LITELLM_API_KEY injection |
+| Telegram stuck on attempt 1/8 | Flag Telegram as degraded, no Zulip action needed |
+
+**Restart Commands**
+
+Standard restart (Infisical present):
+```bash
+ssh root@<CT> "pkill -f 'gateway run'; sleep 2; hermes gateway restart"
+# pct exec variant:
+ssh root@192.168.68.15 "pct exec 113 -- bash -c 'pkill -f \"gateway run\"; sleep 2; systemctl restart hermes-gateway'"
+ssh root@192.168.68.15 "pct exec 111 -- bash -c 'pkill -f \"gateway run\"; sleep 2; systemctl restart hermes-gateway'"
+```
+
+The mechanisms differ by design: Tanko/Mumuni launch the gateway through a
+wrapper loop, so the `hermes gateway restart` CLI is the correct entry point
+(it re-arms the wrapper). Koonimo/Koby run the gateway as a systemd unit
+(`hermes-gateway.service`), so `systemctl restart hermes-gateway` is the
+correct entry point under `pct exec`. Do not swap the two — using the CLI on
+Koonimo/Koby would bypass the unit, and using `systemctl` on Tanko/Mumuni
+would miss the wrapper loop.
+
+Fallback: Infisical missing → start gateway directly from venv with env vars:
+```bash
+ssh root@<CT> "source /usr/local/lib/hermes-agent/venv/bin/activate && \
+  export LITELLM_API_KEY=\$(grep -E '^LITELLM_API_KEY=' /root/.hermes/.env | cut -d= -f2-) && \
+  export ZULIP_API_KEY=\$(grep -E '^ZULIP_API_KEY=' /root/.hermes/.env | cut -d= -f2-) && \
+  cd /root/.hermes && nohup hermes gateway run > logs/gateway-manual-start.log 2>&1 &"
+# pct exec variant:
+ssh root@192.168.68.15 "pct exec 113 -- bash -c 'source /usr/local/lib/hermes-agent/venv/bin/activate; export LITELLM_API_KEY=\$(grep -E ^LITELLM_API_KEY= /root/.hermes/.env | cut -d= -f2-); export ZULIP_API_KEY=\$(grep -E ^ZULIP_API_KEY= /root/.hermes/.env | cut -d= -f2-); cd /root/.hermes; nohup hermes gateway run > logs/gateway-manual-start.log 2>&1 &'"
+ssh root@192.168.68.15 "pct exec 111 -- bash -c 'source /usr/local/lib/hermes-agent/venv/bin/activate; export LITELLM_API_KEY=\$(grep -E ^LITELLM_API_KEY= /root/.hermes/.env | cut -d= -f2-); export ZULIP_API_KEY=\$(grep -E ^ZULIP_API_KEY= /root/.hermes/.env | cut -d= -f2-); cd /root/.hermes; nohup hermes gateway run > logs/gateway-manual-start.log 2>&1 &'"
+```
 
 ### Step 4: Platform C — Agent Zero (kagentz, CT 105 via Docker host .14)
 
@@ -278,7 +459,7 @@ Expected: task ID with "working" status. Poll for completion with `tasks/get`.
 
 Check each agent's log for excessive bot-to-bot chatter:
 - Abiba: `Skipped.*bot msgs` count
-- Tanko/Mumuni: Repeated DM exchanges between bots
+- Tanko/Mumuni/Koonimo/Koby: Repeated DM exchanges between bots
 - kagentz: Adapter log for bot DMs being processed
 
 If any bot processes >50 bot-originated messages in 15min → warning.
@@ -301,6 +482,14 @@ Track via `/tmp/zulip-monitor-debounce` (unix timestamp of last restart).
 
 ## History
 
+### v3.1.0 (2026-07-23) — Koonimo Outage Lessons
+
+Added Koonimo (CT 113) and Koby (CT 111) to Platform B monitoring.
+Added Infisical dependency check, config YAML validation, stale PID/lock
+detection, Telegram adapter health, LiteLLM key injection verification, and
+cli_agent_setup_mixin.py patch verification. Updated restart commands with
+Infisical-missing fallback path.
+
 ### Gen 5 (2026-07-02) — Rate Limit Death Spiral Fix
 
 **Root Cause**: Proactive Queue Rotation at 25 min triggered queue re-registration every cycle. Each re-registration + retry loop (3 attempts) + monitor restart = 8-12 API calls per cycle. Combined with monitor's own API calls (server check, stream alerts), `abiba-bot` hit Zulip's rate limit (429 RATE_LIMIT_HIT). Each restart reset the cycle, creating a death spiral: 111 restarts in 24 hours.

zulip-resilience-v3.prose.md

@@ -0,0 +1,476 @@
+---
+kind: responsibility
+name: zulip-resilience-v3
+description: >
+  Rewrite the pi Zulip gateway with production-grade resilience patterns drawn from
+  Zulip's own event system docs (queue lifecycle, heartbeat monitoring, BAD_EVENT_QUEUE_ID
+  handling, idle_queue_timeout) and battle-tested Node.js resilience patterns
+  (circuit breaker, exponential backoff with jitter, bulkhead isolation, supervisor watchdog).
+replaces: zulip-self-heal (retired)
+agent: abiba
+triggers:
+  - "/zulip self-heal v3"
+  - "zulip stopped responding"
+  - "PM2 abiba-zulip crashed"
+---
+
+# Zulip Gateway v3 — Production Resilience
+
+## Architecture Overview
+
+The current v2 gateway (`/root/.pi/agent/extensions/zulip/index.js`) has three structural
+weaknesses that cause repeated deaths:
+
+1. **No crash recovery** — uncaught errors kill the Node process, PM2 exhausts max_restarts
+2. **No circuit breaker** — 502/fetch-failed errors escalate to process death with no fallback
+3. **No queue lifecycle management** — doesn't use Zulip's documented heartbeat protocol or
+   idle_queue_timeout, so BAD_EVENT_QUEUE_ID errors cascade into crashes
+
+The v3 rewrite addresses all three, following patterns from:
+
+- [Zulip Events System docs](https://zulip.readthedocs.io/en/11.6/subsystems/events-system.html) —
+  queue registration, heartbeat, BAD_EVENT_QUEUE_ID recovery, call_on_each_event loop
+- [Zulip API: Get Events](https://zulip.com/api/get-events) — long-poll timeout, dont_block, event ack
+- [Circuit Breaker & Retry Patterns in Node.js 2026](https://1xapi.com/blog/resilient-api-circuit-breaker-bulkhead-retry-nodejs-2026) —
+  Opossum-based circuit breaker with fallback, retry with jitter, bulkhead isolation
+
+---
+
+## Maintains
+
+- `zulip-gateway`: { status: "healthy" | "degraded" | "down" }
+- `circuit-breaker`: { state: "CLOSED" | "OPEN" | "HALF_OPEN", failures, successes }
+- `queue-lifecycle`: { queue_id, last_event_id, idle_timeout, heartbeat_age }
+- `workers`: { count, busy, idle, stuck }
+- `supervisor`: { pid, last_check, health_failures }
+
+---
+
+## Detection Rules
+
+### Rule 1: Queue Expired (BAD_EVENT_QUEUE_ID)
+- **Detect**: Events API returns error with BAD_EVENT_QUEUE_ID in body
+- **Fix**: Call `POST /register` to create new queue, update queue_id and last_event_id
+- **Debounce**: If 3 re-registrations fail within 60s, escalate (server may be down)
+- **Ref**: Zulip docs: "Your software will need to handle that error condition by re-initializing itself"
+
+### Rule 2: Network Degradation (502/ECONNREFUSED/fetch failed)
+- **Detect**: Events API returns 502 or network error
+- **Circuit breaker**: Track failure rate over 10s rolling window
+  - CLOSED → OPEN: 50% failure rate with ≥5 requests
+  - OPEN → HALF_OPEN: After 30s reset timeout
+  - HALF_OPEN → CLOSED: Probe succeeds
+  - HALF_OPEN → OPEN: Probe fails
+- **While OPEN**: Log errors, skip events, notify user via DM: "⚠️ Zulip connection degraded — will retry in 30s"
+
+### Rule 3: Long-Poll Timeout (natural)
+- **Detect**: Events API response takes > `event_queue_longpoll_timeout_seconds`
+- **Not an error**: Server sends heartbeat events when no real events. Simply re-poll.
+
+### Rule 4: Worker Busy Timeout (>5 min)
+- **Detect**: Worker `busySince` exceeds 5 minutes
+- **Fix**: SIGKILL worker, send error DM, clean up pending replies
+
+### Rule 5: Process Crash (uncaught)
+- **Detect**: `uncaughtException` / `unhandledRejection` fires
+- **Fix**: Log → clear poll timer → attempt reconnect with backoff → if reconnect fails 3x, exit(1) and let PM2 restart
+
+### Rule 6: Supervisor Detects Router Stall
+- **Detect**: External supervisor (`zulip-watchdog`) polls `/health` every 30s. If 3 consecutive failures:
+- **Fix**: `pm2 restart abiba-zulip` gracefully (SIGTERM, drain workers, restart)
+
+---
+
+## Implementation Plan
+
+### Phase 1: Rewrite Router Core (circuit-breaker + queue lifecycle)
+
+Replace the poll loop in index.js with a resilience-first event loop:
+
+```js
+// Queue lifecycle (Zulip docs pattern)
+async function createOrRefreshQueue() {
+  // POST /register with event_types=["message"]
+  // Store: queueId, lastEventId, eventQueueLongpollTimeoutSeconds
+  // NEW: pass idle_queue_timeout parameter (Zulip 12.0+)
+}
+
+// Circuit breaker (Opossum pattern, implemented inline to avoid dependency)
+class ZulipCircuitBreaker {
+  constructor({ failureThreshold=0.5, resetTimeout=30000, volumeThreshold=5, windowMs=10000 }) {
+    this.state = "CLOSED"; // CLOSED | OPEN | HALF_OPEN
+    this.failures = 0;
+    this.successes = 0;
+    this.totalRequests = 0;
+    this.lastFailureTime = null;
+    this.openedAt = null;
+    this.failureThreshold = failureThreshold;
+    this.resetTimeout = resetTimeout;
+    this.volumeThreshold = volumeThreshold;
+    this.windowMs = windowMs;
+  }
+
+  async fire(fn) {
+    if (this.state === "OPEN") {
+      if (Date.now() - this.openedAt > this.resetTimeout) {
+        this.state = "HALF_OPEN";
+      } else {
+        throw new CircuitOpenError("Circuit is OPEN");
+      }
+    }
+    try {
+      const result = await fn();
+      this.onSuccess();
+      return result;
+    } catch (err) {
+      this.onFailure();
+      throw err;
+    }
+  }
+
+  onSuccess() {
+    this.successes++;
+    this.totalRequests++;
+    if (this.state === "HALF_OPEN") {
+      this.state = "CLOSED";
+      this.failures = 0;
+    }
+    // Reset counters periodically
+    if (this.totalRequests > this.volumeThreshold * 2) {
+      this.failures = Math.floor(this.failures / 2);
+      this.successes = Math.floor(this.successes / 2);
+      this.totalRequests = Math.floor(this.totalRequests / 2);
+    }
+  }
+
+  onFailure() {
+    this.failures++;
+    this.totalRequests++;
+    this.lastFailureTime = Date.now();
+    if (this.totalRequests >= this.volumeThreshold &&
+        this.failures / this.totalRequests >= this.failureThreshold) {
+      if (this.state !== "OPEN") {
+        this.state = "OPEN";
+        this.openedAt = Date.now();
+        console.error(`[zulip-ext] CIRCUIT BREAKER OPEN — ${this.failures}/${this.totalRequests} failures`);
+      }
+    }
+  }
+}
+
+// Retry with exponential backoff + jitter (from resilience patterns)
+async function withRetry(fn, { maxAttempts=3, baseDelay=200, maxDelay=10000, shouldRetry=()=>true }={}) {
+  let lastError;
+  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
+    try {
+      return await fn();
+    } catch (err) {
+      lastError = err;
+      if (attempt === maxAttempts || !shouldRetry(err)) throw err;
+      const delay = Math.min(baseDelay * Math.pow(2, attempt - 1), maxDelay);
+      const jitter = delay * (0.5 + Math.random() * 0.5); // 50-100% of delay
+      console.warn(`[zulip-ext] Retry ${attempt}/${maxAttempts} after ${Math.round(jitter)}ms: ${err.message.slice(0,80)}`);
+      await new Promise(r => setTimeout(r, jitter));
+    }
+  }
+  throw lastError;
+}
+
+// Resilience-first event loop (Zulip call_on_each_event pattern)
+async function resilientPollLoop() {
+  while (connected) {
+    try {
+      const events = await circuitBreaker.fire(() =>
+        withRetry(() => zulipQueue.poll(), {
+          maxAttempts: 2,
+          baseDelay: 1000,
+          shouldRetry: (err) => {
+            const msg = err.message || "";
+            return msg.includes("fetch failed") || msg.includes("ECONN") || msg.includes("network");
+          }
+        })
+      );
+
+      lastError = null;
+      retryCount = 0;
+
+      for (const ev of events) {
+        await processEvent(ev);
+      }
+
+      heartbeat();
+    } catch (err) {
+      const msg = err instanceof Error ? err.message : String(err);
+
+      if (msg.includes("BAD_EVENT_QUEUE_ID") || msg.includes("deregistered")) {
+        // Queue expired — re-register (Zulip docs pattern)
+        console.log(`[zulip-ext] Queue expired, re-registering… (${msg.slice(0,80)})`);
+        try {
+          zulipQueue = await createZulipQueue();
+          console.log(`[zulip-ext] Re-registered, new queue=${zulipQueue.queueId}`);
+        } catch (reRegErr) {
+          console.error(`[zulip-ext] Re-registration failed: ${reRegErr.message}`);
+          connected = false;
+          retryCount++;
+          const backoff = Math.min(5000 * Math.pow(2, retryCount), 300000);
+          console.log(`[zulip-ext] Full reconnect in ${Math.round(backoff/1000)}s`);
+          await new Promise(r => setTimeout(r, backoff));
+          await startPolling();
+          return;
+        }
+      } else if (err.name === "CircuitOpenError") {
+        // Circuit is open — skip this cycle, wait for HALF_OPEN
+        lastError = "circuit_open";
+        await new Promise(r => setTimeout(r, POLL_INTERVAL_MS));
+      } else {
+        lastError = msg;
+        retryCount++;
+        const backoff = Math.min(POLL_INTERVAL_MS * Math.pow(1.5, Math.min(retryCount, 8)), 60000);
+        console.error(`[zulip-ext] Poll error (retry ${retryCount}, backoff ${backoff}ms): ${msg}`);
+        await new Promise(r => setTimeout(r, backoff));
+      }
+    }
+  }
+}
+```
+
+### Phase 2: PM2 Hardening
+
+Create `/root/.pm2/ecosystem.config.cjs`:
+
+```js
+module.exports = {
+  apps: [
+    {
+      name: "abiba-zulip",
+      script: "/bin/pi",
+      args: "--mode rpc --session-id zulip-service",
+      env: {
+        ZULIP_ROLE: "router",
+        ZULIP_SITE: "https://chat.sysloggh.net",
+        ZULIP_EMAIL: "abiba-bot@chat.sysloggh.net",
+        ZULIP_API_KEY: process.env.ZULIP_API_KEY,
+        AGENT_NAME: "abiba",
+        AGENT_OWNER_EMAIL: "jerome@sysloggh.com",
+      },
+      max_restarts: 100,            // Up from default 10 — crash loops won't exhaust
+      min_uptime: "10s",            // Must survive 10s to count as "alive"
+      max_memory_restart: "500M",   // OOM protection
+      restart_delay: 5000,          // 5s between restarts
+      kill_timeout: 15000,          // 15s SIGTERM grace before SIGKILL
+      listen_timeout: 30000,        // 30s to bind health port
+      log_date_format: "YYYY-MM-DD HH:mm:ss Z",
+      error_file: "/root/.pm2/logs/abiba-zulip-error.log",
+      out_file: "/root/.pm2/logs/abiba-zulip-out.log",
+      merge_logs: true,
+      autorestart: true,
+      watch: false,
+      instances: 1,
+      exec_mode: "fork",
+    },
+    {
+      name: "zulip-watchdog",
+      script: "/root/.pi/agent/extensions/zulip/watchdog.js",
+      max_restarts: 10,
+      min_uptime: "3s",
+      restart_delay: 3000,
+      autorestart: true,
+    },
+  ],
+};
+```
+
+### Phase 3: Supervisor Watchdog
+
+Create `/root/.pi/agent/extensions/zulip/watchdog.js`:
+
+```js
+// External supervisor — monitors router health and restarts if stalled.
+// This is the pattern Hermes uses: an external process that can recover
+// the gateway even if the gateway process itself is hung (not just crashed).
+
+const HEALTH_URL = "http://127.0.0.1:9200/health";
+const CHECK_INTERVAL_MS = 30_000;
+const MAX_FAILURES = 3;
+
+let failures = 0;
+
+async function check() {
+  try {
+    const res = await fetch(HEALTH_URL, { signal: AbortSignal.timeout(5000) });
+    if (res.ok) {
+      const data = await res.json();
+      if (data.status === "ok" && data.zulip?.connected) {
+        if (failures > 0) {
+          console.log(`[watchdog] Router recovered after ${failures} failures`);
+        }
+        failures = 0;
+        return;
+      }
+    }
+    failures++;
+    console.warn(`[watchdog] Health check ${failures}/${MAX_FAILURES}: status not ok`);
+  } catch (err) {
+    failures++;
+    console.warn(`[watchdog] Health check ${failures}/${MAX_FAILURES}: ${err.message}`);
+  }
+
+  if (failures >= MAX_FAILURES) {
+    console.error(`[watchdog] ${MAX_FAILURES} consecutive failures — restarting abiba-zulip`);
+    const { execSync } = require("child_process");
+    try {
+      execSync("pm2 restart abiba-zulip", { timeout: 30000 });
+      console.log("[watchdog] Restart command sent");
+    } catch (e) {
+      console.error(`[watchdog] Restart failed: ${e.message}`);
+    }
+    failures = 0;
+    // Wait for restart to complete before checking again
+    await new Promise(r => setTimeout(r, 15000));
+  }
+}
+
+console.log("[watchdog] Zulip gateway supervisor started");
+setInterval(check, CHECK_INTERVAL_MS);
+check(); // Immediate first check
+```
+
+### Phase 4: Health Endpoint Enhancement
+
+Add circuit breaker stats to the existing health endpoint:
+
+```js
+// In /health response, add:
+"circuit_breaker": {
+  "state": circuitBreaker.state,
+  "failures": circuitBreaker.failures,
+  "successes": circuitBreaker.successes,
+  "total_requests": circuitBreaker.totalRequests,
+  "failure_rate": circuitBreaker.totalRequests > 0
+    ? (circuitBreaker.failures / circuitBreaker.totalRequests).toFixed(2)
+    : "0.00"
+}
+```
+
+---
+
+## Test Plan
+
+### Test 1: Queue Re-registration
+1. Manually delete the Zulip event queue via API
+2. Next poll should detect BAD_EVENT_QUEUE_ID
+3. Router should auto re-register within 1 poll cycle
+4. Verify: `/health` shows new queue_id, connected=true
+
+### Test 2: Circuit Breaker Trip
+1. Block Zulip server with iptables: `iptables -A OUTPUT -d 192.168.68.19 -j DROP`
+2. Router should detect failures, trip circuit after 5 failures
+3. `/health` should show circuit_breaker.state = "OPEN"
+4. Remove iptables rule
+5. Circuit should transition to HALF_OPEN → CLOSED within 60s
+6. Verify: messages processed after recovery
+
+### Test 3: Supervisor Recovery
+1. Kill the router process: `kill -STOP $(pm2 pid abiba-zulip)` (freeze, don't kill)
+2. Watchdog should detect 3 failed health checks in 90s
+3. Watchdog should execute `pm2 restart abiba-zulip`
+4. Verify: router back online, connected=true
+
+### Test 4: Worker Busy Timeout
+1. Send a message that triggers a long-running operation
+2. If worker stays busy >5 minutes, should receive SIGKILL
+3. User should receive error DM: "Response timed out"
+
+### Test 5: End-to-End Message
+1. Send DM "What time is it?" from Jerome
+2. Should receive response within 30s
+3. `/health` should show messages_processed incremented
+
+---
+
+## Rollback Plan
+
+If v3 causes issues:
+1. `pm2 delete abiba-zulip; pm2 delete zulip-watchdog`
+2. Restore v2 from git: `cd /root/.pi/agent/extensions/zulip && git checkout index.js`
+3. `pm2 resurrect` to reload previous process list
+4. Verify: `/health` returns ok
+
+Backup v2 before starting: `cp index.js index.js.v2-backup-$(date +%Y%m%d-%H%M%S)`
+
+---
+
+## Success Metrics
+
+| Metric | Current (v2) | Target (v3) |
+|--------|-------------|-------------|
+| Uptime between manual interventions | 1-3 days | 30+ days |
+| Crash recovery | Manual (PM2 resurrect) | Automatic (circuit breaker + supervisor) |
+| Queue expiry handling | Crash | Auto re-register |
+| Busy worker deadlock | Router death | Worker SIGKILL + error DM |
+| PM2 restart exhaustion | Yes (max_restarts=10) | No (max_restarts=100 + watchdog) |
+
+---
+
+## Incident Log — 2026-07-18 Fleet-Wide Audit
+
+### Fleet State After Audit
+
+| Agent | Platform | Zulip State | Issues Found | Fix Applied |
+|-------|----------|-------------|--------------|-------------|
+| **Abiba** | pi (CT 100) | ✅ Connected | API key missing from Infisical injection; poll timeout noise | Added .env fallback; AbortError treated as empty poll (no retry); poll timeout 65s→90s |
+| **Tanko** | Hermes (CT 112) | ✅ Connected | Gateway disconnected since Jul 11; watchdog restart didn't re-establish Zulip | Full gateway restart (kill wrapper, let infisical-gateway.sh respawn) |
+| **Mumuni** | Hermes (CT 114) | ✅ Connected | No issues found | None needed |
+
+### Key Fixes Applied
+
+**1. Abiba — Credential Fallback (L4 Pattern)**
+- Root cause: `zulip.api_key` in config.yaml is `""` (expected from Infisical). Infisical vault `ABIBA_ZULIP_API_KEY` wasn't being injected into the process environment.
+- Fix: Added `.env` file fallback at `/root/.pi/agent/extensions/zulip/.env` with known-working key, sourced before the Infisical `exec`.
+- Lesson: Per L4 from gpu-self-heal, Infisical is not always available — always keep a local `.env` fallback.
+
+**2. Abiba — Poll Timeout Handling**
+- Root cause: Zulip long-poll uses `AbortSignal.timeout(65000)`. Zulip's default `event_queue_longpoll_timeout_seconds` can exceed 65s. When the signal fires, an `AbortError` is thrown and caught by the circuit breaker as a failure.
+- Fix: Caught `AbortError` inside `poll()` and return empty array (no events) instead of throwing. Extended timeout to 90s to match Zulip server default.
+- Reference: [Zulip Events System — long-poll timeout](https://zulip.readthedocs.io/en/11.6/subsystems/events-system.html)
+
+**3. Tanko — Gateway Restart**
+- Root cause: Gateway process was running but Zulip platform stayed in "disconnected" state since Jul 11, 2026. The wrapper script (`infisical-gateway.sh`) restarts on crash but the gateway wasn't re-establishing Zulip on restart.
+- Fix: Killed gateway PID to trigger wrapper restart. New gateway (PID 331991) established Zulip connection successfully.
+
+### Fleet-Wide Zulip Health Metrics (as of 2026-07-18)
+
+| Metric | Value |
+|--------|-------|
+| Zulip server | ✅ HTTP 200 |
+| Agents connected | 3/3 (Abiba, Tanko, Mumuni) |
+| Abiba circuit breaker | CLOSED (0 failures) |
+| Abiba uptime | 2D (post-restart) |
+| Tanko gateway uptime | Ongoing |
+| Mumuni gateway uptime | Ongoing |
+| Watchdog status | ✅ Online (2D uptime) |
+
+### Hermes Agent Zulip Plugin Improvements
+
+Based on the audit, improvements that should be ported to all Hermes Zulip adapters:
+
+1. **Circuit breaker pattern** — Already in Abiba's pi extension. Hermes adapters should add the same CLOSED→OPEN→HALF_OPEN state machine with exponential backoff.
+2. **Credential fallback** — All Hermes agents use Infisical for credentials. Add `.env` local fallback per L4 pattern for `ZULIP_API_KEY`.
+3. **Queue re-registration** — Handle `BAD_EVENT_QUEUE_ID` with automatic re-registration instead of gateway restart.
+4. **Supervisor watchdog** — Hermes uses PM2 which auto-restarts on crash, but has no health-check watchdog. Add lightweight external health checks.
+5. **Streaming** — All agents have `streaming: true` in their zulip config. Verify `edit_message()` is implemented in each adapter.
+
+### Abiba pi Zulip Extension v2 — Implemented Resilience Summary
+
+| Feature | Status | Notes |
+|---------|--------|-------|
+| Circuit breaker | ✅ | CLOSED→OPEN→HALF_OPEN; 50% failure threshold; 30s reset timeout |
+| Retry with jitter | ✅ | 2 attempts, 200ms base, 50-100% jitter |
+| Queue lifecycle | ✅ | 10min idle_queue_timeout; BAD_EVENT_QUEUE_ID handling |
+| Crash prevention | ✅ | uncaughtException + unhandledRejection recovery |
+| Worker timeout | ✅ | 5min busy timeout → SIGKILL + error DM |
+| Health endpoint | ✅ | :9200 with circuit breaker metrics |
+| Echo prevention | ✅ | Dynamic bot user resolution |
+| Poll timeout (AbortError) | ✅ v2.1 | Normal timeout returns [] instead of error |
+| Credential fallback | ✅ v2.1 | .env file before Infisical exec |
+| Provider auto-fix | ✅ | Detects reasoning_content models, switches to compatible |