Stop-hook capture overwrites the per-session transcript each turn — only the first turn of every session ever syncs; later turns are silently dropped as "unchanged"

[JUNX7764]

Environment

• Plugin: nowledge-mem-zcode 0.2.1 (installed from the GitHub marketplace source; hooks confirmed loaded)
• nmem CLI/server: 0.10.86 (desktop-managed, local mode)
• ZCode: App 0.16.9 / CLI on macOS (arm64)
• Follow-up to Hooks silently not loaded from a local directory marketplace; ZCode 0.16.5 Stop transcript is assistant-only so stock sync always fails #2 — 0.2.1's pending-prompt pairing fixed "stock sync always fails", but introduced/left a multi-turn gap

Symptom

Every ZCode session syncs to Nowledge Mem with only its first turn (1 user + 1 assistant message). All subsequent turns in the same session are captured by the Stop hook but never imported. There is no error anywhere; the failure is silent.

Observed across 9 sessions spanning two days: every per-session transcript in plugins/data/nowledge-mem-zcode@nowledge-zcode/transcripts/ contains exactly 2 lines (the latest turn at capture time), and every zcode-sess_* thread in Nowledge Mem contains exactly the first turn.

Root cause

Three parts compound:

1. The hook overwrites the per-session transcript instead of accumulating. copiedTranscriptPath() in hooks/zcode-mem-hook.mjs does writeFileSync(out, body) on a fixed per-session path. Because completeTranscript() pairs only the uncleared pending prompts (cleared after each successful sync) with the assistant-only Stop transcript, each Stop emits exactly one turn and replaces whatever was there before.

2. nmem t sync reconciles an existing thread positionally, not by content. Re-syncing a transcript that contains only turn 2 for a thread that already has turn 1 returns:

   {"action": "unchanged", "messages_added": 0, "total_messages": 2}

   The 2 new messages are never appended — same count, same positions → "unchanged".

3. --checkpointed can't cover the gap yet: nmem t sync --from zcode --checkpointed returns "checkpointed automatic capture is not yet available for zcode; use the normal sync path".

Proof the server appends fine when the transcript is cumulative

Controlled experiment with a throwaway session (cleaned up afterwards):

• Sync a 2-message transcript → created.
• Append 2 more messages to the same transcript file, sync again → "action": "appended", "messages_added": 2, "total_messages": 4. ✅

So the server-side reconciliation appends correctly as long as each sync receives the full conversation so far. The plugin is the side sending only the delta.

Suggested fixes

Any one of these closes the gap:

1. Plugin: accumulate the per-session transcript. In copiedTranscriptPath(), append each reconstructed turn to the existing per-session file (or rebuild the full conversation from the sqlite store, as in the workaround described in Hooks silently not loaded from a local directory marketplace; ZCode 0.16.5 Stop transcript is assistant-only so stock sync always fails #2) instead of writeFileSync-overwriting it. This matches what t sync already expects and makes every sync idempotent.
2. Server: enable --checkpointed capture for the zcode source, so per-turn deltas append from a durable checkpoint.
3. In the meantime, a doctor/status check that compares the transcript's turn count against the thread's message count would surface the silent drop.

Footnote

The 0.2.1 changelog says new sessions "retain ordered user and assistant turns" — with this bug, that only holds for the first turn of each session. The save-handoff skill remains the only reliable path for multi-turn sessions today.

[JUNX7764]

Update: local patch deployed and verified working.

I went ahead and patched the installed hook (hooks/zcode-mem-hook.mjs) along the lines of suggested fix #1, plus one related hardening:

1. copiedTranscriptPath(): accumulate instead of overwrite. New appendTranscriptEvents() appends each reconstructed turn to the per-session transcript with content+timestamp dedup, so every sync carries the full conversation — which t sync's positional reconciliation expects.
2. completeTranscript(): pair newest prompts with newest assistant messages instead of returning null. The stock assistants.length < prompts.length guard meant a single failed sync left pending prompts that permanently stalled the session (every later Stop produced no capture at all — observed in the wild: transcript file frozen while pending prompts piled up).

Verified with simulated Stop events (backlog pairing, dedup on re-fire, multi-turn accumulation all behave) and a real session healed via the sqlite export workaround from #2: cumulative sync reported appended, messages_added: 12. Test threads cleaned up afterwards.

Happy to open a PR with the patch if welcome.

[zenstoneWX]

Independent cross-version verification (nmem 0.10.82 / 0.10.85 / 0.10.89): confirmed, and it is not version-specific

Another machine reproduces this exactly. Controlled test with a throwaway session (cleaned up afterwards), syncing flat JSONL directly through the real CLI — no plugin in the loop:

nmem -j t sync --from zcode --session-dir <file> --session-id <sid> --all-projects [--apply]

Step	File content	Apply result
T1	[u1,a1]	created=1 — thread has 2 messages ✅
T2	[u2,a2] (disjoint / per-turn delta)	unchanged=1 — thread stays at 2 messages ❌
T3	[u1,a1,u2,a2] (cumulative)	appended=1 (+2) — 4 messages ✅
T4	[u1,a1,u2,a2,u3,a3]	appended=1 (+2) — 6 messages ✅

Identical behavior on nmem 0.10.85 and 0.10.82 (2026-09-21 / 09-23 runs) — so the server-side reconciliation stays positional/growth-based across releases, and a delta-only file can never accumulate. Still true on 0.10.89 (2026-09-27).

Two practice notes for validating this:

1. Preview cannot predict growth. Without --apply, a disjoint delta reports action: "ready"; the unchanged verdict only appears at apply time.
2. Direct file sync is name-sensitive. For --session-dir <file>, the file must be named <session-id>.jsonl; a differently named file returns No ZCode sessions found.

Since 2026-09-21 we've been running the accumulate-in-hook approach (suggested fix #1 here) as a local patch in production: append each turn to the per-session transcript, dedup adjacent duplicates, sync the growing file on every Stop. It has been stable across the nmem 0.10.82 → 0.10.89 upgrades — sessions keep growing past 100 messages over many turns with no duplication. Happy to help validate a PR for this.

[JUNX7764]

PR opened: #6 — accumulates the per-session transcript with suffix-aware dedup (role + content, timestamps ignored so retried turns replace instead of duplicate) and unblocks the stall path by pairing newest prompts with newest capturable replies. Repo test suite extended to cover multi-turn accumulation and retry; test-hook.mjs + validate-plugin.mjs green. Thanks for the cross-version confirmation and the production data point — reviews welcome.