akm-cli 0.9.0-beta.3 → 0.9.0-beta.4

package/CHANGELOG.md

@@ -341,6 +341,167 @@ proposal and log storage, `--format html` output, and per-stage LLM telemetry.
   `migrate-storage` change is pinned by a sha256 + file-mode fixture-stash
   differential test.
 
+## [0.8.14] - 2026-06-11
+
+### Fixed
+
+- **`akm extract` minContentChars default lowered from 500 to 10.** The 500-char
+  threshold used inputCount (raw session size) but analysis showed 209 of 218
+  candidate-producing sessions had inputCount < 500 — tiny agent sessions (22–368
+  chars) regularly yield 1–5 candidates. The only reliably skippable sessions are
+  empty ones (0 chars, journal files). Default lowered to 10 to catch only
+  truly empty sessions while preserving all signal-bearing content. Closes #597.
+
+## [0.8.13] - 2026-06-11
+
+### Fixed
+
+- **`akm extract` minContentChars gate filtered all sessions.** The threshold was
+  checked against `filtered.stats.outputCount` (post-noise-filter chars), but the
+  pre-filter strips so much boilerplate that even signal-bearing sessions end up
+  below 500 chars of output. All 75 sessions in the first post-deploy run were
+  filtered, dropping candidates from 4–13 to 0. Fix: gate on `inputCount` (raw
+  session size) instead — a session with < 500 raw chars has nothing worth
+  extracting regardless of what the pre-filter produces. Closes #596.
+
+## [0.8.12] - 2026-06-11
+
+### Fixed
+
+- **`akm extract` calling the LLM for noise sessions that never yield candidates.**
+  96% of processed sessions (72/75 measured) produced zero candidates, consuming
+  ~330 s of LLM time per run. The pre-filter had no minimum content threshold —
+  sessions as short as 50 chars were sent to the LLM regardless. A new
+  `minContentChars` gate (default 500) skips the LLM call when post-filter
+  content falls below threshold, cutting extract LLM calls by ~95% on typical
+  stashes. Configurable via `profiles.improve.<name>.processes.extract.minContentChars`.
+  Closes #595.
+
+## [0.8.11] - 2026-06-11
+
+### Fixed
+
+- **`akm improve --profile <name>` ignored profile's `extract.enabled: false` setting.**
+  The session-extraction gate in the preparation stage called
+  `isLlmFeatureEnabled(config, "session_extraction")`, which hardcodes a lookup
+  against `profiles.improve.default.processes.extract.enabled`. Any non-default
+  profile that set `extract.enabled: false` (e.g. `quick-shredder`) was silently
+  ignored, causing the extract pass to run regardless. The fix adds a
+  `resolveProcessEnabled("extract", improveProfile)` check so the active
+  resolved profile gates the pass correctly. Closes #593.
+
+## [0.8.10] - 2026-06-11
+
+### Fixed
+
+- **`akm improve` taking 8–10 minutes per run due to O(n) DB writes for
+  profile-filtered refs.** When a profile disables reflect and distill for
+  certain asset types, `collectEligibleRefs` marks those refs as
+  `profile_filtered_all_passes`. The caller then emitted one `improve_skipped`
+  event per ref — a sequential DB write for each. On a ~9 000-ref stash this
+  was ~500 s of SQLite writes before any consolidation or memory inference
+  began. The fix collapses the per-ref loop into a single summary event
+  carrying a `count` field, eliminating ~9 000 sequential writes per run.
+  Closes #590.
+
+## [0.8.9] - 2026-06-11
+
+### Fixed
+
+- **`akm improve` validation pass was O(n) in stash size, causing ~510 s overhead
+  on large stashes.** For every indexed ref, the preparation phase called
+  `findAssetFilePath()` — an async round-trip to the index DB followed by a
+  filesystem probe — serially inside a `for…await` loop. With ~9 000 indexed
+  refs at ~55 ms each, this loop consumed the entire 600–900 s run budget before
+  any reflect, triage, or memory-inference work began. The fix threads
+  `filePath` from the planning stage (`collectEligibleRefs`) through
+  `ImproveEligibleRef` so the validation pass and the disk-existence guard can
+  use the pre-resolved path directly. The async lookup is retained only as a
+  fallback for refs that enter via a narrow scope (e.g. `--scope ref:foo`).
+  Closes #587.
+
+## [0.8.8] - 2026-06-11
+
+### Fixed
+
+- **SQLite `SQLITE_BUSY` errors under concurrent improve runs.** `busy_timeout`
+  was set to 5 000 ms in all three database open paths (`openDatabase`,
+  `openExistingDatabase`, `openStateDatabase`). Under a busy cron schedule — or
+  when a reindex triggered by memory inference ran concurrently with an event
+  write — the 5 s window was routinely exhausted, producing "database is locked"
+  failures. Raised to 30 000 ms across all three paths so transient lock
+  contention is retried for up to 30 s before surfacing as an error.
+
+## [0.8.7] - 2026-06-09
+
+### Fixed
+
+- **`incrementalSince` duration strings were silently ignored.** Values like
+  `"30m"`, `"24h"`, `"7d"` were passed raw to `narrowToIncrementalCandidates`,
+  which compared them against ISO timestamps via string sort. All `2026-...`
+  timestamps are lexicographically less than `"30m"` (`'2' < '3'`) and `"24h"`
+  (`"20" < "24"`), so `isChanged()` always returned `false` and the candidate
+  pool was silently emptied rather than filtered to the window. The fix adds
+  `parseSinceToIso()`, which resolves human duration strings to absolute ISO
+  timestamps before comparison. Values that already look like ISO timestamps
+  are passed through unchanged.
+
+## [0.8.6] - 2026-06-09
+
+### Added
+
+- **`consolidate.incrementalSince` profile config field.** Setting
+  `incrementalSince: "7d"` (or any duration string) in the `consolidate` block
+  of an improve profile narrows the candidate pool to memories modified within
+  that window plus their top-5 graph neighbours, keeping each pass focused on
+  recent changes. This makes it practical to run consolidation more often than
+  once per day (e.g. via `akm-improve-consolidate` every 4 h) without
+  re-scanning the full pool every time. The nightly default profile leaves this
+  unset (full-pool sweep, same as before). The `incrementalSince` option already
+  existed in `akmConsolidate()` but was hardcoded off at the call site; the
+  field is now surfaced in the config schema and read from the profile.
+
+## [0.8.5] - 2026-06-09
+
+### Fixed
+
+- **Consolidation starved merge recall; the memory pool grew unbounded.** Commit
+  `633ece41` made the `incrementalSince` narrowing unconditional, so every
+  consolidation run only judged memories changed since the last run plus their
+  immediate vector-neighbors. Stale-but-unmerged duplicate clusters were never
+  re-examined, so the eligible pool grew monotonically and never shrank, and
+  contradiction detection (which rides on the consolidation pass) went dark.
+  Consolidation only runs on the nightly default-profile pass (`quick`/`frequent`
+  disable it), so a full-pool sweep is correct and affordable; the override is
+  removed. `lastConsolidateTs` still gates whether the pass runs.
+
+## [0.8.4] - 2026-06-08
+
+### Fixed
+
+- **`akm tasks sync` ignored schedule changes.** Sync classified any task already
+  present in the OS scheduler as "unchanged" without comparing its installed
+  entry, so editing a task's `schedule:` in the `.yml` never reached the crontab —
+  the only way to apply a new schedule was to `remove` and re-`add` the task. The
+  same gap affected `tasks enable`/`disable`, which merely toggled the existing
+  cron line's comment and so re-enabled a stale schedule. Sync now compares the
+  backend's installed signature against the signature the current definition would
+  produce and reinstalls on drift (reported in a new `updated[]` field);
+  `enable`/`disable` reinstall from the current `.yml` instead of toggling in
+  place. Backends that can't cheaply read their installed form fall back to an
+  idempotent reinstall, so the fix is correct on launchd/schtasks too. The cron
+  backend gains `expectedSignature()` and a signature on each `list()` entry.
+
+### Added
+
+- **`akm improve --skip-if-locked`.** When another improve run already holds the
+  lock, the run logs and exits 0 with a no-op result (`skipped.reason:
+  "lock-held"`) instead of failing with the "already running" config error
+  (exit 78). Intended for high-frequency scheduled runs (e.g. an every-30-min
+  `quick` pass) that would otherwise pile up exit-78 failures whenever a longer
+  run overlaps them. Default off — the hard error is preserved for interactive
+  use. The result is still recorded so the skip is auditable.
+
 ## [0.8.3] - 2026-06-08
 
 ### Fixed

package/dist/commands/improve/consolidate.js

@@ -1992,10 +1992,23 @@ async function checkPreEmitDedup(opts) {
  * everything changed or the index can't answer (fail-open to preserve merge
  * correctness). `since` is an ISO timestamp.
  */
+/**
+ * Parse a human-readable duration string (e.g. "30m", "24h", "7d") to an ISO
+ * timestamp representing `now - duration`. Returns the input unchanged when it
+ * doesn't match the pattern (assumed to already be an ISO timestamp).
+ */
+function parseSinceToIso(since) {
+    const m = since.match(/^(\d+)(m|h|d)$/);
+    if (!m)
+        return since;
+    const multiplier = { m: 60_000, h: 3_600_000, d: 86_400_000 }[m[2]];
+    return new Date(Date.now() - parseInt(m[1], 10) * multiplier).toISOString();
+}
 export function narrowToIncrementalCandidates(memories, since, warnings) {
+    const sinceIso = parseSinceToIso(since);
     const isChanged = (m) => {
         try {
-            return fs.statSync(m.filePath).mtime.toISOString() > since;
+            return fs.statSync(m.filePath).mtime.toISOString() > sinceIso;
         }
         catch {
             return true; // never silently drop a memory we cannot stat
@@ -2037,7 +2050,7 @@ export function narrowToIncrementalCandidates(memories, since, warnings) {
             closeDatabase(db);
     }
     const candidates = memories.filter((m) => keep.has(m.name));
-    warnings.push(`Incremental consolidation: ${changed.length} changed + neighbours → ${candidates.length}/${memories.length} memories considered (since ${since}).`);
+    warnings.push(`Incremental consolidation: ${changed.length} changed + neighbours → ${candidates.length}/${memories.length} memories considered (since ${since}${sinceIso !== since ? ` = ${sinceIso}` : ""}).`);
     return candidates;
 }
 function loadMemoriesForSource(source, stashDir, warnings) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "akm-cli",
-  "version": "0.9.0-beta.3",
+  "version": "0.9.0-beta.4",
   "type": "module",
   "description": "akm (Agent Knowledge Management) — A package manager for AI agent skills, commands, tools, and knowledge. Works with Claude Code, OpenCode, Cursor, and any AI coding assistant.",
   "keywords": [
@@ -59,6 +59,7 @@
     "test:unit": "bun test --parallel=${TEST_PARALLEL:-12} --timeout=30000 ./tests --path-ignore-patterns=tests/integration",
     "test:integration": "bun test --parallel=${TEST_PARALLEL:-12} --timeout=30000 ./tests/integration ./tests/commands ./tests/workflows",
     "test:node-smoke": "bun scripts/node-smoke.ts",
+    "test:node-compat": "AKM_NODE_COMPAT_TESTS=1 bun test --timeout=120000 tests/integration/node-compat.test.ts",
     "test:sharded": "bun test ./tests --shard=1/4 & bun test ./tests --shard=2/4 & bun test ./tests --shard=3/4 & bun test ./tests --shard=4/4 & wait",
     "test:time": "bun scripts/test-timing-report.ts",
     "lint:isolation": "bun scripts/lint-tests-isolation.ts",