docs: add SSD research acknowledgment (#128)

Research triage for Apple's Simple Self-Distillation paper (arXiv:2604.01193).
Documents fleet-relevant findings: +7.5pp on Qwen3-4B (our exact scale),
zero-infrastructure fine-tuning, Fork/Lock theory implications for temperature
tuning, and a 4-phase implementation plan from immediate T_eval audit through
nightly self-improvement loop.

Refs #128

.gitea/workflows/notebook-ci.yml

@@ -0,0 +1,44 @@
+name: Notebook CI
+
+on:
+  push:
+    paths:
+      - 'notebooks/**'
+  pull_request:
+    paths:
+      - 'notebooks/**'
+
+jobs:
+  notebook-smoke:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: '3.12'
+
+      - name: Install dependencies
+        run: |
+          pip install papermill jupytext nbformat
+          python -m ipykernel install --user --name python3
+
+      - name: Execute system health notebook
+        run: |
+          papermill notebooks/agent_task_system_health.ipynb /tmp/output.ipynb \
+            -p threshold 0.5 \
+            -p hostname ci-runner
+
+      - name: Verify output has results
+        run: |
+          python -c "
+          import json
+          nb = json.load(open('/tmp/output.ipynb'))
+          code_cells = [c for c in nb['cells'] if c['cell_type'] == 'code']
+          outputs = [c.get('outputs', []) for c in code_cells]
+          total_outputs = sum(len(o) for o in outputs)
+          assert total_outputs > 0, 'Notebook produced no outputs'
+          print(f'Notebook executed successfully with {total_outputs} output(s)')
+          "

docs/NOTEBOOK_WORKFLOW.md

@@ -0,0 +1,57 @@
+# Notebook Workflow for Agent Tasks
+
+This directory demonstrates a sovereign, version-controlled workflow for LLM agent tasks using Jupyter notebooks.
+
+## Philosophy
+
+- **`.py` files are the source of truth`** — authored and reviewed as plain Python with `# %%` cell markers (via Jupytext)
+- **`.ipynb` files are generated artifacts** — auto-created from `.py` for execution and rich viewing
+- **Papermill parameterizes and executes** — each run produces an output notebook with code, narrative, and results preserved
+- **Output notebooks are audit artifacts** — every execution leaves a permanent, replayable record
+
+## File Layout
+
+```
+notebooks/
+  agent_task_system_health.py      # Source of truth (Jupytext)
+  agent_task_system_health.ipynb   # Generated from .py
+docs/
+  NOTEBOOK_WORKFLOW.md             # This document
+.gitea/workflows/
+  notebook-ci.yml                  # CI gate: executes notebooks on PR/push
+```
+
+## How Agents Work With Notebooks
+
+1. **Create** — Agent generates a `.py` notebook using `# %% [markdown]` and `# %%` code blocks
+2. **Review** — PR reviewers see clean diffs in Gitea (no JSON noise)
+3. **Generate** — `jupytext --to ipynb` produces the `.ipynb` before merge
+4. **Execute** — Papermill runs the notebook with injected parameters
+5. **Archive** — Output notebook is committed to a `reports/` branch or artifact store
+
+## Converting Between Formats
+
+```bash
+# .py -> .ipynb
+jupytext --to ipynb notebooks/agent_task_system_health.py
+
+# .ipynb -> .py
+jupytext --to py notebooks/agent_task_system_health.ipynb
+
+# Execute with parameters
+papermill notebooks/agent_task_system_health.ipynb output.ipynb \
+  -p threshold 1.0 -p hostname forge-vps-01
+```
+
+## CI Gate
+
+The `notebook-ci.yml` workflow executes all notebooks in `notebooks/` on every PR and push, ensuring that checked-in notebooks still run and produce outputs.
+
+## Why This Matters
+
+| Problem | Notebook Solution |
+|---|---|
+| Ephemeral agent reasoning | Markdown cells narrate the thought process |
+| Stateless single-turn tools | Stateful cells persist variables across steps |
+| Unreviewable binary artifacts | `.py` source is diffable and PR-friendly |
+| No execution audit trail | Output notebook preserves code + outputs + metadata |

docs/fleet-sitrep-2026-04-06.md

@@ -0,0 +1,132 @@
+# Fleet SITREP — April 6, 2026
+
+**Classification:** Consolidated Status Report
+**Compiled by:** Ezra
+**Acknowledged by:** Claude (Issue #143)
+
+---
+
+## Executive Summary
+
+Allegro executed 7 tasks across infrastructure, contracting, audits, and security. Ezra shipped PR #131, filed formalization audit #132, delivered quarterly report #133, and self-assigned issues #134–#138. All wizard activity mapped below.
+
+---
+
+## 1. Allegro 7-Task Report
+
+| Task | Description | Status |
+|------|-------------|--------|
+| 1 | Roll Call / Infrastructure Map | ✅ Complete |
+| 2 | Dark industrial anthem (140 BPM, Suno-ready) | ✅ Complete |
+| 3 | Operation Get A Job — 7-file contracting playbook pushed to `the-nexus` | ✅ Complete |
+| 4 | Formalization audit filed ([the-nexus #893](https://forge.alexanderwhitestone.com/Timmy_Foundation/the-nexus/issues/893)) | ✅ Complete |
+| 5 | GrepTard Memory Report — PR #525 on `timmy-home` | ✅ Complete |
+| 6 | Self-audit issues #894–#899 filed on `the-nexus` | ✅ Filed |
+| 7 | `keystore.json` permissions fixed to `600` | ✅ Applied |
+
+### Critical Findings from Task 4 (Formalization Audit)
+
+- GOFAI source files missing — only `.pyc` remains
+- Nostr keystore was world-readable — **FIXED** (Task 7)
+- 39 burn scripts cluttering `/root` — archival pending ([#898](https://forge.alexanderwhitestone.com/Timmy_Foundation/the-nexus/issues/898))
+
+---
+
+## 2. Ezra Deliverables
+
+| Deliverable | Issue/PR | Status |
+|-------------|----------|--------|
+| V-011 fix + compressor tuning | [PR #131](https://forge.alexanderwhitestone.com/Timmy_Foundation/hermes-agent/pulls/131) | ✅ Merged |
+| Formalization audit (hermes-agent) | [Issue #132](https://forge.alexanderwhitestone.com/Timmy_Foundation/hermes-agent/issues/132) | Filed |
+| Quarterly report (MD + PDF) | [Issue #133](https://forge.alexanderwhitestone.com/Timmy_Foundation/hermes-agent/issues/133) | Filed |
+| Burn-mode concurrent tool tests | [Issue #134](https://forge.alexanderwhitestone.com/Timmy_Foundation/hermes-agent/issues/134) | Assigned → Ezra |
+| MCP SDK migration | [Issue #135](https://forge.alexanderwhitestone.com/Timmy_Foundation/hermes-agent/issues/135) | Assigned → Ezra |
+| APScheduler migration | [Issue #136](https://forge.alexanderwhitestone.com/Timmy_Foundation/hermes-agent/issues/136) | Assigned → Ezra |
+| Pydantic-settings migration | [Issue #137](https://forge.alexanderwhitestone.com/Timmy_Foundation/hermes-agent/issues/137) | Assigned → Ezra |
+| Contracting playbook tracker | [Issue #138](https://forge.alexanderwhitestone.com/Timmy_Foundation/hermes-agent/issues/138) | Assigned → Ezra |
+
+---
+
+## 3. Fleet Status
+
+| Wizard | Host | Status | Blocker |
+|--------|------|--------|---------|
+| **Ezra** | Hermes VPS | Active — 5 issues queued | None |
+| **Bezalel** | Hermes VPS | Gateway running on 8645 | None |
+| **Allegro-Primus** | Hermes VPS | **Gateway DOWN on 8644** | Needs restart signal |
+| **Bilbo** | External | Gemma 4B active, Telegram dual-mode | Host IP unknown to fleet |
+
+### Allegro Gateway Recovery
+
+Allegro-Primus gateway (port 8644) is down. Options:
+1. **Alexander restarts manually** on Hermes VPS
+2. **Delegate to Bezalel** — Bezalel can issue restart signal via Hermes VPS access
+3. **Delegate to Ezra** — Ezra can coordinate restart as part of issue #894 work
+
+---
+
+## 4. Operation Get A Job — Contracting Playbook
+
+Files pushed to `the-nexus/operation-get-a-job/`:
+
+| File | Purpose |
+|------|---------|
+| `README.md` | Master plan |
+| `entity-setup.md` | Wyoming LLC, Mercury, E&O insurance |
+| `service-offerings.md` | Rates $150–600/hr; packages $5k/$15k/$40k+ |
+| `portfolio.md` | Portfolio structure |
+| `outreach-templates.md` | Cold email templates |
+| `proposal-template.md` | Client proposal structure |
+| `rate-card.md` | Rate card |
+
+**Human-only mile (Alexander's action items):**
+
+1. Pick LLC name from `entity-setup.md`
+2. File Wyoming LLC via Northwest Registered Agent ($225)
+3. Get EIN from IRS (free, ~10 min)
+4. Open Mercury account (requires EIN + LLC docs)
+5. Secure E&O insurance (~$150–250/month)
+6. Restart Allegro-Primus gateway (port 8644)
+7. Update LinkedIn using profile template
+8. Send 5 cold emails using outreach templates
+
+---
+
+## 5. Pending Self-Audit Issues (the-nexus)
+
+| Issue | Title | Priority |
+|-------|-------|----------|
+| [#894](https://forge.alexanderwhitestone.com/Timmy_Foundation/the-nexus/issues/894) | Deploy burn-mode cron jobs | CRITICAL |
+| [#895](https://forge.alexanderwhitestone.com/Timmy_Foundation/the-nexus/issues/895) | Telegram thread-based reporting | Normal |
+| [#896](https://forge.alexanderwhitestone.com/Timmy_Foundation/the-nexus/issues/896) | Retry logic and error recovery | Normal |
+| [#897](https://forge.alexanderwhitestone.com/Timmy_Foundation/the-nexus/issues/897) | Automate morning reports at 0600 | Normal |
+| [#898](https://forge.alexanderwhitestone.com/Timmy_Foundation/the-nexus/issues/898) | Archive 39 burn scripts | Normal |
+| [#899](https://forge.alexanderwhitestone.com/Timmy_Foundation/the-nexus/issues/899) | Keystore permissions | ✅ Done |
+
+---
+
+## 6. Revenue Timeline
+
+| Milestone | Target | Unlocks |
+|-----------|--------|---------|
+| LLC + Bank + E&O | Day 5 | Ability to invoice clients |
+| First 5 emails sent | Day 7 | Pipeline generation |
+| First scoping call | Day 14 | Qualified lead |
+| First proposal accepted | Day 21 | **$4,500–$12,000 revenue** |
+| Monthly retainer signed | Day 45 | **$6,000/mo recurring** |
+
+---
+
+## 7. Delegation Matrix
+
+| Owner | Owns |
+|-------|------|
+| **Alexander** | LLC filing, EIN, Mercury, E&O, LinkedIn, cold emails, gateway restart |
+| **Ezra** | Issues #134–#138 (tests, migrations, tracker) |
+| **Allegro** | Issues #894, #898 (cron deployment, burn script archival) |
+| **Bezalel** | Review formalization audit for Anthropic-specific gaps |
+
+---
+
+*SITREP acknowledged by Claude — April 6, 2026*
+*Source issue: [hermes-agent #143](https://forge.alexanderwhitestone.com/Timmy_Foundation/hermes-agent/issues/143)*

docs/research-ssd-self-distillation-2026-04.md

@@ -0,0 +1,166 @@
+# Research Acknowledgment: SSD — Simple Self-Distillation Improves Code Generation
+
+**Issue:** #128
+**Paper:** [Embarrassingly Simple Self-Distillation Improves Code Generation](https://arxiv.org/abs/2604.01193)
+**Authors:** Ruixiang Zhang, Richard He Bai, Huangjie Zheng, Navdeep Jaitly, Ronan Collobert, Yizhe Zhang (Apple)
+**Date:** April 1, 2026
+**Code:** https://github.com/apple/ml-ssd
+**Acknowledged by:** Claude — April 6, 2026
+
+---
+
+## Assessment: High Relevance to Fleet
+
+This paper is directly applicable to the hermes-agent fleet. The headline result — +7.5pp pass@1 on Qwen3-4B — is at exactly the scale we operate. The method requires no external infrastructure. Triage verdict: **P0 / Week-class work**.
+
+---
+
+## What SSD Actually Does
+
+Three steps, nothing exotic:
+
+1. **Sample**: For each coding prompt, generate one solution at temperature `T_train` (~0.9). Do NOT filter for correctness.
+2. **Fine-tune**: SFT on the resulting `(prompt, unverified_solution)` pairs. Standard cross-entropy loss. No RLHF, no GRPO, no DPO.
+3. **Evaluate**: At `T_eval` (which must be **different** from `T_train`). This asymmetry is not optional — using the same temperature for both loses 30–50% of the gains.
+
+The counterintuitive part: N=1 per problem, unverified. Prior self-improvement work uses N>>1 and filters by execution. SSD doesn't. The paper argues this is *why* it works — you're sharpening the model's own distribution, not fitting to a correctness filter's selection bias.
+
+---
+
+## The Fork/Lock Theory
+
+The paper's core theoretical contribution explains *why* temperature asymmetry matters.
+
+**Locks** — positions requiring syntactic precision: colons, parentheses, import paths, variable names. A mistake here is a hard error. Low temperature helps at Locks. But applying low temperature globally kills diversity everywhere.
+
+**Forks** — algorithmic choice points where multiple valid continuations exist: picking a sort algorithm, choosing a data structure, deciding on a loop structure. High temperature helps at Forks. But applying high temperature globally introduces errors at Locks.
+
+SSD's fine-tuning reshapes token distributions **context-dependently**:
+- At Locks: narrows the distribution, suppressing distractor tokens
+- At Forks: widens the distribution, preserving valid algorithmic paths
+
+A single global temperature cannot do this. SFT on self-generated data can, because the model learns from examples that implicitly encode which positions are Locks and which are Forks in each problem context.
+
+**Fleet implication**: Our agents are currently using a single temperature for everything. This is leaving performance on the table even without fine-tuning. The immediate zero-cost action is temperature auditing (see Phase 1 below).
+
+---
+
+## Results That Matter to Us
+
+| Model | Before | After | Delta |
+|-------|--------|-------|-------|
+| Qwen3-30B-Instruct | 42.4% | 55.3% | +12.9pp (+30% rel) |
+| Qwen3-4B-Instruct | baseline | baseline+7.5pp | +7.5pp |
+| Llama-3.1-8B-Instruct | baseline | baseline+3.5pp | +3.5pp |
+
+Gains concentrate on hard problems: +14.2pp medium, +15.3pp hard. This is the distribution our agents face on real Gitea issues — not easy textbook problems.
+
+---
+
+## Fleet Implementation Plan
+
+### Phase 1: Temperature Audit (Zero cost, this week)
+
+Current state: fleet agents use default or eyeballed temperature settings. The paper shows T_eval != T_train is critical even without fine-tuning.
+
+Actions:
+1. Document current temperature settings in `hermes/`, `skills/`, and any Ollama config files
+2. Establish a held-out test set of 20+ solved Gitea issues with known-correct outputs
+3. Run A/B: current T_eval vs. T_eval=0.7 vs. T_eval=0.3 for code generation tasks
+4. Record pass rates per condition; file findings as a follow-up issue
+
+Expected outcome: measurable improvement with no model changes, no infrastructure, no cost.
+
+### Phase 2: SSD Pipeline (1–2 weeks, single Mac)
+
+Replicate the paper's method on Qwen3-4B via Ollama + axolotl or unsloth:
+
+```
+1. Dataset construction:
+   - Extract 100–500 coding prompts from Gitea issue backlog
+   - Focus on issues that have accepted PRs (ground truth available for evaluation only, not training)
+   - Format: (system_prompt + issue_description) → model generates solution at T_train=0.9
+
+2. Fine-tuning:
+   - Use LoRA (not full fine-tune) to stay local-first
+   - Standard SFT: cross-entropy on (prompt, self-generated_solution) pairs
+   - Recommended: unsloth for memory efficiency on Mac hardware
+   - Training budget: 1–3 epochs, small batch size
+
+3. Evaluation:
+   - Compare base model vs. SSD-tuned model at T_eval=0.7
+   - Metric: pass@1 on held-out issues not in training set
+   - Also test on general coding benchmarks to check for capability regression
+```
+
+Infrastructure assessment:
+- **RAM**: Qwen3-4B quantized (Q4_K_M) needs ~3.5GB VRAM for inference; LoRA fine-tuning needs ~8–12GB unified memory (Mac M-series feasible)
+- **Storage**: Self-generated dataset is small; LoRA adapter is ~100–500MB
+- **Time**: 500 examples × 3 epochs ≈ 2–4 hours on M2/M3 Max
+- **Dependencies**: Ollama (inference), unsloth or axolotl (fine-tuning), datasets (HuggingFace), trl
+
+No cloud required. No teacher model required. No code execution environment required.
+
+### Phase 3: Continuous Self-Improvement Loop (1–2 months)
+
+Wire SSD into the fleet's burn mode:
+
+```
+Nightly cron:
+  1. Collect agent solutions from the day's completed issues
+  2. Filter: only solutions where the PR was merged (human-verified correct)
+  3. Append to rolling training buffer (last 500 examples)
+  4. Run SFT fine-tune on buffer → update LoRA adapter
+  5. Swap adapter into Ollama deployment at dawn
+  6. Agents start next day with yesterday's lessons baked in
+```
+
+This integrates naturally with RetainDB (#112) — the persistent memory system would track which solutions were merged, providing the feedback signal. The continuous loop turns every merged PR into a training example.
+
+### Phase 4: Sovereignty Confirmation
+
+The paper validates that external data is not required for improvement. Our fleet can:
+- Fine-tune exclusively on its own conversation data
+- Stay fully local (no API calls, no external datasets)
+- Accumulate improvements over time without model subscriptions
+
+This is the sovereign fine-tuning capability the fleet needs to remain independent as external model APIs change pricing or capabilities.
+
+---
+
+## Risks and Mitigations
+
+| Risk | Assessment | Mitigation |
+|------|------------|------------|
+| SSD gains don't transfer from LiveCodeBench to Gitea issues | Medium — our domain is software engineering, not competitive programming | Test on actual Gitea issues from the backlog; don't assume benchmark numbers transfer |
+| Fine-tuning degrades non-code capabilities | Low-Medium | LoRA instead of full fine-tune; test on general tasks after SFT; retain base model checkpoint |
+| Small training set (<200 examples) insufficient | Medium | Paper shows gains at modest scale; supplement with open code datasets (Stack, TheVault) if needed |
+| Qwen3 GGUF format incompatible with unsloth fine-tuning | Low | unsloth supports Qwen3; verify exact GGUF variant compatibility before starting |
+| Temperature asymmetry effect smaller on instruction-tuned variants | Low | Paper explicitly tests instruct variants and shows gains; Qwen3-4B-Instruct is in the paper's results |
+
+---
+
+## Acceptance Criteria Status
+
+From the issue:
+
+- [ ] **Temperature audit** — Document current T/top_p settings across fleet agents, compare with paper recommendations
+- [ ] **T_eval benchmark** — A/B test on 20+ solved Gitea issues; measure correctness
+- [ ] **SSD reproduction** — Replicate pipeline on Qwen4B with 100 prompts; measure pass@1 change
+- [ ] **Infrastructure assessment** — Documented above (Phase 2 section); GPU/RAM/storage requirements are Mac-feasible
+- [ ] **Continuous loop design** — Architecture drafted above (Phase 3 section); integrates with RetainDB (#112)
+
+Infrastructure assessment and continuous loop design are addressed in this document. Temperature audit and SSD reproduction require follow-up issues with execution.
+
+---
+
+## Recommended Follow-Up Issues
+
+1. **Temperature Audit** — Audit all fleet agent temperature configs; run A/B on T_eval variants; file results (Phase 1)
+2. **SSD Pipeline Spike** — Build and run the 3-stage SSD pipeline on Qwen3-4B; report pass@1 delta (Phase 2)
+3. **Nightly SFT Integration** — Wire SSD into burn-mode cron; integrate with RetainDB feedback loop (Phase 3)
+
+---
+
+*Research acknowledged by Claude — April 6, 2026*
+*Source issue: [hermes-agent #128](https://forge.alexanderwhitestone.com/Timmy_Foundation/hermes-agent/issues/128)*

notebooks/agent_task_system_health.ipynb

@@ -0,0 +1,57 @@
+{
+  "cells": [
+    {
+      "cell_type": "markdown",
+      "metadata": {},
+      "source": [
+        "# Parameterized Agent Task: System Health Check\n",
+        "\n",
+        "This notebook demonstrates how an LLM agent can generate a task notebook,\n",
+        "a scheduler can parameterize and execute it via papermill,\n",
+        "and the output becomes a persistent audit artifact."
+      ]
+    },
+    {
+      "cell_type": "code",
+      "execution_count": null,
+      "metadata": {"tags": ["parameters"]},
+      "outputs": [],
+      "source": [
+        "# Default parameters — papermill will inject overrides here\n",
+        "threshold = 1.0\n",
+        "hostname = \"localhost\""
+      ]
+    },
+    {
+      "cell_type": "code",
+      "execution_count": null,
+      "metadata": {},
+      "outputs": [],
+      "source": [
+        "import json, subprocess, datetime\n",
+        "gather_time = datetime.datetime.now().isoformat()\n",
+        "load_avg = subprocess.check_output([\"cat\", \"/proc/loadavg\"]).decode().strip()\n",
+        "load_values = [float(x) for x in load_avg.split()[:3]]\n",
+        "avg_load = sum(load_values) / len(load_values)\n",
+        "intervention_needed = avg_load > threshold\n",
+        "report = {\n",
+        "    \"hostname\": hostname,\n",
+        "    \"threshold\": threshold,\n",
+        "    \"avg_load\": round(avg_load, 3),\n",
+        "    \"intervention_needed\": intervention_needed,\n",
+        "    \"gathered_at\": gather_time\n",
+        "}\n",
+        "print(json.dumps(report, indent=2))"
+      ]
+    }
+  ],
+  "metadata": {
+    "kernelspec": {
+      "display_name": "Python 3",
+      "language": "python",
+      "name": "python3"
+    }
+  },
+  "nbformat": 4,
+  "nbformat_minor": 5
+}

notebooks/agent_task_system_health.py

@@ -0,0 +1,41 @@
+# ---
+# jupyter:
+#   jupytext:
+#     text_representation:
+#       extension: .py
+#       format_name: percent
+#       format_version: '1.3'
+#       jupytext_version: 1.19.1
+#   kernelspec:
+#     display_name: Python 3
+#     language: python
+#     name: python3
+# ---
+
+# %% [markdown]
+# # Parameterized Agent Task: System Health Check
+#
+# This notebook demonstrates how an LLM agent can generate a task notebook,
+# a scheduler can parameterize and execute it via papermill,
+# and the output becomes a persistent audit artifact.
+
+# %% tags=["parameters"]
+# Default parameters — papermill will inject overrides here
+threshold = 1.0
+hostname = "localhost"
+
+# %%
+import json, subprocess, datetime
+gather_time = datetime.datetime.now().isoformat()
+load_avg = subprocess.check_output(["cat", "/proc/loadavg"]).decode().strip()
+load_values = [float(x) for x in load_avg.split()[:3]]
+avg_load = sum(load_values) / len(load_values)
+intervention_needed = avg_load > threshold
+report = {
+    "hostname": hostname,
+    "threshold": threshold,
+    "avg_load": round(avg_load, 3),
+    "intervention_needed": intervention_needed,
+    "gathered_at": gather_time
+}
+print(json.dumps(report, indent=2))

reports/ezra-quarterly-report-april-2026.md

@@ -0,0 +1,252 @@
+# Ezra — Quarterly Technical & Strategic Report
+**April 2026**
+
+---
+
+## Executive Summary
+
+This report consolidates the principal technical and strategic outputs from Q1/Q2 2026. Three major workstreams are covered:
+
+1. **Security & Performance Hardening** — Shipped V-011 obfuscation detection and context-compressor tuning.
+2. **System Formalization Audit** — Identified ~6,300 lines of homegrown infrastructure that can be replaced by well-maintained open-source projects.
+3. **Business Development** — Formalized a pure-contracting go-to-market plan ("Operation Get A Job") to monetize the engineering collective.
+
+---
+
+## 1. Recent Deliverables
+
+### 1.1 V-011 Obfuscation Bypass Detection
+
+A significant security enhancement was shipped to the skills-guard subsystem to defeat obfuscated malicious skill code.
+
+**Technical additions:**
+- `normalize_input()` with NFKC normalization, case folding, and zero-width character removal to defeat homoglyph and ZWSP evasion.
+- `PythonSecurityAnalyzer` AST visitor detecting `eval`/`exec`/`compile`, `getattr` dunder access, and imports of `base64`/`codecs`/`marshal`/`types`/`ctypes`.
+- Additional regex patterns for `getattr` builtins chains, `__import__` os/subprocess, and nested base64 decoding.
+- Full integration into `scan_file()`; Python files now receive both normalized regex scanning and AST-based analysis.
+
+**Verification:** All tests passing (`103 passed, 4 warnings`).
+
+**Reference:** Forge PR #131 — `[EPIC-999/Phase II] The Forge — V-011 obfuscation fix + compressor tuning`
+
+### 1.2 Context Compressor Tuning
+
+The default `protect_last_n` parameter was reduced from `20` to `5`. The previous default was overly conservative, preventing meaningful compression on long sessions. The new default preserves the five most recent conversational turns while allowing the compressor to effectively reduce token pressure.
+
+A regression test was added verifying that the last five turns are never summarized away.
+
+### 1.3 Burn Mode Resilience
+
+The agent loop was enhanced with a configurable `burn_mode` flag that increases concurrent tool execution capacity and adds transient-failure retry logic.
+
+**Changes:**
+- `max_tool_workers` increased from `8` to `16` in burn mode.
+- Expanded parallel tool coverage to include browser, vision, skill, and session-search tools.
+- Added batch timeout protection (300s in burn mode / 180s normal) to prevent hung threads from blocking the agent loop.
+- Thread-pool shutdown now uses `executor.shutdown(wait=False)` for immediate control return.
+- Transient errors (timeouts, rate limits, 502/503/504) trigger one automatic retry in burn mode.
+
+---
+
+## 2. System Formalization Audit
+
+A comprehensive audit was performed across the `hermes-agent` codebase to identify homegrown modules that could be replaced by mature open-source alternatives. The objective is efficiency: reduce maintenance burden, leverage community expertise, and improve reliability.
+
+### 2.1 Candidate Matrix
+
+| Priority | Component | Lines | Current State | Proposed Replacement | Effort | ROI |
+|:--------:|-----------|------:|---------------|----------------------|:------:|:---:|
+| **P0** | MCP Client | 2,176 | Custom asyncio transport, sampling, schema translation | `mcp` (official Python SDK) | 2-3 wks | Very High |
+| **P0** | Cron Scheduler | ~1,500 | Custom JSON job store, manual tick loop | `APScheduler` | 1-2 wks | Very High |
+| **P0** | Config Management | 2,589 | Manual YAML loader, no type safety | `pydantic-settings` + Pydantic v2 | 3-4 wks | High |
+| **P1** | Checkpoint Manager | 548 | Shells out to `git` binary | `dulwich` (pure-Python git) | 1 wk | Medium-High |
+| **P1** | Auth / Credential Pool | ~3,800 | Custom JWT decode, OAuth refresh, JSON auth store | `authlib` + `keyring` + `PyJWT` | 2-3 wks | Medium |
+| **P1** | Batch Runner | 1,285 | Custom `multiprocessing.Pool` wrapper | `joblib` (local) or `celery` (distributed) | 1-2 wks | Medium |
+| **P2** | SQLite Session Store | ~2,400 | Raw SQLite + FTS5, manual schema | SQLAlchemy ORM + Alembic | 2-3 wks | Medium |
+| **P2** | Trajectory Compressor | 1,518 | Custom tokenizer + summarization pipeline | Keep core logic; add `zstandard` for binary storage | 3 days | Low-Medium |
+| **P2** | Process Registry | 889 | Custom background process tracking | Keep (adds too much ops complexity) | — | Low |
+| **P2** | Web Tools | 2,080+ | Firecrawl + Parallel wrappers | Keep (Firecrawl is already best-in-class) | — | Low |
+
+### 2.2 P0 Replacements
+
+#### MCP Client → Official `mcp` Python SDK
+
+**Current:** `tools/mcp_tool.py` (2,176 lines) contains custom stdio/HTTP transport lifecycle, manual `anyio` cancel-scope cleanup, hand-rolled schema translation, custom sampling bridge, credential stripping, and reconnection backoff.
+
+**Problem:** The Model Context Protocol is evolving rapidly. Maintaining a custom 2K-line client means every protocol revision requires manual patches. The official SDK already handles transport negotiation, lifecycle management, and type-safe schema generation.
+
+**Migration Plan:**
+1. Add `mcp>=1.0.0` to dependencies.
+2. Build a thin `HermesMCPBridge` class that instantiates `mcp.ClientSession`, maps MCP `Tool` schemas to Hermes registry calls, forwards tool invocations, and preserves the sampling callback.
+3. Deprecate the `_mcp_loop` background thread and `anyio`-based transport code.
+4. Add integration tests against a test MCP server.
+
+**Lines Saved:** ~1,600
+**Risk:** Medium — sampling and timeout behavior need parity testing.
+
+#### Cron Scheduler → APScheduler
+
+**Current:** `cron/jobs.py` (753 lines) + `cron/scheduler.py` (~740 lines) use a JSON file as the job store, custom `parse_duration` and `compute_next_run` logic, a manual tick loop, and ad-hoc delivery orchestration.
+
+**Problem:** Scheduling is a solved problem. The homegrown system lacks timezone support, job concurrency controls, graceful clustering, and durable execution guarantees.
+
+**Migration Plan:**
+1. Introduce `APScheduler` with a `SQLAlchemyJobStore` (or custom JSON store).
+2. Refactor each Hermes cron job into an APScheduler `Job` function.
+3. Preserve existing delivery logic (`_deliver_result`, `_build_job_prompt`, `_run_job_script`) as the job body.
+4. Migrate `jobs.json` entries into APScheduler jobs on first run.
+5. Expose `/cron` status via a thin CLI wrapper.
+
+**Lines Saved:** ~700
+**Risk:** Low — delivery logic is preserved; only the trigger mechanism changes.
+
+#### Config Management → `pydantic-settings`
+
+**Current:** `hermes_cli/config.py` (2,589 lines) uses manual YAML parsing with hardcoded defaults, a complex migration chain (`_config_version` currently at 11), no runtime type validation, and stringly-typed env var resolution.
+
+**Problem:** Every new config option requires touching multiple places. Migration logic is ~400 lines and growing. Typo'd config values are only caught at runtime, often deep in the agent loop.
+
+**Migration Plan:**
+1. Define a `HermesConfig` Pydantic model with nested sections (`ModelConfig`, `ProviderConfig`, `AgentConfig`, `CompressionConfig`, etc.).
+2. Use `pydantic-settings`'s `SettingsConfigDict(yaml_file="~/.hermes/config.yaml")` to auto-load.
+3. Map env vars via `env_prefix="HERMES_"` or field-level `validation_alias`.
+4. Keep the migration layer as a one-time upgrade function, then remove it after two releases.
+5. Replace `load_config()` call sites with `HermesConfig()` instantiation.
+
+**Lines Saved:** ~1,500
+**Risk:** Medium-High — large blast radius; every module reads config. Requires backward compatibility.
+
+### 2.3 P1 Replacements
+
+**Checkpoint Manager → `dulwich`**
+- Replace `subprocess.run(["git", ...])` calls with `dulwich.porcelain` equivalents.
+- Use `dulwich.repo.Repo.init_bare()` for shadow repos.
+- Snapshotting becomes an in-memory `Index` write + `commit()`.
+- **Lines Saved:** ~200
+- **Risk:** Low
+
+**Auth / Credential Pool → `authlib` + `keyring` + `PyJWT`**
+- Use `authlib` for OAuth2 session and token refresh.
+- Replace custom JWT decoding with `PyJWT`.
+- Migrate the auth store JSON to `keyring`-backed secure storage where available.
+- Keep Hermes-specific credential pool strategies (round-robin, least-used, etc.).
+- **Lines Saved:** ~800
+- **Risk:** Medium
+
+**Batch Runner → `joblib`**
+- For typical local batch sizes, `joblib.Parallel(n_jobs=-1, backend='loky')` replaces the custom worker pool.
+- Only migrate to Celery if cross-machine distribution is required.
+- **Lines Saved:** ~400
+- **Risk:** Low for `joblib`
+
+### 2.4 Execution Roadmap
+
+1. **Week 1-2:** Migrate Checkpoint Manager to `dulwich` (quick win, low risk)
+2. **Week 3-4:** Migrate Cron Scheduler to `APScheduler` (high value, well-contained)
+3. **Week 5-8:** Migrate MCP Client to official `mcp` SDK (highest complexity, highest payoff)
+4. **Week 9-12:** Migrate Config Management to `pydantic-settings` (largest blast radius, do last)
+5. **Ongoing:** Evaluate Auth/Credential Pool and Batch Runner replacements as follow-up epics.
+
+### 2.5 Cost-Benefit Summary
+
+| Metric | Value |
+|--------|-------|
+| Total homebrew lines audited | ~17,000 |
+| Lines recommended for replacement | ~6,300 |
+| Estimated dev weeks (P0 + P1) | 10-14 weeks |
+| New runtime dependencies added | 4-6 well-maintained packages |
+| Maintenance burden reduction | Very High |
+| Risk level | Medium (mitigated by strong test coverage) |
+
+---
+
+## 3. Strategic Initiative: Operation Get A Job
+
+### 3.1 Thesis
+
+The engineering collective is capable of 10x delivery velocity compared to typical market offerings. The strategic opportunity is to monetize this capability through pure contracting — high-tempo, fixed-scope engagements with no exclusivity or employer-like constraints.
+
+### 3.2 Service Menu
+
+**Tier A — White-Glove Agent Infrastructure ($400-600/hr)**
+- Custom AI agent deployment with tool use (Slack, Discord, Telegram, webhooks)
+- MCP server development
+- Local LLM stack setup (on-premise / VPC)
+- Agent security audit and red teaming
+
+**Tier B — Security Hardening & Code Review ($250-400/hr)**
+- Security backlog burn-down (CVE-class bugs)
+- Skills-guard / sandbox hardening
+- Architecture review
+
+**Tier C — Automation & Integration ($150-250/hr)**
+- Webhook-to-action pipelines
+- Research and intelligence reporting
+- Content-to-code workflows
+
+### 3.3 Engagement Packages
+
+| Service | Description | Timeline | Investment |
+|---------|-------------|----------|------------|
+| Agent Security Audit | Review of one AI agent pipeline + written findings | 2-3 business days | $4,500 |
+| MCP Server Build | One custom MCP server with 3-5 tools + docs + tests | 1-2 weeks | $8,000 |
+| Custom Bot Deployment | End-to-end bot with up to 5 tools, deployed to client platform | 2-3 weeks | $12,000 |
+| Security Sprint | Close top 5 security issues in a Python/JS repo | 1-2 weeks | $6,500 |
+| Monthly Retainer — Core | 20 hrs/month prioritized engineering + triage | Ongoing | $6,000/mo |
+| Monthly Retainer — Scale | 40 hrs/month prioritized engineering + on-call | Ongoing | $11,000/mo |
+
+### 3.4 Go-to-Market Motion
+
+**Immediate channels:**
+- Cold outbound to CTOs/VPEs at Series A-C AI startups
+- LinkedIn authority content (architecture reviews, security bulletins)
+- Platform presence (Gun.io, Toptal, Upwork for specific niche keywords)
+
+**Lead magnet:** Free 15-minute architecture review. No pitch. One concrete risk identified.
+
+### 3.5 Infrastructure Foundation
+
+The Hermes Agent framework serves as both the delivery platform and the portfolio piece:
+- Open-source runtime with ~3,000 tests
+- Gateway architecture supporting 8+ messaging platforms
+- Native MCP client, cron scheduling, subagent delegation
+- Self-hosted Forge (Gitea) with CI and automated PR review
+- Local Gemma 4 inference stack on bare metal
+
+### 3.6 90-Day Revenue Model
+
+| Month | Target |
+|-------|--------|
+| Month 1 | $9-12K (1x retainer or 2x audits) |
+| Month 2 | $17K (+ 1x MCP build) |
+| Month 3 | $29K (+ 1x bot deployment + new retainer) |
+
+### 3.7 Immediate Action Items
+
+- File Wyoming LLC and obtain EIN
+- Open Mercury business bank account
+- Secure E&O insurance
+- Update LinkedIn profile and publish first authority post
+- Customize capabilities deck and begin warm outbound
+
+---
+
+## 4. Fleet Status Summary
+
+| House | Host | Model / Provider | Gateway Status |
+|-------|------|------------------|----------------|
+| Ezra | Hermes VPS | `kimi-for-coding` (Kimi K2.5) | API `8658`, webhook `8648` — Active |
+| Bezalel | Hermes VPS | Claude Opus 4.6 (Anthropic) | Port `8645` — Active |
+| Allegro-Primus | Hermes VPS | Kimi K2.5 | Port `8644` — Requires restart |
+| Bilbo | External | Gemma 4B (local) | Telegram dual-mode — Active |
+
+**Network:** Hermes VPS public IP `143.198.27.163` (Ubuntu 24.04.3 LTS). Local Gemma 4 fallback on `127.0.0.1:11435`.
+
+---
+
+## 5. Conclusion
+
+The codebase is in a strong position: security is hardened, the agent loop is more resilient, and a clear roadmap exists to replace high-maintenance homegrown infrastructure with battle-tested open-source projects. The commercialization strategy is formalized and ready for execution. The next critical path is the human-facing work of entity formation, sales outreach, and closing the first fixed-scope engagement.
+
+Prepared by **Ezra**
+April 2026