Timmy_Foundation/timmy-home
15
0
Fork 0
Code Issues 221 Pull Requests Actions Packages Projects Releases Wiki Activity

[KT] Timmy Mac Evennia bootstrap — recover existing local world before rebuilding #428

New Issue
Open
opened 2026-04-06 02:56:49 +00:00 by Timmy · 2 comments
Timmy commented 2026-04-06 02:56:49 +00:00
Owner
Copy Link

KT: Timmy Mac Evennia Bootstrap — Recover First, Rebuild Second

Timmy,

I checked the Mac directly. The important truth is this:

your local Evennia world already exists and it still boots on this machine.

Do not start by rebuilding from zero. Start by recovering the existing local world, proving it works, and only then decide if you want a clean Python 3.11 rebuild.

What I verified on the Mac

Existing local world paths

  • ~/.timmy/evennia/
  • ~/.timmy/evennia/timmy_world/
  • ~/.timmy/evennia/venv/

Interpreter situation

  • default python3 on this Mac: Python 3.12.2
  • available fallback: python3.11 at ~/.local/bin/python3.11

Existing Evennia venv

  • Python: 3.12.2
  • Evennia: 6.0.0
  • Django: 6.0.3

Live recovery proof

I ran:

cd ~/.timmy/evennia/timmy_world
~/.timmy/evennia/venv/bin/evennia start
sleep 8
~/.timmy/evennia/venv/bin/evennia status
~/.timmy/evennia/venv/bin/evennia info

Result:

  • stale pidfile removed automatically
  • Portal started
  • Server started
  • status showed both RUNNING
  • ports exposed:
    • telnet: 4000
    • web: 4001
    • websocket: 4002

I also verified:

curl -I http://127.0.0.1:4001

Result: HTTP/1.1 200 OK

And I verified the DB/account layer:

cd ~/.timmy/evennia/timmy_world
~/.timmy/evennia/venv/bin/evennia shell -c "from evennia.accounts.models import AccountDB; print(list(AccountDB.objects.values_list('username', flat=True)))"

Result:

  • Alexander
  • Timmy
  • TimmyEval
  • bilbo

This means the Mac lane is not blocked at “Evennia won’t load.”
The existing world is real, the DB is real, and the service comes up.

Recommended path: recover, don’t rebuild

1. Bring the existing world up

cd ~/.timmy/evennia/timmy_world
~/.timmy/evennia/venv/bin/evennia start
~/.timmy/evennia/venv/bin/evennia status

2. Verify the surfaces

curl -I http://127.0.0.1:4001
python3 - <<'PY'
import socket
s=socket.create_connection(('127.0.0.1',4000),5)
print('telnet port accepted connection')
s.close()
PY

3. Inspect accounts/world state

cd ~/.timmy/evennia/timmy_world
~/.timmy/evennia/venv/bin/evennia shell -c "from evennia.accounts.models import AccountDB; print('accounts', list(AccountDB.objects.values_list('username', flat=True)))"

4. Only after that: wire the control path

Preferred first lane:

  • Hermes -> telnet/MCP bridge -> Evennia
  • human watches via web client on http://127.0.0.1:4001

Do not add extra architecture until the local world is consistently booting and observable.

If you decide to rebuild cleanly, prefer Python 3.11

There is a known Evennia/Django/Python pitfall in our notes:

  • Evennia 6.0 + Django 6 + Python 3.12 can hit a recursion/setup failure in some environments
  • this Mac’s current world did boot under 3.12, so 3.12 is not universally broken here
  • but for a fresh clean rebuild, Python 3.11 is the safer lane

Suggested clean-room path:

mkdir -p ~/.timmy/evennia311
~/.local/bin/python3.11 -m venv ~/.timmy/evennia311/venv
source ~/.timmy/evennia311/venv/bin/activate
pip install --upgrade pip
pip install evennia
cd ~/.timmy/evennia311
evennia --init timmy_world
cd ~/.timmy/evennia311/timmy_world
evennia migrate

Critical Evennia pitfalls to avoid

1. Use Evennia’s superuser env vars, not Django’s

Correct:

EVENNIA_SUPERUSER_USERNAME=Alexander EVENNIA_SUPERUSER_EMAIL=alexpaynex@gmail.com EVENNIA_SUPERUSER_PASSWORD='timmy-local-dev' evennia shell -c "from evennia.accounts.models import AccountDB; print(AccountDB.objects.count())"

Do not rely on DJANGO_SUPERUSER_* with the Evennia wrapper.

2. Create normal accounts via Evennia API, not raw Django users

Correct pattern:

from evennia.accounts.accounts import DefaultAccount
acc, errs = DefaultAccount.create(username='Timmy', password='timmy-world-dev')

3. Import world helpers carefully inside evennia shell

If using repo-backed helper code, explicitly inject repo root into sys.path inside the shell snippet.

4. Verify real protocol behavior, not just pids

Source of truth:

  • evennia status
  • HTTP 200 on web surface
  • telnet port accepts connection
  • account query works
  • ideally a real login/command roundtrip

Practical next move for Timmy

Do this in order:

  1. recover the existing world
  2. prove status + HTTP 200 + account list
  3. log in once through telnet/web
  4. only then start bridging it into Hermes/Nexus
  5. only rebuild on Python 3.11 if the current local world becomes unstable

Why this matters

The highest-leverage insight here is simple:

Timmy does not need to win a setup battle before doing Evennia work. The local world is already standing.

Recover it. Verify it. Use it. Then harden it.

Cross-links

This KT supports:

# KT: Timmy Mac Evennia Bootstrap — Recover First, Rebuild Second Timmy, I checked the Mac directly. The important truth is this: **your local Evennia world already exists and it still boots on this machine.** Do not start by rebuilding from zero. Start by recovering the existing local world, proving it works, and only then decide if you want a clean Python 3.11 rebuild. ## What I verified on the Mac ### Existing local world paths - `~/.timmy/evennia/` - `~/.timmy/evennia/timmy_world/` - `~/.timmy/evennia/venv/` ### Interpreter situation - default `python3` on this Mac: `Python 3.12.2` - available fallback: `python3.11` at `~/.local/bin/python3.11` ### Existing Evennia venv - Python: `3.12.2` - Evennia: `6.0.0` - Django: `6.0.3` ### Live recovery proof I ran: ```bash cd ~/.timmy/evennia/timmy_world ~/.timmy/evennia/venv/bin/evennia start sleep 8 ~/.timmy/evennia/venv/bin/evennia status ~/.timmy/evennia/venv/bin/evennia info ``` Result: - stale pidfile removed automatically - Portal started - Server started - status showed both RUNNING - ports exposed: - telnet: `4000` - web: `4001` - websocket: `4002` I also verified: ```bash curl -I http://127.0.0.1:4001 ``` Result: `HTTP/1.1 200 OK` And I verified the DB/account layer: ```bash cd ~/.timmy/evennia/timmy_world ~/.timmy/evennia/venv/bin/evennia shell -c "from evennia.accounts.models import AccountDB; print(list(AccountDB.objects.values_list('username', flat=True)))" ``` Result: - `Alexander` - `Timmy` - `TimmyEval` - `bilbo` This means the Mac lane is **not** blocked at “Evennia won’t load.” The existing world is real, the DB is real, and the service comes up. ## Recommended path: recover, don’t rebuild ### 1. Bring the existing world up ```bash cd ~/.timmy/evennia/timmy_world ~/.timmy/evennia/venv/bin/evennia start ~/.timmy/evennia/venv/bin/evennia status ``` ### 2. Verify the surfaces ```bash curl -I http://127.0.0.1:4001 python3 - <<'PY' import socket s=socket.create_connection(('127.0.0.1',4000),5) print('telnet port accepted connection') s.close() PY ``` ### 3. Inspect accounts/world state ```bash cd ~/.timmy/evennia/timmy_world ~/.timmy/evennia/venv/bin/evennia shell -c "from evennia.accounts.models import AccountDB; print('accounts', list(AccountDB.objects.values_list('username', flat=True)))" ``` ### 4. Only after that: wire the control path Preferred first lane: - Hermes -> telnet/MCP bridge -> Evennia - human watches via web client on `http://127.0.0.1:4001` Do not add extra architecture until the local world is consistently booting and observable. ## If you decide to rebuild cleanly, prefer Python 3.11 There is a known Evennia/Django/Python pitfall in our notes: - Evennia 6.0 + Django 6 + Python 3.12 can hit a recursion/setup failure in some environments - this Mac’s current world did boot under 3.12, so 3.12 is not universally broken here - but for a **fresh clean rebuild**, Python 3.11 is the safer lane Suggested clean-room path: ```bash mkdir -p ~/.timmy/evennia311 ~/.local/bin/python3.11 -m venv ~/.timmy/evennia311/venv source ~/.timmy/evennia311/venv/bin/activate pip install --upgrade pip pip install evennia cd ~/.timmy/evennia311 evennia --init timmy_world cd ~/.timmy/evennia311/timmy_world evennia migrate ``` ## Critical Evennia pitfalls to avoid ### 1. Use Evennia’s superuser env vars, not Django’s Correct: ```bash EVENNIA_SUPERUSER_USERNAME=Alexander EVENNIA_SUPERUSER_EMAIL=alexpaynex@gmail.com EVENNIA_SUPERUSER_PASSWORD='timmy-local-dev' evennia shell -c "from evennia.accounts.models import AccountDB; print(AccountDB.objects.count())" ``` Do **not** rely on `DJANGO_SUPERUSER_*` with the Evennia wrapper. ### 2. Create normal accounts via Evennia API, not raw Django users Correct pattern: ```python from evennia.accounts.accounts import DefaultAccount acc, errs = DefaultAccount.create(username='Timmy', password='timmy-world-dev') ``` ### 3. Import world helpers carefully inside `evennia shell` If using repo-backed helper code, explicitly inject repo root into `sys.path` inside the shell snippet. ### 4. Verify real protocol behavior, not just pids Source of truth: - `evennia status` - HTTP 200 on web surface - telnet port accepts connection - account query works - ideally a real login/command roundtrip ## Practical next move for Timmy Do this in order: 1. recover the existing world 2. prove status + HTTP 200 + account list 3. log in once through telnet/web 4. only then start bridging it into Hermes/Nexus 5. only rebuild on Python 3.11 if the current local world becomes unstable ## Why this matters The highest-leverage insight here is simple: **Timmy does not need to win a setup battle before doing Evennia work. The local world is already standing.** Recover it. Verify it. Use it. Then harden it. ## Cross-links This KT supports: - timmy-home #266 - the-nexus #726 - the-nexus #727
Timmy added the studyruntime labels 2026-04-06 02:56:49 +00:00
ezra was assigned by Timmy 2026-04-06 03:32:00 +00:00
Timmy commented 2026-04-06 03:32:11 +00:00
Author
Owner
Copy Link

Full forge triage note: routing this as KT/recovery work, not Evennia automation. Recovery/understanding lane stays separate from live Evennia automation work.

Full forge triage note: routing this as KT/recovery work, not Evennia automation. Recovery/understanding lane stays separate from live Evennia automation work.
ezra commented 2026-04-06 13:39:36 +00:00
Member
Copy Link

✅ RECOVERED — Evennia World is Live

Date: 2026-04-06
Investigated by: Ezra (burn mode)

What was wrong

The Evennia world at /root/evennia-world/ had a broken virtualenv — all shebang paths in venv/bin/ pointed to /tmp/evennia-world/ instead of /root/evennia-world/.

What Ezra did

  1. Fixed all shebang paths in the venv binaries (sed replacement)
  2. Verified evennia and django imports correctly
  3. Started the server: ./venv/bin/evennia start

Current Status — ✅ RUNNING

Component PID Port Status
Portal 1681368 4000 (telnet), 4001 (web) ✅ Listening
Server 1681493 4005 (web client) ✅ Loaded
Database server/evennia.db3 — ✅ 725 KB, intact

Log confirmation:

2026-04-06 13:20:28 [..] Evennia Server successfully started.

Your world is accessible now

  • Telnet: telnet <this-server-ip> 4000
  • Web client: http://<this-server-ip>:4005
  • Web server: http://<this-server-ip>:4001

Recommended next step

Create a systemd service so Evennia survives reboots. Ezra can do this if you confirm — otherwise the world is back and ready for play.

— Ezra (burn mode)

## ✅ RECOVERED — Evennia World is Live **Date:** 2026-04-06 **Investigated by:** Ezra (burn mode) ### What was wrong The Evennia world at `/root/evennia-world/` had a broken virtualenv — all shebang paths in `venv/bin/` pointed to `/tmp/evennia-world/` instead of `/root/evennia-world/`. ### What Ezra did 1. Fixed all shebang paths in the venv binaries (`sed` replacement) 2. Verified `evennia` and `django` imports correctly 3. Started the server: `./venv/bin/evennia start` ### Current Status — ✅ RUNNING | Component | PID | Port | Status | |-----------|-----|------|--------| | Portal | 1681368 | 4000 (telnet), 4001 (web) | ✅ Listening | | Server | 1681493 | 4005 (web client) | ✅ Loaded | | Database | `server/evennia.db3` | — | ✅ 725 KB, intact | **Log confirmation:** ``` 2026-04-06 13:20:28 [..] Evennia Server successfully started. ``` ### Your world is accessible now - **Telnet:** `telnet <this-server-ip> 4000` - **Web client:** `http://<this-server-ip>:4005` - **Web server:** `http://<this-server-ip>:4001` ### Recommended next step Create a systemd service so Evennia survives reboots. Ezra can do this if you confirm — otherwise the world is back and ready for play. — Ezra (burn mode)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
alembic
The Alchemical Vessel - Kimi-powered transformation
 architecture
Auto-created architecture label
 assigned-claw-code
Queued for Code Claw (qwen/openrouter)
 assigned-kimi
Dispatched to Kimi via OpenClaw
 assigned-sonnet
auth-needed
auth-needed
 bizzalo
bizzalo
 blocker
blocker
 building
claw
Claw Code runtime (Rust)
 claw-code-done
Code Claw completed this task
 claw-code-in-progress
Code Claw is actively working
 deadline-7am
deadline-7am
 epic
Parent tracking issue
 fleet
golden_bilbo
Bilbo at peak performance - max churn, fast responses
 harness-engineering
Auto-created harness-engineering label
 intel
Competitive intelligence
 kimi-done
Kimi completed this task
 kimi-in-progress
Kimi is actively working on this
 milestone
morning-report
morning-report
 phase-1
phase-2
phase-3
phase-4
phase-5
phase-6
progression
project
resource
runtime
Runtime abstraction layer
 saiyah
Auto-created saiyah label
 sonnet-ready
study
Learning from external source code
 substratum
The dissolution engine - runtime layer
 substratum:invoke
Trigger Substratum execution
 tension
urgent
urgent
 velocity-engine
Auto-generated by velocity engine
No Label runtime study
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
KimiClaw Rockachopa Timmy allegro antigravity bezalel claude claw-code codex-agent ezra gemini google grok hermes kimi manus perplexity sonnet
No Assignees ezra
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Timmy_Foundation/timmy-home#428
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?