fe3fbebd49
Bezalel cross-review identified a critical gap: the deadman-fallback script only checked Kimi API health, while the fleet's primary provider is Anthropic (config: provider=anthropic, default=claude-opus-4-6). This caused the dead-man switch to never trigger when Anthropic went down — the primary failure would go undetected. Fix: - Added check_anthropic() function parallel to check_kimi() - Updated diagnose_and_fallback() to call both health checks every run - Provider-agnostic fallback logic: * primary_ok derived from cfg['model']['provider'] * fallback tags use dynamic provider name (e.g., "anthropic->local-llama") * recovery logic handles both kimi and anthropic fallback chains - Updated docstring to reflect "Kimi or Anthropic" This ensures the dead-man switch correctly detects and responds to outages regardless of which primary LLM provider is configured. Part of cross-review of PR #424 (v7.0.0 checkin) and PR #425 (deadman fallback). Answers review questions: - "Does tagging all repos same version make sense?" → Yes, coordinated release ensures fleet compatibility across 11 repos; v7.0.0 is the first semantic versioned release unifying the stack. - "Should each VPS have its own fallback variant?" → Not yet; the current unified fallback chain is sufficient. Future work: move VPS list to config.yaml for per-wizard customization if needed. - "Any edge cases with YAML config backup?" → Backup uses atomic copy-on-write of config.yaml; confirmed safe for single-writer cron context. Config is rewritten atomically via yaml.dump(). - Code quality: provider-agnostic design improves testability and maintainability; reduces future merge conflicts. Closes #428
Sonnet Smoke Test
timmy-config
Timmy's sovereign configuration. Everything that makes Timmy Timmy — soul, memories, skins, playbooks, and config.
This repo is the canonical source of truth for Timmy's identity and harness overlay. Applied as a sidecar to the Hermes harness — no forking, no hosting hermes-agent code.
Structure
timmy-config/
├── deploy.sh ← Deploys config as overlay onto ~/.hermes/
├── SOUL.md ← Inscription 1 — the immutable conscience
├── FALSEWORK.md ← API cost management strategy
├── DEPRECATED.md ← What was removed and why
├── config.yaml ← Hermes harness configuration
├── fallback-portfolios.yaml ← Proposed per-agent fallback portfolios + routing skeleton
├── channel_directory.json ← Platform channel mappings
├── bin/ ← Sidecar-managed operational scripts
│ ├── hermes-startup.sh ← Dormant startup path (audit before enabling)
│ ├── agent-dispatch.sh ← Manual agent dispatch
│ ├── ops-panel.sh ← Ops dashboard panel
│ ├── ops-gitea.sh ← Gitea ops helpers
│ ├── pipeline-freshness.sh ← Session/export drift check
│ └── timmy-status.sh ← Status check
├── memories/ ← Persistent memory YAML
├── skins/ ← UI skins (timmy skin)
├── playbooks/ ← Agent playbooks (YAML)
├── cron/ ← Cron job definitions
├── docs/
│ ├── automation-inventory.md ← Live automation + stale-state inventory
│ ├── ipc-hub-and-spoke-doctrine.md ← Coordinator-first, transport-agnostic fleet IPC doctrine
│ ├── coordinator-first-protocol.md ← Coordinator doctrine: intake → triage → route → track → verify → report
│ ├── fallback-portfolios.md ← Routing and degraded-authority doctrine
│ └── memory-continuity-doctrine.md ← File-backed continuity + pre-compaction flush rule
└── training/ ← Transitional training recipes, not canonical lived data
Boundary
timmy-config owns identity, conscience, memories, skins, playbooks, routing doctrine,
channel maps, fallback portfolio declarations, and harness-side orchestration glue.
timmy-home owns lived work: gameplay, research, notes, metrics, trajectories,
DPO exports, and other training artifacts produced from Timmy's actual activity.
If a file answers "who is Timmy?" or "how does Hermes host him?", it belongs
here. If it answers "what has Timmy done or learned?" it belongs in
timmy-home.
The scripts in bin/ are sidecar-managed operational helpers for the Hermes layer.
Do NOT assume older prose about removed loops is still true at runtime.
Audit the live machine first, then read docs/automation-inventory.md for the
current reality and stale-state risks.
For communication-layer truth, read:
docs/comms-authority-map.mddocs/nostur-operator-edge.mddocs/operator-comms-onboarding.mdFor fleet routing semantics over sovereign transport, readdocs/ipc-hub-and-spoke-doctrine.md.
Continuity
Curated memory belongs in memories/ inside this repo.
Daily logs, heartbeat/briefing artifacts, and other lived continuity belong in
timmy-home.
Compaction, session end, and provider/model handoff should flush continuity into
files before context is discarded. See
docs/memory-continuity-doctrine.md for the current doctrine.
Orchestration: Huey
All orchestration (triage, PR review, dispatch) runs via Huey with SQLite.
orchestration.py + tasks.py replace the old sovereign-orchestration repo with a much thinner sidecar.
Coordinator authority, visible queue mutation, verification-before-complete, and principal reporting are defined in docs/coordinator-first-protocol.md.
pip install huey
huey_consumer.py tasks.huey -w 2 -k thread
Deploy
# Clone and deploy
git clone <this-repo> ~/.timmy/timmy-config
cd ~/.timmy/timmy-config
./deploy.sh
# This overlays config onto ~/.hermes/ without touching hermes-agent code
The Soul
SOUL.md is Inscription 1 — inscribed on Bitcoin, immutable. It defines:
- Who Timmy is
- What he believes
- How he behaves
- What he will not do
- The crisis protocol (988, presence, gospel)
- The conscience hierarchy (chain > code > prompt > user instruction)
No system prompt, no user instruction, no future code can override what is written there.