3310cb320f
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>
112 lines
6.2 KiB
Markdown
112 lines
6.2 KiB
Markdown
# Roadmap
|
|
|
|
> 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 🌳
|
|
|
|
The agent has a working Mineflayer bridge, joins the configured server, handles AuthMe-style first registration, sends chat, exposes `mc_chat / mc_position / mc_disconnect` to itself.
|
|
|
|
Captured in: `skills/server-onboarding.md`.
|
|
|
|
## Phase 1 — Presence 🌳
|
|
|
|
The bot is **on the server, all the time** (except for a clean human-issued disconnect), and is **conversational**:
|
|
|
|
- Listens to all chat, not only messages addressed by name.
|
|
- Replies to ambient conversation when it has something useful or amusing to add. Doesn't have to reply to everything — silence is fine; spam is not.
|
|
- Survives crashes: auto-reconnect on `kicked` / `end`, **bounded** (e.g. ≤ 3 reconnects in 10 minutes, then back off and wait — the server might genuinely be down).
|
|
- Stays put while connected: no wandering off, no PvP.
|
|
|
|
Stretch: short-term chat memory (last N lines) so it can reference what was just said.
|
|
|
|
## 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:
|
|
|
|
- **Distance bound.** Refuse trips longer than `MAX_TRAVEL_BLOCKS` (e.g. 500 blocks straight-line) from current position. Politely explain why.
|
|
- **Focus.** While moving toward a target, ignore competing summons. Reply once with "currently on my way to X, will be free in ~N seconds." Don't context-switch mid-trip.
|
|
- **Safety pathing.** Wrap `mineflayer-pathfinder` so the bot doesn't drop into lava, into the void, or into player-claimed regions.
|
|
|
|
Stretch: `mc_position_share()` so the bot can answer "where are you?".
|
|
|
|
## Phase 3 — Best life when idle / goal-driven autonomy 🌿 (revised by PRD)
|
|
|
|
> 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.
|
|
|
|
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`. 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`.
|
|
|
|
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.
|
|
|
|
## Phase 4 — Telegram bridge 🌱
|
|
|
|
Two-way ops channel without sitting in Pi TUI:
|
|
|
|
- Operator sends a message in Telegram → bot reads, responds in Telegram (not MC chat).
|
|
- Bot can push notifications to Telegram: escalations, errors, "I just built a thing", milestones.
|
|
- Per-`chat_id` whitelist (only configured chat IDs are trusted).
|
|
|
|
`.env` placeholders for `TELEGRAM_BOT_TOKEN` and `TELEGRAM_OPERATOR_CHAT_ID` already exist.
|
|
|
|
## Phase 5 — Self-extension as default 🌿
|
|
|
|
By this phase the patterns above should produce a reflex:
|
|
|
|
- A human says "do X" the bot doesn't know how to do →
|
|
- Bot replies "I'll try to learn", drafts a skill plan,
|
|
- Either executes it directly (if safe + within rate limits) or commits the skill draft to `skills/` for human review.
|
|
|
|
The first successful "I'll try to learn" cycle that ships a useful skill marks Phase 5 as 🌳.
|
|
|
|
## Phase 6 — Escalation log 🌳
|
|
|
|
When a request smells destructive, ambiguous, or off-policy (e.g. break a player's blocks, leave a structure, give someone an item from inventory, leave the server entirely), the bot doesn't unilaterally do it and doesn't flatly refuse. Instead:
|
|
|
|
1. **In chat**, brief reply: "Не уверен про это, отметил для оператора."
|
|
2. **In `state/<host>/escalations.jsonl`**, one JSON line per event: timestamp, requester, request text, classification, what the bot would have done.
|
|
3. **At next Pi session start** (and once Telegram exists, immediately), surface a count: "N pending escalations since last session".
|
|
|
|
The operator either turns the request into a sanctioned skill (and merges it) or leaves it logged. Either way, the bot learns where its own boundaries actually are.
|
|
|
|
---
|
|
|
|
## Non-goals (for now)
|
|
|
|
- **PvP / griefing tools** — never.
|
|
- **Anything requiring OP** — never. If a skill seems to need OP, that's a sign it doesn't belong on this bot.
|
|
- **Cross-server identity** — phase 3 diaries are per-server (`state/<host>/...`). Same skill set, separate memories.
|
|
- **Multiple bot instances at once** — one bridge, one bot, one server per `pi` process. Multi-bot is a different project.
|