v0.32.7 — Simulators stay booted while their agent's job is queued

• Keep a simulator booted while an agent's queued job names it. The idle
  reaper shut a simulator down after 10 CPU-flat minutes unless a Maestro
  driver held it, so an agent whose xcodebuild -destination id=<UDID> (or
  name=<device>) was waiting in the queue lost its device and had to boot it
  again once admitted. Any live process under an agent session that names the
  device's UDID or exact destination name now holds it, including the waiting
  runner. This only ever retains a device; nothing new is shut down or killed.
• Termination reports now say whether memcap itself acted. memcap keeps a
  fixed-vocabulary record of its own process signals, queued-job cancellations,
  simulator shutdowns and watchdog environment stops (no pids, commands or
  paths), and every report includes memcap_*_30m counts. An
  unexpected-termination report states plainly when memcap did nothing in the
  30 minutes before it, so a failing test is not mistaken for a kill.

v0.32.6 — Readable help and a smoother first install

Launch polish found by running a first install in a throwaway home directory.

• Readable memcap help. It is also what bare memcap prints, and it was a single 600-column usage line. The commands are now grouped (get started, day to day, cleanup, diagnostics, service) and fit an 80-column terminal.
• memcap init mentions the agent hooks. When it finds no Claude Code or Codex profile, it now says how to add the hooks later (memcap integrate). Before, it skipped them without a word.
• Clearer reporting status. After you decline reporting, memcap report status now says reports stay on this Mac. Before, it went on describing GitHub publishing.
• Docs. Added a social preview card, and questions now go to Discussions.

Admission, measurement and enforcement are unchanged from v0.32.5.

Upgrade: brew upgrade memcap

v0.32.5 — Reservations shrink after a peak on a busy queue

Busy queues no longer hold a finished peak for the rest of a job. Pressure checks, headroom and safety margins are unchanged.

Fix

• Reservations shrink after a peak again, even when many jobs are waiting. memcap reserves a running job's recent peak and lets it drop after 60 seconds of steady lower usage. With several jobs waiting, observations often arrived a fraction of a second out of order. memcap mistook that for a gap in measurement and kept the job's lifetime peak reserved until it finished. On October 27, a Go test run that peaked at 4.5 GiB kept 5.6 GiB reserved for eight minutes while using 0.25 GiB, so 15 jobs waited while memory pressure was green. Out-of-order observations now count toward the window. They can raise a reservation but never lower it early. Real measurement gaps still hold the reservation.

Upgrade

brew upgrade memcap

Jobs that are already running keep their current reservations until they finish. New jobs use v0.32.5.

Full details: CHANGELOG.md

v0.32.4 — Queued jobs survive upgrades

Queued jobs now survive an upgrade. Admission, pressure checks, memory accounting and kill policy are unchanged.

Fix

• Upgrading no longer stalls the queue. brew upgrade deletes the previous installation while queued jobs may still be waiting on it. Those waiting jobs measured memory through their own, now deleted, copy of memcap, so every measurement failed. Each failure also held back waiters from the new version. On October 27 one upgrade stalled nine jobs across several sessions for about 25 minutes, with pressure green and slots free. A waiting job now falls back to the installed memcap when its own copy is gone. It also loads everything it needs when it starts, and stops re-reading every code file on each measurement.

Also in this release

• A rewritten README with a demo, a three-line quickstart and a short explanation of how memcap works.
• Internal working notes moved to docs/dev-notes/.

Upgrade

brew upgrade memcap

Jobs that were already waiting on v0.32.3 or earlier still run that older code. To keep them moving during this one upgrade, run HOMEBREW_NO_INSTALL_CLEANUP=1 brew upgrade memcap, then brew cleanup memcap once they finish. Upgrades from v0.32.4 onward do not need this.

Full details: CHANGELOG.md

v0.32.3 — Retire test environments whose containers no longer exist

A follow-up to v0.32.2. Admission, pressure checks, memory accounting and kill policy are unchanged.

Fix

• Retire test environments whose containers are gone. Once v0.32.2 let the watchdog reach Docker again, cleanup found disposable test environments whose containers had been removed outside memcap, for example by an engine reset. It refused them on every pass, logging one line per environment per minute, because the empty container set did not match the recorded one. When no container carries the environment's exclusive project label at all, there is nothing left to stop or protect, so memcap now marks it stopped. A surviving container that is still running, or whose identity no longer matches, is still left alone.

Upgrade

brew upgrade memcap

No re-integration or session reload is required.

Full details: CHANGELOG.md

v0.32.2 — Watchdog tool PATH, analytics collector refresh and doctor whitespace

A maintenance release. Admission, pressure checks, memory accounting and cleanup policy are unchanged.

After a week on v0.32.1, the queue behaved as intended. Pressure never reached red, expired-sample denials fell from 21,422 to zero, and the 95th-percentile queue wait dropped from 19 minutes to about one minute. The same logs exposed three operational bugs, fixed here.

Fixes

• The watchdog can find Homebrew tools. launchd starts memcap watch with only the system directories on PATH, so docker was never found. Cleanup of finished disposable test environments failed on every pass and wrote about 70,000 identical errors to memcap.err. The watchdog now appends /opt/homebrew/bin and /usr/local/bin. It appends rather than prepends, so tools that already resolved, python3 included, keep resolving to the same binary.
• Upgrades refresh the analytics collector. brew upgrade replaces the code on disk but never restarts the long-lived analytics collector, so one kept running a deleted older version for two releases and silently dropped every newer event field. The collector now records which installation it loaded, and the next watch pass restarts it if that differs. It restarts at most once per installation, so it can never loop. The manual launchctl kickstart step after upgrades is no longer needed.
• memcap doctor ignores whitespace-only differences. A blank line added to CLAUDE.md or AGENTS.md by an editor no longer reports the integration as stale. Any change to the guidance text still warns.

Upgrade

brew upgrade memcap

No re-integration or session reload is required. Existing queued jobs finish on the code they loaded, and new commands use v0.32.2. The first watch pass after the upgrade refreshes the analytics collector if it is enabled.

Full details: CHANGELOG.md

v0.32.1 — Sampling-expiry churn under lock contention and analytics cohort crash

• Stop queued work from losing its turn to sample expiry under lock
  contention. Waiters sample memory before taking the queue's registry lock;
  with about 40 waiters the lock wait alone exceeded the two-second freshness
  limit, so admission denied with "sampling" over and over while other
  supervisors were publishing fresh samples. v0.32.0 recorded 21,445 such
  denials, and short jobs waited about an hour on October 19. After taking the
  lock, a waiter now adopts a newer published sample of the same configuration
  that is still under two seconds old. It only reads the cache and never probes
  under the lock. A failed measurement is never replaced, and red pressure,
  headroom, slots and the launch-time pressure recheck are unchanged.
  memcap analytics today reports how often this happens as "refreshed under
  lock".
• Fix memcap analytics today crashing when a retained job had no build, for
  example a pending job whose queued row was evicted. Such jobs now report
  their build from any surviving row, or as "unknown".

v0.32.0 — Zombie measurement faults, dev-server slots and kill logging

• Stop counting exited, unreaped (zombie) processes as missing footprint rows.
  top never lists them and they hold no memory, but an Android emulator that
  never reaps its children left 135 of them, crossed the 10% missing-rows
  threshold and marked every sample faulty. That held all heavy admission at
  green pressure. Zombies stay in the process table at zero memory, and
  memcap status shows how many were excluded. Processes top genuinely lost
  still count as missing and still fault at the same threshold.
• Register dev servers launched through an explicit memcap run wrapper, or
  backgrounded with a single trailing &, as persistent resources instead of
  finite jobs that hold a finite slot indefinitely. Wrappers with --memory,
  --resource or --shell, and & followed by further commands, stay finite.
• Queue simctl bootstatus as a simulator start only with -b; without it the
  command only reports boot status. simctl boot is unchanged.
• Log a process that exited after SIGTERM but awaits reaping as exited, not as
  PID reuse. No SIGKILL is sent in that case. A changed command line with an
  unchanged start time is logged separately and still not escalated, because
  one-second start times cannot exclude reuse.
• Store analytics events in compact rowid tables; most rows previously took
  their own overflow page, so the page cap held about 90 minutes of events.
  Existing files convert once at collector startup and fall back to the old
  layout on failure. Eviction reclaims pages incrementally and removes routine
  events before high-rate sampling events, then incident evidence. The page cap
  is unchanged, so retention grows but does not reach 14 days.
• Hold the swap-used warning until swap drops 1 GB below the threshold, and
  notify once per episode, with no repeat within an hour.
• Prune job-feedback guidance receipts, orphaned locks and notices older than
  seven days, hourly from the watchdog pass. Held locks and notices for jobs in
  the queue registry are kept; the pass stops while memcap is paused.
• Admission, pressure, reservation and termination policies are unchanged.

v0.31.0 — Native emulator queries and durable incident evidence

This release fixes Android emulator listing classification and improves diagnosis of queue waits, cancellations and compiler memory use.

• Exact emulator listings remain lightweight. Real boots still require admission.
• Agent feedback distinguishes explicit waits and compound heavy execution from independent inspection.
• Private analytics retain bounded cancellation/action evidence and job checkpoints for up to 90 days, prioritize incident decisions, and support tool-call selection without publishing identifiers or commands.
• Long waits include observed blockers and finite-slot occupants. Learning reports distinguish missing coverage from usable measurements; release comparisons include matching workloads.
• Direct local Node/TypeScript invocations support bounded compiler profiles. Sampling-only retries are shorter without relaxing freshness or pressure checks.

Memory limits and termination policy are unchanged. A TypeScript process over the configured cap still needs a smaller workload; prediction is not an exemption. The initiating sender of historical cancellation #403 remains unknown and that issue stays open. New report #408 concerns Claude's worktree guard rejecting a managed heavy wrapper before execution. New report #410 describes a v0.30 heavy-work wait with recorded slot/headroom blocking. Both remain open and are not claimed fixed here.

Existing jobs keep their loaded runner until completion. Stable hooks use the new installation on subsequent calls. No profile edit or engine restart is required. If analytics is enabled, refresh its collector with launchctl kickstart -k gui/$(id -u)/com.memcap.analytics.

Validation: 658/658 Bats tests passed both normally and with isolated HOME/no Docker; grouped and individual shellcheck and all 27 Bash parse checks passed. The pre-release baseline is saved locally. Production performance gains will be assessed after comparable workloads run; this release does not claim a measured latency improvement yet.

memcap v0.30.0

Fixes from the October 8 incident investigation:

• Xcode version queries and shell executable lookups stay native; actual launches retain admission.
• Codex wrappers preserve the tool's actual working directory.
• Isolated Claude agents retain original lightweight commands so optional observation does not obstruct the host worktree guard; unknown-call telemetry is omitted in that scope while heavy admission remains intact.
• Queue feedback respects final task results and no longer prompts false search/polling reports after ordinary build waits.
• Expo startup uses admission and bounded Metro workers. Standalone Expo servers are tracked as persistent resources, so finite completion waits can finish.
• Supported direct Android emulator launches retain memory accounting and admission without occupying finite-work slots until shutdown. Existing supervisors keep their original classification until they finish.

Memory budgets, headroom, pressure gates and termination rules are unchanged. Existing work is not restarted. New commands and stable installed hooks pick up the new code; existing supervisors retain their loaded version. No hook trust approval or integration rewrite is required.

The October 8 reports #391–#401 are covered by these fixes and incident dispositions. The Expo termination in #399 followed the configured oversized-process policy; missing startup admission and worker controls are fixed. Worker limiting reduces startup concurrency but is not a hard cap on application memory.

Validation: 100 focused tests, 657/657 Bats checks normally, and 657/657 with isolated HOME and no Docker; ShellCheck and individual Bash parsing passed. Both push and PR CI passed. A private pre-release analytics baseline is retained for comparison. Production performance improvements will be evaluated after rollout, not inferred from test success.