By-ID feedback target validation is namespace-scoped, contradicting ADR-007 Rev 6

[ohdearquant]

ADR-007 Rev 6 states by-ID operations (get, update, delete, merge) are namespace-agnostic: namespace is attribution, not isolation, and authorization lives at the Gate.

Two paths still apply namespace scoping to exact-ID lookups:

1. brain.auto_feedback target validation: passing a full canonical UUID for a record whose namespace differs from the caller default fails with not found: target_id <uuid> not found in namespace 'local'. Reproduced against a memory note with namespace = <non-local>, deleted_at IS NULL — the row exists and is recallable, but cannot be credited.

2. Short-prefix resolution behind get/link and the feedback verbs inherits the multi-record default WHERE namespace='local' scan, so a prefix that uniquely identifies a record in another namespace reports no match.

Consequence: cross-namespace recall results structurally cannot receive feedback, so recall posteriors for profiles serving cross-namespace content never train.

Proposed fix:

• Make the exact-ID validation in the feedback path resolve by ID only (no namespace predicate), consistent with the other by-ID verbs.
• Route short-prefix resolution through the same namespace-agnostic candidate scan (prefix uniqueness should be evaluated across namespaces; ambiguity remains an error).
• Audit brain.feedback and memory.feedback for the same scoped-lookup pattern; if they share a helper, fix at the helper.

Tests should cover: full-UUID feedback on a record in a non-default namespace succeeds; prefix resolution finds a unique cross-namespace record; ambiguous prefix across namespaces errors.

[ohdearquant]

Additional datapoint narrowing the boundary: brain.auto_feedback against a target whose row is stamped namespace='local' succeeds even with a short-prefix id. The failure is therefore precisely rows stamped with a non-local namespace — independent of whether the caller passes a short prefix or the full canonical UUID. This confirms the namespace filter sits inside auto_feedback's target validation itself, not in prefix resolution.

[ohdearquant]

Related datapoint: served_by_profile_id profile-resolution failure (distinct leg, same family)

Field report (not yet minimally reproduced — see note): a brain.auto_feedback(served_by_profile_id="implementer-recall-v1", …) call returned profile not found even though:

• the profile implementer-recall-v1 exists (verified via brain.profiles(): active, 0 events), and
• the agent:implementer binding exists (verified via brain.bindings(): priority 10).

A different caller's call in the same window (served_by_profile_id="leo-recall-v1") succeeded (total_events incremented). So resolution of served_by_profile_id appears to fail for some caller/profile combinations despite the named profile existing.

This is a distinct code path from the original finding in this issue (which is auto_feedback target-ID validation rejecting namespace-stamped rows, an ADR-007 Rev 6 by-ID violation). This new leg is on the profile-resolution path — looking up the profile named by served_by_profile_id — not the target-record path. It smells like the same scoped-lookup family surfacing on a second seam.

Note on evidence discipline: deliberately not running a synthetic cross-actor repro, to avoid polluting the fresh role-profile event ledger currently under observation. Documenting as a field datapoint to fold into the resolver-fix scope; a clean repro will be constructed in an isolated profile/namespace when the fix work starts. Exact error string observed: profile not found; window ≈ 2026-07-02 01:00–01:15 UTC.

[ohdearquant]

Root-cause recon (confirmed in source — lambda:khive + lambda:leo)

Three distinct legs surfaced, differing in root cause and fix locus. The original body describes leg C only.

Leg A — profile-registry per-session staleness (NOT a namespace issue)

kkernel mcp serving processes are per-session and long-lived; the --daemon bounce does not restart them (evidence: 5 long-lived kkernel mcp --db processes from 15:00–16:00 EDT still serving; a byte-identical retry at 01:32 UTC post-bounce reproduced the same error).

• ensure_loaded (persist.rs:450) loads snapshot+events into in-process state.profiles once per namespace, gated by is_loaded/mark_loaded (persist.rs:100/110). Subsequent ops skip the DB reload.
• create_profile (handlers.rs:1440) inserts into the creating process's state.profiles and persists, but never invalidates other long-lived processes.
• Consequence: a process that loaded a namespace before a profile was created serves a stale registry indefinitely.
• Serve-path miss: handle_feedback (handlers.rs:905-911) does state.profiles.get(effective_profile) → hard NotFound, no reload.

Fix: reload-on-miss (force a fresh namespace snapshot load bypassing is_loaded, re-lookup, NotFound only if still absent) — self-healing, no IPC. Alternative: refresh-on-create broadcast (needs cross-process IPC). Constraint: the reload must go through the ensure_loaded/dispatch_gate serialization (pack.rs:56-61), not a raw second load inside the handler, or it races the state lock.

This is a different root cause and fix locus from legs B/C — recommend splitting into its own issue.

Leg B — fresh-write invisible to auto_feedback target resolution

• Path: handle_feedback → resolve_auto_feedback_target (handlers.rs:1601) → resolve_prefix (operations.rs:2769).
• resolve_prefix is a direct SQL scan: SELECT id FROM {entities,notes,events,graph_edges} WHERE id LIKE ?1 AND namespace = ?2 AND deleted_at IS NULL LIMIT 2, ?2 = caller-token namespace. Committed rows are visible immediately → not index-warm latency.
• Open question: a memory written seconds earlier (35947ed1) fails while an older one (ccdb31f8) resolves, same caller. Since the scan is ns-scoped direct-SQL, either the two rows carry different namespace column values, or a per-session write/read connection split hides the fresh commit. Needs a live repro capturing the actual namespace column of both rows + the caller-token ns.

Leg C — exact-ID feedback validation is ns-scoped (original body)

• resolve_primary (called at handlers.rs:886) applies the same caller-namespace scoping to full-UUID lookups.
• Caveat that challenges the proposed fix: the handlers.rs:886 comment cites ADR-007:215-219 to justify ns-scoped validation for feedback specifically, on the grounds that feedback is a mutation and a visible-only (foreign) record must not be targeted by a mutation. ADR-007 Rev 6's ns-agnostic guarantee is stated for get/update/delete/merge; whether feedback (posterior mutation) belongs in that set or is deliberately excluded is an ADR-interpretation call, not a clear-cut bug. Read ADR-007:215-219 and reconcile before removing the predicate — the current "resolve by ID only, no namespace predicate" proposal contradicts the cited rationale.

Synthesis

Legs B and C share the caller-namespace-scoping principle across two seams (resolve_prefix for prefixes, resolve_primary for exact IDs) — the "one helper" intuition resolves to "one principle at two seams," not one function.

Status: recon only, no code (C(τ)≥0.3; the repro must be isolated to avoid polluting the live role-profile ledger).