Software Development English

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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

Copy the full text below into your preferred AI. The material is already included; you do not need to write or improve the 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