Notas

Role and goal You are implementing a structured autonomy layer for an existing Mineflayer bot in autonomous/. Do not replace Mineflayer with C++ or Botcraft. Instead, adopt patterns inspired by Botcraft’s design: behaviour trees (BT), explicit node states, debuggable execution, vanilla-faithful movement assumptions, and a server-backed test harness for behaviours. Primary outcome: smarter, more inspectable, more testable bot logic while preserving current capabilities (planner, skills, persistence, pathfinder). Repository context (read before coding) 1. Read .cursor/skills/mineflayer-bot/SKILL.md and .cursor/skills/mineflayer-pathfinder/SKILL.md if present. 2. Map the current loop: bot.js → lib/brain.js → lib/planner.js / roadmap → lib/executor.js → skills/* and lib/*. 3. Respect config via .env and lib/config.js; do not hardcode secrets or server addresses. 4. After changes, run cd autonomous && npm test (and follow .cursor/rules/jarvys-autonomous-testing.mdc for live probes if relevant). Design principles (Botcraft-inspired, adapted to JS) 1. Behaviour tree as the execution spine • Introduce a small BT runtime in autonomous/lib/ (new module(s)): nodes for Sequence, Selector, Decorator (e.g. Retry, Timeout, Cooldown, Inverter), and leaf nodes that wrap existing “skills” or atomic actions. • Do not delete the planner/roadmap in v1 unless you prove feature parity: prefer planner chooses high-level goal → BT executes sub-behaviour (hybrid), or BT root that embeds current nextTask as one branch. • Every node exposes: tick(bot, blackboard) → { status: 'success'|'failure'|'running', debug? }. 2. Blackboard schema • Unify state / blackboard usage: typed or documented keys (food, health, hostiles, phase, last failure, cooldowns). Extend lib/blackboardSchema.js or add lib/btBlackboard.js rather than scattering magic strings. • BT leaves read/write only through blackboard + small facades (e.g. movement, inventory, combat). 3. Debuggability (lightweight “Botcraft debugger” analogue) • Optional structured trace: env flag e.g. BT_TRACE=1 writes JSONL (or pretty stderr) with timestamp, tree id, node path, status transitions. • Optional breakpoint/step: env BT_STEP=1 pauses between ticks waiting for stdin or a simple HTTP hook—only if low complexity; otherwise document as future work. • Goal: reproduce Botcraft’s “see which node failed” workflow without OpenGL. 4. Vanilla-faithful assumptions • Document in code comments (brief) where the bot assumes vanilla physics (gravity, ladders, water, scaffolding) vs heuristics. • Align pathfinder goals (lib/goals.js, mineflayer-pathfinder Movements) with failure recovery in BT: timeout → reposition → explore subtree (mirror Botcraft’s pathfinding + recovery idea). 5. Testing harness (Botcraft-style discipline) • Add deterministic unit tests for BT core: sequence/selector/retry/timeout without a server. • Add one integration test pattern: optional slow test gated by env (similar spirit to Botcraft’s vanilla server tests)—e.g. BT_INTEGRATION=1 spins bot against local server or uses existing yolo test patterns in tests/integration-yolo.test.js. Do not require a server for default npm test. • Each new BT subtree should have at least one test or trace fixture. 6. Migration strategy • Phase 1: BT executes one existing high-churn path (e.g. retreat, eat_if_needed, or explore_nearby after failures) while planner unchanged. • Phase 2: Move combat or mining subtree to BT with retries and cooldowns. • Phase 3: Optional—planner emits BT “program” or template id + params instead of flat taskId only. Deliverables 1. New files: autonomous/lib/bt/ (or similar) with BT engine + node library. 2. Integration glue: one exported createBehaviourRoot(state) or attach from brain.js / executor.js with minimal churn to call sites. 3. Env-driven tracing; document env vars in existing internal comment block or the agent’s final summary (do not add unsolicited README files unless the user asks). 4. Tests under autonomous/tests/ for BT + one migrated behaviour. 5. No regression: existing npm test passes; skill APIs remain usable. Non-goals • No C++/Botcraft vendoring, no GPL code copy-paste. • No anti-cheat or “human-like” evasion features. • No large unrelated refactors of skills/* unless required for BT leaves. Success criteria • BT runs in the live bot with clear traces when enabled. • At least one production behaviour is clearly easier to extend (new leaf = new file + register). • Tests cover BT semantics; CI/default test run stays fast and offline. • Short summary of architecture (hybrid planner+BT) for the user in the final message. Implementation order 1. BT core + tests. 2. Blackboard helpers. 3. Migrate first behaviour + trace. 4. Second behaviour + optional integration gate. 5. Cleanup, ensure npm test green.