frontend-patterns/research/evaluations/language-pilot-01/masked/S05-U.md

Here's a recommendation for the frontend architecture based on the scenario:

• Outcome/State: The system should transition to a state where revision c is the active local content, with pending operation Q awaiting remote acceptance. The late receipt for P should update its own operation history, marking P as remotely accepted, but it should not alter the active content or the status of Q.

• Preserved Information: Both divergent revisions a and b should be preserved with their identities and provenance until c is fully committed and resolved. The original pending operation P and its identity must also be retained, along with the new pending operation Q.

• Recovery Action and Rejected Alternative: Upon process restart, the system must recover c as the active content and Q as the pending operation. The late receipt for P should not trigger a re-application of P or a rollback to a, as this would erase the user's explicit resolution into c.

• Missing Contract or Clarification: The architecture needs a clear contract for the receiver's ancestry and precondition behavior. Specifically, it must define how the receiver handles an in-flight operation (P) when a superseding operation (Q derived from c) is subsequently sent, and how it would respond to P if b was already accepted.