Memory policy is the only governance setting that isn't per-scope

[ianTPE]

Memory policy is the one governance setting that doesn't resolve per scope.

admin-resources.ts exposes ambient-policy, egress, security-posture,
command-policy, approval-grant-modes, soul, runtime and the rest as scope-keyed
resources — 21 of the 23 take a scope argument, and the Governance page renders
them for whichever scope you're on. Memory isn't among them. memoryPolicy is
built once in wiring.ts from MEMORY_CAPTURE / MEMORY_RECALL in config.ts,
and the orchestrator reads deps.memoryPolicy ?? DEFAULT_MEMORY_POLICY with no
scope in the lookup. So it's the whole deployment or nothing.

The case I ran into thinking about it: a channel where HR discusses a specific
employee. I'd want capture off in that one channel and unchanged everywhere
else. Today the only lever is not inviting the bot — which is probably the right
answer for that particular channel anyway, but it means there is no middle
setting for "the agent may take part and must not remember."

The org-memory path is what makes it sharp rather than cosmetic. Every scope
mounts the org scope as a read-only layer, and with recall at its default
(visible) that layer is read in every scope, including the subject's own DM.
An org admin's turn is granted orgWrite to it — that grant is decided by
actorIsOrgAdmin, so it's identity, not model behaviour. What model behaviour
decides is what gets written there, and there's no scope-level guardrail on
that at all. Nothing has written to org: in two weeks of use here, so this is
a shape I'm reporting rather than an incident.

Memory seems like the setting most worth having per scope, given it's the one
that travels between conversations.