memory: drop personal preference extraction for multi-actor runs

[dcramer]

Policy

When a run has multiple actors (run.actors.length > 1), passive memory extraction must not record preference memories at all — not even preferences whose evidence citations all point at run-actor instructions.

Rationale: in a multi-actor turn, first-person statements from different people are interleaved in model-visible content. Citation verification (#773 Track 1) makes cross-actor personal writes require the model to mis-cite, but a mis-cite is still possible; multi-actor runs are exactly where the cost of that mistake is highest. Personal preferences can wait for a single-actor run to restate them. This is defense in depth on top of the deterministic router, not a replacement for it.

Implementation sketch

• packages/junior-memory/src/process-session.ts routeExtractedMemory: add a deterministic gate — kind === "preference" && run.actors.length > 1 → drop (never downgrade to conversation scope, consistent with the existing rule).
• run.actors is already exposed on the plugin run context (specs/multi-actor-runs.md; attribution-not-authority contract).
• Spec: add the rule to specs/memory-plugin/policy.md (personal-scope authorship section).
• Tests: junior-memory component test — multi-actor run + preference proposal citing only run-actor instructions → dropped; single-actor run unchanged. Eval: extend packages/junior-evals/evals/memory/multi-actor-provenance.eval.ts case 2/3 DB assertions if needed (they already assert no cross-actor personal writes; add an assertion that no preference row is written at all for the batched multi-actor case).

Depends on

• Audit actor/instruction provenance across plugins #773 Track 1 (run.actors) — implemented on eval/multi-actor-provenance, pending merge.

Part of the #773 follow-up set: case-specific consumers of run.actors.

[dcramer]

Analysis after implementation planning:

The fix should not just add a prompt instruction or pass derived booleans like hasRunActor or runActorCount. The memory routing code should consume the existing run context directly, so the policy is expressed in domain terms:

routeExtractedMemory(memory, transcript, run)

with the hard storage gate:

if (memory.kind === "preference" && run.actors.length > 1) {
  return "drop";
}

Recommended implementation shape:

1. Pass run or Pick<PluginRunContext, "actor" | "actors"> into routeExtractedMemory rather than inventing a new routing context.
2. Also pass run.actors into passive extraction so extraction behavior changes deterministically before model generation.
3. Derive passive extraction allowed kinds from run.actors.length:
   • single actor: preference | procedure | knowledge
   • multi actor: procedure | knowledge
4. Render the extraction prompt from the same allowed-kind set. In multi-actor runs, omit preference-specific kind and rule text, and add explicit guidance that passive extraction may return only conversation-scoped procedure or knowledge memories.
5. The multi-actor prompt branch should also prevent laundering personal preferences into another kind. Suggested rule text:

- This completed run has multiple run actors. Passive extraction may return only conversation-scoped procedure or knowledge memories.
- Do not return personal user preferences, opinions, habits, identity facts, or workflow preferences from any actor in this run.
- Do not convert a personal first-person statement into shared knowledge or procedure. Statements like "I prefer ...", "I use ...", "I always ...", or "I never ..." are not memory evidence in multi-actor passive extraction.
- Shared team, channel, repository, or operational norms are still eligible only when the source explicitly states them as collective practice or durable operational fact, not as one individual preference.

6. Keep the final routeExtractedMemory multi-actor preference drop anyway. It covers cached extraction results, older task state, malformed callers, or future schema drift.

Important nuance: do not remove personal preference instructions globally. Single-actor passive extraction and explicit memory review still need them. The change should be scoped to passive extraction when run.actors.length > 1.

Testing plan:

• Component test: multi-actor run plus preference proposal citing only run-actor instruction evidence results in no memory row.
• Positive control: existing single-actor preference extraction remains stored.
• Eval assertion: in the batched multi-actor case, assert no active kind === "preference" row exists for the thread at all, not merely that the preference was not written to the wrong actor.