Diogo Soares Rodrigues
ea023c380a
The previous commit paired every server-resolved todo block with a result, but built that result in the provider from the flat snapshot. `todoToolRenderer.renderResult` reconstructs the list exclusively from `details.phases`, so the block survived the dangling-strip only to replay as `Todo 0 tasks`. Only the host computes that grouping -- the provider sees a flat list -- so `todoSync` now returns the result it already assembled and the provider persists it verbatim. A refused snapshot never reaches the host, so the provider's summary-only fallback still covers that path, and exactly one result is emitted either way. Separately, `Agent`'s Cursor buffering wrapper pushed its entry only after awaiting the optional `cursorOnToolResult` transformer. The provider dispatches decoded messages with `void handleServerMessage(...)`, so a `message_end` from the same chunk could drain the buffer while a transformer was still pending, dropping the result. The entry is now reserved synchronously and patched in place when the transformer resolves, keeping buffer order and still applying the customization. Production is unaffected -- `sdk.ts` sets no transformer -- but the option is supported and its contract returns a Promise. Tests: a delayed-transformer case that loses the result without the buffering change, and a replay case driving the persisted result through `buildSessionContext` and asserting `details.phases` rebuilds a non-empty list -- the id-pair assertion alone did not catch the empty render.
@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.