@try-works/dsh-memory 0.1.26 → 0.1.27

package/STATUS.md

@@ -3,7 +3,8 @@
 A tracker and planner: what exists, what is verified working, what is written but not
 loaded, and what is left. Kept as a record of MEASURED state, not intention.
 
-**Last measured: 2026-10-06** (347 tests passing, 41 src files, 50 test files).
+**Last measured: 2026-10-12** (408 tests passing; plugin at 0.1.26, published and installed
+byte-identical to source; store committed and pushed to `origin`).
 
 ## How to read this
 
@@ -64,6 +65,8 @@ Observed in the running host. Each row names the effect that was seen, not a cla
 | `memory/map` events carry `ignorable: true` | the live session log's own event is marked, and both dsh-memory logs pass the harness's `validateStoredEvents` — the exact check that refused session-cc4795a7 with "unknown to this harness and not marked ignorable" |
 | 0.1.21 guard is LOADED | the 2026-10-11 06:01+08 restart booted the installed 0.1.21; `map-publish ok:true` events follow boot, so the guarded publisher runs. The suppression branch itself cannot be observed on this harness — it only fires on one that does not stamp the marker |
 | Boot tasks backup + restore ran live | at boot (2026-10-10T22:03:14Z) the log records `tasks-backup ok:true written:0 refreshed:5` and `tasks-restore ok:true owner:session-6e8d9a10 present:5 added:0 paused:0` — the restore reached the schedule service, found everything present, and duplicated nothing |
+| Git sync works live | after the 0.1.22+ boot the log shows real `sync` events, `state/sync.json` records `ok:true remote:https://github.com/try-works/dsh-memory-store` (2026-10-11T10:34:54Z), and `git log` in the store holds `memory(store): update [dsh-memory]` commits — the first syncs this plugin has ever performed |
+| History ingest works live | `history-check ok=true` entries after the boot, including `count=1` at 09:37Z — a commit was actually ingested; the hourly `null.run` error era is over |
 
 ## WRITTEN but NOT LOADED
 
@@ -76,6 +79,8 @@ Implemented and tested on disk. The running host predates them, so none of this
 | `memory_recover` report omits its `entries` field rather than blanking it | the old line added `entries: undefined`, which is NOT valid JSON, so the harness rejected the whole result | the new guard round-trips every tool output; reintroducing it fails with `value.entries is undefined` |
 | Publisher stops when the harness does not stamp `ignorable` (0.1.21) | ≤0.1.19 appended `memory/map` WITHOUT the marker into ten real session logs, so every later load of those sessions failed ("unknown to this harness and not marked ignorable"). The guard checks the RETURN VALUE of `session.append` and suppresses publishing for that session at the first refusal, instead of poisoning the log | 403 tests pass; the new test drives a harness-shaped stub that returns an unstamped event and asserts the next turn appends nothing, even with a changed store and a passed throttle |
 | Git runner resolves the subprocess service lazily (0.1.22) | `makeGitRunner` probed `ctx.get('subprocess')` ONCE at wire time; cordis `get()` only returns services whose providing fiber is ACTIVE (vendor/cordis reflect.ts), so during mount it returns undefined, git stayed null forever, and every git path was dead: zero sync events ever recorded, and `history-check` threw `Cannot read properties of null (reading 'run')` hourly since 2026-10-06. The runner now re-probes at use and reports an honest reason while absent | 405 tests pass; the new test pins no-probe-at-mount, an honest refusal while the service is absent, and working ingest after it appears |
+| `classifyGitResult` reads `exitCode`, the name the runner actually returns (0.1.23-0.1.25) | the doc promised `code` and the code read `code`, but the injected runner returns `exitCode` — every successful git command was classified as a failure, so pull/push always reported failed and sync "had never once succeeded". `memory_sync` also stopped counting local commits as `synced: true` | sync tests drive the runner through the real classifier; an empty remote is asserted as the first push, not a failed pull |
+| `memory_recover` run path gets real services (0.1.26) | `recoverNow.run` called `recoverOne(store, services, ...)` where `services` was NEVER DEFINED — a ReferenceError the catch quietly turned into "1 declined or refused", so 75 recoverable candidates sat behind a tool that could only refuse them (observed live: limit:1 rebuilt 0). Services are now resolved at call time (`sessionQuery`), and the summary uses the plugin's own memory-model ladder | 408 tests pass; the new test executes the REAL run path through the wiring: plan → requeue → readSession → capture → digest file written, queue leaves ORPHANED |
 
 How to tell loaded from not: ask the host. `memory_recover` used to reply *"unavailable in this
 context"* and now replies *"returned invalid output: value is not lossless JSON"*. The change of
@@ -121,15 +126,31 @@ reporting success.
 Known limitation, by design: the host deletes a task when its owning session stops, so a restored
 task lives as long as the session that adopted it. The boot restore is what re-arms them.
 
-## NOT VERIFIED — treat these as unknown
+## OUT OF SCOPE — not dsh-memory's problem
 
-| item | what is actually known | what would settle it |
-|---|---|---|
-| Session CONTENT search | The index database exists at `~/.dsh/storages/session-search.sqlite` and was opened, so `openAt: first-search` took effect. It holds **0 sessions, 0 documents, `global_generation` 0**. Every sidebar result therefore comes from a browser-side TITLE match. | A **content-only** hit: a query matching text inside a session that appears in no title or workspace name. |
-| Cause of the empty index | Reconciliation runs `_observeStable -> persistence.list -> readColdSessionLog` and indexes nothing. Candidates, untraced: persistence binding unavailable, cold reads failing silently, live sessions skipped. | Tracing the reconcile path with a real store. |
-| Sidebar behaviour with a populated index | The service uses FTS5 MATCH and the client merges content hits with local title matches. The merge code is real; it has never had content to merge. | The same content-only hit above. |
+Closed 2026-10-12 by operator decision. Recorded once so it is not re-investigated.
+
+The sidebar's full-text session search does not work on this machine, and **that is not
+dsh-memory's concern**. The session logs under `~/.dsh/sessions/` are DSH's own files: they are
+written by `session-persistence-jsonl`, they exist whether or not this plugin is installed, and
+they are not memory data. This store holds no session logs at all.
+
+What was found while investigating (kept only so nobody repeats the work): 91 of 630 stored logs
+are legacy v0 artifacts DSH cannot read (`subagent/descriptor ... unsupported descriptor version
+2`); one such log aborts the whole corpus reconcile, so the search index stays empty and the
+sidebar falls back to matching titles. Verified by isolation — two valid v4 logs return content
+hits, and adding one bad v0 log fails the same query.
 
-### Where the sidebar search actually comes from
+Why this is not a dsh-memory bug: the plugin **never calls session search**. It reads individual
+sessions directly through `sessionQuery.readSession` in `capture.js` and `recover.js`. The only
+link is one config line — this plugin's patch layer sets `openAt: first-search` on the
+`session-query-sqlite` row, which is what turns the harness's opt-in search on. Nothing in the
+plugin's code is involved.
+
+Per instruction: do not modify the harness, do not touch the session logs, do not work around
+this from the plugin. Sidebar search stays title-only; dsh-memory is unaffected.
+
+### Where the sidebar search comes from
 
 Recorded because it was got wrong once. `client/ui-workspace/src/client/tree.ts`
 `deriveSearchResults` has two sources:
@@ -139,22 +160,21 @@ Recorded because it was got wrong once. `client/ui-workspace/src/client/tree.ts`
 sessionTitle(summary).toLowerCase().includes(q)
   || labelOf(summary).toLowerCase().includes(q)
 
-// CONTENT - server-side FTS hits, empty today
+// CONTENT - server-side FTS hits, empty because the index cannot fill
 for (const item of content.items) include(summary)
 ```
 
-So title search works and content search is wired but starved. The distinction matters: turning
-the flag on did not change what the user sees.
-
 ## TODO — ordered
 
 ### Blocked on a restart
 
-- [ ] **Restart to load 0.1.22.** The lazy git-runner fix is published; install is pending the
-      registry finishing its staged publish (E409 "previously staged version" on retry). Once the
-      profile install lands and the host restarts, the hourly `history-check ok:false null.run`
-      should become either a working ingest or an honest `reason` — and git sync gets its first
-      real chance to run ever.
+- [x] **Restart to load 0.1.26 — DONE 2026-10-12 05:18+08.** After the boot, `memory_recover({limit:1})`
+      rebuilt one candidate (log: `recover count:1 detail.id 9521e4c9...`), and the rebuilt digest
+      was committed by the sync cadence right after. The recover run path is live.
+- [x] **Restart to load 0.1.22 — DONE 2026-10-11.** The lazy git-runner fix is live: real `sync`
+      events in the log, `state/sync.json` ok:true against the configured remote, `memory(store)`
+      commits in the store's git history, and `history-check ok=true` entries including an ingested
+      commit. The hourly `null.run` era is over.
 - [x] **Restart to load 0.1.21 — DONE 2026-10-11 06:01+08.** The host booted the installed 0.1.21;
       `map-publish ok:true` events follow boot and the boot tasks backup/restore ran live (see
       LIVE table).
@@ -173,23 +193,33 @@ the flag on did not change what the user sees.
 
 - [x] `memory_recover({})` — DONE 2026-10-11: report-only call returned a clean report (75
       recoverable, 0 oversized), no error.
-- [ ] `memory_recover({ limit: 1 })` — **prove it end to end on one** before spending on 76.
-- [ ] Then the rest in batches of ~10. Cost is roughly 76-150 model calls plus consolidation,
-      against **52 MB** of logs. All 76 are under the 8 MB approval threshold, so nothing will
-      stop an accidental `limit: 76` — the one-candidate proof is the guard, not the threshold.
+- [x] `memory_recover({ limit: 1 })` — DONE 2026-10-12: rebuilt 1, declined 0 (the 0.1.26 run
+      path). Attempted earlier on 0.1.25 it rebuilt 0 and declined 1 — the live proof that the
+      undefined-`services` ReferenceError was real.
+- [x] The rest in batches of ~10 — DONE 2026-10-12: all 75 candidates recovered (1 proof + 10/10
+      batches through the queue, `logs/memory.log` shows `recover` count=75), 0 remain. Each
+      rebuild was followed by a sync commit; `state/sync.json` stayed ok:true. Recovered digests
+      now flow into the normal consolidation cadence.
 ### Open work, not blocked
 
-- [ ] **Held backfills: 28.** `state/backfill-hold.json`. Released one as a gate test and it
-      produced 2 entries against a 1-3 target, where the live rate was 7-10 — so the conservative
-      bar works. Release in batches and watch the rate after each; ~7 per digest means the bar is
-      not reaching the prompt and the batch should stop.
-- [ ] **79 held records, reason `unclassified`.** Legacy records whose summary was empty and
-      whose cause was never recorded, so a conclusion and a defect are indistinguishable. Parked
-      deliberately: retrying them unasked would be a backfill nobody requested. An operator
-      decision, not a bug.
-- [ ] **Session content search.** See NOT VERIFIED. Two routes: trace why reconciliation indexes
-      nothing, or accept title search and close it. Do not claim it works until a content-only
-      hit is observed.
+- [x] **The held backlog — CLEARED 2026-10-12.** Both figures quoted here for weeks were WRONG,
+  which is why this sat untouched: the real store had **one** record marked `unclassified` (not
+  79 — the append-only journal is the authority, and it contained exactly one), and
+  `state/backfill-hold.json` is read by **no production code at all** (an orphaned artefact of the
+  retired `sessions.json` migration; 27 of its 28 ids are not even in the queue). The genuine
+  backlog was 80 pending digests, consolidated in batches into **~215 entries**. Two real defects
+  were found while doing it:
+  - **Header-only digests were sent to the model.** `runConsolidation` batched
+    `withContent.concat(headerOnly)`, so a digest with no summary section went to the LLM as a bare
+    header. The reply could only be "nothing durable", which never advanced the entry, so the same
+    empty shells were re-sent every cadence — one entry reached `consolidateAttempts: 39`. Fixed:
+    consolidation now filters to digests that actually contain a summary section (capture writes
+    summaries; consolidation only reads them), with a test asserting the model is never called.
+  - **A stuck `pending` candidate had no operator path.** Recovery accepts orphaned/abandoned/failed
+    but not pending, and capture never re-summarizes a historical session. One genuine main-agent
+    session (1317 events) was recovered by marking it orphaned, then `memory_recover`.
+    The other 8 stragglers were `origin: subagent` sessions — never memory material by
+    `isSubagentSession` — and were skipped with a truthful reason.
 - [ ] **Agent-facing session tools** (`session_search` and friends). NOT a config change. In a
       Web profile the tool plane belongs to a preset, and a patch REPLACES a preset row config
       wholesale — so adding one tool means restating the whole ~20-row `config.plugins` list and
@@ -217,10 +247,11 @@ Kept because the pattern matters more than the list: every one of these was foun
 | A test edit silently discarded | my own script re-read and overwrote the file before writing |
 ## Published
 
-**`@try-works/dsh-memory@0.1.16`** on npm (0.1.0 was the first release; the Memory tab and the
-tasks layer each added several). The unscoped name `dsh-memory` was already taken by an
-unrelated DeepSeek Harness memory plugin, so the package publishes under the existing `@try-works`
-scope.
+**`@try-works/dsh-memory@0.1.26`** on npm, installed in the profile byte-identical to source.
+(0.1.0 was the first release; the Memory tab, the tasks layer, the ignorable/log-poisoning fix, the
+git-sync fixes and the recovery run-path fix each added versions in between.) The unscoped name
+`dsh-memory` was already taken by an unrelated DeepSeek Harness memory plugin, so the package
+publishes under the existing `@try-works` scope.
 
 What did NOT change, deliberately: the Cordis plugin name (`export const name = 'dsh-memory'`) and
 the bundle row id (`id: dsh-memory`). Config is addressed by ROW ID, so an existing profile's

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@try-works/dsh-memory",
-  "version": "0.1.26",
+  "version": "0.1.27",
   "description": "Git-backed, workspace-scoped memory for the DeepSeek Harness (global layer + per-workspace layers)",
   "type": "module",
   "main": "src/index.js",

package/scripts/inspect-one-session.ts

@@ -0,0 +1,28 @@
+/* eslint-disable no-console */
+// One-session inspection via the harness's real session-query reader.
+import { Context } from '@deepseek-ai/cordis'
+import { SessionStore } from '@deepseek-ai/dsh-session'
+import JsonlSessionPersistence from '@deepseek-ai/dsh-session-persistence-jsonl'
+import SqliteSessionQueryEngine from '@deepseek-ai/dsh-session-query-sqlite'
+
+const root = process.argv[2] ?? 'C:/Users/erikb/.dsh/sessions'
+const id = process.argv[3]
+if (!id) throw new Error('usage: inspect-one-session.ts <sessions-root> <id>')
+const ctx = new Context()
+await ctx.plugin(SessionStore)
+await ctx.plugin(JsonlSessionPersistence, { root, compression: 'zstd' })
+await ctx.plugin(SqliteSessionQueryEngine, { path: ':memory:', openAt: 'first-search' })
+const snapshot = await ctx.sessionQuery.readSession(id)
+console.log(JSON.stringify({ id: snapshot.session.id, cwd: snapshot.session.cwd, createdAt: snapshot.session.createdAt, count: snapshot.events.length, origin: snapshot.session.origin, delegationDepth: snapshot.session.delegationDepth, parentSession: snapshot.session.parentSession }))
+for (const event of snapshot.events) {
+  if (event.type === 'user/message') {
+    const text = event.data.message?.content?.filter?.(x => x.type === 'text').map(x => x.text).join('\n') ?? ''
+    if (text) console.log(`USER[${event.seq}]: ${text.slice(0, 500)}`)
+  } else if (event.type === 'assistant/message') {
+    const text = event.data.message?.content?.filter?.(x => x.type === 'text').map(x => x.text).join('\n') ?? ''
+    if (text) console.log(`ASSISTANT[${event.seq}]: ${text.slice(0, 350)}`)
+  } else if (event.type === 'tool/call') {
+    console.log(`TOOL[${event.seq}]: ${event.data.name} ${String(event.data.arguments).slice(0, 250)}`)
+  }
+}
+process.exit(0)

package/scripts/inspect-search-db.ts

@@ -0,0 +1,24 @@
+/* eslint-disable no-console */
+// Diagnostic: read the session-search index the way a search would.
+import { DatabaseSync } from 'node:sqlite'
+
+const db = new DatabaseSync(process.argv[2] ?? 'C:/Users/erikb/.dsh/storages/session-search.sqlite', { readOnly: true })
+const tables = db.prepare("SELECT name, type FROM sqlite_master WHERE type IN ('table','view') ORDER BY name").all()
+console.log('objects:', tables.map((t) => `${t.type}:${t.name}`).join(', ') || '(none)')
+
+for (const { name, type } of tables) {
+  if (type !== 'table' || name.startsWith('sqlite_')) continue
+  try {
+    const n = db.prepare(`SELECT COUNT(*) AS n FROM "${name}"`).get()
+    console.log(`  ${name}: ${n.n} rows`)
+  } catch (err) {
+    console.log(`  ${name}: unreadable (${String(err).slice(0, 80)})`)
+  }
+}
+
+// Show the schema so the columns a search would read are visible.
+for (const { name, type } of tables) {
+  if (type !== 'table' || name.startsWith('sqlite_')) continue
+  const sql = db.prepare('SELECT sql FROM sqlite_master WHERE name = ?').get(name)
+  console.log(`\n--- ${name} ---\n${sql.sql}`)
+}

package/scripts/orphan-for-recovery.ts

@@ -0,0 +1,15 @@
+/* eslint-disable no-console */
+// One-shot: mark a legacy header-only candidate orphaned so memory_recover can rebuild it.
+// A `pending` entry with a header-only digest (no summary) cannot be consolidated, and capture
+// will never re-summarize a historical session on its own. Recovery is the path that re-reads
+// the session log and re-captures it.
+import { readQueue, transition, STATES, REASONS } from '../src/queue.js'
+
+const ROOT = process.argv[2] ?? 'E:/dsh-memory'
+const id = process.argv[3]
+if (!id) throw new Error('usage: orphan-for-recovery.ts <root> <id>')
+
+const entry = readQueue(ROOT).get(id)
+if (!entry) throw new Error(id + ' is not in the queue')
+transition(ROOT, id, STATES.ORPHANED, { reason: REASONS.DIGEST_GONE })
+console.log(`orphaned ${id} (was ${entry.state}); now run memory_recover({ id: '${id}' })`)

package/scripts/probe-search.ts

@@ -0,0 +1,44 @@
+/* eslint-disable no-console */
+// Probe: does the session-search index actually index the REAL session logs?
+//
+// The live index at ~/.dsh/storages/session-search.sqlite holds 0 rows and has never been
+// written since it was created. Because `openAt: first-search` means reconciliation runs on the
+// first real search, "empty" could equally mean "never searched" or "searches index nothing".
+// This assembles the real persistence + query services over a COPY of a real sessions root, so a
+// search can be observed without touching the live index.
+//
+// Usage: node --import tsx/esm scripts/probe-search.ts <sessions-root-copy> <out.sqlite>
+import { Context } from '@deepseek-ai/cordis'
+import { SessionStore } from '@deepseek-ai/dsh-session'
+import JsonlSessionPersistence from '@deepseek-ai/dsh-session-persistence-jsonl'
+import SqliteSessionQueryEngine from '@deepseek-ai/dsh-session-query-sqlite'
+
+const root = process.argv[2]
+const out = process.argv[3]
+if (!root || !out) throw new Error('usage: probe-search.ts <sessions-root> <out.sqlite>')
+
+const ctx = new Context()
+await ctx.plugin(SessionStore)
+await ctx.plugin(JsonlSessionPersistence, { root, compression: 'zstd' })
+await ctx.plugin(SqliteSessionQueryEngine, { path: out, openAt: 'first-search' })
+
+const persistence = ctx.get('sessionPersistence')
+console.log('persistence service:', persistence ? 'present' : 'MISSING')
+const listed = await persistence.list()
+console.log('persistence.list():', listed.length, 'stored session(s)')
+for (const s of listed.slice(0, 3)) console.log('  -', s.header.id, 'cwd=' + s.header.cwd)
+
+const query = ctx.get('sessionQuery')
+console.log('sessionQuery service:', query ? 'present' : 'MISSING')
+
+// A word that certainly appears inside some session body but in no title.
+const needle = process.argv[4] ?? 'the'
+const page = await query.searchSessions({ query: needle, limit: 5 })
+console.log(`\nsearchSessions(${JSON.stringify(needle)}) -> ${page.items.length} hit(s)`)
+for (const hit of page.items.slice(0, 5)) {
+  console.log('  hit', hit.header.id, 'live=' + hit.live, 'persisted=' + hit.persisted)
+  console.log('     ', String(hit.bestMatch.snippet).replace(/\s+/g, ' ').slice(0, 140))
+}
+
+await ctx.stop?.()
+process.exit(0)

package/scripts/scan-unreadable.ts

@@ -0,0 +1,52 @@
+/* eslint-disable no-console */
+// Diagnostic: which stored session logs can the harness NOT read?
+//
+// The SQLite search index reconciles by listing persistence and cold-reading each log. A single
+// unreadable artifact aborts the whole observation (`session-search persistence observation
+// failed`), so the index stays empty and every search returns an error instead of results. This
+// walks the real sessions root and reports each artifact that fails to read, with its reason.
+//
+// Usage: node --import tsx/esm scripts/scan-unreadable.ts [sessions-root]
+import { Context } from '@deepseek-ai/cordis'
+import { SessionStore } from '@deepseek-ai/dsh-session'
+import JsonlSessionPersistence from '@deepseek-ai/dsh-session-persistence-jsonl'
+import { readColdSessionLog } from '@deepseek-ai/dsh-session-query'
+
+const root = process.argv[2] ?? 'C:/Users/erikb/.dsh/sessions'
+
+const ctx = new Context()
+await ctx.plugin(SessionStore)
+await ctx.plugin(JsonlSessionPersistence, { root, compression: 'zstd' })
+const persistence = ctx.get('sessionPersistence')
+
+const listed = await persistence.list()
+console.log(`stored sessions: ${listed.length}\n`)
+
+let ok = 0
+const failures = []
+for (const snapshot of listed) {
+  try {
+    await readColdSessionLog(persistence, snapshot.header.id, undefined)
+    ok += 1
+  } catch (error) {
+    failures.push({ id: snapshot.header.id, cwd: snapshot.header.cwd, error: String((error && error.message) || error) })
+  }
+}
+
+console.log(`readable:   ${ok}`)
+console.log(`UNREADABLE: ${failures.length}\n`)
+for (const f of failures) {
+  console.log(`- ${f.id}  cwd=${f.cwd}`)
+  console.log(`    ${f.error.slice(0, 220)}`)
+}
+
+// Group the failure reasons so the shape of the problem is visible at a glance.
+console.log('\n--- reasons, grouped ---')
+const groups = new Map()
+for (const f of failures) {
+  const key = f.error.replace(/\(raw log:.*\)/, '').replace(/session-[0-9a-f-]+|[0-9a-f]{8}-[0-9a-f-]{27,}/g, '<id>').trim().slice(0, 120)
+  groups.set(key, (groups.get(key) ?? 0) + 1)
+}
+for (const [reason, count] of [...groups].sort((a, b) => b[1] - a[1])) console.log(`${count}  ${reason}`)
+
+process.exit(0)

package/scripts/skip-subagent-held.ts

@@ -0,0 +1,24 @@
+/* eslint-disable no-console */
+// One-shot: settle subagent candidates stuck in `pending` with header-only digests.
+// These sessions are `origin: subagent` / `delegationDepth > 0`, so by the plugin's own rule
+// they are never memory material; their parent transcript holds the story. They reached `pending`
+// through the legacy migration and now have no summary to consolidate, so they would otherwise
+// sit in the backlog forever. This marks them skipped with a truthful reason.
+import { readQueue, transition, STATES, REASONS } from '../src/queue.js'
+
+const ROOT = process.argv[2] ?? 'E:/dsh-memory'
+const ids = process.argv.slice(3)
+if (ids.length === 0) throw new Error('usage: skip-subagent-held.ts <root> <id...>')
+
+// The subagent determination is NOT made here: the caller lists ids it has already verified
+// (by reading each session's header) as subagent sessions. This script only performs the queue
+// transition with a truthful reason, so it cannot skip a candidate on a guess.
+let skipped = 0
+for (const id of ids) {
+  const entry = readQueue(ROOT).get(id)
+  if (!entry) { console.log(`not in queue: ${id}`); continue }
+  transition(ROOT, id, STATES.SKIPPED, { reason: REASONS.TRIVIAL })
+  console.log(`skipped subagent: ${id}`)
+  skipped += 1
+}
+console.log(`\nskipped ${skipped} subagent candidate(s)`)

package/src/consolidate-run.js

@@ -10,18 +10,19 @@ import { readAssociations } from './workspace.js'
 export async function runConsolidation(store, {
   llm, digests, indexHeads, guidance, batchSize = 3, maxPromptBytes = 65536, maxDigestBytes = 20000, maxAttempts = 3,
 } = {}) {
-  // Prefer digests that actually have something to consolidate: a header-only digest costs a
-  // batch slot and a share of the prompt budget while carrying nothing.
+  // A header-only digest carries NOTHING to consolidate: capture has not summarized it yet.
+  // Sending it to the model spends a call on a header with no body, and the reply can only be
+  // "nothing durable" — which never advances the entry, so the same empty shells get re-sent
+  // forever (one real entry accumulated 39 attempts). Consolidation works on summaries; capture
+  // is what fills summaries. Header-only candidates are therefore left untouched here.
   const all = digests ?? pendingDigests(store)
   const withContent = []
-  const headerOnly = []
   for (const item of all) {
     const raw = readDigestText(store.root, item.id)
     if (raw.includes('summary (')) withContent.push(item)
-    else headerOnly.push({ ...item, empty: true })
   }
-  const pending = withContent.concat(headerOnly).slice(0, batchSize)
-  if (pending.length === 0) return { consolidated: 0, written: 0 }
+  if (withContent.length === 0) return { consolidated: 0, written: 0 }
+  const pending = withContent.slice(0, batchSize)
   // Bound the prompt: a digest is clipped to its own ceiling, and the whole payload
   // to the prompt budget. Each digest carries its header plus the most recent bullets.
   // Hand the model the RIGHT workspace key instead of letting it invent one from a path.
@@ -41,9 +42,9 @@ export async function runConsolidation(store, {
     const full = readDigestText(store.root, item.id)
     const text = clipBlock(full, Math.min(maxDigestBytes, budget))
     if (text === '') continue
-    // A digest with no summary section is a HEADER ONLY: capture has not summarized it yet
-    // (or its summary failed). It is not empty of purpose, it is empty of content, and sending
-    // it wastes a batch slot while inviting the model to mark it done forever.
+    // Every item in `pending` now carries a summary section (see the filter above), so `empty`
+    // is never true here. Kept explicit so a future change to the filter cannot silently revive
+    // the empty-digest branch that used to send a bare header to the model.
     const empty = !full.includes('summary (')
     // A backfilled digest carries material reconstructed from an old session rather than a live
     // summary. If ANY digest in the batch came from a backfill, the pass takes the stricter bar,