Summary
The Pulse memory badge counts a proposal as pending unless its status is exactly auto-applied. Every other terminal state — applied (a human accepted it) and dismissed (a human rejected it) — stays counted forever, so the badge never returns to zero once a proposal has been resolved by hand.
Root cause
LIFEOS/PULSE/modules/memory.ts:238:
pendingProposals: proposals.filter((p: any) => p.status !== "auto-applied").length,
The filter enumerates a single terminal state by exclusion. Any status the pipeline can reach that is not that one literal counts as outstanding work, including the two states that mean a human already dealt with it.
Impact
A badge that cannot return to zero stops being read. After the first hand-resolved proposal the number only ever grows, so the signal that should say "something needs you" becomes decoration — and the next genuinely pending proposal arrives invisible inside a count that was already non-zero.
Proposed fix
Enumerate the terminal states positively, and deliberately leave auto-apply-failed out of them — a failed apply is a signal that still wants attention, not a resolution:
// Terminal statuses a proposal can reach: it silently applied, a human accepted it, or a
// human dismissed it. Anything else ("pending", "auto-apply-failed") still wants attention
// and stays counted. "auto-apply-failed" is deliberately NOT resolved — a failed apply is
// a signal, not a resolution.
const RESOLVED_PROPOSAL_STATUSES = new Set(["auto-applied", "applied", "dismissed"]);
// …
pendingProposals: proposals.filter((p: any) => !RESOLVED_PROPOSAL_STATUSES.has(p.status)).length,Running locally since 2026-07-25; the badge clears as expected and a failed auto-apply still shows.
Summary
The Pulse memory badge counts a proposal as pending unless its status is exactly
auto-applied. Every other terminal state —applied(a human accepted it) anddismissed(a human rejected it) — stays counted forever, so the badge never returns to zero once a proposal has been resolved by hand.Root cause
LIFEOS/PULSE/modules/memory.ts:238:The filter enumerates a single terminal state by exclusion. Any status the pipeline can reach that is not that one literal counts as outstanding work, including the two states that mean a human already dealt with it.
Impact
A badge that cannot return to zero stops being read. After the first hand-resolved proposal the number only ever grows, so the signal that should say "something needs you" becomes decoration — and the next genuinely pending proposal arrives invisible inside a count that was already non-zero.
Proposed fix
Enumerate the terminal states positively, and deliberately leave
auto-apply-failedout of them — a failed apply is a signal that still wants attention, not a resolution:Running locally since 2026-07-25; the badge clears as expected and a failed auto-apply still shows.