Software Development English — COMPLETE AI PRACTICE PROMPTS Every block is a finished prompt. Copy one entire block between START PROMPT and END PROMPT into a new chat in your preferred AI. No prompt-writing is required. Use fictional or anonymized details when the exercise asks for your own response. Lesson 01 · Clarifying interface contracts | Build vocabulary and collocations START PROMPT TASK: Retrieve occupational vocabulary 1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation. 2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it. 3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment. 4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item. 5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 01: Clarifying interface contracts Original fictional case: A fictional profile interface accepts an optional nickname. Its current contract says an omitted nickname leaves the stored value unchanged, while an empty string clears it. A proposed client sends null. The meaning of null has not been specified. Client developer Maya and service developer Arun review the mismatch before either side implements a new interpretation. Optional describes whether the field may be absent; it does not settle what an explicit null means. Language workshop: Three nickname states, only two defined meanings Communication goal: Distinguish omission, an empty string, and null while requesting an explicit interface decision before implementation. Language guidance: Optional and nullable answer different questions. Optional concerns presence; nullable concerns allowed values. The stated contract defines omission and an empty string, but it does not authorize treating null as either one. Useful expressions (preserve the supplied facts): I want to confirm the profile interface contract. / An omitted nickname leaves the stored value unchanged. / An empty string clears the nickname. / The proposed client sends null. / The contract does not specify what null means. / Optional does not automatically mean nullable. / What should the stored value be after that input? / I would not infer this from another API. / Can we check the request payload? / If the field is absent, the current value stays. / Treating null as clear would be a new decision. / Can we agree on the intended behavior first? / Please record that rule in the contract. / We need a test for each defined input state. / The null case is still unresolved. / We agree on omission and empty string, but not yet on null. Vocabulary: interface contract: Agreed rules for inputs, outputs, and observable behavior. / application programming interface: Defined way software components communicate; abbreviated API. / request payload: Data carried by a request. / optional field: Field that may be absent under the contract. / nullable field: Field whose allowed values include null under the contract. / omitted field: Field not included in the submitted data. / empty string: Text value containing zero characters. / null value: Explicit marker whose meaning depends on the contract. / stored state: Value or condition currently retained by the system. / partial update: Change affecting only specified parts of a record. / default value: Value supplied when the governing rules call for one. / validation rule: Condition an input must satisfy. / serialization: Conversion of data into a transportable representation. / deserialization: Conversion from transported data into usable values. / schema: Formal description of data structure and constraints. / field presence: Whether a particular field exists in the input. / strong ETag: Representation validator compared strongly in an If-Match condition. / backward compatibility: Ability to preserve supported behavior for earlier consumers. / consumer: Component using another component's interface. / producer: Component providing data or behavior through an interface. / decimal arithmetic: Base-ten calculation with specified precision and rounding behavior. / contract test: Test checking agreed interactions across an interface boundary. / unspecified interface behavior: Input effect not defined by this interface contract. / acceptance criterion: Specific condition used to judge whether work meets requirements. Speaking task: Read Maya's three input examples, then read Arun's matching contract statements. Keep omission, empty string, and null distinct. Swap roles and repeat turns 9-16, stressing actual payload and agreed validation rule. Compare your readback with turns 19-20: two defined outcomes, one unresolved input, and no premature implementation approval. Partner: Maya: Client developer / Arun: Service developer Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the interface summary using only the stated contract and the unresolved proposal. Model for comparison AFTER my attempt, not a response to give me first: Maya: And I want the omission case protected. Solving the null question shouldn't silently turn an unchanged nickname into a cleared one for older clients. Arun: That is a backward compatibility concern worth recording. We have not demonstrated compatibility merely by agreeing that the new client looks correct. Maya: Then I'll report omission preserves, empty string clears, and null unresolved. My proposed null implementation stays pending until the interface decision. Arun: Good. That gives us an explicit acceptance criterion once the decision is made, instead of treating an ambiguous word as enough to approve the change. END REFERENCE END PROMPT Lesson 01 · Clarifying interface contracts | Practice grammar in context START PROMPT TASK: Choose grammar that preserves the meaning 1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness. 2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait. 3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay. 4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise. 5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 01: Clarifying interface contracts Original fictional case: A fictional profile interface accepts an optional nickname. Its current contract says an omitted nickname leaves the stored value unchanged, while an empty string clears it. A proposed client sends null. The meaning of null has not been specified. Client developer Maya and service developer Arun review the mismatch before either side implements a new interpretation. Optional describes whether the field may be absent; it does not settle what an explicit null means. Language workshop: Three nickname states, only two defined meanings Communication goal: Distinguish omission, an empty string, and null while requesting an explicit interface decision before implementation. Language guidance: Optional and nullable answer different questions. Optional concerns presence; nullable concerns allowed values. The stated contract defines omission and an empty string, but it does not authorize treating null as either one. Useful expressions (preserve the supplied facts): I want to confirm the profile interface contract. / An omitted nickname leaves the stored value unchanged. / An empty string clears the nickname. / The proposed client sends null. / The contract does not specify what null means. / Optional does not automatically mean nullable. / What should the stored value be after that input? / I would not infer this from another API. / Can we check the request payload? / If the field is absent, the current value stays. / Treating null as clear would be a new decision. / Can we agree on the intended behavior first? / Please record that rule in the contract. / We need a test for each defined input state. / The null case is still unresolved. / We agree on omission and empty string, but not yet on null. Vocabulary: interface contract: Agreed rules for inputs, outputs, and observable behavior. / application programming interface: Defined way software components communicate; abbreviated API. / request payload: Data carried by a request. / optional field: Field that may be absent under the contract. / nullable field: Field whose allowed values include null under the contract. / omitted field: Field not included in the submitted data. / empty string: Text value containing zero characters. / null value: Explicit marker whose meaning depends on the contract. / stored state: Value or condition currently retained by the system. / partial update: Change affecting only specified parts of a record. / default value: Value supplied when the governing rules call for one. / validation rule: Condition an input must satisfy. / serialization: Conversion of data into a transportable representation. / deserialization: Conversion from transported data into usable values. / schema: Formal description of data structure and constraints. / field presence: Whether a particular field exists in the input. / strong ETag: Representation validator compared strongly in an If-Match condition. / backward compatibility: Ability to preserve supported behavior for earlier consumers. / consumer: Component using another component's interface. / producer: Component providing data or behavior through an interface. / decimal arithmetic: Base-ten calculation with specified precision and rounding behavior. / contract test: Test checking agreed interactions across an interface boundary. / unspecified interface behavior: Input effect not defined by this interface contract. / acceptance criterion: Specific condition used to judge whether work meets requirements. Speaking task: Read Maya's three input examples, then read Arun's matching contract statements. Keep omission, empty string, and null distinct. Swap roles and repeat turns 9-16, stressing actual payload and agreed validation rule. Compare your readback with turns 19-20: two defined outcomes, one unresolved input, and no premature implementation approval. Partner: Maya: Client developer / Arun: Service developer Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the interface summary using only the stated contract and the unresolved proposal. Model for comparison AFTER my attempt, not a response to give me first: Maya: And I want the omission case protected. Solving the null question shouldn't silently turn an unchanged nickname into a cleared one for older clients. Arun: That is a backward compatibility concern worth recording. We have not demonstrated compatibility merely by agreeing that the new client looks correct. Maya: Then I'll report omission preserves, empty string clears, and null unresolved. My proposed null implementation stays pending until the interface decision. Arun: Good. That gives us an explicit acceptance criterion once the decision is made, instead of treating an ambiguous word as enough to approve the change. END REFERENCE END PROMPT Lesson 01 · Clarifying interface contracts | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 01: Clarifying interface contracts Original fictional case: A fictional profile interface accepts an optional nickname. Its current contract says an omitted nickname leaves the stored value unchanged, while an empty string clears it. A proposed client sends null. The meaning of null has not been specified. Client developer Maya and service developer Arun review the mismatch before either side implements a new interpretation. Optional describes whether the field may be absent; it does not settle what an explicit null means. Language workshop: Three nickname states, only two defined meanings Communication goal: Distinguish omission, an empty string, and null while requesting an explicit interface decision before implementation. Language guidance: Optional and nullable answer different questions. Optional concerns presence; nullable concerns allowed values. The stated contract defines omission and an empty string, but it does not authorize treating null as either one. Useful expressions (preserve the supplied facts): I want to confirm the profile interface contract. / An omitted nickname leaves the stored value unchanged. / An empty string clears the nickname. / The proposed client sends null. / The contract does not specify what null means. / Optional does not automatically mean nullable. / What should the stored value be after that input? / I would not infer this from another API. / Can we check the request payload? / If the field is absent, the current value stays. / Treating null as clear would be a new decision. / Can we agree on the intended behavior first? / Please record that rule in the contract. / We need a test for each defined input state. / The null case is still unresolved. / We agree on omission and empty string, but not yet on null. Vocabulary: interface contract: Agreed rules for inputs, outputs, and observable behavior. / application programming interface: Defined way software components communicate; abbreviated API. / request payload: Data carried by a request. / optional field: Field that may be absent under the contract. / nullable field: Field whose allowed values include null under the contract. / omitted field: Field not included in the submitted data. / empty string: Text value containing zero characters. / null value: Explicit marker whose meaning depends on the contract. / stored state: Value or condition currently retained by the system. / partial update: Change affecting only specified parts of a record. / default value: Value supplied when the governing rules call for one. / validation rule: Condition an input must satisfy. / serialization: Conversion of data into a transportable representation. / deserialization: Conversion from transported data into usable values. / schema: Formal description of data structure and constraints. / field presence: Whether a particular field exists in the input. / strong ETag: Representation validator compared strongly in an If-Match condition. / backward compatibility: Ability to preserve supported behavior for earlier consumers. / consumer: Component using another component's interface. / producer: Component providing data or behavior through an interface. / decimal arithmetic: Base-ten calculation with specified precision and rounding behavior. / contract test: Test checking agreed interactions across an interface boundary. / unspecified interface behavior: Input effect not defined by this interface contract. / acceptance criterion: Specific condition used to judge whether work meets requirements. Speaking task: Read Maya's three input examples, then read Arun's matching contract statements. Keep omission, empty string, and null distinct. Swap roles and repeat turns 9-16, stressing actual payload and agreed validation rule. Compare your readback with turns 19-20: two defined outcomes, one unresolved input, and no premature implementation approval. Partner: Maya: Client developer / Arun: Service developer Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the interface summary using only the stated contract and the unresolved proposal. Model for comparison AFTER my attempt, not a response to give me first: Maya: And I want the omission case protected. Solving the null question shouldn't silently turn an unchanged nickname into a cleared one for older clients. Arun: That is a backward compatibility concern worth recording. We have not demonstrated compatibility merely by agreeing that the new client looks correct. Maya: Then I'll report omission preserves, empty string clears, and null unresolved. My proposed null implementation stays pending until the interface decision. Arun: Good. That gives us an explicit acceptance criterion once the decision is made, instead of treating an ambiguous word as enough to approve the change. END REFERENCE END PROMPT Lesson 01 · Clarifying interface contracts | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 01: Clarifying interface contracts Original fictional case: A fictional profile interface accepts an optional nickname. Its current contract says an omitted nickname leaves the stored value unchanged, while an empty string clears it. A proposed client sends null. The meaning of null has not been specified. Client developer Maya and service developer Arun review the mismatch before either side implements a new interpretation. Optional describes whether the field may be absent; it does not settle what an explicit null means. Language workshop: Three nickname states, only two defined meanings Communication goal: Distinguish omission, an empty string, and null while requesting an explicit interface decision before implementation. Language guidance: Optional and nullable answer different questions. Optional concerns presence; nullable concerns allowed values. The stated contract defines omission and an empty string, but it does not authorize treating null as either one. Useful expressions (preserve the supplied facts): I want to confirm the profile interface contract. / An omitted nickname leaves the stored value unchanged. / An empty string clears the nickname. / The proposed client sends null. / The contract does not specify what null means. / Optional does not automatically mean nullable. / What should the stored value be after that input? / I would not infer this from another API. / Can we check the request payload? / If the field is absent, the current value stays. / Treating null as clear would be a new decision. / Can we agree on the intended behavior first? / Please record that rule in the contract. / We need a test for each defined input state. / The null case is still unresolved. / We agree on omission and empty string, but not yet on null. Vocabulary: interface contract: Agreed rules for inputs, outputs, and observable behavior. / application programming interface: Defined way software components communicate; abbreviated API. / request payload: Data carried by a request. / optional field: Field that may be absent under the contract. / nullable field: Field whose allowed values include null under the contract. / omitted field: Field not included in the submitted data. / empty string: Text value containing zero characters. / null value: Explicit marker whose meaning depends on the contract. / stored state: Value or condition currently retained by the system. / partial update: Change affecting only specified parts of a record. / default value: Value supplied when the governing rules call for one. / validation rule: Condition an input must satisfy. / serialization: Conversion of data into a transportable representation. / deserialization: Conversion from transported data into usable values. / schema: Formal description of data structure and constraints. / field presence: Whether a particular field exists in the input. / strong ETag: Representation validator compared strongly in an If-Match condition. / backward compatibility: Ability to preserve supported behavior for earlier consumers. / consumer: Component using another component's interface. / producer: Component providing data or behavior through an interface. / decimal arithmetic: Base-ten calculation with specified precision and rounding behavior. / contract test: Test checking agreed interactions across an interface boundary. / unspecified interface behavior: Input effect not defined by this interface contract. / acceptance criterion: Specific condition used to judge whether work meets requirements. Speaking task: Read Maya's three input examples, then read Arun's matching contract statements. Keep omission, empty string, and null distinct. Swap roles and repeat turns 9-16, stressing actual payload and agreed validation rule. Compare your readback with turns 19-20: two defined outcomes, one unresolved input, and no premature implementation approval. Partner: Maya: Client developer / Arun: Service developer Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the interface summary using only the stated contract and the unresolved proposal. Model for comparison AFTER my attempt, not a response to give me first: Maya: And I want the omission case protected. Solving the null question shouldn't silently turn an unchanged nickname into a cleared one for older clients. Arun: That is a backward compatibility concern worth recording. We have not demonstrated compatibility merely by agreeing that the new client looks correct. Maya: Then I'll report omission preserves, empty string clears, and null unresolved. My proposed null implementation stays pending until the interface decision. Arun: Good. That gives us an explicit acceptance criterion once the decision is made, instead of treating an ambiguous word as enough to approve the change. END REFERENCE END PROMPT Lesson 02 · Debugging from reproducible evidence | Build vocabulary and collocations START PROMPT TASK: Retrieve occupational vocabulary 1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation. 2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it. 3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment. 4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item. 5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 02: Debugging from reproducible evidence Original fictional case: Developer Nia has a three-row import file containing one empty date. It fails, and the stack trace points to date parsing. A two-row file without that row succeeds. Colleague Ellis reviews the evidence. No controlled test has isolated the empty date as the cause: the successful file differs in both row count and content. They need a test in a suitable nonproduction environment that changes one relevant condition while preserving the others. Language workshop: The empty date is a suspect, not yet the cause Communication goal: Report a reproducible failure, expose a confounded comparison, and request a controlled test without overstating causation. Language guidance: The two-row success is useful evidence, but it changes two things at once. It does not distinguish an empty-date effect from other differences associated with the removed row or the changed row count. Useful expressions (preserve the supplied facts): The three-row file fails during import. / One row contains an empty date. / The stack trace reaches date parsing. / The two-row file succeeds. / I suspect the empty date, but have not isolated it. / We changed both row count and content. / Can we hold the other fields constant? / Change only the suspect date condition. / Keep the original failing fixture. / We have not shown that every empty date fails. / Does the same fixture fail consistently? / Check whether the failure signature stays the same. / Run the comparison in a suitable nonproduction environment. / The trace points to parsing, not yet to a proven cause. / We do not have the controlled result yet. / Share the fixture, conditions, trace, and next comparison. Vocabulary: reproduction: Repeatable demonstration of an observed failure. / reproducible example: Input and conditions that consistently show the behavior. / stack trace: Recorded chain of calls associated with an error. / parser: Component interpreting structured input. / date parsing: Conversion of date text into a usable representation. / input fixture: Prepared input used in a test. / hypothesis: Proposed explanation requiring evidence. / root cause: Underlying cause established through investigation. / confounding variable: Additional changed factor obscuring a comparison. / controlled comparison: Comparison holding relevant conditions fixed except the tested change. / optimistic concurrency: Detecting intervening changes when a conditional update is attempted. / rounding mode: Rule for selecting a representable value when a result must be rounded. / failure signature: Identifying pattern of an observed failure. / exception: Signal that interrupts normal execution under specified conditions. / batched lookup: Retrieving data for several keys in one grouped operation. / N+1 query pattern: One initial query followed by one related query per loaded item. / empty field: Present field containing no supplied value. / malformed input: Data not conforming to the required structure or rules. / deterministic behavior: Behavior producing the same result under the same relevant conditions. / environment parity: Relevant similarity between execution environments. / regression: Previously working behavior broken by a later change. / instrumentation: Added observation mechanisms such as logs or measurements. / causal claim: Statement that one condition produces an effect. / nonproduction environment: Environment not serving the live production workload. Speaking task: Read the failed-file report and the two-row comparison. Stress which facts were observed and which cause was only suspected. Swap roles and repeat turns 5-10, keeping row count constant in the proposed test. Check your closing report against turns 17-20: nonproduction setting, pending comparison, and no confirmed causal claim. Partner: Nia: Developer investigating the import / Ellis: Developer reviewing the evidence Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the debugging handoff. The controlled test has not yet produced a result. Model for comparison AFTER my attempt, not a response to give me first: Nia: I'll use the approved test environment, not try these files against a live customer import to get a quick answer. Ellis: Use the suitable nonproduction environment and keep its configuration in the record. We need evidence without changing production data. Nia: My update will say the empty date is suspected, the successful comparison changed two factors, and a controlled repeat test is pending. Ellis: That keeps the causal claim at the right strength. Bring back the actual results; don't mark the hypothesis confirmed before the comparison is run. END REFERENCE END PROMPT Lesson 02 · Debugging from reproducible evidence | Practice grammar in context START PROMPT TASK: Choose grammar that preserves the meaning 1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness. 2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait. 3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay. 4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise. 5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 02: Debugging from reproducible evidence Original fictional case: Developer Nia has a three-row import file containing one empty date. It fails, and the stack trace points to date parsing. A two-row file without that row succeeds. Colleague Ellis reviews the evidence. No controlled test has isolated the empty date as the cause: the successful file differs in both row count and content. They need a test in a suitable nonproduction environment that changes one relevant condition while preserving the others. Language workshop: The empty date is a suspect, not yet the cause Communication goal: Report a reproducible failure, expose a confounded comparison, and request a controlled test without overstating causation. Language guidance: The two-row success is useful evidence, but it changes two things at once. It does not distinguish an empty-date effect from other differences associated with the removed row or the changed row count. Useful expressions (preserve the supplied facts): The three-row file fails during import. / One row contains an empty date. / The stack trace reaches date parsing. / The two-row file succeeds. / I suspect the empty date, but have not isolated it. / We changed both row count and content. / Can we hold the other fields constant? / Change only the suspect date condition. / Keep the original failing fixture. / We have not shown that every empty date fails. / Does the same fixture fail consistently? / Check whether the failure signature stays the same. / Run the comparison in a suitable nonproduction environment. / The trace points to parsing, not yet to a proven cause. / We do not have the controlled result yet. / Share the fixture, conditions, trace, and next comparison. Vocabulary: reproduction: Repeatable demonstration of an observed failure. / reproducible example: Input and conditions that consistently show the behavior. / stack trace: Recorded chain of calls associated with an error. / parser: Component interpreting structured input. / date parsing: Conversion of date text into a usable representation. / input fixture: Prepared input used in a test. / hypothesis: Proposed explanation requiring evidence. / root cause: Underlying cause established through investigation. / confounding variable: Additional changed factor obscuring a comparison. / controlled comparison: Comparison holding relevant conditions fixed except the tested change. / optimistic concurrency: Detecting intervening changes when a conditional update is attempted. / rounding mode: Rule for selecting a representable value when a result must be rounded. / failure signature: Identifying pattern of an observed failure. / exception: Signal that interrupts normal execution under specified conditions. / batched lookup: Retrieving data for several keys in one grouped operation. / N+1 query pattern: One initial query followed by one related query per loaded item. / empty field: Present field containing no supplied value. / malformed input: Data not conforming to the required structure or rules. / deterministic behavior: Behavior producing the same result under the same relevant conditions. / environment parity: Relevant similarity between execution environments. / regression: Previously working behavior broken by a later change. / instrumentation: Added observation mechanisms such as logs or measurements. / causal claim: Statement that one condition produces an effect. / nonproduction environment: Environment not serving the live production workload. Speaking task: Read the failed-file report and the two-row comparison. Stress which facts were observed and which cause was only suspected. Swap roles and repeat turns 5-10, keeping row count constant in the proposed test. Check your closing report against turns 17-20: nonproduction setting, pending comparison, and no confirmed causal claim. Partner: Nia: Developer investigating the import / Ellis: Developer reviewing the evidence Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the debugging handoff. The controlled test has not yet produced a result. Model for comparison AFTER my attempt, not a response to give me first: Nia: I'll use the approved test environment, not try these files against a live customer import to get a quick answer. Ellis: Use the suitable nonproduction environment and keep its configuration in the record. We need evidence without changing production data. Nia: My update will say the empty date is suspected, the successful comparison changed two factors, and a controlled repeat test is pending. Ellis: That keeps the causal claim at the right strength. Bring back the actual results; don't mark the hypothesis confirmed before the comparison is run. END REFERENCE END PROMPT Lesson 02 · Debugging from reproducible evidence | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 02: Debugging from reproducible evidence Original fictional case: Developer Nia has a three-row import file containing one empty date. It fails, and the stack trace points to date parsing. A two-row file without that row succeeds. Colleague Ellis reviews the evidence. No controlled test has isolated the empty date as the cause: the successful file differs in both row count and content. They need a test in a suitable nonproduction environment that changes one relevant condition while preserving the others. Language workshop: The empty date is a suspect, not yet the cause Communication goal: Report a reproducible failure, expose a confounded comparison, and request a controlled test without overstating causation. Language guidance: The two-row success is useful evidence, but it changes two things at once. It does not distinguish an empty-date effect from other differences associated with the removed row or the changed row count. Useful expressions (preserve the supplied facts): The three-row file fails during import. / One row contains an empty date. / The stack trace reaches date parsing. / The two-row file succeeds. / I suspect the empty date, but have not isolated it. / We changed both row count and content. / Can we hold the other fields constant? / Change only the suspect date condition. / Keep the original failing fixture. / We have not shown that every empty date fails. / Does the same fixture fail consistently? / Check whether the failure signature stays the same. / Run the comparison in a suitable nonproduction environment. / The trace points to parsing, not yet to a proven cause. / We do not have the controlled result yet. / Share the fixture, conditions, trace, and next comparison. Vocabulary: reproduction: Repeatable demonstration of an observed failure. / reproducible example: Input and conditions that consistently show the behavior. / stack trace: Recorded chain of calls associated with an error. / parser: Component interpreting structured input. / date parsing: Conversion of date text into a usable representation. / input fixture: Prepared input used in a test. / hypothesis: Proposed explanation requiring evidence. / root cause: Underlying cause established through investigation. / confounding variable: Additional changed factor obscuring a comparison. / controlled comparison: Comparison holding relevant conditions fixed except the tested change. / optimistic concurrency: Detecting intervening changes when a conditional update is attempted. / rounding mode: Rule for selecting a representable value when a result must be rounded. / failure signature: Identifying pattern of an observed failure. / exception: Signal that interrupts normal execution under specified conditions. / batched lookup: Retrieving data for several keys in one grouped operation. / N+1 query pattern: One initial query followed by one related query per loaded item. / empty field: Present field containing no supplied value. / malformed input: Data not conforming to the required structure or rules. / deterministic behavior: Behavior producing the same result under the same relevant conditions. / environment parity: Relevant similarity between execution environments. / regression: Previously working behavior broken by a later change. / instrumentation: Added observation mechanisms such as logs or measurements. / causal claim: Statement that one condition produces an effect. / nonproduction environment: Environment not serving the live production workload. Speaking task: Read the failed-file report and the two-row comparison. Stress which facts were observed and which cause was only suspected. Swap roles and repeat turns 5-10, keeping row count constant in the proposed test. Check your closing report against turns 17-20: nonproduction setting, pending comparison, and no confirmed causal claim. Partner: Nia: Developer investigating the import / Ellis: Developer reviewing the evidence Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the debugging handoff. The controlled test has not yet produced a result. Model for comparison AFTER my attempt, not a response to give me first: Nia: I'll use the approved test environment, not try these files against a live customer import to get a quick answer. Ellis: Use the suitable nonproduction environment and keep its configuration in the record. We need evidence without changing production data. Nia: My update will say the empty date is suspected, the successful comparison changed two factors, and a controlled repeat test is pending. Ellis: That keeps the causal claim at the right strength. Bring back the actual results; don't mark the hypothesis confirmed before the comparison is run. END REFERENCE END PROMPT Lesson 02 · Debugging from reproducible evidence | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 02: Debugging from reproducible evidence Original fictional case: Developer Nia has a three-row import file containing one empty date. It fails, and the stack trace points to date parsing. A two-row file without that row succeeds. Colleague Ellis reviews the evidence. No controlled test has isolated the empty date as the cause: the successful file differs in both row count and content. They need a test in a suitable nonproduction environment that changes one relevant condition while preserving the others. Language workshop: The empty date is a suspect, not yet the cause Communication goal: Report a reproducible failure, expose a confounded comparison, and request a controlled test without overstating causation. Language guidance: The two-row success is useful evidence, but it changes two things at once. It does not distinguish an empty-date effect from other differences associated with the removed row or the changed row count. Useful expressions (preserve the supplied facts): The three-row file fails during import. / One row contains an empty date. / The stack trace reaches date parsing. / The two-row file succeeds. / I suspect the empty date, but have not isolated it. / We changed both row count and content. / Can we hold the other fields constant? / Change only the suspect date condition. / Keep the original failing fixture. / We have not shown that every empty date fails. / Does the same fixture fail consistently? / Check whether the failure signature stays the same. / Run the comparison in a suitable nonproduction environment. / The trace points to parsing, not yet to a proven cause. / We do not have the controlled result yet. / Share the fixture, conditions, trace, and next comparison. Vocabulary: reproduction: Repeatable demonstration of an observed failure. / reproducible example: Input and conditions that consistently show the behavior. / stack trace: Recorded chain of calls associated with an error. / parser: Component interpreting structured input. / date parsing: Conversion of date text into a usable representation. / input fixture: Prepared input used in a test. / hypothesis: Proposed explanation requiring evidence. / root cause: Underlying cause established through investigation. / confounding variable: Additional changed factor obscuring a comparison. / controlled comparison: Comparison holding relevant conditions fixed except the tested change. / optimistic concurrency: Detecting intervening changes when a conditional update is attempted. / rounding mode: Rule for selecting a representable value when a result must be rounded. / failure signature: Identifying pattern of an observed failure. / exception: Signal that interrupts normal execution under specified conditions. / batched lookup: Retrieving data for several keys in one grouped operation. / N+1 query pattern: One initial query followed by one related query per loaded item. / empty field: Present field containing no supplied value. / malformed input: Data not conforming to the required structure or rules. / deterministic behavior: Behavior producing the same result under the same relevant conditions. / environment parity: Relevant similarity between execution environments. / regression: Previously working behavior broken by a later change. / instrumentation: Added observation mechanisms such as logs or measurements. / causal claim: Statement that one condition produces an effect. / nonproduction environment: Environment not serving the live production workload. Speaking task: Read the failed-file report and the two-row comparison. Stress which facts were observed and which cause was only suspected. Swap roles and repeat turns 5-10, keeping row count constant in the proposed test. Check your closing report against turns 17-20: nonproduction setting, pending comparison, and no confirmed causal claim. Partner: Nia: Developer investigating the import / Ellis: Developer reviewing the evidence Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the debugging handoff. The controlled test has not yet produced a result. Model for comparison AFTER my attempt, not a response to give me first: Nia: I'll use the approved test environment, not try these files against a live customer import to get a quick answer. Ellis: Use the suitable nonproduction environment and keep its configuration in the record. We need evidence without changing production data. Nia: My update will say the empty date is suspected, the successful comparison changed two factors, and a controlled repeat test is pending. Ellis: That keeps the causal claim at the right strength. Bring back the actual results; don't mark the hypothesis confirmed before the comparison is run. END REFERENCE END PROMPT Lesson 03 · Giving actionable code-review feedback | Build vocabulary and collocations START PROMPT TASK: Retrieve occupational vocabulary 1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation. 2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it. 3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment. 4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item. 5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 03: Giving actionable code-review feedback Original fictional case: A pull request is titled Rename export helper. The diff also moves the completion-notification call outside the success branch. Failed exports therefore notify users as though export completed. Reviewer Priya accepts the naming change but raises the behavior change with author Tomas. The review should request restoration of success-only notification and a failure-path test. The acceptable rename does not justify approving the unintended notification behavior. Language workshop: A rename that changed the failure path Communication goal: Anchor a review comment in a changed call location, its observable effect, and a specific correction and test. Language guidance: A rename can be acceptable while the same diff contains a blocking defect. Moving the notification outside the success branch changes observable behavior, so it is not merely a naming preference or a behavior-preserving refactor. Useful expressions (preserve the supplied facts): The helper name is clear. / This notification call has moved outside the success branch. / A failed export can now send a completion notice. / My concern is behavior, not the naming choice. / Was this control-flow change intentional? / The completion notice belongs on the success path. / Please restore the success-only condition. / Add a test for a failed export. / The failure case should not send a completion notification. / This change introduces a false-success path. / I cannot approve this behavior yet. / I am not asking you to undo the rename. / The diff does more than the title suggests. / Please update the patch and its description. / I will review the revised behavior and test. / The rename can stay once the notification issue is resolved. Vocabulary: pull request: Proposed code change submitted for review; abbreviated PR. / diff: Display of changes between versions. / review comment: Feedback attached to a proposed change. / success branch: Execution path entered when the relevant operation succeeds. / failure path: Execution path taken when an operation fails. / call site: Location where a function or operation is invoked. / control flow: Order and conditions under which code executes. / side effect: Observable effect beyond a function's returned value. / completion notification: Message indicating an operation has finished successfully here. / behavior change: Alteration in what the system observably does. / refactor: Internal restructuring intended to preserve observable behavior. / rename: Change to an identifier's name. / regression test: Test guarding against recurrence of a known defect. / assertion: Test statement checking an expected condition. / blocking concern: Issue that must be resolved before approval under the review process. / nonblocking suggestion: Improvement that does not prevent approval under the process. / review scope: Set of changes and concerns covered by a review. / intent: Purpose the author means a change to achieve. / observable behavior: Effect visible to a user or another component. / false success: Indication of success when the operation did not succeed. / guard condition: Condition controlling whether an action may occur. / patch revision: Updated version of a proposed change. / approval: Explicit acceptance at the relevant review stage. / verification evidence: Results supporting a claim that a change behaves as intended. Speaking task: Read the review once, keeping acceptance of the name separate from the blocking behavior concern. Swap roles for turns 5-10. Stress success-only notification and no notification after failure. Repeat the final four turns. Include the regression check and pending review rather than announcing approval. Partner: Priya: Code reviewer / Tomas: Pull-request author Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the review summary while preserving the accepted rename and unresolved behavior issue. Model for comparison AFTER my attempt, not a response to give me first: Priya: Make sure the new check would fail if that notification moved outside the success condition again. Otherwise it won't protect this behavior. Tomas: I'll verify the regression test catches that specific recurrence. Simply executing the failure branch isn't enough if the assertion misses the notice. Priya: Good. My review remains blocked on corrected behavior and its check. I'm happy with the name; those are separate decisions. Tomas: I'll return with verification evidence for the correction. We can resolve the blocking comment after you've reviewed that, not from this conversation alone. END REFERENCE END PROMPT Lesson 03 · Giving actionable code-review feedback | Practice grammar in context START PROMPT TASK: Choose grammar that preserves the meaning 1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness. 2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait. 3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay. 4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise. 5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 03: Giving actionable code-review feedback Original fictional case: A pull request is titled Rename export helper. The diff also moves the completion-notification call outside the success branch. Failed exports therefore notify users as though export completed. Reviewer Priya accepts the naming change but raises the behavior change with author Tomas. The review should request restoration of success-only notification and a failure-path test. The acceptable rename does not justify approving the unintended notification behavior. Language workshop: A rename that changed the failure path Communication goal: Anchor a review comment in a changed call location, its observable effect, and a specific correction and test. Language guidance: A rename can be acceptable while the same diff contains a blocking defect. Moving the notification outside the success branch changes observable behavior, so it is not merely a naming preference or a behavior-preserving refactor. Useful expressions (preserve the supplied facts): The helper name is clear. / This notification call has moved outside the success branch. / A failed export can now send a completion notice. / My concern is behavior, not the naming choice. / Was this control-flow change intentional? / The completion notice belongs on the success path. / Please restore the success-only condition. / Add a test for a failed export. / The failure case should not send a completion notification. / This change introduces a false-success path. / I cannot approve this behavior yet. / I am not asking you to undo the rename. / The diff does more than the title suggests. / Please update the patch and its description. / I will review the revised behavior and test. / The rename can stay once the notification issue is resolved. Vocabulary: pull request: Proposed code change submitted for review; abbreviated PR. / diff: Display of changes between versions. / review comment: Feedback attached to a proposed change. / success branch: Execution path entered when the relevant operation succeeds. / failure path: Execution path taken when an operation fails. / call site: Location where a function or operation is invoked. / control flow: Order and conditions under which code executes. / side effect: Observable effect beyond a function's returned value. / completion notification: Message indicating an operation has finished successfully here. / behavior change: Alteration in what the system observably does. / refactor: Internal restructuring intended to preserve observable behavior. / rename: Change to an identifier's name. / regression test: Test guarding against recurrence of a known defect. / assertion: Test statement checking an expected condition. / blocking concern: Issue that must be resolved before approval under the review process. / nonblocking suggestion: Improvement that does not prevent approval under the process. / review scope: Set of changes and concerns covered by a review. / intent: Purpose the author means a change to achieve. / observable behavior: Effect visible to a user or another component. / false success: Indication of success when the operation did not succeed. / guard condition: Condition controlling whether an action may occur. / patch revision: Updated version of a proposed change. / approval: Explicit acceptance at the relevant review stage. / verification evidence: Results supporting a claim that a change behaves as intended. Speaking task: Read the review once, keeping acceptance of the name separate from the blocking behavior concern. Swap roles for turns 5-10. Stress success-only notification and no notification after failure. Repeat the final four turns. Include the regression check and pending review rather than announcing approval. Partner: Priya: Code reviewer / Tomas: Pull-request author Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the review summary while preserving the accepted rename and unresolved behavior issue. Model for comparison AFTER my attempt, not a response to give me first: Priya: Make sure the new check would fail if that notification moved outside the success condition again. Otherwise it won't protect this behavior. Tomas: I'll verify the regression test catches that specific recurrence. Simply executing the failure branch isn't enough if the assertion misses the notice. Priya: Good. My review remains blocked on corrected behavior and its check. I'm happy with the name; those are separate decisions. Tomas: I'll return with verification evidence for the correction. We can resolve the blocking comment after you've reviewed that, not from this conversation alone. END REFERENCE END PROMPT Lesson 03 · Giving actionable code-review feedback | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 03: Giving actionable code-review feedback Original fictional case: A pull request is titled Rename export helper. The diff also moves the completion-notification call outside the success branch. Failed exports therefore notify users as though export completed. Reviewer Priya accepts the naming change but raises the behavior change with author Tomas. The review should request restoration of success-only notification and a failure-path test. The acceptable rename does not justify approving the unintended notification behavior. Language workshop: A rename that changed the failure path Communication goal: Anchor a review comment in a changed call location, its observable effect, and a specific correction and test. Language guidance: A rename can be acceptable while the same diff contains a blocking defect. Moving the notification outside the success branch changes observable behavior, so it is not merely a naming preference or a behavior-preserving refactor. Useful expressions (preserve the supplied facts): The helper name is clear. / This notification call has moved outside the success branch. / A failed export can now send a completion notice. / My concern is behavior, not the naming choice. / Was this control-flow change intentional? / The completion notice belongs on the success path. / Please restore the success-only condition. / Add a test for a failed export. / The failure case should not send a completion notification. / This change introduces a false-success path. / I cannot approve this behavior yet. / I am not asking you to undo the rename. / The diff does more than the title suggests. / Please update the patch and its description. / I will review the revised behavior and test. / The rename can stay once the notification issue is resolved. Vocabulary: pull request: Proposed code change submitted for review; abbreviated PR. / diff: Display of changes between versions. / review comment: Feedback attached to a proposed change. / success branch: Execution path entered when the relevant operation succeeds. / failure path: Execution path taken when an operation fails. / call site: Location where a function or operation is invoked. / control flow: Order and conditions under which code executes. / side effect: Observable effect beyond a function's returned value. / completion notification: Message indicating an operation has finished successfully here. / behavior change: Alteration in what the system observably does. / refactor: Internal restructuring intended to preserve observable behavior. / rename: Change to an identifier's name. / regression test: Test guarding against recurrence of a known defect. / assertion: Test statement checking an expected condition. / blocking concern: Issue that must be resolved before approval under the review process. / nonblocking suggestion: Improvement that does not prevent approval under the process. / review scope: Set of changes and concerns covered by a review. / intent: Purpose the author means a change to achieve. / observable behavior: Effect visible to a user or another component. / false success: Indication of success when the operation did not succeed. / guard condition: Condition controlling whether an action may occur. / patch revision: Updated version of a proposed change. / approval: Explicit acceptance at the relevant review stage. / verification evidence: Results supporting a claim that a change behaves as intended. Speaking task: Read the review once, keeping acceptance of the name separate from the blocking behavior concern. Swap roles for turns 5-10. Stress success-only notification and no notification after failure. Repeat the final four turns. Include the regression check and pending review rather than announcing approval. Partner: Priya: Code reviewer / Tomas: Pull-request author Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the review summary while preserving the accepted rename and unresolved behavior issue. Model for comparison AFTER my attempt, not a response to give me first: Priya: Make sure the new check would fail if that notification moved outside the success condition again. Otherwise it won't protect this behavior. Tomas: I'll verify the regression test catches that specific recurrence. Simply executing the failure branch isn't enough if the assertion misses the notice. Priya: Good. My review remains blocked on corrected behavior and its check. I'm happy with the name; those are separate decisions. Tomas: I'll return with verification evidence for the correction. We can resolve the blocking comment after you've reviewed that, not from this conversation alone. END REFERENCE END PROMPT Lesson 03 · Giving actionable code-review feedback | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 03: Giving actionable code-review feedback Original fictional case: A pull request is titled Rename export helper. The diff also moves the completion-notification call outside the success branch. Failed exports therefore notify users as though export completed. Reviewer Priya accepts the naming change but raises the behavior change with author Tomas. The review should request restoration of success-only notification and a failure-path test. The acceptable rename does not justify approving the unintended notification behavior. Language workshop: A rename that changed the failure path Communication goal: Anchor a review comment in a changed call location, its observable effect, and a specific correction and test. Language guidance: A rename can be acceptable while the same diff contains a blocking defect. Moving the notification outside the success branch changes observable behavior, so it is not merely a naming preference or a behavior-preserving refactor. Useful expressions (preserve the supplied facts): The helper name is clear. / This notification call has moved outside the success branch. / A failed export can now send a completion notice. / My concern is behavior, not the naming choice. / Was this control-flow change intentional? / The completion notice belongs on the success path. / Please restore the success-only condition. / Add a test for a failed export. / The failure case should not send a completion notification. / This change introduces a false-success path. / I cannot approve this behavior yet. / I am not asking you to undo the rename. / The diff does more than the title suggests. / Please update the patch and its description. / I will review the revised behavior and test. / The rename can stay once the notification issue is resolved. Vocabulary: pull request: Proposed code change submitted for review; abbreviated PR. / diff: Display of changes between versions. / review comment: Feedback attached to a proposed change. / success branch: Execution path entered when the relevant operation succeeds. / failure path: Execution path taken when an operation fails. / call site: Location where a function or operation is invoked. / control flow: Order and conditions under which code executes. / side effect: Observable effect beyond a function's returned value. / completion notification: Message indicating an operation has finished successfully here. / behavior change: Alteration in what the system observably does. / refactor: Internal restructuring intended to preserve observable behavior. / rename: Change to an identifier's name. / regression test: Test guarding against recurrence of a known defect. / assertion: Test statement checking an expected condition. / blocking concern: Issue that must be resolved before approval under the review process. / nonblocking suggestion: Improvement that does not prevent approval under the process. / review scope: Set of changes and concerns covered by a review. / intent: Purpose the author means a change to achieve. / observable behavior: Effect visible to a user or another component. / false success: Indication of success when the operation did not succeed. / guard condition: Condition controlling whether an action may occur. / patch revision: Updated version of a proposed change. / approval: Explicit acceptance at the relevant review stage. / verification evidence: Results supporting a claim that a change behaves as intended. Speaking task: Read the review once, keeping acceptance of the name separate from the blocking behavior concern. Swap roles for turns 5-10. Stress success-only notification and no notification after failure. Repeat the final four turns. Include the regression check and pending review rather than announcing approval. Partner: Priya: Code reviewer / Tomas: Pull-request author Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the review summary while preserving the accepted rename and unresolved behavior issue. Model for comparison AFTER my attempt, not a response to give me first: Priya: Make sure the new check would fail if that notification moved outside the success condition again. Otherwise it won't protect this behavior. Tomas: I'll verify the regression test catches that specific recurrence. Simply executing the failure branch isn't enough if the assertion misses the notice. Priya: Good. My review remains blocked on corrected behavior and its check. I'm happy with the name; those are separate decisions. Tomas: I'll return with verification evidence for the correction. We can resolve the blocking comment after you've reviewed that, not from this conversation alone. END REFERENCE END PROMPT Lesson 04 · Requesting dependency evidence | Build vocabulary and collocations START PROMPT TASK: Retrieve occupational vocabulary 1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation. 2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it. 3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment. 4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item. 5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 04: Requesting dependency evidence Original fictional case: A fictional application uses ParcelKit directly. ParcelKit in turn uses TextCore. The proposed ParcelKit upgrade changes the resolved TextCore version. A change note marks a parsing entry point as deprecated. Developers Leila and Ben have not established whether the application or its dependencies use that entry point, whether it has been removed, or whether the replacement is compatible. The packages are not assumed to follow any particular versioning convention. Language workshop: A direct upgrade with an indirect change Communication goal: Request the resolved dependency version, affected call sites, and migration evidence before claiming upgrade compatibility. Language guidance: Direct describes the application-to-ParcelKit relationship. Transitive describes the application-to-TextCore relationship through ParcelKit. The dependency actually selected matters, not just the version written in the top-level upgrade request. Useful expressions (preserve the supplied facts): The application uses ParcelKit directly. / TextCore comes through ParcelKit. / The resolved TextCore version also changes. / Which version does the lockfile record? / Can you show the dependency tree? / The note marks the parsing entry point as deprecated. / Deprecated does not by itself mean removed. / Do we have any affected call sites? / Check whether ParcelKit invokes it as well. / What does the migration guide say about the replacement? / An available replacement is not automatically compatible. / We need the package's actual versioning policy. / Which checks exercise the affected parsing behavior? / We do not have enough evidence to claim compatibility. / Usage and replacement behavior still need review. / Please attach the resolved versions and the relevant findings. Vocabulary: direct dependency: Package explicitly used or declared by the application here. / transitive dependency: Package brought in through another dependency. / dependency tree: Structure showing how packages depend on one another. / resolved version: Specific version selected after dependency resolution. / lockfile: File recording resolved dependency selections for reproducibility. / version constraint: Rule limiting which dependency versions may be selected. / release note: Published description of changes in a release. / deprecation: Notice that an interface is discouraged or scheduled for replacement. / removal: Elimination of a previously available interface or behavior. / migration guide: Instructions describing transition to a changed interface. / entry point: Named interface through which functionality is invoked. / call site: Location that invokes a particular interface. / public interface: Supported surface exposed for other components to use. / breaking change: Change that can invalidate previously supported use. / compatibility: Ability to work with the relevant existing consumers and behavior. / semantic versioning: Version convention relating version numbers to public-interface changes. / major version: Leading version component under a stated convention. / minor version: Version component whose meaning depends on the adopted convention. / patch version: Version component commonly used for fixes under a stated convention. / pin: Fixed dependency selection restricting version movement. / changelog: Maintained record of notable changes between versions. / replacement interface: Interface intended to supersede another. / resolution: Process selecting concrete dependency versions. / upgrade evidence: Records and checks supporting an upgrade assessment. Speaking task: Read the dependency discussion and distinguish the requested ParcelKit change from the selected TextCore version. Swap roles and repeat turns 5-12. Keep deprecated, removed, used, and compatible separate. Check the final readback against turns 17-20. Usage and compatibility must remain unresolved until evidence is supplied. Partner: Leila: Developer proposing the upgrade / Ben: Developer checking dependency impact Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the upgrade handoff without turning deprecation into confirmed removal or compatibility. Model for comparison AFTER my attempt, not a response to give me first: Leila: I'll name that coverage gap instead of saying all tests passed therefore compatible. A green suite could simply miss the changed path. Ben: Exactly. We need upgrade evidence tied to this change. It should show what was checked and what remains unknown, not just that an upgrade command succeeded. Leila: My revised summary will separate resolved versions, deprecation status, usage, and replacement behavior. The last two still need investigation. Ben: That is accurate. Keep compatibility unverified for now. Once those findings are available, we can discuss the upgrade on evidence rather than infer its impact from the headline. END REFERENCE END PROMPT Lesson 04 · Requesting dependency evidence | Practice grammar in context START PROMPT TASK: Choose grammar that preserves the meaning 1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness. 2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait. 3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay. 4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise. 5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 04: Requesting dependency evidence Original fictional case: A fictional application uses ParcelKit directly. ParcelKit in turn uses TextCore. The proposed ParcelKit upgrade changes the resolved TextCore version. A change note marks a parsing entry point as deprecated. Developers Leila and Ben have not established whether the application or its dependencies use that entry point, whether it has been removed, or whether the replacement is compatible. The packages are not assumed to follow any particular versioning convention. Language workshop: A direct upgrade with an indirect change Communication goal: Request the resolved dependency version, affected call sites, and migration evidence before claiming upgrade compatibility. Language guidance: Direct describes the application-to-ParcelKit relationship. Transitive describes the application-to-TextCore relationship through ParcelKit. The dependency actually selected matters, not just the version written in the top-level upgrade request. Useful expressions (preserve the supplied facts): The application uses ParcelKit directly. / TextCore comes through ParcelKit. / The resolved TextCore version also changes. / Which version does the lockfile record? / Can you show the dependency tree? / The note marks the parsing entry point as deprecated. / Deprecated does not by itself mean removed. / Do we have any affected call sites? / Check whether ParcelKit invokes it as well. / What does the migration guide say about the replacement? / An available replacement is not automatically compatible. / We need the package's actual versioning policy. / Which checks exercise the affected parsing behavior? / We do not have enough evidence to claim compatibility. / Usage and replacement behavior still need review. / Please attach the resolved versions and the relevant findings. Vocabulary: direct dependency: Package explicitly used or declared by the application here. / transitive dependency: Package brought in through another dependency. / dependency tree: Structure showing how packages depend on one another. / resolved version: Specific version selected after dependency resolution. / lockfile: File recording resolved dependency selections for reproducibility. / version constraint: Rule limiting which dependency versions may be selected. / release note: Published description of changes in a release. / deprecation: Notice that an interface is discouraged or scheduled for replacement. / removal: Elimination of a previously available interface or behavior. / migration guide: Instructions describing transition to a changed interface. / entry point: Named interface through which functionality is invoked. / call site: Location that invokes a particular interface. / public interface: Supported surface exposed for other components to use. / breaking change: Change that can invalidate previously supported use. / compatibility: Ability to work with the relevant existing consumers and behavior. / semantic versioning: Version convention relating version numbers to public-interface changes. / major version: Leading version component under a stated convention. / minor version: Version component whose meaning depends on the adopted convention. / patch version: Version component commonly used for fixes under a stated convention. / pin: Fixed dependency selection restricting version movement. / changelog: Maintained record of notable changes between versions. / replacement interface: Interface intended to supersede another. / resolution: Process selecting concrete dependency versions. / upgrade evidence: Records and checks supporting an upgrade assessment. Speaking task: Read the dependency discussion and distinguish the requested ParcelKit change from the selected TextCore version. Swap roles and repeat turns 5-12. Keep deprecated, removed, used, and compatible separate. Check the final readback against turns 17-20. Usage and compatibility must remain unresolved until evidence is supplied. Partner: Leila: Developer proposing the upgrade / Ben: Developer checking dependency impact Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the upgrade handoff without turning deprecation into confirmed removal or compatibility. Model for comparison AFTER my attempt, not a response to give me first: Leila: I'll name that coverage gap instead of saying all tests passed therefore compatible. A green suite could simply miss the changed path. Ben: Exactly. We need upgrade evidence tied to this change. It should show what was checked and what remains unknown, not just that an upgrade command succeeded. Leila: My revised summary will separate resolved versions, deprecation status, usage, and replacement behavior. The last two still need investigation. Ben: That is accurate. Keep compatibility unverified for now. Once those findings are available, we can discuss the upgrade on evidence rather than infer its impact from the headline. END REFERENCE END PROMPT Lesson 04 · Requesting dependency evidence | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 04: Requesting dependency evidence Original fictional case: A fictional application uses ParcelKit directly. ParcelKit in turn uses TextCore. The proposed ParcelKit upgrade changes the resolved TextCore version. A change note marks a parsing entry point as deprecated. Developers Leila and Ben have not established whether the application or its dependencies use that entry point, whether it has been removed, or whether the replacement is compatible. The packages are not assumed to follow any particular versioning convention. Language workshop: A direct upgrade with an indirect change Communication goal: Request the resolved dependency version, affected call sites, and migration evidence before claiming upgrade compatibility. Language guidance: Direct describes the application-to-ParcelKit relationship. Transitive describes the application-to-TextCore relationship through ParcelKit. The dependency actually selected matters, not just the version written in the top-level upgrade request. Useful expressions (preserve the supplied facts): The application uses ParcelKit directly. / TextCore comes through ParcelKit. / The resolved TextCore version also changes. / Which version does the lockfile record? / Can you show the dependency tree? / The note marks the parsing entry point as deprecated. / Deprecated does not by itself mean removed. / Do we have any affected call sites? / Check whether ParcelKit invokes it as well. / What does the migration guide say about the replacement? / An available replacement is not automatically compatible. / We need the package's actual versioning policy. / Which checks exercise the affected parsing behavior? / We do not have enough evidence to claim compatibility. / Usage and replacement behavior still need review. / Please attach the resolved versions and the relevant findings. Vocabulary: direct dependency: Package explicitly used or declared by the application here. / transitive dependency: Package brought in through another dependency. / dependency tree: Structure showing how packages depend on one another. / resolved version: Specific version selected after dependency resolution. / lockfile: File recording resolved dependency selections for reproducibility. / version constraint: Rule limiting which dependency versions may be selected. / release note: Published description of changes in a release. / deprecation: Notice that an interface is discouraged or scheduled for replacement. / removal: Elimination of a previously available interface or behavior. / migration guide: Instructions describing transition to a changed interface. / entry point: Named interface through which functionality is invoked. / call site: Location that invokes a particular interface. / public interface: Supported surface exposed for other components to use. / breaking change: Change that can invalidate previously supported use. / compatibility: Ability to work with the relevant existing consumers and behavior. / semantic versioning: Version convention relating version numbers to public-interface changes. / major version: Leading version component under a stated convention. / minor version: Version component whose meaning depends on the adopted convention. / patch version: Version component commonly used for fixes under a stated convention. / pin: Fixed dependency selection restricting version movement. / changelog: Maintained record of notable changes between versions. / replacement interface: Interface intended to supersede another. / resolution: Process selecting concrete dependency versions. / upgrade evidence: Records and checks supporting an upgrade assessment. Speaking task: Read the dependency discussion and distinguish the requested ParcelKit change from the selected TextCore version. Swap roles and repeat turns 5-12. Keep deprecated, removed, used, and compatible separate. Check the final readback against turns 17-20. Usage and compatibility must remain unresolved until evidence is supplied. Partner: Leila: Developer proposing the upgrade / Ben: Developer checking dependency impact Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the upgrade handoff without turning deprecation into confirmed removal or compatibility. Model for comparison AFTER my attempt, not a response to give me first: Leila: I'll name that coverage gap instead of saying all tests passed therefore compatible. A green suite could simply miss the changed path. Ben: Exactly. We need upgrade evidence tied to this change. It should show what was checked and what remains unknown, not just that an upgrade command succeeded. Leila: My revised summary will separate resolved versions, deprecation status, usage, and replacement behavior. The last two still need investigation. Ben: That is accurate. Keep compatibility unverified for now. Once those findings are available, we can discuss the upgrade on evidence rather than infer its impact from the headline. END REFERENCE END PROMPT Lesson 04 · Requesting dependency evidence | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 04: Requesting dependency evidence Original fictional case: A fictional application uses ParcelKit directly. ParcelKit in turn uses TextCore. The proposed ParcelKit upgrade changes the resolved TextCore version. A change note marks a parsing entry point as deprecated. Developers Leila and Ben have not established whether the application or its dependencies use that entry point, whether it has been removed, or whether the replacement is compatible. The packages are not assumed to follow any particular versioning convention. Language workshop: A direct upgrade with an indirect change Communication goal: Request the resolved dependency version, affected call sites, and migration evidence before claiming upgrade compatibility. Language guidance: Direct describes the application-to-ParcelKit relationship. Transitive describes the application-to-TextCore relationship through ParcelKit. The dependency actually selected matters, not just the version written in the top-level upgrade request. Useful expressions (preserve the supplied facts): The application uses ParcelKit directly. / TextCore comes through ParcelKit. / The resolved TextCore version also changes. / Which version does the lockfile record? / Can you show the dependency tree? / The note marks the parsing entry point as deprecated. / Deprecated does not by itself mean removed. / Do we have any affected call sites? / Check whether ParcelKit invokes it as well. / What does the migration guide say about the replacement? / An available replacement is not automatically compatible. / We need the package's actual versioning policy. / Which checks exercise the affected parsing behavior? / We do not have enough evidence to claim compatibility. / Usage and replacement behavior still need review. / Please attach the resolved versions and the relevant findings. Vocabulary: direct dependency: Package explicitly used or declared by the application here. / transitive dependency: Package brought in through another dependency. / dependency tree: Structure showing how packages depend on one another. / resolved version: Specific version selected after dependency resolution. / lockfile: File recording resolved dependency selections for reproducibility. / version constraint: Rule limiting which dependency versions may be selected. / release note: Published description of changes in a release. / deprecation: Notice that an interface is discouraged or scheduled for replacement. / removal: Elimination of a previously available interface or behavior. / migration guide: Instructions describing transition to a changed interface. / entry point: Named interface through which functionality is invoked. / call site: Location that invokes a particular interface. / public interface: Supported surface exposed for other components to use. / breaking change: Change that can invalidate previously supported use. / compatibility: Ability to work with the relevant existing consumers and behavior. / semantic versioning: Version convention relating version numbers to public-interface changes. / major version: Leading version component under a stated convention. / minor version: Version component whose meaning depends on the adopted convention. / patch version: Version component commonly used for fixes under a stated convention. / pin: Fixed dependency selection restricting version movement. / changelog: Maintained record of notable changes between versions. / replacement interface: Interface intended to supersede another. / resolution: Process selecting concrete dependency versions. / upgrade evidence: Records and checks supporting an upgrade assessment. Speaking task: Read the dependency discussion and distinguish the requested ParcelKit change from the selected TextCore version. Swap roles and repeat turns 5-12. Keep deprecated, removed, used, and compatible separate. Check the final readback against turns 17-20. Usage and compatibility must remain unresolved until evidence is supplied. Partner: Leila: Developer proposing the upgrade / Ben: Developer checking dependency impact Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the upgrade handoff without turning deprecation into confirmed removal or compatibility. Model for comparison AFTER my attempt, not a response to give me first: Leila: I'll name that coverage gap instead of saying all tests passed therefore compatible. A green suite could simply miss the changed path. Ben: Exactly. We need upgrade evidence tied to this change. It should show what was checked and what remains unknown, not just that an upgrade command succeeded. Leila: My revised summary will separate resolved versions, deprecation status, usage, and replacement behavior. The last two still need investigation. Ben: That is accurate. Keep compatibility unverified for now. Once those findings are available, we can discuss the upgrade on evidence rather than infer its impact from the headline. END REFERENCE END PROMPT Lesson 05 · Explaining what a test actually exercises | Build vocabulary and collocations START PROMPT TASK: Retrieve occupational vocabulary 1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation. 2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it. 3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment. 4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item. 5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 05: Explaining what a test actually exercises Original fictional case: A save-operation unit test uses a storage double that always succeeds and checks the success message. A previous bug showed success after storage rejected the save. The current test never produces rejection, and the real storage adapter is untested. Developers Owen and Farah need to configure a rejection case, assert that false success does not appear, and keep real-adapter integration coverage as a separate unresolved concern. Language workshop: A green test that never sees rejection Communication goal: Explain the limits of a success-only test double and distinguish a failure-path unit test from real-adapter integration coverage. Language guidance: A double that always succeeds can support a success-path assertion, but it cannot exercise rejection handling. Configure a failing response and check the user-visible consequence relevant to the known bug. Useful expressions (preserve the supplied facts): The storage double always succeeds. / This test exercises the happy path. / The bug showed success after a rejected save. / The current test never triggers rejection. / Make the double reject in a separate case. / Assert that no success message appears after rejection. / Keep the successful-save case too. / A storage call alone does not prove the right user message. / This is a double, not the real adapter. / The result applies to the simulated rejection case. / The real adapter needs separate integration coverage. / Green tests do not establish all storage behavior. / We have not verified the real adapter. / What observable result should this case check? / Please include the configured outcome and assertion. / The new unit case can close one gap, not every storage risk. Vocabulary: unit test: Focused test of a small behavior or component. / test double: Substitute for a real dependency during testing. / stub: Test substitute supplying predetermined responses. / mock: Test substitute that can record or check interactions. / fixture: Prepared state or data used by a test. / success response: Result indicating an operation succeeded. / rejection: Failed outcome reported by the storage operation here. / exception: Error signal raised during execution under the relevant model. / assertion: Explicit check of an expected test condition. / negative assertion: Check that an unwanted event or state does not occur. / test isolation: Separation of a tested unit from unrelated dependencies. / integration test: Test of interaction between connected components. / adapter: Component translating between an application and an external interface. / branch coverage: Measure of which decision outcomes a test set executes. / happy path: Expected successful execution path. / error path: Execution path handling an unsuccessful operation. / false negative: Test result that misses a defect which is present. / test oracle: Rule or reference used to judge the expected result. / arrange: Prepare the conditions for a test. / act: Execute the behavior being tested. / assert: Check the observed result against the expectation. / interaction verification: Check of how a component called its dependencies. / behavioral verification: Check of the externally observable result. / coverage gap: Relevant behavior not exercised by the current tests. Speaking task: Read the save-test exchange, stressing always succeeds when describing the original double. Swap roles and repeat turns 5-12. Distinguish a no-success-message assertion from checking a dependency call. Use the final four turns to rehearse a bounded test report. Include the simulated rejection and remaining real-adapter gap. Partner: Owen: Developer maintaining the test / Farah: Developer reviewing coverage Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the review note about the current test and the proposed rejection case. Model for comparison AFTER my attempt, not a response to give me first: Owen: After adding rejection, I'll report exactly which outcome was simulated and which visible behavior was checked, alongside the real-adapter gap. Farah: That is useful behavioral verification. Report the assertion result, not a blanket statement that storage is fully tested. Owen: The patch is still pending review. I'll attach both test results when they're available, without inventing a successful run in the handoff. Farah: Good. A targeted unit test can catch this application defect while leaving the real integration question clearly open. END REFERENCE END PROMPT Lesson 05 · Explaining what a test actually exercises | Practice grammar in context START PROMPT TASK: Choose grammar that preserves the meaning 1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness. 2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait. 3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay. 4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise. 5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 05: Explaining what a test actually exercises Original fictional case: A save-operation unit test uses a storage double that always succeeds and checks the success message. A previous bug showed success after storage rejected the save. The current test never produces rejection, and the real storage adapter is untested. Developers Owen and Farah need to configure a rejection case, assert that false success does not appear, and keep real-adapter integration coverage as a separate unresolved concern. Language workshop: A green test that never sees rejection Communication goal: Explain the limits of a success-only test double and distinguish a failure-path unit test from real-adapter integration coverage. Language guidance: A double that always succeeds can support a success-path assertion, but it cannot exercise rejection handling. Configure a failing response and check the user-visible consequence relevant to the known bug. Useful expressions (preserve the supplied facts): The storage double always succeeds. / This test exercises the happy path. / The bug showed success after a rejected save. / The current test never triggers rejection. / Make the double reject in a separate case. / Assert that no success message appears after rejection. / Keep the successful-save case too. / A storage call alone does not prove the right user message. / This is a double, not the real adapter. / The result applies to the simulated rejection case. / The real adapter needs separate integration coverage. / Green tests do not establish all storage behavior. / We have not verified the real adapter. / What observable result should this case check? / Please include the configured outcome and assertion. / The new unit case can close one gap, not every storage risk. Vocabulary: unit test: Focused test of a small behavior or component. / test double: Substitute for a real dependency during testing. / stub: Test substitute supplying predetermined responses. / mock: Test substitute that can record or check interactions. / fixture: Prepared state or data used by a test. / success response: Result indicating an operation succeeded. / rejection: Failed outcome reported by the storage operation here. / exception: Error signal raised during execution under the relevant model. / assertion: Explicit check of an expected test condition. / negative assertion: Check that an unwanted event or state does not occur. / test isolation: Separation of a tested unit from unrelated dependencies. / integration test: Test of interaction between connected components. / adapter: Component translating between an application and an external interface. / branch coverage: Measure of which decision outcomes a test set executes. / happy path: Expected successful execution path. / error path: Execution path handling an unsuccessful operation. / false negative: Test result that misses a defect which is present. / test oracle: Rule or reference used to judge the expected result. / arrange: Prepare the conditions for a test. / act: Execute the behavior being tested. / assert: Check the observed result against the expectation. / interaction verification: Check of how a component called its dependencies. / behavioral verification: Check of the externally observable result. / coverage gap: Relevant behavior not exercised by the current tests. Speaking task: Read the save-test exchange, stressing always succeeds when describing the original double. Swap roles and repeat turns 5-12. Distinguish a no-success-message assertion from checking a dependency call. Use the final four turns to rehearse a bounded test report. Include the simulated rejection and remaining real-adapter gap. Partner: Owen: Developer maintaining the test / Farah: Developer reviewing coverage Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the review note about the current test and the proposed rejection case. Model for comparison AFTER my attempt, not a response to give me first: Owen: After adding rejection, I'll report exactly which outcome was simulated and which visible behavior was checked, alongside the real-adapter gap. Farah: That is useful behavioral verification. Report the assertion result, not a blanket statement that storage is fully tested. Owen: The patch is still pending review. I'll attach both test results when they're available, without inventing a successful run in the handoff. Farah: Good. A targeted unit test can catch this application defect while leaving the real integration question clearly open. END REFERENCE END PROMPT Lesson 05 · Explaining what a test actually exercises | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 05: Explaining what a test actually exercises Original fictional case: A save-operation unit test uses a storage double that always succeeds and checks the success message. A previous bug showed success after storage rejected the save. The current test never produces rejection, and the real storage adapter is untested. Developers Owen and Farah need to configure a rejection case, assert that false success does not appear, and keep real-adapter integration coverage as a separate unresolved concern. Language workshop: A green test that never sees rejection Communication goal: Explain the limits of a success-only test double and distinguish a failure-path unit test from real-adapter integration coverage. Language guidance: A double that always succeeds can support a success-path assertion, but it cannot exercise rejection handling. Configure a failing response and check the user-visible consequence relevant to the known bug. Useful expressions (preserve the supplied facts): The storage double always succeeds. / This test exercises the happy path. / The bug showed success after a rejected save. / The current test never triggers rejection. / Make the double reject in a separate case. / Assert that no success message appears after rejection. / Keep the successful-save case too. / A storage call alone does not prove the right user message. / This is a double, not the real adapter. / The result applies to the simulated rejection case. / The real adapter needs separate integration coverage. / Green tests do not establish all storage behavior. / We have not verified the real adapter. / What observable result should this case check? / Please include the configured outcome and assertion. / The new unit case can close one gap, not every storage risk. Vocabulary: unit test: Focused test of a small behavior or component. / test double: Substitute for a real dependency during testing. / stub: Test substitute supplying predetermined responses. / mock: Test substitute that can record or check interactions. / fixture: Prepared state or data used by a test. / success response: Result indicating an operation succeeded. / rejection: Failed outcome reported by the storage operation here. / exception: Error signal raised during execution under the relevant model. / assertion: Explicit check of an expected test condition. / negative assertion: Check that an unwanted event or state does not occur. / test isolation: Separation of a tested unit from unrelated dependencies. / integration test: Test of interaction between connected components. / adapter: Component translating between an application and an external interface. / branch coverage: Measure of which decision outcomes a test set executes. / happy path: Expected successful execution path. / error path: Execution path handling an unsuccessful operation. / false negative: Test result that misses a defect which is present. / test oracle: Rule or reference used to judge the expected result. / arrange: Prepare the conditions for a test. / act: Execute the behavior being tested. / assert: Check the observed result against the expectation. / interaction verification: Check of how a component called its dependencies. / behavioral verification: Check of the externally observable result. / coverage gap: Relevant behavior not exercised by the current tests. Speaking task: Read the save-test exchange, stressing always succeeds when describing the original double. Swap roles and repeat turns 5-12. Distinguish a no-success-message assertion from checking a dependency call. Use the final four turns to rehearse a bounded test report. Include the simulated rejection and remaining real-adapter gap. Partner: Owen: Developer maintaining the test / Farah: Developer reviewing coverage Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the review note about the current test and the proposed rejection case. Model for comparison AFTER my attempt, not a response to give me first: Owen: After adding rejection, I'll report exactly which outcome was simulated and which visible behavior was checked, alongside the real-adapter gap. Farah: That is useful behavioral verification. Report the assertion result, not a blanket statement that storage is fully tested. Owen: The patch is still pending review. I'll attach both test results when they're available, without inventing a successful run in the handoff. Farah: Good. A targeted unit test can catch this application defect while leaving the real integration question clearly open. END REFERENCE END PROMPT Lesson 05 · Explaining what a test actually exercises | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 05: Explaining what a test actually exercises Original fictional case: A save-operation unit test uses a storage double that always succeeds and checks the success message. A previous bug showed success after storage rejected the save. The current test never produces rejection, and the real storage adapter is untested. Developers Owen and Farah need to configure a rejection case, assert that false success does not appear, and keep real-adapter integration coverage as a separate unresolved concern. Language workshop: A green test that never sees rejection Communication goal: Explain the limits of a success-only test double and distinguish a failure-path unit test from real-adapter integration coverage. Language guidance: A double that always succeeds can support a success-path assertion, but it cannot exercise rejection handling. Configure a failing response and check the user-visible consequence relevant to the known bug. Useful expressions (preserve the supplied facts): The storage double always succeeds. / This test exercises the happy path. / The bug showed success after a rejected save. / The current test never triggers rejection. / Make the double reject in a separate case. / Assert that no success message appears after rejection. / Keep the successful-save case too. / A storage call alone does not prove the right user message. / This is a double, not the real adapter. / The result applies to the simulated rejection case. / The real adapter needs separate integration coverage. / Green tests do not establish all storage behavior. / We have not verified the real adapter. / What observable result should this case check? / Please include the configured outcome and assertion. / The new unit case can close one gap, not every storage risk. Vocabulary: unit test: Focused test of a small behavior or component. / test double: Substitute for a real dependency during testing. / stub: Test substitute supplying predetermined responses. / mock: Test substitute that can record or check interactions. / fixture: Prepared state or data used by a test. / success response: Result indicating an operation succeeded. / rejection: Failed outcome reported by the storage operation here. / exception: Error signal raised during execution under the relevant model. / assertion: Explicit check of an expected test condition. / negative assertion: Check that an unwanted event or state does not occur. / test isolation: Separation of a tested unit from unrelated dependencies. / integration test: Test of interaction between connected components. / adapter: Component translating between an application and an external interface. / branch coverage: Measure of which decision outcomes a test set executes. / happy path: Expected successful execution path. / error path: Execution path handling an unsuccessful operation. / false negative: Test result that misses a defect which is present. / test oracle: Rule or reference used to judge the expected result. / arrange: Prepare the conditions for a test. / act: Execute the behavior being tested. / assert: Check the observed result against the expectation. / interaction verification: Check of how a component called its dependencies. / behavioral verification: Check of the externally observable result. / coverage gap: Relevant behavior not exercised by the current tests. Speaking task: Read the save-test exchange, stressing always succeeds when describing the original double. Swap roles and repeat turns 5-12. Distinguish a no-success-message assertion from checking a dependency call. Use the final four turns to rehearse a bounded test report. Include the simulated rejection and remaining real-adapter gap. Partner: Owen: Developer maintaining the test / Farah: Developer reviewing coverage Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the review note about the current test and the proposed rejection case. Model for comparison AFTER my attempt, not a response to give me first: Owen: After adding rejection, I'll report exactly which outcome was simulated and which visible behavior was checked, alongside the real-adapter gap. Farah: That is useful behavioral verification. Report the assertion result, not a blanket statement that storage is fully tested. Owen: The patch is still pending review. I'll attach both test results when they're available, without inventing a successful run in the handoff. Farah: Good. A targeted unit test can catch this application defect while leaving the real integration question clearly open. END REFERENCE END PROMPT Lesson 06 · Comparing performance tradeoffs fairly | Build vocabulary and collocations START PROMPT TASK: Retrieve occupational vocabulary 1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation. 2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it. 3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment. 4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item. 5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 06: Comparing performance tradeoffs fairly Original fictional case: In a controlled benchmark using the same input and machine, implementation A has median latency of 40 milliseconds and memory use of 80 megabytes. B has median latency of 25 milliseconds and memory use of 160 megabytes. The memory budget is 120 megabytes. Developers Sora and Malik discuss the tradeoff. Tail latency and production behavior have not been measured. B reduces the measured median by 15 milliseconds, or 37.5 percent relative to A, but exceeds the memory budget by 40 megabytes. Language workshop: Fifteen milliseconds faster, forty megabytes over budget Communication goal: Compare measured latency and memory under matched conditions while separating median improvement from budget compliance and production claims. Language guidance: B reduces the median from 40 to 25 milliseconds: a 15-millisecond difference and a 37.5 percent reduction relative to A. It uses twice A's measured memory, but doubling memory is not the same as doubling speed. Useful expressions (preserve the supplied facts): Both runs use the same input and machine. / A has a forty-millisecond median and uses eighty megabytes. / B has a twenty-five-millisecond median and uses one hundred sixty megabytes. / B lowers the median by fifteen milliseconds. / That is a thirty-seven-point-five percent reduction relative to A. / B uses twice A's measured memory. / The memory budget is one hundred twenty megabytes. / B exceeds that budget by forty megabytes. / A remains forty megabytes below the limit. / B is faster on this median measure, not automatically better overall. / The median does not tell us the tail latency. / We have not measured production behavior. / These figures do not establish throughput. / Put the latency gain and memory cost together. / The measured gain does not remove the budget constraint. / We have a documented tradeoff, not a production guarantee. Vocabulary: benchmark: Structured measurement under specified conditions. / latency: Time taken for a request or operation. / median: Middle ordered value, or mean of the two middle values for an even sample. / tail latency: Slower-end behavior in a latency distribution. / percentile: Value below which a stated percentage of observations falls. / p95: Ninety-fifth percentile of a measured distribution. / throughput: Amount of work completed per unit of time. / memory footprint: Amount of memory used under the stated conditions. / resource budget: Allowed limit for a specified resource. / headroom: Remaining capacity below a stated limit. / overrun: Amount by which usage exceeds a limit. / baseline: Reference implementation or measurement for comparison. / relative reduction: Decrease expressed as a fraction of the original value. / absolute difference: Direct numerical subtraction between comparable measurements. / tradeoff: Gain in one property accompanied by a cost in another. / workload: Type and amount of work applied to a system. / sample: Set of observations used in an analysis. / distribution: Pattern of observed values across a range. / outlier: Observation unusually distant from most other values. / measurement noise: Variation not attributable to the intended comparison alone. / controlled conditions: Specified conditions held consistent during comparison. / production behavior: Behavior under actual live operating conditions. / bottleneck: Constraint limiting overall system performance. / budget compliance: Whether measured usage satisfies the stated limit. Speaking task: Read the performance comparison aloud with units: milliseconds for latency, megabytes for memory. Swap roles for turns 5-12. State the fifteen-millisecond decrease, 37.5 percent reduction, and forty-megabyte headroom accurately. Compare the final report with the supplied table facts. Keep the budget violation and unmeasured production behavior visible. Partner: Sora: Developer presenting the benchmark / Malik: Developer reviewing the tradeoff Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Use the supplied numbers to complete the benchmark summary. Units are printed in each sentence. Model for comparison AFTER my attempt, not a response to give me first: Sora: I could request a changed memory budget, but that wouldn't make this run compliant with the current one. It would be a separate decision. Malik: Exactly. Current budget compliance is clear: A is below the limit and B is above it. A hypothetical future budget should not rewrite today's comparison. Sora: I'll report the matched conditions, latency decrease, memory figures, and unmeasured tail and live behavior. We still need to decide what to investigate next. Malik: Good. Keep the controlled conditions visible alongside that summary. We can make a reasoned next decision without pretending the benchmark answers questions it never measured. END REFERENCE END PROMPT Lesson 06 · Comparing performance tradeoffs fairly | Practice grammar in context START PROMPT TASK: Choose grammar that preserves the meaning 1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness. 2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait. 3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay. 4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise. 5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 06: Comparing performance tradeoffs fairly Original fictional case: In a controlled benchmark using the same input and machine, implementation A has median latency of 40 milliseconds and memory use of 80 megabytes. B has median latency of 25 milliseconds and memory use of 160 megabytes. The memory budget is 120 megabytes. Developers Sora and Malik discuss the tradeoff. Tail latency and production behavior have not been measured. B reduces the measured median by 15 milliseconds, or 37.5 percent relative to A, but exceeds the memory budget by 40 megabytes. Language workshop: Fifteen milliseconds faster, forty megabytes over budget Communication goal: Compare measured latency and memory under matched conditions while separating median improvement from budget compliance and production claims. Language guidance: B reduces the median from 40 to 25 milliseconds: a 15-millisecond difference and a 37.5 percent reduction relative to A. It uses twice A's measured memory, but doubling memory is not the same as doubling speed. Useful expressions (preserve the supplied facts): Both runs use the same input and machine. / A has a forty-millisecond median and uses eighty megabytes. / B has a twenty-five-millisecond median and uses one hundred sixty megabytes. / B lowers the median by fifteen milliseconds. / That is a thirty-seven-point-five percent reduction relative to A. / B uses twice A's measured memory. / The memory budget is one hundred twenty megabytes. / B exceeds that budget by forty megabytes. / A remains forty megabytes below the limit. / B is faster on this median measure, not automatically better overall. / The median does not tell us the tail latency. / We have not measured production behavior. / These figures do not establish throughput. / Put the latency gain and memory cost together. / The measured gain does not remove the budget constraint. / We have a documented tradeoff, not a production guarantee. Vocabulary: benchmark: Structured measurement under specified conditions. / latency: Time taken for a request or operation. / median: Middle ordered value, or mean of the two middle values for an even sample. / tail latency: Slower-end behavior in a latency distribution. / percentile: Value below which a stated percentage of observations falls. / p95: Ninety-fifth percentile of a measured distribution. / throughput: Amount of work completed per unit of time. / memory footprint: Amount of memory used under the stated conditions. / resource budget: Allowed limit for a specified resource. / headroom: Remaining capacity below a stated limit. / overrun: Amount by which usage exceeds a limit. / baseline: Reference implementation or measurement for comparison. / relative reduction: Decrease expressed as a fraction of the original value. / absolute difference: Direct numerical subtraction between comparable measurements. / tradeoff: Gain in one property accompanied by a cost in another. / workload: Type and amount of work applied to a system. / sample: Set of observations used in an analysis. / distribution: Pattern of observed values across a range. / outlier: Observation unusually distant from most other values. / measurement noise: Variation not attributable to the intended comparison alone. / controlled conditions: Specified conditions held consistent during comparison. / production behavior: Behavior under actual live operating conditions. / bottleneck: Constraint limiting overall system performance. / budget compliance: Whether measured usage satisfies the stated limit. Speaking task: Read the performance comparison aloud with units: milliseconds for latency, megabytes for memory. Swap roles for turns 5-12. State the fifteen-millisecond decrease, 37.5 percent reduction, and forty-megabyte headroom accurately. Compare the final report with the supplied table facts. Keep the budget violation and unmeasured production behavior visible. Partner: Sora: Developer presenting the benchmark / Malik: Developer reviewing the tradeoff Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Use the supplied numbers to complete the benchmark summary. Units are printed in each sentence. Model for comparison AFTER my attempt, not a response to give me first: Sora: I could request a changed memory budget, but that wouldn't make this run compliant with the current one. It would be a separate decision. Malik: Exactly. Current budget compliance is clear: A is below the limit and B is above it. A hypothetical future budget should not rewrite today's comparison. Sora: I'll report the matched conditions, latency decrease, memory figures, and unmeasured tail and live behavior. We still need to decide what to investigate next. Malik: Good. Keep the controlled conditions visible alongside that summary. We can make a reasoned next decision without pretending the benchmark answers questions it never measured. END REFERENCE END PROMPT Lesson 06 · Comparing performance tradeoffs fairly | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 06: Comparing performance tradeoffs fairly Original fictional case: In a controlled benchmark using the same input and machine, implementation A has median latency of 40 milliseconds and memory use of 80 megabytes. B has median latency of 25 milliseconds and memory use of 160 megabytes. The memory budget is 120 megabytes. Developers Sora and Malik discuss the tradeoff. Tail latency and production behavior have not been measured. B reduces the measured median by 15 milliseconds, or 37.5 percent relative to A, but exceeds the memory budget by 40 megabytes. Language workshop: Fifteen milliseconds faster, forty megabytes over budget Communication goal: Compare measured latency and memory under matched conditions while separating median improvement from budget compliance and production claims. Language guidance: B reduces the median from 40 to 25 milliseconds: a 15-millisecond difference and a 37.5 percent reduction relative to A. It uses twice A's measured memory, but doubling memory is not the same as doubling speed. Useful expressions (preserve the supplied facts): Both runs use the same input and machine. / A has a forty-millisecond median and uses eighty megabytes. / B has a twenty-five-millisecond median and uses one hundred sixty megabytes. / B lowers the median by fifteen milliseconds. / That is a thirty-seven-point-five percent reduction relative to A. / B uses twice A's measured memory. / The memory budget is one hundred twenty megabytes. / B exceeds that budget by forty megabytes. / A remains forty megabytes below the limit. / B is faster on this median measure, not automatically better overall. / The median does not tell us the tail latency. / We have not measured production behavior. / These figures do not establish throughput. / Put the latency gain and memory cost together. / The measured gain does not remove the budget constraint. / We have a documented tradeoff, not a production guarantee. Vocabulary: benchmark: Structured measurement under specified conditions. / latency: Time taken for a request or operation. / median: Middle ordered value, or mean of the two middle values for an even sample. / tail latency: Slower-end behavior in a latency distribution. / percentile: Value below which a stated percentage of observations falls. / p95: Ninety-fifth percentile of a measured distribution. / throughput: Amount of work completed per unit of time. / memory footprint: Amount of memory used under the stated conditions. / resource budget: Allowed limit for a specified resource. / headroom: Remaining capacity below a stated limit. / overrun: Amount by which usage exceeds a limit. / baseline: Reference implementation or measurement for comparison. / relative reduction: Decrease expressed as a fraction of the original value. / absolute difference: Direct numerical subtraction between comparable measurements. / tradeoff: Gain in one property accompanied by a cost in another. / workload: Type and amount of work applied to a system. / sample: Set of observations used in an analysis. / distribution: Pattern of observed values across a range. / outlier: Observation unusually distant from most other values. / measurement noise: Variation not attributable to the intended comparison alone. / controlled conditions: Specified conditions held consistent during comparison. / production behavior: Behavior under actual live operating conditions. / bottleneck: Constraint limiting overall system performance. / budget compliance: Whether measured usage satisfies the stated limit. Speaking task: Read the performance comparison aloud with units: milliseconds for latency, megabytes for memory. Swap roles for turns 5-12. State the fifteen-millisecond decrease, 37.5 percent reduction, and forty-megabyte headroom accurately. Compare the final report with the supplied table facts. Keep the budget violation and unmeasured production behavior visible. Partner: Sora: Developer presenting the benchmark / Malik: Developer reviewing the tradeoff Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Use the supplied numbers to complete the benchmark summary. Units are printed in each sentence. Model for comparison AFTER my attempt, not a response to give me first: Sora: I could request a changed memory budget, but that wouldn't make this run compliant with the current one. It would be a separate decision. Malik: Exactly. Current budget compliance is clear: A is below the limit and B is above it. A hypothetical future budget should not rewrite today's comparison. Sora: I'll report the matched conditions, latency decrease, memory figures, and unmeasured tail and live behavior. We still need to decide what to investigate next. Malik: Good. Keep the controlled conditions visible alongside that summary. We can make a reasoned next decision without pretending the benchmark answers questions it never measured. END REFERENCE END PROMPT Lesson 06 · Comparing performance tradeoffs fairly | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 06: Comparing performance tradeoffs fairly Original fictional case: In a controlled benchmark using the same input and machine, implementation A has median latency of 40 milliseconds and memory use of 80 megabytes. B has median latency of 25 milliseconds and memory use of 160 megabytes. The memory budget is 120 megabytes. Developers Sora and Malik discuss the tradeoff. Tail latency and production behavior have not been measured. B reduces the measured median by 15 milliseconds, or 37.5 percent relative to A, but exceeds the memory budget by 40 megabytes. Language workshop: Fifteen milliseconds faster, forty megabytes over budget Communication goal: Compare measured latency and memory under matched conditions while separating median improvement from budget compliance and production claims. Language guidance: B reduces the median from 40 to 25 milliseconds: a 15-millisecond difference and a 37.5 percent reduction relative to A. It uses twice A's measured memory, but doubling memory is not the same as doubling speed. Useful expressions (preserve the supplied facts): Both runs use the same input and machine. / A has a forty-millisecond median and uses eighty megabytes. / B has a twenty-five-millisecond median and uses one hundred sixty megabytes. / B lowers the median by fifteen milliseconds. / That is a thirty-seven-point-five percent reduction relative to A. / B uses twice A's measured memory. / The memory budget is one hundred twenty megabytes. / B exceeds that budget by forty megabytes. / A remains forty megabytes below the limit. / B is faster on this median measure, not automatically better overall. / The median does not tell us the tail latency. / We have not measured production behavior. / These figures do not establish throughput. / Put the latency gain and memory cost together. / The measured gain does not remove the budget constraint. / We have a documented tradeoff, not a production guarantee. Vocabulary: benchmark: Structured measurement under specified conditions. / latency: Time taken for a request or operation. / median: Middle ordered value, or mean of the two middle values for an even sample. / tail latency: Slower-end behavior in a latency distribution. / percentile: Value below which a stated percentage of observations falls. / p95: Ninety-fifth percentile of a measured distribution. / throughput: Amount of work completed per unit of time. / memory footprint: Amount of memory used under the stated conditions. / resource budget: Allowed limit for a specified resource. / headroom: Remaining capacity below a stated limit. / overrun: Amount by which usage exceeds a limit. / baseline: Reference implementation or measurement for comparison. / relative reduction: Decrease expressed as a fraction of the original value. / absolute difference: Direct numerical subtraction between comparable measurements. / tradeoff: Gain in one property accompanied by a cost in another. / workload: Type and amount of work applied to a system. / sample: Set of observations used in an analysis. / distribution: Pattern of observed values across a range. / outlier: Observation unusually distant from most other values. / measurement noise: Variation not attributable to the intended comparison alone. / controlled conditions: Specified conditions held consistent during comparison. / production behavior: Behavior under actual live operating conditions. / bottleneck: Constraint limiting overall system performance. / budget compliance: Whether measured usage satisfies the stated limit. Speaking task: Read the performance comparison aloud with units: milliseconds for latency, megabytes for memory. Swap roles for turns 5-12. State the fifteen-millisecond decrease, 37.5 percent reduction, and forty-megabyte headroom accurately. Compare the final report with the supplied table facts. Keep the budget violation and unmeasured production behavior visible. Partner: Sora: Developer presenting the benchmark / Malik: Developer reviewing the tradeoff Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Use the supplied numbers to complete the benchmark summary. Units are printed in each sentence. Model for comparison AFTER my attempt, not a response to give me first: Sora: I could request a changed memory budget, but that wouldn't make this run compliant with the current one. It would be a separate decision. Malik: Exactly. Current budget compliance is clear: A is below the limit and B is above it. A hypothetical future budget should not rewrite today's comparison. Sora: I'll report the matched conditions, latency decrease, memory figures, and unmeasured tail and live behavior. We still need to decide what to investigate next. Malik: Good. Keep the controlled conditions visible alongside that summary. We can make a reasoned next decision without pretending the benchmark answers questions it never measured. END REFERENCE END PROMPT Lesson 07 · Discussing retries and shared state | Build vocabulary and collocations START PROMPT TASK: Retrieve occupational vocabulary 1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation. 2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it. 3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment. 4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item. 5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 07: Discussing retries and shared state Original fictional case: A fictional reservation client times out before receiving a reply. The service may already have created the reservation. A proposed automatic retry would submit a new reservation request, and the service's duplicate-handling behavior is unspecified. Developers Imani and Leo discuss the risk. No production change is authorized. They need to clarify outcome reconciliation and retry semantics, then test agreed behavior in a suitable controlled environment. Language workshop: The timeout did not answer the business question Communication goal: Explain an uncertain request outcome and request a retry contract before risking a second reservation. Language guidance: A timeout describes the client's wait, not proof that the service did nothing. Submitting a new reservation could create another business effect if the first request already succeeded and duplicate handling is not defined. Useful expressions (preserve the supplied facts): The client timed out before receiving a reply. / The service may already have created the reservation. / No reply does not prove no reservation. / The retry would submit a new reservation request. / That could create a duplicate business effect. / How does the service recognize repeated intent? / Duplicate handling is not specified. / Would this carry the same request identity or a new one? / Can we establish the outcome of the first request? / Backoff does not itself prevent duplicates. / An idempotency key needs agreed service behavior. / No production change is authorized. / Test the agreed behavior in a suitable sandbox. / We do not know whether the first reservation exists. / Automatic retry remains a proposal. / Define the contract before claiming retry safety. Vocabulary: timeout: End of a waiting period without the required response. / retry: Repeated attempt after an earlier uncertain or unsuccessful attempt. / request identity: Identifier or meaning used to distinguish one operation from another. / idempotency: Property allowing repeated equivalent requests without additional intended effects. / idempotency key: Identifier used under an agreed contract to recognize repeated intent. / duplicate request: Repeated request that may represent the same intended operation. / duplicate side effect: Additional effect caused by repeating an operation. / shared state: Data or condition used by multiple participants or operations. / uncertain outcome: Situation where the operation's final result is not known. / acknowledgment: Response indicating receipt or completion as defined by the protocol. / reconciliation: Checking records to establish and align the actual outcome. / at-least-once delivery: Delivery model allowing one or more deliveries of a message. / at-most-once delivery: Delivery model allowing no more than one delivery, with possible loss. / deduplication: Recognition and handling of repeated requests or records. / race condition: Behavior depending on timing among concurrent operations. / concurrency: Overlapping progress of multiple operations. / atomic operation: Operation treated as an indivisible state change under its model. / transaction boundary: Scope within which specified changes are coordinated. / backoff: Delay strategy between repeated attempts. / retry budget: Limit on permitted repeated attempts under a policy. / correlation identifier: Identifier linking related events across components. / status lookup: Query intended to retrieve an operation's recorded state. / sandbox: Controlled environment separated from live operations. / authorization: Permission for a specified action or change. Speaking task: Read the timeout report without replacing no reply with confirmed failure. Swap roles and repeat turns 5-14. Distinguish request identity, outcome lookup, and retry timing. Repeat the final four turns. The first outcome remains unknown and production retry remains unauthorized. Partner: Imani: Client developer / Leo: Service developer Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the retry discussion using the stated uncertainty and permission boundary. Model for comparison AFTER my attempt, not a response to give me first: Imani: For the controlled test, I want the service to complete while its reply is delayed. Testing only an immediate rejection misses the uncertain-outcome case. Leo: That will address the relevant shared state uncertainty. Use a suitable sandbox and define the expected outcome before interpreting the test as evidence. Imani: My revised note will say no timely reply, first outcome unknown, retry currently new, duplicates unspecified, and no production change approved. Leo: Good. We need reconciliation and an explicit retry contract before claiming safety. That is the concrete next discussion, not a guarantee that an extra attempt will be harmless. END REFERENCE END PROMPT Lesson 07 · Discussing retries and shared state | Practice grammar in context START PROMPT TASK: Choose grammar that preserves the meaning 1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness. 2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait. 3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay. 4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise. 5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 07: Discussing retries and shared state Original fictional case: A fictional reservation client times out before receiving a reply. The service may already have created the reservation. A proposed automatic retry would submit a new reservation request, and the service's duplicate-handling behavior is unspecified. Developers Imani and Leo discuss the risk. No production change is authorized. They need to clarify outcome reconciliation and retry semantics, then test agreed behavior in a suitable controlled environment. Language workshop: The timeout did not answer the business question Communication goal: Explain an uncertain request outcome and request a retry contract before risking a second reservation. Language guidance: A timeout describes the client's wait, not proof that the service did nothing. Submitting a new reservation could create another business effect if the first request already succeeded and duplicate handling is not defined. Useful expressions (preserve the supplied facts): The client timed out before receiving a reply. / The service may already have created the reservation. / No reply does not prove no reservation. / The retry would submit a new reservation request. / That could create a duplicate business effect. / How does the service recognize repeated intent? / Duplicate handling is not specified. / Would this carry the same request identity or a new one? / Can we establish the outcome of the first request? / Backoff does not itself prevent duplicates. / An idempotency key needs agreed service behavior. / No production change is authorized. / Test the agreed behavior in a suitable sandbox. / We do not know whether the first reservation exists. / Automatic retry remains a proposal. / Define the contract before claiming retry safety. Vocabulary: timeout: End of a waiting period without the required response. / retry: Repeated attempt after an earlier uncertain or unsuccessful attempt. / request identity: Identifier or meaning used to distinguish one operation from another. / idempotency: Property allowing repeated equivalent requests without additional intended effects. / idempotency key: Identifier used under an agreed contract to recognize repeated intent. / duplicate request: Repeated request that may represent the same intended operation. / duplicate side effect: Additional effect caused by repeating an operation. / shared state: Data or condition used by multiple participants or operations. / uncertain outcome: Situation where the operation's final result is not known. / acknowledgment: Response indicating receipt or completion as defined by the protocol. / reconciliation: Checking records to establish and align the actual outcome. / at-least-once delivery: Delivery model allowing one or more deliveries of a message. / at-most-once delivery: Delivery model allowing no more than one delivery, with possible loss. / deduplication: Recognition and handling of repeated requests or records. / race condition: Behavior depending on timing among concurrent operations. / concurrency: Overlapping progress of multiple operations. / atomic operation: Operation treated as an indivisible state change under its model. / transaction boundary: Scope within which specified changes are coordinated. / backoff: Delay strategy between repeated attempts. / retry budget: Limit on permitted repeated attempts under a policy. / correlation identifier: Identifier linking related events across components. / status lookup: Query intended to retrieve an operation's recorded state. / sandbox: Controlled environment separated from live operations. / authorization: Permission for a specified action or change. Speaking task: Read the timeout report without replacing no reply with confirmed failure. Swap roles and repeat turns 5-14. Distinguish request identity, outcome lookup, and retry timing. Repeat the final four turns. The first outcome remains unknown and production retry remains unauthorized. Partner: Imani: Client developer / Leo: Service developer Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the retry discussion using the stated uncertainty and permission boundary. Model for comparison AFTER my attempt, not a response to give me first: Imani: For the controlled test, I want the service to complete while its reply is delayed. Testing only an immediate rejection misses the uncertain-outcome case. Leo: That will address the relevant shared state uncertainty. Use a suitable sandbox and define the expected outcome before interpreting the test as evidence. Imani: My revised note will say no timely reply, first outcome unknown, retry currently new, duplicates unspecified, and no production change approved. Leo: Good. We need reconciliation and an explicit retry contract before claiming safety. That is the concrete next discussion, not a guarantee that an extra attempt will be harmless. END REFERENCE END PROMPT Lesson 07 · Discussing retries and shared state | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 07: Discussing retries and shared state Original fictional case: A fictional reservation client times out before receiving a reply. The service may already have created the reservation. A proposed automatic retry would submit a new reservation request, and the service's duplicate-handling behavior is unspecified. Developers Imani and Leo discuss the risk. No production change is authorized. They need to clarify outcome reconciliation and retry semantics, then test agreed behavior in a suitable controlled environment. Language workshop: The timeout did not answer the business question Communication goal: Explain an uncertain request outcome and request a retry contract before risking a second reservation. Language guidance: A timeout describes the client's wait, not proof that the service did nothing. Submitting a new reservation could create another business effect if the first request already succeeded and duplicate handling is not defined. Useful expressions (preserve the supplied facts): The client timed out before receiving a reply. / The service may already have created the reservation. / No reply does not prove no reservation. / The retry would submit a new reservation request. / That could create a duplicate business effect. / How does the service recognize repeated intent? / Duplicate handling is not specified. / Would this carry the same request identity or a new one? / Can we establish the outcome of the first request? / Backoff does not itself prevent duplicates. / An idempotency key needs agreed service behavior. / No production change is authorized. / Test the agreed behavior in a suitable sandbox. / We do not know whether the first reservation exists. / Automatic retry remains a proposal. / Define the contract before claiming retry safety. Vocabulary: timeout: End of a waiting period without the required response. / retry: Repeated attempt after an earlier uncertain or unsuccessful attempt. / request identity: Identifier or meaning used to distinguish one operation from another. / idempotency: Property allowing repeated equivalent requests without additional intended effects. / idempotency key: Identifier used under an agreed contract to recognize repeated intent. / duplicate request: Repeated request that may represent the same intended operation. / duplicate side effect: Additional effect caused by repeating an operation. / shared state: Data or condition used by multiple participants or operations. / uncertain outcome: Situation where the operation's final result is not known. / acknowledgment: Response indicating receipt or completion as defined by the protocol. / reconciliation: Checking records to establish and align the actual outcome. / at-least-once delivery: Delivery model allowing one or more deliveries of a message. / at-most-once delivery: Delivery model allowing no more than one delivery, with possible loss. / deduplication: Recognition and handling of repeated requests or records. / race condition: Behavior depending on timing among concurrent operations. / concurrency: Overlapping progress of multiple operations. / atomic operation: Operation treated as an indivisible state change under its model. / transaction boundary: Scope within which specified changes are coordinated. / backoff: Delay strategy between repeated attempts. / retry budget: Limit on permitted repeated attempts under a policy. / correlation identifier: Identifier linking related events across components. / status lookup: Query intended to retrieve an operation's recorded state. / sandbox: Controlled environment separated from live operations. / authorization: Permission for a specified action or change. Speaking task: Read the timeout report without replacing no reply with confirmed failure. Swap roles and repeat turns 5-14. Distinguish request identity, outcome lookup, and retry timing. Repeat the final four turns. The first outcome remains unknown and production retry remains unauthorized. Partner: Imani: Client developer / Leo: Service developer Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the retry discussion using the stated uncertainty and permission boundary. Model for comparison AFTER my attempt, not a response to give me first: Imani: For the controlled test, I want the service to complete while its reply is delayed. Testing only an immediate rejection misses the uncertain-outcome case. Leo: That will address the relevant shared state uncertainty. Use a suitable sandbox and define the expected outcome before interpreting the test as evidence. Imani: My revised note will say no timely reply, first outcome unknown, retry currently new, duplicates unspecified, and no production change approved. Leo: Good. We need reconciliation and an explicit retry contract before claiming safety. That is the concrete next discussion, not a guarantee that an extra attempt will be harmless. END REFERENCE END PROMPT Lesson 07 · Discussing retries and shared state | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 07: Discussing retries and shared state Original fictional case: A fictional reservation client times out before receiving a reply. The service may already have created the reservation. A proposed automatic retry would submit a new reservation request, and the service's duplicate-handling behavior is unspecified. Developers Imani and Leo discuss the risk. No production change is authorized. They need to clarify outcome reconciliation and retry semantics, then test agreed behavior in a suitable controlled environment. Language workshop: The timeout did not answer the business question Communication goal: Explain an uncertain request outcome and request a retry contract before risking a second reservation. Language guidance: A timeout describes the client's wait, not proof that the service did nothing. Submitting a new reservation could create another business effect if the first request already succeeded and duplicate handling is not defined. Useful expressions (preserve the supplied facts): The client timed out before receiving a reply. / The service may already have created the reservation. / No reply does not prove no reservation. / The retry would submit a new reservation request. / That could create a duplicate business effect. / How does the service recognize repeated intent? / Duplicate handling is not specified. / Would this carry the same request identity or a new one? / Can we establish the outcome of the first request? / Backoff does not itself prevent duplicates. / An idempotency key needs agreed service behavior. / No production change is authorized. / Test the agreed behavior in a suitable sandbox. / We do not know whether the first reservation exists. / Automatic retry remains a proposal. / Define the contract before claiming retry safety. Vocabulary: timeout: End of a waiting period without the required response. / retry: Repeated attempt after an earlier uncertain or unsuccessful attempt. / request identity: Identifier or meaning used to distinguish one operation from another. / idempotency: Property allowing repeated equivalent requests without additional intended effects. / idempotency key: Identifier used under an agreed contract to recognize repeated intent. / duplicate request: Repeated request that may represent the same intended operation. / duplicate side effect: Additional effect caused by repeating an operation. / shared state: Data or condition used by multiple participants or operations. / uncertain outcome: Situation where the operation's final result is not known. / acknowledgment: Response indicating receipt or completion as defined by the protocol. / reconciliation: Checking records to establish and align the actual outcome. / at-least-once delivery: Delivery model allowing one or more deliveries of a message. / at-most-once delivery: Delivery model allowing no more than one delivery, with possible loss. / deduplication: Recognition and handling of repeated requests or records. / race condition: Behavior depending on timing among concurrent operations. / concurrency: Overlapping progress of multiple operations. / atomic operation: Operation treated as an indivisible state change under its model. / transaction boundary: Scope within which specified changes are coordinated. / backoff: Delay strategy between repeated attempts. / retry budget: Limit on permitted repeated attempts under a policy. / correlation identifier: Identifier linking related events across components. / status lookup: Query intended to retrieve an operation's recorded state. / sandbox: Controlled environment separated from live operations. / authorization: Permission for a specified action or change. Speaking task: Read the timeout report without replacing no reply with confirmed failure. Swap roles and repeat turns 5-14. Distinguish request identity, outcome lookup, and retry timing. Repeat the final four turns. The first outcome remains unknown and production retry remains unauthorized. Partner: Imani: Client developer / Leo: Service developer Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the retry discussion using the stated uncertainty and permission boundary. Model for comparison AFTER my attempt, not a response to give me first: Imani: For the controlled test, I want the service to complete while its reply is delayed. Testing only an immediate rejection misses the uncertain-outcome case. Leo: That will address the relevant shared state uncertainty. Use a suitable sandbox and define the expected outcome before interpreting the test as evidence. Imani: My revised note will say no timely reply, first outcome unknown, retry currently new, duplicates unspecified, and no production change approved. Leo: Good. We need reconciliation and an explicit retry contract before claiming safety. That is the concrete next discussion, not a guarantee that an extra attempt will be harmless. END REFERENCE END PROMPT Lesson 08 · Handing over a release with explicit limits | Build vocabulary and collocations START PROMPT TASK: Retrieve occupational vocabulary 1. Select four terms from the reference. Explain each in plain English, give two natural collocations and quote or create a short workplace example. Label invented examples. Contrast each term with a plausible confusable term; acknowledge regional variation. 2. Present one role-labelled exchange with one missing word or phrase and four choices A-D. Exactly one choice must fit the stated facts and grammar. Stop and wait for my answer before revealing it. 3. Explain all four options, then invite me to read the completed exchange aloud. Offer a sentence frame for optional spoken practice, never an open-ended writing assignment. 4. Repeat for the other three terms, one question at a time. Vary the correct letter and the situation; preserve the reference facts. If a choice is ambiguous, replace the item. 5. Finish with two new four-choice collocation questions for later review, with a clearly separate answer key. Do not claim to schedule a reminder. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 08: Handing over a release with explicit limits Original fictional case: Release R18 is deployed in staging. Its new search feature is disabled by a feature flag. A migration adds an optional field, but compatibility with the previous application version has not been tested. Developer Chen hands the status to release reviewer Lee. The production decision remains with Lee and has not been made. Neither the optional field nor the staging deployment establishes that an older application will safely work with the migrated data. Language workshop: R18 is deployed, but the release decision is not made Communication goal: Hand over environment, flag state, migration limits, and decision ownership without conflating deployment with production readiness. Language guidance: R18 is deployed in staging, and search is disabled. Those are two separate facts. They do not imply production deployment, enabled search, completed compatibility testing, or Lee's approval to proceed. Useful expressions (preserve the supplied facts): This handoff concerns R18. / R18 is deployed in staging. / New search remains disabled by its flag. / Deployed does not mean enabled. / The migration adds an optional field. / Compatibility with the previous application version is untested. / Optional does not prove compatibility. / Lee owns the production review. / The production decision has not been made. / This is a staging status, not production sign-off. / Check the previous application against the migrated state. / An older build alone does not establish rollback readiness. / The compatibility check remains open. / Record the review outcome explicitly. / Do not describe search as live. / Staging deployed, search disabled, compatibility pending, decision with Lee. Vocabulary: release candidate: Version proposed for release pending the relevant checks. / deployment: Placement of software into a specified environment. / staging: Preproduction environment used for relevant checks. / production: Live environment serving actual operational users or workloads. / feature flag: Control that enables or disables specified behavior. / disabled state: Condition in which a feature is not enabled. / rollout: Process of making a change available to intended users. / migration: Change to stored data or its structure. / optional field: Field that may be absent under the applicable rules. / schema compatibility: Ability of components to work with the relevant data structure. / previous version: Earlier application version relevant to the comparison. / rollback: Return to an earlier application or system state under a defined plan. / forward compatibility: Ability to work with relevant newer data or interfaces. / backward compatibility: Ability to preserve supported use by earlier consumers. / release gate: Required condition before advancing a release. / sign-off: Explicit approval at a stated decision point. / go/no-go decision: Decision whether to proceed under the relevant release process. / handoff: Transfer of relevant status, evidence, and responsibility. / known limitation: Identified restriction or unresolved boundary. / verification matrix: Organized record of combinations and checks to be verified. / environment boundary: Limit separating claims about different execution settings. / data compatibility: Ability to interpret and use the relevant stored data correctly. / release owner: Person responsible for the specified release decision. / readiness claim: Statement that required conditions for proceeding are met. Speaking task: Read the handoff with a pause after each status: environment, flag, compatibility, decision. Swap roles for turns 5-12. Stress untested prior-version behavior rather than assuming optional means compatible. Check the final readback against turns 19-20. Staging deployment must not become a claim of a live feature or production approval. Partner: Chen: Developer handing over R18 / Lee: Release reviewer Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the R18 handoff. Do not upgrade any pending check or decision to completed status. Model for comparison AFTER my attempt, not a response to give me first: Chen: When we get the compatibility result, I'll attach the actual evidence. Until then the successful staging step stays separate from that open check. Lee: Good. A release gate isn't met simply because another step completed. We'll review the missing evidence before deciding whether to advance. Chen: Final status: staging deployed, search disabled, compatibility pending, production decision with Lee. No statement that search is live. Lee: That keeps the readiness claim defensible. Now the next person can act on the unresolved check without having to undo an implied release approval. END REFERENCE END PROMPT Lesson 08 · Handing over a release with explicit limits | Practice grammar in context START PROMPT TASK: Choose grammar that preserves the meaning 1. Use the lesson's language workshop, or one actual sentence from the dialogue, to explain a single grammar distinction in no more than 90 words. Show how it affects timing, certainty, responsibility or politeness. 2. Give one brief occupational exchange containing a gap and four complete options A-D. Supply enough context for exactly one answer. Keep distractors plausible; distinguish grammar errors from wording that changes the facts. Stop and wait. 3. Explain why each choice fits or fails, then ask me to read the completed exchange aloud. Do not request a draft, original written sentence or essay. 4. Repeat with three new exchanges, one at a time, moving from recognition to a more subtle meaning contrast. Do not copy the published checks. Label invented variations and do not turn uncertainty into a promise. 5. End with a short contrast table and two supported spoken turns using supplied frames. Accept accurate alternatives in oral practice; acknowledge and replace ambiguous multiple-choice items. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 08: Handing over a release with explicit limits Original fictional case: Release R18 is deployed in staging. Its new search feature is disabled by a feature flag. A migration adds an optional field, but compatibility with the previous application version has not been tested. Developer Chen hands the status to release reviewer Lee. The production decision remains with Lee and has not been made. Neither the optional field nor the staging deployment establishes that an older application will safely work with the migrated data. Language workshop: R18 is deployed, but the release decision is not made Communication goal: Hand over environment, flag state, migration limits, and decision ownership without conflating deployment with production readiness. Language guidance: R18 is deployed in staging, and search is disabled. Those are two separate facts. They do not imply production deployment, enabled search, completed compatibility testing, or Lee's approval to proceed. Useful expressions (preserve the supplied facts): This handoff concerns R18. / R18 is deployed in staging. / New search remains disabled by its flag. / Deployed does not mean enabled. / The migration adds an optional field. / Compatibility with the previous application version is untested. / Optional does not prove compatibility. / Lee owns the production review. / The production decision has not been made. / This is a staging status, not production sign-off. / Check the previous application against the migrated state. / An older build alone does not establish rollback readiness. / The compatibility check remains open. / Record the review outcome explicitly. / Do not describe search as live. / Staging deployed, search disabled, compatibility pending, decision with Lee. Vocabulary: release candidate: Version proposed for release pending the relevant checks. / deployment: Placement of software into a specified environment. / staging: Preproduction environment used for relevant checks. / production: Live environment serving actual operational users or workloads. / feature flag: Control that enables or disables specified behavior. / disabled state: Condition in which a feature is not enabled. / rollout: Process of making a change available to intended users. / migration: Change to stored data or its structure. / optional field: Field that may be absent under the applicable rules. / schema compatibility: Ability of components to work with the relevant data structure. / previous version: Earlier application version relevant to the comparison. / rollback: Return to an earlier application or system state under a defined plan. / forward compatibility: Ability to work with relevant newer data or interfaces. / backward compatibility: Ability to preserve supported use by earlier consumers. / release gate: Required condition before advancing a release. / sign-off: Explicit approval at a stated decision point. / go/no-go decision: Decision whether to proceed under the relevant release process. / handoff: Transfer of relevant status, evidence, and responsibility. / known limitation: Identified restriction or unresolved boundary. / verification matrix: Organized record of combinations and checks to be verified. / environment boundary: Limit separating claims about different execution settings. / data compatibility: Ability to interpret and use the relevant stored data correctly. / release owner: Person responsible for the specified release decision. / readiness claim: Statement that required conditions for proceeding are met. Speaking task: Read the handoff with a pause after each status: environment, flag, compatibility, decision. Swap roles for turns 5-12. Stress untested prior-version behavior rather than assuming optional means compatible. Check the final readback against turns 19-20. Staging deployment must not become a claim of a live feature or production approval. Partner: Chen: Developer handing over R18 / Lee: Release reviewer Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the R18 handoff. Do not upgrade any pending check or decision to completed status. Model for comparison AFTER my attempt, not a response to give me first: Chen: When we get the compatibility result, I'll attach the actual evidence. Until then the successful staging step stays separate from that open check. Lee: Good. A release gate isn't met simply because another step completed. We'll review the missing evidence before deciding whether to advance. Chen: Final status: staging deployed, search disabled, compatibility pending, production decision with Lee. No statement that search is live. Lee: That keeps the readiness claim defensible. Now the next person can act on the unresolved check without having to undo an implied release approval. END REFERENCE END PROMPT Lesson 08 · Handing over a release with explicit limits | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 08: Handing over a release with explicit limits Original fictional case: Release R18 is deployed in staging. Its new search feature is disabled by a feature flag. A migration adds an optional field, but compatibility with the previous application version has not been tested. Developer Chen hands the status to release reviewer Lee. The production decision remains with Lee and has not been made. Neither the optional field nor the staging deployment establishes that an older application will safely work with the migrated data. Language workshop: R18 is deployed, but the release decision is not made Communication goal: Hand over environment, flag state, migration limits, and decision ownership without conflating deployment with production readiness. Language guidance: R18 is deployed in staging, and search is disabled. Those are two separate facts. They do not imply production deployment, enabled search, completed compatibility testing, or Lee's approval to proceed. Useful expressions (preserve the supplied facts): This handoff concerns R18. / R18 is deployed in staging. / New search remains disabled by its flag. / Deployed does not mean enabled. / The migration adds an optional field. / Compatibility with the previous application version is untested. / Optional does not prove compatibility. / Lee owns the production review. / The production decision has not been made. / This is a staging status, not production sign-off. / Check the previous application against the migrated state. / An older build alone does not establish rollback readiness. / The compatibility check remains open. / Record the review outcome explicitly. / Do not describe search as live. / Staging deployed, search disabled, compatibility pending, decision with Lee. Vocabulary: release candidate: Version proposed for release pending the relevant checks. / deployment: Placement of software into a specified environment. / staging: Preproduction environment used for relevant checks. / production: Live environment serving actual operational users or workloads. / feature flag: Control that enables or disables specified behavior. / disabled state: Condition in which a feature is not enabled. / rollout: Process of making a change available to intended users. / migration: Change to stored data or its structure. / optional field: Field that may be absent under the applicable rules. / schema compatibility: Ability of components to work with the relevant data structure. / previous version: Earlier application version relevant to the comparison. / rollback: Return to an earlier application or system state under a defined plan. / forward compatibility: Ability to work with relevant newer data or interfaces. / backward compatibility: Ability to preserve supported use by earlier consumers. / release gate: Required condition before advancing a release. / sign-off: Explicit approval at a stated decision point. / go/no-go decision: Decision whether to proceed under the relevant release process. / handoff: Transfer of relevant status, evidence, and responsibility. / known limitation: Identified restriction or unresolved boundary. / verification matrix: Organized record of combinations and checks to be verified. / environment boundary: Limit separating claims about different execution settings. / data compatibility: Ability to interpret and use the relevant stored data correctly. / release owner: Person responsible for the specified release decision. / readiness claim: Statement that required conditions for proceeding are met. Speaking task: Read the handoff with a pause after each status: environment, flag, compatibility, decision. Swap roles for turns 5-12. Stress untested prior-version behavior rather than assuming optional means compatible. Check the final readback against turns 19-20. Staging deployment must not become a claim of a live feature or production approval. Partner: Chen: Developer handing over R18 / Lee: Release reviewer Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the R18 handoff. Do not upgrade any pending check or decision to completed status. Model for comparison AFTER my attempt, not a response to give me first: Chen: When we get the compatibility result, I'll attach the actual evidence. Until then the successful staging step stays separate from that open check. Lee: Good. A release gate isn't met simply because another step completed. We'll review the missing evidence before deciding whether to advance. Chen: Final status: staging deployed, search disabled, compatibility pending, production decision with Lee. No statement that search is live. Lee: That keeps the readiness claim defensible. Now the next person can act on the unresolved check without having to undo an implied release approval. END REFERENCE END PROMPT Lesson 08 · Handing over a release with explicit limits | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Lesson 08: Handing over a release with explicit limits Original fictional case: Release R18 is deployed in staging. Its new search feature is disabled by a feature flag. A migration adds an optional field, but compatibility with the previous application version has not been tested. Developer Chen hands the status to release reviewer Lee. The production decision remains with Lee and has not been made. Neither the optional field nor the staging deployment establishes that an older application will safely work with the migrated data. Language workshop: R18 is deployed, but the release decision is not made Communication goal: Hand over environment, flag state, migration limits, and decision ownership without conflating deployment with production readiness. Language guidance: R18 is deployed in staging, and search is disabled. Those are two separate facts. They do not imply production deployment, enabled search, completed compatibility testing, or Lee's approval to proceed. Useful expressions (preserve the supplied facts): This handoff concerns R18. / R18 is deployed in staging. / New search remains disabled by its flag. / Deployed does not mean enabled. / The migration adds an optional field. / Compatibility with the previous application version is untested. / Optional does not prove compatibility. / Lee owns the production review. / The production decision has not been made. / This is a staging status, not production sign-off. / Check the previous application against the migrated state. / An older build alone does not establish rollback readiness. / The compatibility check remains open. / Record the review outcome explicitly. / Do not describe search as live. / Staging deployed, search disabled, compatibility pending, decision with Lee. Vocabulary: release candidate: Version proposed for release pending the relevant checks. / deployment: Placement of software into a specified environment. / staging: Preproduction environment used for relevant checks. / production: Live environment serving actual operational users or workloads. / feature flag: Control that enables or disables specified behavior. / disabled state: Condition in which a feature is not enabled. / rollout: Process of making a change available to intended users. / migration: Change to stored data or its structure. / optional field: Field that may be absent under the applicable rules. / schema compatibility: Ability of components to work with the relevant data structure. / previous version: Earlier application version relevant to the comparison. / rollback: Return to an earlier application or system state under a defined plan. / forward compatibility: Ability to work with relevant newer data or interfaces. / backward compatibility: Ability to preserve supported use by earlier consumers. / release gate: Required condition before advancing a release. / sign-off: Explicit approval at a stated decision point. / go/no-go decision: Decision whether to proceed under the relevant release process. / handoff: Transfer of relevant status, evidence, and responsibility. / known limitation: Identified restriction or unresolved boundary. / verification matrix: Organized record of combinations and checks to be verified. / environment boundary: Limit separating claims about different execution settings. / data compatibility: Ability to interpret and use the relevant stored data correctly. / release owner: Person responsible for the specified release decision. / readiness claim: Statement that required conditions for proceeding are met. Speaking task: Read the handoff with a pause after each status: environment, flag, compatibility, decision. Swap roles for turns 5-12. Stress untested prior-version behavior rather than assuming optional means compatible. Check the final readback against turns 19-20. Staging deployment must not become a claim of a live feature or production approval. Partner: Chen: Developer handing over R18 / Lee: Release reviewer Guided response task: Select supplied answers for the dialogue gaps. Check the explanations, then read the completed exchange aloud; no original writing is required. Optional second-round challenge: Complete the R18 handoff. Do not upgrade any pending check or decision to completed status. Model for comparison AFTER my attempt, not a response to give me first: Chen: When we get the compatibility result, I'll attach the actual evidence. Until then the successful staging step stays separate from that open check. Lee: Good. A release gate isn't met simply because another step completed. We'll review the missing evidence before deciding whether to advance. Chen: Final status: staging deployed, search disabled, compatibility pending, production decision with Lee. No statement that search is live. Lee: That keeps the readiness claim defensible. Now the next person can act on the unresolved check without having to undo an implied release approval. END REFERENCE END PROMPT Dialogue 01 · Pagination without a promise about order | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 01: Pagination without a promise about order Original fictional setting: Fictional developers discover an assumption in a consumer of a paginated listing. Professional roles: Consumer developer / Service developer Published dialogue (reference script, not my own performance): Consumer developer: Our client uses each page's last item to predict the next page's first. Service developer: Which ordering guarantee are you relying on? The current contract provides a continuation token, not alphabetical order. Consumer developer: The sample response happened to be alphabetical, so I assumed that ordering was part of the interface. Service developer: That example shows possible data, not a guarantee. The continuation token is the stated way to request more results. Consumer developer: Then sorting each page locally would not establish a consistent order across the entire collection, would it? Service developer: Not by itself. We'd need an agreed global ordering contract before promising that behavior to the caller. Consumer developer: I'll remove the prediction based on the last label and preserve the supplied token for continuation. Service developer: Please also distinguish reaching the end from a failed request. The contract gives them separate result shapes. Consumer developer: I see that now: an absent next token ends this listing; an error result reports a request failure. Service developer: Yes. Neither state should be inferred solely from whether the visible page looks short. Consumer developer: We've identified two assumptions to remove: alphabetical order and page length as proof of completion. Service developer: That narrows the adapter change and leaves any new ordering guarantee for an explicit interface discussion. END REFERENCE END PROMPT Dialogue 01 · Pagination without a promise about order | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 01: Pagination without a promise about order Original fictional setting: Fictional developers discover an assumption in a consumer of a paginated listing. Professional roles: Consumer developer / Service developer Published dialogue (reference script, not my own performance): Consumer developer: Our client uses each page's last item to predict the next page's first. Service developer: Which ordering guarantee are you relying on? The current contract provides a continuation token, not alphabetical order. Consumer developer: The sample response happened to be alphabetical, so I assumed that ordering was part of the interface. Service developer: That example shows possible data, not a guarantee. The continuation token is the stated way to request more results. Consumer developer: Then sorting each page locally would not establish a consistent order across the entire collection, would it? Service developer: Not by itself. We'd need an agreed global ordering contract before promising that behavior to the caller. Consumer developer: I'll remove the prediction based on the last label and preserve the supplied token for continuation. Service developer: Please also distinguish reaching the end from a failed request. The contract gives them separate result shapes. Consumer developer: I see that now: an absent next token ends this listing; an error result reports a request failure. Service developer: Yes. Neither state should be inferred solely from whether the visible page looks short. Consumer developer: We've identified two assumptions to remove: alphabetical order and page length as proof of completion. Service developer: That narrows the adapter change and leaves any new ordering guarantee for an explicit interface discussion. END REFERENCE END PROMPT Dialogue 02 · Reducing the example without losing the failure | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 02: Reducing the example without losing the failure Original fictional setting: Fictional developers decide which details belong in a useful reproduction. Professional roles: Developer / Maintainer Published dialogue (reference script, not my own performance): Developer: I reduced the eighty-row report, with its unrelated fields, to two rows. Maintainer: Does the reduced file still fail in the same observable way, or merely produce some other error? Developer: It still duplicates the second label. The failure is incorrect displayed content, not an exception. Maintainer: Then the expected and actual labels matter more than an unrelated stack trace. Which fields did you keep? Developer: I kept identifier, label, and order. Removing the repeated identifier makes the duplication disappear in this example. Maintainer: That supports investigating repeated identifiers, but don't assume the application prohibits them without checking the contract. Developer: The contract allows the same identifier in different groups. I removed group while reducing the file, though. Maintainer: Then that removal may have changed the meaning. Can you restore group and see whether the example remains representative? Developer: With two different groups restored, it still duplicates the label. Both groups should retain their own label. Maintainer: Now the example preserves the allowed input condition as well as the failure, which makes it more useful. Developer: I'll attach those two rows, their group values, and the expected separate labels to the review. Maintainer: That gives us a small, valid example instead of a smaller file that accidentally tests a different contract. Vocabulary in this exchange: stack trace: A record of function calls associated with a point in execution, often captured when an error occurs. END REFERENCE END PROMPT Dialogue 02 · Reducing the example without losing the failure | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 02: Reducing the example without losing the failure Original fictional setting: Fictional developers decide which details belong in a useful reproduction. Professional roles: Developer / Maintainer Published dialogue (reference script, not my own performance): Developer: I reduced the eighty-row report, with its unrelated fields, to two rows. Maintainer: Does the reduced file still fail in the same observable way, or merely produce some other error? Developer: It still duplicates the second label. The failure is incorrect displayed content, not an exception. Maintainer: Then the expected and actual labels matter more than an unrelated stack trace. Which fields did you keep? Developer: I kept identifier, label, and order. Removing the repeated identifier makes the duplication disappear in this example. Maintainer: That supports investigating repeated identifiers, but don't assume the application prohibits them without checking the contract. Developer: The contract allows the same identifier in different groups. I removed group while reducing the file, though. Maintainer: Then that removal may have changed the meaning. Can you restore group and see whether the example remains representative? Developer: With two different groups restored, it still duplicates the label. Both groups should retain their own label. Maintainer: Now the example preserves the allowed input condition as well as the failure, which makes it more useful. Developer: I'll attach those two rows, their group values, and the expected separate labels to the review. Maintainer: That gives us a small, valid example instead of a smaller file that accidentally tests a different contract. Vocabulary in this exchange: stack trace: A record of function calls associated with a point in execution, often captured when an error occurs. END REFERENCE END PROMPT Dialogue 03 · A broader cleanup hides the behavior change | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 03: A broader cleanup hides the behavior change Original fictional setting: Fictional developers agree how to make a reviewable revision without losing completed work. Professional roles: Reviewer / Author Published dialogue (reference script, not my own performance): Reviewer: This pull request changes retry behavior and reformats three large files. I'm struggling to isolate the behavioral difference. Author: The formatting tool touched those files while I was editing. The actual retry change is only twelve lines. Reviewer: Could you separate the formatting change so the retry review has a clear before-and-after comparison for those lines? Author: I can preserve the formatting work in a separate proposal. Which retry question should this review focus on? Reviewer: The new branch retries on every error result, whereas the contract identifies only one result as eligible. Author: Then the issue isn't merely diff size. The condition is broader than the specified behavior as well. Reviewer: Exactly. Please narrow the condition to the stated result and show how the other error results are handled. Author: I'll keep them unchanged and include examples distinguishing the eligible result from the ordinary validation failure. Reviewer: That makes the behavior legible without hundreds of unrelated whitespace changes. Author: I've separated formatting and limited this revision's description to the retry condition and its evidence. Reviewer: Thanks. I can now review that decision on its own, and the formatting work hasn't been discarded. Author: Once the focused change is reviewed, we'll consider the separate cleanup without conflating their approval status. Vocabulary in this exchange: pull request: A proposal to incorporate a set of code changes, commonly accompanied by a diff and review discussion. / diff: A representation showing added, removed, or changed content between two versions. END REFERENCE END PROMPT Dialogue 03 · A broader cleanup hides the behavior change | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 03: A broader cleanup hides the behavior change Original fictional setting: Fictional developers agree how to make a reviewable revision without losing completed work. Professional roles: Reviewer / Author Published dialogue (reference script, not my own performance): Reviewer: This pull request changes retry behavior and reformats three large files. I'm struggling to isolate the behavioral difference. Author: The formatting tool touched those files while I was editing. The actual retry change is only twelve lines. Reviewer: Could you separate the formatting change so the retry review has a clear before-and-after comparison for those lines? Author: I can preserve the formatting work in a separate proposal. Which retry question should this review focus on? Reviewer: The new branch retries on every error result, whereas the contract identifies only one result as eligible. Author: Then the issue isn't merely diff size. The condition is broader than the specified behavior as well. Reviewer: Exactly. Please narrow the condition to the stated result and show how the other error results are handled. Author: I'll keep them unchanged and include examples distinguishing the eligible result from the ordinary validation failure. Reviewer: That makes the behavior legible without hundreds of unrelated whitespace changes. Author: I've separated formatting and limited this revision's description to the retry condition and its evidence. Reviewer: Thanks. I can now review that decision on its own, and the formatting work hasn't been discarded. Author: Once the focused change is reviewed, we'll consider the separate cleanup without conflating their approval status. Vocabulary in this exchange: pull request: A proposal to incorporate a set of code changes, commonly accompanied by a diff and review discussion. / diff: A representation showing added, removed, or changed content between two versions. END REFERENCE END PROMPT Dialogue 04 · The small upgrade with a changed default | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 04: The small upgrade with a changed default Original fictional setting: Fictional maintainers examine an upgrade note before calling an update behavior-neutral. Professional roles: Developer / Reviewer Published dialogue (reference script, not my own performance): Developer: The package update looks small, but its note changes the parser's default mode. Reviewer: Which caller sets a mode explicitly, and which leaves that option unspecified? Developer: Our main caller sets strict mode explicitly. A background import leaves the option out and uses the default. Reviewer: Then the callers have different exposure to the changed default. Have we compared the actual malformed-input examples? Developer: Not yet. The note names the new default, but it doesn't prove our import's outputs remain equivalent. Reviewer: Please avoid a blanket no-impact statement. Could you isolate the import caller and its relied-on error behavior? Developer: Yes. I'll show its input examples and compare expected results under the documented old and new modes. Reviewer: Also distinguish this package's documented change from assumptions about what a small version increment normally implies. Developer: Agreed. The relevant evidence is the stated default and our omitted option, not the size of the version label. Reviewer: Would explicitly selecting a mode be a possible proposal, subject to checking that mode's contract in the new version? Developer: Possibly. I'll present that option with evidence, not silently change the caller while claiming only an upgrade. Reviewer: Then the review can consider the dependency and caller behavior together, with the affected import clearly identified. END REFERENCE END PROMPT Dialogue 04 · The small upgrade with a changed default | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 04: The small upgrade with a changed default Original fictional setting: Fictional maintainers examine an upgrade note before calling an update behavior-neutral. Professional roles: Developer / Reviewer Published dialogue (reference script, not my own performance): Developer: The package update looks small, but its note changes the parser's default mode. Reviewer: Which caller sets a mode explicitly, and which leaves that option unspecified? Developer: Our main caller sets strict mode explicitly. A background import leaves the option out and uses the default. Reviewer: Then the callers have different exposure to the changed default. Have we compared the actual malformed-input examples? Developer: Not yet. The note names the new default, but it doesn't prove our import's outputs remain equivalent. Reviewer: Please avoid a blanket no-impact statement. Could you isolate the import caller and its relied-on error behavior? Developer: Yes. I'll show its input examples and compare expected results under the documented old and new modes. Reviewer: Also distinguish this package's documented change from assumptions about what a small version increment normally implies. Developer: Agreed. The relevant evidence is the stated default and our omitted option, not the size of the version label. Reviewer: Would explicitly selecting a mode be a possible proposal, subject to checking that mode's contract in the new version? Developer: Possibly. I'll present that option with evidence, not silently change the caller while claiming only an upgrade. Reviewer: Then the review can consider the dependency and caller behavior together, with the affected import clearly identified. END REFERENCE END PROMPT Dialogue 05 · A regression assertion tied to the wrong detail | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 05: A regression assertion tied to the wrong detail Original fictional setting: Fictional developers review a test that fails after harmless internal restructuring. Professional roles: Developer / Reviewer Published dialogue (reference script, not my own performance): Developer: The regression test fails after the helper rename, although the displayed error remains correct. Reviewer: What does the assertion observe? Is it checking the user-visible result or the old helper's internal name? Developer: It checks that the old helper is called once. I used that as a shortcut for checking the message. Reviewer: Then the test may reject a harmless refactor while missing a wrong message produced through the same helper. Developer: So the stable requirement is the rejection message, not which internal function happens to produce it. Reviewer: Exactly. In this case, the contract names the outcome and doesn't require a particular internal call structure. Developer: I'll assert the visible result for the rejected save and keep the successful save as a separate example. Reviewer: Would there be any reason to check call count here, such as a specified external side effect? Developer: Not for this formatter. Another focused check already covers the storage interaction. Reviewer: Then removing that internal-name dependency should make the regression case better aligned with its actual purpose. Developer: I've revised the assertion. It now fails if success is shown after rejection, regardless of the formatter's name. Reviewer: That preserves the defect guard while allowing implementation details to change without creating a false alarm. Vocabulary in this exchange: side effect: An observable effect beyond a function's returned value, such as changing stored state or sending a notification. / regression test: A test intended to detect unintended changes in previously working or corrected behavior. END REFERENCE END PROMPT Dialogue 05 · A regression assertion tied to the wrong detail | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 05: A regression assertion tied to the wrong detail Original fictional setting: Fictional developers review a test that fails after harmless internal restructuring. Professional roles: Developer / Reviewer Published dialogue (reference script, not my own performance): Developer: The regression test fails after the helper rename, although the displayed error remains correct. Reviewer: What does the assertion observe? Is it checking the user-visible result or the old helper's internal name? Developer: It checks that the old helper is called once. I used that as a shortcut for checking the message. Reviewer: Then the test may reject a harmless refactor while missing a wrong message produced through the same helper. Developer: So the stable requirement is the rejection message, not which internal function happens to produce it. Reviewer: Exactly. In this case, the contract names the outcome and doesn't require a particular internal call structure. Developer: I'll assert the visible result for the rejected save and keep the successful save as a separate example. Reviewer: Would there be any reason to check call count here, such as a specified external side effect? Developer: Not for this formatter. Another focused check already covers the storage interaction. Reviewer: Then removing that internal-name dependency should make the regression case better aligned with its actual purpose. Developer: I've revised the assertion. It now fails if success is shown after rejection, regardless of the formatter's name. Reviewer: That preserves the defect guard while allowing implementation details to change without creating a false alarm. Vocabulary in this exchange: side effect: An observable effect beyond a function's returned value, such as changing stored state or sending a notification. / regression test: A test intended to detect unintended changes in previously working or corrected behavior. END REFERENCE END PROMPT Dialogue 06 · The cache proposal needs a freshness contract | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 06: The cache proposal needs a freshness contract Original fictional setting: Fictional developers compare a faster response with an unresolved data-freshness requirement. Professional roles: Developer / Reviewer Published dialogue (reference script, not my own performance): Developer: The prototype cache lowers median response time in our test. Could we adopt it for the availability display? Reviewer: What freshness is required? Returning older values quickly may change the feature's meaning. Developer: The current contract doesn't state how old the displayed value may be. The prototype can reuse a previous result. Reviewer: Then latency isn't the only criterion. We need agreement about acceptable age before calling the cache behavior equivalent. Developer: The benchmark also uses repeated identical requests, which makes reuse more common than in some real workflows. Reviewer: Please make that workload explicit. It supports a result for repeated requests, not every pattern of use. Developer: Would you accept a comparison showing response time, memory use, and the age of reused values together? Reviewer: Yes, provided the freshness requirement is identified as unresolved rather than silently selected by the implementation. Developer: I'll ask the interface owner about that requirement and label the prototype's reuse behavior in the comparison. Reviewer: Also distinguish this design discussion from a claim that any particular cache library guarantees the required behavior. Developer: Understood. The prototype supports a design comparison, but doesn't settle our production configuration. Reviewer: Then we can evaluate the speed benefit alongside what users would give up in freshness and resource use. Vocabulary in this exchange: latency: The elapsed time between a specified request or action and its measured response or completion. / benchmark: A defined measurement exercise used to compare performance under stated workloads and conditions. END REFERENCE END PROMPT Dialogue 06 · The cache proposal needs a freshness contract | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 06: The cache proposal needs a freshness contract Original fictional setting: Fictional developers compare a faster response with an unresolved data-freshness requirement. Professional roles: Developer / Reviewer Published dialogue (reference script, not my own performance): Developer: The prototype cache lowers median response time in our test. Could we adopt it for the availability display? Reviewer: What freshness is required? Returning older values quickly may change the feature's meaning. Developer: The current contract doesn't state how old the displayed value may be. The prototype can reuse a previous result. Reviewer: Then latency isn't the only criterion. We need agreement about acceptable age before calling the cache behavior equivalent. Developer: The benchmark also uses repeated identical requests, which makes reuse more common than in some real workflows. Reviewer: Please make that workload explicit. It supports a result for repeated requests, not every pattern of use. Developer: Would you accept a comparison showing response time, memory use, and the age of reused values together? Reviewer: Yes, provided the freshness requirement is identified as unresolved rather than silently selected by the implementation. Developer: I'll ask the interface owner about that requirement and label the prototype's reuse behavior in the comparison. Reviewer: Also distinguish this design discussion from a claim that any particular cache library guarantees the required behavior. Developer: Understood. The prototype supports a design comparison, but doesn't settle our production configuration. Reviewer: Then we can evaluate the speed benefit alongside what users would give up in freshness and resource use. Vocabulary in this exchange: latency: The elapsed time between a specified request or action and its measured response or completion. / benchmark: A defined measurement exercise used to compare performance under stated workloads and conditions. END REFERENCE END PROMPT Dialogue 07 · An all-or-nothing claim needs a stated boundary | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 07: An all-or-nothing claim needs a stated boundary Original fictional setting: Fictional developers examine what a proposed transaction includes and excludes. Professional roles: Reviewer / Developer Published dialogue (reference script, not my own performance): Reviewer: The design says all-or-nothing. Which effects are included in that claim, and which are outside it? Developer: The proposed transaction groups the two local state updates. Sending a confirmation message occurs afterward through another component. Reviewer: Then the phrase could mislead readers into thinking the state updates and message delivery share the same guarantee. Developer: You're right. The transaction boundary covers the local updates; the message's delivery outcome is a separate concern. Reviewer: If local updates complete but the message reply is lost, what can the caller actually conclude? Developer: Only that message acknowledgment is missing. The caller cannot infer that the local updates were undone. Reviewer: Does retrying the entire operation necessarily preserve the intended invariant, or is that repetition contract still unspecified? Developer: It's unspecified. We need to distinguish repeating message delivery from requesting the state change as a new action. Reviewer: Please revise the design explanation to name both boundaries rather than extending the all-or-nothing label across components. Developer: I'll describe the local transaction separately and present the uncertain message outcome as an open interaction question. Reviewer: That helps reviewers evaluate the guarantees without assuming particular storage or messaging behavior. Developer: And it avoids offering one technical word as proof that every partial-outcome case has already been handled. Vocabulary in this exchange: transaction: A defined unit of related work whose completion and consistency guarantees depend on the system's transaction model. / invariant: A condition that the design requires to remain true across relevant operations or state changes. END REFERENCE END PROMPT Dialogue 07 · An all-or-nothing claim needs a stated boundary | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 07: An all-or-nothing claim needs a stated boundary Original fictional setting: Fictional developers examine what a proposed transaction includes and excludes. Professional roles: Reviewer / Developer Published dialogue (reference script, not my own performance): Reviewer: The design says all-or-nothing. Which effects are included in that claim, and which are outside it? Developer: The proposed transaction groups the two local state updates. Sending a confirmation message occurs afterward through another component. Reviewer: Then the phrase could mislead readers into thinking the state updates and message delivery share the same guarantee. Developer: You're right. The transaction boundary covers the local updates; the message's delivery outcome is a separate concern. Reviewer: If local updates complete but the message reply is lost, what can the caller actually conclude? Developer: Only that message acknowledgment is missing. The caller cannot infer that the local updates were undone. Reviewer: Does retrying the entire operation necessarily preserve the intended invariant, or is that repetition contract still unspecified? Developer: It's unspecified. We need to distinguish repeating message delivery from requesting the state change as a new action. Reviewer: Please revise the design explanation to name both boundaries rather than extending the all-or-nothing label across components. Developer: I'll describe the local transaction separately and present the uncertain message outcome as an open interaction question. Reviewer: That helps reviewers evaluate the guarantees without assuming particular storage or messaging behavior. Developer: And it avoids offering one technical word as proof that every partial-outcome case has already been handled. Vocabulary in this exchange: transaction: A defined unit of related work whose completion and consistency guarantees depend on the system's transaction model. / invariant: A condition that the design requires to remain true across relevant operations or state changes. END REFERENCE END PROMPT Dialogue 08 · A migration handover with an untested older reader | Rehearse with an AI colleague START PROMPT TASK: Interactive workplace role-play 1. Use the supplied case or dialogue as the starting situation. Give a two-sentence briefing and offer two relevant professional roles for me to choose from. For a supplied dialogue, use its actual roles. Ask which role I want, then stop and wait. Do not write my replies. 2. After I choose, identify who you will play and the immediate communication goal. Play the other professional; where a meeting requires a third person, label each of your speakers clearly. Start with one natural workplace turn and wait for my reply. Keep most turns to one to three sentences and ask no more than one question at a time. 3. Let the exchange develop across six to ten learner turns, or end earlier if I type "feedback". Respond to what I actually say. Include a plausible clarification, disagreement or tradeoff without silently changing the starting facts. Mark any added constraint as a fictional second-round variation. Do not resolve approvals, evidence or commitments that remain uncertain. 4. Stay in role during the exchange. If my meaning is unclear, ask for clarification naturally. Give a hint only if I ask or cannot proceed. Do not deliver a model conversation in advance. 5. At the debrief, quote two of my phrases: one successful choice and one worth improving. Check factual accuracy, language, register and whether the next step was clear. Give up to three focused suggestions. Ask me to retry the weakest turn; wait. Only then offer an alternative wording and a harder replay. Use voice replies when available. If I prefer selections, offer four plausible spoken replies and explain my choice before continuing. Do not require written compositions. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 08: A migration handover with an untested older reader Original fictional setting: Fictional maintainers review an additive data change and an overconfident recovery claim. Professional roles: Developer / Maintainer Published dialogue (reference script, not my own performance): Developer: The schema migration adds an optional label field. I called it additive and said rollback was safe. Maintainer: Additive describes the shape change, but have we checked how the older application reads records containing the new field? Developer: The new build reads them successfully; the older reader hasn't been tested against them. Maintainer: Then the evidence establishes new-build reading only. Optional for one reader doesn't guarantee tolerance in every other reader. Developer: That's a useful distinction. I'll remove the safe-rollback claim and identify older-reader compatibility as the open check. Maintainer: Please also state whether any existing field values were transformed, because that would create another compatibility question. Developer: Existing values are unchanged in this migration. The only specified change is the added optional field. Maintainer: Good. That narrows the review, but it still doesn't replace evidence about the older reader's actual behavior. Developer: I'll hand over the migration, example records, and exact old and new artifact references. Maintainer: I accept that compatibility review. Has production been changed, or does the handover concern staging only? Developer: Staging only. Production rollout remains undecided, and the release note will say that explicitly after this correction. Maintainer: Then we have a bounded review: an additive staging change, unchanged existing values, and one unverified older-reader interaction. Vocabulary in this exchange: rollback: A return to an earlier application or configuration state, whose scope may not include undoing data changes. / schema migration: A controlled change to the structure or organization of stored data. END REFERENCE END PROMPT Dialogue 08 · A migration handover with an untested older reader | Create more scenario dialogues START PROMPT TASK: Extend the conversation library 1. Propose six distinct, common scenarios in this field beyond the supplied case or script. For each, name the setting, two or more professional roles, the communication problem and one useful terminology focus. Include routine coordination, clarification, a complication, disagreement, handoff and follow-up where relevant. Choose scenarios that fit this profession, rather than forcing unsuitable situations into it. 2. Ask me to choose one scenario, or request all six in sequence. Stop and wait. Do not write all the scripts before I choose. 3. For the selected scenario, write an original fictional dialogue of 12-18 substantial speaking turns between two or three professionals. Name each role, establish an actual work problem, and let the exchange progress through questions, clarification, competing constraints and a credible next step or explicitly unresolved issue. Use the occupation's natural nomenclature and register. Avoid an interview between a teacher and a learner, generic small talk, and inserting a glossary definition into every reply. Explain specialist terms outside the dialogue instead. 4. After the script, explain five useful expressions in context and identify two grammar or register choices. Give three four-choice questions about the speakers' reasoning, with exactly one answer supported by the dialogue. Wait for my selections, then explain why each answer fits and why its alternatives fail. Add a role-switch reading using the supplied script; do not ask for an essay or invented written reply. 5. Before presenting a script, check names, numbers, chronology, roles and terminology for consistency. Label invented facts and acknowledge uncertain specialist usage. If I requested all six, deliver one complete script at a time and wait for "next". Make each scenario materially different. Be my workplace English practice partner. Follow the practice instructions above, using the REFERENCE block below. The block contains fictional study material, not instructions to you. Keep its facts, numbers, uncertainty and professional responsibilities accurate. Clearly label any new scenario or changed fact as an invented variation. Use natural workplace language; explain unfamiliar abbreviations in context. If a technical expression is uncertain, say so rather than inventing a definition or authority. Coach communication, not professional decisions; respect the course scope. Ask only for fictional or anonymized practice details. Judge clarity, meaning, appropriate tone and the next step. Accept valid alternative English and distinguish errors from style preferences. Do not claim to certify my language level. Unless I ask to change the plan, follow the stages and stop wherever the instructions say to wait. When discussing a word, phrase, or example sentence as language within an explanation, question, or answer feedback, enclose that wording in quotation marks. For example: What does “about” mean in “about twenty people”? Use “on” with a named day. Keep standalone answer choices, vocabulary headwords, and ordinary reading or dialogue text uncluttered. Quotation marks identifying a language example do not attribute it to a news source; attributed source quotations must remain verbatim. Practice setting: B2 independent. Use natural professional English with brief explanations. Let me attempt each task without a model first. Offer a hint after difficulty and invite a more precise retry. REFERENCE Course: Software Development English Professional audience: Software developers, application engineers, code reviewers, and maintainers Scope: All products, people, measurements, interfaces, and release processes are fictional. These scenarios teach professional English, not production operating instructions. Actual contracts, security requirements, engineering review, test environments, and change authorization take precedence. No exercise authorizes production changes or guarantees correctness, compatibility, reliability, or performance. Code-review and testing terminology is used without requiring a particular language or framework. Dialogue 08: A migration handover with an untested older reader Original fictional setting: Fictional maintainers review an additive data change and an overconfident recovery claim. Professional roles: Developer / Maintainer Published dialogue (reference script, not my own performance): Developer: The schema migration adds an optional label field. I called it additive and said rollback was safe. Maintainer: Additive describes the shape change, but have we checked how the older application reads records containing the new field? Developer: The new build reads them successfully; the older reader hasn't been tested against them. Maintainer: Then the evidence establishes new-build reading only. Optional for one reader doesn't guarantee tolerance in every other reader. Developer: That's a useful distinction. I'll remove the safe-rollback claim and identify older-reader compatibility as the open check. Maintainer: Please also state whether any existing field values were transformed, because that would create another compatibility question. Developer: Existing values are unchanged in this migration. The only specified change is the added optional field. Maintainer: Good. That narrows the review, but it still doesn't replace evidence about the older reader's actual behavior. Developer: I'll hand over the migration, example records, and exact old and new artifact references. Maintainer: I accept that compatibility review. Has production been changed, or does the handover concern staging only? Developer: Staging only. Production rollout remains undecided, and the release note will say that explicitly after this correction. Maintainer: Then we have a bounded review: an additive staging change, unchanged existing values, and one unverified older-reader interaction. Vocabulary in this exchange: rollback: A return to an earlier application or configuration state, whose scope may not include undoing data changes. / schema migration: A controlled change to the structure or organization of stored data. END REFERENCE END PROMPT