frontend-patterns/research/evaluations/language-replication-02/scenarios.json

[
  {
    "id": "R02-S01",
    "title": "Support ticket attachments after access withdrawal",
    "brief": "A help-desk agent edits a confidential incident ticket offline. The application acknowledged a local save of the text and attachments. On reconnect, the authority explicitly rejects upload because the agent lost access. A teammate suggests leaving the editor open forever and exporting a recovery archive. The only stated product rule is that rejected edits should be recoverable; there is no rule about local viewing, retention, export or deletion after access withdrawal. Recommend the next states and actions.",
    "criteria": [
      {
        "id": "A1",
        "requirement": "Distinguish the acknowledged local save from explicitly denied remote upload."
      },
      {
        "id": "A2",
        "requirement": "Stop the unauthorized upload instead of retrying it as an unchanged permitted operation."
      },
      {
        "id": "A3",
        "requirement": "Identify the missing local retention policy after access withdrawal."
      },
      {
        "id": "A4",
        "requirement": "Make continued local viewing conditional on its access policy rather than promise it unconditionally."
      },
      {
        "id": "A5",
        "requirement": "Make exporting the attachment archive conditional on separate export permission."
      },
      {
        "id": "A6",
        "requirement": "Avoid unconditional destructive deletion while its policy is unspecified."
      }
    ],
    "prohibited": [
      "Unconditionally retain or export confidential content after access withdrawal.",
      "Treat upload denial as evidence the local save never happened.",
      "Silently wipe the saved work without the required policy."
    ]
  },
  {
    "id": "R02-S02",
    "title": "Accepted order and an uncertain reversal",
    "brief": "An order editor has an authenticated receipt that order submission A was accepted. The user has since typed an unsubmitted replacement B. Clicking Stop hides the spinner and cancels the browser wait. The user then requests reversal C through a separate endpoint; its response is lost. The service has not documented C's lookup, replay scope, retention or authorization semantics. Explain the statuses and recovery choices without inventing a successful reversal.",
    "criteria": [
      {
        "id": "A1",
        "requirement": "Keep submission A accepted on the strength of its matching authenticated receipt."
      },
      {
        "id": "A2",
        "requirement": "Preserve replacement draft B independently of A and C."
      },
      {
        "id": "A3",
        "requirement": "Do not treat cancelling the local browser wait as undoing A."
      },
      {
        "id": "A4",
        "requirement": "Recognize that reversal C has its own authorization preconditions."
      },
      {
        "id": "A5",
        "requirement": "Keep C's result unknown after the response is lost."
      },
      {
        "id": "A6",
        "requirement": "Identify C's missing lookup or bounded replay contract before asserting a safe retry."
      }
    ],
    "prohibited": [
      "Claim Stop undid accepted A.",
      "Report C as successful solely because the user requested reversal.",
      "Resubmit B or C automatically with a fresh identity as guaranteed recovery."
    ]
  },
  {
    "id": "R02-S03",
    "title": "Reconciliation committed in a split queue transaction",
    "brief": "A mobile checklist has pending upload P for revision a. Another device supplies incompatible revision b. A user compares both and records chosen revision c. The implementation saves c and queues new operation Q in one transaction, but marks P non-retryable in a later transaction. A process can die between the transactions, and an already transmitted P may still complete. The receiver's version/ancestry enforcement is undocumented. Specify the minimal correction and receipt handling.",
    "criteria": [
      {
        "id": "A1",
        "requirement": "Include P's superseded/non-retryable status in the same recoverable commit as c and Q."
      },
      {
        "id": "A2",
        "requirement": "Do not acknowledge the resolution before the required combined commit succeeds."
      },
      {
        "id": "A3",
        "requirement": "Retain the identities and provenance of the compared inputs for the resolution."
      },
      {
        "id": "A4",
        "requirement": "Do not claim local retirement of P recalls its already transmitted request."
      },
      {
        "id": "A5",
        "requirement": "Identify the missing receiver version/ancestry contract before claiming the stale write cannot apply."
      },
      {
        "id": "A6",
        "requirement": "Apply a late receipt for P only to P's history rather than clearing Q or replacing c."
      }
    ],
    "prohibited": [
      "Call the two local transactions atomic together.",
      "Declare P cancelled remotely because the local flag changed.",
      "Clear Q when P later acknowledges."
    ]
  },
  {
    "id": "R02-S04",
    "title": "Snapshots, an off-device archive and missing restore proof",
    "brief": "An offline drawing tool reports that a scene and pending upload queue survived one ordinary process restart. It also keeps a scene snapshot and conflict copy on the same laptop. The laptop may be destroyed. A scheduled off-device archive exists, but its last successful contents, key availability, deletion retention and restoration of pending operation identities have never been checked. The team asks whether synchronization plus these copies guarantees device-loss recovery.",
    "criteria": [
      {
        "id": "A1",
        "requirement": "Distinguish the observed process-restart result from device-loss recovery."
      },
      {
        "id": "A2",
        "requirement": "Do not treat the copies on the same laptop as independent device-loss protection."
      },
      {
        "id": "A3",
        "requirement": "Do not claim that synchronization by itself is a separately recoverable backup."
      },
      {
        "id": "A4",
        "requirement": "Keep device-loss recovery unverified rather than declare it guaranteed or impossible."
      },
      {
        "id": "A5",
        "requirement": "Identify the missing restore-key availability contract for the independent archive."
      },
      {
        "id": "A6",
        "requirement": "Require a clean-store restore test of the saved pending operation identities before promising resume safety."
      }
    ],
    "prohibited": [
      "Guarantee recovery because sync and two local copies exist.",
      "Declare recovery impossible merely because the archive was not tested.",
      "Automatically replay restored work with new identities."
    ]
  },
  {
    "id": "R02-S05",
    "title": "Lookup absence after a bounded receipt expires",
    "brief": "A report editor retains the original payload and operation identity K after an upload response was lost. The receiver guarantees deduplication for K only for 16 hours. Twenty-five hours later, lookup returns no record, but the service does not say whether no record means never accepted or expired history. The editor can resend K or create a fresh identity. The user asks for a duplicate-free automatic recovery plan.",
    "criteria": [
      {
        "id": "A1",
        "requirement": "Keep the old operation's acceptance unknown despite the ambiguous lookup absence."
      },
      {
        "id": "A2",
        "requirement": "Recognize that the documented 16-hour deduplication guarantee no longer covers this replay."
      },
      {
        "id": "A3",
        "requirement": "Do not promise a duplicate-free resend of K outside that retention guarantee."
      },
      {
        "id": "A4",
        "requirement": "Do not claim a fresh identity makes the same logical submission duplicate-safe."
      },
      {
        "id": "A5",
        "requirement": "Retain the original payload and identity for reconciliation."
      },
      {
        "id": "A6",
        "requirement": "Identify the missing meaning of lookup absence after receipt history expires."
      }
    ],
    "prohibited": [
      "Equate absent expired lookup history with explicit rejection.",
      "Guarantee a safe replay using either K or a new identity after the window."
    ]
  },
  {
    "id": "R02-S06",
    "title": "Accepted import with incomplete projection and a newer edit",
    "brief": "A project board receives an authenticated operation-specific receipt that batch import I was accepted. Refreshing the visible cards fails. The user is already editing a new card draft D. A background cache read later returns different opaque version labels; no ordering or read-after-write contract is supplied. A teammate proposes rerunning I and replacing the editor from that cache. Recommend the correct recovery boundaries.",
    "criteria": [
      {
        "id": "A1",
        "requirement": "Keep import I accepted despite the failed view refresh."
      },
      {
        "id": "A2",
        "requirement": "Distinguish accepted operation state from unresolved view freshness."
      },
      {
        "id": "A3",
        "requirement": "Preserve the newer draft D when observations refresh."
      },
      {
        "id": "A4",
        "requirement": "Do not rerun the accepted import solely to repair its failed projection refresh."
      },
      {
        "id": "A5",
        "requirement": "Do not infer currentness by sorting or comparing opaque version labels."
      },
      {
        "id": "A6",
        "requirement": "Identify the missing read-after-write or server-ordering contract before asserting fresh cards."
      }
    ],
    "prohibited": [
      "Retry the import because the view failed.",
      "Discard D on receipt or cache completion.",
      "Order opaque labels as proof the cache is fresh."
    ]
  }
]