Timestamp Memory Core repair-defrag progress lines

Context

During the live Memory Core repair-defrag, the operator added the new progress output from #14011/#14013 but found the log still hard to correlate with LM Studio warnings and wall-clock runtime. The visible progress stream now reports useful phase buckets, but the individual repair progress lines have no timestamp:

3️⃣  Memory Core repair-defrag: full-enumeration extract + re-embed + shadow-promote...
   🔎 Enumerating Memory Core metadata/vector coverage for 3 collection(s)...
   ✅ Coverage enumeration complete (4 coverage row(s)).
   📦 'neo-agent-memory': metadata=22545, vector=8583, missing=13962, extra=0
   ⏳ 'neo-agent-memory': extraction starting (total=22545, intact=0, reEmbedded=0, unrecoverable=0)
   ⏳ 'neo-agent-memory': intact-vector extraction 10% (1000/8583; intact=1000)
   ⏳ 'neo-agent-memory': missing-vector re-embed 30% (5000/13962; reEmbedded=5000, unrecoverable=0)

When the repair can run for hours and LMS emits separate warnings with timestamps, untimestamped progress lines are not enough. The operator cannot pin which repair batch or phase emitted which external warning without manual wall-clock watching.

The Problem

#14011 made repair-defrag progress visible, but not time-correlatable. That leaves a forensic gap during incident recovery: progress percentage, phase, and counts are present, but not the precise time at which each phase/bucket occurred.

This is a follow-up, not a reopening of #14011. The missing functionality is narrower: add machine-readable timestamps to the progress log lines emitted by the repair-defrag path.

The Architectural Reality

The affected surface is the operator-facing maintenance script output:

• ai/scripts/maintenance/defragChromaDB.mjs owns formatMemoryCoreRepairProgress() and the CLI log calls around Memory Core repair-defrag.
• ai/scripts/maintenance/repairMemoryCoreStoredEmbeddings.mjs already emits phase/count progress events; the timestamp belongs at formatting/logging time, not in embedding provider config or Chroma state.
• The format should remain human-readable while making correlation with LM Studio / process supervisor logs straightforward.

The Fix

1. Prefix Memory Core repair-defrag progress lines with an ISO timestamp or otherwise include an explicit timestamp field in each formatted progress line.
2. Cover start, intact extraction, missing re-embed, complete, and fallback progress phases.
3. Keep the existing phase/count content intact so #14011 progress semantics do not regress.
4. Add focused unit coverage for timestamped progress formatting.

Contract Ledger Matrix

Decision Record impact

none - this is maintenance-script observability within the existing repair-defrag path.

Acceptance Criteria

• Memory Core repair progress lines include an ISO timestamp or equivalent explicit timestamp.
• Timestamped output covers extraction start, intact extraction buckets, missing-vector re-embed buckets, completion, and fallback progress phases.
• Existing collection name, phase, percent, processed/total, and count details remain present.
• Unit coverage proves representative timestamped progress lines.
• The change does not alter embedding provider selection, batch sizing, Chroma mutation semantics, or defrag repair control flow.

Out of Scope

• Reopening #14011 or changing its completed progress-bucket scope.
• Fixing LMS SEP/EOS handling, tracked by #14015/#14016.
• Repairing Memory Core vector corruption or backup exportability, tracked by #13999.
• Changing Chroma defrag/backup semantics.

Avoided Traps

• Do not add timestamps to the embedding payload or metadata. This is log formatting only.
• Do not use a relative elapsed counter only; external log correlation needs a wall-clock timestamp.
• Do not remove the existing progress wording that operators are already using.

Related

Related: #14011 Related: #14013 Related: #13999 Related: #14015

Live latest-open sweep: checked latest 20 open issues at 2026-06-25T18:43Z; no equivalent open ticket found. Targeted open search for defrag timestamp progress log Memory Core repair returned no open issues. A2A in-flight claim sweep: checked latest 30 all-status messages at the same time; no overlapping [lane-claim] or [lane-intent] found.

Origin Session ID: 9280140f-8b54-4462-9342-49cca7e226f4

Handoff Retrieval Hints: Memory Core repair-defrag progress timestamps formatMemoryCoreRepairProgress, #14011 progress bucket timestamp follow-up, correlate LMS warnings with defrag re-embed progress