Files

T

mayatnikovandClaude Opus 4.7 6ed45a00d5 feat(autonomy): memory model + long-term goal + bias-to-action + live-your-life prompt

Three things that together turn the bot from a reactive chat agent into
a goal-driven autonomous one.

1. Memory model (docs/memory-model.md, new). Formal split:
   - SHARED knowledge — skills/, extensions/, prompts/, docs/,
     .pi/settings.json — committed, community-improvable, portable to any
     server.
   - PERSONAL memory — state/<MC_HOST>/ — gitignored, per-instance, per-
     server. Survives restarts (local disk), doesn't survive a re-clone
     (deliberately). Holds goal.md, plan.md, current-task.json,
     locations.json, diary/, inventory-log.jsonl, escalations.
   Covers resume-after-restart protocol, what "abstract a lesson into a
   skill" means, and the two anti-patterns (committing state, gitignoring
   shared knowledge).

2. AGENTS.md changes:
   - New section "Long-term goal and personal memory" wiring AGENTS.md
     directly into state/<MC_HOST>/goal.md + current-task.json with a
     pointer to docs/memory-model.md.
   - Operating principle #4 ("I'll try to learn") rewritten with
     **bias to action**: a pending stub is now a last resort, not a
     default. Operator-trusted requests are themselves approval — bot
     does not write a stub and wait for a separate "go".
     Rationale: today's pyramid task got stuck because the bot wrote
     a careful "pending" stub and waited; the operator had to send
     "ты ждешь одобрения? можешь стартовать!" before any action. That
     extra round-trip is the reflex this rewrite removes.
   - Operating principle #5 ("live your best life when idle") expanded
     to "goal-driven autonomy" with an explicit 5-level priority order
     (operator task > non-op reply > resume current-task.json > next
     plan milestone > decompose goal). Memory protocol made concrete:
     write current-task.json before every meaningful action, append to
     diary, keep locations.json fresh, tick off plan.md.

3. prompts/live-your-life.md (new). Canonical kickoff to switch the
   bot into autonomous mode. Numbered concrete asks (re-read three
   docs, write plan.md, implement memory protocol, implement
   resume-on-restart, start). Includes a "plan.md draft for review"
   gate so the operator can shape direction without micromanaging
   execution. Designed to be sent after Phase 0/1/operator-trust are
   stable and a goal.md exists for the target server.

Companion seed (local-only, NOT in this commit because gitignored):
state/play.xmatic.team_25565/goal.md — "build a small village and
survive long-term, live like a farmer". Lives only on the operator's
machine; a fresh clone won't see it.

README and roadmap updated with the new Phase 3 status (🌱 → 🌿
kickoff) and pointers to the new memory-model doc.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-25 12:21:25 +03:00

5.1 KiB

Raw Blame History

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.

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 🌱

The bot can be summoned by chat: "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 🌿 (kickoff)

When chat is quiet for some threshold (5-10 minutes of no addressed/non-trivial messages), the bot switches to autonomous mode.

Now it is goal-driven, not just idle-active:

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.
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):

Live operator task → drop everything, do it.
Live non-operator chat → reply briefly.
Resume current-task.json if interrupted.
Next milestone in plan.md.
Decompose goal.md → new plan.

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.

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:

In chat, brief reply: "Не уверен про это, отметил для оператора."
In state/<host>/escalations.jsonl, one JSON line per event: timestamp, requester, request text, classification, what the bot would have done.
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.

5.1 KiB Raw Blame History