akm-cli 0.9.16 → 0.9.17-alpha.2

package/CHANGELOG.md

@@ -6,6 +6,510 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [0.9.17-alpha.2] - 2026-09-24
+
+### Fixed
+
+- **A config carrying the retired `experimental.workflowEngine` key no longer
+  fails to load.** `ExperimentalConfigSchema` moved from `.passthrough()` to
+  `.strict()` in 0.9.16 (`cc6152e02`), after `workflowEngine` had already been
+  removed from it in `e0655d13c`; a real config a 0.9.15 install wrote (whose
+  passthrough still accepted the key) then failed every command with
+  `Invalid config: experimental: Unrecognized key(s) in object: 'workflowEngine'`.
+  The config loader now strips known-retired `experimental.*` keys in memory
+  before validation, warning once and naming `akm migrate apply`; a genuinely
+  unknown/misspelled key (e.g. `improveAutonomyy`) still fails closed.
+  `akm migrate apply` removes the retired key from `config.json` on disk
+  (with the usual backup), and `--dry-run` reports the pending removal.
+- **Unscoped `akm task sync` no longer crashes when an enabled website or npm
+  bundle is configured.** The sync plan loop resolved every active source
+  through the write-target resolver, which rejects any kind other than
+  `filesystem`/`git` outright (writes, and therefore scheduler state, are
+  undefined for those kinds — the same rejection `akm task enable` already
+  hit). Unscoped sync now skips non-filesystem/git bundles when building
+  install operations — they never carried schedulable tasks — while
+  inactive-bundle removal/revocation still sees them. A scoped
+  `akm task sync --bundle <website-or-npm-bundle>` now fails with a clear
+  usage error instead of the write-target `ConfigError`.
+
+## [0.9.17-alpha.1] - 2026-09-24
+
+### Added
+
+- **`akm improve --require-engines` now records its reachability probe on the
+  run result (R17).** `assertRequiredEnginesReachable` only ever reported a
+  failure (abort, exit 78); a probe that passed — including a slow or
+  flapping gateway that still answered in time — left no trace once the run
+  proceeded. It now returns one outcome per probed target (`process`,
+  `engine`, `endpoint`, `reachable`, `latencyMs`), threaded through a new
+  `AkmImproveOptions.engineProbe` and copied onto the persisted result as
+  `AkmImproveResult.engineProbe`. Omitted entirely when `--require-engines`
+  was not passed; a result persisted without it (every run before this
+  change) still decodes. `--require-engines --dry-run` results carry it too.
+- **Reflect had no way to exclude raw wiki-ingest snapshots, which are the
+  longest generations in the ledger (89.5s/161.8s observed).** `wikis/articles/raw/*.md`
+  website snapshots index as `knowledge/wikis/articles/raw/<slug>`, and
+  reflect's `allowedTypes` filter is type-only, so it can't exclude a subset
+  of the `knowledge` type. `processes.reflect` now accepts an optional
+  `excludeRefPrefixes: string[]` — conceptId prefixes, matched after
+  stripping an optional `bundle//` from both the ref and each prefix.
+  `shouldSkipRef` skips a matching ref with reason `exclude-filter`, for
+  reflect only (distill and consolidate are memory-only and reject the key).
+  A trailing `/` on a prefix is ignored, so
+  `"knowledge/wikis/articles/raw/"` excludes the same refs as
+  `"knowledge/wikis/articles/raw"`.
+
+- **`akm health` now checks state.db's own SQLite integrity.** A new hard
+  `state-db-integrity` check runs a read-only `PRAGMA quick_check` against
+  `state.db` and fails, naming the returned diagnostic lines and the repair
+  steps (back up, dump/restore via `sqlite3`, verify, swap in), when it
+  reports anything other than `ok`. The same check reports state.db's
+  freelist ratio (the fraction of pages `VACUUM` could reclaim) and warns
+  above 50%. Previously nothing in `akm health` looked past a successful
+  append/read round trip, which stays true on a database that is corrupt at
+  the SQLite level.
+- **The retention purge (`akm improve`) now VACUUMs state.db when more than
+  half its pages are free**, immediately after the events/improve_runs/
+  cycle-metrics purge, recording a `state_db_vacuumed` event with pages
+  before/after. Opportunistic: a locked/busy database is skipped, not
+  raised, so it never fails the purge pass it follows.
+
+### Changed
+
+- **The orphan-state GC pass no longer probes index.db once per pending
+  row.** `runOrphanStateGcPass` used to call `getEntryByRef` (up to two
+  statements each, via its bare-ref fallback) for every pending
+  `asset_salience` / `asset_outcome` row — 2,101 pending rows cost 83–100s
+  per run. It now builds one snapshot of every live `item_ref` in index.db up
+  front and matches every pending row against it in memory: O(1) index.db
+  queries per run instead of one probe per row, with the same live/orphan
+  resolution (including the bundle-qualified-exact and bare-conceptId-suffix
+  fallback) as before.
+- **Memory inference no longer forces a full reindex for the file(s) it
+  writes.** The post-inference maintenance step used to call the full
+  `reindexFn` (42–220s per run, typically for one written derived fact)
+  whenever memory inference split a parent. `runMemoryInferencePass` now
+  reports the exact paths it wrote or rewrote (`writtenPaths`, sourced from
+  the run's write-provenance journal), and the maintenance pass indexes just
+  those files with `indexWrittenAssets` instead — closing and reopening the
+  shared index.db handle around the call with the same discipline the full
+  reindex used (#584). The separate post-consolidation full reindex is
+  removed outright rather than re-gated: it used to fire whenever
+  `consolidation.processed > 0` (memories the LLM judged), but
+  merge/delete/contradict ops are advisory and never auto-applied, and the
+  one op that does execute — promote — writes a proposal to state.db, not to
+  the stash. Consolidation therefore cannot change a file the index reads,
+  so the reindex had no precondition it could ever satisfy.
+- **The improve loop's reflect dispatch now checks the proposal
+  fingerprint/rejection-backoff guard *before* calling reflect, not just
+  after.** `fingerprint_match` and `rejection_backoff` were evaluated only
+  inside `createProposal`, which runs after reflect's full generation and
+  quality-judge call — so a ref already guaranteed to be skipped still paid
+  the LLM cost (measured: 2–16% of reflect LLM seconds spent on refs the
+  guard then discarded). The guard's fingerprint is an input fingerprint
+  (target ref, source, before-hash, model id), computable before dispatch, so
+  `checkProposalGuard` (`src/commands/proposal/repository.ts`) exposes the
+  identical check `createProposal` runs post-generation — the two share one
+  implementation and can never disagree. `runLoopReflectPass`
+  (`src/commands/improve/loop-stages.ts`) now calls it first; a hit skips
+  `reflectFn` entirely and lands in the existing `reflect-cooldown` bucket
+  with the same `reflect_invoked` event the signal-delta cursor
+  (`buildLatestProposalTsMap`) reads, so cursor advancement and run-result
+  classification are unchanged. `createProposal`'s post-generation check
+  remains the authoritative gate.
+- **Consolidate's plan schema and prompt are promote-only.** The apply loop
+  only ever executed `promote` — `merge`/`delete`/`contradict` were advisory
+  by design and never applied — but the schema still asked for all four ops
+  plus a free-text `warnings` array, and completion tokens rose from 7–8k to
+  21–30k per run after the 35B-A3B model switch with no change in
+  promotions. `CONSOLIDATE_PLAN_JSON_SCHEMA` and `consolidate-system.md` now
+  request only `promote` (with `reason` capped at 200 chars), and `isValidOp`
+  rejects any other op shape — e.g. from a model that ignores the schema —
+  with the existing "skipping invalid operation" warning instead of treating
+  it as an actionable plan entry. `ConsolidateResult.merged` / `deleted` /
+  `contradicted` and the `planned` op breakdown are unchanged in shape and
+  stay zero.
+- **`improve-maintenance-passes.test.ts` moved under `tests/integration/`.**
+  The suite opens a real `state.db` via `openStateDatabase`, which AGENTS.md's
+  ORG-03..06 rule places under `tests/integration/`, not `tests/`; no content
+  change. Also corrected
+  `docs/architecture/specs/improve-collapse-churn-detector-design.md` §2.5,
+  which described the post-loop collapse-detector gate as `consolidationRan
+  OR recombination.processed > 0` — no `recombination` value is plumbed into
+  `runImprovePostLoopStage` and no recombine pass exists in the codebase, so
+  the spec now matches the shipped `consolidationRan`-only gate and notes
+  that the recombine-triggered pass is not implemented.
+- **Graph-extraction relations are now compact `[from, type, to]` triples
+  instead of `{"from","to","type"}` objects, and the batch graph-extraction
+  call now sends a `responseSchema`.** The object-keyed form cost 10+ tokens
+  per relation for no signal, and completion tokens cost far more than
+  prompt tokens; a compact triple form measured −51% / −18% completion
+  tokens on two chunks. `graph-extract.ts`'s single-asset and batch prompts
+  and JSON schemas now ask for `["from", "type", "to"]` (`type` may be `""`);
+  `parseGraphExtraction` accepts both the triple form and the legacy object
+  form (a relation-level `confidence` is still read from a legacy object,
+  though the schema no longer offers it — the prompt never asked for one).
+  Separately, production runs graph extraction batched
+  (`processes.graphExtraction.batchSize`), and `extractGraphFromBodies` sent
+  no `responseSchema` at all, so the R12b output-bounding schema only ever
+  reached the single-asset path. The batch call now sends the same
+  `maxItems`-bounded schema (scoped to the batch's asset count) through the
+  same `supportsJsonSchema`-gated `responseSchema` field the single-asset
+  call uses. `GRAPH_EXTRACT_PROMPT_VERSION` bumps `v2` → `v3`, so every file
+  re-extracts once on the next graph pass — entity semantics, caps, chunking
+  and batch sizing are unchanged.
+
+### Removed
+
+- **The write-only distill/proposal eval-cases path.** `writeEvalCase`
+  (`src/commands/improve/eval-cases.ts`) wrote a Markdown file per rejection
+  under `$STATE/improve/eval-cases/<stash>/` that nothing ever read back, and
+  `countEvalCases` reported a cumulative on-disk file count as if it were a
+  per-run number (surfaced as `evalCasesWritten` on the improve result and in
+  `akm health`'s improve metrics). A rejected proposal row (see above) now
+  carries the same information through a path something actually reads.
+  Deleted `eval-cases.ts` and its two `loop-stages.ts` call sites, the
+  `evalCasesWritten` field from `AkmImproveResult` and every health-metrics
+  reader/aggregator, and the `improve_completed` event's `evalCasesWritten`
+  field. `decodeImproveResult` still accepts (and ignores) `evalCasesWritten`
+  on an envelope an older release wrote, and existing eval-case files on disk
+  are untouched — `getEvalCasesDir` (`core/paths.ts`) stays, since
+  `scripts/akm-migrate/migrate/writer-relocation.ts` still uses it to
+  relocate them from the legacy `$STASH/.akm/eval-cases/` path.
+
+### Fixed
+
+- **The lesson quality judge's ACTIONABILITY criterion carried no signal, and
+  the judge's request/parser let a differently-spelled or extra key change
+  the verdict (R16).** Splinter measured ACTIONABILITY at AUC 0.46 against
+  accept/reject outcomes — no better than chance — and averaging it into the
+  score pulled every verdict toward its 3.0 mode, i.e. the review band.
+  `buildJudgePrompt` no longer asks for it;
+  `LESSON_JUDGE_CRITERIA_KEYS` is now `novelty`/`nonRedundancy` only.
+  Separately, `runQualityJudge`'s request sent no `responseSchema` while the
+  prompt text spelled criteria as NON-REDUNDANCY / FEEDBACK ALIGNMENT, so a
+  model that echoed a differently-cased or -spelled key turned the verdict
+  into a parse failure routed to review; and `parseJudgeResponse` averaged
+  over every key present in `scores`, so an unexpected extra key changed the
+  score. `runQualityJudge` now sends a strict `responseSchema` — built from
+  the judge's own expected criteria keys, `additionalProperties: false` at
+  both levels — through the same `supportsJsonSchema`-gated
+  `request.responseSchema` path `src/llm/graph-extract.ts` uses, a no-op for
+  providers that don't opt in; and `parseJudgeResponse` now reads, validates,
+  and averages only the expected keys, silently ignoring any other key
+  instead of averaging or validating it. A missing expected key is still a
+  parse failure, unchanged.
+- **The reflect quality-gate's "no judge configured" warning named a config
+  key nothing reads.** It told users to set
+  `improve.strategies.<name>.processes.reflect.qualityGate.engine`, but
+  `qualityGate` is `{ enabled }` passthrough — `resolveReflectQualityJudgeRunner`
+  always uses the generation runner when it is an LLM, or falls back to
+  `defaults.llmEngine` via `resolveImproveLlmExecution` with no profile/process
+  layer, so that key was never read. The warning now names only
+  `defaults.llmEngine`.
+- **The distill/reflect LLM-as-judge quality gate inherited the generation
+  runner's temperature, and its averaged score hid which criterion actually
+  failed.** `runQualityJudge`'s request only pinned `enableThinking: false`,
+  so the judge ran at whatever temperature generation used — measured at 0.3,
+  the verdict flipped on 10/16 identical inputs, vs. 0/16 at temperature 0.
+  The request now also pins `temperature: 0`, for both the distill and
+  reflect judges that share this function, independent of the runner's
+  configured temperature. Separately, both judge prompts asked for one
+  averaged float, so a criterion carrying no signal was invisible in
+  production. They now ask for per-criterion integer scores
+  (`buildJudgePrompt`: novelty/actionability/nonRedundancy;
+  `buildReflectJudgePrompt`: feedbackAlignment/preservation/quality), averaged
+  in code to the same `score` the unchanged 3.5/2.5 thresholds gate on. The
+  parser accepts this new `{"scores": {...}, "reason"}` shape and still
+  accepts the old `{"score": <float>, "reason"}` shape a model may return;
+  each criterion (or the bare score) must be a finite number in 1..5 or the
+  response routes to review exactly as a parse failure does today. The
+  per-criterion scores, when present, are now carried through
+  `QualityJudgeResult.criteria` into the `distill_invoked` event metadata and
+  rejection-envelope frontmatter `writeQualityRejection` writes, and into
+  reflect's `reflect_completed` rejection event as `qualityCriteria`.
+- **The judge parser accepted a partial `scores` object and auto-passed it.**
+  `parseJudgeResponse` validated only that whatever criterion keys arrived
+  held finite 1-5 values, then averaged over those keys alone — so a
+  truncated judge response like `{"scores": {"novelty": 5}, "reason": "…"}`
+  parsed to `score: 5.0` and `pass: true`, promoting content the judge never
+  finished evaluating on its other criteria. `runQualityJudge` now passes the
+  criterion key set its prompt asked for (`buildJudgePrompt`:
+  novelty/actionability/nonRedundancy; `buildReflectJudgePrompt`:
+  feedbackAlignment/preservation/quality) down to `parseJudgeResponse`, which
+  returns a parse failure — routed to review, exactly as a malformed response
+  is today — when any expected key is missing from `scores`.
+- **The reflect pre-generation proposal-guard skip (R9) emitted `reflect_invoked` with no paired `reflect_completed`.** `runLoopReflectPass`'s guard-skip branch in `loop-stages.ts` appended a synthetic `reflect_invoked` event to advance the signal-delta cursor, but never called `reflectFn`, so `reflect.ts`'s own `reflect_completed` emission never ran either — a new, permanent source of unpaired `reflect_invoked` rows for every fingerprint/backoff hit, violating the invoke/complete pairing invariant `buildReflectEventEmitters` documents. The branch now also appends a matching `reflect_completed` (`ok:false`, `reason:"cooldown"`, `subreason:"pre_generation_guard"`), mirroring `emitFailed`'s shape.
+- **R9's pre-generation proposal guard covered reflect only — distill paid for a full generation + judge call before the same fingerprint/backoff guard could reject it.** `runLoopDistillPass` had no equivalent of `runLoopReflectPass`'s pre-check, even though `createProposal`'s post-generation guard (and every rejected row R10 now mints under `source: "distill"`) applies to distill just as much. `runLoopDistillPass` now calls `checkProposalGuard` against the derived lesson/knowledge ref (distill's real `createProposal` call never targets the input ref) before dispatching `distillFn`; a hit routes to the pass's existing `distill-skipped` bucket and emits `distill_invoked` with a `skipped` outcome so `buildLatestProposalTsMap`'s signal cursor still advances.
+- **The distill pre-generation proposal guard could suppress a legitimate dispatch by checking a ref distill would never target.** For a memory input, distill's real `createProposal` call targets one of two refs decided at dispatch time inside `planMemoryKnowledgePromotion` — the derived knowledge ref when the deterministic promotion heuristic fires, the derived lesson ref otherwise — but `runLoopDistillPass`'s pre-check checked both candidate refs and skipped on the FIRST guard hit, so a stale fingerprint/backoff hit on the ref distill would NOT have targeted silently suppressed dispatch until that ref's fingerprint happened to change. The pre-check now resolves the SAME target `planMemoryKnowledgePromotion` would via `wouldPromoteMemoryToKnowledge` (`distill/promote-memory.ts`) — a thin wrapper that delegates to `planMemoryKnowledgePromotion` itself so the classification can never drift from the real dispatch decision, with no LLM call — and checks only that ref; content and the classification's `durableInputRef` are read via `planned.ref` alone, matching `akmDistill`'s real dispatch, while `planned.itemRef ?? planned.ref` feeds only the feedback-events query.
+- **The `akm improve` triage pre-pass drain's judgment LLM calls were unattributed in the usage report.** `runTriagePrePass`'s `drainProposalsFn` call dispatched judgment calls with no `withLlmStage` wrapper, unlike the standalone `akm proposal drain` CLI path, so they landed in `byProcessEngineModel` as unattributed (5 calls, 24s per run) instead of under a `triage` stage. The pre-pass drain is now wrapped in `withLlmStage("triage", …, { engine, process: "triage.judgment" })`, mirroring the CLI path.
+- **The batch graph-extraction provider-storm guard only recognized one error
+  code.** After a failed batch call, `extractGraphFromBodies` skipped the
+  per-asset fallback retry only for `LlmCallError`s coded `provider_error` —
+  but a dead endpoint more often raises `network_error` (a dropped
+  connection) or `provider_html_error` (a provider serving an HTML error
+  page), both of which still paid the full per-asset fallback storm the
+  guard exists to prevent. The predicate is now `isTransportFailure`
+  (`src/llm/client.ts`), shared with `chatCompletion`'s retry classifier so
+  the two cannot drift apart, and covers `provider_error`, `network_error`,
+  and `provider_html_error`.
+- **`akm health`'s `state-db-integrity` check no longer crashes when the freelist/page-count read fails.** `getStateDbFreelistInfo` had a `finally` but no `catch` around its read-only open and pragma reads, unlike its sibling `runStateDbQuickCheck` — a throw there (e.g. an unopenable state.db) escaped `akm health` as an unclassified exit 70 on exactly the damaged database the check exists to report. It now returns a zeroed `StateDbFreelistInfo` with an `error` field, and the check renders that as a failed check instead of throwing.
+- **The post-purge VACUUM's `state_db_vacuumed` event now honors the caller's `EventsContext`.** `vacuumStateDbIfReclaimable` appended its event with a direct `insertEvent` call, bypassing `EventsContext.readOnly` and the injectable clock its sibling purge events (`events_purged`, `improve_runs_purged`, `improve_cycle_metrics_purged`) use in the same `runRetentionPurgePass` callback. It now appends the event via `appendEvent` with the caller's `EventsContext` plumbed through.
+- **Consolidate's per-chunk prompt excerpt truncated the raw file (frontmatter
+  + body) instead of the body.** `buildChunkPrompt` sliced `body.slice(0,
+  bodyTruncation)` off the unstripped file; a memory whose frontmatter alone
+  exceeded the excerpt length was judged on metadata only and never showed
+  its own body text. The excerpt now truncates `stripFrontmatterBody(body)`;
+  hot/queued detection is unchanged and still reads the raw body.
+- **Consolidate's chunk prompt carried an unused ~14k-char standards block and
+  a header the model sometimes echoed back as a bogus `ref`.** Every chunk
+  prompt resolved and injected a "Standards to follow" section
+  (`resolveStandardsContext("memories/_consolidated", ...)`), but the chunk
+  output is a promote-only op list that never reads it. Separately, the
+  chunk header (`Chunk N of M, memories <first>–<last>:`) named the chunk's
+  boundary memories with an en dash between two `memories/<name>` refs; on
+  2026-09-24 the judge model returned promote ops whose `ref` was exactly
+  that `memories/<first>–memories/<last>` range, naming a memory that does
+  not exist and losing the promotion. `buildChunkPrompt` no longer takes a
+  `standardsContext` and the header is now
+  `Chunk N of M (<count> memories):` — no refs in it.
+- **Consolidate re-judged memories that were already promoted verbatim into
+  `knowledge/`.** That duplication was previously discovered only after the
+  LLM (`shouldSkipPromotionBodyDuplicate`), so a pool where the large
+  majority of memories were already-promoted duplicates still paid the full
+  chunk/LLM cost on all of them before being skipped.
+  `inspectConsolidationPool` now drops those memories before any chunking or
+  LLM work, sharing one `loadExistingKnowledgeBodyHashes` call and the same
+  `cacheHash` domain with the post-LLM check so the two cannot disagree. The
+  dropped count is reported as `prefilteredAlreadyPromoted` on the
+  consolidate result and in a warning line. The pre-filter also now runs
+  *before* the `consolidate.limit` cap (previously after), so a run with a
+  limit set selects its oldest-modified window from the pre-filtered pool
+  instead of re-selecting and re-dropping the same permanently-undeletable
+  duplicates every run while fresh memories past the cap went unreached; the
+  preview/eligibility path (`preparation.ts`) computes and passes the same
+  hash set so the reported candidate pool agrees with what the run will act
+  on. A live (non-preview) `akm improve` run reuses that same hash set for
+  the actual `akmConsolidate` call instead of recomputing it, so a run still
+  walks `knowledge/` only once.
+- **`improve`'s start-of-run index rescan ran after triage dirtied the stash,
+  not before it.** Proposal triage promotes accepted proposals straight into
+  the flat `knowledge/` root, and the blocking `ensureIndex` call that is
+  supposed to give the run a current index ran only afterward (inside
+  `collectEligibleRefs`'s setup), so every triage promotion guaranteed the
+  very full rescan it should have preceded — up to ~27 minutes, holding the
+  index lock against co-scheduled writers. `ensureIndex` now runs before the
+  triage pre-pass, and triage's own writes are indexed incrementally
+  (`indexWrittenAssets`) so `collectEligibleRefs` still sees them without a
+  second full walk. Because `indexWrittenAssets` upserts a file's
+  `content_hash` without bumping `builtAt`, index staleness detection
+  (`ensure-index.ts`) is now per-file: a file newer than the last build is
+  only treated as stale when its current content actually differs from what
+  is indexed, so incrementally-reindexed content stops re-triggering the
+  same full rescan on every subsequent run. The implicit reindex's timing
+  breakdown (walk/llm/embed/finalize), previously discarded, is now logged
+  at verbose level and surfaced on the improve result as `ensureIndexDurationMs`.
+- **Distill quality rejections vanished instead of persisting, so backoff and
+  Reflexion never saw them and the same ref was re-selected and re-rejected
+  on every run** (two refs were rejected 11× and 10×). `writeQualityRejection`
+  wrote only a `$STATE`-side file and an event, never a `proposals` row, so
+  `rejection_backoff`/`fingerprint_match` (proposal/repository.ts) and the
+  Reflexion "previously rejected" context had nothing to find; the distill
+  signal-delta cursor (`buildLatestProposalTsMap`) also only advanced for
+  `queued`/`skipped`/`validation_failed` outcomes, so a rejected ref stayed
+  eligible forever. `writeQualityRejection` now mints a real proposal through
+  the same `createProposal`/`archiveProposal` path every other proposal
+  source uses: a `quality_rejected` outcome is minted pending then archived
+  to `rejected` carrying the judge's reason; a `review_needed` outcome stays
+  `pending` in the normal queue, where triage — a human, or the drain's
+  judgment tier when one is configured — decides, the same path every other
+  pending distill proposal (including quality-gate passes) already takes.
+  The cursor now also advances on both outcomes (still excluding
+  `llm_failed`, where no real attempt produced anything). A retry for the
+  same target, source, and model is skipped by `fingerprint_match` (the
+  input fingerprint recorded at mint, retained `archiveRetentionDays`,
+  default 90 days); the 30-day `rejection_backoff` window only applies once
+  the target's before-hash or the model differs. Because these machine
+  rejections are now real `rejected` rows under `source: "distill"`, `akm
+  health`'s distill accept rate (`computeAcceptRateBySource`,
+  src/commands/health/accept-rate.ts) drops relative to earlier releases and
+  no longer measures reviewer acceptance alone. Nothing gates on that
+  metric.
+- **`writeQualityRejection` could throw instead of returning a rejection
+  result.** Minting the proposal row above runs the mint-time canonical
+  validator (`createProposal` → `rejectProposal`,
+  `src/commands/proposal/repository.ts`), which throws `UsageError` for
+  structurally-invalid content — e.g. a `lessons/` ref whose body lacks
+  `description`/`when_to_use`. `writeQualityRejection` is the terminal,
+  non-throwing rejection path and none of its callers handled a throw. The
+  proposal row is bookkeeping for backoff/Reflexion, never the authoritative
+  record of the rejection, so a validator throw now degrades to "no row
+  minted" — the envelope file and `distill_invoked` event are still written,
+  matching the existing fingerprint/backoff skip behavior.
+- **A `review_needed` quality-gate rejection could be auto-promoted by the
+  triage drain's judgment tier with no human ever seeing it.**
+  `writeQualityRejection` minted a `review_needed` outcome as an ordinary
+  pending proposal under `source: "distill"` (knowledge promotions from
+  `promote-memory.ts` take the same path); the `personal-stash` drain policy
+  defers `distill` proposals to the judgment tier, which can auto-accept
+  under `applyMode: promote` + `experimental.improveAutonomy` — so content
+  the quality judge explicitly refused to auto-queue (the 2.5–3.5
+  review-needed band) could be promoted without a human in the loop.
+  `writeQualityRejection` now stamps a `review_needed` mint with a
+  `{ outcome: "deferred", reason: "quality-review", gate: "quality-gate" }`
+  gate decision (best-effort: a stamp failure warns and continues, like the
+  existing mint/archive tolerance), and `classifyPendingProposals`
+  (`proposal/drain.ts`) skips any pending row carrying it — leaving it
+  pending and untouched, before the drain's own policy-deferred re-stamp
+  loop would otherwise overwrite the stamp.
+- **Consolidate's post-LLM promote-dedup hash double-stripped frontmatter.**
+  `shouldSkipPromotionBodyDuplicate`'s `bodyHash` was computed as
+  `cacheHash(parseFrontmatter(memoryContent).content.trim())` — the body was
+  already frontmatter-stripped before being handed to `cacheHash`, which
+  strips it again internally — diverging from the single-strip
+  `cacheHash(raw)` domain `loadExistingKnowledgeBodyHashes` and the pre-filter
+  use for a source memory body that begins with its own `---` block. The
+  check now hashes `cacheHash(memoryContent)` directly, so the two sides of
+  the dedup comparison agree.
+- **Consolidate's per-chunk prompt still warned against proposing `delete`
+  for `(captureMode: hot)` memories.** The consolidate op schema and system
+  prompt dropped `delete` (along with `merge`/`contradict`), leaving
+  `buildChunkPrompt`'s top-of-prompt hot-ref block as the only remaining
+  mention of `delete` anywhere in the prompt — a retired op name that
+  `isValidOp` now rejects if the model echoes it back, wasting tokens on
+  "skipping invalid operation" warnings. The block and the `hotRefs`
+  collection that fed it are removed; the inline `(captureMode: hot)`
+  annotation on each memory line is unchanged.
+- **Graph extraction sent no `json_schema` and no per-asset chunk cap, so a
+  long file could pay for dozens of LLM calls whose output was then sliced
+  down to the same 32-entity/32-relation limit anyway** (one file spent 21 of
+  27 calls and 12.9k completion tokens this way). The single-asset extraction
+  call (`extractGraphFromBody`) now sends a `responseSchema` (entities/
+  relations capped at 32 each, `additionalProperties: false` otherwise), via
+  the same `supportsJsonSchema`-gated request path memory-infer.ts uses — no
+  `maxTokens` is sent; cost is bounded by the schema's `maxItems` caps alone,
+  per AGENTS.md's "LLM Defaults" (a hardcoded cap risked silent truncation
+  with zero headroom for JSON punctuation or reasoning tokens). A body
+  chunked beyond the new
+  `processes.graphExtraction.maxChunksPerAsset` (default 8) now stops after
+  the first N chunks instead of processing every one; the skipped chunks are
+  reported as `truncatedChunks` in the run's graph-extraction telemetry so
+  the coverage loss is visible rather than silently absorbed. The `improve`
+  loop's dispatch (`loop-stages.ts`) now also forwards a configured
+  `maxChunksPerAsset` to the extraction call, mirroring the existing
+  `topN`/`batchSize` wiring — without this the config key had no effect in a
+  real `akm improve` run and the default of 8 always applied.
+- **The graph-extraction `responseSchema` forbade the `confidence` field the
+  parser itself reads.** `additionalProperties: false` on both the root
+  object and each relation item made `confidence` impossible on a
+  `supportsJsonSchema` provider, even though `parseGraphExtraction` uses
+  `rel.confidence` to drop relations below `MIN_RELATION_CONFIDENCE` and
+  `item.confidence` to feed the merged extraction confidence — silently
+  turning the confidence filter into dead code on exactly the providers the
+  schema targets. `confidence: {"type": "number"}` is now allowed at both
+  levels; `additionalProperties: false` still forbids anything else.
+- **A pending proposal went stale the moment akm's own bookkeeping touched
+  its target, and promote refused it forever (R20).** `resolveProposalTargetInfo`
+  captured the target's raw `beforeHash` at mint; the SAME nightly run's
+  `writeSalienceToFrontmatter` (distill) and memory inference's
+  `inferenceProcessed` stamp then rewrote the target's frontmatter before
+  promote ran, so `promoteProposalWithLease`'s guard (`repository.ts` ~L2406)
+  and `drain.ts`'s dry-run mirror (`assertProposalTargetFresh`) refused every
+  affected proposal with "target changed after proposal was created" — the
+  same 11+ reflect proposals, every day, on splinter. `resolveProposalTargetInfo`
+  now also captures `beforeHashNormalized` (`core/asset/frontmatter.ts`'s new
+  `computeNormalizedContentHash`, over the target with
+  `BOOKKEEPING_FRONTMATTER_KEYS` — `salience`/`salienceInputs`/`inferenceProcessed`
+  — stripped and the remaining frontmatter canonically re-serialized); the
+  promote guard and its dry-run mirror both prefer it over the raw
+  `beforeHash` when present, so a bookkeeping-only rewrite no longer stales a
+  proposal out while a real content change still refuses. Promotion also now
+  carries the live target's bookkeeping keys forward
+  (`carryForwardBookkeepingFrontmatter`) when the proposal's own frontmatter
+  doesn't set them, so accepting never drops `inferenceProcessed` and forces
+  memory inference to reprocess the memory. A legacy proposal minted before
+  this field existed keeps its exact original raw-hash check.
+  `computeNormalizedContentHash` also normalizes the body boundary the same
+  way `assembleAssetFromString` does (leading newlines stripped, exactly one
+  trailing newline) before hashing, and treats an empty frontmatter block as
+  `{}` instead of falling back to the raw hash — both `writeSalienceToFrontmatter`
+  and the memory-inference `assembleAsset` rewrite shift where the body starts,
+  which without this normalization still staled a proposal out unless the
+  target's frontmatter was already in that exact on-disk shape.
+- **A stale-target promote failure was retried, and refused, identically
+  every drain run forever (R20).** The drain already categorized a
+  "target changed/was created after proposal" failure as `stale-target`
+  (`categorizeDrainFailure`), but left the row pending either way — so the
+  same proposals failed the same way on every subsequent `akm proposal
+  drain` / triage pass. Both promote-failure sites (`drainProposals`'s
+  deterministic loop and `runJudgmentTier`) now auto-reject a stale-target
+  failure once, stamping `gateDecision: { outcome: "auto-rejected", reason:
+  "stale-target" }` instead of leaving it to retry. This is not a merit
+  rejection, so `checkFingerprintAndBackoff`'s rejection-backoff window
+  (`repository.ts`) now excludes stale-target rows — the ref stays
+  re-proposable against its current content — and the Reflexion
+  "previously rejected" context (`reflect.ts`'s `readRejectedProposals`,
+  `distill.ts`'s `buildDistillMessages`) and the accept-rate health metric
+  (`health/accept-rate.ts`) now exclude stale-target rejections too, so a
+  procedural refusal doesn't misrepresent content quality. `--dry-run` now
+  predicts the same outcome: a stale-target promote failure it detects is
+  reported under `rejected`, matching what a real run does, instead of under
+  `failed`.
+
+- **Reflect quality-gate rejections were mislabelled `parse_error` and fed
+  back into later prompts as learned "avoid" patterns.** When the reflect
+  quality judge rejected an otherwise well-parsed proposal, the result
+  carried `reason: "parse_error"` — a real parse failure and a judge
+  rejection were indistinguishable. The improve loop injects non-excluded
+  reflect failures into the next reflect prompt's "Avoid These Patterns"
+  block, so a single gate rejection could poison every subsequent candidate
+  in the run. Judge rejections now carry a distinct `quality_rejected`
+  reason, stay in the `reflect-failed` metrics bucket, and are excluded from
+  that avoid-patterns injection like the existing deterministic skips.
+- **Legacy rejected proposals no longer throw before reflect/distill prompt
+  dispatch.** `readRejectedProposals` (reflect.ts) and the equivalent mapper
+  in distill.ts built their "previously rejected" context via
+  `proposalContent(p)`, which throws when a proposal's `changes[0]?.after` is
+  undefined — the shape `storedToChanges` deliberately returns for rows
+  archived before the `changes` field existed (the large majority of
+  real-world rejected-proposal history). The throw happened before the
+  signal cursor advanced, so a ref with any such legacy rejection errored on
+  every run instead of ever completing. Both call sites now read the preview
+  from `payload.content`, which is populated for every row regardless of
+  its `changes` shape.
+- **Failed graph extractions are no longer cached as permanent hits.** A
+  provider outage upserted thousands of `{"entities":[],"status":"failed"}`
+  results into `llm_enrichment_cache` and the persisted graph, and both
+  cache-hit paths (the DB lookup and reuse from the previous graph) treated
+  them as valid hits forever after — the affected files never retried.
+  `status: "failed"` results are now treated as a miss and are never written
+  to the cache; existing rows are left on disk and are overwritten naturally
+  on the next successful extraction. `src/llm/graph-extract.ts` also no
+  longer falls back to a per-asset retry for every body in a batch after a
+  `provider_error` — the provider has already demonstrated it is failing, so
+  each asset in that batch is recorded as failed directly. Graph extraction
+  now aborts the rest of the run (returning the partial results already
+  extracted) once the failure rate crosses 50% over at least 4 attempted
+  extraction dispatches, mirroring consolidate's existing failure-rate guard.
+  The abort counts one attempt per `extractGraphFromBodies` dispatch, not per
+  file inside its batch — per-file counting let a single batched
+  `provider_error` trip the guard after one HTTP failure whenever
+  `graphExtractionBatchSize` was at its default of 4.
+- **Memory consolidation's cooldown could never engage.** `consolidate_completed`
+  was only emitted when a run planned zero merge/delete/contradict operations —
+  advisory ops the model plans daily and that are never auto-applied — so the
+  event had, in practice, never fired and the pool-delta gate stayed
+  permanently in its bootstrap "run every time" state. The event now fires
+  whenever the LLM pass itself completes, recording the unapplied advisory op
+  count (`advisoryOpsUnapplied`) instead of withholding the event. Separately,
+  the memory-volume override (`memoryVolumeConsolidationThreshold`, forcing a
+  run when the eligible pool exceeds the threshold) is now bootstrap-only: once
+  a `consolidate_completed` event exists for the source, the pool-delta gate
+  governs on its own, even when the pool is large. `akm improve --plan`'s
+  `consolidation.gates.delta.reason` no longer reports "memory pool has work"
+  for both a real pool delta and the bootstrap case (no `consolidate_completed`
+  event yet, so no delta was evaluated) — bootstrap now reports its own reason.
+
 ## [0.9.16] - 2026-09-22
 
 ### Fixed

package/dist/assets/prompts/consolidate-system.md

@@ -1,21 +1,14 @@
 You are the akm consolidate assistant analyzing memory assets.
 
 Rules:
-1. MERGE: Two or more memories are substantially duplicated or closely related → propose merging. Return the primary ref to keep and secondary refs to delete. Do NOT include mergedContent — the merge will be executed in a separate step.
-2. DELETE: Memory is clearly outdated, contradicted, or redundant → propose deletion. NEVER propose delete for memories annotated `(captureMode: hot)` — they are user-explicit and only the user can retire them. The downstream guard will refuse these regardless, so proposing them just wastes tokens.
-3. PROMOTE: Memory expresses a stable, reusable fact suitable as a `knowledge/` asset → propose promotion. Do NOT delete the source memory. NEVER propose promote / merge / contradict for memories annotated `(already queued)` — they have a pending proposal whose body matches; a duplicate will be deterministically dropped, so proposing them just wastes tokens.
-4. CONTRADICT: Two memories assert logically exclusive facts such that following BOTH simultaneously is impossible — not merely related or overlapping. You MUST cite the exact sentence from Memory A and the exact sentence from Memory B that are in direct conflict. If you cannot cite specific opposing sentences, use KEEP instead. Sharing a topic, tool, domain, or workflow stage is NOT sufficient. Only direct factual opposites qualify: opposing recommended commands, opposing boolean flags, opposing version numbers, or mutually exclusive instructions. Use confidence ≥ 0.92 only; omit the op entirely if below that threshold.
-5. KEEP: Memory is unique and current → omit from output.
+1. PROMOTE: Memory expresses a stable, reusable fact suitable as a `knowledge/` asset → propose promotion. Do NOT delete the source memory. NEVER propose promote for memories annotated `(already queued)` — they have a pending proposal whose body matches; a duplicate will be deterministically dropped, so proposing them just wastes tokens.
+2. KEEP: Memory is unique and current → omit from output.
 
 Return ONLY JSON (no prose, no code fences):
 {
   "operations": [
-    { "op": "merge", "primary": "memories/<name>", "secondaries": ["memories/<name>", ...], "mergeStrategy": "synthesize", "confidence": 0.95 },
-    { "op": "delete", "ref": "memories/<name>", "reason": "<brief reason>", "confidence": 0.90 },
-    { "op": "promote", "ref": "memories/<name>", "knowledgeRef": "knowledge/<suggested-slug>", "reason": "<brief reason>", "description": "<one sentence describing the new knowledge asset>", "confidence": 0.92 },
-    { "op": "contradict", "ref": "memories/<name>", "contradictedByRef": "memories/<name>", "reason": "<brief reason>", "confidence": 0.88 }
-  ],
-  "warnings": ["<optional concerns>"]
+    { "op": "promote", "ref": "memories/<name>", "knowledgeRef": "knowledge/<suggested-slug>", "reason": "<brief reason>", "description": "<one sentence describing the new knowledge asset>", "confidence": 0.92 }
+  ]
 }
 
 For every operation, emit a `confidence` field in [0, 1] expressing your certainty that the operation is correct and safe. Use 0.95+ only when evidence is unambiguous. Omit the field rather than guessing if you are uncertain.

package/dist/assets/prompts/graph-extract-user-prompt.md

@@ -1,10 +1,10 @@
 Extract entities and relations from the asset body below.
 
 Rules:
-- Output ONLY a JSON object: {"entities": ["Entity One", ...], "relations": [{"from": "A", "to": "B", "type": "uses"}, ...]}.
+- Output ONLY a JSON object: {"entities": ["Entity One", ...], "relations": [["A", "uses", "B"], ...]}.
 - Entities are short, canonical noun phrases (project names, services, tools, people, technical concepts). Do NOT emit file or directory paths (anything containing "/" or "\") — they are dropped downstream.
-- Relations connect two entities that both appear in the entities array.
-- "type" is a short verb phrase (e.g. "uses", "depends on", "owns", "documents"). Optional; omit when unsure.
+- Each relation is a 3-element array: [from, type, to]. Relations connect two entities that both appear in the entities array.
+- "type" is a short verb phrase (e.g. "uses", "depends on", "owns", "documents"). Use "" when unsure.
 - Drop pleasantries, meta-commentary, and timestamps.
 - Limit to at most {{MAX_ENTITIES}} entities and {{MAX_RELATIONS}} relations per asset.
 - Return {"entities": [], "relations": []} if the body has no extractable graph content.
@@ -19,7 +19,7 @@ for rate limiting. The terraform-provisioner deploys everything to the prod clus
 Owner: @alice.
 
 Output:
-{"entities":["auth-service","PostgreSQL","redis-cache","terraform-provisioner","prod cluster","@alice"],"relations":[{"from":"auth-service","to":"PostgreSQL","type":"uses"},{"from":"auth-service","to":"redis-cache","type":"depends on"},{"from":"terraform-provisioner","to":"prod cluster","type":"deploys"},{"from":"terraform-provisioner","to":"auth-service","type":"deploys"},{"from":"@alice","to":"auth-service","type":"owns"}]}
+{"entities":["auth-service","PostgreSQL","redis-cache","terraform-provisioner","prod cluster","@alice"],"relations":[["auth-service","uses","PostgreSQL"],["auth-service","depends on","redis-cache"],["terraform-provisioner","deploys","prod cluster"],["terraform-provisioner","deploys","auth-service"],["@alice","owns","auth-service"]]}
 
 Input:
 ## Meeting: API Redesign
@@ -27,7 +27,7 @@ Discussed moving from REST to GraphQL. The frontend team will use Apollo Client.
 Backend needs to implement resolvers. Timeline: Q2.
 
 Output:
-{"entities":["REST","GraphQL","Apollo Client","frontend team","backend","resolvers","Q2"],"relations":[{"from":"frontend team","to":"Apollo Client","type":"uses"},{"from":"backend","to":"resolvers","type":"implements"},{"from":"frontend team","to":"GraphQL","type":"migrates to"}]}
+{"entities":["REST","GraphQL","Apollo Client","frontend team","backend","resolvers","Q2"],"relations":[["frontend team","uses","Apollo Client"],["backend","implements","resolvers"],["frontend team","migrates to","GraphQL"]]}
 
 ===============
 

package/dist/commands/health/accept-rate.js

@@ -15,6 +15,7 @@
  * same read extended to the accepted/rejected archive.
  */
 import { resolveStashDir } from "../../core/common.js";
+import { isStaleTargetRejection } from "../proposal/proposal-types.js";
 import { listProposals } from "../proposal/repository.js";
 /**
  * Compute accept-rate-per-source metrics from the proposal store. Defaults to
@@ -28,6 +29,11 @@ export function computeAcceptRateBySource(stashDir) {
         for (const status of statuses) {
             const proposals = listProposals(stash, { status, includeArchive });
             for (const p of proposals) {
+                // A stale-target auto-reject (STALE, R20) is procedural, not a
+                // judgement on the content — counting it would understate the
+                // source's real accept rate for content the drain will re-propose.
+                if (status === "rejected" && isStaleTargetRejection(p))
+                    continue;
                 const src = p.source || "(unknown)";
                 const entry = bySource.get(src) ?? { accepted: 0, rejected: 0, pending: 0 };
                 if (status === "accepted")