z80
40b2d534a0
While the agent worked through a plan, every sub-todo rendered unchecked no matter how far along the run was: the phase header highlighted, the task rows below it looked untouched. Three separate causes, all on the collapsed path that is the default view. `selectCollapsedTodos` dropped every closed row while a phase held open work, so finishing a task only ever *removed* a line — the panel never rendered a checked box until the whole phase settled. That also made the card's completion animation dead code: `details.completedTasks` drives a 14-frame strike reveal at 65ms with a component render per tick, against a row the viewport had already discarded. The existing animation test missed it by asserting on `expanded: true`. The viewport now keeps the newest closed task as a checked lead row, additive to the open-task cap so it never evicts open work, and the strike sweep lands where users actually see it. Second, the card gave a `done/total` count to every collapsed untouched phase but not to the active one, so the phase being worked in was the single phase reporting no progress. Extracted `formatPhaseProgress` and put it on every phase header. Third, the todo auto-clear (`tasks.todoClearDelay`, default 60s) armed on any list holding a closed task and physically deleted those tasks from the HUD's copy. An in-flight phase at `3/4` silently became `0/1` sixty seconds later, fully-closed phases vanished, and stage roman numerals renumbered off the filtered index — until the next `todo` call restored the real snapshot. It now fires only once the whole list is settled, which is the case the setting exists for; the walking viewport already hides closed rows while work remains. Progress counters also count closed tasks rather than only completed ones. The viewport hides abandoned tasks too, so counting only completions left a phase reading permanently stuck.
@oh-my-pi/pi-coding-agent
Core implementation package for the omp coding agent in the oh-my-pi monorepo.
For installation, setup, provider configuration, model roles, slash commands, and full CLI reference, see:
Package-specific references:
Memory backends
The agent supports three mutually-exclusive memory backends, selected via the memory.backend setting (Settings → Memory tab, or ~/.omp/config.yml):
off(default) — no memory subsystem runs.local— existing rollout-summarisation pipeline; writesmemory_summary.mdand consolidated artifacts under the agent dir.hindsight— talks to a Hindsight server (Cloud or self-hosted Docker), retains transcripts every Nth user turn, recalls memories on the first turn of a session, and exposesretain,recall, andreflect.
Hindsight quickstart
- Run a Hindsight server (Cloud or
docker run -p 8888:8888 ghcr.io/vectorize-io/hindsight:latest). - Set
memory.backend = "hindsight"andhindsight.apiUrl = "http://localhost:8888"(or your Cloud URL). - Optional environment overrides (env wins over settings):
HINDSIGHT_API_URL,HINDSIGHT_API_TOKEN— connectionHINDSIGHT_BANK_ID,HINDSIGHT_DYNAMIC_BANK_ID,HINDSIGHT_AGENT_NAME— bank addressingHINDSIGHT_AUTO_RECALL,HINDSIGHT_AUTO_RETAIN,HINDSIGHT_RETAIN_MODE— lifecycleHINDSIGHT_RECALL_BUDGET,HINDSIGHT_RECALL_MAX_TOKENS— recall sizingHINDSIGHT_BANK_MISSION,HINDSIGHT_DEBUG
Switching backends mid-session immediately replaces the live backend, memory tools, listeners, and system-prompt context. Existing users with memories.enabled = true|false are migrated to memory.backend = "local"|"off" exactly once on first launch; afterward, memory.backend is the sole runtime selector.