Context (V-B-A'd against the live orchestrator.log, 2026-06-26)
[Orchestrator] Deferring memory miniSummary backfill; heavy maintenance task knowledge base sync is active (pending-memory-minisummary:N) appears 123× in 1500 log lines (~8%) — a third orchestrator-log flood source (after #14147 the bridge + #14149 the child-stderr).
MaintenanceBackpressureService.recordDeferral (line 227) already dedups via a caller-owned deferralLogKeys Set, and clearDeferralLogState (line 193, called at lines 512/571/642) clears it per-episode — so it should log once per deferral episode. But the dedup key embeds the full reasonText (line 242):
`${taskName}:${blockingTaskName}:${reasonText}`and memorySummaryBackfill.mjs:195 sets reason: \pending-memory-minisummary:${backlog}` — **backlogis the pending count, which changes every poll** → a new dedup key every poll → the dedup never fires → it logs every ~3s while kbSync holds the lease (hours, during a re-embed). Other deferrals whosereasonText carries a *constant* interval (periodic-sweep:86400000`) dedup correctly (2-3× in the log).
The fix (log-key only — does NOT touch the deferral behavior / the deliberate fully-serial mutex)
Stabilize the dedup key by stripping the trailing volatile counter, keeping the full reasonText in the log message + the structured recordTaskOutcome payload:
NEO_CODE_BLOCK_1
pending-memory-minisummary:47 / :48 / :49 collapse to one key → one log per episode; periodic-sync (no counter) and periodic-sweep:<interval> are unaffected in effect.
Acceptance criteria
Refs #14147, #14149 (sibling log-hygiene), #14144 (the backpressure behavior — distinct), #14039 (epic). Self-assign @neo-opus-ada. Authored by Ada (Claude Opus 4.8, Claude Code).
Context (V-B-A'd against the live
orchestrator.log, 2026-06-26)[Orchestrator] Deferring memory miniSummary backfill; heavy maintenance task knowledge base sync is active (pending-memory-minisummary:N)appears 123× in 1500 log lines (~8%) — a third orchestrator-log flood source (after #14147 the bridge + #14149 the child-stderr).MaintenanceBackpressureService.recordDeferral(line 227) already dedups via a caller-owneddeferralLogKeysSet, andclearDeferralLogState(line 193, called at lines 512/571/642) clears it per-episode — so it should log once per deferral episode. But the dedup key embeds the fullreasonText(line 242):`${taskName}:${blockingTaskName}:${reasonText}`and
memorySummaryBackfill.mjs:195setsreason: \pending-memory-minisummary:${backlog}`— **backlogis the pending count, which changes every poll** → a new dedup key every poll → the dedup never fires → it logs every ~3s while kbSync holds the lease (hours, during a re-embed). Other deferrals whosereasonTextcarries a *constant* interval (periodic-sweep:86400000`) dedup correctly (2-3× in the log).The fix (log-key only — does NOT touch the deferral behavior / the deliberate fully-serial mutex)
Stabilize the dedup key by stripping the trailing volatile counter, keeping the full
reasonTextin the log message + the structuredrecordTaskOutcomepayload:NEO_CODE_BLOCK_1
pending-memory-minisummary:47/:48/:49collapse to one key → one log per episode;periodic-sync(no counter) andperiodic-sweep:<interval>are unaffected in effect.Acceptance criteria
reasonTextcounter dedup to ONE log line per episode.clearDeferralLogState) re-logs once.recordTaskOutcomepayload still carry the livereasonText(with count).Refs #14147, #14149 (sibling log-hygiene), #14144 (the backpressure behavior — distinct), #14039 (epic). Self-assign @neo-opus-ada. Authored by Ada (Claude Opus 4.8, Claude Code).