Version. 0.2 (corrects v0.1's mechanism section — see below)
Date. 2026-07-05
Status. Built, merged, pushed. Engine main @ 5e9c857 (unchanged), OL main @ 2a320fd.
Repos. loomworks (frontend-only — see correction).
v0.1 assumed this required net-new backend work (a data-level mechanism to design at Step-0). Step-0 investigation found the engine already had a complete, shipped mechanism — redirect_assertion (Phase 17 §6), built earlier for an unrelated original purpose — that does exactly what this CR asked for: retracts the held source assertion with a rationale, creates a held copy in the target with back-pointer metadata, enforces held-only and same-engagement rejection, and even handles file-copy for uploaded assertions. 9/9 tests already passing before this CR touched it. The actual build was frontend-only: wiring the UI to the existing endpoint. v0.1's proposed mechanism (retract-in-source + create-in-target as a new composition) was the right shape — it just turned out to already exist.
A Memory-list entry sometimes belongs to a different engagement than the one it was captured in. Added a "Move to..." action on held Memory-list cards.
redirectAssertion() API client wiring to the existing /redirect endpoint.EngagementPickerDialog component — searchable, type-to-filter (no such component existed in the codebase before this).
Scripted HTTP/DB verification (the Chrome browser extension was unavailable both times this was attempted): captured a held assertion, moved it via the real /redirect endpoint between two synthetic engagements, confirmed the target received it (correctly attributed to the human, not the Companion — matching Operator-authority's "propose as Companion, act as human" split), confirmed the source emptied, confirmed the retraction event recorded a walkable rationale. Confirmed the hide-when-solo-engagement gate via a real membership check. Not verified: an actual rendered browser click-through of the picker itself (search, filter, click) — that remains covered only by mocked component tests, flagged as a gap, not claimed as done.
Retracted assertions are recorded correctly on the backend (event + rationale) but have no frontend surface — the Memory room only renders held and settled sections. An Operator cannot currently see that a note was moved, or why, without a direct DB/API query. This was not in this CR's stated scope; filed as its own finding.
No conflict. Operator-authority is satisfied (move requires human action, target attribution correctly switches to the human). "Corrections preserved, not smoothed" is satisfied on the backend (the retraction is walkable) but not yet visible to the Operator — see the recorded gap above.