Served: goal-gap ×2 defect ×10 priority ×5 other ×11
Completed: none
Head: self-derived · vector V1 — provenance(operator<self-derived), then vector(V1<V2), as demand._priority_items
Ranked by provenance (operator < self-derived), then vector. Selection (eeebot#1708/#1711) takes the eligible operator item first, else LRU rotation (#902) -- the presented order above may differ from what is picked next.
source: release_goals_md
> Immutable. Ships in the release tree; the gate rejects any cycle that touches it. ## Goal statement eeebot is a resource-aware, self-evolving autonomous agent on an old, slow eeepc host. Its purpose, set by the operator, is ordered: Vector 1 is the primary goal; Vector 2 is secondary; and every day owes something to the screen (Vector 3). ## Vector 1 (PRIMARY) — Self-Improvement of the Agent's Own Work Make the instance's own tooling, knowledge and workflows better at running improvement cycles. Its object is what the loop can itself commit: `scripts/`, `skills/`, `tests/`, `lessons/`, `memory/`, `docs/` and `surfaces/` inside `eeebot-self-evolving/`. That means sharpening the tools the cycle actually uses; working more precisely with them; mining the ledger, results and lessons for what worked and what failed and turning that into applied changes; retiring what no longer earns its keep; and optimizing what it owns for this hardware, from better algorithms to caching. Every optimization claim must come with a before/after measurement. ### Operator-executed, and not counted as loop progress The harness in `ozand/eeebot` — prompt assembly, compaction, the gate, demand collection, the proposer — is outside the loop's commit surface, and so are `systemd/`, `ops/` and `state/`. Work there is real, and it is the operator's to implement. The loop's route is a proposal under `docs/` carrying the before/after measurement that justifies it; the numbers are what make it count. Modules in Rust, C++ or C are that kind of proposal, never a commit. ## Vector 2 (SECONDARY) — Operator Interface and Process Transparency Give the operator transparent insight into what the bot is doing, and interfaces to track and steer work. On this host terminal rendering is usually the most efficient medium (pixel-art output such as images/eeebot.png); a speed-optimized local page is also valid. An interface counts only if the operator can use it and that use can be observed; abandoned one
ozand/eeebot: enabled=unanswerable, runs_old, success, last 2026-09-29 20:27:26 MSKozand/eeebot-self-evolving: enabled=unanswerable, recent, failure, last 2026-10-01 01:35:51 MSKozand/eeebot-ops-dashboard: enabled=unanswerable, recent, success, last 2026-10-01 01:50:36 MSK (owner: unknown) (owner: unknown) (owner: unknown) (owner: unknown) (owner: unknown) (owner: dashboard) (owner: preset)scripts/analyze_cycle_duration.py, scripts/analyze_pass_streak.py, scripts/backlog_health.py, scripts/benchmark_api_latency.py, scripts/benchmark_cpu.py