A user-scoped memory read or write without a real user refuses
A memory bucket keyed by identity is only meaningful when there is an identity. Degrading to a shared bucket is how one caller's conversation ends up in another's history, so the scope refuses instead.
The rule
- Resolving the
usermemory scope refuses whenever the execution context is absent, carries no user identifier, carries one that is not a usable identifier, or carries the identifier that denotes no user. - A refusal is distinct from resolving to an empty scope identifier: an empty identifier selects the shared global bucket, so a
userscope that degraded would merge every identity-less execution path into one bucket and every anonymous caller into another. - Scopes that are not identity scopes continue to resolve to the empty identifier.
What it means
A refusal is not the same outcome as resolving to an empty scope identifier.
The empty identifier is a legitimate answer for scopes that are not tied to
an identity — it selects one shared bucket, and every caller in that shape
of execution shares it on purpose. The user scope cannot degrade to that
same empty identifier when it has no usable identity, because doing so would
merge every identity-less execution path into the one shared bucket, and
every anonymous caller into another single bucket alongside every other
anonymous caller. So it refuses instead of resolving.
The identifier 0 — the value an owner-less record reports for "no owner",
not the absence of a value — refuses for the same reason, in both its integer
and string spelling: accepting it would put every anonymous caller in one
user:0 bucket.
Example
{ "user_id": 0 }{ "user_id": "0" }{ "user_id": "7" }