Impact
The private-claim API can create a claim but cannot discover or explain that same claim through its default list and detail routes. This prevents a user from reliably inspecting or managing private memories after creation. The documented actor guidance is also inconsistent with the runtime actor identity.
Reproduction
On an isolated local server using the default actor:
- POST /api/v2/memory/claims with {"key":"private note","value":"secret-value","claim_type":"private_fact"}.
- The request returns HTTP 200 with status active and a memory_id.
- GET /api/v2/memory/claims returns an empty claims list.
- GET /api/v2/memory/claims/{memory_id} returns HTTP 404 Memory claim not found.
- Adding speaker=local to both GET requests makes the claim visible.
The same behavior was observed through the real FastAPI route path during the post-merge runtime audit. The workaround depends on knowing the deployment actor and manually adding it to every read request, but the create route assigns that actor automatically and the endpoint table does not explain this requirement. A client following docs/self-evolution.md:157-162 may use loopback or authenticated as the speaker label, while the current runtime uses KYROZEN_SERVER_ACTOR and defaults to local.
Likely cause
server.py:659-670 and 696-707 pass an optional speaker into memory_bank.filter_records. memory.py:268-270 intentionally hides a private claim unless claim_speaker equals the supplied speaker and is authorized. The create route normalizes private claims to the server actor, but the list and detail routes do not default speaker to that actor.
Acceptance criteria
- Define one consistent actor-resolution rule for private claim list, explain, and forget operations.
- Ensure the owner can create, list, explain, and forget a private claim without an undocumented manual query parameter, while another actor cannot read it.
- Update docs/self-evolution.md and the README examples to use the configured KYROZEN_SERVER_ACTOR consistently and show the complete lifecycle.
- Add regression tests for default-actor access, configured actor access, and rejection of a different speaker.
Impact
The private-claim API can create a claim but cannot discover or explain that same claim through its default list and detail routes. This prevents a user from reliably inspecting or managing private memories after creation. The documented actor guidance is also inconsistent with the runtime actor identity.
Reproduction
On an isolated local server using the default actor:
The same behavior was observed through the real FastAPI route path during the post-merge runtime audit. The workaround depends on knowing the deployment actor and manually adding it to every read request, but the create route assigns that actor automatically and the endpoint table does not explain this requirement. A client following docs/self-evolution.md:157-162 may use loopback or authenticated as the speaker label, while the current runtime uses KYROZEN_SERVER_ACTOR and defaults to local.
Likely cause
server.py:659-670 and 696-707 pass an optional speaker into memory_bank.filter_records. memory.py:268-270 intentionally hides a private claim unless claim_speaker equals the supplied speaker and is authorized. The create route normalizes private claims to the server actor, but the list and detail routes do not default speaker to that actor.
Acceptance criteria