timmy-home/OPERATIONS.md

# 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
```bash
# 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