Summary
As of 7.28.3, no shipped code can resolve a human-gated memory proposal. The Telegram reply path that used to write the decision statuses was removed in the same release that renamed telegram-proposals.ts to memory-proposals.ts, and nothing replaced it. Four of the six statuses in the proposal union (sent, accepted, rejected, edited) now have zero writers anywhere in the repository.
Evidence, from main as of 2026-08-09
Grepping the repository for consumers of the proposals library (markProposal, applyProposalEdit, parseProposalReply, drainPendingProposals) finds exactly three files:
LIFEOS/PULSE/lib/memory-proposals.ts (the library itself)LIFEOS/TOOLS/MemoryReviewer.ts (enqueues pending, writes auto-applied / auto-apply-failed)LIFEOS/PULSE/modules/memory.ts (counts rows for the dashboard)
Path-based access to pending-proposals.jsonl adds only the menubar counter and two more memory tools, none of which implements a decision. There is no surface left that can accept, reject, or edit a proposal.
Consequence
Every proposal the reviewer does not auto-apply lands in the queue and stays pending forever. The pending badge that #1610 fixed can now never clear for human-gated rows, this time by construction rather than by a wrong filter: the count is correct, and the number only ever goes up.
This failure is silent in exactly the way that matters. The reviewer keeps capturing durable user statements correctly, the queue keeps growing, and nothing ever surfaces them for a decision. In my install this pattern buried a month of correct captures before I noticed, back when the Telegram drain still existed but was piggybacked on a conversational turn that my usage never reached. Main is now in a strictly worse version of that state for every install, regardless of usage pattern.
Questions and suggestion
The 7.28.3 release notes mention the Hermes sidecar, so a rewire of the reply channel may already be planned. If so, this issue is mostly a request to confirm that, and to note that the terminal-status authority proposed in #1804 is a natural prerequisite, so the new channel does not hand-roll its own status literals.
If it is not planned, the suggestion: make the decision primitive channel-neutral in the library (something like resolveProposal(id, decision) owning status transitions and the edit application), and let surfaces be thin. A terminal CLI over the existing library is a few hundred lines; I built one locally to drain my own backlog and would be happy to PR a cleaned-up version if that direction is welcome.
Related
#1804 is the companion issue on the status union and hand-rolled terminal lists, filed separately since it is a type-design defect rather than a functional gap. #1610 is the shared history for both.
Summary
As of 7.28.3, no shipped code can resolve a human-gated memory proposal. The Telegram reply path that used to write the decision statuses was removed in the same release that renamed
telegram-proposals.tstomemory-proposals.ts, and nothing replaced it. Four of the six statuses in the proposal union (sent,accepted,rejected,edited) now have zero writers anywhere in the repository.Evidence, from main as of 2026-08-09
Grepping the repository for consumers of the proposals library (
markProposal,applyProposalEdit,parseProposalReply,drainPendingProposals) finds exactly three files:LIFEOS/PULSE/lib/memory-proposals.ts(the library itself)LIFEOS/TOOLS/MemoryReviewer.ts(enqueuespending, writesauto-applied/auto-apply-failed)LIFEOS/PULSE/modules/memory.ts(counts rows for the dashboard)Path-based access to
pending-proposals.jsonladds only the menubar counter and two more memory tools, none of which implements a decision. There is no surface left that can accept, reject, or edit a proposal.Consequence
Every proposal the reviewer does not auto-apply lands in the queue and stays
pendingforever. The pending badge that #1610 fixed can now never clear for human-gated rows, this time by construction rather than by a wrong filter: the count is correct, and the number only ever goes up.This failure is silent in exactly the way that matters. The reviewer keeps capturing durable user statements correctly, the queue keeps growing, and nothing ever surfaces them for a decision. In my install this pattern buried a month of correct captures before I noticed, back when the Telegram drain still existed but was piggybacked on a conversational turn that my usage never reached. Main is now in a strictly worse version of that state for every install, regardless of usage pattern.
Questions and suggestion
The 7.28.3 release notes mention the Hermes sidecar, so a rewire of the reply channel may already be planned. If so, this issue is mostly a request to confirm that, and to note that the terminal-status authority proposed in #1804 is a natural prerequisite, so the new channel does not hand-roll its own status literals.
If it is not planned, the suggestion: make the decision primitive channel-neutral in the library (something like
resolveProposal(id, decision)owning status transitions and the edit application), and let surfaces be thin. A terminal CLI over the existing library is a few hundred lines; I built one locally to drain my own backlog and would be happy to PR a cleaned-up version if that direction is welcome.Related
#1804 is the companion issue on the status union and hand-rolled terminal lists, filed separately since it is a type-design defect rather than a functional gap. #1610 is the shared history for both.