> Auto-generated codebase genome. Repo 9/16 in the Codebase Genome series.
## Project Overview
`timmy-home` is not a single product application. It is the Timmy Foundation workspace repo: an operational monorepo that mixes live guardrails, fleet scripts, local-world experiments, training pipelines, research artifacts, notes, and prototype agent runtimes.
**compounding-intelligence** turns 1B+ daily tokens into durable, compounding fleet intelligence. It solves the core problem of AI agent amnesia: every session starts at zero, rediscovering the same facts, pitfalls, and patterns that previous sessions already learned.
The most important reality check is in `OPERATIONS.md`: the active production system is Hermes plus the `timmy-config` sidecar, while `timmy-home` functions as the workspace, proving ground, and artifact store.
The project implements three pipelines forming a compounding loop:
### What the repo is good at
```
SESSION ENDS --> HARVESTER --> KNOWLEDGE STORE --> BOOTSTRAPPER --> NEW SESSION STARTS SMARTER
|
MEASURER --> Prove it's working
```
- local operational utilities and proof-oriented runbooks
- offline-first data transforms for training and archive analysis
- not a consistently production-hardened deployable service
- not one coherent architecture; it is several architectures sharing one tree
### Repository shape
Metric snapshot from `/tmp/BURN-7-6`:
- 3,119 files total
- 234 source files (`.py`, `.sh`, `.js`)
- 29 test files
- 21 config files
- 397,683 text lines total
- 42,428 Python lines
- 2,403 shell lines
- 272,829 Markdown lines
The file count is dominated by data and documentation:
-`training-data/` → 2,013 files
-`wizards/` → 345 files
-`skills/` → 327 files
This matters: operational code is only a small fraction of the repo. Any analysis that treats the repo as “just a Python package” will be wrong.
## Runtime Reality
The current live-system contract is defined more accurately by `OPERATIONS.md` than by `README.md`.
-`README.md` documents secret scanning and a tiny subset of the repo.
-`OPERATIONS.md` states that the active system is Hermes + `timmy-config` sidecar.
-`CONTRIBUTING.md` defines the repo’s most important invariant: proof is required for merge.
That means `timmy-home` behaves as a workspace + runbook + experiment garden around a live sidecar/orchestrator that mostly lives elsewhere.
**Key insight**: Intelligence from a million tokens of work evaporates when the session ends. This project captures it, stores it, and injects it into future sessions so they start smarter.
- covers state persistence, dry-run behavior, unknown milestones, idempotence
-`tests/test_failover_monitor.py`
- covers online/offline detection and status-file emission
These close two concrete gaps around previously untested operational scripts.
### Well-covered areas
- secret detection
- trajectory sanitization
- Tower game (`scripts/tower_game.py`)
- Know Thy Father pipeline
- Twitter archive pipeline
- Evennia telemetry/layout helper modules
- documentation proof-policy assertions
### Weak or missing coverage
- no real end-to-end coverage for `scripts/evennia/bootstrap_local_evennia.py`
- no runtime coverage for `scripts/evennia/verify_local_evennia.py` against a real Evennia world
- no automated tests for `morrowind/`
- no meaningful automated coverage for `infrastructure/timmy-bridge/`
- most shell/provisioning scripts remain untested
-`uni-wizard/v2` and `uni-wizard/v3` are not full-repo-pytest clean
### Concrete failing area
Full-repo pytest currently fails in `uni-wizard/v2/tests/test_author_whitelist.py` because `uni-wizard/v2/task_router_daemon.py` imports `harness` and resolves to `uni-wizard/harness.py` instead of the version-local v2 harness. That is a real namespace collision, not flaky test noise.
### Gaps
- No integration tests for full harvester pipeline
-No tests for bootstrapper context assembly
-No tests for measurer metrics computation
-No tests for deduplication logic
- No CI pipeline configured
## Security Considerations
### 1. Hard-coded IPs and host-specific paths
1.**Knowledge injection**: Bootstrapper injects context from knowledge store. Malicious facts in the store could influence agent behavior. Trust scoring partially mitigates this.
2.**Session transcripts**: May contain sensitive data (tokens, API keys). Harvester must filter sensitive patterns before storage.
3.**LLM extraction**: Harvest prompt instructs "no hallucination" but LLMs can still confabulate. Confidence scoring and source attribution provide auditability.
4.**File-based storage**: No access control on knowledge files. Anyone with filesystem access can read/modify.
Examples appear across the repo, including:
## Dependencies
-`timmy-local/README.md`
-`scripts/setup-uni-wizard.sh`
-`scripts/provision-timmy-vps.sh`
-`scripts/emacs-fleet-poll.sh`
-`scripts/emacs-fleet-bridge.py`
-`scripts/failover_monitor.py`
-Python 3.10+
-No external packages (stdlib only)
-LLM access for harvester pipeline (Ollama or cloud provider)
-Hermes agent framework for session management
Risk:
## Status
-fragile deploy assumptions
-easy environment drift
-accidental disclosure in public docs or configs
### 2. Broad mutation surfaces in world-shell commands
`timmy-local/evennia/commands/tools.py` exposes host file, git, search, system, and network operations inside the world abstraction.
Risk:
- large blast radius if command permissions are weak
- hard to separate playful world interaction from privileged host mutation
### 3. CI is smoke-only and partly broken
`.gitea/workflows/smoke.yml` does not run pytest.
Worse, its JSON parse command is broken as written:
These are overlapping Tower implementations with different behavior and shared concepts.
### Architecture-generation drift
-`uniwizard/`
-`uni-wizard/`
-`uni-wizard/v2/`
-`uni-wizard/v3/`
-`uni-wizard/v4/`
Multiple generations coexist with conflicting import assumptions.
### Pipeline overlap
-`twitter-archive/`
-`scripts/twitter_archive/`
-`scripts/know_thy_father/`
These lanes overlap in mission and artifact shape.
## Performance and Scaling Notes
- most heavy data volume lives in `training-data/`, so repo-wide file scans are expensive by default
- smoke commands that blindly walk all JSON files will age poorly as artifact volume grows
- archive/media pipelines depend on batch processing and checkpointing to remain tractable
- routing/telemetry systems rely heavily on local SQLite and JSONL append-only files, which is simple and inspectable but may become contention-prone under sustained automation
## Recommended Follow-up Work
1. Fix `.gitea/workflows/smoke.yml` so JSON validation iterates file-by-file and pytest is part of CI. Filed as issue #715.
2. Resolve `uni-wizard` namespace collisions so `pytest -q` is green repo-wide. Filed as issue #716.
3. Decide which Tower implementation is canonical and retire the others or clearly mark them experimental.
4. Separate production-grade bridge/runtime code from placeholder or speculative prototypes.
5. Centralize host/path/IP configuration instead of embedding machine-specific values in docs and scripts.
6. Add end-to-end verification for the Evennia runtime lane.
7. Add at least smoke coverage for the `morrowind/` and `timmy-bridge/` lanes.
## Verification Notes
This GENOME is based on:
- direct inspection of the repo root, top-level metrics, and key runtime docs
- direct test execution on this branch
- direct reproduction of the broken CI JSON-parse command
- targeted new tests added for untested operational scripts
- deeper file-level analysis across Evennia, archive, harness, and game-agent lanes
It should be read as a map of a workspace monorepo with several real subsystems and several prototype subsystems, not as documentation for one singular deployable app.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.