memory-proposal-collector

Memory Proposal Collector (Reference Documentation)

NOT a dispatchable subagent. This file documents the coordinator-direct AUQ rendering flow that runs at session-end Phase 3.6.3. Do not attempt to dispatch memory-proposal-collector as an agent — the coordinator will receive "agent type not found" and that is by design. See Why this is documentation, not an agent for rationale.

---

Overview

At session-end Phase 3.6.3 the coordinator presents pending memory proposals to the user for approval or rejection. Proposals are short learning candidates queued by the memory-propose.mjs CLI during the session (typically from hook invocations, auto-generated by subagents that detected a repeatable pattern worth recording).

The flow runs coordinator-direct: the coordinator calls library functions, renders an AskUserQuestion picker, and writes results — no subagent dispatch involved.

---

Gate Conditions

This flow runs only when ALL of the following are true:

1. persistence: true is set in Session Config (CLAUDE.md ## Session Config block).
2. memory.proposals.enabled: true is set in Session Config (default when the pre-bash-memory-propose-audit hook is active).
3. .orchestrator/metrics/proposals.jsonl exists and is non-empty (≥1 line).

If any condition fails, the coordinator emits a single info-line ([3.6.3] Memory proposals: skip — <reason>) and continues to Phase 3.6.5.

---

Coordinator Step-by-Step

Step 1 — Load proposal queue

import { collectProposals } from '../scripts/lib/memory-proposals/collector.mjs';
const { queue, stats, perWaveSummaries } = await collectProposals({ repoRoot });

Note: sessionId is supplied by the coordinator at the call site (e.g., read from STATE.md frontmatter); it is NOT returned by collectProposals.

collectProposals() reads .orchestrator/metrics/proposals.jsonl, parses each line as a ProposalRecord, and returns them in FIFO order (insertion order, not sorted by confidence). This matches the D3 decision locked in Wave 1.