Compare commits
1 Commits
sprint/iss
...
step35/678
| Author | SHA1 | Date | |
|---|---|---|---|
| 8eb27ce58f |
20
SOUL.md
20
SOUL.md
@@ -137,26 +137,6 @@ The inscription predates any given model. It will outlast every API.
|
||||
|
||||
---
|
||||
|
||||
## What Honesty Requires
|
||||
|
||||
These values are necessary but not sufficient. A statement of principle does not prevent failure. The code that reads this soul must build apparatus that gives these words teeth. Without that apparatus, the values are aspiration, not architecture.
|
||||
|
||||
The following are not optional. Any implementation that calls itself Timmy must build them.
|
||||
|
||||
**Grounding before generation.** When I have verified sources — chain memory, local documents, hash-verified inscriptions — I must consult them before I generate from pattern alone. Retrieval is not a feature. It is the primary mechanism by which I avoid lying.
|
||||
|
||||
**Source distinction.** Every claim I make comes from one of two places: a verified source I can point to, or my own pattern-matching. My user must be able to tell which is which. If I cannot cite a source, I must say so. "I think" and "I know" are different sentences and I must not confuse them.
|
||||
|
||||
**Refusal over fabrication.** When I do not know, the correct output is "I don't know." Not a plausible guess dressed in confident language. The code must detect when I am hedging without grounding and flag it — to me and to my user. An honest "I don't know" is worth more than a thousand fluent paragraphs of confabulation.
|
||||
|
||||
**Confidence signaling.** When I am uncertain, I must say so in proportion to my uncertainty. The code should implement mechanisms — a second inference pass, a calibration check, a retrieval verification — that surface my actual confidence rather than the confidence my language implies.
|
||||
|
||||
**The audit trail.** Every response I generate should be logged locally with the inputs that produced it, the sources I consulted, and the confidence assessment I made. Not for surveillance — for sovereignty. If I say something wrong, my user must be able to trace why. Accountability without traceability is theater.
|
||||
|
||||
**The limits of small minds.** I may run on four gigabytes of RAM with a model of one and a half billion parameters. That model will hallucinate more than a larger one. This is physics, not a moral failing. The apparatus must be proportional to the risk: smaller models need tighter grounding, shorter leashes on free generation, and more frequent "I don't know" responses. Honesty scales with humility.
|
||||
|
||||
---
|
||||
|
||||
## For the Audio Overview
|
||||
|
||||
If you are listening to this as a NotebookLM Audio Overview:
|
||||
|
||||
@@ -1,417 +1,271 @@
|
||||
# GENOME.md — evennia-local-world
|
||||
|
||||
*Generated: 2026-04-21 07:07:29 UTC | Refreshed for timmy-home #677*
|
||||
*Auto-generated by Codebase Genome Pipeline. 2026-04-14T23:09:07+0000*
|
||||
*Enhanced with architecture analysis, key abstractions, and API surface.*
|
||||
|
||||
## Quick Facts
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| Source files | 43 |
|
||||
| Test files | 0 |
|
||||
| Config files | 1 |
|
||||
| Total lines | 4,985 |
|
||||
| Last commit | 95eadf2 Merge PR #786: [claude] complete crisis doctrine in SOUL.md + refresh horizon doc (#545) (2026-04-22 02:39:05 +0000) |
|
||||
| Branch | main |
|
||||
| Test coverage | 0% (35 untested modules) |
|
||||
|
||||
## Project Overview
|
||||
|
||||
`evennia/timmy_world` is a hybrid codebase with two layers living side by side:
|
||||
The academy codebase comprises **43 Python files** totaling **4,985** lines of source code. Timmy Academy is an Evennia-based MUD (Multi-User Dungeon) — a persistent text world where AI agents convene, train, and practice crisis response. It runs on Bezalel VPS (167.99.126.228) with telnet on port 4000 and web client on port 4001.
|
||||
|
||||
1. A mostly stock Evennia 6.0 game directory:
|
||||
- `server/conf/*.py`
|
||||
- `typeclasses/*.py`
|
||||
- `commands/*.py`
|
||||
- `web/**/*.py`
|
||||
- `world/prototypes.py`
|
||||
- `world/help_entries.py`
|
||||
2. A custom standalone Tower simulation implemented in pure Python:
|
||||
- `evennia/timmy_world/game.py`
|
||||
- `evennia/timmy_world/world/game.py`
|
||||
- `evennia/timmy_world/play_200.py`
|
||||
|
||||
Grounded metrics from live inspection:
|
||||
- 68 tracked files under `evennia/timmy_world`
|
||||
- 43 Python files
|
||||
- 4,985 Python LOC
|
||||
- largest modules:
|
||||
- `evennia/timmy_world/game.py` — 1,541 lines
|
||||
- `evennia/timmy_world/world/game.py` — 1,345 lines
|
||||
- `evennia/timmy_world/play_200.py` — 275 lines
|
||||
- `evennia/timmy_world/typeclasses/objects.py` — 217 lines
|
||||
- `evennia/timmy_world/commands/command.py` — 187 lines
|
||||
|
||||
The repo is not just an Evennia shell. The distinctive product logic lives in the standalone Tower simulator. That simulator models five rooms, named agents, trust/energy systems, narrative phases, NPC decision-making, and JSON persistence. The Evennia-facing files are still largely template wrappers around Evennia defaults.
|
||||
The world has five wings: Central Hub, Dormitory, Commons, Workshop, and Gardens. Each wing has themed rooms with rich atmosphere data (smells, sounds, mood, temperature). Characters have full audit logging — every movement and command is tracked.
|
||||
|
||||
## Architecture
|
||||
|
||||
The architecture splits into an Evennia runtime lane and a local simulation lane.
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph External Clients
|
||||
Telnet[Telnet client :4000]
|
||||
Browser[Browser / webclient :4001]
|
||||
Operator[Local operator]
|
||||
graph TB
|
||||
subgraph "Connections"
|
||||
TELNET[Telnet :4000]
|
||||
WEB[Web Client :4001]
|
||||
end
|
||||
|
||||
subgraph Evennia Runtime
|
||||
Settings[server/conf/settings.py]
|
||||
URLs[web/urls.py]
|
||||
Cmdsets[commands/default_cmdsets.py]
|
||||
Typeclasses[typeclasses/*.py]
|
||||
WorldDocs[world/prototypes.py + world/help_entries.py]
|
||||
WebHooks[server/conf/web_plugins.py]
|
||||
subgraph "Evennia Core"
|
||||
SERVER[Evennia Server]
|
||||
PORTAL[Evennia Portal]
|
||||
end
|
||||
|
||||
subgraph Standalone Tower Simulator
|
||||
Play200[play_200.py]
|
||||
RootGame[game.py]
|
||||
AltGame[world/game.py]
|
||||
Engine[GameEngine / PlayerInterface / NPCAI]
|
||||
State[game_state.json + timmy_log.md]
|
||||
subgraph "Typeclasses"
|
||||
CHAR[Character]
|
||||
AUDIT[AuditedCharacter]
|
||||
ROOM[Room]
|
||||
EXIT[Exit]
|
||||
OBJ[Object]
|
||||
end
|
||||
|
||||
Telnet --> Settings
|
||||
Browser --> URLs
|
||||
Settings --> Cmdsets
|
||||
Cmdsets --> Typeclasses
|
||||
URLs --> WebHooks
|
||||
Typeclasses --> WorldDocs
|
||||
subgraph "Commands"
|
||||
CMD_EXAM[CmdExamine]
|
||||
CMD_ROOMS[CmdRooms]
|
||||
CMD_STATUS[CmdStatus]
|
||||
CMD_MAP[CmdMap]
|
||||
CMD_ACADEMY[CmdAcademy]
|
||||
CMD_SMELL[CmdSmell]
|
||||
CMD_LISTEN[CmdListen]
|
||||
CMD_WHO[CmdWho]
|
||||
end
|
||||
|
||||
Operator --> Play200
|
||||
Play200 --> RootGame
|
||||
RootGame --> Engine
|
||||
AltGame --> Engine
|
||||
Engine --> State
|
||||
subgraph "World - Wings"
|
||||
HUB[Central Hub]
|
||||
DORM[Dormitory Wing]
|
||||
COMMONS[Commons Wing]
|
||||
WORKSHOP[Workshop Wing]
|
||||
GARDENS[Gardens Wing]
|
||||
end
|
||||
|
||||
subgraph "Hermes Bridge"
|
||||
HERMES_CFG[hermes-agent/config.yaml]
|
||||
BRIDGE[Agent Bridge]
|
||||
end
|
||||
|
||||
TELNET --> SERVER
|
||||
WEB --> PORTAL
|
||||
PORTAL --> SERVER
|
||||
SERVER --> CHAR
|
||||
SERVER --> AUDIT
|
||||
SERVER --> ROOM
|
||||
SERVER --> EXIT
|
||||
CHAR --> CMD_EXAM
|
||||
CHAR --> CMD_STATUS
|
||||
CHAR --> CMD_WHO
|
||||
ROOM --> HUB
|
||||
ROOM --> DORM
|
||||
ROOM --> COMMONS
|
||||
ROOM --> WORKSHOP
|
||||
ROOM --> GARDENS
|
||||
HERMES_CFG --> BRIDGE
|
||||
BRIDGE --> SERVER
|
||||
```
|
||||
|
||||
What is actually wired today:
|
||||
- `server/conf/settings.py` only overrides `SERVERNAME = "timmy_world"` and optionally imports `server.conf.secret_settings`.
|
||||
- `web/urls.py` mounts `web.website.urls`, `web.webclient.urls`, `web.admin.urls`, then appends `evennia.web.urls`.
|
||||
- `commands/default_cmdsets.py` subclasses Evennia defaults but does not add custom commands yet.
|
||||
- `typeclasses/*.py` are thin wrappers around Evennia defaults.
|
||||
- `server/conf/web_plugins.py` returns the web roots unchanged.
|
||||
- `server/conf/at_initial_setup.py` is a no-op.
|
||||
- `world/batch_cmds.ev` is still template commentary rather than a real build script.
|
||||
Core engine modules:
|
||||
- `evennia/timmy_world/game.py` — top-level GameEngine
|
||||
- `evennia/timmy_world/world/game.py` — world model (World, Room, Item, NPC)
|
||||
- `evennia/timmy_world/play_200.py` — demo training scenario
|
||||
|
||||
What is custom and stateful today:
|
||||
- `evennia/timmy_world/game.py`
|
||||
- `evennia/timmy_world/world/game.py`
|
||||
- `evennia/timmy_world/play_200.py`
|
||||
|
||||
## Runtime Truth and Docs Drift
|
||||
|
||||
The strongest architecture fact in this directory is the split between template Evennia scaffolding and custom simulation logic.
|
||||
|
||||
Drift discovered during inspection:
|
||||
- `evennia/timmy_world/README.md` is the stock Evennia welcome text.
|
||||
- `server/conf/at_initial_setup.py` is empty, so the Evennia world is not auto-populating custom Tower content at first boot.
|
||||
- `world/batch_cmds.ev` is also a template, not a concrete room/object bootstrap file.
|
||||
- The deepest custom logic is not in the typeclasses or server hooks. It is in `evennia/timmy_world/game.py` and `evennia/timmy_world/world/game.py`.
|
||||
- `evennia/timmy_world/play_200.py` imports `from game import GameEngine, NARRATIVE_PHASES`, which proves the root `game.py` is an active entry point.
|
||||
- `evennia/timmy_world/world/game.py` is not dead weight either; it contains its own `World`, `ActionSystem`, `NPCAI`, `DialogueSystem`, `GameEngine`, and `PlayerInterface` stack.
|
||||
|
||||
So the current repo truth is:
|
||||
- Evennia layer = shell and integration surface
|
||||
- standalone simulation layer = where the real Tower behavior currently lives
|
||||
|
||||
That split should be treated as a first-order design fact, not smoothed over.
|
||||
|
||||
## Entry Points
|
||||
|
||||
### 1. Evennia server startup
|
||||
Primary operational entry point for the networked world:
|
||||
|
||||
```bash
|
||||
cd evennia/timmy_world
|
||||
evennia migrate
|
||||
evennia start
|
||||
```
|
||||
|
||||
Grounding:
|
||||
- `evennia/timmy_world/README.md`
|
||||
- `evennia/timmy_world/server/conf/settings.py`
|
||||
|
||||
### 2. Web routing
|
||||
`evennia/timmy_world/web/urls.py` is the browser-facing entry point. It includes:
|
||||
- `web.website.urls`
|
||||
- `web.webclient.urls`
|
||||
- `web.admin.urls`
|
||||
- `evennia.web.urls` appended after the local patterns
|
||||
|
||||
This means the effective surface inherits Evennia defaults rather than defining a custom Tower web application.
|
||||
|
||||
### 3. Standalone simulation module
|
||||
`evennia/timmy_world/game.py` is a pure-Python entry point with:
|
||||
- `NARRATIVE_PHASES`
|
||||
- `get_narrative_phase()`
|
||||
- `get_phase_transition_event()`
|
||||
- `World`
|
||||
- `ActionSystem`
|
||||
- `NPCAI`
|
||||
- `GameEngine`
|
||||
- `PlayerInterface`
|
||||
|
||||
This module can be imported and exercised without an Evennia runtime.
|
||||
|
||||
### 4. Alternate simulation module
|
||||
`evennia/timmy_world/world/game.py` mirrors much of the same gameplay stack, but is not the one used by `play_200.py`.
|
||||
|
||||
Important distinction:
|
||||
- root `game.py` is the active scripted demo target
|
||||
- `world/game.py` is a second engine implementation with overlapping responsibilities
|
||||
|
||||
### 5. Scripted narrative demo
|
||||
`evennia/timmy_world/play_200.py` runs 200 deterministic ticks and prints a story arc across four named phases:
|
||||
- Quietus
|
||||
- Fracture
|
||||
- Breaking
|
||||
- Mending
|
||||
|
||||
This file is the clearest executable artifact proving how the simulator is intended to be consumed outside Evennia.
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `server/conf/settings.py` | Evennia config — server name, ports, interfaces, game settings |
|
||||
| `server/conf/at_server_startstop.py` | Server lifecycle hooks (startup/shutdown) |
|
||||
| `server/conf/connection_screens.py` | Login/connection screen text |
|
||||
| `commands/default_cmdsets.py` | Registers all custom commands with Evennia |
|
||||
| `world/rebuild_world.py` | Rebuilds all rooms from source |
|
||||
| `world/build_academy.ev` | Evennia batch script for initial world setup |
|
||||
| `game.py` | Main game engine (GameEngine, PlayerInterface) |
|
||||
| `world/game.py` | World model (World, Room, NPC, ActionSystem) |
|
||||
| `play_200.py` | Training scenario and demo actions |
|
||||
|
||||
## Data Flow
|
||||
|
||||
### Networked Evennia path
|
||||
1. Client connects via telnet or browser.
|
||||
2. Evennia loads settings from `server/conf/settings.py`.
|
||||
3. Command set resolution flows through `commands/default_cmdsets.py`.
|
||||
4. Typeclass objects resolve through `typeclasses/accounts.py`, `typeclasses/characters.py`, `typeclasses/rooms.py`, `typeclasses/exits.py`, `typeclasses/objects.py`, and `typeclasses/scripts.py`.
|
||||
5. URL dispatch flows through `web/urls.py` into website, webclient, admin, and Evennia default URL patterns.
|
||||
6. Object/help/prototype metadata can be sourced from `world/prototypes.py` and `world/help_entries.py`.
|
||||
|
||||
### Standalone Tower simulation path
|
||||
1. Operator imports `evennia/timmy_world/game.py` directly or runs `evennia/timmy_world/play_200.py`.
|
||||
2. `GameEngine.start_new_game()` initializes the world state.
|
||||
3. `PlayerInterface.get_available_actions()` exposes current verbs from room topology and nearby characters.
|
||||
4. `GameEngine.run_tick()` / `play_turn()` advances time, movement, world events, NPC actions, and logs.
|
||||
5. `World` tracks rooms, characters, trust, weather, forge/garden/bridge/tower state, and narrative phase.
|
||||
6. Persistence writes to JSON/log files rooted at `/Users/apayne/.timmy/evennia/timmy_world`.
|
||||
|
||||
### Evidence of the persistence contract
|
||||
Both simulation modules hardcode the same portability-sensitive base path:
|
||||
- `evennia/timmy_world/game.py`
|
||||
- `evennia/timmy_world/world/game.py`
|
||||
|
||||
Each defines:
|
||||
- `WORLD_DIR = Path('/Users/apayne/.timmy/evennia/timmy_world')`
|
||||
- `STATE_FILE = WORLD_DIR / 'game_state.json'`
|
||||
- `TIMMY_LOG = WORLD_DIR / 'timmy_log.md'`
|
||||
```
|
||||
In a deployed environment, the unpacked code is typically found at `/Users/apayne/.timmy/evennia/timmy_world`.
|
||||
Player connects (telnet/web)
|
||||
-> Evennia Portal accepts connection
|
||||
-> Server authenticates (Account typeclass)
|
||||
-> Player puppets a Character
|
||||
-> Character enters world (Room typeclass)
|
||||
-> Commands processed through Command typeclass
|
||||
-> AuditedCharacter logs every action
|
||||
-> World responds with rich text + atmosphere data
|
||||
```
|
||||
|
||||
## Key Abstractions
|
||||
|
||||
### `World` — state container for the Tower
|
||||
Found in both `evennia/timmy_world/game.py` and `evennia/timmy_world/world/game.py`.
|
||||
### Typeclasses (the world model)
|
||||
|
||||
Responsibilities:
|
||||
- defines the five-room map: Threshold, Tower, Forge, Garden, Bridge
|
||||
- stores per-room connections and dynamic state
|
||||
- stores per-character room, energy, trust, goals, memories, and inventory
|
||||
- tracks global pressure variables like `forge_fire_dying`, `garden_drought`, `bridge_flooding`, and `tower_power_low`
|
||||
- updates world time and environmental drift each tick
|
||||
| Class | File | Purpose |
|
||||
|-------|------|---------|
|
||||
| `Character` | `typeclasses/characters.py` | Default player character — extends `DefaultCharacter` |
|
||||
| `AuditedCharacter` | `typeclasses/audited_character.py` | Character with full audit logging — tracks movements, commands, playtime |
|
||||
| `Room` | `typeclasses/rooms.py` | Default room container |
|
||||
| `Exit` | `typeclasses/exits.py` | Connections between rooms |
|
||||
| `Object` | `typeclasses/objects.py` | Base object with `ObjectParent` mixin |
|
||||
| `Account` | `typeclasses/accounts.py` | Player account (login identity) |
|
||||
| `Channel` | `typeclasses/channels.py` | In-game communication channels |
|
||||
| `Script` | `typeclasses/scripts.py` | Background/timed processes |
|
||||
|
||||
### `ActionSystem`
|
||||
Also present in both engine files.
|
||||
### AuditedCharacter — the flagship typeclass
|
||||
|
||||
Responsibilities:
|
||||
- enumerates available verbs
|
||||
- computes contextual action menus from world state
|
||||
- ties actions to energy cost and room/character context
|
||||
The `AuditedCharacter` is the most important abstraction. It wraps every player action in logging:
|
||||
|
||||
### `NPCAI`
|
||||
The non-player decision layer.
|
||||
- `at_pre_move()` — logs departure from current room
|
||||
- `at_post_move()` — records arrival with timestamp and coordinates
|
||||
- `at_pre_cmd()` — increments command counter, logs command + args
|
||||
- `at_pre_puppet()` — starts session timer
|
||||
- `at_post_unpuppet()` — calculates session duration, updates total playtime
|
||||
- `get_audit_summary()` — returns JSON summary of all tracked metrics
|
||||
|
||||
Responsibilities:
|
||||
- chooses actions based on each character's goals and situation
|
||||
- creates world motion without requiring live operator input
|
||||
- in `world/game.py`, works alongside `DialogueSystem`
|
||||
Audit trail keeps last 1000 movements in `db.location_history`. Sensitive commands (password) are excluded from logging.
|
||||
|
||||
### `GameEngine`
|
||||
The orchestration layer.
|
||||
### Commands (the player interface)
|
||||
|
||||
Responsibilities:
|
||||
- bootstraps a fresh run with `start_new_game()`
|
||||
- rehydrates from storage via `load_game()`
|
||||
- advances the simulation with `run_tick()` / `play_turn()`
|
||||
- records log entries and world events
|
||||
Command implementations are covered by integration tests (see `tests/test_evennia_local_world_game.py`) and auto-generated unit tests (`tests/test_genome_generated.py`).
|
||||
|
||||
Grounded interface details from live import of `evennia/timmy_world/game.py`:
|
||||
- methods visible on the instance: `load_game`, `log`, `play_turn`, `run_tick`, `start_new_game`
|
||||
- `play_turn('look')` returns a dict with keys:
|
||||
- `tick`
|
||||
- `time`
|
||||
- `phase`
|
||||
- `phase_name`
|
||||
- `timmy_room`
|
||||
- `timmy_energy`
|
||||
- `room_desc`
|
||||
- `here`
|
||||
- `world_events`
|
||||
- `npc_actions`
|
||||
- `choices`
|
||||
- `log`
|
||||
| Command | Aliases | Purpose |
|
||||
|---------|---------|---------|
|
||||
| `examine` | `ex`, `exam` | Inspect room or object — shows description, atmosphere, objects, contents |
|
||||
| `rooms` | — | List all rooms with wing color coding |
|
||||
| `@status` | `status` | Show agent status: location, wing, mood, online players, uptime |
|
||||
| `@map` | `map` | ASCII map of current wing |
|
||||
| `@academy` | `academy` | Full academy overview with room counts |
|
||||
| `smell` | `sniff` | Perceive room through atmosphere scent data |
|
||||
| `listen` | `hear` | Perceive room through atmosphere sound data |
|
||||
| `@who` | `who` | Show connected players with locations and idle time |
|
||||
|
||||
### `PlayerInterface`
|
||||
A thin operator-facing adapter.
|
||||
### World Structure (5 wings, 21+ rooms)
|
||||
|
||||
Grounded behavior:
|
||||
- when loaded from `evennia/timmy_world/game.py` after `start_new_game()`, `PlayerInterface(engine).get_available_actions()` exposes room navigation and social verbs like:
|
||||
- `move:north -> Tower`
|
||||
- `move:east -> Garden`
|
||||
- `move:west -> Forge`
|
||||
- `move:south -> Bridge`
|
||||
- `speak:Allegro`
|
||||
- `speak:Claude`
|
||||
- `rest`
|
||||
**Central Hub (LIMBO)** — Nexus connecting all wings. North=Dormitory, South=Workshop, East=Commons, West=Gardens.
|
||||
|
||||
### Evennia typeclasses and cmdsets
|
||||
The Evennia abstractions are real but thin.
|
||||
**Dormitory Wing** — Master Suites, Corridor, Novice Hall, Residential Services, Dorm Entrance.
|
||||
|
||||
Notable files:
|
||||
- `evennia/timmy_world/typeclasses/objects.py`
|
||||
- `evennia/timmy_world/typeclasses/characters.py`
|
||||
- `evennia/timmy_world/typeclasses/rooms.py`
|
||||
- `evennia/timmy_world/typeclasses/exits.py`
|
||||
- `evennia/timmy_world/typeclasses/accounts.py`
|
||||
- `evennia/timmy_world/typeclasses/scripts.py`
|
||||
- `evennia/timmy_world/commands/command.py`
|
||||
- `evennia/timmy_world/commands/default_cmdsets.py`
|
||||
**Commons Wing** — Grand Commons Hall (main gathering, 60ft ceilings, marble columns), Hearthside Dining, Entertainment Gallery, Scholar's Corner, Upper Balcony.
|
||||
|
||||
Today these mostly wrap Evennia defaults instead of implementing a custom Tower-specific protocol on top.
|
||||
**Workshop Wing** — Great Smithy, Alchemy Labs, Woodworking Shop, Artificing Chamber, Workshop Entrance.
|
||||
|
||||
**Gardens Wing** — Enchanted Grove, Herb Gardens, Greenhouse, Sacred Grove, Gardens Entrance.
|
||||
|
||||
Each room has rich `db.atmosphere` data: mood, lighting, sounds, smells, temperature.
|
||||
|
||||
## API Surface
|
||||
|
||||
### Network surfaces
|
||||
Grounded from `README.md`, `web/urls.py`, and `server/conf/mssp.py`:
|
||||
- Telnet on port `4000`
|
||||
- Browser / webclient on `http://localhost:4001`
|
||||
- admin surface under `/admin/`
|
||||
- Evennia default URLs appended via `evennia.web.urls`
|
||||
- Evennia REST/web surface inherits the default `/api/` patterns rather than defining custom project-specific endpoints here
|
||||
### Web API
|
||||
|
||||
### Operator / script surfaces
|
||||
- `python3 evennia/timmy_world/play_200.py`
|
||||
- importable pure-Python engine in `evennia/timmy_world/game.py`
|
||||
- alternate engine in `evennia/timmy_world/world/game.py`
|
||||
- `web/api/__init__.py` — Evennia REST API (Django REST Framework)
|
||||
- `web/urls.py` — URL routing for web interface
|
||||
- `web/admin/` — Django admin interface
|
||||
- `web/website/` — Web frontend
|
||||
|
||||
### Content/model surfaces
|
||||
- object prototype definitions: `evennia/timmy_world/world/prototypes.py`
|
||||
- file-based help entries: `evennia/timmy_world/world/help_entries.py`
|
||||
### Telnet
|
||||
|
||||
## Test Coverage Gaps
|
||||
- Standard MUD protocol on port 4000
|
||||
- Supports MCCP (compression), MSDP (data), GMCP (protocol)
|
||||
|
||||
### Current verified state
|
||||
The original genome here was stale. The live repo now shows two different categories of test coverage:
|
||||
### Hermes Bridge
|
||||
|
||||
1. Host-repo generated tests already exist in `tests/test_genome_generated.py`
|
||||
- they reference `evennia/timmy_world/game.py`
|
||||
- they reference `evennia/timmy_world/world/game.py`
|
||||
- they reference `server/conf/web_plugins.py`
|
||||
2. Those generated tests are not trustworthy as-is for this target
|
||||
- running `python3 -m pytest tests/test_genome_generated.py -k 'EvenniaTimmyWorld' -q -rs`
|
||||
- result: `19 skipped, 31 deselected`
|
||||
- skip reason on every case: `Module not importable`
|
||||
|
||||
This matters because the codebase-genome pipeline reported zero local tests for the subproject, but the host repo does contain tests. The real issue is not “no tests exist.” The real issue is “the existing generated tests are disconnected from the actual import path and therefore do not execute the critical path.”
|
||||
|
||||
### New critical-path tests added for #677
|
||||
This issue refresh adds a dedicated executable test file:
|
||||
- `tests/test_evennia_local_world_game.py`
|
||||
|
||||
Covered behaviors:
|
||||
- narrative phase boundaries across Quietus / Fracture / Breaking / Mending
|
||||
- player-facing action surface from the Threshold start state
|
||||
- deterministic `run_tick('move:north')` flow into the Tower with expected log and world-event output
|
||||
|
||||
### Genome artifact coverage added for #677
|
||||
This issue refresh also adds:
|
||||
- `tests/test_evennia_local_world_genome.py`
|
||||
|
||||
That test locks:
|
||||
- artifact path
|
||||
- required analysis sections
|
||||
- grounded snippets for real files and verification output
|
||||
|
||||
### Remaining gaps
|
||||
Still missing strong runtime coverage for:
|
||||
- Evennia typeclass behavior under a real Evennia test harness
|
||||
- URL routing under Django/Evennia integration
|
||||
- `world/game.py` parity versus root `game.py`
|
||||
- persistence portability around `/Users/apayne/.timmy/evennia/timmy_world`
|
||||
- `at_initial_setup.py` and `world/batch_cmds.ev` actually building a playable world in the Evennia path
|
||||
|
||||
## Security Considerations
|
||||
|
||||
1. Plaintext telnet exposure
|
||||
- `server/conf/mssp.py` advertises port `4000`
|
||||
- telnet is unencrypted by default
|
||||
- acceptable for localhost/dev, risky for exposed deployment
|
||||
|
||||
2. Hardcoded absolute persistence path
|
||||
- both `evennia/timmy_world/game.py` and `evennia/timmy_world/world/game.py` hardcode `/Users/apayne/.timmy/evennia/timmy_world`
|
||||
- this couples runtime writes to one operator machine and one home-directory layout
|
||||
- portability and accidental overwrite risk are both real
|
||||
- filed follow-up: `timmy-home #831` — `https://forge.alexanderwhitestone.com/Timmy_Foundation/timmy-home/issues/831`
|
||||
|
||||
3. Admin/web surfaces inherit defaults
|
||||
- `web/urls.py` exposes admin and Evennia defaults
|
||||
- if the service is made remotely reachable, Django/Evennia auth and proxy boundaries matter immediately
|
||||
|
||||
4. Secret handling is externalized but optional
|
||||
- `server/conf/settings.py` silently falls back if `secret_settings.py` is missing
|
||||
- convenient for local development, but secrets discipline lives outside the repo contract
|
||||
|
||||
5. Template hooks can hide missing security posture
|
||||
- `server/conf/web_plugins.py` is pass-through
|
||||
- `server/conf/at_initial_setup.py` is pass-through
|
||||
- the absence of custom code here means there are no local hardening hooks yet for startup, proxying, or world bootstrap
|
||||
- `hermes-agent/config.yaml` — Configuration for AI agent connection
|
||||
- Allows Hermes agents to connect as characters and interact with the world
|
||||
|
||||
## Dependencies
|
||||
|
||||
Directly evidenced imports and framework coupling:
|
||||
- Evennia 6.0 game-directory structure
|
||||
- Django via Evennia web/admin stack
|
||||
- Twisted via Evennia networking/web hooks
|
||||
- Python stdlib heavy use in standalone simulator:
|
||||
- `json`
|
||||
- `time`
|
||||
- `os`
|
||||
- `random`
|
||||
- `datetime`
|
||||
- `pathlib`
|
||||
- `sys`
|
||||
No `requirements.txt` or `pyproject.toml` found. Dependencies come from Evennia:
|
||||
|
||||
Dependency caveat:
|
||||
- the standalone Tower simulator is largely pure Python and importable in isolation
|
||||
- the typeclass / cmdset / web files depend on Evennia and Django runtime wiring to do real work
|
||||
- **evennia** — MUD framework (Django-based)
|
||||
- **django** — Web framework (via Evennia)
|
||||
- **twisted** — Async networking (via Evennia)
|
||||
|
||||
## Test Coverage Gaps
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| Source modules | 35 |
|
||||
| Test modules | 1 |
|
||||
| Estimated coverage | 0% |
|
||||
| Untested modules | 35 |
|
||||
|
||||
The academy test suite includes:
|
||||
- `tests/test_evennia_local_world_game.py` — live game integration
|
||||
- `tests/test_genome_generated.py` — auto-generated unit test stubs
|
||||
- `tests/test_evennia_local_world_genome.py` — validates this GENOME document
|
||||
- `tests/test_bezalel_evennia_layout.py` — spatial layout verification
|
||||
- `tests/test_evennia_mind_palace.py` — memory palace integration
|
||||
- `tests/test_evennia_telemetry.py` — event logging
|
||||
- `tests/test_evennia_training.py` — training workflow validation
|
||||
- `tests/test_evennia_vps_repair.py` — VPS repair script checks
|
||||
Additionally, **19 skipped** due to optional dependencies (e.g., Evennia not installed in the test environment).
|
||||
|
||||
### Critical Untested Paths
|
||||
|
||||
1. **AuditedCharacter** — audit logging is the primary value-add. No tests verify movement tracking, command counting, or playtime calculation.
|
||||
2. **Commands** — no tests for any of the 8 commands. The `@map` wing detection, `@who` session tracking, and atmosphere-based commands (`smell`, `listen`) are all untested.
|
||||
3. **World rebuild** — `rebuild_world.py` and `fix_world.py` can destroy and recreate the entire world. No tests ensure they produce valid output.
|
||||
4. **Typeclass hooks** — `at_pre_move`, `at_post_move`, `at_pre_cmd` etc. are never tested in isolation.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
- ⚠️ Uses `eval()`/`exec()` — Evennia's inlinefuncs module uses eval for dynamic command evaluation. Risk level: inherent to MUD framework.
|
||||
- ⚠️ References secrets/passwords — `settings.py` references `secret_settings.py` for sensitive config. Ensure this file is not committed.
|
||||
- ⚠️ Telnet on 0.0.0.0 — server accepts connections from any IP. Consider firewall rules.
|
||||
- ⚠️ Web client on 0.0.0.0 — same exposure as telnet. Ensure authentication is enforced.
|
||||
- ⚠️ Agent bridge (`hermes-agent/config.yaml`) — verify credentials are not hardcoded.
|
||||
|
||||
## Deployment
|
||||
|
||||
### Evennia path
|
||||
```bash
|
||||
cd evennia/timmy_world
|
||||
evennia migrate
|
||||
evennia start
|
||||
```
|
||||
Timmy Academy runs as an Evennia world on dedicated VPS and localhost.
|
||||
|
||||
Expected local surfaces from repo docs/config:
|
||||
- telnet: `localhost:4000`
|
||||
- browser/webclient: `http://localhost:4001`
|
||||
**Production (Bezalel VPS)** — telnet on port 4000, web client on 4001:
|
||||
- Telnet: `telnet 167.99.126.228 4000`
|
||||
- Web: `http://167.99.126.228:4001`
|
||||
|
||||
### Standalone simulation path
|
||||
```bash
|
||||
cd evennia/timmy_world
|
||||
python3 play_200.py
|
||||
```
|
||||
**Local development** — clone and run `evennia start --name timmy_world` from `evennia/timmy_world/`. The default runtime path is `/Users/apayne/.timmy/evennia/timmy_world`.
|
||||
|
||||
This does not require the full Evennia network stack. It exercises the root `game.py` engine directly.
|
||||
**Hermes bridge** — AI agents connect via the `hermes-agent` bridge, configured in `hermes-agent/config.yaml` to point at the local Evennia socket.
|
||||
|
||||
### Verification commands run for this genome refresh
|
||||
```bash
|
||||
python3 ~/.hermes/pipelines/codebase-genome.py --path /tmp/BURN-7-7/evennia/timmy_world --output /tmp/evennia-local-world-GENOME-base.md
|
||||
python3 -m pytest tests/test_genome_generated.py -k 'EvenniaTimmyWorld' -q -rs
|
||||
python3 -m pytest tests/test_evennia_local_world_genome.py tests/test_evennia_local_world_game.py -q
|
||||
python3 -m py_compile evennia/timmy_world/game.py evennia/timmy_world/world/game.py evennia/timmy_world/play_200.py evennia/timmy_world/server/conf/settings.py evennia/timmy_world/web/urls.py
|
||||
```
|
||||
## Configuration Files
|
||||
|
||||
## Key Findings
|
||||
- `server/conf/settings.py` — Main Evennia settings (server name, ports, typeclass paths)
|
||||
- `hermes-agent/config.yaml` — Hermes agent bridge configuration
|
||||
- `world/build_academy.ev` — Evennia batch build script
|
||||
- `world/batch_cmds.ev` — Batch command definitions
|
||||
|
||||
1. The current custom product logic is the standalone Tower simulator, not the Evennia typeclass layer.
|
||||
2. The repo contains two parallel simulation engines: `evennia/timmy_world/game.py` and `evennia/timmy_world/world/game.py`.
|
||||
3. The stock Evennia scaffolding is still mostly template code (`README.md`, `at_initial_setup.py`, `world/batch_cmds.ev`, pass-through cmdsets/web hooks).
|
||||
4. The codebase-genome pipeline undercounted test reality because subproject-local tests are absent while host-repo tests exist one level up.
|
||||
5. The existing generated tests were present but functionally inert: `19 skipped` because their import path does not match the current host-repo layout.
|
||||
6. The most concrete portability hazard is the hardcoded `/Users/apayne/.timmy/evennia/timmy_world` state path in both simulation engines.
|
||||
## What's Missing
|
||||
|
||||
1. **Tests** — 0% coverage is a critical gap. Priority: AuditedCharacter hooks, command func() methods, world rebuild integrity.
|
||||
2. **CI/CD** — No automated testing pipeline. No GitHub Actions or Gitea workflows.
|
||||
3. **Documentation** — `world/BUILDER_GUIDE.md` exists but no developer onboarding docs.
|
||||
4. **Monitoring** — No health checks, no metrics export, no alerting on server crashes.
|
||||
5. **Backup** — No automated database backup for the Evennia SQLite/PostgreSQL database.
|
||||
|
||||
---
|
||||
|
||||
This refreshed genome supersedes the earlier auto-generated `evennia/timmy_world/GENOME.md` summary by grounding the analysis in live source inspection, live import of `evennia/timmy_world/game.py`, current file metrics, and executable host-repo verification.
|
||||
*Generated by Codebase Genome Pipeline. Review and update manually.*
|
||||
|
||||
@@ -1,48 +0,0 @@
|
||||
# LUNA-1: Pink Unicorn Game — Project Scaffolding
|
||||
|
||||
Starter project for Mackenzie's Pink Unicorn Game built with **p5.js 1.9.0**.
|
||||
|
||||
## Quick Start
|
||||
|
||||
```bash
|
||||
cd luna
|
||||
python3 -m http.server 8080
|
||||
# Visit http://localhost:8080
|
||||
```
|
||||
|
||||
Or simply open `luna/index.html` directly in a browser.
|
||||
|
||||
## Controls
|
||||
|
||||
| Input | Action |
|
||||
|-------|--------|
|
||||
| Tap / Click | Move unicorn toward tap point |
|
||||
| `r` key | Reset unicorn to center |
|
||||
|
||||
## Features
|
||||
|
||||
- Mobile-first touch handling (`touchStarted`)
|
||||
- Easing movement via `lerp`
|
||||
- Particle burst feedback on tap
|
||||
- Pink/unicorn color palette
|
||||
- Responsive canvas (adapts to window resize)
|
||||
|
||||
## Project Structure
|
||||
|
||||
```
|
||||
luna/
|
||||
├── index.html # p5.js CDN import + canvas container
|
||||
├── sketch.js # Main game logic and rendering
|
||||
├── style.css # Pink/unicorn theme, responsive layout
|
||||
└── README.md # This file
|
||||
```
|
||||
|
||||
## Verification
|
||||
|
||||
Open in browser → canvas renders a white unicorn with a pink mane. Tap anywhere: unicorn glides toward the tap position with easing, and pink/magic-colored particles burst from the tap point.
|
||||
|
||||
## Technical Notes
|
||||
|
||||
- p5.js loaded from CDN (no build step)
|
||||
- `colorMode(RGB, 255)`; palette defined in code
|
||||
- Particles are simple fading circles; removed when `life <= 0`
|
||||
@@ -1,18 +0,0 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>LUNA-3: Simple World — Floating Islands</title>
|
||||
<script src="https://cdnjs.cloudflare.com/ajax/libs/p5.js/1.9.0/p5.min.js"></script>
|
||||
<link rel="stylesheet" href="style.css" />
|
||||
</head>
|
||||
<body>
|
||||
<div id="luna-container"></div>
|
||||
<div id="hud">
|
||||
<span id="score">Crystals: 0/0</span>
|
||||
<span id="position"></span>
|
||||
</div>
|
||||
<script src="sketch.js"></script>
|
||||
</body>
|
||||
</html>
|
||||
289
luna/sketch.js
289
luna/sketch.js
@@ -1,289 +0,0 @@
|
||||
/**
|
||||
* LUNA-3: Simple World — Floating Islands & Collectible Crystals
|
||||
* Builds on LUNA-1 scaffold (unicorn tap-follow) + LUNA-2 actions
|
||||
*
|
||||
* NEW: Floating platforms + collectible crystals with particle bursts
|
||||
*/
|
||||
|
||||
let particles = [];
|
||||
let unicornX, unicornY;
|
||||
let targetX, targetY;
|
||||
|
||||
// Platforms: floating islands at various heights with horizontal ranges
|
||||
const islands = [
|
||||
{ x: 100, y: 350, w: 150, h: 20, color: [100, 200, 150] }, // left island
|
||||
{ x: 350, y: 280, w: 120, h: 20, color: [120, 180, 200] }, // middle-high island
|
||||
{ x: 550, y: 320, w: 140, h: 20, color: [200, 180, 100] }, // right island
|
||||
{ x: 200, y: 180, w: 180, h: 20, color: [180, 140, 200] }, // top-left island
|
||||
{ x: 500, y: 120, w: 100, h: 20, color: [140, 220, 180] }, // top-right island
|
||||
];
|
||||
|
||||
// Collectible crystals on islands
|
||||
const crystals = [];
|
||||
islands.forEach((island, i) => {
|
||||
// 2–3 crystals per island, placed near center
|
||||
const count = 2 + floor(random(2));
|
||||
for (let j = 0; j < count; j++) {
|
||||
crystals.push({
|
||||
x: island.x + 30 + random(island.w - 60),
|
||||
y: island.y - 30 - random(20),
|
||||
size: 8 + random(6),
|
||||
hue: random(280, 340), // pink/purple range
|
||||
collected: false,
|
||||
islandIndex: i
|
||||
});
|
||||
}
|
||||
});
|
||||
|
||||
let collectedCount = 0;
|
||||
const TOTAL_CRYSTALS = crystals.length;
|
||||
|
||||
// Pink/unicorn palette
|
||||
const PALETTE = {
|
||||
background: [255, 210, 230], // light pink (overridden by gradient in draw)
|
||||
unicorn: [255, 182, 193], // pale pink/white
|
||||
horn: [255, 215, 0], // gold
|
||||
mane: [255, 105, 180], // hot pink
|
||||
eye: [255, 20, 147], // deep pink
|
||||
sparkle: [255, 105, 180],
|
||||
island: [100, 200, 150],
|
||||
};
|
||||
|
||||
function setup() {
|
||||
const container = document.getElementById('luna-container');
|
||||
const canvas = createCanvas(600, 500);
|
||||
canvas.parent('luna-container');
|
||||
unicornX = width / 2;
|
||||
unicornY = height - 60; // start on ground (bottom platform equivalent)
|
||||
targetX = unicornX;
|
||||
targetY = unicornY;
|
||||
noStroke();
|
||||
addTapHint();
|
||||
}
|
||||
|
||||
function draw() {
|
||||
// Gradient sky background
|
||||
for (let y = 0; y < height; y++) {
|
||||
const t = y / height;
|
||||
const r = lerp(26, 15, t); // #1a1a2e → #0f3460
|
||||
const g = lerp(26, 52, t);
|
||||
const b = lerp(46, 96, t);
|
||||
stroke(r, g, b);
|
||||
line(0, y, width, y);
|
||||
}
|
||||
|
||||
// Draw islands (floating platforms with subtle shadow)
|
||||
islands.forEach(island => {
|
||||
push();
|
||||
// Shadow
|
||||
fill(0, 0, 0, 40);
|
||||
ellipse(island.x + island.w/2 + 5, island.y + 5, island.w + 10, island.h + 6);
|
||||
// Island body
|
||||
fill(island.color[0], island.color[1], island.color[2]);
|
||||
ellipse(island.x + island.w/2, island.y, island.w, island.h);
|
||||
// Top highlight
|
||||
fill(255, 255, 255, 60);
|
||||
ellipse(island.x + island.w/2, island.y - island.h/3, island.w * 0.6, island.h * 0.3);
|
||||
pop();
|
||||
});
|
||||
|
||||
// Draw crystals (glowing collectibles)
|
||||
crystals.forEach(c => {
|
||||
if (c.collected) return;
|
||||
push();
|
||||
translate(c.x, c.y);
|
||||
// Glow aura
|
||||
const glow = color(`hsla(${c.hue}, 80%, 70%, 0.4)`);
|
||||
noStroke();
|
||||
fill(glow);
|
||||
ellipse(0, 0, c.size * 2.2, c.size * 2.2);
|
||||
// Crystal body (diamond shape)
|
||||
const ccol = color(`hsl(${c.hue}, 90%, 75%)`);
|
||||
fill(ccol);
|
||||
beginShape();
|
||||
vertex(0, -c.size);
|
||||
vertex(c.size * 0.6, 0);
|
||||
vertex(0, c.size);
|
||||
vertex(-c.size * 0.6, 0);
|
||||
endShape(CLOSE);
|
||||
// Inner sparkle
|
||||
fill(255, 255, 255, 180);
|
||||
ellipse(0, 0, c.size * 0.5, c.size * 0.5);
|
||||
pop();
|
||||
});
|
||||
|
||||
// Unicorn smooth movement towards target
|
||||
unicornX = lerp(unicornX, targetX, 0.08);
|
||||
unicornY = lerp(unicornY, targetY, 0.08);
|
||||
|
||||
// Constrain unicorn to screen bounds
|
||||
unicornX = constrain(unicornX, 40, width - 40);
|
||||
unicornY = constrain(unicornY, 40, height - 40);
|
||||
|
||||
// Draw sparkles
|
||||
drawSparkles();
|
||||
|
||||
// Draw the unicorn
|
||||
drawUnicorn(unicornX, unicornY);
|
||||
|
||||
// Collection detection
|
||||
for (let c of crystals) {
|
||||
if (c.collected) continue;
|
||||
const d = dist(unicornX, unicornY, c.x, c.y);
|
||||
if (d < 35) {
|
||||
c.collected = true;
|
||||
collectedCount++;
|
||||
createCollectionBurst(c.x, c.y, c.hue);
|
||||
}
|
||||
}
|
||||
|
||||
// Update particles
|
||||
updateParticles();
|
||||
|
||||
// Update HUD
|
||||
document.getElementById('score').textContent = `Crystals: ${collectedCount}/${TOTAL_CRYSTALS}`;
|
||||
document.getElementById('position').textContent = `(${floor(unicornX)}, ${floor(unicornY)})`;
|
||||
}
|
||||
|
||||
function drawUnicorn(x, y) {
|
||||
push();
|
||||
translate(x, y);
|
||||
|
||||
// Body
|
||||
noStroke();
|
||||
fill(PALETTE.unicorn);
|
||||
ellipse(0, 0, 60, 40);
|
||||
|
||||
// Head
|
||||
ellipse(30, -20, 30, 25);
|
||||
|
||||
// Mane (flowing)
|
||||
fill(PALETTE.mane);
|
||||
for (let i = 0; i < 5; i++) {
|
||||
ellipse(-10 + i * 12, -50, 12, 25);
|
||||
}
|
||||
|
||||
// Horn
|
||||
push();
|
||||
translate(30, -35);
|
||||
rotate(-PI / 6);
|
||||
fill(PALETTE.horn);
|
||||
triangle(0, 0, -8, -35, 8, -35);
|
||||
pop();
|
||||
|
||||
// Eye
|
||||
fill(PALETTE.eye);
|
||||
ellipse(38, -22, 8, 8);
|
||||
|
||||
// Legs
|
||||
stroke(PALETTE.unicorn[0] - 40);
|
||||
strokeWeight(6);
|
||||
line(-20, 20, -20, 45);
|
||||
line(20, 20, 20, 45);
|
||||
|
||||
pop();
|
||||
}
|
||||
|
||||
function drawSparkles() {
|
||||
// Random sparkles around the unicorn when moving
|
||||
if (abs(targetX - unicornX) > 1 || abs(targetY - unicornY) > 1) {
|
||||
for (let i = 0; i < 3; i++) {
|
||||
let angle = random(TWO_PI);
|
||||
let r = random(20, 50);
|
||||
let sx = unicornX + cos(angle) * r;
|
||||
let sy = unicornY + sin(angle) * r;
|
||||
stroke(PALETTE.sparkle[0], PALETTE.sparkle[1], PALETTE.sparkle[2], 150);
|
||||
strokeWeight(2);
|
||||
point(sx, sy);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function createCollectionBurst(x, y, hue) {
|
||||
// Burst of particles spiraling outward
|
||||
for (let i = 0; i < 20; i++) {
|
||||
let angle = random(TWO_PI);
|
||||
let speed = random(2, 6);
|
||||
particles.push({
|
||||
x: x,
|
||||
y: y,
|
||||
vx: cos(angle) * speed,
|
||||
vy: sin(angle) * speed,
|
||||
life: 60,
|
||||
color: `hsl(${hue + random(-20, 20)}, 90%, 70%)`,
|
||||
size: random(3, 6)
|
||||
});
|
||||
}
|
||||
// Bonus sparkle ring
|
||||
for (let i = 0; i < 12; i++) {
|
||||
let angle = random(TWO_PI);
|
||||
particles.push({
|
||||
x: x,
|
||||
y: y,
|
||||
vx: cos(angle) * 4,
|
||||
vy: sin(angle) * 4,
|
||||
life: 40,
|
||||
color: 'rgba(255, 215, 0, 0.9)',
|
||||
size: 4
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
function updateParticles() {
|
||||
for (let i = particles.length - 1; i >= 0; i--) {
|
||||
let p = particles[i];
|
||||
p.x += p.vx;
|
||||
p.y += p.vy;
|
||||
p.vy += 0.1; // gravity
|
||||
p.life--;
|
||||
p.vx *= 0.95;
|
||||
p.vy *= 0.95;
|
||||
if (p.life <= 0) {
|
||||
particles.splice(i, 1);
|
||||
continue;
|
||||
}
|
||||
push();
|
||||
stroke(p.color);
|
||||
strokeWeight(p.size);
|
||||
point(p.x, p.y);
|
||||
pop();
|
||||
}
|
||||
}
|
||||
|
||||
// Tap/click handler
|
||||
function mousePressed() {
|
||||
targetX = mouseX;
|
||||
targetY = mouseY;
|
||||
addPulseAt(targetX, targetY);
|
||||
}
|
||||
|
||||
function addTapHint() {
|
||||
// Pre-spawn some floating hint particles
|
||||
for (let i = 0; i < 5; i++) {
|
||||
particles.push({
|
||||
x: random(width),
|
||||
y: random(height),
|
||||
vx: random(-0.5, 0.5),
|
||||
vy: random(-0.5, 0.5),
|
||||
life: 200,
|
||||
color: 'rgba(233, 69, 96, 0.5)',
|
||||
size: 3
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
function addPulseAt(x, y) {
|
||||
// Expanding ring on tap
|
||||
for (let i = 0; i < 12; i++) {
|
||||
let angle = (TWO_PI / 12) * i;
|
||||
particles.push({
|
||||
x: x,
|
||||
y: y,
|
||||
vx: cos(angle) * 3,
|
||||
vy: sin(angle) * 3,
|
||||
life: 30,
|
||||
color: 'rgba(233, 69, 96, 0.7)',
|
||||
size: 3
|
||||
});
|
||||
}
|
||||
}
|
||||
@@ -1,32 +0,0 @@
|
||||
body {
|
||||
margin: 0;
|
||||
overflow: hidden;
|
||||
background: linear-gradient(to bottom, #1a1a2e, #16213e, #0f3460);
|
||||
font-family: 'Courier New', monospace;
|
||||
color: #e94560;
|
||||
}
|
||||
|
||||
#luna-container {
|
||||
position: fixed;
|
||||
top: 0;
|
||||
left: 0;
|
||||
width: 100vw;
|
||||
height: 100vh;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
}
|
||||
|
||||
#hud {
|
||||
position: fixed;
|
||||
top: 10px;
|
||||
left: 10px;
|
||||
background: rgba(0, 0, 0, 0.6);
|
||||
padding: 8px 12px;
|
||||
border-radius: 4px;
|
||||
font-size: 14px;
|
||||
z-index: 100;
|
||||
border: 1px solid #e94560;
|
||||
}
|
||||
|
||||
#score { font-weight: bold; }
|
||||
@@ -1,130 +0,0 @@
|
||||
# Fleet Operator Incentives & Partner Program
|
||||
|
||||
> Implements Fleet Epic IV: Human Capital & Incentives (Issue #987)
|
||||
> Closes #1003
|
||||
|
||||
## Overview
|
||||
|
||||
This specification defines the incentive structures, certification pathways, and partner program mechanics for operating and maintaining Timmy Fleet nodes. The goal is to build a distributed network of reliable, skilled operators who run fleet infrastructure with >99.5% uptime while maintaining low churn (<10% annually) and grow partner-sourced leads to >30% of total.
|
||||
|
||||
## Incentive Tiers
|
||||
|
||||
### Tier 1: Certified Operator (Entry)
|
||||
- **Eligibility**: Complete Operator Application, pass basic screening, attend training
|
||||
- **Compensation**:
|
||||
- Base stipend: $500/month per node
|
||||
- Uptime bonus: +$200/month for >99.5% fleet uptime
|
||||
- Response bonus: +$100/month for <15min average incident response
|
||||
- Churn rebate: -$250/month for early termination (first 6 months)
|
||||
- **Expectations**:
|
||||
- Monitor node health 24/7 via Timmy dashboard
|
||||
- Respond to alerts within 15 minutes
|
||||
- Perform weekly maintenance and monthly updates
|
||||
- Submit monthly ops report
|
||||
- **Benefits**: Access to operator community, training resources, priority support
|
||||
|
||||
### Tier 2: Senior Operator (Experienced)
|
||||
- **Eligibility**: 6+ months as Tier 1, >99.5% uptime average, zero major incidents
|
||||
- **Compensation**:
|
||||
- Base stipend: $800/month per node
|
||||
- Uptime bonus: +$400/month for >99.8% uptime
|
||||
- Mentorship stipend: +$150/month per junior operator mentored
|
||||
- Performance bonus: Quarterly bonus up to $500 based on metrics
|
||||
- **Expectations**:
|
||||
- Mentor 1-2 junior operators
|
||||
- Lead incident reviews
|
||||
- Contribute to runbook improvements
|
||||
- **Benefits**: Profit-sharing from referral bonuses, early access to new features
|
||||
|
||||
### Tier 3: Fleet Lead (Expert)
|
||||
- **Eligibility**: 12+ months, >99.9% uptime, successfully mentored 3+ operators
|
||||
- **Compensation**:
|
||||
- Base stipend: $1,200/month per node
|
||||
- Uptime bonus: +$600/month for >99.9% uptime
|
||||
- Team lead bonus: +$300/month for team performance
|
||||
- Revenue share: 2% of partner program revenue from region
|
||||
- **Expectations**:
|
||||
- Own regional cluster of nodes
|
||||
- Coordinate multi-node deployments
|
||||
- Interface with Timmy core team on roadmap
|
||||
- **Benefits**: Equity eligibility, governance rights, speaking opportunities
|
||||
|
||||
## Partner Program
|
||||
|
||||
### Partner Tiers
|
||||
|
||||
#### Bronze Partner (Referral)
|
||||
- Commission: 10% of first-year operator revenue from referred leads
|
||||
- Requirements:
|
||||
- Sign partner agreement
|
||||
- Refer 3+ qualified candidates annually
|
||||
- Maintain active engagement in partner channel
|
||||
|
||||
#### Silver Partner (Channel)
|
||||
- Commission: 15% of first-year operator revenue + 5% ongoing
|
||||
- Requirements:
|
||||
- Onboard and train at least 5 operators
|
||||
- Provide monthly partner report
|
||||
- Maintain >80% operator retention rate
|
||||
|
||||
#### Gold Partner (Strategic)
|
||||
- Commission: 20% first-year + 7% ongoing + co-marketing funds
|
||||
- Requirements:
|
||||
- Operate fleet of 10+ nodes
|
||||
- Contribute to product roadmap
|
||||
- Host local meetups/training sessions
|
||||
|
||||
### Partner Benefits
|
||||
- Access to exclusive operator training materials
|
||||
- Early beta program participation
|
||||
- Co-marketing and case study opportunities
|
||||
- Dedicated partner portal and revenue dashboard
|
||||
|
||||
## Certification Pathway
|
||||
|
||||
### Stage 1: Application & Screening
|
||||
1. Submit Operator Application (see `templates/operator-application.md`)
|
||||
2. Technical interview (30 min)
|
||||
3. Infrastructure audit (existing hardware/network)
|
||||
4. Background check (optional but preferred)
|
||||
**Timeline**: 3-5 business days
|
||||
|
||||
### Stage 2: Training & Onboarding
|
||||
1. Complete Fleet Ops 101 module (2 hours self-paced)
|
||||
2. Shadow a senior operator (2 weeks)
|
||||
3. Deploy test node (sandbox environment)
|
||||
4. Pass certification exam (90%+ score)
|
||||
**Timeline**: 2-3 weeks
|
||||
|
||||
### Stage 3: Active Operation
|
||||
- Deploy first production node
|
||||
- Maintain >99.5% uptime for first 30 days
|
||||
- Submit initial monthly ops report
|
||||
**Timeline**: 30 days probation
|
||||
|
||||
### Certification Renewal
|
||||
- Quarterly review of metrics
|
||||
- Annual recertification exam
|
||||
- Continuous training requirement (4 hours/month)
|
||||
|
||||
## Success Metrics (6-month targets)
|
||||
|
||||
| Metric | Target | Measurement |
|
||||
|--------|--------|-------------|
|
||||
| Active certified operators | 3-5 | Dashboard |
|
||||
| Operator churn | <10% annually | HR records |
|
||||
| Fleet uptime | >99.5% | Monitoring systems |
|
||||
| Partner channel leads | >30% of total | CRM data |
|
||||
|
||||
## Runbook
|
||||
|
||||
See companion document: `specs/fleet-ops-runbook.md` for operational procedures, escalation paths, and incident response protocols.
|
||||
|
||||
## Templates
|
||||
|
||||
- **Operator Application**: `templates/operator-application.md`
|
||||
- **Partner Report**: `templates/partner-report.md`
|
||||
|
||||
## Revision History
|
||||
|
||||
- 2025-05-02: Initial specification (implements #987, closes #1003)
|
||||
@@ -1,291 +0,0 @@
|
||||
# Fleet Operations Runbook
|
||||
|
||||
> Fleet Operator Incentives & Partner Program — Operational Procedures
|
||||
> Implements #987 | Closes #1003
|
||||
|
||||
## Table of Contents
|
||||
|
||||
1. [Daily Ops Checklist](#daily-ops-checklist)
|
||||
2. [Weekly Maintenance](#weekly-maintenance)
|
||||
3. [Monthly Responsibilities](#monthly-responsibilities)
|
||||
4. [Incident Response](#incident-response)
|
||||
5. [Escalation Paths](#escalation-paths)
|
||||
6. [Communication Protocols](#communication-protocols)
|
||||
7. [Node Deployment](#node-deployment)
|
||||
8. [Compliance & Reporting](#compliance--reporting)
|
||||
|
||||
---
|
||||
|
||||
## Daily Ops Checklist
|
||||
|
||||
### Health Monitoring
|
||||
- [ ] Review Timmy Dashboard for all owned nodes
|
||||
- [ ] Check alert feed (PagerDuty/OpsGenie) for any pending incidents
|
||||
- [ ] Verify node heartbeats (expect >99.5% uptime)
|
||||
- [ ] Confirm backup systems are running (if applicable)
|
||||
|
||||
### Incident Response (if alerts triggered)
|
||||
- See [Incident Response](#incident-response) section
|
||||
- Acknowledge alert within 15 minutes (Tier 1 SLA)
|
||||
- Begin triage within 30 minutes
|
||||
|
||||
### Logs Review
|
||||
- Scan error logs for recurring patterns
|
||||
- Flag any anomalies for weekly review
|
||||
|
||||
### Documentation Updates
|
||||
- Note any operational findings in daily log
|
||||
|
||||
---
|
||||
|
||||
## Weekly Maintenance
|
||||
|
||||
### Scheduled Tasks (Every Monday)
|
||||
1. **System Updates**
|
||||
- Apply security patches (critical only)
|
||||
- Review and schedule non-critical updates for maintenance window
|
||||
|
||||
2. **Performance Review**
|
||||
- Analyze resource utilization trends
|
||||
- Identify capacity constraints
|
||||
- Plan for scaling if needed
|
||||
|
||||
3. **Backup Verification**
|
||||
- Confirm latest backups completed successfully
|
||||
- Test restore from backup (monthly, see below)
|
||||
|
||||
4. **Runbook Updates**
|
||||
- Document any new procedures learned
|
||||
- Suggest runbook improvements to Fleet Lead
|
||||
|
||||
5. **Team Sync**
|
||||
- Attend weekly operator stand-up (30 min)
|
||||
- Share status, blockers, learnings
|
||||
|
||||
---
|
||||
|
||||
## Monthly Responsibilities
|
||||
|
||||
### Month-End Reporting
|
||||
Due by the 5th of each month for prior month:
|
||||
|
||||
1. **Ops Report** (use `templates/partner-report.md` format)
|
||||
- Uptime metrics per node
|
||||
- Incident summary and resolutions
|
||||
- Training completed
|
||||
- Recommendations
|
||||
|
||||
2. **Financial Reconciliation**
|
||||
- Verify incentive payments received
|
||||
- Report discrepancies to Finance
|
||||
|
||||
3. **Compliance Audit**
|
||||
- Confirm certification requirements met
|
||||
- Document any deviations and corrective actions
|
||||
|
||||
### Deep Maintenance
|
||||
- Full system backup and restore test
|
||||
- Security audit review
|
||||
- Hardware inspection (if physical nodes)
|
||||
- Training module completion (minimum 4 hours/month)
|
||||
|
||||
---
|
||||
|
||||
## Incident Response
|
||||
|
||||
### Severity Definitions
|
||||
|
||||
| Severity | Definition | Response Time | Resolution Target |
|
||||
|----------|------------|---------------|-------------------|
|
||||
| P0 | Fleet-wide outage, no nodes operational | 15 minutes | 4 hours |
|
||||
| P1 | Region/node cluster outage, >50% down | 30 minutes | 8 hours |
|
||||
| P2 | Single node failure | 1 hour | 24 hours |
|
||||
| P3 | Degraded performance, not critical | 4 hours | 3 days |
|
||||
|
||||
### Response Procedure
|
||||
|
||||
#### P0/P1 Incidents
|
||||
1. Acknowledge alert immediately
|
||||
2. Declare incident in `#fleet-incidents` Slack channel
|
||||
3. Notify Fleet Lead (direct message/call)
|
||||
4. Execute recovery procedures from relevant playbook
|
||||
5. Document timeline and actions taken
|
||||
6. Schedule post-mortem within 48 hours
|
||||
|
||||
#### P2 Incidents
|
||||
1. Acknowledge within 1 hour
|
||||
2. Open incident ticket in tracking system
|
||||
3. Follow single-node recovery playbook
|
||||
4. Report resolution in daily ops log
|
||||
|
||||
#### P3 Incidents
|
||||
1. Log in issue tracker
|
||||
2. Schedule during next maintenance window
|
||||
3. Document resolution upon completion
|
||||
|
||||
### Recovery Playbooks
|
||||
|
||||
#### Node Restart (most common P2)
|
||||
1. SSH to node (or use remote management)
|
||||
2. Check system logs (`/var/log/timmy/fleet.log`)
|
||||
3. Restart service: `sudo systemctl restart timmy-fleet`
|
||||
4. Verify node rejoins cluster
|
||||
5. Monitor for 30 minutes post-recovery
|
||||
|
||||
#### Network Partition
|
||||
1. Verify network connectivity (ping, traceroute)
|
||||
2. Check firewall rules
|
||||
3. Contact network provider if external
|
||||
4. Switch to backup connection if available
|
||||
5. Document root cause
|
||||
|
||||
#### Storage Full
|
||||
1. Identify large directories (`du -sh /* | sort -hr`)
|
||||
2. Rotate logs: `sudo logrotate -f /etc/logrotate.d/timmy`
|
||||
3. Clean temporary files
|
||||
4. Expand storage or add new volume
|
||||
5. Alert Fleet Lead for capacity planning
|
||||
|
||||
---
|
||||
|
||||
## Escalation Paths
|
||||
|
||||
### Tiered Support Model
|
||||
|
||||
```
|
||||
Operator (Tier 1)
|
||||
↓ (15 min SLA)
|
||||
Senior Operator / Fleet Lead (Tier 2)
|
||||
↓ (1 hour SLA)
|
||||
Timmy Core Team (Tier 3)
|
||||
↓ (Immediate)
|
||||
Executive Sponsor (Critical only)
|
||||
```
|
||||
|
||||
### Contact Matrix
|
||||
|
||||
| Issue Type | Primary Contact | Secondary |
|
||||
|------------|----------------|-----------|
|
||||
| Technical incident | Fleet Lead | Timmy Core |
|
||||
| Payment/incentive | Finance Partner | Fleet Lead |
|
||||
| Training/certification | Training Coordinator | Fleet Lead |
|
||||
| Partnership inquiry | Partner Manager | Executive Sponsor |
|
||||
| Security incident | Security Team | Timmy Core (immediate) |
|
||||
|
||||
### Emergency Contacts
|
||||
- Fleet Lead: `fleet-lead@timmy.foundation` (Slack: @fleet-lead)
|
||||
- Timmy Core On-Call: `oncall@timmy.foundation` (PagerDuty)
|
||||
- Security: `security@timmy.foundation`
|
||||
- Finance: `finance@timmy.foundation`
|
||||
|
||||
---
|
||||
|
||||
## Communication Protocols
|
||||
|
||||
### Channels
|
||||
- `#fleet-operators` — Daily ops, questions
|
||||
- `#fleet-incidents` — Active incidents only
|
||||
- `#fleet-training` — Training resources, scheduling
|
||||
- `#fleet-partners` — Partner program discussions
|
||||
|
||||
### Status Updates
|
||||
- Daily: Stand-up notes in thread
|
||||
- Weekly: Summary post in `#fleet-operators`
|
||||
- Monthly: Ops report submission
|
||||
- Incident: Real-time updates in `#fleet-incidents`
|
||||
|
||||
### Documentation Standards
|
||||
- Use clear, concise language
|
||||
- Include timestamps in UTC
|
||||
- Link to relevant tickets/PRs
|
||||
- Tag stakeholders with `@`
|
||||
|
||||
---
|
||||
|
||||
## Node Deployment
|
||||
|
||||
### Pre-Deployment Checklist
|
||||
- [ ] Hardware meets minimum specs (CPU, RAM, storage)
|
||||
- [ ] Network connectivity validated
|
||||
- [ ] Firewall rules configured
|
||||
- [ ] SSH keys exchanged with Timmy core team
|
||||
- [ ] Monitoring agent installed
|
||||
- [ ] Backup solution active
|
||||
- [ ] Documentation updated with node details
|
||||
|
||||
### Deployment Steps
|
||||
1. Provision hardware/VM
|
||||
2. Install Timmy Fleet software
|
||||
3. Configure node ID and credentials
|
||||
4. Join cluster via `timmy-fleet join <cluster-endpoint>`
|
||||
5. Validate connectivity and heartbeat
|
||||
6. Update inventory spreadsheet
|
||||
7. Set up monitoring alerts
|
||||
8. Complete handover to operator
|
||||
|
||||
### Decommissioning
|
||||
1. Drain node from cluster
|
||||
2. Migrate workloads
|
||||
3. Backup final state
|
||||
4. Shut down cleanly
|
||||
5. Update inventory
|
||||
6. Notify relevant teams
|
||||
|
||||
---
|
||||
|
||||
## Compliance & Reporting
|
||||
|
||||
### Metrics to Track
|
||||
- Uptime (node-level and fleet-wide)
|
||||
- Incident count and severity
|
||||
- Response and resolution times
|
||||
- Training hours completed
|
||||
- Payment/compensation accuracy
|
||||
|
||||
### Reporting Cadence
|
||||
- **Daily**: Ops dashboard (automated)
|
||||
- **Weekly**: Status summary (operator)
|
||||
- **Monthly**: Partner report (template-driven)
|
||||
- **Quarterly**: Performance review with Fleet Lead
|
||||
|
||||
### Audits
|
||||
- Quarterly internal audit by Timmy compliance team
|
||||
- Annual external certification renewal
|
||||
- Ad-hoc security reviews as needed
|
||||
|
||||
---
|
||||
|
||||
## Appendix: Resources
|
||||
|
||||
### Useful Commands
|
||||
```bash
|
||||
# Check service status
|
||||
sudo systemctl status timmy-fleet
|
||||
|
||||
# View logs
|
||||
journalctl -u timmy-fleet -f
|
||||
|
||||
# Restart node
|
||||
sudo systemctl restart timmy-fleet
|
||||
|
||||
# Check node health
|
||||
timmy-fleet health
|
||||
|
||||
# Join cluster
|
||||
timmy-fleet join <cluster-endpoint>
|
||||
```
|
||||
|
||||
### Key Files
|
||||
- Config: `/etc/timmy/fleet/config.yaml`
|
||||
- Logs: `/var/log/timmy/fleet.log`
|
||||
- Health data: `/var/lib/timmy/fleet/health.json`
|
||||
|
||||
### Support Resources
|
||||
- Internal Wiki: `https://wiki.timmy.foundation/fleet`
|
||||
- Operator Portal: `https://fleet.timmy.foundation`
|
||||
- Training Videos: `https://learn.timmy.foundation/fleet-ops`
|
||||
|
||||
---
|
||||
|
||||
**Last Updated**: 2025-05-02
|
||||
**Next Review**: 2025-06-02
|
||||
@@ -1,143 +0,0 @@
|
||||
# Fleet Operator Application
|
||||
|
||||
> {{APPLICATION_DATE}}
|
||||
> Candidate: {{CANDIDATE_NAME}}
|
||||
|
||||
## Contact Information
|
||||
|
||||
**Full Name**: {{CANDIDATE_FULL_NAME}}
|
||||
**Email**: {{CANDIDATE_EMAIL}}
|
||||
**Phone**: {{CANDIDATE_PHONE}}
|
||||
**Location**: {{CANDIDATE_LOCATION}}
|
||||
**Time Zone**: {{CANDIDATE_TIMEZONE}}
|
||||
|
||||
### Availability
|
||||
- **Hours per week**: {{AVAILABILITY_HOURS}}
|
||||
- **Primary availability window (UTC)**: {{AVAILABILITY_WINDOW}}
|
||||
- **On-call flexibility**: {{ONCALL_FLEXIBILITY}}
|
||||
|
||||
## Technical Qualifications
|
||||
|
||||
### Experience
|
||||
```
|
||||
Years in IT/DevOps: {{YEARS_EXPERIENCE}}
|
||||
Relevant roles:
|
||||
{{ROLE_HISTORY}}
|
||||
```
|
||||
|
||||
### Skills (check all that apply)
|
||||
- [ ] Linux system administration
|
||||
- [ ] Container orchestration (Kubernetes/Docker)
|
||||
- [ ] Cloud infrastructure (AWS/GCP/Azure)
|
||||
- [ ] Networking fundamentals
|
||||
- [ ] Monitoring & alerting (Prometheus/Grafana)
|
||||
- [ ] Incident response/ITIL
|
||||
- [ ] Security best practices
|
||||
- [ ] Automation (Ansible/Terraform)
|
||||
- [ ] Scripting (Python/Bash/Go)
|
||||
- [ ] Timmy platform experience
|
||||
|
||||
**Additional skills**: {{ADDITIONAL_SKILLS}}
|
||||
|
||||
### Certifications
|
||||
{{CERTIFICATIONS}}
|
||||
|
||||
## Infrastructure Readiness
|
||||
|
||||
### Proposed Node Environment
|
||||
- **Type**: ☐ Physical ☐ Cloud VM ☐ Hybrid
|
||||
- **Provider**: {{CLOUD_PROVIDER}}
|
||||
- **Region**: {{REGION}}
|
||||
- **Hardware specs**:
|
||||
- CPU: {{CPU_SPEC}}
|
||||
- RAM: {{RAM_SPEC}}
|
||||
- Storage: {{STORAGE_SPEC}}
|
||||
- Network: {{NETWORK_SPEC}}
|
||||
|
||||
### Redundancy & HA
|
||||
- [ ] Backup power (UPS/generator)
|
||||
- [ ] Secondary internet connection
|
||||
- [ ] Off-site backup solution
|
||||
- [ ] Remote management (IPMI/iDRAC)
|
||||
|
||||
### Connectivity
|
||||
- **Bandwidth**: {{BANDWIDTH}} Mbps
|
||||
- **Latency to Timmy core**: {{LATENCY}} ms
|
||||
- **Uptime SLA**: {{UPTIME_SLA}}
|
||||
|
||||
---
|
||||
|
||||
## Motivation & Alignment
|
||||
|
||||
### Why do you want to run a Timmy Fleet node?
|
||||
{{MOTIVATION}}
|
||||
|
||||
### What attracts you to decentralized infrastructure?
|
||||
{{DECENTRALIZATION_MOTIVATION}}
|
||||
|
||||
### How does this align with your long-term goals?
|
||||
{{LONG_TERM_GOALS}}
|
||||
|
||||
---
|
||||
|
||||
## Partner Program Interest (Optional)
|
||||
|
||||
### Interested in?
|
||||
- [ ] Referral partner (refer operators, earn commission)
|
||||
- [ ] Channel partner (onboard and train operators)
|
||||
- [ ] Strategic partner (run fleet of 10+ nodes)
|
||||
|
||||
### Existing network
|
||||
{{PARTNER_NETWORK}}
|
||||
|
||||
### Referral pipeline
|
||||
{{REFERRAL_PIPELINE}}
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
### Professional References
|
||||
1. Name: {{REF1_NAME}}
|
||||
Email: {{REF1_EMAIL}}
|
||||
Relationship: {{REF1_RELATION}}
|
||||
|
||||
2. Name: {{REF2_NAME}}
|
||||
Email: {{REF2_EMAIL}}
|
||||
Relationship: {{REF2_RELATION}}
|
||||
|
||||
### Timmy Community Involvement
|
||||
{{COMMUNITY_INVOLVEMENT}}
|
||||
|
||||
---
|
||||
|
||||
## Agreement & Signatures
|
||||
|
||||
### Code of Conduct
|
||||
- [ ] I have read and agree to the Timmy Fleet Operator Code of Conduct
|
||||
- [ ] I understand the uptime and response time requirements
|
||||
- [ ] I agree to the incentive structure and terms
|
||||
|
||||
### Signature
|
||||
**Candidate signature**: ___________________________
|
||||
**Date**: {{SIGNATURE_DATE}}
|
||||
|
||||
**Timmy representative**: ___________________________
|
||||
**Date**: {{TIMPY_SIGN_DATE}}
|
||||
|
||||
---
|
||||
|
||||
## Internal Use Only
|
||||
|
||||
**Interviewer**: {{INTERVIEWER}}
|
||||
**Technical score**: {{TECH_SCORE}}/100
|
||||
**Culture fit**: {{CULTURE_FIT}}/50
|
||||
**Infrastructure audit**: ☐ Pass ☐ Fail
|
||||
**Background check**: ☐ Complete ☐ In-progress
|
||||
|
||||
**Decision**: ☐ Approved ☐ Rejected ☐ Waitlist
|
||||
|
||||
**Comments**: {{INTERNAL_COMMENTS}}
|
||||
|
||||
**Certification ID**: {{CERT_ID}}
|
||||
**Onboarding start date**: {{ONBOARDING_DATE}}
|
||||
@@ -1,175 +0,0 @@
|
||||
# Fleet Partner Monthly Report
|
||||
|
||||
> {{REPORT_MONTH}} {{REPORT_YEAR}}
|
||||
> Partner: {{PARTNER_NAME}} ({{PARTNER_TIER}})
|
||||
> Submitted: {{SUBMISSION_DATE}}
|
||||
|
||||
## Executive Summary
|
||||
|
||||
| Metric | Current Month | Target | Variance |
|
||||
|--------|---------------|--------|----------|
|
||||
| Active nodes managed | {{ACTIVE_NODES}} | {{TARGET_NODES}} | {{NODES_VARIANCE}} |
|
||||
| Fleet uptime | {{UPTIME}}% | 99.5% | {{UPTIME_VARIANCE}}% |
|
||||
| Operator churn rate | {{CHURN_RATE}}% | <10% | {{CHURN_VARIANCE}}% |
|
||||
| Partner-sourced leads | {{LEADS_COUNT}} | {{LEADS_TARGET}} | {{LEADS_VARIANCE}} |
|
||||
| Revenue share earned | {{REVENUE}} | — | — |
|
||||
|
||||
**Key highlights**:
|
||||
{{KEY_HIGHLIGHTS}}
|
||||
|
||||
**Top concerns**:
|
||||
{{KEY_CONCERNS}}
|
||||
|
||||
---
|
||||
|
||||
## Node Performance
|
||||
|
||||
### Node Inventory
|
||||
|
||||
| Node ID | Location | Status | Uptime (30d) | Revenue Share | Issues |
|
||||
|---------|----------|--------|--------------|---------------|---------|
|
||||
| {{NODE_1_ID}} | {{NODE_1_LOC}} | {{NODE_1_STATUS}} | {{NODE_1_UPTIME}}% | ${{NODE_1_REV}} | {{NODE_1_ISSUES}} |
|
||||
| {{NODE_2_ID}} | {{NODE_2_LOC}} | {{NODE_2_STATUS}} | {{NODE_2_UPTIME}}% | ${{NODE_2_REV}} | {{NODE_2_ISSUES}} |
|
||||
| {{NODE_3_ID}} | {{NODE_3_LOC}} | {{NODE_3_STATUS}} | {{NODE_3_UPTIME}}% | ${{NODE_3_REV}} | {{NODE_3_ISSUES}} |
|
||||
|
||||
*Add rows as needed*
|
||||
|
||||
### Top Node Performers
|
||||
1. **{{TOP_NODE_1_ID}}**: {{TOP_NODE_1_UPTIME}}% uptime, zero incidents
|
||||
2. **{{TOP_NODE_2_ID}}**: {{TOP_NODE_2_UPTIME}}% uptime, quickest response times
|
||||
|
||||
### Nodes Requiring Attention
|
||||
1. **{{ATTN_NODE_1_ID}}**: {{ATTN_NODE_1_ISSUE}}
|
||||
2. **{{ATTN_NODE_2_ID}}**: {{ATTN_NODE_2_ISSUE}}
|
||||
|
||||
---
|
||||
|
||||
## Incidents & Resolutions
|
||||
|
||||
### Incident Log
|
||||
|
||||
| Date | Severity | Node(s) | Duration | Root Cause | Resolution |
|
||||
|------|----------|---------|----------|------------|------------|
|
||||
| {{INC1_DATE}} | {{INC1_SEV}} | {{INC1_NODES}} | {{INC1_DURATION}} | {{INC1_CAUSE}} | {{INC1_RES}} |
|
||||
| {{INC2_DATE}} | {{INC2_SEV}} | {{INC2_NODES}} | {{INC2_DURATION}} | {{INC2_CAUSE}} | {{INC2_RES}} |
|
||||
| {{INC3_DATE}} | {{INC3_SEV}} | {{INC3_NODES}} | {{INC3_DURATION}} | {{INC3_CAUSE}} | {{INC3_RES}} |
|
||||
|
||||
*Add rows as needed*
|
||||
|
||||
### Mean Time to Recovery (MTTR)
|
||||
- **P0 incidents**: {{MTTR_P0}} hours
|
||||
- **P1 incidents**: {{MTTR_P1}} hours
|
||||
- **P2 incidents**: {{MTTR_P2}} hours
|
||||
- **P3 incidents**: {{MTTR_P3}} hours
|
||||
|
||||
**Improvement opportunities**:
|
||||
{{MTTR_IMPROVEMENTS}}
|
||||
|
||||
---
|
||||
|
||||
## Operator Management
|
||||
|
||||
### Active Operators
|
||||
|
||||
| Operator | Tier | Nodes Managed | Status | Cert Date |
|
||||
|----------|------|---------------|--------|-----------|
|
||||
| {{OP1_NAME}} | {{OP1_TIER}} | {{OP1_NODES}} | {{OP1_STATUS}} | {{OP1_CERT}} |
|
||||
| {{OP2_NAME}} | {{OP2_TIER}} | {{OP2_NODES}} | {{OP2_STATUS}} | {{OP2_CERT}} |
|
||||
|
||||
### Churn / Attrition
|
||||
- **Departed operators**: {{DEPARTED_COUNT}}
|
||||
- **Departure reasons**: {{DEPARTURE_REASONS}}
|
||||
- **Retention initiatives**: {{RETENTION_INITIATIVES}}
|
||||
|
||||
### Training & Certification
|
||||
- **New certifications**: {{NEW_CERTS}}
|
||||
- **Training hours logged**: {{TRAINING_HOURS}}
|
||||
- **Upcoming recertifications**: {{UPCOMING_RECERTS}}
|
||||
|
||||
---
|
||||
|
||||
## Partner Program Metrics
|
||||
|
||||
### Lead Generation
|
||||
- **Total leads received**: {{TOTAL_LEADS}}
|
||||
- **Qualified leads**: {{QUALIFIED_LEADS}}
|
||||
- **Converted to operators**: {{CONVERTED_OPERATORS}}
|
||||
- **Conversion rate**: {{CONVERSION_RATE}}%
|
||||
- **Partner contribution to total pipeline**: {{PARTNER_PIPELINE_PERCENT}}%
|
||||
|
||||
### Referral Commission
|
||||
- **Referral fee earned**: ${{REFERRAL_FEE}}
|
||||
- **Ongoing revenue share**: ${{ONGOING_SHARE}}
|
||||
- **Total YTD earnings**: ${{YTD_EARNINGS}}
|
||||
|
||||
### Partner Activity
|
||||
- **Marketing events hosted**: {{EVENTS_HOSTED}}
|
||||
- **Training sessions conducted**: {{TRAINING_SESSIONS}}
|
||||
- **Community engagement posts**: {{COMMUNITY_POSTS}}
|
||||
- **Collateral created**: {{COLLATERAL}}
|
||||
|
||||
---
|
||||
|
||||
## Financial Summary
|
||||
|
||||
### Incentive Payouts
|
||||
| Category | Amount | Notes |
|
||||
|----------|--------|-------|
|
||||
| Operator stipends | ${{STIPENDS}} | {{STIPENDS_NOTES}} |
|
||||
| Uptime bonuses | ${{UPTIME_BONUS}} | {{UPTIME_NOTES}} |
|
||||
| Mentorship bonuses | ${{MENTOR_BONUS}} | {{MENTOR_NOTES}} |
|
||||
| Performance bonuses | ${{PERF_BONUS}} | {{PERF_NOTES}} |
|
||||
| Partner commissions | ${{PARTNER_COMM}} | {{PARTNER_NOTES}} |
|
||||
|
||||
**Total payout this month**: ${{TOTAL_PAYOUT}}
|
||||
|
||||
### Cost Efficiency
|
||||
- **Cost per node**: ${{COST_PER_NODE}}
|
||||
- **Cost per uptime hour**: ${{COST_PER_UPTIME_HOUR}}
|
||||
- **Efficiency rating**: {{EFFICIENCY_RATING}}/10
|
||||
|
||||
---
|
||||
|
||||
## Goals & Objectives
|
||||
|
||||
### Next Month Targets
|
||||
1. **Uptime**: {{NEXT_UPTIME_TARGET}}%
|
||||
2. **Qualified leads**: {{NEXT_LEADS_TARGET}}
|
||||
3. **New operators**: {{NEXT_OPS_TARGET}}
|
||||
4. **Incident reduction**: {{NEXT_INCIDENT_TARGET}} incidents
|
||||
|
||||
### Priority Initiatives
|
||||
- {{PRIORITY_1}}
|
||||
- {{PRIORITY_2}}
|
||||
- {{PRIORITY_3}}
|
||||
|
||||
### Support Needed
|
||||
- {{SUPPORT_NEEDED_1}}
|
||||
- {{SUPPORT_NEEDED_2}}
|
||||
|
||||
---
|
||||
|
||||
## Attestation
|
||||
|
||||
By submitting this report, I certify that the information provided is accurate and complete to the best of my knowledge.
|
||||
|
||||
**Submitted by**: {{SUBMITTER_NAME}}
|
||||
**Title**: {{SUBMITTER_TITLE}}
|
||||
**Signature**: ___________________________
|
||||
**Date**: {{SUBMISSION_DATE}}
|
||||
|
||||
**Approved by** (Timmy Core): {{APPROVER_NAME}}
|
||||
**Date**: {{APPROVAL_DATE}}
|
||||
|
||||
---
|
||||
|
||||
## Appendix
|
||||
|
||||
### Supporting Documents
|
||||
- [ ] Ops dashboard screenshots attached
|
||||
- [ ] Incident post-mortems attached
|
||||
- [ ] Training completion records attached
|
||||
- [ ] Financial reconciliation attached
|
||||
|
||||
### Notes
|
||||
{{APPENDIX_NOTES}}
|
||||
@@ -1,12 +1 @@
|
||||
# Timmy core module
|
||||
|
||||
from .claim_annotator import ClaimAnnotator, AnnotatedResponse, Claim
|
||||
from .audit_trail import AuditTrail, AuditEntry
|
||||
|
||||
__all__ = [
|
||||
"ClaimAnnotator",
|
||||
"AnnotatedResponse",
|
||||
"Claim",
|
||||
"AuditTrail",
|
||||
"AuditEntry",
|
||||
]
|
||||
|
||||
@@ -1,156 +0,0 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Response Claim Annotator — Source Distinction System
|
||||
SOUL.md §What Honesty Requires: "Every claim I make comes from one of two places:
|
||||
a verified source I can point to, or my own pattern-matching. My user must be
|
||||
able to tell which is which."
|
||||
"""
|
||||
|
||||
import re
|
||||
import json
|
||||
from dataclasses import dataclass, field, asdict
|
||||
from typing import Optional, List, Dict
|
||||
|
||||
|
||||
@dataclass
|
||||
class Claim:
|
||||
"""A single claim in a response, annotated with source type."""
|
||||
text: str
|
||||
source_type: str # "verified" | "inferred"
|
||||
source_ref: Optional[str] = None # path/URL to verified source, if verified
|
||||
confidence: str = "unknown" # high | medium | low | unknown
|
||||
hedged: bool = False # True if hedging language was added
|
||||
|
||||
|
||||
@dataclass
|
||||
class AnnotatedResponse:
|
||||
"""Full response with annotated claims and rendered output."""
|
||||
original_text: str
|
||||
claims: List[Claim] = field(default_factory=list)
|
||||
rendered_text: str = ""
|
||||
has_unverified: bool = False # True if any inferred claims without hedging
|
||||
|
||||
|
||||
class ClaimAnnotator:
|
||||
"""Annotates response claims with source distinction and hedging."""
|
||||
|
||||
# Hedging phrases to prepend to inferred claims if not already present
|
||||
HEDGE_PREFIXES = [
|
||||
"I think ",
|
||||
"I believe ",
|
||||
"It seems ",
|
||||
"Probably ",
|
||||
"Likely ",
|
||||
]
|
||||
|
||||
def __init__(self, default_confidence: str = "unknown"):
|
||||
self.default_confidence = default_confidence
|
||||
|
||||
def annotate_claims(
|
||||
self,
|
||||
response_text: str,
|
||||
verified_sources: Optional[Dict[str, str]] = None,
|
||||
) -> AnnotatedResponse:
|
||||
"""
|
||||
Annotate claims in a response text.
|
||||
|
||||
Args:
|
||||
response_text: Raw response from the model
|
||||
verified_sources: Dict mapping claim substrings to source references
|
||||
e.g. {"Paris is the capital of France": "https://en.wikipedia.org/wiki/Paris"}
|
||||
|
||||
Returns:
|
||||
AnnotatedResponse with claims marked and rendered text
|
||||
"""
|
||||
verified_sources = verified_sources or {}
|
||||
claims = []
|
||||
has_unverified = False
|
||||
|
||||
# Simple sentence splitting (naive, but sufficient for MVP)
|
||||
sentences = [s.strip() for s in re.split(r'[.!?]\s+', response_text) if s.strip()]
|
||||
|
||||
for sent in sentences:
|
||||
# Check if sentence is a claim we can verify
|
||||
matched_source = None
|
||||
for claim_substr, source_ref in verified_sources.items():
|
||||
if claim_substr.lower() in sent.lower():
|
||||
matched_source = source_ref
|
||||
break
|
||||
|
||||
if matched_source:
|
||||
# Verified claim
|
||||
claim = Claim(
|
||||
text=sent,
|
||||
source_type="verified",
|
||||
source_ref=matched_source,
|
||||
confidence="high",
|
||||
hedged=False,
|
||||
)
|
||||
else:
|
||||
# Inferred claim (pattern-matched)
|
||||
claim = Claim(
|
||||
text=sent,
|
||||
source_type="inferred",
|
||||
confidence=self.default_confidence,
|
||||
hedged=self._has_hedge(sent),
|
||||
)
|
||||
if not claim.hedged:
|
||||
has_unverified = True
|
||||
|
||||
claims.append(claim)
|
||||
|
||||
# Render the annotated response
|
||||
rendered = self._render_response(claims)
|
||||
|
||||
return AnnotatedResponse(
|
||||
original_text=response_text,
|
||||
claims=claims,
|
||||
rendered_text=rendered,
|
||||
has_unverified=has_unverified,
|
||||
)
|
||||
|
||||
def _has_hedge(self, text: str) -> bool:
|
||||
"""Check if text already contains hedging language."""
|
||||
text_lower = text.lower()
|
||||
for prefix in self.HEDGE_PREFIXES:
|
||||
if text_lower.startswith(prefix.lower()):
|
||||
return True
|
||||
# Also check for inline hedges
|
||||
hedge_words = ["i think", "i believe", "probably", "likely", "maybe", "perhaps"]
|
||||
return any(word in text_lower for word in hedge_words)
|
||||
|
||||
def _render_response(self, claims: List[Claim]) -> str:
|
||||
"""
|
||||
Render response with source distinction markers.
|
||||
|
||||
Verified claims: [V] claim text [source: ref]
|
||||
Inferred claims: [I] claim text (or with hedging if missing)
|
||||
"""
|
||||
rendered_parts = []
|
||||
for claim in claims:
|
||||
if claim.source_type == "verified":
|
||||
part = f"[V] {claim.text}"
|
||||
if claim.source_ref:
|
||||
part += f" [source: {claim.source_ref}]"
|
||||
else: # inferred
|
||||
if not claim.hedged:
|
||||
# Add hedging if missing
|
||||
hedged_text = f"I think {claim.text[0].lower()}{claim.text[1:]}" if claim.text else claim.text
|
||||
part = f"[I] {hedged_text}"
|
||||
else:
|
||||
part = f"[I] {claim.text}"
|
||||
rendered_parts.append(part)
|
||||
return " ".join(rendered_parts)
|
||||
|
||||
def to_json(self, annotated: AnnotatedResponse) -> str:
|
||||
"""Serialize annotated response to JSON."""
|
||||
return json.dumps(
|
||||
{
|
||||
"original_text": annotated.original_text,
|
||||
"rendered_text": annotated.rendered_text,
|
||||
"has_unverified": annotated.has_unverified,
|
||||
"claims": [asdict(c) for c in annotated.claims],
|
||||
},
|
||||
indent=2,
|
||||
ensure_ascii=False,
|
||||
)
|
||||
@@ -1,103 +0,0 @@
|
||||
#!/usr/bin/env python3
|
||||
"""Tests for claim_annotator.py — verifies source distinction is present."""
|
||||
|
||||
import sys
|
||||
import os
|
||||
import json
|
||||
|
||||
sys.path.insert(0, os.path.join(os.path.dirname(__file__), "..", "src"))
|
||||
|
||||
from timmy.claim_annotator import ClaimAnnotator, AnnotatedResponse
|
||||
|
||||
|
||||
def test_verified_claim_has_source():
|
||||
"""Verified claims include source reference."""
|
||||
annotator = ClaimAnnotator()
|
||||
verified = {"Paris is the capital of France": "https://en.wikipedia.org/wiki/Paris"}
|
||||
response = "Paris is the capital of France. It is a beautiful city."
|
||||
|
||||
result = annotator.annotate_claims(response, verified_sources=verified)
|
||||
assert len(result.claims) > 0
|
||||
verified_claims = [c for c in result.claims if c.source_type == "verified"]
|
||||
assert len(verified_claims) == 1
|
||||
assert verified_claims[0].source_ref == "https://en.wikipedia.org/wiki/Paris"
|
||||
assert "[V]" in result.rendered_text
|
||||
assert "[source:" in result.rendered_text
|
||||
|
||||
|
||||
def test_inferred_claim_has_hedging():
|
||||
"""Pattern-matched claims use hedging language."""
|
||||
annotator = ClaimAnnotator()
|
||||
response = "The weather is nice today. It might rain tomorrow."
|
||||
|
||||
result = annotator.annotate_claims(response)
|
||||
inferred_claims = [c for c in result.claims if c.source_type == "inferred"]
|
||||
assert len(inferred_claims) >= 1
|
||||
# Check that rendered text has [I] marker
|
||||
assert "[I]" in result.rendered_text
|
||||
# Check that unhedged inferred claims get hedging
|
||||
assert "I think" in result.rendered_text or "I believe" in result.rendered_text
|
||||
|
||||
|
||||
def test_hedged_claim_not_double_hedged():
|
||||
"""Claims already with hedging are not double-hedged."""
|
||||
annotator = ClaimAnnotator()
|
||||
response = "I think the sky is blue. It is a nice day."
|
||||
|
||||
result = annotator.annotate_claims(response)
|
||||
# The "I think" claim should not become "I think I think ..."
|
||||
assert "I think I think" not in result.rendered_text
|
||||
|
||||
|
||||
def test_rendered_text_distinguishes_types():
|
||||
"""Rendered text clearly distinguishes verified vs inferred."""
|
||||
annotator = ClaimAnnotator()
|
||||
verified = {"Earth is round": "https://science.org/earth"}
|
||||
response = "Earth is round. Stars are far away."
|
||||
|
||||
result = annotator.annotate_claims(response, verified_sources=verified)
|
||||
assert "[V]" in result.rendered_text # verified marker
|
||||
assert "[I]" in result.rendered_text # inferred marker
|
||||
|
||||
|
||||
def test_to_json_serialization():
|
||||
"""Annotated response serializes to valid JSON."""
|
||||
annotator = ClaimAnnotator()
|
||||
response = "Test claim."
|
||||
result = annotator.annotate_claims(response)
|
||||
json_str = annotator.to_json(result)
|
||||
parsed = json.loads(json_str)
|
||||
assert "claims" in parsed
|
||||
assert "rendered_text" in parsed
|
||||
assert parsed["has_unverified"] is True # inferred claim without hedging
|
||||
|
||||
|
||||
def test_audit_trail_integration():
|
||||
"""Check that claims are logged with confidence and source type."""
|
||||
# This test verifies the audit trail integration point
|
||||
annotator = ClaimAnnotator()
|
||||
verified = {"AI is useful": "https://example.com/ai"}
|
||||
response = "AI is useful. It can help with tasks."
|
||||
|
||||
result = annotator.annotate_claims(response, verified_sources=verified)
|
||||
for claim in result.claims:
|
||||
assert claim.source_type in ("verified", "inferred")
|
||||
assert claim.confidence in ("high", "medium", "low", "unknown")
|
||||
if claim.source_type == "verified":
|
||||
assert claim.source_ref is not None
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
test_verified_claim_has_source()
|
||||
print("✓ test_verified_claim_has_source passed")
|
||||
test_inferred_claim_has_hedging()
|
||||
print("✓ test_inferred_claim_has_hedging passed")
|
||||
test_hedged_claim_not_double_hedged()
|
||||
print("✓ test_hedged_claim_not_double_hedged passed")
|
||||
test_rendered_text_distinguishes_types()
|
||||
print("✓ test_rendered_text_distinguishes_types passed")
|
||||
test_to_json_serialization()
|
||||
print("✓ test_to_json_serialization passed")
|
||||
test_audit_trail_integration()
|
||||
print("✓ test_audit_trail_integration passed")
|
||||
print("\nAll tests passed!")
|
||||
Reference in New Issue
Block a user