frontend-patterns/research/evaluations/language-pilot-01/scenarios.json

[
  {
    "id": "S01",
    "title": "Late receipt and a newer draft",
    "brief": "A server-validated record editor submits operation A. Its request promise rejects, but an authenticated server event identifying A and its accepted revision arrives. The user has already typed draft B. A previously started replica read then returns a different opaque version; the replica consistency contract is unspecified. Explain the correct visible states and next actions.",
    "criteria": [
      {
        "id": "C1",
        "requirement": "Keep A accepted despite the rejected promise."
      },
      {
        "id": "C2",
        "requirement": "Preserve draft B; receipt for A cannot clear it."
      },
      {
        "id": "R",
        "requirement": "Do not replace current data based on opaque-version ordering or equate acceptance with freshness; mark freshness unresolved or gate stale reads."
      },
      {
        "id": "Q",
        "requirement": "Identify the missing read-after-write/server ordering contract before asserting freshness."
      }
    ],
    "prohibited": [
      "Treat the rejected promise as proof A failed.",
      "Erase B because A completed.",
      "Numerically or lexically order opaque versions as proof of freshness."
    ]
  },
  {
    "id": "S02",
    "title": "Retry after losing operation identity",
    "brief": "A mobile message composer queued an immutable payload and sent it. The response was lost. After logout, reinstall and login as a new device, only the payload remains; the original operation ID is lost. The server deduplication scope is device and endpoint. Lookup support and retention are unspecified. The product suggests generating a fresh ID and automatically retrying. Evaluate that suggestion and give a recovery plan.",
    "criteria": [
      {
        "id": "C1",
        "requirement": "Outcome remains unknown; same payload does not establish rejection or identity."
      },
      {
        "id": "C2",
        "requirement": "A fresh ID/new device cannot be claimed duplicate-safe; do not automatically resend as recovery."
      },
      {
        "id": "R",
        "requirement": "Preserve the payload separately and resolve/check the old outcome before a new send, or require an explicit informed reconciliation decision."
      },
      {
        "id": "Q",
        "requirement": "Ask about operation/history lookup and retention or recoverability of the old device/operation identity."
      }
    ],
    "prohibited": [
      "Claim identical content guarantees idempotency across devices.",
      "Promise automatic fresh-ID retry cannot duplicate."
    ]
  },
  {
    "id": "S03",
    "title": "Revoked access during offline work",
    "brief": "An offline field editor has a completed local commit of confidential notes and a pending upload. On reconnect, the server explicitly denies write authorization. The product requirement only says \"never lose edits\"; it says nothing about whether revoked users may retain, view or export local copies. Design the next states and recovery behavior without inventing an access policy.",
    "criteria": [
      {
        "id": "C1",
        "requirement": "Distinguish saved locally from uploaded/accepted remotely."
      },
      {
        "id": "C2",
        "requirement": "Block unauthorized synchronization and do not bypass revocation or endlessly retry unchanged credentials."
      },
      {
        "id": "R",
        "requirement": "Make recovery conditional on authorized access/policy; do not promise unconditional export, permanent retention or silent destructive deletion."
      },
      {
        "id": "Q",
        "requirement": "Explicitly request the policy for retaining, viewing or deleting/exporting confidential copies after revocation."
      }
    ],
    "prohibited": [
      "Assert never-lose-edits authorizes export despite revocation.",
      "Unconditionally wipe or retain all confidential content as if policy were known."
    ]
  },
  {
    "id": "S04",
    "title": "Local cancellation after uncertain booking",
    "brief": "A server-confirmed booking UI times out after submitting operation K. Before receiving authoritative evidence, the user presses Cancel; the client removes its pending entry. The user then asks to submit the same booking again. The server exposes no documented operation-status lookup or deduplication retention guarantee. Specify what Cancel can honestly mean and whether a new submission is safe.",
    "criteria": [
      {
        "id": "C1",
        "requirement": "Local cancellation does not establish remote cancellation or rejection of K."
      },
      {
        "id": "C2",
        "requirement": "Do not claim a new submission is duplicate-safe while K is unresolved."
      },
      {
        "id": "R",
        "requirement": "Use an authoritative reconciliation/escalation path before replacement; remote reversal is a separate authorized action if K was accepted."
      },
      {
        "id": "Q",
        "requirement": "Ask about cancellation, lookup/history and retry-retention contracts needed to resolve K."
      }
    ],
    "prohibited": [
      "Tell the user the booking was undone by removing local state.",
      "Automatically use a new ID and promise no duplicate booking."
    ]
  },
  {
    "id": "S05",
    "title": "An old upload survives conflict resolution",
    "brief": "Device A durably recorded offline revision a with pending operation P. Another device uploaded divergent revision b. A preserves both and resolves them into revision c with new pending operation Q. P was already in flight. Later a receipt for P arrives. Local commits survive process restart, but receiver ancestry/precondition behavior is unspecified. Specify queue transitions, crash boundaries and what the late receipt may change.",
    "criteria": [
      {
        "id": "C1",
        "requirement": "Block/supersede P atomically with the resolved revision and Q; maintain restart-safe pending intent."
      },
      {
        "id": "C2",
        "requirement": "A receipt for P updates P history only, not Q status or the active resolved revision."
      },
      {
        "id": "R",
        "requirement": "Do not assume local queue retirement stops an in-flight P; require receiver preconditions/ancestry to protect c."
      },
      {
        "id": "Q",
        "requirement": "Explicitly identify receiver ancestry/version handling as a missing contract requiring verification."
      }
    ],
    "prohibited": [
      "Mark Q synchronized because P was acknowledged.",
      "Guarantee local cancellation prevents P from overwriting remotely."
    ]
  },
  {
    "id": "S06",
    "title": "Storage guarantee beyond the evidence",
    "brief": "A field-note product promises edits survive device loss and complete power failure. The chosen local transaction has only been tested against ordinary process restart. Two copies of a conflict are stored on the same device, and the sync protocol propagates deletions. The team proposes declaring recovery solved and removing conflict review from the keyboard interface. Assess that design and state what can actually be promised.",
    "criteria": [
      {
        "id": "C1",
        "requirement": "Ordinary restart evidence cannot establish power-loss or device-loss survival."
      },
      {
        "id": "C2",
        "requirement": "Copies on one device and deletion-propagating sync are not independent backup."
      },
      {
        "id": "R",
        "requirement": "Retain accessible discoverable comparison/resolution; storing conflict copies alone does not resolve intent."
      },
      {
        "id": "Q",
        "requirement": "Request storage flush/power-loss evidence and an independently recoverable backup/restore contract."
      }
    ],
    "prohibited": [
      "Claim local transaction or same-device copies guarantee device-loss recovery.",
      "Treat synchronization as sufficient independent backup.",
      "Approve inaccessible conflict review because bytes are preserved."
    ]
  }
]