Memory proposals are CLI-only: Pulse serves the pending count but has no surface to decide, and the decision library is already in the repo

Memory proposals below the auto-apply threshold enqueue to pending-proposals.jsonl and wait for a human. Pulse counts them and never shows them: GET /api/memory serves pendingProposals, no component renders it, and the module refuses every method that is not a read, so there is no route a decision could travel on. The only way to resolve a row is the CLI.

What makes this worth reporting rather than just doing: the hard half is already written and wired to nothing.

What exists

• LIFEOS/PULSE/lib/memory-proposals.ts implements all four decisions — accept, reject, edit, applied-elsewhere — with the status transitions, the target pinning and the observability logging.
• LIFEOS/TOOLS/ProposalDecide.ts is explicitly a thin driver over it, and its header says why:

 * This CLI is a thin driver over the decision writers in
 * `LIFEOS/PULSE/lib/memory-proposals.ts`. The transitions, the target pinning,
 * and the observability logging all live there, so a Pulse or Hermes surface can
 * offer the same four decisions without reimplementing any of it.

• LIFEOS/PULSE/modules/memory.ts already reads the queue and publishes the counts (pendingProposals, autoAppliedProposals, proposalsRecent).

What is missing

• No component in LIFEOS/PULSE/Observability/src mentions proposals at all; a search for the word across the web source returns only an unrelated navigation entry.
• LIFEOS/PULSE/modules/memory.ts returns early for any non-GET request, and publishes four read routes. Nothing can post a decision.
• The menu-bar surface does badge N memory proposals await you, which names the queue and leads nowhere.

So the count is visible in three places and actionable in none, unless the user knows the CLI exists.

What it costs in practice

On this install the queue held 7 rows. Four of them were identical RULE: E2E mock rows with why: smoke, all targeting the principal identity file, left behind by an end-to-end test. They had sat in the badge count for days. A human looking at a list would have cleared them in seconds; instead they age in a number.

That is a second, smaller finding worth separating: the smoke test appears to write into the live queue. A fixture queue would keep test rows out of the count a human is asked to trust.

Suggested shape

A panel on the Cortex page listing the pending rows — target file, confidence, the proposed text, the why — with the four decisions as buttons, posting to routes that call the existing library. No new decision logic, no new storage, and the CLI keeps working unchanged for scripted use.

Happy to send this as a PR if the direction is right.