journal: add routing layer to separate memory-candidates from resume-checkpoints / open-questions / process-reports

[tznthou]

Context

v0.3.0 session_journal is a single bucket — all auto-harvested entries with score>=0 flow into one queue, and ccmem promote / ccmem reject is the only outbound. Cross-provider review (Codex, 2026-05-08) observes that journal entries serve mixed semantic purposes that should not compete on the same promotion path.

Finding

5/7 dogfood capture (16 entries, 24h) shows at least 5 distinct semantic kinds in one bucket:

journal id	content kind	should route to
18	smoke-test plan with priority list	resume-checkpoint (next session todo)
19	next-session reminder	resume-checkpoint
10	trial schedule + commits-to-push	resume-checkpoint
9	open question soliciting user decision	open-question (likely discard)
21	technical knowledge wrapped in summary	memory-candidate (after extract)
6/8 (rejected)	wrap-up process reports	process-report (discard / hard-floor)

memories is intended as durable lasting facts for recall_query retrieval. Routing all kinds through one promote path means:

• Resume-checkpoints (id=10/18/19) pollute memories if promoted, vanish if rejected — but their natural home is project resume / next-session todo, not memories
• Open-questions (id=9) are transient by definition — promoting them is misuse, but rejecting loses the context of "user asked about X"
• Process-reports (id=6/8) are Wrap-up flow leakage: Chinese verb form '存檔完成' bypasses PROCESS_REPORT_RES anchor #27 territory — should never reach pending in the first place
• Memory-candidates (id=21) are the only true positives, and only after extract (companion issue: partial promote UX)

Why this matters

• journalPendingCount aggregates 5+ kinds — the metric is structurally noisy
• Manual promote yield (issue Surfacing UX: SessionStart hook nudge for pending journal review #28's nudge UX) is upper-bounded by wrong routing — even with ideal review UX, user keeps seeing entries that shouldn't be candidates
• ccFamily division (cc trilogy planning) suggests resume-checkpoints belong to a different surface than memories — this issue is where that division lands at the data layer

Proposed fix

Add entry_type column to session_journal (schema v24):

```sql
entry_type TEXT NOT NULL DEFAULT 'unclassified'
CHECK (entry_type IN ('memory-candidate', 'resume-checkpoint', 'open-question', 'process-report', 'unclassified'))
```

Classification logic in outcome-scorer.ts (extending epistemic-status work in companion scorer issue):

• process-report: matches isProcessReport() (existing Wrap-up flow leakage: Chinese verb form '存檔完成' bypasses PROCESS_REPORT_RES anchor #27 hard floor) → still hard-floor blocked, never reaches journal
• open-question: ends with question marks targeting user, vocab signals (要不要 / shall we / which option)
• resume-checkpoint: contains schedule markers (next session / 下次 / 5月X日 / commit待push) AND last-substantial-assistant position
• memory-candidate: real outcome vocab (impl-facts / cause-effect anchors), not session-ending wrap-up
• unclassified: doesn't match any → still surfaces in pending but flagged

ccmem pending and ccmem promote filter by entry_type='memory-candidate' by default; explicit --all or --type X flag exposes other types for triage.

resume-checkpoint entries: out of scope to route in this issue — flag the type at minimum, then a follow-up issue can decide outbound (project resume generator? cc trilogy ccReason hand-off?).

Acceptance criteria

• Schema v24 adds session_journal.entry_type column with CHECK constraint
• outcome-scorer.ts returns entry_type alongside score / reasons (signature extended)
• ccmem pending defaults to memory-candidate filter; --type X switches; --all shows everything
• Migration: legacy entries get entry_type='unclassified' (handled by DEFAULT)
• Test cases: 5/7 ground-truth entries classify correctly per the table above
• Documentation: entry_type semantics in docs/architecture.md

Risk

• Larger architectural change than Wrap-up flow leakage: Chinese verb form '存檔完成' bypasses PROCESS_REPORT_RES anchor #27 / Surfacing UX: SessionStart hook nudge for pending journal review #28 / companion scorer/promote issues — affects scorer signature, schema, CLI, and docs. Likely needs RFC discussion before implementation.
• Classification ambiguity: real entries blend kinds (id=21 is memory-candidate-after-extract, currently looks like wrap-up). Initial classifier will mis-categorize; observation period (corpus collection) needed to tune.
• Resume-checkpoint outbound is unsolved — flagging without routing leaves a half-implemented surface. Acceptance: this issue lands the type; a follow-up issue drives outbound.

Related

• Wrap-up flow leakage: Chinese verb form '存檔完成' bypasses PROCESS_REPORT_RES anchor #27 (4 commits in main, awaiting 0.4.0 batch) — process-report hard floor; same scoring-layer touch points
• Surfacing UX: SessionStart hook nudge for pending journal review #28 (open) — ccmem pending UX; entry_type filter integrates here
• Make tags first-class in recall — extend to memories table and add filter to recall_query #15 (open) — tag first-class; entry_type is orthogonal (entry_type is automatic semantic kind, tag is user-curated topic)

Cross-provider review trail

Codex review (2026-05-08): journal entries currently mix lasting fact / resume checkpoint / open question / plan / tool lesson — all competing on same promotion path. Plans and session markers are more like checkpoints than memories — recommends routing layer to separate semantic kinds before they enter the same review queue.