Use this two-issue negotiation game to compare four packages, explain the blocking constraints, and retain acceptance as a separate decision. The HTML checker starts with no proposal and calculates feasibility only after both issues are selected.
Use an original two-role workshop scenario
This fictional activity has two issues: workshop time and setup. Time can be Tuesday or Wednesday. Setup can be Basic or Extended.
Use these independently authored role briefs:
| Role | Hard constraint | Preference |
|---|---|---|
| A | Can attend only Tuesday | Prefers Extended setup |
| B | Can provide only Basic setup; can attend Tuesday or Wednesday | Prefers Wednesday |
A preference is not a hard constraint in this fixture. A's Extended preference does not automatically forbid Basic. B's Wednesday preference does not eliminate Tuesday.
The labels Basic and Extended are scenario choices, not priced equipment packages or promises about real classroom facilities. There is no real calendar reservation.
Enumerate the four packages before checking an offer
The teacher's Version V1 feasibility key is:
| Package | A's Tuesday constraint | B's Basic constraint | Hard-constraint outcome |
|---|---|---|---|
| Tuesday + Basic | Met | Met | Feasible |
| Tuesday + Extended | Met | Not met | Violates B's setup constraint |
| Wednesday + Basic | Not met | Met | Violates A's time constraint |
| Wednesday + Extended | Not met | Not met | Violates both |
Tuesday + Basic is the only package satisfying both supplied hard constraints. It gives neither role its stated preference, but preference satisfaction is a separate question.
Do not assign a numerical value to those preferences. The role briefs provide no utility points, price, penalty, or rule that either preference must outweigh the other. “Feasible” is the supported conclusion; “best,” “fair,” and “accepted” need additional criteria or actual responses.
Keep the teacher key separate from role packets if the teacher wants learners to discover the combinations through discussion.
Let a proposal start the exchange
Use an explicitly illustrative first offer O1: Tuesday + Extended. It meets A's time constraint and A's preference. It violates B's available setup.
An anticipated B explanation is “My role can provide Basic setup only.” That is a teacher discussion example, not a student statement already observed.
The team can revise to illustrative offer O2: Tuesday + Basic. A useful exchange asks whether that package addresses each role's constraint and what concerns remain. It does not ask the checker to accept on anyone's behalf.
Keep the learner's offer, explanation, and acceptance fields blank until the discussion begins. A teacher demonstration can show the O1/O2 sequence, but it should be labeled as prepared example records.
A quiet learner, an empty response cell, or a feasible package does not establish assent.
Maintain three different kinds of status
An offer ledger should include role-brief version, offer ID, both issue values, proposer, reason, hard-constraint result, A response, B response, and review status.
Keep these distinctions:
- Proposed: Someone has put forward the named package.
- Feasible under the supplied version: Its two issue values meet both hard constraints.
- Accepted by both: Both roles explicitly accepted that same unchanged offer under the same version.
The illustrative Tuesday + Basic package can be “Feasible; acceptance unknown.” Leave both actual response fields blank until a response is made. If one accepts and the other does not, retain both outcomes without converting the pair into agreement.
Changing a package requires checking its new values and obtaining responses to that offer. An earlier acceptance of Tuesday + Basic is not acceptance of Tuesday + Extended.
The game checks the role constraints; the teacher facilitates interpretation and discussion. It cannot judge an arbitrary explanation automatically or turn a classroom response into a real legal deal.
Change one role brief and keep the history
For V2, change B's hard setup constraint to Extended only. Keep B's Wednesday preference and Tuesday availability, and keep A's brief unchanged.
The feasible package is now Tuesday + Extended. The old Tuesday + Basic conclusion belongs to V1 and fails V2's setup constraint.
Keep O1 and O2 in their historical V1 rows. Add a version-change review flag rather than overwriting their original results. The learner can propose a new V2 offer, but its actual responses remain blank.
Try the worked example
Choose Tuesday and Extended under V1, then check: B cannot provide that setup. Change only the setup to Basic and check again; the package now meets both hard constraints, while acceptance remains unknown. Switch to V2, select Tuesday and Basic again, and press Check package to see Basic fail when B can provide Extended only. Write each revised offer as a new row in the classroom ledger. A feasible proposal still needs two explicit responses.
This is an all-role review copy and local constraint checker, not private role distribution, a reservation, or an agreement recorder.
Recreate this example
Build one complete self-contained HTML page for this task: let a teacher and learners test a two-role, two-issue workshop package without inventing agreement.
Use these exact original practice data and worked expectations: V1: A attends Tuesday only and prefers Extended; B supplies Basic only, attends either day, and prefers Wednesday. V2 changes B to Extended only. Issues: Tuesday/Wednesday and Basic/Extended. Only Tuesday+Basic is feasible in V1; only Tuesday+Extended in V2.
Implement the following useful local interactions: Provide version, time, and setup as labeled button choices with visible current selection. Check both constraints, distinguish missing selections, and keep acceptance unknown. Version changes clear package selections. Reset clears the current proposal. Preserve the supplied source text and distinguish an uncomputed state, a successful local result, and an invalid or incomplete input. Update output only from the current input snapshot. An input edit must retire stale feedback until the reader runs the relevant action again. Do not silently invent missing values or replace a failing case with a success.
Design the page as a green and cream classroom negotiation board with side-by-side role briefs and an offer slip. Put a compact task heading, actual sample data, the main result, and usable controls early enough to be useful on a narrow screen. Use readable text of at least 16px, generous paragraph spacing, strong contrast, native labels, accessible buttons, and visible keyboard focus. Stack long records at 360px and wrap code without page-level horizontal overflow.
Use type=button and explicit querySelector-based click handlers rather than relying on form submission. If Enter is useful, handle it only on the relevant input and ignore isComposing. Keep effects within this open page; no remote dependencies, network calls, persistence, fake downloads, or automated sending. This is an all-role review copy and local constraint checker, not private role distribution, a reservation, or an agreement recorder. Place worked explanations beside their data and identify teacher or synthetic examples clearly. Output only the complete HTML document, with inline styles and script and LF line endings.
Review the role briefs in NOS
Before the debrief, prepare separate role packets if learners should not see each other’s brief. An optional all-role HTML copy in NOS can display the constraint comparison; revise eligible static role instructions in visual editing mode when the next round changes the scenario.