Files
oh-my-pi/packages/coding-agent
Larry Gordon 959ad3451f fix(test): gave CLI-spawning tests explicit timeouts
Four tests spawn the full CLI entry graph (or compile a standalone binary)
and declared no timeout, so they inherited Bun's 5s default. Spawning
`src/cli.ts` costs ~900ms warm on a fast machine and ~3.1s cold, so the
budget is spent almost entirely on transpile. When CI runs the native
bucket with OMP_TEST_CONCURRENCY=4, a cold spawn on a contended runner
crosses 5s and the test fails with `timed out after 5000ms` plus a
trailing `killed 1 dangling process` - the subprocess was still alive when
the timeout fired.

Reproduced locally by oversubscribing the box (48 concurrent runs of the
same chunk): 48/48 failed with the identical signature, while 4-way
concurrency - what CI actually configures - passed every time. Only the
subprocess tests starve; the pure-unit tests in the same files pass.

Timeouts are sized to the work, matching existing subprocess tests
(read-cli-mcp-resource 30_000, acp-stdout-hygiene 60_000): 30s for CLI
spawns, 60s for the `bun build --compile` case. After the change, 64
concurrent runs of all three files produce zero timeouts.

`profile-cli.test.ts` gets the timeout on both spawn tests. Only the first
was observed failing, because it warms the transpile cache for its
sibling - that ordering is incidental and would flake if it changed.

These are drift and wiring assertions, not latency assertions, so a
generous ceiling costs nothing on a healthy run.
2026-07-30 11:27:10 -07:00
..
2026-07-30 17:27:05 +02:00
2026-07-30 17:27:05 +02:00

@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; writes memory_summary.md and 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 exposes retain, recall, and reflect.

Hindsight quickstart

  1. Run a Hindsight server (Cloud or docker run -p 8888:8888 ghcr.io/vectorize-io/hindsight:latest).
  2. Set memory.backend = "hindsight" and hindsight.apiUrl = "http://localhost:8888" (or your Cloud URL).
  3. Optional environment overrides (env wins over settings):
    • HINDSIGHT_API_URL, HINDSIGHT_API_TOKEN — connection
    • HINDSIGHT_BANK_ID, HINDSIGHT_DYNAMIC_BANK_ID, HINDSIGHT_AGENT_NAME — bank addressing
    • HINDSIGHT_AUTO_RECALL, HINDSIGHT_AUTO_RETAIN, HINDSIGHT_RETAIN_MODE — lifecycle
    • HINDSIGHT_RECALL_BUDGET, HINDSIGHT_RECALL_MAX_TOKENS — recall sizing
    • HINDSIGHT_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.