Timmy Operations — What Runs the Workforce

ACTIVE SYSTEM: Hermes + timmy-config sidecar

Harness: Hermes
Config repo: Timmy_Foundation/timmy-config
Workspace repo: Timmy_Foundation/timmy-home
Orchestration: Huey + SQLite via timmy-config/orchestration.py and timmy-config/tasks.py
Target repos: Timmy_Foundation/the-nexus, Timmy_Foundation/timmy-home, Timmy_Foundation/timmy-config
Training data home: ~/.timmy/training-data/

DEPRECATED — DO NOT RESTORE

bash loops (claude-loop.sh, gemini-loop.sh, timmy-orchestrator.sh)
workforce-manager.py (bash version)
nexus-merge-bot.sh
agent-loop.sh
deploy.sh --restart-loops

These crash-loop and produce zero work. They were restored by mistake on 2026-03-25 causing a regression. The Hermes + timmy-config sidecar replaces them.

The scripts in timmy-config/bin/ are live utility scripts for the sidecar. What is dead is the old always-on bash loop model.

How to check what's running

# Hermes gateway / API should be up
lsof -iTCP:8642 -sTCP:LISTEN

# Sessions should be landing in ~/.hermes/sessions
ls -lt ~/.hermes/sessions | head

# DPO exports should not lag far behind new sessions
~/.hermes/bin/pipeline-freshness.sh

# Should be EMPTY (no bash loops)
ps aux | grep -E "claude-loop|gemini-loop|timmy-orchestrator" | grep -v grep

Cron Jobs (Hermes built-in)

Health Monitor: every 5m, haiku (not opus!)
DPO export / training support jobs: explicit model, explicit task, no hidden defaults
All crons MUST specify model explicitly. Never inherit default.

Proof Standard

visual changes require screenshot proof
keep screenshots and binary media out of Gitea backup unless explicitly required
CLI/verifiable changes must reference the exact command output, log path, or observable state proving the claim
see CONTRIBUTING.md for the merge gate

1.9 KiB Raw Blame History