Memory lifecycle hardening: wire-boundary attribution trust and undo semantics

[jhrozek]

Post-merge hardening follow-up to ADR 0107's operator-profile memory lifecycle,
driven by ADR 0226 and its
acceptance plan. Six scenarios,
four independent threads.

The main thread: attribution could switch off a security scan

tool.MemoryAttribution is documented as inert — "stores must never derive
authorization from context attribution" — but one line in
ValidateMemoryContentWrite reads Writer/Origin to decide whether the
instruction-injection scan runs on a user/-scoped write. That gate is
deliberate and worth keeping: a human deliberately storing instruction-shaped
text is legitimate; a model autonomously persisting it is the attack shape
automatic learning produces from a poisoned tool result.

The problem was who fills the field in. Over the gRPC memory driver the request
supplied it and the server threaded it in verbatim, so a peer could set
Writer="user" — or send no attribution at all, which the legacy
RememberEntry handler already did — and the scan silently did not run.

Fix: a new MemoryAttribution.ForceInstructionScan bit that feeds exactly
one expression (the scan gate) and nothing else. Persisted Writer/Origin/
Source still report what the caller claimed — overwriting them would corrupt
the durable provenance of every legitimate wire write to fix a scan.

Applied to all three RPCs whose request carries a MemoryEntry the stores will
scan: RememberEntry, RememberVersioned, and RememberIfCurrent. The
third is easy to miss — it reads as a convergence CAS, not a lifecycle write —
but it runs the same ValidateMemoryEntryWrite as its siblings. Asserted as a
table over the write RPCs so a fourth cannot silently escape the gate.

withForcedMemoryWriteAttribution delegates to withProtoAttribution and flips
one bit rather than rebuilding the struct, so the two cannot drift on a future
MemorySource field.

Three smaller threads

• Undo. UndoLatest filtered its target selection but read its restore
  source unfiltered — same intent, different predicate, so a redo was
  reachable. Both walks now share undoCandidate, and the contract (no redo;
  repeated undo walks strictly backward through revisions never yet undone) is
  stated on MemoryLifecycleStore rather than left implicit. The horizon guard
  stays keyed on target == 0 deliberately; the comment explains why keying it
  on the walk result is wrong.
• Truncation. MemoryRecord.Truncated / wire history_truncated let
  Inspect distinguish a retained tail from complete history, instead of it
  surfacing later as a confusing undo failure. max_revisions sets the flag too.
• Operator profile. childOperatorProfileSource was a deny-list that failed
  open — an unrecognised role got the operator's durable user facts.
  Inverted to an allow-list. Verified behaviour-preserving across all 19 role
  strings the codebase constructs, including the per-call model-override and
  agent-def roles. The six model-facing lifecycle tools were also missing from
  the caller-ownership classification table; added.

Deliberately not done

Recorded in the plan's Deferred decisions rather than left as gaps:

• Consolidating the two injection phrase lists. Looks like free hygiene; it
  is not. DirectiveShapedUserMemory is also the operator-profile RENDER
  filter, applied unconditionally every turn, so widening it does not merely
  reject new writes — it silently drops already-stored facts from the prompt,
  with no error and no entry in the profile's own omitted count.
• Raising Undo*'s permission floor. Remember* is equally floor-Allow, so
  gating Undo alone closes nothing. The property worth having needs write gating
  on tombstone state generally.
• The render sinks disagree about the directive-shape filter
  (operatorprofile.go applies it, memoryindex.go and usermodel.go do not).
  Pre-existing, out of scope, newly written down — and the reason the write-time
  gate is load-bearing rather than redundant with the render layer.

The wire fix has an honest cost, stated in the ADR: a legitimate remote driver
deployment permanently loses the ability to write human-authored,
instruction-shaped preferences. Present-day reach is nil — nothing in-tree
registers MemoryStoreServiceServer in production.

Verification

task lint clean (0 issues × 7 modules), task api:check ok, docs/lint ok,
go run ./cmd/mecademo ok.

task test exits 201 on 7 failures in cmd/mecatui (6, learning-settings) and
internal/adapter/skills (1). All 7 reproduce identically on a detached
origin/main worktree — they are the macOS /var-symlink $TMPDIR issue, not
this branch. Expected green on Linux CI.

🤖 Generated with Claude Code