feat(runtime): survival-bot pivot — MC chat is dialog-only (Phase 0) (#12)
Phase 0 of plans/autonomous-survival-bot-prd.md: change the product direction from operator-driven remote control to autonomous survival resident. MC chat is dialog-only for everyone, including OPERATOR_USERNAMES — commands like come/follow/build/pause/stop are recorded in the diary but not dispatched. TUI remains the only local control plane. Runtime changes: - Remove operatorGoalReflex from reflex.js (the come-here chat command). - Replace handleOperatorChat in bot.js with a dialog-only handleChat that answers greetings/status questions and records command-like verbs (en+ru) without dispatching them. - Default MC_VERSION to "auto" in runtime/config.js; mineflayer receives `false` to trigger version auto-detection. - Update auto-escalation prompt's reflex chain summary. Docs: - AGENTS.md: product pivot notice up top; chat-driven scope-trust is flagged as legacy/Pi-only. - README.md / docs/runtime.md: replace operator-chat command list with dialog-only description; update reflex chain summary. - docs/roadmap.md: Phase 2/3 marked superseded by the PRD where they assumed chat-driven control. Co-authored-by: Yuriy Mayatnikov <mayatnikov@me.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit was merged in pull request #12.
This commit is contained in:
Yuriy Mayatnikov
+31
-13
@@ -2,6 +2,14 @@
|
||||
|
||||
> The bot grows by accretion. This file describes **the order in which it should grow**, not a set of features to build upfront. Each phase is something the agent itself can extend itself into, one skill at a time.
|
||||
|
||||
> **Product pivot (2026-05-25).** The original roadmap below assumed an
|
||||
> operator-driven bot (chat summons, follow-me, etc.). The new direction is
|
||||
> an autonomous survival resident — see `plans/autonomous-survival-bot-prd.md`
|
||||
> for the active plan and phase structure. Where the two disagree, **the PRD
|
||||
> wins.** Phases 2 (chat-summons) and 3 (operator-priority loop) below are
|
||||
> kept as historical context but no longer represent shipping work; the new
|
||||
> phases are tracked in the PRD.
|
||||
|
||||
Status legend: 🌱 not started · 🌿 in progress · 🌳 done · ⏸️ paused
|
||||
|
||||
## Phase 0 — Body 🌳
|
||||
@@ -21,7 +29,12 @@ The bot is **on the server, all the time** (except for a clean human-issued disc
|
||||
|
||||
Stretch: short-term chat memory (last N lines) so it can reference what was just said.
|
||||
|
||||
## Phase 2 — Locomotion with guard rails 🌿
|
||||
## Phase 2 — Locomotion with guard rails ⏸️ (superseded by PRD)
|
||||
|
||||
> Historical scope: chat-driven summons. As of the 2026-05-25 pivot, MC chat
|
||||
> cannot summon the bot. Pathfinder/safety primitives from this phase are
|
||||
> still useful for autonomous survival movement; the chat-driven summon
|
||||
> surface is removed. See PRD §5 (Target Architecture).
|
||||
|
||||
The bot can be **summoned** by trusted/sanctioned coordinate requests via `mc_goto`; dynamic follow is still pending. Goal: "come to 100 64 -200", "follow me", "go to spawn" with three hard rails:
|
||||
|
||||
@@ -31,28 +44,33 @@ The bot can be **summoned** by trusted/sanctioned coordinate requests via `mc_go
|
||||
|
||||
Stretch: `mc_position_share()` so the bot can answer "where are you?".
|
||||
|
||||
## Phase 3 — Best life when idle / goal-driven autonomy 🌿 (kickoff)
|
||||
## Phase 3 — Best life when idle / goal-driven autonomy 🌿 (revised by PRD)
|
||||
|
||||
When chat is quiet for some threshold (5-10 minutes of no addressed/non-trivial messages), the bot switches to **autonomous mode**.
|
||||
> The "live operator task → drop everything" step from the legacy priority
|
||||
> loop no longer applies — MC chat cannot create tasks. The revised
|
||||
> scheduler priority lives in PRD §5.3 (Task Scheduler Priority). The rest
|
||||
> of this section (goal/plan/current-task/diary structure) still applies
|
||||
> and is the foundation for the survival curriculum.
|
||||
|
||||
Now it is **goal-driven**, not just idle-active:
|
||||
The bot is **always autonomous**: it does not wait for operator chat to
|
||||
have something to do.
|
||||
|
||||
- A long-term goal lives in `state/<MC_HOST>/goal.md` (e.g. "build a small village and survive"). Personal memory, see `docs/memory-model.md`.
|
||||
- A long-term goal lives in `state/<MC_HOST>/goal.md`. Personal memory, see `docs/memory-model.md`.
|
||||
- Decomposed into milestones in `state/<MC_HOST>/plan.md`.
|
||||
- Current action is checkpointed in `state/<MC_HOST>/current-task.json` for resume-on-restart.
|
||||
- Daily journal in `state/<MC_HOST>/diary/YYYY-MM-DD.md`.
|
||||
|
||||
Priority loop (highest to lowest):
|
||||
1. Live operator task → drop everything, do it.
|
||||
2. Live non-operator chat → reply briefly.
|
||||
3. Resume `current-task.json` if interrupted.
|
||||
4. Next milestone in `plan.md`.
|
||||
5. Decompose `goal.md` → new plan.
|
||||
Revised priority loop (per PRD §5.3):
|
||||
1. Emergency survival (death/lava/low HP/starvation).
|
||||
2. Finish or recover current task.
|
||||
3. Maintain base safety (light, shelter, repair).
|
||||
4. Execute current milestone.
|
||||
5. Expand village/base.
|
||||
6. Social reply if there is a relevant chat event.
|
||||
7. Idle diary/status heartbeat.
|
||||
|
||||
Concrete activities while autonomous: scout/build modest base, farm food, store in chests, light area, defend at night, explore cautiously, build out toward the goal. Skills emerge: `farming-wheat`, `chest-organizer`, `careful-cave-mining`, `village-layout`, etc.
|
||||
|
||||
Kicked off via [`prompts/live-your-life.md`](../prompts/live-your-life.md).
|
||||
|
||||
## Phase 4 — Telegram bridge 🌱
|
||||
|
||||
Two-way ops channel without sitting in Pi TUI:
|
||||
|
||||
+40
-25
@@ -4,6 +4,12 @@
|
||||
> 2026-05-25. The pure Pi runtime (`pi` from repo root) still works and is
|
||||
> documented as a fallback at the bottom of this file.
|
||||
|
||||
> **Phase 0 product pivot (2026-05-25).** MC chat is now **dialog-only** for
|
||||
> everyone, including `OPERATOR_USERNAMES`. The reflex loop no longer takes
|
||||
> commands from chat. Local control lives in the TUI (`p`/`s` hotkeys);
|
||||
> long-term control lives in the repo. See
|
||||
> `plans/autonomous-survival-bot-prd.md` for the survival-bot pivot.
|
||||
|
||||
## Why a hybrid runtime?
|
||||
|
||||
The original design ran every tick inside Pi — the LLM saw the world, picked
|
||||
@@ -41,8 +47,8 @@ new code for itself.
|
||||
│ │ - MC TCP │ │ - tick every N sec │ │ - Unix socket ││
|
||||
│ │ - AuthMe handler │◀─│ - priority order: │─▶│ - broadcasts ││
|
||||
│ │ - chat / events │ │ defend > eat │ │ status/log/ ││
|
||||
│ │ │ │ > sleep > current │ │ chat events ││
|
||||
│ │ │ │ > idle │ │ - accepts ││
|
||||
│ │ (dialog-only) │ │ > sleep > tech │ │ chat events ││
|
||||
│ │ │ │ > autonomous │ │ - accepts ││
|
||||
│ │ │ │ - NO LLM in path │ │ commands ││
|
||||
│ └──────────────────┘ └─────────┬────────────┘ └────────────────┘│
|
||||
│ │ │
|
||||
@@ -100,18 +106,23 @@ TUI; the bot is unaffected.
|
||||
The chain (highest priority first), wired and dispatching real
|
||||
Mineflayer actions:
|
||||
|
||||
1. **`operatorGoalReflex`** — if `OPERATOR_USERNAMES` issued a `come` /
|
||||
`follow` command, satisfy it (walk to the operator's last known
|
||||
position, reply in chat on arrival or failure).
|
||||
2. **`defendReflex`** — closest hostile within 4 m → `attackNearest`
|
||||
1. **`defendReflex`** — closest hostile within 4 m → `attackNearest`
|
||||
(equips best melee). Within 12 m + low HP or ≥3 hostiles → `fleeFrom`
|
||||
along the away-vector.
|
||||
3. **`eatReflex`** — food < 16 → `eatBestFood` (picks from
|
||||
2. **`eatReflex`** — food < 16 → `eatBestFood` (picks from
|
||||
FOOD_PRIORITY list, equip + consume). 5 s cooldown.
|
||||
4. **`sleepReflex`** — night + no hostile within 8 m → `sleepInBed`
|
||||
3. **`sleepReflex`** — night + no hostile within 8 m → `sleepInBed`
|
||||
(finds nearest placed bed within 16 blocks, paths there, sleeps).
|
||||
30 s cooldown on failures.
|
||||
5. **`idleReflex`** — every 20th tick, log heartbeat (HP / food / pos).
|
||||
5 min cooldown on failures.
|
||||
4. **`techTreeReflex`** — deterministic crafting progression
|
||||
(planks → sticks → wooden axe → pickaxe → sword) when prerequisites
|
||||
are in inventory.
|
||||
5. **`autonomousReflex`** — when nothing reactive fires: chop trees until
|
||||
~16 logs, then wander to discover new chunks.
|
||||
6. **`idleReflex`** — every 20th tick, log heartbeat (HP / food / pos).
|
||||
|
||||
There is **no operator-goal reflex anymore.** MC chat does not create
|
||||
movement/build/mining tasks (Phase 0 of `plans/autonomous-survival-bot-prd.md`).
|
||||
|
||||
Adding a new reflex = a function `(ctx) => { action, ... }` in
|
||||
`runtime/reflex.js`, inserted at the right priority. Actions live in
|
||||
@@ -127,8 +138,8 @@ bot spawns `pi -p "<question>"` and streams its stdout into the Pi
|
||||
panel.
|
||||
|
||||
**2. Automatic** — every tick where the entire reflex chain returns
|
||||
`noop` (no operator goal, no hostiles in reach, food fine, day or no
|
||||
bed, etc.) increments a counter. When the counter hits
|
||||
`noop` (no hostiles in reach, food fine, day or no bed, nothing to
|
||||
craft, nowhere to wander) increments a counter. When the counter hits
|
||||
`ESCALATE_AFTER_NOOPS = 20` (≈1 min at `tick=3s`), the bot fires
|
||||
`askPi` with the current snapshot and a fixed system prompt telling Pi
|
||||
to suggest one next action. 10 min cooldown so a permanently-idle bot
|
||||
@@ -139,22 +150,26 @@ should only suggest what to do *with the existing tools*. If a deeper
|
||||
problem is happening, the failure-tracker (see Self-improvement) will
|
||||
file a proposal instead.
|
||||
|
||||
## Operator chat commands
|
||||
## In-game chat (dialog-only)
|
||||
|
||||
Players listed in `OPERATOR_USERNAMES` can address the bot in MC chat
|
||||
by prefixing the message with the bot's name:
|
||||
As of the Phase 0 survival-bot pivot, MC chat does **not** drive bot
|
||||
actions for anyone, including names listed in `OPERATOR_USERNAMES`.
|
||||
The bot will:
|
||||
|
||||
```
|
||||
pepa_bot status → bot replies with HP / food / pos / hostiles / busy
|
||||
pepa_bot come → bot pathfinds to the operator's current position
|
||||
pepa_bot pause → reflex loop stops
|
||||
pepa_bot resume → reflex loop resumes
|
||||
pepa_bot stop → graceful disconnect + process exit
|
||||
```
|
||||
- reply to greetings (`hi`, `привет`, etc.) and to being addressed by
|
||||
name, rate-limited;
|
||||
- answer status questions (`pepa_bot status`, `как дела`, `what are
|
||||
you doing?`) from the live snapshot;
|
||||
- detect command-like verbs (`come`, `follow`, `build`, `pause`,
|
||||
`stop`, `give`, …) when addressed, record them in the diary, and
|
||||
reply once per cooldown that MC chat is dialog-only.
|
||||
|
||||
Unrecognized commands get a polite "didn't recognize" reply. Operator
|
||||
identity verification is the server's job (AuthMe on cracked,
|
||||
online-mode on premium) — the bot trusts the nickname.
|
||||
Local control of the bot (pause/resume/stop, sending chat manually,
|
||||
escalating to Pi) lives in the TUI. Long-term control (skills,
|
||||
runtime code, proposals) lives in the repo. `OPERATOR_USERNAMES` is
|
||||
still used to **label** speakers in logs (`operator <name>` vs
|
||||
`player <name>`), and remains the right place to plug a future
|
||||
trusted control channel (e.g. Telegram bridge).
|
||||
|
||||
## IPC protocol
|
||||
|
||||
|
||||
Reference in New Issue
Block a user