diff --git a/README.md b/README.md
index daed93b..366741f 100644
--- a/README.md
+++ b/README.md
@@ -17,7 +17,7 @@ All created via code. Use or repurpose the content to fit your next Dev Day!
 | Child Workflows | Foundations | Java · child workflows | [`segments/14-child-workflows.md`](decks/java-master/segments/14-child-workflows.md) | [`workshops/child-workflows/`](workshops/child-workflows/) | [`child-workflows-java`](https://play.instruqt.com/temporal/tracks/child-workflows-java) | 15 min | Nikolay Advolodkin | Opus 5.5 (100%) | Pending | 3.98 |
 | Continue-As-New | Advanced | Java · event history | [`segments/15-continue-as-new.md`](decks/java-master/segments/15-continue-as-new.md) | [`workshops/continue-as-new-subscription/`](workshops/continue-as-new-subscription/) | [`continue-as-new-java`](https://play.instruqt.com/temporal/tracks/continue-as-new-java) | 10 min | Nikolay Advolodkin | Opus 5.5 (100%) | Pending | 2.86 |
 | Activity Heartbeats | Advanced | Java · activities | [`segments/16-heartbeating.md`](decks/java-master/segments/16-heartbeating.md) | [`workshops/heartbeats-shipment/`](workshops/heartbeats-shipment/) | [`heartbeats-java`](https://play.instruqt.com/temporal/tracks/heartbeats-java) | 10 min | Nikolay Advolodkin | Opus 5.5 (100%) | Pending | 4.45 |
-| Temporal Essentials | Foundations | Java · Workflows, Activities, Workers, Clients, Signals, Queries, Updates, Sagas, versioning, timeouts and retries, observability | [`decks/java-master/`](decks/java-master/) | Deck only; code slides proven in [`snippets/`](decks/java-master/snippets/) | per section, linked in the Deck | Pending | Nikolay Advolodkin | Opus 5.5 (100%) | [112.15](docs/authoring/java-master-deck.md) | — |
+| Temporal Essentials | Foundations | Java · Workflows, Activities, Workers, Clients, Signals, Queries, Updates, Sagas, versioning, timeouts and retries, observability | [`decks/java-master/`](decks/java-master/) | Deck only; code slides proven in [`snippets/`](decks/java-master/snippets/) | one invite link for every lab, in the Deck | Pending | Nikolay Advolodkin | Opus 5.5 (100%) | [112.15](docs/authoring/java-master-deck.md) | — |
 
 **Temporal Essentials is a Deck, not a Workshop**: it has no Track, Exercise or
 Solution of its own, so its Track cost is a dash. It is the Foundations Deck
diff --git a/decks/java-master/components/CopyLink.vue b/decks/java-master/components/CopyLink.vue
new file mode 100644
index 0000000..bdedb0e
--- /dev/null
+++ b/decks/java-master/components/CopyLink.vue
@@ -0,0 +1,82 @@
+<!--
+  ABOUTME: A link with a copy-to-clipboard button beside it, for the lab URL on
+  ABOUTME: the exercise slides.
+
+    <CopyLink href="https://t.mp/ddnov122026" />
+
+  The label defaults to the href without its scheme. Clicks stop here, so
+  pressing the button copies instead of advancing the slide. Copying uses the
+  Clipboard API, with a hidden-textarea fallback for when it is unavailable
+  (an insecure origin, or a browser that refuses).
+-->
+<script setup lang="ts">
+import { computed, ref } from 'vue'
+
+const props = defineProps<{ href: string; label?: string }>()
+const text = computed(() => props.label ?? props.href.replace(/^https?:\/\//, ''))
+const copied = ref(false)
+let timer: ReturnType<typeof setTimeout> | undefined
+
+function fallbackCopy(value: string): void {
+  const area = document.createElement('textarea')
+  area.value = value
+  area.setAttribute('readonly', '')
+  area.style.position = 'fixed'
+  area.style.opacity = '0'
+  document.body.appendChild(area)
+  area.select()
+  document.execCommand('copy')
+  area.remove()
+}
+
+async function copy(): Promise<void> {
+  try {
+    await navigator.clipboard.writeText(props.href)
+  } catch {
+    fallbackCopy(props.href)
+  }
+  copied.value = true
+  clearTimeout(timer)
+  timer = setTimeout(() => (copied.value = false), 1500)
+}
+</script>
+
+<template>
+  <span class="copy-link" @click.stop>
+    <a :href="href" target="_blank" rel="noopener">{{ text }}</a>
+    <button type="button" :class="{ copied }" :aria-label="copied ? 'Copied' : `Copy ${text}`" @click.stop="copy">
+      {{ copied ? 'Copied' : 'Copy' }}
+    </button>
+  </span>
+</template>
+
+<style scoped>
+.copy-link {
+  display: inline-flex;
+  align-items: center;
+  gap: 0.6rem;
+}
+.copy-link a {
+  font-weight: 700;
+}
+button {
+  font-size: 0.7rem;
+  font-weight: 600;
+  letter-spacing: 0.06em;
+  text-transform: uppercase;
+  padding: 0.25rem 0.6rem;
+  border-radius: 999px;
+  border: 1px solid var(--temporal-border-hi);
+  color: var(--temporal-text-strong);
+  background: rgb(154 128 255 / 15%);
+  cursor: pointer;
+}
+button:hover {
+  border-color: var(--temporal-lavender);
+}
+button.copied {
+  color: var(--temporal-green);
+  border-color: var(--temporal-green);
+  background: rgba(89, 253, 160, 0.12);
+}
+</style>
diff --git a/decks/java-master/components/ResumableTransfer.vue b/decks/java-master/components/ResumableTransfer.vue
index d7f615b..b15d8ad 100644
--- a/decks/java-master/components/ResumableTransfer.vue
+++ b/decks/java-master/components/ResumableTransfer.vue
@@ -4,16 +4,18 @@
 
     <ResumableTransfer />
 
-  Slide clicks step through the four engineer actions (the slide needs
-  `clicks: 4`), so arrow keys and a clicker work; each button jumps to its
-  action, and the next one is outlined. Each step shows the CLI command an
+  Slide clicks step through the three engineer actions (the slide needs
+  `clicks: 3`), so arrow keys and a clicker work; each button jumps to its
+  action. The action just performed is outlined, so the button always matches
+  the terminal and the Events beside it; before the first click, a dashed
+  outline points at action 1. Each step shows the CLI command an
   engineer would run, its output, and the Events it adds. Workflow Task events are left out, as the UI's compact
   view does. Everything here matches the resumable package in snippets/
   (TransferWorkflowImpl.java, TransferActivitiesImpl.java) and what
   ResumableTest checks: one attempt on a non-retryable failure, a Query that
-  adds nothing to history, a malformed fix that is recorded but ignored, both
-  Signals in history, the Java SDK's default type names (TransferWorkflow,
-  ExecuteTransfer), and one Workflow run from start to finish.
+  adds nothing to history, a COMPLETED status at the end, the Java SDK's
+  default type names (TransferWorkflow, ExecuteTransfer), and one Workflow run
+  from start to finish.
 -->
 <script setup lang="ts">
 import { computed } from 'vue'
@@ -38,7 +40,6 @@ const STARTED: Row[] = [
   { event: 'ActivityTaskStarted', detail: 'attempt 1', tone: 'plain' },
   { event: 'ActivityTaskFailed', detail: 'AccountNotFoundError · non-retryable', tone: 'fail' },
 ]
-const BAD_FIX: Row = { event: 'WorkflowExecutionSignaled', detail: 'retryWithCorrection "acct 1234"', tone: 'signal' }
 const GOOD_FIX: Row[] = [
   { event: 'WorkflowExecutionSignaled', detail: 'retryWithCorrection "12345678"', tone: 'signal' },
   { event: 'ActivityTaskScheduled', detail: 'ExecuteTransfer → 12345678', tone: 'plain' },
@@ -66,19 +67,14 @@ const STEPS: Step[] = [
     say: 'It tells you exactly where it is stuck. Look at the history: <strong>no new Events</strong>. A Query is a read.',
   },
   {
-    stage: 'parked', status: 'AWAITING_CORRECTION', account: '99999999', rows: [...STARTED, BAD_FIX], fresh: 1,
-    term: { cmd: signal('acct 1234'), out: 'Signal workflow succeeded' },
-    say: 'Typo under pressure. The Signal is <strong>recorded</strong>, but the handler validates the format and drops it. Still parked, no transfer attempted.',
-  },
-  {
-    stage: 'done', status: 'COMPLETED', account: '12345678', rows: [...STARTED, BAD_FIX, ...GOOD_FIX], fresh: GOOD_FIX.length,
+    stage: 'done', status: 'COMPLETED', account: '12345678', rows: [...STARTED, ...GOOD_FIX], fresh: GOOD_FIX.length,
     term: { cmd: signal('12345678'), out: 'Signal workflow succeeded' },
     say: 'The same Workflow wakes up and retries with your fix. <strong>One run, one history</strong>: the failure, your correction and the success, in order. The customer never re-entered anything.',
   },
 ]
 
 // The buttons name the action each click performs, and jump to it when pressed.
-const ACTIONS = ['Send the transfer', 'Query getStatus', 'Signal fix: "acct 1234"', 'Signal fix: "12345678"']
+const ACTIONS = ['Send the transfer', 'Query getStatus', 'Signal fix: "12345678"']
 
 const { $clicks, $page } = useSlideContext()
 const nav = useNav()
@@ -107,7 +103,7 @@ const badge = computed(() => ({ idle: 'Not started', parked: 'Running', done: 'C
         <button
           v-for="(label, i) in ACTIONS"
           :key="label"
-          :class="{ next: i === at, done: i < at }"
+          :class="{ current: i === at - 1, next: at === 0 && i === 0, done: i < at - 1 }"
           @click.stop="go(i + 1)"
         >
           <span class="n">{{ i + 1 }}</span>{{ label }}
@@ -186,9 +182,10 @@ button {
 }
 button:hover { background: rgb(154 128 255 / 35%); }
 button .n { display: inline-block; width: 1.1em; opacity: 0.6; font-variant-numeric: tabular-nums; }
-button.next { box-shadow: 0 0 0 2px var(--temporal-green); }
+button.current { box-shadow: 0 0 0 2px var(--temporal-green); }
+button.next { outline: 2px dashed var(--temporal-green); outline-offset: 1px; }
 button.done { opacity: 0.4; }
-button.reset { grid-column: span 2; text-align: center; background: none; border-color: var(--temporal-border); font-size: 0.6rem; }
+button.reset { text-align: center; background: none; border-color: var(--temporal-border); font-size: 0.6rem; }
 
 .term { background: #0b1020; flex: 1 1 auto; min-height: 4.2rem; }
 .cmd, .out {
diff --git a/decks/java-master/components/WorkflowRun.vue b/decks/java-master/components/WorkflowRun.vue
index 28adaf9..d632a84 100644
--- a/decks/java-master/components/WorkflowRun.vue
+++ b/decks/java-master/components/WorkflowRun.vue
@@ -13,7 +13,8 @@ import { useSlideContext } from '@slidev/client'
 
 type Kind = 'worker' | 'command' | 'event' | 'task'
 type Pill = { icon: string; text: string; mono?: boolean; dim?: boolean }
-type Step = { kind: Kind; lane: number; pills: Pill[]; say: string }
+// `dx` nudges a step right of its slot when its pill is too wide for the gap.
+type Step = { kind: Kind; lane: number; pills: Pill[]; say: string; dx?: number }
 
 const LANES = [
   { icon: '⚙️', label: 'Worker' },
@@ -24,12 +25,12 @@ const LANE_Y = [62, 196, 300]
 const COMMAND_Y = 129
 
 const STEPS: Step[] = [
-  { kind: 'worker', lane: 0, pills: [{ icon: '▶️', text: 'chargeCard()', mono: true }], say: 'Your Workflow code calls the Activity' },
+  { kind: 'worker', lane: 0, pills: [{ icon: '▶️', text: 'activities.chargeCard()', mono: true }], say: 'Your Workflow calls the chargeCard Activity. Nothing runs yet: the call is a request' },
   { kind: 'command', lane: -1, pills: [{ icon: '📨', text: 'ScheduleActivityTask', mono: true }], say: 'The call becomes a Command, sent when the Workflow Task ends' },
   { kind: 'event', lane: 1, pills: [{ icon: '📝', text: 'ActivityTaskScheduled', mono: true }], say: 'The Service writes it down' },
-  { kind: 'task', lane: 2, pills: [{ icon: '🎫', text: 'Activity Task' }], say: 'An Activity Task waits on the queue' },
+  { kind: 'task', lane: 2, pills: [{ icon: '🎫', text: 'Activity Task' }], say: 'An Activity Task waits on the queue: the Activity Type, ChargeCard, and an Activity ID' },
   { kind: 'worker', lane: 0, pills: [{ icon: '🙋', text: 'poll' }], say: 'A Worker polls and takes it' },
-  { kind: 'worker', lane: 0, pills: [{ icon: '💳', text: 'charge' }], say: 'The Worker runs chargeCard' },
+  { kind: 'worker', lane: 0, dx: 30, pills: [{ icon: '💳', text: 'chargeCard runs', mono: true }], say: 'The Worker matches ChargeCard to the method it registered at startup, and runs it' },
   {
     kind: 'event',
     lane: 1,
@@ -40,7 +41,7 @@ const STEPS: Step[] = [
     say: 'The result is recorded. Started is written now too',
   },
   { kind: 'task', lane: 2, pills: [{ icon: '🎫', text: 'Workflow Task' }], say: 'A new Workflow Task wakes the Workflow' },
-  { kind: 'worker', lane: 0, pills: [{ icon: '🔁', text: 'replay → next line' }], say: 'Replay returns the result. The next line runs' },
+  { kind: 'worker', lane: 0, pills: [{ icon: '↩️', text: 'chargeCard() returns' }], say: 'A Worker takes the Workflow Task: activities.chargeCard() returns the result, and the next line runs' },
 ]
 
 const LEGEND: { kind: Kind; label: string }[] = [
@@ -59,7 +60,7 @@ function width(p: Pill): number {
 }
 function centre(i: number): { x: number; y: number } {
   const s = STEPS[i]
-  return { x: X0 + i * DX, y: s.lane < 0 ? COMMAND_Y : LANE_Y[s.lane] }
+  return { x: X0 + i * DX + (s.dx ?? 0), y: s.lane < 0 ? COMMAND_Y : LANE_Y[s.lane] }
 }
 function pillY(i: number, j: number): number {
   const n = STEPS[i].pills.length
diff --git a/decks/java-master/segments/01-why-temporal.md b/decks/java-master/segments/01-why-temporal.md
index 29ade30..cf4740d 100644
--- a/decks/java-master/segments/01-why-temporal.md
+++ b/decks/java-master/segments/01-why-temporal.md
@@ -4,389 +4,379 @@ layout: section
 
 <ZiggyHero scene="juggle">
 
-# Business logic is complex
+# A simple feature
 
-One support ticket, three paths, and everything you write around them.
+Let customers send money. How hard can it be?
 
 </ZiggyHero>
 
 <!--
-Source: PPT slides 4-19.
+The arc of this segment: a feature that fits in two lines, everything
+production does to it, the plumbing you write in response, and then the same
+two lines on Temporal. Everything after this segment is a consequence of that
+last part.
 
-The arc of this segment: show a business process that fits on an index card,
-show the code it actually takes to run it reliably, then show that code
-disappear. Everything after this segment is a consequence of the last slide.
-
-The original opened with a photo of the flow sketched by hand on a hotel
-notepad. It was dropped here because the notepad carries a brand. If you have
-your own sketch of a flow, use it: the point is that the business logic fits on
-a card.
+One example the whole way through: a bank transfer. The Workflows segment and
+the first lab build on the same transfer, so nothing here is thrown away.
 -->
 
 ---
 layout: default
 ---
 
-# One support ticket
+# The feature request
 
-<div class="ticket-flow">
-<div class="path">
-<p class="path-head">Low priority</p>
-<ol>
-<li><code>sendAutoResponse</code></li>
-<li><code>searchKnowledgeBase</code></li>
-<li class="branch">Solution found?<span><b>Yes:</b> <code>notifyCustomer</code></span><span><b>No:</b> <code>assignAgent</code>, <code>resolveTicket</code></span></li>
-</ol>
-</div>
-<div class="path">
-<p class="path-head">Medium priority</p>
-<ol>
-<li><code>assignAgent</code></li>
-<li><code>investigateIssue</code></li>
-<li class="branch">Needs escalation?<span><b>Yes:</b> <code>escalateToEngineering</code></span><span><b>No:</b> <code>resolveTicket</code></span></li>
-</ol>
+<div class="request">
+<p class="request-head">As a customer, I want to send money to another account.</p>
+<div class="steps">
+<div class="step"><span class="n">1</span><span><strong>Withdraw</strong> $500 from Alice</span></div>
+<span class="arrow">→</span>
+<div class="step"><span class="n">2</span><span><strong>Deposit</strong> $500 to Bob</span></div>
 </div>
-<div class="path">
-<p class="path-head">High priority</p>
-<ol>
-<li><code>assignAgent</code> (senior)</li>
-<li><code>escalateToEngineering</code></li>
-<li><code>applyUrgentFix</code></li>
-<li><code>notifyCustomer</code></li>
-<li><code>notifyManagement</code></li>
-</ol>
+<p class="request-done"><strong>Done when:</strong> the money left one account and arrived in the other.</p>
 </div>
-</div>
-
-<p class="ticket-end">Every path ends in <strong>Ticket resolved</strong>.</p>
 
 <style scoped>
-.ticket-flow {
-  display: grid;
-  grid-template-columns: repeat(3, minmax(0, 1fr));
-  gap: 1.25rem;
-  margin-top: 1rem;
-}
-.path {
+.request {
+  margin-top: 1.5rem;
   border: 1px solid var(--temporal-border-hi);
   border-radius: 0.6rem;
-  padding: 0.8rem 1rem;
+  padding: 1.5rem 1.75rem;
 }
-.path-head {
-  text-transform: uppercase;
-  letter-spacing: 0.08em;
-  font-size: 0.8rem;
-  color: var(--temporal-green);
-  margin: 0 0 0.5rem !important;
+.request-head {
+  font-size: 1.3rem;
+  margin: 0 0 1.5rem !important;
+  color: var(--temporal-text-strong);
 }
-.path ol {
-  margin: 0;
-  padding-left: 1.2rem;
+.steps {
+  display: flex;
+  align-items: center;
+  gap: 1.25rem;
 }
-.path li {
-  font-size: 0.95rem;
-  margin: 0.3rem 0;
+.step {
+  flex: 1;
+  display: flex;
+  align-items: center;
+  gap: 0.8rem;
+  border: 1px solid var(--temporal-border-hi);
+  border-radius: 0.5rem;
+  padding: 0.9rem 1rem;
+  font-size: 1.05rem;
 }
-/* The theme sizes inline code for prose; in these narrow columns the longer
-   Activity names would overrun their box. */
-.path code {
-  font-size: 0.72rem;
-  white-space: nowrap;
+.step .n {
+  display: grid;
+  place-items: center;
+  width: 1.8rem;
+  height: 1.8rem;
+  border-radius: 999px;
+  background: rgba(89, 253, 160, 0.15);
+  color: var(--temporal-green);
+  font-weight: 600;
 }
-.branch span {
-  display: block;
-  font-size: 0.85rem;
-  margin-top: 0.15rem;
+.arrow {
+  font-size: 1.6rem;
+  color: var(--temporal-text);
 }
-.ticket-end {
-  margin-top: 1.25rem;
-  text-align: center;
+.request-done {
+  margin: 1.5rem 0 0 !important;
+  font-size: 1rem;
 }
 </style>
 
 <!--
-Source: PPT slide 5. The original was a flowchart image; it is redrawn here as
-three columns.
-
-Walk it left to right, fast. Low priority: auto-respond, search the knowledge
-base, hand to an agent if nothing matches. Medium: assign an agent, investigate,
-escalate if needed. High: senior agent, straight to engineering, urgent fix,
-notify customer and management.
-
-Nobody in the room would call this hard. That is the point. Hold that thought
-for the next slide.
+Read it like a product manager would. One sentence, two steps, one acceptance
+criterion. Ask the room how long they would estimate. Someone will say an
+afternoon. Hold onto that number.
 -->
 
 ---
-layout: big-stat
-value: 268
-unit: lines
-caption: The same flow, written the obvious way
+layout: code-stack
+heading: The happy path
+proseMax: 30
 ---
 
-One class per team, one method that branches on priority, and a sleep between
-every step. It runs. It is also the version that exists before anyone asks what
-happens when a step fails.
+::code::
 
-<!--
-Source: PPT slide 6.
+```java
+public void transfer(Transfer t) {
+  bank.withdraw(t.fromAccount(), t.amount());
+  bank.deposit(t.toAccount(), t.amount());
+}
+```
+
+::default::
 
-The original showed the whole file as an image, deliberately too small to read:
-the size is the argument. 268 lines, for the flow on the previous slide. The
-line counts on this slide and two slides on are from the original deck's
-reference implementation of the ticket flow; the exact number matters less than
-the ratio you are about to see.
+Two lines, and both of them are the feature. The demo works, the tests pass,
+the PR is approved. Ship it?
 
-The original deck's speaker note says the code was generated by an LLM, which
-is worth saying: this is what "just write it" looks like today, and it is a
-perfectly reasonable first draft.
+<!--
+Code: snippets/src/main/java/io/temporal/devdays/essentials/why/HandRolled.java,
+with the retry helper on the next slide. `bank` is the bank's API client.
+
+Let it sit. This is what everyone writes first, and it is correct: it is
+exactly the business requirement. Ask "ship it?" and wait. Someone always says
+"what about errors?" That is the cue for the next slide.
 -->
 
 ---
 layout: default
 ---
 
-# Unspoken requirements…
+# Then it meets production
 
-The flow never says them. Production always does.
+<div class="failures">
+<div v-click class="failure"><p class="what">The bank's API is down</p><p class="then">Every transfer throws for ten minutes. Or hangs, and never returns.</p></div>
+<div v-click class="failure"><p class="what">The process crashes between the two lines</p><p class="then">Alice was debited. Bob was never credited.</p></div>
+<div v-click class="failure"><p class="what">A power outage, or a deploy</p><p class="then">The node goes away mid-transfer, and so does everything in memory.</p></div>
+<div v-click class="failure"><p class="what">A race condition</p><p class="then">Alice double-taps Send. Two requests, two transfers.</p></div>
+<div v-click class="failure"><p class="what">A bug in the deposit code</p><p class="then">Every transfer since the release is stuck halfway.</p></div>
+<div v-click class="failure"><p class="what">Insufficient funds</p><p class="then">Not an outage. Retrying will never fix it.</p></div>
+</div>
 
-- **Retries and checkpoints.** Tightly coupled components, zero fault tolerance.
-- **Visibility.** No audit trail, no in-flight telemetry. Logs are the only
-  thing you have when it breaks.
-- **Execution guarantees.** Data lost on failure or restart. No way to replay
-  what happened.
+<style scoped>
+.failures {
+  display: grid;
+  grid-template-columns: repeat(3, minmax(0, 1fr));
+  gap: 1rem;
+  margin-top: 1.25rem;
+}
+.failure {
+  border: 1px solid var(--temporal-border-hi);
+  border-left: 3px solid #ff6b6b;
+  border-radius: 0.5rem;
+  padding: 0.8rem 1rem;
+}
+.what {
+  font-weight: 600;
+  color: var(--temporal-text-strong);
+  margin: 0 0 0.4rem !important;
+  font-size: 1rem;
+}
+.then {
+  margin: 0 !important;
+  font-size: 0.88rem;
+}
+</style>
 
 <!--
-Source: PPT slide 8.
-
-Ask the room which of these they have been paged for. Someone always has a
-story about the third one: a process restarted mid-ticket and the customer got
-two emails, or none.
-
-These three are the whole value proposition of the next hour. Do not name
-Temporal yet.
+One click per failure. For each, ask the room whether they have been paged for
+it. The second one always gets a story.
+
+- **The bank is down or slow.** The call throws, or worse, never returns.
+- **A crash between the lines.** The money left Alice and never reached Bob.
+  This is the one to land; the next slide is only this.
+- **Power outage, or a deploy.** A rolling deploy is a planned crash. Whatever
+  was in memory is gone.
+- **A race.** A double tap, a mobile retry on a flaky connection, a load
+  balancer replaying a request: two transfers.
+- **A bug.** Not the network: your code. You fix it in an hour. What happens to
+  the transfers that failed in that hour?
+- **Insufficient funds.** The odd one out. Retrying makes it worse, not better.
+  Some errors must never be retried.
 -->
 
 ---
 layout: center
+class: text-center
 ---
 
-# So let's account for those
-
-<!--
-Source: PPT slide 9. A breath before the code. Three seconds, then click on.
--->
-
----
-layout: code-stack
-heading: The naive version
-proseMax: 30
----
-
-::code::
-
-```java
-return fulfillmentService.fulfill(orderId);
-```
-
-::default::
+<p style="font-size: 2.4rem; font-weight: 200; line-height: 1.3">The withdrawal succeeded.<br />Then the process died.</p>
 
-One line. The whole business requirement, and nothing else.
-
-It works right up until the service is down, slow, rate limited, or the process
-is killed halfway through.
+<p v-click style="font-size: 3rem; font-weight: 300; margin-top: 2rem; color: #ff6b6b">$500 left Alice. It never reached Bob.</p>
 
 <!--
-Source: PPT slide 10. Code: snippets/src/main/java/io/temporal/devdays/essentials/why/HandRolledRetry.java,
-with the next two slides.
-
-Let it sit. Ask what is wrong with it. Someone says "no error handling," and
-that is the cue for the next slide.
+Say the first line, pause, click. Nothing in the two-line version remembers
+that the withdrawal happened. When the process comes back, it has no idea
+there is a transfer to finish.
 
-Name the failure people forget: it is not only that the call can throw. The
-process holding this line can die, and nothing remembers the request was made.
+This is not an edge case at scale. Every deploy kills processes mid-request.
 -->
 
 ---
-layout: code-stack
-heading: So you add a retry
-proseMax: 30
+layout: default
 ---
 
-::code::
-
-```java {all|1|3|4-5}
-for (int attempt = 0; attempt < 4; attempt++) {
-  try {
-    return fulfillmentService.fulfill(orderId);
-  } catch (Exception e) {
-    Thread.sleep(5000);
-  }
-}
-```
+# And the questions start
 
-::default::
+<div class="questions">
+<div class="q"><strong>When do we retry?</strong><span>A 503? A timeout? A connection reset?</span></div>
+<div class="q"><strong>When don't we?</strong><span>Insufficient funds. A closed account.</span></div>
+<div class="q"><strong>How many times?</strong><span>Three? Ten? Until it works?</span></div>
+<div class="q"><strong>How long between attempts?</strong><span>Exponential backoff? With jitter? Capped at what?</span></div>
+<div class="q"><strong>Where do we remember how far we got?</strong><span>So a restart does not withdraw twice.</span></div>
+<div class="q"><strong>Who finds out when it never succeeds?</strong><span>And how do they fix it?</span></div>
+</div>
 
-Four attempts, five seconds apart. Fixed count, fixed delay, no backoff, no
-jitter, and no record anywhere of what was tried.
+<style scoped>
+.questions {
+  display: grid;
+  grid-template-columns: repeat(2, minmax(0, 1fr));
+  gap: 0.9rem 1.5rem;
+  margin-top: 1.25rem;
+}
+.q {
+  border: 1px solid var(--temporal-border-hi);
+  border-radius: 0.5rem;
+  padding: 0.75rem 1rem;
+}
+.q strong {
+  display: block;
+  color: var(--temporal-text-strong);
+  font-size: 1.02rem;
+}
+.q span {
+  font-size: 0.88rem;
+}
+</style>
 
 <!--
-Source: PPT slide 11.
-
-- **Build 1 -** four, because four felt right. Nobody tuned this.
-- **Build 2 -** the one line that is the business requirement, now buried two
-  levels deep.
-- **Build 3 -** the catch swallows the error, and the sleep is a hard five
-  seconds whether the service needs 50ms or 50 seconds.
-
-If the process dies inside this loop, every attempt so far is lost and nobody
-knows how far it got. And after the fourth failure the loop simply ends. The
-compiler insists on a return after it, and what usually gets written there is
-`return null`, which is its own bug, found later by somebody else. Point at
-that if someone notices.
+Every one of these is a real decision, and the two-line function answers none
+of them. Read the left column fast, then slow down on the last two: they are
+not about retries at all, and they are the ones that turn a function into a
+system.
+
+None of these questions is about sending money. All of them have to be answered
+before you can ship it.
 -->
 
 ---
 layout: code-stack
-heading: So you add real backoff
+heading: So you add a retry
 proseMax: 30
 ---
 
 ::code::
 
-```java {all|2-3|8-10|14}
-FulfillmentResult fulfillWithRetry(String orderId) throws InterruptedException {
-  long delay = 1000;
-  int maxRetries = 3;
-  for (int attempt = 0; attempt < maxRetries; attempt++) {
+```java {all|7-8|10|11-12|2-3}
+void withRetry(Runnable call) throws InterruptedException {
+  long delay = 1_000;
+  for (int attempt = 1; ; attempt++) {
     try {
-      return fulfillmentService.fulfill(orderId);
-    } catch (Exception e) {
-      if (attempt < maxRetries - 1) {
-        Thread.sleep(delay);
-        delay = Math.min(delay * 2, 30_000);
-      }
+      call.run();
+      return;
+    } catch (InsufficientFundsException e) {
+      throw e;
+    } catch (RuntimeException e) {
+      if (attempt == 5) throw e;
+      Thread.sleep(delay + ThreadLocalRandom.current().nextLong(250));
+      delay = Math.min(delay * 2, 30_000);
     }
   }
-  throw new IllegalStateException("Failed after too many attempts");
 }
 ```
 
 ::default::
 
-A dozen lines of retry policy wrapped around one line of business logic. Still
-in memory, still lost on restart, still no jitter.
+Fifteen lines to answer three of the questions. All of it in memory: when the
+process dies, so do the attempt count, the delay, and the transfer.
 
 <!--
-Source: PPT slide 12.
-
-- **Build 1 -** the tuning knobs, now hard-coded constants someone will have to
-  find and change under pressure.
-- **Build 2 -** the backoff itself, doubling with a ceiling. This is the part
-  people are proud of. It is also identical in every codebase and written
-  slightly wrong in most of them.
-- **Build 3 -** after all that, it gives up. The caller has no idea how many
-  attempts happened or why.
-
-`Thread.sleep` here parks a thread, and the wait lives only in that thread.
-Plant this now, because it matters in about ten slides: in real Workflow code
-you would not write this loop at all, because retries are policy. When a
-Workflow does need to wait, `Workflow.sleep` is a durable Timer that survives
-the process dying. `Thread.sleep` is never allowed inside a Workflow.
-
-The honest summary: this is a good implementation of the wrong idea. Every
-service in the company has its own copy, and none of them survive a restart.
+Code: HandRolled.java. `Thread.sleep` parks a thread, and the wait lives only
+in that thread. It is never allowed inside a Workflow; when a Workflow needs
+to wait, `Workflow.sleep` is a durable Timer.
+
+- **Build 1 - when not to retry.** Insufficient funds is final. Every new
+  error type the bank invents is another line here.
+- **Build 2 - how many times.** Five, because five felt right. Nobody tuned it.
+- **Build 3 - how long between.** Doubling, capped at 30 seconds, with jitter so
+  a thousand failed transfers do not all retry in the same millisecond. This is
+  the part people are proud of. Every service in the company has its own copy,
+  slightly different.
+- **Build 4 - where the state lives.** A local variable. The retry loop is the
+  first thing to die when the process does.
+
+And it answers none of the last three questions on the previous slide.
 -->
 
 ---
 layout: code-walkthrough
-heading: The non-Temporal version
+heading: The plumbing version
 notes:
-  - A <strong>distributed lock</strong>, so two instances never run one order. Die holding it and everyone waits out the TTL
+  - A <strong>distributed lock</strong>, so a double-tap never runs one transfer twice. Die holding it and the transfer waits out the TTL
   - Your own <strong>state table</strong>. Reload progress so a restart skips finished steps
-  - A <strong>checkpoint</strong> around every step. Crash between the reserve and the save, and the stock is held twice
-  - The backoff loop from the last slide, wrapped round every call with <code>withRetry</code>
-  - <strong>Timeouts</strong>, hand-rolled per call with <code>withTimeout</code>
+  - A <strong>checkpoint</strong> around every step. Crash between the withdraw and the save, and Alice is debited twice
+  - The retry helper from the last slide, <code>withRetry</code>, round every call
+  - A <strong>timeout</strong> on every call with <code>withTimeout</code>, so a hung bank cannot hang you
   - An <strong>audit trail</strong> you write, and nobody reads until the incident
   - Failures parked for a human, in a <strong>dead-letter queue</strong> you also run
-  - And a <strong>recovery cron</strong> for the orders that get stuck anyway
+  - And a <strong>recovery cron</strong> for the transfers that get stuck anyway
 ---
 
 ::code::
 
-```java {all|2-3|5|6-9|7|11|13|17-18|24}
-void fulfillOrder(String orderId) {
-  Lock lock = locks.acquire("order:" + orderId, Duration.ofSeconds(30));
+```java {all|2-3|5|6-9|7|7|9|17-18|24}
+void transfer(Transfer t) {
+  Lock lock = locks.acquire(t.transferId(), Duration.ofSeconds(30));
   if (lock == null) return;
   try {
-    OrderState state = db.loadOrderState(orderId);
-    if (!state.isDone(Step.RESERVED)) {
-      withRetry(() -> inventory.reserve(orderId));
-      db.saveStep(orderId, Step.RESERVED);
+    TransferState state = db.loadTransfer(t.transferId());
+    if (!state.isDone(Step.WITHDRAWN)) {
+      withRetry(() -> withTimeout(() -> bank.withdraw(t.fromAccount(), t.amount())));
+      db.saveStep(t.transferId(), Step.WITHDRAWN);
+      audit.append(t.transferId(), "withdrawn");
     }
-    if (!state.isDone(Step.CHARGED)) {
-      String chargeId = withTimeout(() -> payments.charge(orderId), Duration.ofSeconds(10));
-      db.saveStep(orderId, Step.CHARGED, chargeId);
-      audit.append(orderId, "payment-charged", chargeId);
+    if (!state.isDone(Step.DEPOSITED)) {
+      withRetry(() -> withTimeout(() -> bank.deposit(t.toAccount(), t.amount())));
+      db.saveStep(t.transferId(), Step.DEPOSITED);
+      audit.append(t.transferId(), "deposited");
     }
-    // ...and the same again for shipping
   } catch (Exception e) {
-    db.markFailed(orderId, e.toString());
-    deadLetters.push(orderId);
+    db.markFailed(t.transferId(), e.toString());
+    deadLetters.push(t.transferId());
   } finally {
     lock.release();
   }
 }
 
-// RecoveryJob.java: a cron that finds orders stuck mid-flow and re-runs them
+// RecoveryJob.java: a cron that finds transfers stuck halfway and re-runs them
 ```
 
 <!--
 Illustrative, not compiled: the locks, state table, audit log and dead-letter
-queue are the services you would have to build, so there is nothing to compile
-against. It is `fulfillOrder`, the call from the last three slides, as a
-three-step process (reserve, charge, ship) written to survive production
-without Temporal. "The Temporal version"
-shows the same function three slides on; the two are meant to be compared.
-
-Each bubble is one of the unspoken requirements, paid for by hand:
-
-- **Build 1 - the lock.** Two pods pick up the same order; without it, both
-  run it. With it, a pod that crashes holding the lock stalls the order for
-  the TTL.
-- **Build 2 - the state table.** The process remembers nothing, so progress
-  lives in a table you design, migrate and back up.
+queue are services you would have to build, so there is nothing to compile
+against. It is the happy path, written to survive production without Temporal. "The Temporal version" a few slides on is the same transfer;
+the two are meant to be compared.
+
+Each bubble is one of the questions, answered by hand:
+
+- **Build 1 - the lock.** The race condition. Two requests for one transfer;
+  with the lock, only one runs. A pod that crashes holding it stalls the
+  transfer for the TTL.
+- **Build 2 - the state table.** "Where do we remember how far we got?" In a
+  table you design, migrate and back up.
 - **Build 3 - the checkpoint.** Do the step, then record it. The gap between
-  the two lines is where double reservations come from.
-- **Build 4 - the retry.** The backoff from the previous slide, now a helper
-  wrapped round every call.
+  the two lines is exactly the crash from three slides ago, moved one line down.
+  Closing it needs idempotency keys on the bank calls too.
+- **Build 4 - the retry.** The helper from the last slide.
 - **Build 5 - the timeout.** Another helper. Pick a number for every call.
-- **Build 6 - the audit trail.** The visibility requirement, as rows you write
-  yourself.
-- **Build 7 - failure handling.** Something has to catch what the retries
-  could not fix, and someone has to drain it.
+- **Build 6 - the audit trail.** So someone can answer "what happened to my
+  money?" Rows you write yourself.
+- **Build 7 - failure handling.** "Who finds out when it never succeeds?" A
+  queue, and someone to drain it.
 - **Build 8 - recovery.** For everything above that still goes wrong: a second
   program whose only job is finding the first one's stuck work.
 
-That is two of the three steps. The next slide is what a whole flow costs.
+The bug from the failures slide is still not handled: a transfer that hit the
+bad deposit code is now in the dead-letter queue, and someone replays it by
+hand after the fix ships.
 -->
 
 ---
 layout: default
 ---
 
-# Most of the code is not the business
+# Most of the code is not the feature
 
 <div class="grid grid-cols-2 gap-10 mt-8">
 <div>
-<p class="loc-eyebrow">Naive</p>
-<p class="loc-count">268 <span>lines</span></p>
-<p><strong>75% business logic</strong>, not much scaffolding. It also does not survive a single failure.</p>
+<p class="loc-eyebrow">Happy path</p>
+<p class="loc-count">4 <span>lines</span></p>
+<p><strong>Two of them are the feature.</strong> It does not survive a single failure.</p>
 </div>
 <div v-click>
-<p class="loc-eyebrow">Exhaustive</p>
-<p class="loc-count">1,063 <span>lines</span></p>
-<p><strong>29% business logic.</strong> State persistence, retries, timeouts, audit history, recovery on restart.</p>
+<p class="loc-eyebrow">Production-ready</p>
+<p class="loc-count">35+ <span>lines</span></p>
+<p><strong>The same two lines of feature,</strong> plus a lock, a state table, an audit log, a dead-letter queue, a recovery cron, and a retry helper to maintain.</p>
 </div>
 </div>
 
@@ -412,19 +402,13 @@ layout: default
 </style>
 
 <!--
-Source: PPT slides 13-14. The original showed both files as images too small to
-read; the numbers carry the same argument.
-
-Same flow, twice. The left is the obvious version. The right is what it takes
-to add the unspoken requirements by hand: a state table, a retry executor, an
-event log, locking, recovery on startup.
-
-Four times the code, and the business logic went from three quarters of the
-file to under a third. The original deck had a big "I HATE THIS!!!" stamped
-across it. Feel free to say it out loud.
+The numbers are the last three slides: the happy path is 4 lines; the plumbing
+version is 22 and the retry helper 15. That is before `timeout`, the cron,
+the queue consumer and three table schemas, hence the plus.
 
-The question to leave hanging: where did the other 71% go when we used
-Temporal? The answer is the next slide.
+Remember the afternoon estimate from the feature request? This is the version
+that takes a sprint, and it is still the part of the system nobody wants to
+touch.
 -->
 
 ---
@@ -432,108 +416,291 @@ layout: center
 class: text-center
 ---
 
-<p style="font-size: 2.6rem; font-weight: 200; line-height: 1.2">Most platforms push complexity onto you.</p>
+<p style="font-size: 2.6rem; font-weight: 200; line-height: 1.2">What if you only wrote the happy path?</p>
 
-<p v-click style="font-size: 3.2rem; font-weight: 300; margin-top: 2rem; color: var(--temporal-green)">Temporal absorbs it.</p>
+<p v-click style="font-size: 3.2rem; font-weight: 300; margin-top: 2rem; color: var(--temporal-green)">That is Temporal.</p>
 
 <!--
-Source: PPT slide 19. Say it and let it land. This is the thesis of the day.
+The thesis of the day. Say the question and let it hang, then click.
+
+If someone says it sounds like magic, agree that it feels that way and promise
+the mechanism: Event History and replay, in the concepts and Workflows
+segments. Developers distrust magic, so do not leave it there.
 -->
 
 ---
 layout: code-walkthrough
 heading: The Temporal version
 notes:
-  - The same three steps as The non-Temporal version. No lock, no state table, no retry loop, no audit rows
-  - Retries, backoff and timeouts become <strong>configuration</strong>, declared once, by the caller
-  - The Workflow calls <code>fulfillOrder</code>. The business requirement is one line again
+  - Each step is its own <strong>Activity</strong>. Just the call. No lock, no retry loop, no checkpoint
+  - "<strong>Timeouts</strong> are configuration: a hung bank call is abandoned and retried after 10 seconds"
+  - "<strong>When not to retry</strong> is configuration too. Everything else retries, with exponential backoff, by default"
+  - The Workflow is the <strong>happy path</strong>. The same two lines
 ---
 
 ::code::
 
-```java {all|4-8|13-19|21-24}
-// FulfillmentActivitiesImpl.java
-public class FulfillmentActivitiesImpl implements FulfillmentActivities {
+```java {all|2-12|20|21-24|27-31}
+// BankActivitiesImpl.java
+public class BankActivitiesImpl implements BankActivities {
+  @Override
+  public void withdraw(Transfer t) {
+    bank.withdraw(t.fromAccount(), t.amount());
+  }
+
   @Override
-  public String fulfillOrder(String orderId) {
-    inventory.reserve(orderId);
-    String chargeId = payments.charge(orderId);
-    return shipping.ship(orderId, chargeId);
+  public void deposit(Transfer t) {
+    bank.deposit(t.toAccount(), t.amount());
   }
 }
 
-// FulfillmentWorkflowImpl.java
-public class FulfillmentWorkflowImpl implements FulfillmentWorkflow {
-  private final FulfillmentActivities activities =
+// TransferWorkflowImpl.java
+public class TransferWorkflowImpl implements TransferWorkflow {
+  private final BankActivities activities =
       Workflow.newActivityStub(
-          FulfillmentActivities.class,
+          BankActivities.class,
           ActivityOptions.newBuilder()
               .setStartToCloseTimeout(Duration.ofSeconds(10))
-              .setRetryOptions(RetryOptions.newBuilder().setMaximumAttempts(4).build())
+              .setRetryOptions(
+                  RetryOptions.newBuilder()
+                      .setDoNotRetry(InsufficientFundsException.class.getName())
+                      .build())
               .build());
 
   @Override
-  public String fulfill(String orderId) {
-    return activities.fulfillOrder(orderId);
+  public void transfer(Transfer t) {
+    activities.withdraw(t);
+    activities.deposit(t);
   }
 }
 ```
 
 <!--
-Source: PPT slides 15-16. Reworked to mirror "The non-Temporal version":
-the same `fulfillOrder`, the same three steps. Code:
-snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentActivitiesImpl.java
-and FulfillmentWorkflowImpl.java. The two interfaces they implement,
-`FulfillmentActivities` (`@ActivityInterface`) and `FulfillmentWorkflow`
-(`@WorkflowInterface`), are one method each and left off the slide.
-
-This is the payoff. Deliver it slowly, and put "The non-Temporal version" back in their heads first:
-the lock, the state table, a checkpoint round every step, `withRetry`,
-`withTimeout`, the audit rows, the dead-letter queue, the recovery cron.
-
-- **Build 1 - the Activity.** `fulfillOrder` with only the business left in
-  it: reserve, charge, ship. If a service fails, the Activity throws; that is
-  the whole of its error handling.
-- **Build 2 - the policy.** The same knobs from the backoff slide, except now
-  they are declarative, they live in one place, and the defaults are sensible:
-  a 1s initial interval that doubles to a 100s ceiling, with unlimited
-  attempts. `setStartToCloseTimeout` bounds each attempt, not the sequence; to
-  bound the whole thing, set `setScheduleToCloseTimeout` or
-  `setMaximumAttempts`. Most people can leave `setRetryOptions` off entirely.
-- **Build 3 - the Workflow.** It calls `fulfillOrder`, and the call is the one
-  line from the naive slide again. The Workflow knows only the Activity's
-  interface; the stub `Workflow.newActivityStub` returns turns each call into a
-  scheduled Activity Task. Go
-  down the non-Temporal version's bubbles and say where each went: the lock is the Workflow
-  ID, the state table and checkpoints are Event History, retries and timeouts
-  are the policy, the audit trail is the Web UI, and the recovery cron is a
-  Worker picking the Workflow up where it stopped.
-
-If someone spots it: a retry reruns the whole Activity, so a failed charge
-means the reservation is made again. Each service call has to be idempotent by
-order ID, or each step becomes its own Activity so a retry repeats only the
-step that failed. The design-patterns segment covers when to split.
+Code: snippets/src/main/java/io/temporal/devdays/essentials/why/BankActivitiesImpl.java
+and TransferWorkflowImpl.java, run by WhyTemporalTest: a bank that fails the
+deposit twice still completes the transfer with one withdrawal, and
+insufficient funds fails at once without a retry. The two interfaces they
+implement, `BankActivities` (`@ActivityInterface`) and `TransferWorkflow`
+(`@WorkflowInterface`), are two methods and one, and left off the slide.
+
+Deliver it slowly, with the plumbing version in their heads.
+
+- **Build 1 - the Activities.** The two bank calls, and nothing else. If the
+  bank fails, the Activity throws; that is all of its error handling.
+- **Build 2 - the timeout.** `setStartToCloseTimeout` bounds each attempt. A call
+  that hangs is abandoned and retried.
+- **Build 3 - when not to retry.** One option. `setDoNotRetry` takes failure
+  types, and an exception thrown from an Activity has its class name as its
+  type. The defaults answer the rest: a 1
+  second first retry, doubling, capped at 100 seconds, unlimited attempts.
+- **Build 4 - the Workflow.** The happy path, line for line.
 
 The claim to make out loud, because it separates Temporal from a retry library:
-this survives the process dying. Kill the Worker mid-attempt and the retry
-sequence carries on, on another Worker, with the attempt count intact. No retry
-library can do that, because its state is in memory.
+this survives the process dying. Kill the Worker after the withdrawal and
+another Worker carries on with the deposit. The withdrawal is not repeated,
+because it is already recorded in the Workflow's Event History.
+
+Do not explain `Workflow.newActivityStub` here. It gets its own walkthrough in the
+Workflows segment.
+-->
+
+---
+layout: default
+---
+
+# Where did the failures go?
+
+<table class="where">
+<thead><tr><th>In production</th><th>With Temporal</th></tr></thead>
+<tbody>
+<tr><td>The bank's API is down, or hangs</td><td>Retried with backoff until it is back; <code>setStartToCloseTimeout</code> abandons a hung call</td></tr>
+<tr><td>A crash between the two lines</td><td>Another Worker resumes the Workflow at the deposit. The withdrawal is not repeated</td></tr>
+<tr><td>A power outage, or a deploy</td><td>Progress lives in the Temporal Service, not in your process</td></tr>
+<tr><td>A double-tapped Send</td><td>Use the transfer ID as the Workflow ID: the second start is rejected</td></tr>
+<tr><td>A bug in the deposit code</td><td>The deposit keeps retrying. Ship the fix, and the next attempt runs it</td></tr>
+<tr><td>Insufficient funds</td><td>Listed as non-retryable: it fails at once</td></tr>
+</tbody>
+</table>
+
+<style scoped>
+.where {
+  margin-top: 1rem;
+  font-size: 0.9rem;
+}
+.where td:first-child {
+  white-space: nowrap;
+  color: var(--temporal-text-strong);
+}
+</style>
+
+<!--
+Go back to the failures slide, row by row. None of the right-hand column is
+code you wrote.
+
+- **Bank down.** The Retry Policy. The bank can be down for an hour; the
+  transfer simply finishes late.
+- **Crash between the lines.** Every completed Activity is recorded in Event
+  History. A new Worker replays the Workflow, sees the withdrawal already
+  happened, and schedules only the deposit. That replay is the mechanism behind
+  the "only the happy path" promise.
+- **Power outage.** Same mechanism. Workers are stateless; kill all of them and
+  start them again.
+- **Double tap.** Two running Workflows can never share an ID. The patterns
+  section comes back to this.
+- **A bug.** Unlimited retries are a feature here: the stuck transfers wait
+  for your fix instead of landing in a dead-letter queue.
+- **Insufficient funds.** The one line of configuration from the last slide.
+
+The honest caveat: Activities run at least once, so the bank calls still need
+an idempotency key. That has its own slide later in the day.
+-->
+
+---
+layout: default
+---
+
+# Retries are configuration
+
+<table class="policy">
+<thead><tr><th>The question</th><th>Retry Policy field</th><th>Default</th></tr></thead>
+<tbody>
+<tr><td>How long before the first retry?</td><td><code>setInitialInterval</code></td><td>1 second</td></tr>
+<tr><td>How fast does the wait grow?</td><td><code>setBackoffCoefficient</code></td><td>2.0</td></tr>
+<tr><td>What is the longest wait?</td><td><code>setMaximumInterval</code></td><td>100 × the initial interval</td></tr>
+<tr><td>How many times?</td><td><code>setMaximumAttempts</code></td><td>Unlimited</td></tr>
+<tr><td>When don't we retry?</td><td><code>setDoNotRetry</code></td><td>None</td></tr>
+</tbody>
+</table>
+
+<p class="policy-note">Declared once, by the caller. No loop, no helper, no state to lose.</p>
+
+<style scoped>
+.policy {
+  margin-top: 1rem;
+  font-size: 0.95rem;
+}
+.policy-note {
+  margin-top: 1.25rem !important;
+}
+</style>
+
+<!--
+Source: docs.temporal.io/encyclopedia/retry-policies (default values).
+
+Every question from "And the questions start" that was about retries, mapped to
+one field. The defaults are sensible, which is why the Temporal version set
+only one of them.
+
+Point out that this is not a library default living in your process: the
+Temporal Service tracks the attempt count and the next retry time, so a retry
+schedule survives every Worker restarting.
+
+`setStartToCloseTimeout` is not on this table because it is not part of the Retry
+Policy (it is on `ActivityOptions`, beside `setRetryOptions`), but it is
+what decides that an attempt has failed by hanging.
+-->
+
+---
+layout: default
+---
+
+# Just the code you already write
+
+<div class="grid grid-cols-2 gap-10 mt-6">
+<div>
+
+- **No DSL.** No YAML, no JSON state machine, no visual designer.
+- **Plain Java.** Classes, methods, `if`, loops, `try`/`catch`.
+- **Your tools.** Your IDE, your debugger, your test runner, your CI.
 
-Do not explain `Workflow.newActivityStub` properly here. It gets its own
-walkthrough in the Workflows segment.
+</div>
+<div>
+
+- **Your packages.** Activities call any Maven library, any API, any database.
+- **Your architecture.** Start one Workflow from the service you already run.
+- **One feature at a time.** No rewrite to adopt it.
+
+</div>
+</div>
+
+<!--
+The objection this answers before anyone raises it: "so I have to learn a new
+workflow language." No. A Workflow is an interface and a class, and an
+Activity is any method.
+
+The rule that comes with it, said now so it is not a surprise later: Workflow
+code must be deterministic, which is why the bank calls live in Activities.
+The design-patterns segment draws that line properly.
+
+Adoption is the point of the last row. Teams usually start with one painful
+flow (a transfer, an onboarding, a nightly batch), not a migration.
+-->
+
+---
+layout: default
+---
+
+# And out of the box
+
+<div class="features">
+<div class="feature"><strong>Durable timers</strong><span><code>Workflow.sleep(Duration.ofDays(30))</code> survives every restart</span></div>
+<div class="feature"><strong>Signals, Queries, Updates</strong><span>Talk to a Workflow while it runs</span></div>
+<div class="feature"><strong>Full visibility</strong><span>Every run, its inputs, and its history in the Web UI</span></div>
+<div class="feature"><strong>Schedules</strong><span>Start Workflows on a schedule, without a cron box</span></div>
+<div class="feature"><strong>Child Workflows and Sagas</strong><span>Compose flows, and undo them when they fail</span></div>
+<div class="feature"><strong>Versioning</strong><span>Change code while transfers are still running</span></div>
+</div>
+
+<style scoped>
+.features {
+  display: grid;
+  grid-template-columns: repeat(3, minmax(0, 1fr));
+  gap: 1rem;
+  margin-top: 1.25rem;
+}
+.feature {
+  border: 1px solid var(--temporal-border-hi);
+  border-left: 3px solid var(--temporal-green);
+  border-radius: 0.5rem;
+  padding: 0.8rem 1rem;
+}
+.feature strong {
+  display: block;
+  color: var(--temporal-text-strong);
+  margin-bottom: 0.3rem;
+}
+.feature span {
+  display: block;
+  font-size: 0.88rem;
+  line-height: 1.4;
+}
+.feature code {
+  font-size: 0.8rem !important;
+}
+</style>
+
+<!--
+A tour of the agenda, not a feature list to explain. Each box is a section
+later today; name it and move on.
+
+- Durable timers: the Workflows segment.
+- Signals, Queries, Updates: right after the first lab.
+- Visibility: the next two slides, and every demo.
+- Schedules: More features.
+- Child Workflows and Sagas: the advanced topics.
+- Versioning: its own segment.
 -->
 
 ---
 layout: default
 ---
 
-# What you get for free
+# What you see in the Web UI
 
 <div class="ui-timeline">
-  <div class="row"><span class="lane">Workflow Execution</span><span class="track"><span class="bar ok" style="left: 0%; width: 100%">ticket-low-TEMP-042</span></span></div>
-  <div class="row"><span class="lane">Activity</span><span class="track"><span class="bar ok" style="left: 0%; width: 31%">sendAutoResponse</span></span></div>
-  <div class="row"><span class="lane">Activity</span><span class="track"><span class="bar ok" style="left: 32%; width: 31%">searchKnowledgeBase</span></span></div>
-  <div class="row"><span class="lane">Activity</span><span class="track"><span class="bar ok" style="left: 64%; width: 36%">notifyCustomer</span></span></div>
+  <div class="row"><span class="lane">Workflow Execution</span><span class="track"><span class="bar ok" style="left: 0%; width: 100%">transfer-4471</span></span></div>
+  <div class="row"><span class="lane">Activity</span><span class="track"><span class="bar ok" style="left: 0%; width: 48%">withdraw</span></span></div>
+  <div class="row"><span class="lane">Activity</span><span class="track"><span class="bar ok" style="left: 50%; width: 50%">deposit</span></span></div>
 </div>
 
 <style scoped>
@@ -580,27 +747,23 @@ layout: default
 </style>
 
 <!--
-Source: PPT slides 17-18. The original was a screenshot of the Web UI's
-timeline view; this is a redrawing of the same run.
+A redrawing of the Web UI's timeline view for one transfer, the happy path.
 
-The same ticket flow, run on Temporal, as the Web UI's timeline shows it.
-
-A low-priority ticket, the happy path. Every Activity is a bar with a start,
-an end and a result. You wrote none of this.
+The Workflow ID is the transfer ID, so support finds Alice's transfer by the
+number on her receipt. Every Activity is a bar with a start, an end, and a
+result. This is the audit trail the plumbing version wrote by hand.
 -->
 
 ---
 layout: default
 ---
 
-# …including when it fails
+# …including when the bank is down
 
 <div class="ui-timeline">
-  <div class="row"><span class="lane">Workflow Execution</span><span class="track"><span class="bar ok" style="left: 0%; width: 100%">ticket-low-TEMP-043</span></span></div>
-  <div class="row"><span class="lane">Activity</span><span class="track"><span class="bar ok" style="left: 0%; width: 22%">sendAutoResponse</span></span></div>
-  <div class="row"><span class="lane">Activity</span><span class="track"><span class="bar failed" style="left: 23%; width: 22%">searchKnowledgeBase ⓘ</span></span></div>
-  <div class="row"><span class="lane">Activity</span><span class="track"><span class="bar ok" style="left: 46%; width: 21%">assignAgent</span></span></div>
-  <div class="row"><span class="lane">Activity</span><span class="track"><span class="bar ok" style="left: 68%; width: 32%">resolveTicket</span></span></div>
+  <div class="row"><span class="lane">Workflow Execution</span><span class="track"><span class="bar ok" style="left: 0%; width: 100%">transfer-4472</span></span></div>
+  <div class="row"><span class="lane">Activity</span><span class="track"><span class="bar ok" style="left: 0%; width: 22%">withdraw</span></span></div>
+  <div class="row"><span class="lane">Activity</span><span class="track"><span class="bar failed" style="left: 24%; width: 16%">deposit ⓘ</span><span class="bar failed" style="left: 42%; width: 16%">attempt 2</span><span class="bar failed" style="left: 60%; width: 16%">attempt 3</span><span class="bar ok" style="left: 78%; width: 22%">attempt 4</span></span></div>
 </div>
 
 <style scoped>
@@ -619,13 +782,13 @@ layout: default
   border-bottom: none;
 }
 .lane {
-  padding: 0.6rem 0.9rem;
+  padding: 0.7rem 0.9rem;
   font-size: 0.9rem;
   border-right: 1px solid var(--temporal-border-hi);
 }
 .track {
   position: relative;
-  margin: 0.4rem 0.9rem;
+  margin: 0.45rem 0.9rem;
 }
 .bar {
   position: absolute;
@@ -651,35 +814,13 @@ layout: default
 </style>
 
 <!--
-Source: PPT slide 18. Redrawn from the original's Web UI screenshot.
-
-The knowledge base search fails with a non-retryable error, and the Workflow
-takes the other branch: assign an agent, resolve the ticket. The failure is not a
-log line; in the Web UI it is a red bar with the error and the stack trace one
-click away.
-
-That is the visibility requirement from the "unspoken" slide, met without a
-line of code. If you have a live environment, show the Event History tab here:
-it is the audit trail the exhaustive version spent hundreds of lines building.
--->
-
----
-layout: image-right
----
-
-# Every run, on the record
-
-Each ticket is its own Workflow Execution, with an ID you choose and a status
-you can filter on.
-
-::image::
-
-<img src="/images/workflow-list.png" alt="Temporal UI Workflow list: ticket Workflows, all Completed, with IDs like ticket-high-TEMP-100" class="rounded" />
-
-<!--
-Source: PPT slide 18.
-
-Point at the Workflow IDs: `ticket-high-TEMP-100-…`. The ID is yours to design,
-and it is the first thing an on-call engineer searches for. Choosing it well
-(ticket number, order number) is how support finds the run in seconds.
+A redrawing, not a screenshot: the real timeline shows one Activity bar with
+its attempt count and last failure, one click from the stack trace. It is
+drawn as separate attempts here so the room can see the retries.
+
+The bank is down for three attempts. Nobody was paged, nothing went to a
+dead-letter queue, and no one wrote a retry loop. The deposit succeeds on the
+fourth attempt and the withdrawal ran once. This is the answer to "who finds
+out when it never succeeds?": anyone with the Web UI open, with the error in
+front of them.
 -->
diff --git a/decks/java-master/segments/04-design-patterns.md b/decks/java-master/segments/04-design-patterns.md
index b249e8b..ff1a4b4 100644
--- a/decks/java-master/segments/04-design-patterns.md
+++ b/decks/java-master/segments/04-design-patterns.md
@@ -247,217 +247,6 @@ Temporal learns it has died in well under two hours. That gets its own segment
 — forward-reference it, do not teach it here.
 -->
 
----
-layout: subsection
-eyebrow: DESIGN PATTERNS
----
-
-# Keep it in the Workflow if it…
-
-<!--
-Source: PPT slide 31, expanded into slides 45-49 of the expanded edition,
-`{{BLOCK:workflow-patterns}}`.
-
-The other half. Five criteria, one slide each, all short:
-
-- Makes business logic decisions
-- Coordinates between Activities
-- Manages timing and state transitions
-- Is a pure calculation
-- Needs to survive process restarts
-
-The last one is the one people underrate. A local variable in a Workflow
-survives a Worker crash, because it is rebuilt by replay. A local variable in an
-Activity does not.
--->
-
----
-layout: code-stack
-heading: Keep it in the Workflow if it… makes business decisions
-proseMax: 26
----
-
-::code::
-
-```java
-@Override
-public ApprovalStatus triage(Claim claim) {
-  if (claim.amount() > 10_000 || claim.type() == ClaimType.SURGERY) {
-    return ApprovalStatus.REQUIRES_REVIEW;
-  }
-
-  // continue to Activities...
-  return activities.autoApprove(claim);
-}
-```
-
-::default::
-
-The decision itself is the orchestration. It is deterministic, it is cheap, and
-it belongs where you can read it.
-
-<!--
-Source: PPT slide 32.
-Code: snippets/src/main/java/io/temporal/devdays/essentials/patterns4/TriageWorkflowImpl.java.
-The runtime test checks a surgery claim is sent for review with no Activity
-scheduled at all.
-
-This is what "orchestration" means in practice: an `if`. There is nothing to
-retry and nothing to time out, so wrapping it in an Activity buys nothing and
-costs a round trip to the Server.
-
-The practical argument, which lands better than the theoretical one: this
-branch is the business rule. Put it in an Activity and it is invisible in the
-Workflow history — you see "Activity completed" and not *why*. Keep it in the
-Workflow and the decision is in the code and in the Event History.
--->
-
----
-layout: code-stack
-heading: Keep it in the Workflow if it… coordinates Activities
-proseMax: 26
----
-
-::code::
-
-```java
-@Override
-public Decision adjudicate(Applicant applicant) {
-  CreditCheck creditCheck = activities.runCreditCheck(applicant);
-  FraudCheck fraud = activities.checkFraud(applicant, creditCheck);
-  Decision decision = activities.makeDecision(applicant, creditCheck, fraud);
-
-  return decision;
-}
-```
-
-::default::
-
-Chaining Activities with results flowing between the steps. This is the
-Workflow's actual job.
-
-<!--
-Source: PPT slide 46.
-Code: snippets/src/main/java/io/temporal/devdays/essentials/patterns4/LoanWorkflowImpl.java.
-
-Point at how ordinary it looks. Three method calls and three local variables.
-No queues, no callbacks, no futures, no state machine, no correlation IDs.
-
-Then point at what is not written: every one of those three calls is
-independently retried, independently timed out, and survives the process dying
-between any two of them.
--->
-
----
-layout: code-stack
-heading: Keep it in the Workflow if it… manages timing
-proseMax: 30
----
-
-::code::
-
-```java
-// Sleep for 30 days — durable, costs nothing while waiting
-Workflow.sleep(Duration.ofDays(30));
-
-// Wait for a customer response — survives restarts
-Workflow.await(() -> response != null);
-```
-
-::default::
-
-Scheduling future actions and reacting to external events. Both are durable:
-they survive Worker restarts and deploys.
-
-<!--
-Source: PPT slide 47.
-Code: snippets/src/main/java/io/temporal/devdays/essentials/patterns4/FollowUpWorkflowImpl.java,
-where `response` is a field a Signal sets. The runtime test skips 31 days of
-test-server time and reads the 30-day Timer back out of the history.
-
-The thirty-day sleep is the slide that changes how people think, so give it a
-beat. No cron, no scheduler table, no polling job, no "wake up and check"
-Lambda. One line, and the process can be redeployed forty times in between.
-
-The mechanism, if asked: Temporal records a Timer in history and the Workflow is
-evicted from memory. It is not a thread parked for a month. That is also why it
-is `Workflow.sleep` and never `Thread.sleep`: only the first is a Timer.
-
-`Workflow.await` is the primitive the Signals segment builds on. Timing and
-events are the same mechanism from the Workflow's point of view — both are
-"stop here until something happens."
--->
-
----
-layout: code-stack
-heading: Keep it in the Workflow if it… is a pure calculation
-proseMax: 30
----
-
-::code::
-
-```java
-boolean isValidEmail = email.matches("[^@\\s]+@company\\.com");
-
-double riskScore = claim.amount() / 1000 + claim.history().size();
-```
-
-::default::
-
-Deterministic in, deterministic out. Same inputs, same answer, every replay.
-
-<!--
-Source: PPT slide 48.
-Code: snippets/src/main/java/io/temporal/devdays/essentials/patterns4/RiskWorkflowImpl.java.
-
-These call nothing external, are completely idempotent, and produce the same
-output on every replay. Round-tripping them through an Activity buys you a
-Temporal Server call and three history Events in exchange for nothing.
-
-The honest caveat, because someone will push back with the previous
-`validateEligibility` slide: the line between "pure calculation, keep it" and
-"complex validation, extract it" is testability, not purity. Both are correct.
-Extract when the logic is worth a test of its own.
--->
-
----
-layout: code-stack
-heading: Keep it in the Workflow if it… must survive restarts
-proseMax: 38
----
-
-::code::
-
-```java
-ActivityOptions options =
-    ActivityOptions.newBuilder().setStartToCloseTimeout(Duration.ofSeconds(30)).build();
-ClaimActivities activities = Workflow.newActivityStub(ClaimActivities.class, options);
-
-Approval approval = activities.getApproval(claim);
-```
-
-::default::
-
-The Activity call is the **checkpoint**. Its result is written to history, so a
-Worker restart replays up to this line and carries on from there.
-
-<!--
-Source: PPT slide 49.
-Code: snippets/src/main/java/io/temporal/devdays/essentials/patterns4/ClaimWorkflowImpl.java.
-The runtime test finds the `ActivityTaskCompleted` Event in the history.
-
-This is the slide that explains what "durable" actually means mechanically, so
-do not rush it.
-
-Everything before this line is replayed from history, not re-executed against
-the outside world. Everything after it has not happened yet. The Activity
-result is the boundary between the two.
-
-The consequence worth stating: Workflow state persists across failures and
-restarts without you writing a single line of persistence. No database, no
-checkpoint table, no serialisation of your own.
--->
-
 ---
 layout: default
 ---
diff --git a/decks/java-master/segments/05-workflows.md b/decks/java-master/segments/05-workflows.md
index 8bc7a22..dbc4382 100644
--- a/decks/java-master/segments/05-workflows.md
+++ b/decks/java-master/segments/05-workflows.md
@@ -160,3 +160,217 @@ run by snippets/src/test/java/io/temporal/devdays/essentials/workflows/TransferW
 
 If you only have time for three builds, take 2, 4 and 6.
 -->
+
+---
+layout: subsection
+eyebrow: DESIGN PATTERNS
+---
+
+# Keep it in the Workflow if it…
+
+<!--
+Source: PPT slide 31, expanded into slides 45-49 of the expanded edition,
+`{{BLOCK:workflow-patterns}}`.
+
+The Workflow half of the split, taught right after the anatomy slide. The
+Activity half ("Make it an Activity if it…") comes right after the Activities
+section.
+Five criteria, one slide each, all short:
+
+- Makes business logic decisions
+- Coordinates between Activities
+- Manages timing and state transitions
+- Is a pure calculation
+- Needs to survive process restarts
+
+The last one is the one people underrate. A local variable in a Workflow
+survives a Worker crash, because it is rebuilt by replay. A local variable in an
+Activity does not.
+-->
+
+---
+layout: code-stack
+heading: Keep it in the Workflow if it… makes business decisions
+proseMax: 26
+---
+
+::code::
+
+```java
+@Override
+public ApprovalStatus triage(Claim claim) {
+  if (claim.amount() > 10_000 || claim.type() == ClaimType.SURGERY) {
+    return ApprovalStatus.REQUIRES_REVIEW;
+  }
+
+  // continue to Activities...
+  return activities.autoApprove(claim);
+}
+```
+
+::default::
+
+The decision itself is the orchestration. It is deterministic, it is cheap, and
+it belongs where you can read it.
+
+<!--
+Source: PPT slide 32.
+Code: snippets/src/main/java/io/temporal/devdays/essentials/patterns4/TriageWorkflowImpl.java.
+The runtime test checks a surgery claim is sent for review with no Activity
+scheduled at all.
+
+This is what "orchestration" means in practice: an `if`. There is nothing to
+retry and nothing to time out, so wrapping it in an Activity buys nothing and
+costs a round trip to the Server.
+
+The practical argument, which lands better than the theoretical one: this
+branch is the business rule. Put it in an Activity and it is invisible in the
+Workflow history — you see "Activity completed" and not *why*. Keep it in the
+Workflow and the decision is in the code and in the Event History.
+-->
+
+---
+layout: code-stack
+heading: Keep it in the Workflow if it… coordinates Activities
+proseMax: 26
+---
+
+::code::
+
+```java
+@Override
+public Decision adjudicate(Applicant applicant) {
+  CreditCheck creditCheck = activities.runCreditCheck(applicant);
+  FraudCheck fraud = activities.checkFraud(applicant, creditCheck);
+  Decision decision = activities.makeDecision(applicant, creditCheck, fraud);
+
+  return decision;
+}
+```
+
+::default::
+
+Chaining Activities with results flowing between the steps. This is the
+Workflow's actual job.
+
+<!--
+Source: PPT slide 46.
+Code: snippets/src/main/java/io/temporal/devdays/essentials/patterns4/LoanWorkflowImpl.java.
+
+Point at how ordinary it looks. Three method calls and three local variables.
+No queues, no callbacks, no futures, no state machine, no correlation IDs.
+
+Then point at what is not written: every one of those three calls is
+independently retried, independently timed out, and survives the process dying
+between any two of them.
+-->
+
+---
+layout: code-stack
+heading: Keep it in the Workflow if it… manages timing
+proseMax: 30
+---
+
+::code::
+
+```java
+// Sleep for 30 days — durable, costs nothing while waiting
+Workflow.sleep(Duration.ofDays(30));
+
+// Wait for a customer response — survives restarts
+Workflow.await(() -> response != null);
+```
+
+::default::
+
+Scheduling future actions and reacting to external events. Both are durable:
+they survive Worker restarts and deploys.
+
+<!--
+Source: PPT slide 47.
+Code: snippets/src/main/java/io/temporal/devdays/essentials/patterns4/FollowUpWorkflowImpl.java,
+where `response` is a field a Signal sets. The runtime test skips 31 days of
+test-server time and reads the 30-day Timer back out of the history.
+
+The thirty-day sleep is the slide that changes how people think, so give it a
+beat. No cron, no scheduler table, no polling job, no "wake up and check"
+Lambda. One line, and the process can be redeployed forty times in between.
+
+The mechanism, if asked: Temporal records a Timer in history and the Workflow is
+evicted from memory. It is not a thread parked for a month. That is also why it
+is `Workflow.sleep` and never `Thread.sleep`: only the first is a Timer.
+
+`Workflow.await` is the primitive the Signals segment builds on. Timing and
+events are the same mechanism from the Workflow's point of view — both are
+"stop here until something happens."
+-->
+
+---
+layout: code-stack
+heading: Keep it in the Workflow if it… is a pure calculation
+proseMax: 30
+---
+
+::code::
+
+```java
+boolean isValidEmail = email.matches("[^@\\s]+@company\\.com");
+
+double riskScore = claim.amount() / 1000 + claim.history().size();
+```
+
+::default::
+
+Deterministic in, deterministic out. Same inputs, same answer, every replay.
+
+<!--
+Source: PPT slide 48.
+Code: snippets/src/main/java/io/temporal/devdays/essentials/patterns4/RiskWorkflowImpl.java.
+
+These call nothing external, are completely idempotent, and produce the same
+output on every replay. Round-tripping them through an Activity buys you a
+Temporal Server call and three history Events in exchange for nothing.
+
+The honest caveat, because someone will push back with the previous
+`validateEligibility` slide: the line between "pure calculation, keep it" and
+"complex validation, extract it" is testability, not purity. Both are correct.
+Extract when the logic is worth a test of its own.
+-->
+
+---
+layout: code-stack
+heading: Keep it in the Workflow if it… must survive restarts
+proseMax: 38
+---
+
+::code::
+
+```java
+ActivityOptions options =
+    ActivityOptions.newBuilder().setStartToCloseTimeout(Duration.ofSeconds(30)).build();
+ClaimActivities activities = Workflow.newActivityStub(ClaimActivities.class, options);
+
+Approval approval = activities.getApproval(claim);
+```
+
+::default::
+
+The Activity call is the **checkpoint**. Its result is written to history, so a
+Worker restart replays up to this line and carries on from there.
+
+<!--
+Source: PPT slide 49.
+Code: snippets/src/main/java/io/temporal/devdays/essentials/patterns4/ClaimWorkflowImpl.java.
+The runtime test finds the `ActivityTaskCompleted` Event in the history.
+
+This is the slide that explains what "durable" actually means mechanically, so
+do not rush it.
+
+Everything before this line is replayed from history, not re-executed against
+the outside world. Everything after it has not happened yet. The Activity
+result is the boundary between the two.
+
+The consequence worth stating: Workflow state persists across failures and
+restarts without you writing a single line of persistence. No database, no
+checkpoint table, no serialisation of your own.
+-->
diff --git a/decks/java-master/segments/06b-event-history.md b/decks/java-master/segments/06b-event-history.md
index 80f1393..336bdb4 100644
--- a/decks/java-master/segments/06b-event-history.md
+++ b/decks/java-master/segments/06b-event-history.md
@@ -27,10 +27,12 @@ says what each step is, and the colours are the four kinds of thing in play.
    `ActivityTaskCompleted`. On failure, it records the failure or schedules a
    retry.
 8. **Task.** The Service puts a new Workflow Task on the Task Queue.
-9. **Worker action.** A Worker picks up that Workflow Task and replays the
-   history (or, if it still has this Workflow in its cache, applies just the
-   new Events); `activities.chargeCard(...)` now returns the recorded result,
-   and the next line of your code runs.
+9. **Worker action.** A Worker picks up that Workflow Task;
+   `activities.chargeCard(...)` returns the recorded result, and the next line
+   of your code runs. Usually the Worker still has this Workflow in its cache
+   and just hands it the result. If it does not (it crashed, restarted, or this
+   is a different Worker), it first replays the Workflow from the top against
+   the Event History to get back to this line. That replay is the next slides.
 
 Two details worth knowing. The Service writes `ActivityTaskStarted` only after
 the attempt finishes, not at pickup, so a retrying Activity does not flood the
diff --git a/decks/java-master/segments/07-workers.md b/decks/java-master/segments/07-workers.md
index a588d5a..49c8e2f 100644
--- a/decks/java-master/segments/07-workers.md
+++ b/decks/java-master/segments/07-workers.md
@@ -18,6 +18,40 @@ your code. The Server never sees it. That is the answer to the security question
 somebody always asks.
 -->
 
+---
+layout: default
+---
+
+# What is a Worker?
+
+The part of your application that runs your Workflow and Activity code.
+
+- **The Temporal Service is the manager.** It keeps state, schedules work and
+  records what happened
+- **The Worker does the work.** It polls a Task Queue ("any work for me?"), runs
+  your code, and reports the result back
+- **It runs on your infrastructure**: servers, containers, serverless. The
+  Service never runs your code or calls your databases and APIs
+- **It scales horizontally**: one on your laptop, hundreds in production
+
+<!--
+Sources: docs.temporal.io/evaluate/understanding-temporal#workers and
+docs.temporal.io/encyclopedia/architecture/how-temporal-works#worker.
+
+The misconception to kill: "Temporal runs my code." It does not. The Service
+stores Event History and hands out Tasks; the code only ever runs inside a
+Worker that you deploy, so your databases and APIs are only ever called from
+inside your own network. That is the answer to the security question somebody
+always asks. Be precise if it comes up: Workflow and Activity inputs and results
+do travel to the Service, because they are stored in Event History. Encrypting
+them with a Payload Codec has its own segment later.
+
+Polling is the other word to land. Workers pull work; the Service never pushes
+to them. So a Worker needs only outbound access to the Service, no open
+inbound port, and adding capacity means starting another Worker on the same
+Task Queue. Nothing to register, no load balancer to reconfigure.
+-->
+
 ---
 layout: code-walkthrough
 heading: Java Workers
diff --git a/decks/java-master/segments/11-updates.md b/decks/java-master/segments/11-updates.md
index ed8843a..78fbbf9 100644
--- a/decks/java-master/segments/11-updates.md
+++ b/decks/java-master/segments/11-updates.md
@@ -217,3 +217,204 @@ needs to know (did the withdrawal go through, and what is left).
 Updates have their own limits: at most 10 in flight at once per Workflow, and
 2,000 per run (rejected ones do not count). Continue-As-New resets the count.
 -->
+
+---
+layout: comparison
+heading: "Resumable Activity (Pause On Failure)"
+leftTitle: What it is
+leftFeatures:
+  - "An Activity's retries run out, and the Workflow parks instead of failing"
+  - "It waits, using nothing, for a human to Signal in corrected input"
+  - "Then it runs the same Activity again, in the same Workflow"
+rightTitle: When to use it
+rightFeatures:
+  - "The failure is bad input someone can fix: a mistyped account number"
+  - "An invalid reference, or a missing record that will be created"
+  - "Restarting from scratch is worse: the customer would re-enter everything"
+---
+
+<!--
+Source: docs.temporal.io/design-patterns/resumable-activity, overview and
+problem statement.
+
+The framing that lands: retrying can't fix bad input, because the same wrong
+account number fails the same way every time. The usual options are both bad:
+fail the Workflow (the customer re-enters everything), or mark the error
+non-retryable (same thing). What you want is for the Workflow to pause, using
+nothing, until someone with authority supplies the right value, and then pick
+up exactly where it stopped.
+
+When *not* to use it: transient failures (timeouts, 503s) are the Retry
+Policy's job, and failures nobody can correct should fail fast with a
+non-retryable error. And it is not the Approval pattern: approval gates
+progress on a decision; this recovers from a failure with corrected data.
+
+Next slide: the room plays the on-call engineer for exactly this scenario.
+-->
+
+---
+layout: default
+clicks: 3
+---
+
+# Resumable Activity: you're on call
+
+<div class="rt-slide">
+<ResumableTransfer />
+</div>
+
+<style>
+.rt-slide {
+  height: 22rem;
+}
+</style>
+
+<!--
+Source: docs.temporal.io/design-patterns/resumable-activity, and its best
+practices.
+Code: snippets/src/main/java/io/temporal/devdays/essentials/resumable/TransferWorkflowImpl.java
+and TransferActivitiesImpl.java, run by ResumableTest; the console is
+components/ResumableTransfer.vue.
+
+Hand the room the keyboard, figuratively: "you're the engineer on call; what
+do you do first?" Each click (arrow key or clicker) performs the next action,
+in order. The buttons jump to an action if someone calls one out of order;
+Reset goes back to the start.
+
+The pattern in one breath: when an Activity fails because its input is wrong,
+retries cannot fix it and failing the Workflow makes the customer start over.
+So the Workflow catches the failure, parks on `Workflow.await`, and waits for a
+Signal carrying the corrected input. Then it runs the same Activity again.
+
+What each button teaches:
+- **Send the transfer.** `executeTransfer` throws
+  `ApplicationFailure.newNonRetryableFailure(..., "AccountNotFoundError")` for
+  an unknown account, so there is one attempt, not the Retry Policy's three (it
+  is `setMaximumAttempts(3)` for timeouts and 503s). The Workflow catches the
+  `ActivityFailure` and is Running, not Failed. The Event History shows the
+  Activity Type as `ExecuteTransfer`: the method name with its first letter
+  capitalized, the Java SDK's default.
+- **Query getStatus.** A `@QueryMethod` on the Workflow interface. The answer is `AWAITING_CORRECTION`, and the history
+  does not grow. Point at that. In production, also set a Search Attribute with
+  the status so operators can list every parked transfer, and alert when one
+  parks rather than hoping someone opens the Web UI.
+- **Signal "12345678".** `retryWithCorrection` is a `@SignalMethod`. The
+  parked `Workflow.await` returns, the loop runs `executeTransfer` again, and
+  the Workflow completes. Same run ID throughout: the test checks it.
+
+Two rules worth one sentence each: catch only `ActivityFailure` (and rethrow it
+when its cause is a `CanceledFailure`, so cancellation gets through), so a
+Workflow bug is not parked as if it were bad data; and if a Workflow may be corrected many times,
+Continue-As-New before the history grows.
+
+This is not the Approval pattern: approval gates progress on a decision; this
+recovers from a failure with corrected data. The docs' version adds an approval
+Signal after the transfer, which is the Signals segment's pattern.
+
+The live demo on the next slide is this exact scenario against a real Worker.
+-->
+
+---
+layout: comparison
+heading: "Resumable Activity in practice"
+leftTitle: Key advantages
+leftFeatures:
+  - "The Workflow stays alive throughout: no restart from scratch"
+  - "No external database, queue or polling mechanism"
+  - "Status, corrected input and any approval are durably persisted the entire time"
+rightTitle: Best practices
+rightFeatures:
+  - "Allow a few automatic retries before parking, for transient failures"
+  - "Expose the status through a Query"
+  - "Validate the corrected input in the Signal handler"
+  - "Continue-As-New if many correction cycles are expected"
+  - "Notify the operator (email, Slack, a ticket) when it parks"
+---
+
+<!--
+Source: docs.temporal.io/design-patterns/resumable-activity, Key advantages and
+Best practices.
+
+One minute, and every row maps to something the room just clicked through:
+
+- **Stays alive.** The status pill said Running the whole time; one run ID from
+  start to finish.
+- **No database or queue.** The parked transfer, its status and the corrected
+  account live in the Workflow. Nothing to provision, nothing to reconcile.
+- **Durably persisted.** Kill every Worker while it is parked: the Signal is
+  still accepted and the transfer resumes when a Worker comes back.
+
+- **Retries before parking.** `setMaximumAttempts(3)` handles a timeout or a 503;
+  only the non-retryable `AccountNotFoundError` parks at once.
+- **Query.** That was step 2. Pair it with a Search Attribute so operators can
+  list every parked transfer, not just look one up.
+- **Validate in the handler.** The Workflow's handler ignores anything that is
+  not 8 to 12 digits, but a Signal cannot report that back: the sender sees
+  success either way. If the operator needs an error back, make the correction
+  an Update with a validator.
+- **Continue-As-New.** Each correction cycle adds Events; a transfer corrected
+  once never needs it, a long-lived record corrected weekly does.
+- **Notify.** The transition to AWAITING_CORRECTION is the place to send the
+  alert, rather than hoping someone opens the Web UI.
+-->
+
+---
+layout: section
+---
+
+<ZiggyHero scene="demo">
+
+# Demo: Resumable Activity
+
+A transfer to a mistyped account, parked, corrected, and sent.
+
+</ZiggyHero>
+
+<!--
+The code is the previous slide's, in snippets/ (TransferWorkflowImpl.java and
+TransferActivitiesImpl.java under io/temporal/devdays/essentials/resumable).
+The bank knows two accounts: 10000001 and 12345678.
+
+Terminal 1, the dev server (skip if one is running):
+
+    temporal server start-dev
+
+Terminal 2, the Worker, from decks/java-master/snippets:
+
+    mvn -q compile exec:java -Dexec.mainClass=io.temporal.devdays.essentials.resumable.ResumableDemo
+
+Terminal 3, a transfer to an account that does not exist. The Workflow Type is
+the interface name, `TransferWorkflow`:
+
+    temporal workflow start --type TransferWorkflow \
+      --task-queue resumable-demo --workflow-id transfer-4471 \
+      --input '{"fromAccount":"10000001","toAccount":"99999999","amount":500}'
+
+Open the Web UI at localhost:8233 and find `transfer-4471`. Show the room the
+ActivityTaskFailed Event with `AccountNotFoundError`, then point out the
+Workflow is still Running, not Failed.
+
+Ask it where it is:
+
+    temporal workflow query --workflow-id transfer-4471 --name getStatus
+
+It answers `"AWAITING_CORRECTION"`. Optional: send a malformed fix and query
+again to show the handler ignored it:
+
+    temporal workflow signal --workflow-id transfer-4471 \
+      --name retryWithCorrection --input '"acct 1234"'
+
+Now the real fix:
+
+    temporal workflow signal --workflow-id transfer-4471 \
+      --name retryWithCorrection --input '"12345678"'
+
+    temporal workflow result --workflow-id transfer-4471
+
+It completes with "Transfer of 500 to 12345678 completed". Back in the Web UI,
+the whole story is one history: the failure, the Signal, the second
+ExecuteTransfer, the result.
+
+To run it again, use a new --workflow-id, or wait for this one to close: the
+default reuse policy allows a new run once the first has finished.
+-->
diff --git a/decks/java-master/segments/17-saga-01-overview.md b/decks/java-master/segments/17-saga-01-overview.md
index 73f0fc3..0b5fe14 100644
--- a/decks/java-master/segments/17-saga-01-overview.md
+++ b/decks/java-master/segments/17-saga-01-overview.md
@@ -11,7 +11,7 @@ later step fails, run the undos for the steps that already happened, in reverse.
 <!--
 Source: Temporal docs, Saga pattern page (Overview).
 
-Thirty seconds. Every slide from here to Related follows the Saga pattern page in
+Thirty seconds. Every slide from here to the pitfalls follows the Saga pattern page in
 the Temporal docs, in its order and its words. Only the code is different: it is
 the lab's order fulfillment Workflow, from the Saga Workshop in this repo
 (workshops/saga-order-fulfillment).
diff --git a/decks/java-master/segments/17-saga-03-implementation.md b/decks/java-master/segments/17-saga-03-implementation.md
index 488e4a0..c610e30 100644
--- a/decks/java-master/segments/17-saga-03-implementation.md
+++ b/decks/java-master/segments/17-saga-03-implementation.md
@@ -30,89 +30,98 @@ yourself. The Saga helper swallows a failed compensation silently when
 layout: code-walkthrough
 heading: Implementation
 notes:
-  - '<code>fulfill</code> implements the <code class="ref">@WorkflowMethod</code>: an <code>Order</code> in, an <code>OrderResult</code> out'
-  - "<code>Saga</code> is the SDK's compensation stack, kept in Workflow state. Replay rebuilds it"
+  - "The Workflow: an order in, a result out"
+  - "A list of undos, kept in Workflow state. Replay rebuilds it after a crash"
   - "Everything that can fail goes inside the <code>try</code>"
-  - "Register the undo <strong>before</strong> the step. <code>addCompensation</code> stores it; nothing runs yet"
-  - "Calling the stub runs <code>reserveInventory</code> as an Activity. Its undo is already on record"
+  - "Register the undo <strong>before</strong> the step, at the front of the list. Nothing runs yet"
+  - "Step 1 runs as an Activity. Its undo is already on record"
   - "Same pair for the charge, so a charge that lands and then fails is still refunded"
-  - 'Last step, no undo needed. No courier throws <code class="ref">CourierUnavailable</code>'
-  - "Happy path: return the tracking number. The Saga is simply dropped"
-  - "Catch <code>ActivityFailure</code> only. A bug in Workflow code retries instead of refunding"
-  - '<code>log</code> comes from <code class="ref">Workflow.getLogger</code>, which is replay-aware'
-  - "<code>saga.compensate()</code> runs the undos newest first: refund, then release"
-  - "<code>setContinueWithError(true)</code>: a failed undo does not stop the ones after it"
-  - "<code>throw e</code>: the original failure goes back to the caller. <strong>Compensating is not succeeding</strong>"
+  - 'Last step, no undo needed. No courier fails with <code class="ref">CourierUnavailable</code>'
+  - "Happy path: return the tracking number. The undo list is simply dropped"
+  - "Compensate <strong>Activity failures</strong> only. A bug in Workflow code retries instead of refunding"
+  - "Log it. The Workflow logger is replay-aware"
+  - "Walk the list front to back: newest first, so refund, then release"
+  - "Each undo is itself an Activity, with its own timeouts and retries"
+  - "Each undo has its own <code>catch</code>. One failure is logged, the rest still run"
+  - "Rethrow the original failure. <strong>Compensating is not succeeding</strong>"
 ---
 
 ::code::
 
-```java {all|1-2|3-4|6|7|8|10-11|13|14|15|16-17|18|4|19}
-@Override
-public OrderResult fulfill(Order order) {
-  Saga saga =
-      new Saga(new Saga.Options.Builder().setContinueWithError(true).build());
+```txt {all|1|2|4|5|6|8-9|11|12|14|15|17|19|18-21|23}
+workflow fulfill(order):
+  undos = []
 
-  try {
-    saga.addCompensation(activities::releaseInventoryIfReserved, order);
-    activities.reserveInventory(order);
+  try:
+    undos.addToFront(releaseInventory)
+    reserveInventory(order)
 
-    saga.addCompensation(activities::refundPaymentIfCharged, order);
-    activities.chargePayment(order);
+    undos.addToFront(refundPayment)
+    chargePayment(order)
 
-    String trackingNumber = activities.dispatchCourier(order);
-    return new OrderResult(order.orderId(), trackingNumber);
-  } catch (ActivityFailure e) {
-    log.warn("fulfillment failed for {}, unwinding: {}",
-        order.orderId(), Shared.rootCause(e));
-    saga.compensate();
-    throw e;
-  }
-}
+    trackingNumber = dispatchCourier(order)
+    return trackingNumber
+
+  catch activityFailure:
+    log("fulfillment failed, unwinding")
+
+    for each undo in undos:
+      try:
+        undo(order)
+      catch error:
+        log("compensation failed"), keep going
+
+    rethrow activityFailure
 ```
 
 <!--
-Source: workshops/saga-order-fulfillment/solution/src/main/java/io/temporal/devdays/saga/OrderFulfillmentWorkflowImpl.java,
-with the Workshop's `newSaga()` and `unwind()` helpers inlined (the Workshop
-keeps them separate so TODO 1 has one place to edit).
-Code: snippets/src/main/java/io/temporal/devdays/essentials/saga/OrderFulfillmentWorkflowImpl.java
+Pseudocode of workshops/saga-order-fulfillment/solution/src/main/java/io/temporal/devdays/saga/OrderFulfillmentWorkflowImpl.java.
+The next slide is the same Workflow in real Java; this one is the shape,
+without the syntax.
 
 Five minutes, one click per note. Out of frame, as fields of the class: one
 `Workflow.newActivityStub(OrderActivities.class, ...)` hands back all five
-Activities with a 10 second Start-To-Close Timeout and two attempts, and
-`log` is `Workflow.getLogger(OrderFulfillmentWorkflowImpl.class)`. The SDK does
+Activities with a 10 second Start-To-Close Timeout and two attempts, and the
+logger is `Workflow.getLogger(OrderFulfillmentWorkflowImpl.class)`. The SDK does
 not know which of the five Activities is an undo.
 
 The walk is in execution order: forward through the `try`, then the `catch` and
-the unwind.
+the unwind. The builds below name the Java each pseudocode line becomes on the
+next slide. The Java SDK ships a Saga helper, `io.temporal.workflow.Saga`, that
+is exactly this list: `undos` is the `Saga`, `addToFront` is
+`saga.addCompensation`, each step is a call on the Activity stub, `catch
+activityFailure` is `catch (ActivityFailure e)`, and the whole loop, its inner
+try/catch included, is `saga.compensate()` with `setContinueWithError(true)`.
 
 The bubbles are the short version. The full explanation for each build:
 
-- **Build 1 - Lines 1-2: a Workflow definition.** `OrderFulfillmentWorkflow` is a `@WorkflowInterface` with one `@WorkflowMethod`, `fulfill`; this class implements it. The Worker registers the class, and a client starts it on the fulfillment-tasks Task Queue. It takes an Order and returns an OrderResult, both records; Temporal serializes them as JSON.
+- **Build 1 - Line 1: a Workflow definition.** `OrderFulfillmentWorkflow` is a `@WorkflowInterface` with one `@WorkflowMethod`, `fulfill`; the class implements it. The Worker registers the class, and a client starts it on the fulfillment-tasks Task Queue. It takes an Order and returns an OrderResult, both records; Temporal serializes them as JSON.
+
+- **Build 2 - Line 2: the compensation list.** In Java, a `Saga`: a plain object, a list of undos, kept in Workflow state. If the Worker crashes, replay rebuilds it, so the Workflow still knows what it owes. Its options come back on Build 13.
 
-- **Build 2 - Lines 3-4: the compensation stack.** A `Saga` is a plain object, a list of undos, kept in Workflow state. If the Worker crashes, replay rebuilds it, so the Workflow still knows what it owes. The options come back on Build 12.
+- **Build 3 - Line 4: the failure boundary.** Every step that can fail goes inside the try. A failing Activity lands in the catch below, which is where the unwind starts.
 
-- **Build 3 - Line 6: the failure boundary.** Every step that can fail goes inside the try. A failing Activity lands in the catch below, which is where the unwind starts.
+- **Build 4 - Line 5: register before the step.** `saga.addCompensation(activities::releaseInventoryIfReserved, order)` takes a method reference on the Activity stub and its argument, and stores them. Nothing runs yet.
 
-- **Build 4 - Line 7: register before the step.** `addCompensation` takes a method reference on the Activity stub and its argument, and stores them. Nothing runs yet.
+- **Build 5 - Line 6: step 1 runs.** Calling a method on the Activity stub schedules reserveInventory on the Task Queue and blocks the Workflow until its result comes back. The reservation lands in the inventory system, outside the Workflow. Its undo is already on record.
 
-- **Build 5 - Line 8: step 1 runs.** Calling a method on the Activity stub schedules reserveInventory on the Task Queue and blocks the Workflow until its result comes back. The reservation lands in the inventory system, outside the Workflow. Its undo is already on record.
+- **Build 6 - Lines 8-9: the same pair for the charge.** Register refundPaymentIfCharged, then charge. Registering first means a charge that lands and then reports failure is still refunded.
 
-- **Build 6 - Lines 10-11: the same pair for the charge.** Register refundPaymentIfCharged, then charge. Registering first means a charge that lands and then reports failure is still refunded.
+- **Build 7 - Line 11: step 3 has no compensation.** dispatchCourier is last, so no later step can fail and leave it standing. When there is no courier, it throws a non-retryable ApplicationFailure of type CourierUnavailable, and the Workflow sees it as an ActivityFailure whose cause is that ApplicationFailure.
 
-- **Build 7 - Line 13: step 3 has no compensation.** dispatchCourier is last, so no later step can fail and leave it standing. When there is no courier, it throws a non-retryable ApplicationFailure of type CourierUnavailable, and the Workflow sees it as an ActivityFailure whose cause is that ApplicationFailure.
+- **Build 8 - Line 12: the happy path.** If dispatch succeeds, the Workflow returns the tracking number. The Saga is simply dropped: nothing is undone.
 
-- **Build 8 - Line 14: the happy path.** If dispatch succeeds, the Workflow returns the tracking number. The Saga is simply dropped: nothing is undone.
+- **Build 9 - Line 14: compensate Activity failures only.** In Java, `catch (ActivityFailure e)`. An ActivityFailure is the business failure a Saga compensates. Anything else, such as a NullPointerException from a bug in Workflow code, is not caught, so not a single undo is scheduled. An exception that is not a Temporal failure fails the Workflow Task, not the Workflow, so Temporal retries the Task and you can fix and redeploy without refunding anyone. One thing this slide does not handle: if someone cancels the Workflow, the error is a CanceledFailure and it goes straight through. Compensating on cancellation means running the unwind in `Workflow.newDetachedCancellationScope`, since Activities scheduled in a cancelled scope are cancelled too.
 
-- **Build 9 - Line 15: compensate Activity failures only.** An ActivityFailure is the business failure a Saga compensates. Anything else, such as a NullPointerException from a bug in Workflow code, is not caught, so not a single undo is scheduled. An exception that is not a Temporal failure fails the Workflow Task, not the Workflow, so Temporal retries the Task and you can fix and redeploy without refunding anyone. One thing this slide does not handle: if someone cancels the Workflow, the error is a CanceledFailure and it goes straight through. Compensating on cancellation means running the unwind in `Workflow.newDetachedCancellationScope`, since Activities scheduled in a cancelled scope are cancelled too.
+- **Build 10 - Line 15: log the failure.** The logger from `Workflow.getLogger` is replay-aware: it does not repeat this line when the Workflow replays its history. `Shared.rootCause` digs out the Activity's own failure, here CourierUnavailable.
 
-- **Build 10 - Lines 16-17: log the failure.** The logger from `Workflow.getLogger` is replay-aware: it does not repeat this line when the Workflow replays its history. `Shared.rootCause` digs out the Activity's own failure, here CourierUnavailable.
+- **Build 11 - Line 17: newest first.** Because each undo went on the front, walking the list runs refundPaymentIfCharged, then releaseInventoryIfReserved. The undo order mirrors the forward order. `saga.compensate()` does this walk for you. By default it runs one undo at a time; `setParallelCompensation(true)` would start them all at once.
 
-- **Build 11 - Line 18: newest first.** `compensate()` walks its list from the end, so it runs refundPaymentIfCharged, then releaseInventoryIfReserved. The undo order mirrors the forward order. Each undo is an Activity, so it gets timeouts and retries too. By default it runs one undo at a time; `setParallelCompensation(true)` would start them all at once.
+- **Build 12 - Line 19: run one compensation.** Each undo is an Activity call on the same stub, so it gets timeouts and retries too.
 
-- **Build 12 - Line 4: one failure must not strand the rest.** `setContinueWithError(true)`: if one compensation fails after its retries, the Saga moves on to the next. The default is false, which stops the unwind at the first failed undo. The Saga does not log the failure for you; it shows in the Event History. In production, this is where you alert a human.
+- **Build 13 - Lines 18-21: one failure must not strand the rest.** Each undo has its own try/catch. If one fails after its retries, the unwind moves on to the next. In Java that is `setContinueWithError(true)` on the Saga's options; the default is false, which stops the unwind at the first failed undo. The Saga does not log the failure for you; it shows in the Event History as an `ActivityTaskFailed` Event. In production, this is where you alert a human.
 
-- **Build 13 - Line 19: re-throw.** `throw e` re-throws the original ActivityFailure, a Temporal failure, so the Workflow Execution ends Failed and the caller learns the order did not go through. Compensating is not succeeding.
+- **Build 14 - Line 23: re-throw.** `throw e` re-throws the original ActivityFailure, a Temporal failure, so the Workflow Execution ends Failed and the caller learns the order did not go through. Compensating is not succeeding.
 -->
 
 ---
@@ -165,10 +174,15 @@ h1 { font-size: 1.8rem !important; margin-bottom: 0.5rem !important; }
 </style>
 
 <!--
-Source: the same code as the previous slide, with components/SagaUnwind.vue.
+Source: workshops/saga-order-fulfillment/solution/src/main/java/io/temporal/devdays/saga/OrderFulfillmentWorkflowImpl.java,
+with the Workshop's `newSaga()` and `unwind()` helpers inlined (the Workshop
+keeps them separate so TODO 1 has one place to edit), and
+components/SagaUnwind.vue.
+Code: snippets/src/main/java/io/temporal/devdays/essentials/saga/OrderFulfillmentWorkflowImpl.java
 
-Three minutes, ten clicks, one order whose courier fails. The code is the same
-block as the previous slide; this time watch the right-hand side.
+Three minutes, ten clicks, one order whose courier fails. This is the previous
+slide's pseudocode as real Java: the undo list is a `Saga`, and its loop is
+`saga.compensate()`. This time watch the right-hand side.
 
 - **Stack.** Each `addCompensation` puts an undo on top. Nothing on the stack
   runs until the courier fails. Then `compensate()` starts from the top: the
diff --git a/decks/java-master/segments/17-saga-04-when-to-register.md b/decks/java-master/segments/17-saga-04-when-to-register.md
index c7aaaa2..25d2828 100644
--- a/decks/java-master/segments/17-saga-04-when-to-register.md
+++ b/decks/java-master/segments/17-saga-04-when-to-register.md
@@ -41,3 +41,81 @@ exist before the step, and the step had better be atomic.
 Code: snippets/src/main/java/io/temporal/devdays/essentials/saga/TitleTransfer.java
 (no slide shows it; SagaTest runs it).
 -->
+
+---
+layout: code-walkthrough
+heading: A compensation Activity
+notes:
+  - "An undo is an ordinary <strong>Activity</strong>: it calls the payment API to reverse the charge"
+  - "An <strong>idempotency key</strong>, because the undo will be retried. Two calls, one refund"
+  - "The forward step"
+  - "It gets a <strong>deadline</strong>: the customer is waiting, so after 2 minutes we give up and roll back"
+  - "The undo"
+  - "No deadline, no attempt cap, <strong>no Retry Policy at all</strong>: the defaults retry forever, with backoff"
+---
+
+::code::
+
+```java {all|2-6|4|9-15|14|17-22|20-22}
+// PaymentActivitiesImpl.java
+@Override
+public void refundPayment(Order order) {
+  String idempotencyKey = "refund-" + order.orderId();
+  payments.refund(order.orderId(), idempotencyKey);
+}
+
+// ChargeThenRefundWorkflowImpl.java
+private final PaymentActivities charges =
+    Workflow.newActivityStub(
+        PaymentActivities.class,
+        ActivityOptions.newBuilder()
+            .setStartToCloseTimeout(Duration.ofSeconds(10))
+            .setScheduleToCloseTimeout(Duration.ofMinutes(2))
+            .build());
+
+private final PaymentActivities refunds =
+    Workflow.newActivityStub(
+        PaymentActivities.class,
+        ActivityOptions.newBuilder()
+            .setStartToCloseTimeout(Duration.ofSeconds(10))
+            .build());
+```
+
+<!--
+Code: snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/PaymentActivitiesImpl.java
+and ChargeThenRefundWorkflowImpl.java, run by SagaCompensationTest: the refund
+endpoint is down for three attempts, the fourth succeeds, and the customer is
+refunded once. Two stubs over one `@ActivityInterface`, because each gets its
+own `ActivityOptions`: `charges` for the forward step, `refunds` for the undo.
+
+The question this answers, because someone always asks it: "if the API is
+down, wouldn't the compensation fail too?" Yes, at first, and that is fine.
+
+- **Build 1 - the Activity.** A compensation is not special to Temporal. It is
+  an Activity like any other, that happens to undo something.
+- **Build 2 - the key.** The undo will be retried, maybe many times, and an
+  attempt can succeed at the payment API and still time out on the way back.
+  The idempotency key makes the repeat harmless.
+- **Builds 3 and 4 - the forward step has a deadline.**
+  `setScheduleToCloseTimeout` bounds every attempt and retry together. The
+  customer is waiting, so after two minutes the charge gives up, and the Saga
+  rolls back.
+- **Builds 5 and 6 - the undo has none.** No `setScheduleToCloseTimeout`, and
+  no `setRetryOptions` at all: the default Retry Policy has unlimited attempts,
+  so Temporal keeps retrying with backoff (1 second, doubling, capped at 100
+  seconds between attempts) whether the API is back in ten minutes or two days.
+  To hit a struggling API less often, raise `setMaximumInterval`; that spaces
+  the attempts out without ever giving up. The Workflow waits durably; nothing
+  is lost. A bill collector who never gets tired: the API can hide, but not
+  forever.
+
+Why the asymmetry: giving up on a forward step costs you a sale. Giving up on
+an undo leaves a ghost charge on a customer's card, which is worse than being
+slow.
+
+If the API is gone for good (the vendor went out of business), retrying will
+never succeed, and that is where a human comes in. Alert on attempts that have
+been failing for hours; the Web UI shows the attempt count and the last error
+on the pending Activity. Fix the cause, or complete it by hand, and the
+Workflow carries on.
+-->
diff --git a/decks/java-master/segments/17-saga-06-practices.md b/decks/java-master/segments/17-saga-06-practices.md
index 0eeb13d..ff0ee4e 100644
--- a/decks/java-master/segments/17-saga-06-practices.md
+++ b/decks/java-master/segments/17-saga-06-practices.md
@@ -85,43 +85,4 @@ layout: default
 Source: Temporal docs, Saga pattern page (Common pitfalls).
 
 One minute. The docs page's pitfalls.
-
-The next slide is the lab's answer to the first one.
--->
-
----
-layout: code-walkthrough
-heading: An idempotent compensation
-notes:
-  - "A compensation can run when its step never happened, or twice on retry"
-  - "Nothing reserved? <strong>Return early.</strong> Undoing nothing is a no-op"
-  - 'Otherwise release it, once. Same shape in <code class="ref">refundPaymentIfCharged</code>'
----
-
-::code::
-
-```java {all|2|3-6|7}
-@Override
-public void releaseInventoryIfReserved(Order order) {
-  if (!Ledger.isReserved(order.orderId())) {
-    System.out.println("[compensate] nothing reserved for " + order.orderId() + ", no-op");
-    return;
-  }
-  Ledger.record("release:" + order.orderId());
-}
-```
-
-<!--
-Source: workshops/saga-order-fulfillment/solution/src/main/java/io/temporal/devdays/saga/OrderActivitiesImpl.java,
-TODO markers trimmed.
-Code: snippets/src/main/java/io/temporal/devdays/essentials/saga/OrderActivitiesImpl.java
-
-An Activity in Java is a method on an `@ActivityInterface`; this is its
-implementation in `OrderActivitiesImpl`. The Worker registers an instance with
-`registerActivitiesImplementations`, and the Workflow only ever sees the
-interface, through its Activity stub.
-
-`Ledger.isReserved` stands in for the check a real system makes: reading the
-reservation's status, or the gateway's own idempotency key. The lab keeps it in
-memory so the effect is visible in the Worker terminal.
 -->
diff --git a/decks/java-master/segments/17-saga-07-related.md b/decks/java-master/segments/17-saga-07-related.md
index fe31ae0..e60e4ad 100644
--- a/decks/java-master/segments/17-saga-07-related.md
+++ b/decks/java-master/segments/17-saga-07-related.md
@@ -2,42 +2,91 @@
 layout: default
 ---
 
-# Related
+# Idempotency key best practices
 
-<div class="dense">
+- **The same key on every retry.** No `UUID.randomUUID()` in an Activity.
+- **A natural key first,** named for the operation: `order-create-{id}`
+- **No natural key?** Workflow Run ID + Activity ID.
+- **In a Workflow?** Pass it in from the Client, or use `Workflow.randomUUID()`.
+- **The service you call enforces it,** not the Activity.
+- **Your own store?** A unique constraint before acting, a TTL after.
 
-**Patterns**
+<!--
+Sources: docs.temporal.io/activity-definition#idempotency;
+temporal.io/blog/idempotency-and-durable-execution#idempotency-keys;
+temporal.io/blog/error-handling-in-distributed-systems#idempotency-the-unsung-hero;
+temporal.io/blog/saga-pattern-made-easy#idempotency.
+
+Six bullets in three pairs, in the order a developer meets them: pick a key,
+generate it safely, then know who enforces it.
+
+- Same key on every retry. This is the whole point. A key minted inside the
+  Activity changes per attempt, so the service sees every retry as new.
+- Natural key first. If the data already has an `orderId` or `transferId`, use
+  it, and make the key say what the operation is (`order-create-…`, not just
+  the ID) so two different operations on one order cannot collide.
+- Run ID + Activity ID is the fallback when there is no natural key. The next
+  slide shows it.
+- Inside a Workflow, `UUID.randomUUID()` or a timestamp breaks replay. Have the
+  Client generate the key and pass it in (closest to the user, which also
+  covers a double-tapped button), or use `Workflow.randomUUID()`, which draws
+  from the Workflow's seeded random and replays to the same value.
+  `Workflow.sideEffect` also works: it runs once and records the result in
+  Event History.
+- The Activity does not deduplicate anything. The receiving service checks the
+  key and, on a repeat, returns the first result instead of acting again.
+  Stripe's `Idempotency-Key` header is the usual example.
+- If you own the receiver: insert the key into a table with a unique constraint
+  *before* doing the work, in the same transaction. A duplicate-key error means
+  it already happened: skip and return success. Add a timestamp and prune old
+  keys, or the table grows forever.
+-->
 
-- **Error Handling & Retry Patterns**: often combined with the Saga pattern to handle
-  transient failures before compensating
-- **Child Workflows**: organize complex Sagas with multiple sub-Sagas
-- **Long-Running Activity**: Heartbeats work well with long-running compensation Activities
-- **Early Return**: return initialization results before compensation runs
+---
+layout: code-stack
+heading: An idempotency key that survives retries
+proseMax: 30
+---
 
-**Guides and samples**
+::code::
 
-- [Recover business processes without restarting](https://docs.temporal.io/guides/recover-without-restart)
-- [Saga pattern in the Temporal docs](https://docs.temporal.io/design-patterns/saga-pattern)
-- [Java sample: trip booking Saga with `io.temporal.workflow.Saga`](https://github.com/temporalio/samples-java/tree/main/core/src/main/java/io/temporal/samples/bookingsaga)
-- [Java SDK reference: `io.temporal.workflow.Saga`](https://javadoc.io/doc/io.temporal/temporal-sdk/latest/io/temporal/workflow/Saga.html)
+```java
+@Override
+public String postDebit(Debit debit) {
+  ActivityInfo info = Activity.getExecutionContext().getInfo();
+  String idempotencyKey = info.getWorkflowRunId() + "-" + info.getActivityId();
 
-</div>
+  return ledger.post(debit, idempotencyKey);
+}
+```
 
-<style>
-.dense :is(p, li) { font-size: 1.2rem; line-height: 1.45; }
-</style>
+::default::
+
+Activities run at least once. The run ID plus the Activity ID is the same on
+every retry and unique across Workflows, so the ledger can drop the repeat.
 
 <!--
-Source: Temporal docs, Saga pattern page (Related).
-
-Thirty seconds. "Related" from the docs page, with the Java sample and the
-`Saga` class reference. The sample has the same shape as this section: it
-registers each compensation before its step, catches `ActivityFailure`, and
-re-throws. It also wraps `saga.compensate()` in
-`Workflow.newDetachedCancellationScope`, so the undos still run when the
-Workflow is cancelled, which the lab code does not handle.
-
-Child Workflows and Heartbeats, covered earlier in this Deck, both extend what
-the room just built: a Saga step can be a Child Workflow, and a long step
-should heartbeat.
+Source: docs.temporal.io/activity-definition#idempotency and
+docs.temporal.io/best-practices/error-handling#idempotence.
+Code: snippets/src/main/java/io/temporal/devdays/essentials/antipatterns/DebitActivitiesImpl.java,
+run by AntipatternsTest.
+
+The failure this prevents: the Worker posts the debit, the ledger commits it,
+and the Worker crashes (or the response times out) before Temporal hears about
+it. Temporal has no record of success, so it retries. Without a key, the
+customer is debited twice. The test does exactly this: the stub ledger commits
+and then throws once, the retry sends the same key, and there is one posting.
+
+The key is enforced by the service you call, not by the Activity. Most payment
+APIs accept one (Stripe's `Idempotency-Key` header is the usual example). If
+yours does not, an `operations` table with a unique constraint on the key does
+the job.
+
+`getWorkflowRunId()` is the run of the Workflow that scheduled the Activity. It
+is `null` only for a Standalone Activity, which no Workflow scheduled; an
+Activity called from a Workflow always has it. (The older `getRunId()` returns
+the same value and is deprecated.)
+
+Do not use `UUID.randomUUID()` inside the Activity: every attempt gets a new key,
+which deduplicates nothing.
 -->
diff --git a/decks/java-master/segments/17b-patterns-and-anti-patterns.md b/decks/java-master/segments/17b-patterns-and-anti-patterns.md
index e3eba12..92f109f 100644
--- a/decks/java-master/segments/17b-patterns-and-anti-patterns.md
+++ b/decks/java-master/segments/17b-patterns-and-anti-patterns.md
@@ -18,7 +18,8 @@ A bank runs through the whole section, the same one as the Signals, Queries and
 Updates segments: transfers, wires, deposits, accounts. Every pattern here is a
 fix for a specific way a payment goes wrong.
 
-Pacing: four pattern slides, then Resumable Activity and its demo at the end.
+Pacing: three pattern slides. Resumable Activity and its demo come earlier,
+right after Updates, since the pattern is built from a Signal and a Query.
 -->
 
 ---
@@ -82,55 +83,6 @@ Two policies to know by name, without reading them out:
 Bonus: the transfer is now findable by its own ID in the Web UI and the CLI.
 -->
 
----
-layout: code-stack
-heading: An idempotency key that survives retries
-proseMax: 30
----
-
-::code::
-
-```java
-@Override
-public String postDebit(Debit debit) {
-  ActivityInfo info = Activity.getExecutionContext().getInfo();
-  String idempotencyKey = info.getWorkflowRunId() + "-" + info.getActivityId();
-
-  return ledger.post(debit, idempotencyKey);
-}
-```
-
-::default::
-
-Activities run at least once. The run ID plus the Activity ID is the same on
-every retry and unique across Workflows, so the ledger can drop the repeat.
-
-<!--
-Source: docs.temporal.io/activity-definition#idempotency and
-docs.temporal.io/best-practices/error-handling#idempotence.
-Code: snippets/src/main/java/io/temporal/devdays/essentials/antipatterns/DebitActivitiesImpl.java,
-run by AntipatternsTest.
-
-The failure this prevents: the Worker posts the debit, the ledger commits it,
-and the Worker crashes (or the response times out) before Temporal hears about
-it. Temporal has no record of success, so it retries. Without a key, the
-customer is debited twice. The test does exactly this: the stub ledger commits
-and then throws once, the retry sends the same key, and there is one posting.
-
-The key is enforced by the service you call, not by the Activity. Most payment
-APIs accept one (Stripe's `Idempotency-Key` header is the usual example). If
-yours does not, an `operations` table with a unique constraint on the key does
-the job.
-
-`getWorkflowRunId()` is the run of the Workflow that scheduled the Activity. It
-is `null` only for a Standalone Activity, which no Workflow scheduled; an
-Activity called from a Workflow always has it. (The older `getRunId()` returns
-the same value and is deprecated.)
-
-Do not use `UUID.randomUUID()` inside the Activity: every attempt gets a new key,
-which deduplicates nothing.
--->
-
 ---
 layout: code-stack
 heading: Polling an external system
@@ -239,207 +191,3 @@ Everything wrong with the ❌ version, in the order people discover it:
 The ✅ version costs two Events (TimerStarted, TimerFired), survives any number
 of Worker restarts, and holds a million deposits as easily as one.
 -->
-
----
-layout: comparison
-heading: "Resumable Activity (Pause On Failure)"
-leftTitle: What it is
-leftFeatures:
-  - "An Activity's retries run out, and the Workflow parks instead of failing"
-  - "It waits, using nothing, for a human to Signal in corrected input"
-  - "Then it runs the same Activity again, in the same Workflow"
-rightTitle: When to use it
-rightFeatures:
-  - "The failure is bad input someone can fix: a mistyped account number"
-  - "An invalid reference, or a missing record that will be created"
-  - "Restarting from scratch is worse: the customer would re-enter everything"
----
-
-<!--
-Source: docs.temporal.io/design-patterns/resumable-activity, overview and
-problem statement.
-
-The framing that lands: retrying can't fix bad input, because the same wrong
-account number fails the same way every time. The usual options are both bad:
-fail the Workflow (the customer re-enters everything), or mark the error
-non-retryable (same thing). What you want is for the Workflow to pause, using
-nothing, until someone with authority supplies the right value, and then pick
-up exactly where it stopped.
-
-When *not* to use it: transient failures (timeouts, 503s) are the Retry
-Policy's job, and failures nobody can correct should fail fast with a
-non-retryable error. And it is not the Approval pattern: approval gates
-progress on a decision; this recovers from a failure with corrected data.
-
-Next slide: the room plays the on-call engineer for exactly this scenario.
--->
-
----
-layout: default
-clicks: 4
----
-
-# Resumable Activity: you're on call
-
-<div class="rt-slide">
-<ResumableTransfer />
-</div>
-
-<style>
-.rt-slide {
-  height: 22rem;
-}
-</style>
-
-<!--
-Source: docs.temporal.io/design-patterns/resumable-activity, and its best
-practices.
-Code: snippets/src/main/java/io/temporal/devdays/essentials/resumable/TransferWorkflowImpl.java
-and TransferActivitiesImpl.java, run by ResumableTest; the console is
-components/ResumableTransfer.vue.
-
-Hand the room the keyboard, figuratively: "you're the engineer on call; what
-do you do first?" Each click (arrow key or clicker) performs the next action,
-in order. The buttons jump to an action if someone calls one out of order;
-Reset goes back to the start.
-
-The pattern in one breath: when an Activity fails because its input is wrong,
-retries cannot fix it and failing the Workflow makes the customer start over.
-So the Workflow catches the failure, parks on `Workflow.await`, and waits for a
-Signal carrying the corrected input. Then it runs the same Activity again.
-
-What each button teaches:
-- **Send the transfer.** `executeTransfer` throws
-  `ApplicationFailure.newNonRetryableFailure(..., "AccountNotFoundError")` for
-  an unknown account, so there is one attempt, not the Retry Policy's three (it
-  is `setMaximumAttempts(3)` for timeouts and 503s). The Workflow catches the
-  `ActivityFailure` and is Running, not Failed. The Event History shows the
-  Activity Type as `ExecuteTransfer`: the method name with its first letter
-  capitalized, the Java SDK's default.
-- **Query getStatus.** A `@QueryMethod` on the Workflow interface. The answer is `AWAITING_CORRECTION`, and the history
-  does not grow. Point at that. In production, also set a Search Attribute with
-  the status so operators can list every parked transfer, and alert when one
-  parks rather than hoping someone opens the Web UI.
-- **Signal "acct 1234".** `retryWithCorrection` is a `@SignalMethod`. The
-  Signal is in history (Signals always are), but the handler checks the format
-  and ignores it. A Signal handler cannot reject
-  the way an Update validator can; if the operator needs an error back, make
-  the correction an Update.
-- **Signal "12345678".** The parked `Workflow.await` returns, the loop runs
-  `executeTransfer` again, and the Workflow completes. Same run ID throughout:
-  the test checks it.
-
-Two rules worth one sentence each: catch only `ActivityFailure` (and rethrow it
-when its cause is a `CanceledFailure`, so cancellation gets through), so a
-Workflow bug is not parked as if it were bad data; and if a Workflow may be corrected many times,
-Continue-As-New before the history grows.
-
-This is not the Approval pattern: approval gates progress on a decision; this
-recovers from a failure with corrected data. The docs' version adds an approval
-Signal after the transfer, which is the Signals segment's pattern.
-
-The live demo on the next slide is this exact scenario against a real Worker.
--->
-
----
-layout: comparison
-heading: "Resumable Activity in practice"
-leftTitle: Key advantages
-leftFeatures:
-  - "The Workflow stays alive throughout: no restart from scratch"
-  - "No external database, queue or polling mechanism"
-  - "Status, corrected input and any approval are durably persisted the entire time"
-rightTitle: Best practices
-rightFeatures:
-  - "Allow a few automatic retries before parking, for transient failures"
-  - "Expose the status through a Query"
-  - "Validate the corrected input in the Signal handler"
-  - "Continue-As-New if many correction cycles are expected"
-  - "Notify the operator (email, Slack, a ticket) when it parks"
----
-
-<!--
-Source: docs.temporal.io/design-patterns/resumable-activity, Key advantages and
-Best practices.
-
-One minute, and every row maps to something the room just clicked through:
-
-- **Stays alive.** The status pill said Running the whole time; one run ID from
-  start to finish.
-- **No database or queue.** The parked transfer, its status and the corrected
-  account live in the Workflow. Nothing to provision, nothing to reconcile.
-- **Durably persisted.** Kill every Worker while it is parked: the Signal is
-  still accepted and the transfer resumes when a Worker comes back.
-
-- **Retries before parking.** `setMaximumAttempts(3)` handles a timeout or a 503;
-  only the non-retryable `AccountNotFoundError` parks at once.
-- **Query.** That was step 2. Pair it with a Search Attribute so operators can
-  list every parked transfer, not just look one up.
-- **Validate in the handler.** That was step 3, the "acct 1234" typo. If the
-  operator needs an error back, make the correction an Update with a validator.
-- **Continue-As-New.** Each correction cycle adds Events; a transfer corrected
-  once never needs it, a long-lived record corrected weekly does.
-- **Notify.** The transition to AWAITING_CORRECTION is the place to send the
-  alert, rather than hoping someone opens the Web UI.
--->
-
----
-layout: section
----
-
-<ZiggyHero scene="demo">
-
-# Demo: Resumable Activity
-
-A transfer to a mistyped account, parked, corrected, and sent.
-
-</ZiggyHero>
-
-<!--
-The code is the previous slide's, in snippets/ (TransferWorkflowImpl.java and
-TransferActivitiesImpl.java under io/temporal/devdays/essentials/resumable).
-The bank knows two accounts: 10000001 and 12345678.
-
-Terminal 1, the dev server (skip if one is running):
-
-    temporal server start-dev
-
-Terminal 2, the Worker, from decks/java-master/snippets:
-
-    mvn -q compile exec:java -Dexec.mainClass=io.temporal.devdays.essentials.resumable.ResumableDemo
-
-Terminal 3, a transfer to an account that does not exist. The Workflow Type is
-the interface name, `TransferWorkflow`:
-
-    temporal workflow start --type TransferWorkflow \
-      --task-queue resumable-demo --workflow-id transfer-4471 \
-      --input '{"fromAccount":"10000001","toAccount":"99999999","amount":500}'
-
-Open the Web UI at localhost:8233 and find `transfer-4471`. Show the room the
-ActivityTaskFailed Event with `AccountNotFoundError`, then point out the
-Workflow is still Running, not Failed.
-
-Ask it where it is:
-
-    temporal workflow query --workflow-id transfer-4471 --name getStatus
-
-It answers `"AWAITING_CORRECTION"`. Optional: send a malformed fix and query
-again to show the handler ignored it:
-
-    temporal workflow signal --workflow-id transfer-4471 \
-      --name retryWithCorrection --input '"acct 1234"'
-
-Now the real fix:
-
-    temporal workflow signal --workflow-id transfer-4471 \
-      --name retryWithCorrection --input '"12345678"'
-
-    temporal workflow result --workflow-id transfer-4471
-
-It completes with "Transfer of 500 to 12345678 completed". Back in the Web UI,
-the whole story is one history: the failure, the Signal, the second
-ExecuteTransfer, the result.
-
-To run it again, use a new --workflow-id, or wait for this one to close: the
-default reuse policy allows a new run once the first has finished.
--->
diff --git a/decks/java-master/slides.md b/decks/java-master/slides.md
index fd1abb6..1557fbd 100644
--- a/decks/java-master/slides.md
+++ b/decks/java-master/slides.md
@@ -84,7 +84,7 @@ variant: planet-teal
 
 # Temporal Essentials
 
-## Java · Foundations
+## Java
 
 <!--
 Temporal Essentials, the Foundations Deck for a Java Dev Day. Every snippet
@@ -129,11 +129,11 @@ src: ./segments/06-activities.md
 ---
 
 ---
-src: ./segments/06b-event-history.md
+src: ./segments/04-design-patterns.md
 ---
 
 ---
-src: ./segments/04-design-patterns.md
+src: ./segments/06b-event-history.md
 ---
 
 ---
@@ -150,9 +150,12 @@ minutes: 15
 heading: "Lab: The First Workflow"
 ---
 
-**[play.instruqt.com/temporal/tracks/first-workflow-java](https://play.instruqt.com/temporal/tracks/first-workflow-java)**
+<CopyLink href="https://play.instruqt.com/temporal/invite/zxfg8rb7ygov" />
 
 <!--
+The link is the invite for every lab in this Deck: learners open it once and
+pick each lab's Track from there.
+
 The lab for Workflows, Activities, Workers and the Client: Your First Workflow,
 a money transfer. Learners start a transfer with no Worker and watch it wait,
 start the Worker and read the Event History in the Temporal UI, then crash the
@@ -229,14 +232,16 @@ minutes: 35
 heading: Labs
 ---
 
-- [Child Workflows](https://play.instruqt.com/temporal/tracks/child-workflows-java) · 15 min
-- [Continue-As-New](https://play.instruqt.com/temporal/tracks/continue-as-new-java) · 10 min
-- [Heartbeats](https://play.instruqt.com/temporal/tracks/heartbeats-java) · 10 min
+<CopyLink href="https://play.instruqt.com/temporal/invite/zxfg8rb7ygov" />
+
+- Child Workflows · 15 min
+- Continue-As-New · 10 min
+- Heartbeats · 10 min
 
 <!--
 The labs for the three sections just taught, in this order. Each is its own
-Track; the minutes are each lab's measured length, and each Track's time limit
-is 30.
+Track, and all of them sit behind the one invite link; the minutes are each
+lab's measured length, and each Track's time limit is 30.
 
 - **Child Workflows** (workshops/child-workflows): run one child, chain
   children five deep and follow a failure up from the bottom, fan out and watch
@@ -308,7 +313,7 @@ minutes: 25
 heading: "Lab: The Saga Pattern"
 ---
 
-**[play.instruqt.com/temporal/tracks/saga-java](https://play.instruqt.com/temporal/tracks/saga-java)**
+<CopyLink href="https://play.instruqt.com/temporal/invite/zxfg8rb7ygov" />
 
 <!--
 The Saga Workshop's lab (workshops/saga-order-fulfillment):
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/antipatterns/DebitActivitiesImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/antipatterns/DebitActivitiesImpl.java
index 25503b4..15c811e 100644
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/antipatterns/DebitActivitiesImpl.java
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/antipatterns/DebitActivitiesImpl.java
@@ -10,7 +10,7 @@ public DebitActivitiesImpl(Ledger ledger) {
     this.ledger = ledger;
   }
 
-  // slide: 17b-patterns-and-anti-patterns.md "An idempotency key that survives retries"
+  // slide: 17-saga-07-related.md "An idempotency key that survives retries"
   @Override
   public String postDebit(Debit debit) {
     ActivityInfo info = Activity.getExecutionContext().getInfo();
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/ClaimWorkflowImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/ClaimWorkflowImpl.java
index f16aeff..cc63150 100644
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/ClaimWorkflowImpl.java
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/ClaimWorkflowImpl.java
@@ -8,7 +8,7 @@
 public class ClaimWorkflowImpl implements ClaimWorkflow {
   @Override
   public Approval process(Claim claim) {
-    // slide: 04-design-patterns.md "Keep it in the Workflow if it… must survive restarts"
+    // slide: 05-workflows.md "Keep it in the Workflow if it… must survive restarts"
     ActivityOptions options =
         ActivityOptions.newBuilder().setStartToCloseTimeout(Duration.ofSeconds(30)).build();
     ClaimActivities activities = Workflow.newActivityStub(ClaimActivities.class, options);
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/FollowUpWorkflowImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/FollowUpWorkflowImpl.java
index 5750423..62b79cb 100644
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/FollowUpWorkflowImpl.java
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/FollowUpWorkflowImpl.java
@@ -9,7 +9,7 @@ public class FollowUpWorkflowImpl implements FollowUpWorkflow {
 
   @Override
   public String followUp() {
-    // slide: 04-design-patterns.md "Keep it in the Workflow if it… manages timing"
+    // slide: 05-workflows.md "Keep it in the Workflow if it… manages timing"
     // Sleep for 30 days — durable, costs nothing while waiting
     Workflow.sleep(Duration.ofDays(30));
 
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/LoanWorkflowImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/LoanWorkflowImpl.java
index fecab87..b7bfce9 100644
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/LoanWorkflowImpl.java
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/LoanWorkflowImpl.java
@@ -11,7 +11,7 @@ public class LoanWorkflowImpl implements LoanWorkflow {
           LoanActivities.class,
           ActivityOptions.newBuilder().setStartToCloseTimeout(Duration.ofSeconds(30)).build());
 
-  // slide: 04-design-patterns.md "Keep it in the Workflow if it… coordinates Activities"
+  // slide: 05-workflows.md "Keep it in the Workflow if it… coordinates Activities"
   @Override
   public Decision adjudicate(Applicant applicant) {
     CreditCheck creditCheck = activities.runCreditCheck(applicant);
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/RiskWorkflowImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/RiskWorkflowImpl.java
index 3476cb1..8d9afb6 100644
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/RiskWorkflowImpl.java
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/RiskWorkflowImpl.java
@@ -5,7 +5,7 @@
 public class RiskWorkflowImpl implements RiskWorkflow {
   @Override
   public double score(String email, Claim claim) {
-    // slide: 04-design-patterns.md "Keep it in the Workflow if it… is a pure calculation"
+    // slide: 05-workflows.md "Keep it in the Workflow if it… is a pure calculation"
     boolean isValidEmail = email.matches("[^@\\s]+@company\\.com");
 
     double riskScore = claim.amount() / 1000 + claim.history().size();
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/TriageWorkflowImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/TriageWorkflowImpl.java
index 78b27cb..f0f2c7a 100644
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/TriageWorkflowImpl.java
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/patterns4/TriageWorkflowImpl.java
@@ -11,7 +11,7 @@ public class TriageWorkflowImpl implements TriageWorkflow {
           ClaimActivities.class,
           ActivityOptions.newBuilder().setStartToCloseTimeout(Duration.ofSeconds(30)).build());
 
-  // slide: 04-design-patterns.md "Keep it in the Workflow if it… makes business decisions"
+  // slide: 05-workflows.md "Keep it in the Workflow if it… makes business decisions"
   @Override
   public ApprovalStatus triage(Claim claim) {
     if (claim.amount() > 10_000 || claim.type() == ClaimType.SURGERY) {
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/resumable/ResumableDemo.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/resumable/ResumableDemo.java
index 3d64730..db03375 100644
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/resumable/ResumableDemo.java
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/resumable/ResumableDemo.java
@@ -6,7 +6,7 @@
 import io.temporal.worker.WorkerFactory;
 
 /**
- * The Worker for the Resumable Activity demo in 17b-patterns-and-anti-patterns.md. Start a dev
+ * The Worker for the Resumable Activity demo in 11-updates.md. Start a dev
  * server ({@code temporal server start-dev}), then from decks/java-master/snippets:
  *
  * <pre>
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/resumable/TransferWorkflowImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/resumable/TransferWorkflowImpl.java
index b755a88..97d7eb9 100644
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/resumable/TransferWorkflowImpl.java
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/resumable/TransferWorkflowImpl.java
@@ -29,7 +29,9 @@ public String transfer(Transfer transfer) {
     while (true) {
       status = "TRANSFERRING";
       try {
-        return activities.executeTransfer(transfer.withToAccount(account));
+        String receipt = activities.executeTransfer(transfer.withToAccount(account));
+        status = "COMPLETED";
+        return receipt;
       } catch (ActivityFailure e) {
         // Let cancellation through: only a failed transfer parks.
         if (e.getCause() instanceof CanceledFailure) {
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/saga/OrderActivitiesImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/saga/OrderActivitiesImpl.java
index 0c245e3..9bcb36f 100644
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/saga/OrderActivitiesImpl.java
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/saga/OrderActivitiesImpl.java
@@ -38,7 +38,6 @@ public String dispatchCourier(Order order) {
     return "TRK-" + order.orderId();
   }
 
-  // slide: 17-saga-06-practices.md "heading: An idempotent compensation"
   @Override
   public void releaseInventoryIfReserved(Order order) {
     if (!Ledger.isReserved(order.orderId())) {
@@ -47,7 +46,6 @@ public void releaseInventoryIfReserved(Order order) {
     }
     Ledger.record("release:" + order.orderId());
   }
-  // end slide
 
   @Override
   public void refundPaymentIfCharged(Order order) {
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/saga/OrderFulfillmentWorkflowImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/saga/OrderFulfillmentWorkflowImpl.java
index 69aa4d3..ca09e6b 100644
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/saga/OrderFulfillmentWorkflowImpl.java
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/saga/OrderFulfillmentWorkflowImpl.java
@@ -29,7 +29,7 @@ public class OrderFulfillmentWorkflowImpl implements OrderFulfillmentWorkflow {
                       .build())
               .build());
 
-  // slide: 17-saga-03-implementation.md "heading: Implementation"
+  // slide: 17-saga-03-implementation.md "# Implementation: the unwind"
   @Override
   public OrderResult fulfill(Order order) {
     Saga saga =
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/ChargeThenRefundWorkflow.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/ChargeThenRefundWorkflow.java
new file mode 100644
index 0000000..6b36b8a
--- /dev/null
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/ChargeThenRefundWorkflow.java
@@ -0,0 +1,12 @@
+package io.temporal.devdays.essentials.sagacompensation;
+
+import io.temporal.devdays.essentials.saga.Order;
+import io.temporal.workflow.WorkflowInterface;
+import io.temporal.workflow.WorkflowMethod;
+
+/** Not on a slide: the smallest Workflow that charges and then undoes the charge. */
+@WorkflowInterface
+public interface ChargeThenRefundWorkflow {
+  @WorkflowMethod
+  void chargeThenRefund(Order order);
+}
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/ChargeThenRefundWorkflowImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/ChargeThenRefundWorkflowImpl.java
new file mode 100644
index 0000000..f7cb1eb
--- /dev/null
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/ChargeThenRefundWorkflowImpl.java
@@ -0,0 +1,37 @@
+package io.temporal.devdays.essentials.sagacompensation;
+
+import io.temporal.activity.ActivityOptions;
+import io.temporal.devdays.essentials.saga.Order;
+import io.temporal.workflow.Workflow;
+import java.time.Duration;
+
+/**
+ * The two Activity stubs from "A compensation Activity" in 17-saga-04-when-to-register.md: the
+ * forward step with a deadline, and the undo with none. The Workflow method is not on the slide;
+ * it charges and then refunds, so the test can watch the refund outlast an outage.
+ */
+public class ChargeThenRefundWorkflowImpl implements ChargeThenRefundWorkflow {
+  // part: 17-saga-04-when-to-register.md "heading: A compensation Activity" 2
+  // ChargeThenRefundWorkflowImpl.java
+  private final PaymentActivities charges =
+      Workflow.newActivityStub(
+          PaymentActivities.class,
+          ActivityOptions.newBuilder()
+              .setStartToCloseTimeout(Duration.ofSeconds(10))
+              .setScheduleToCloseTimeout(Duration.ofMinutes(2))
+              .build());
+
+  private final PaymentActivities refunds =
+      Workflow.newActivityStub(
+          PaymentActivities.class,
+          ActivityOptions.newBuilder()
+              .setStartToCloseTimeout(Duration.ofSeconds(10))
+              .build());
+  // end part
+
+  @Override
+  public void chargeThenRefund(Order order) {
+    charges.chargePayment(order);
+    refunds.refundPayment(order);
+  }
+}
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/PaymentActivities.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/PaymentActivities.java
new file mode 100644
index 0000000..248d921
--- /dev/null
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/PaymentActivities.java
@@ -0,0 +1,12 @@
+package io.temporal.devdays.essentials.sagacompensation;
+
+import io.temporal.activity.ActivityInterface;
+import io.temporal.devdays.essentials.saga.Order;
+
+/** The forward step and its undo, behind "A compensation Activity". */
+@ActivityInterface
+public interface PaymentActivities {
+  void chargePayment(Order order);
+
+  void refundPayment(Order order);
+}
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/PaymentActivitiesImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/PaymentActivitiesImpl.java
new file mode 100644
index 0000000..55f6780
--- /dev/null
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/PaymentActivitiesImpl.java
@@ -0,0 +1,22 @@
+package io.temporal.devdays.essentials.sagacompensation;
+
+import static io.temporal.devdays.essentials.sagacompensation.PaymentApi.payments;
+
+import io.temporal.devdays.essentials.saga.Order;
+
+/** The compensation Activity on "A compensation Activity" in 17-saga-04-when-to-register.md. */
+public class PaymentActivitiesImpl implements PaymentActivities {
+  @Override
+  public void chargePayment(Order order) {
+    payments.charge(order.orderId());
+  }
+
+  // part: 17-saga-04-when-to-register.md "heading: A compensation Activity" 1
+  // PaymentActivitiesImpl.java
+  @Override
+  public void refundPayment(Order order) {
+    String idempotencyKey = "refund-" + order.orderId();
+    payments.refund(order.orderId(), idempotencyKey);
+  }
+  // end part
+}
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/PaymentApi.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/PaymentApi.java
new file mode 100644
index 0000000..9669ace
--- /dev/null
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/sagacompensation/PaymentApi.java
@@ -0,0 +1,42 @@
+package io.temporal.devdays.essentials.sagacompensation;
+
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.atomic.AtomicInteger;
+
+/**
+ * The payment API behind "A compensation Activity" in 17-saga-04-when-to-register.md, as an
+ * in-memory fake. Tests set {@code refundFailuresLeft} to make the refund endpoint fail a set
+ * number of times, as if it were down.
+ */
+public final class PaymentApi {
+  public final Set<String> charged = ConcurrentHashMap.newKeySet();
+  /** Idempotency key to order ID: one entry per refund actually made. */
+  public final Map<String, String> refunds = new ConcurrentHashMap<>();
+
+  public final AtomicInteger refundCalls = new AtomicInteger();
+  public final AtomicInteger refundFailuresLeft = new AtomicInteger();
+
+  public void charge(String orderId) {
+    charged.add(orderId);
+  }
+
+  public void refund(String orderId, String idempotencyKey) {
+    refundCalls.incrementAndGet();
+    if (refundFailuresLeft.getAndUpdate(n -> n > 0 ? n - 1 : 0) > 0) {
+      throw new IllegalStateException("payment API unavailable");
+    }
+    // The same key twice is one refund, not two.
+    refunds.putIfAbsent(idempotencyKey, orderId);
+  }
+
+  public void reset() {
+    charged.clear();
+    refunds.clear();
+    refundCalls.set(0);
+    refundFailuresLeft.set(0);
+  }
+
+  public static final PaymentApi payments = new PaymentApi();
+}
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/Bank.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/Bank.java
new file mode 100644
index 0000000..2410748
--- /dev/null
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/Bank.java
@@ -0,0 +1,43 @@
+package io.temporal.devdays.essentials.why;
+
+import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.atomic.AtomicInteger;
+
+/**
+ * The bank's API behind 01-why-temporal.md, as an in-memory fake. Tests set {@code
+ * depositFailuresLeft} to make the deposit fail a set number of times, as if the bank were down,
+ * and read the call counts to see how often each endpoint was hit.
+ */
+public final class Bank {
+  public final Map<String, Long> balances = new ConcurrentHashMap<>();
+  public final AtomicInteger depositFailuresLeft = new AtomicInteger();
+  public final AtomicInteger withdrawCalls = new AtomicInteger();
+  public final AtomicInteger depositCalls = new AtomicInteger();
+
+  public void withdraw(String account, long amount) {
+    withdrawCalls.incrementAndGet();
+    long balance = balances.getOrDefault(account, 0L);
+    if (balance < amount) {
+      throw new InsufficientFundsException(account + " has " + balance);
+    }
+    balances.put(account, balance - amount);
+  }
+
+  public void deposit(String account, long amount) {
+    depositCalls.incrementAndGet();
+    if (depositFailuresLeft.getAndUpdate(n -> n > 0 ? n - 1 : 0) > 0) {
+      throw new IllegalStateException("bank unavailable");
+    }
+    balances.merge(account, amount, Long::sum);
+  }
+
+  public void reset() {
+    balances.clear();
+    depositFailuresLeft.set(0);
+    withdrawCalls.set(0);
+    depositCalls.set(0);
+  }
+
+  public static final Bank bank = new Bank();
+}
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentActivities.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/BankActivities.java
similarity index 68%
rename from decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentActivities.java
rename to decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/BankActivities.java
index 80f91a3..e04c248 100644
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentActivities.java
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/BankActivities.java
@@ -4,6 +4,8 @@
 
 /** The Activity interface behind "The Temporal version" in 01-why-temporal.md. */
 @ActivityInterface
-public interface FulfillmentActivities {
-  String fulfillOrder(String orderId);
+public interface BankActivities {
+  void withdraw(Transfer t);
+
+  void deposit(Transfer t);
 }
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/BankActivitiesImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/BankActivitiesImpl.java
new file mode 100644
index 0000000..0bf8304
--- /dev/null
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/BankActivitiesImpl.java
@@ -0,0 +1,18 @@
+package io.temporal.devdays.essentials.why;
+
+import static io.temporal.devdays.essentials.why.Bank.bank;
+
+// part: 01-why-temporal.md "The Temporal version" 1
+// BankActivitiesImpl.java
+public class BankActivitiesImpl implements BankActivities {
+  @Override
+  public void withdraw(Transfer t) {
+    bank.withdraw(t.fromAccount(), t.amount());
+  }
+
+  @Override
+  public void deposit(Transfer t) {
+    bank.deposit(t.toAccount(), t.amount());
+  }
+}
+// end part
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentActivitiesImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentActivitiesImpl.java
deleted file mode 100644
index 279cb00..0000000
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentActivitiesImpl.java
+++ /dev/null
@@ -1,17 +0,0 @@
-package io.temporal.devdays.essentials.why;
-
-import static io.temporal.devdays.essentials.why.Services.inventory;
-import static io.temporal.devdays.essentials.why.Services.payments;
-import static io.temporal.devdays.essentials.why.Services.shipping;
-
-// part: 01-why-temporal.md "The Temporal version" 1
-// FulfillmentActivitiesImpl.java
-public class FulfillmentActivitiesImpl implements FulfillmentActivities {
-  @Override
-  public String fulfillOrder(String orderId) {
-    inventory.reserve(orderId);
-    String chargeId = payments.charge(orderId);
-    return shipping.ship(orderId, chargeId);
-  }
-}
-// end part
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentWorkflowImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentWorkflowImpl.java
deleted file mode 100644
index ba14000..0000000
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentWorkflowImpl.java
+++ /dev/null
@@ -1,24 +0,0 @@
-package io.temporal.devdays.essentials.why;
-
-import io.temporal.activity.ActivityOptions;
-import io.temporal.common.RetryOptions;
-import io.temporal.workflow.Workflow;
-import java.time.Duration;
-
-// part: 01-why-temporal.md "The Temporal version" 2
-// FulfillmentWorkflowImpl.java
-public class FulfillmentWorkflowImpl implements FulfillmentWorkflow {
-  private final FulfillmentActivities activities =
-      Workflow.newActivityStub(
-          FulfillmentActivities.class,
-          ActivityOptions.newBuilder()
-              .setStartToCloseTimeout(Duration.ofSeconds(10))
-              .setRetryOptions(RetryOptions.newBuilder().setMaximumAttempts(4).build())
-              .build());
-
-  @Override
-  public String fulfill(String orderId) {
-    return activities.fulfillOrder(orderId);
-  }
-}
-// end part
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/HandRolled.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/HandRolled.java
new file mode 100644
index 0000000..b5943e7
--- /dev/null
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/HandRolled.java
@@ -0,0 +1,40 @@
+package io.temporal.devdays.essentials.why;
+
+import java.util.concurrent.ThreadLocalRandom;
+
+/**
+ * The two hand-written slides from 01-why-temporal.md: the happy path and the retry helper. Plain
+ * Java with no Temporal in it, which is the point of those slides.
+ */
+public class HandRolled {
+  private final Bank bank;
+
+  public HandRolled(Bank bank) {
+    this.bank = bank;
+  }
+
+  // slide: 01-why-temporal.md "The happy path"
+  public void transfer(Transfer t) {
+    bank.withdraw(t.fromAccount(), t.amount());
+    bank.deposit(t.toAccount(), t.amount());
+  }
+  // end slide
+
+  // slide: 01-why-temporal.md "So you add a retry"
+  void withRetry(Runnable call) throws InterruptedException {
+    long delay = 1_000;
+    for (int attempt = 1; ; attempt++) {
+      try {
+        call.run();
+        return;
+      } catch (InsufficientFundsException e) {
+        throw e;
+      } catch (RuntimeException e) {
+        if (attempt == 5) throw e;
+        Thread.sleep(delay + ThreadLocalRandom.current().nextLong(250));
+        delay = Math.min(delay * 2, 30_000);
+      }
+    }
+  }
+  // end slide
+}
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/HandRolledRetry.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/HandRolledRetry.java
deleted file mode 100644
index 17d70b8..0000000
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/HandRolledRetry.java
+++ /dev/null
@@ -1,59 +0,0 @@
-package io.temporal.devdays.essentials.why;
-
-/**
- * The three hand-rolled slides from 01-why-temporal.md: the naive call, the retry loop, and the
- * backoff. Plain Java with no Temporal in it, which is the point of those slides.
- */
-public class HandRolledRetry {
-
-  /** Whatever fulfils an order. Any failure is an exception. */
-  public interface FulfillmentService {
-    FulfillmentResult fulfill(String orderId) throws Exception;
-  }
-
-  public record FulfillmentResult(String trackingNumber) {}
-
-  private final FulfillmentService fulfillmentService;
-
-  public HandRolledRetry(FulfillmentService fulfillmentService) {
-    this.fulfillmentService = fulfillmentService;
-  }
-
-  public FulfillmentResult naive(String orderId) throws Exception {
-    // slide: 01-why-temporal.md "The naive version"
-    return fulfillmentService.fulfill(orderId);
-    // end slide
-  }
-
-  public FulfillmentResult withRetry(String orderId) throws InterruptedException {
-    // slide: 01-why-temporal.md "So you add a retry"
-    for (int attempt = 0; attempt < 4; attempt++) {
-      try {
-        return fulfillmentService.fulfill(orderId);
-      } catch (Exception e) {
-        Thread.sleep(5000);
-      }
-    }
-    // end slide
-    // The compiler insists on something here. This is what usually gets written.
-    return null;
-  }
-
-  // slide: 01-why-temporal.md "So you add real backoff"
-  FulfillmentResult fulfillWithRetry(String orderId) throws InterruptedException {
-    long delay = 1000;
-    int maxRetries = 3;
-    for (int attempt = 0; attempt < maxRetries; attempt++) {
-      try {
-        return fulfillmentService.fulfill(orderId);
-      } catch (Exception e) {
-        if (attempt < maxRetries - 1) {
-          Thread.sleep(delay);
-          delay = Math.min(delay * 2, 30_000);
-        }
-      }
-    }
-    throw new IllegalStateException("Failed after too many attempts");
-  }
-  // end slide
-}
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/InsufficientFundsException.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/InsufficientFundsException.java
new file mode 100644
index 0000000..4574443
--- /dev/null
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/InsufficientFundsException.java
@@ -0,0 +1,11 @@
+package io.temporal.devdays.essentials.why;
+
+/**
+ * Thrown by the bank when the source account cannot cover the transfer. Its class name is the
+ * failure type the Workflow's Retry Policy lists as non-retryable.
+ */
+public class InsufficientFundsException extends RuntimeException {
+  public InsufficientFundsException(String message) {
+    super(message);
+  }
+}
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/Services.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/Services.java
deleted file mode 100644
index 5ad27d1..0000000
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/Services.java
+++ /dev/null
@@ -1,62 +0,0 @@
-package io.temporal.devdays.essentials.why;
-
-import java.util.concurrent.atomic.AtomicInteger;
-import java.util.function.Function;
-
-/**
- * In-memory fakes for the three services behind "The Temporal version" in 01-why-temporal.md.
- * Tests set {@code failuresLeft} to make a service throw a set number of times, and read {@code
- * calls} to see how often it was called.
- */
-public final class Services {
-  private Services() {}
-
-  public static final class FakeService {
-    public final AtomicInteger failuresLeft = new AtomicInteger();
-    public final AtomicInteger calls = new AtomicInteger();
-    private final Function<String, String> result;
-
-    FakeService(Function<String, String> result) {
-      this.result = result;
-    }
-
-    String run(String orderId) {
-      calls.incrementAndGet();
-      if (failuresLeft.getAndUpdate(n -> n > 0 ? n - 1 : 0) > 0) {
-        throw new IllegalStateException("service unavailable");
-      }
-      return result.apply(orderId);
-    }
-
-    public void reset() {
-      failuresLeft.set(0);
-      calls.set(0);
-    }
-  }
-
-  public static final FakeService INVENTORY = new FakeService(id -> null);
-  public static final FakeService PAYMENTS = new FakeService(id -> "ch-" + id);
-  public static final FakeService SHIPPING = new FakeService(id -> "trk-" + id);
-
-  public static final class Inventory {
-    public void reserve(String orderId) {
-      INVENTORY.run(orderId);
-    }
-  }
-
-  public static final class Payments {
-    public String charge(String orderId) {
-      return PAYMENTS.run(orderId);
-    }
-  }
-
-  public static final class Shipping {
-    public String ship(String orderId, String chargeId) {
-      return SHIPPING.run(orderId);
-    }
-  }
-
-  public static final Inventory inventory = new Inventory();
-  public static final Payments payments = new Payments();
-  public static final Shipping shipping = new Shipping();
-}
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/Transfer.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/Transfer.java
new file mode 100644
index 0000000..4a8cf27
--- /dev/null
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/Transfer.java
@@ -0,0 +1,4 @@
+package io.temporal.devdays.essentials.why;
+
+/** One bank transfer, the example that runs through 01-why-temporal.md. Amounts are in dollars. */
+public record Transfer(String transferId, String fromAccount, String toAccount, long amount) {}
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentWorkflow.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/TransferWorkflow.java
similarity index 78%
rename from decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentWorkflow.java
rename to decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/TransferWorkflow.java
index 1d1ee39..6c036e1 100644
--- a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/FulfillmentWorkflow.java
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/TransferWorkflow.java
@@ -5,7 +5,7 @@
 
 /** The Workflow interface behind "The Temporal version" in 01-why-temporal.md. */
 @WorkflowInterface
-public interface FulfillmentWorkflow {
+public interface TransferWorkflow {
   @WorkflowMethod
-  String fulfill(String orderId);
+  void transfer(Transfer t);
 }
diff --git a/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/TransferWorkflowImpl.java b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/TransferWorkflowImpl.java
new file mode 100644
index 0000000..953af9e
--- /dev/null
+++ b/decks/java-master/snippets/src/main/java/io/temporal/devdays/essentials/why/TransferWorkflowImpl.java
@@ -0,0 +1,28 @@
+package io.temporal.devdays.essentials.why;
+
+import io.temporal.activity.ActivityOptions;
+import io.temporal.common.RetryOptions;
+import io.temporal.workflow.Workflow;
+import java.time.Duration;
+
+// part: 01-why-temporal.md "The Temporal version" 2
+// TransferWorkflowImpl.java
+public class TransferWorkflowImpl implements TransferWorkflow {
+  private final BankActivities activities =
+      Workflow.newActivityStub(
+          BankActivities.class,
+          ActivityOptions.newBuilder()
+              .setStartToCloseTimeout(Duration.ofSeconds(10))
+              .setRetryOptions(
+                  RetryOptions.newBuilder()
+                      .setDoNotRetry(InsufficientFundsException.class.getName())
+                      .build())
+              .build());
+
+  @Override
+  public void transfer(Transfer t) {
+    activities.withdraw(t);
+    activities.deposit(t);
+  }
+}
+// end part
diff --git a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/antipatterns/AntipatternsTest.java b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/antipatterns/AntipatternsTest.java
index 90b9bde..0b15f03 100644
--- a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/antipatterns/AntipatternsTest.java
+++ b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/antipatterns/AntipatternsTest.java
@@ -17,7 +17,10 @@
 import org.junit.jupiter.api.BeforeEach;
 import org.junit.jupiter.api.Test;
 
-/** 17b-patterns-and-anti-patterns.md: the four ❌/✅ slides, each half run and checked. */
+/**
+ * 17b-patterns-and-anti-patterns.md: the three ❌/✅ slides, each half run and checked; and the
+ * idempotency key slide in 17-saga-07-related.md.
+ */
 class AntipatternsTest {
   private TestWorkflowEnvironment env;
   private WorkflowClient client;
diff --git a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/deck/WalkthroughsTest.java b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/deck/WalkthroughsTest.java
index 5ab69bd..ac19758 100644
--- a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/deck/WalkthroughsTest.java
+++ b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/deck/WalkthroughsTest.java
@@ -32,7 +32,8 @@ class WalkthroughsTest {
   private static final Pattern CODE_TAG = Pattern.compile("<code>(.*?)</code>");
   private static final Pattern HEADING = Pattern.compile("^heading: (.+)$", Pattern.MULTILINE);
   private static final Pattern FENCE =
-      Pattern.compile("^```java \\{([^}]*)\\}\\n([\\s\\S]*?)^```$", Pattern.MULTILINE);
+      // Java, or `txt` for a pseudocode walkthrough.
+      Pattern.compile("^```(?:java|txt) \\{([^}]*)\\}\\n([\\s\\S]*?)^```$", Pattern.MULTILINE);
 
   record Walkthrough(String id, List<String> steps, List<String> notes, List<String> code) {}
 
@@ -85,7 +86,7 @@ static List<Walkthrough> walkthroughs() {
         String heading = h.find() ? h.group(1).replaceAll("^\"|\"$", "") : "(no heading)";
         Matcher f = FENCE.matcher(body);
         if (!f.find()) {
-          throw new IllegalStateException(name + ": " + heading + " has no highlighted java block");
+          throw new IllegalStateException(name + ": " + heading + " has no highlighted java or txt block");
         }
         List<String> specs = Arrays.asList(f.group(1).split("\\|"));
         // `all` burns click 0, unannotated.
diff --git a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/patterns4/DesignPatternsTest.java b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/patterns4/DesignPatternsTest.java
index 480e827..6554685 100644
--- a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/patterns4/DesignPatternsTest.java
+++ b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/patterns4/DesignPatternsTest.java
@@ -32,7 +32,7 @@
 import org.junit.jupiter.api.Test;
 import org.junit.jupiter.api.Timeout;
 
-/** 04-design-patterns: each slide's code runs, and the claims its notes make about it hold. */
+/** 04-design-patterns and the Workflow half in 05-workflows: each slide's code runs, and the claims its notes make about it hold. */
 @Timeout(30)
 class DesignPatternsTest {
   private static final String QUEUE = "patterns";
@@ -175,7 +175,7 @@ void theBusinessDecisionIsAnIfInTheWorkflow() {
     assertTrue(
         history(id).stream()
             .noneMatch(e -> e.getEventType() == EventType.EVENT_TYPE_ACTIVITY_TASK_SCHEDULED),
-        "04-design-patterns.md (makes business decisions): the decision costs no Activity call");
+        "05-workflows.md (makes business decisions): the decision costs no Activity call");
     assertEquals(
         ApprovalStatus.APPROVED,
         stub(TriageWorkflow.class).triage(new Claim("c-3", 500, ClaimType.CHECKUP, List.of())),
@@ -213,7 +213,7 @@ void aThirtyDaySleepIsADurableTimerAndAwaitWaitsForTheSignal() {
     assertEquals(
         Duration.ofDays(30).toSeconds(),
         timer.getTimerStartedEventAttributes().getStartToFireTimeout().getSeconds(),
-        "04-design-patterns.md (manages timing): Workflow.sleep(30 days) is a Timer in history");
+        "05-workflows.md (manages timing): Workflow.sleep(30 days) is a Timer in history");
   }
 
   @Test
@@ -239,7 +239,7 @@ void theActivityResultIsWrittenToHistory() {
     assertTrue(
         history(id).stream()
             .anyMatch(e -> e.getEventType() == EventType.EVENT_TYPE_ACTIVITY_TASK_COMPLETED),
-        "04-design-patterns.md (must survive restarts): the Activity result is in Event History");
+        "05-workflows.md (must survive restarts): the Activity result is in Event History");
   }
 
   @Test
diff --git a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/resumable/ResumableTest.java b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/resumable/ResumableTest.java
index dd271ec..9c87f32 100644
--- a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/resumable/ResumableTest.java
+++ b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/resumable/ResumableTest.java
@@ -16,7 +16,7 @@
 import org.junit.jupiter.api.Test;
 
 /**
- * 17b-patterns-and-anti-patterns.md: "Resumable Activity: you're on call", the console in
+ * 11-updates.md: "Resumable Activity: you're on call", the console in
  * components/ResumableTransfer.vue, and the demo after it.
  */
 class ResumableTest {
@@ -91,6 +91,11 @@ void parksOnABadAccountIgnoresAMalformedFixAndResumesOnAValidOne() throws Interr
         stub.getResult(String.class),
         "TransferWorkflowImpl.transfer should resume with the corrected account");
     assertEquals(List.of("99999999", "12345678"), activities.attempts);
+    // A Query on the finished Workflow reports where it ended, as the console shows.
+    assertEquals(
+        "COMPLETED",
+        transfer.getStatus(),
+        "TransferWorkflowImpl.transfer should set the status to COMPLETED before it returns");
 
     // Same Workflow Execution throughout: no restart, no new run.
     WorkflowExecutionDescription description = stub.describe();
diff --git a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/saga/SagaTest.java b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/saga/SagaTest.java
index d1c017a..edc4a37 100644
--- a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/saga/SagaTest.java
+++ b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/saga/SagaTest.java
@@ -7,7 +7,6 @@
 import io.temporal.client.WorkflowClient;
 import io.temporal.client.WorkflowFailedException;
 import io.temporal.client.WorkflowOptions;
-import io.temporal.devdays.essentials.deck.Slides;
 import io.temporal.devdays.essentials.saga.TitleTransfer.TitleActivitiesImpl;
 import io.temporal.devdays.essentials.saga.TitleTransfer.TitleOrder;
 import io.temporal.devdays.essentials.saga.TitleTransfer.TitleTransferWorkflow;
@@ -148,14 +147,6 @@ public void refundPaymentIfCharged(Order order) {
         WORKFLOW + ": setContinueWithError(true) means a failed refund does not stop the release");
   }
 
-  @Test
-  void theUnwindSlideShowsTheSameCodeAsTheWalkthrough() {
-    assertEquals(
-        Slides.slideCode("17-saga-03-implementation.md", "heading: Implementation"),
-        Slides.slideCode("17-saga-03-implementation.md", "# Implementation: the unwind"),
-        "17-saga-03-implementation.md: the unwind slide must show the walkthrough's code");
-  }
-
   @Test
   void anUndoRegisteredAfterItsStepUsesTheForwardResult() {
     TitleTransfer.JOURNAL.clear();
diff --git a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/sagacompensation/SagaCompensationTest.java b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/sagacompensation/SagaCompensationTest.java
new file mode 100644
index 0000000..8827654
--- /dev/null
+++ b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/sagacompensation/SagaCompensationTest.java
@@ -0,0 +1,63 @@
+package io.temporal.devdays.essentials.sagacompensation;
+
+import static io.temporal.devdays.essentials.sagacompensation.PaymentApi.payments;
+import static org.junit.jupiter.api.Assertions.assertEquals;
+
+import io.temporal.client.WorkflowOptions;
+import io.temporal.devdays.essentials.saga.Order;
+import io.temporal.testing.TestWorkflowEnvironment;
+import io.temporal.worker.Worker;
+import java.util.List;
+import org.junit.jupiter.api.AfterEach;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+
+/**
+ * 17-saga-04-when-to-register.md "A compensation Activity": the undo has no deadline and no attempt
+ * cap, so it outlasts an outage of the payment API, and its idempotency key keeps the retries to a
+ * single refund.
+ */
+class SagaCompensationTest {
+  private static final String TASK_QUEUE = "saga-compensation";
+
+  private TestWorkflowEnvironment env;
+
+  @BeforeEach
+  void setUp() {
+    payments.reset();
+    env = TestWorkflowEnvironment.newInstance();
+    Worker worker = env.newWorker(TASK_QUEUE);
+    worker.registerWorkflowImplementationTypes(ChargeThenRefundWorkflowImpl.class);
+    worker.registerActivitiesImplementations(new PaymentActivitiesImpl());
+    env.start();
+  }
+
+  @AfterEach
+  void tearDown() {
+    env.close();
+  }
+
+  @Test
+  void theRefundKeepsRetryingThroughAnOutageAndRefundsOnce() {
+    payments.refundFailuresLeft.set(3);
+
+    env.getWorkflowClient()
+        .newWorkflowStub(
+            ChargeThenRefundWorkflow.class,
+            WorkflowOptions.newBuilder()
+                .setTaskQueue(TASK_QUEUE)
+                .setWorkflowId("refund-order-1")
+                .build())
+        .chargeThenRefund(Order.widget("order-1"));
+
+    assertEquals(
+        4,
+        payments.refundCalls.get(),
+        "ChargeThenRefundWorkflowImpl.java: the refunds stub sets no Retry Policy, so the default"
+            + " keeps retrying until the payment API is back");
+    assertEquals(
+        List.of("order-1"),
+        List.copyOf(payments.refunds.values()),
+        "PaymentActivitiesImpl.refundPayment: the idempotency key means one refund, not four");
+  }
+}
diff --git a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/why/WhyTemporalTest.java b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/why/WhyTemporalTest.java
index 4bd047c..f5d417e 100644
--- a/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/why/WhyTemporalTest.java
+++ b/decks/java-master/snippets/src/test/java/io/temporal/devdays/essentials/why/WhyTemporalTest.java
@@ -1,11 +1,15 @@
 package io.temporal.devdays.essentials.why;
 
+import static io.temporal.devdays.essentials.why.Bank.bank;
 import static org.junit.jupiter.api.Assertions.assertEquals;
+import static org.junit.jupiter.api.Assertions.assertInstanceOf;
 import static org.junit.jupiter.api.Assertions.assertThrows;
 
 import io.temporal.client.WorkflowClient;
 import io.temporal.client.WorkflowFailedException;
 import io.temporal.client.WorkflowOptions;
+import io.temporal.failure.ActivityFailure;
+import io.temporal.failure.ApplicationFailure;
 import io.temporal.testing.TestWorkflowEnvironment;
 import io.temporal.worker.Worker;
 import org.junit.jupiter.api.AfterEach;
@@ -13,25 +17,25 @@
 import org.junit.jupiter.api.Test;
 
 /**
- * 01-why-temporal.md "The Temporal version": retries are configuration. The Activity has no retry
- * loop, yet a payment service that fails three times still lets the order through on the fourth
- * attempt, and a fifth is never made.
+ * 01-why-temporal.md "The Temporal version": retries are configuration. The Activities have no
+ * retry loop, yet a bank that fails the deposit twice still completes the transfer, with one
+ * withdrawal. Insufficient funds is listed as non-retryable, so it fails at once.
  */
 class WhyTemporalTest {
   private static final String TASK_QUEUE = "why-temporal";
+  private static final Transfer TRANSFER = new Transfer("4471", "alice", "bob", 500);
 
   private TestWorkflowEnvironment env;
   private WorkflowClient client;
 
   @BeforeEach
   void setUp() {
-    Services.INVENTORY.reset();
-    Services.PAYMENTS.reset();
-    Services.SHIPPING.reset();
+    bank.reset();
+    bank.balances.put("alice", 1000L);
     env = TestWorkflowEnvironment.newInstance();
     Worker worker = env.newWorker(TASK_QUEUE);
-    worker.registerWorkflowImplementationTypes(FulfillmentWorkflowImpl.class);
-    worker.registerActivitiesImplementations(new FulfillmentActivitiesImpl());
+    worker.registerWorkflowImplementationTypes(TransferWorkflowImpl.class);
+    worker.registerActivitiesImplementations(new BankActivitiesImpl());
     env.start();
     client = env.getWorkflowClient();
   }
@@ -41,57 +45,51 @@ void tearDown() {
     env.close();
   }
 
-  private FulfillmentWorkflow stub(String id) {
+  private TransferWorkflow stub(String id) {
     return client.newWorkflowStub(
-        FulfillmentWorkflow.class,
+        TransferWorkflow.class,
         WorkflowOptions.newBuilder().setTaskQueue(TASK_QUEUE).setWorkflowId(id).build());
   }
 
   @Test
-  void threePaymentFailuresThenTheFourthAttemptSucceeds() {
-    Services.PAYMENTS.failuresLeft.set(3);
+  void theBankFailsTheDepositTwiceAndTheTransferCompletesWithOneWithdrawal() {
+    bank.depositFailuresLeft.set(2);
 
-    String tracking = stub("order-1").fulfill("order-1");
+    stub("transfer-1").transfer(TRANSFER);
 
-    assertEquals(
-        "trk-order-1",
-        tracking,
-        "FulfillmentWorkflowImpl.java: the slide claims retries are configuration, so the order"
-            + " ships after three payment failures");
-    assertEquals(
-        4,
-        Services.PAYMENTS.calls.get(),
-        "FulfillmentWorkflowImpl.java: setMaximumAttempts(4) should allow exactly four payment"
-            + " attempts");
-    // A retry reruns the whole Activity, so the reservation is repeated: the speaker notes say
-    // why each service call must be idempotent by order ID.
-    assertEquals(
-        4,
-        Services.INVENTORY.calls.get(),
-        "FulfillmentActivitiesImpl.java: the notes claim a retry reruns the whole Activity,"
-            + " reservation included");
     assertEquals(
         1,
-        Services.SHIPPING.calls.get(),
-        "FulfillmentActivitiesImpl.java: shipping runs once, on the attempt that succeeds");
+        bank.withdrawCalls.get(),
+        "TransferWorkflowImpl.java: a failed deposit retries the deposit only; the withdrawal"
+            + " already happened and is not repeated");
+    assertEquals(
+        3,
+        bank.depositCalls.get(),
+        "TransferWorkflowImpl.java: the default Retry Policy retries the deposit until it succeeds");
+    assertEquals(500L, bank.balances.get("alice"), "alice is debited once");
+    assertEquals(500L, bank.balances.get("bob"), "bob is credited once");
   }
 
   @Test
-  void givesUpAfterMaximumAttemptsAndNeverShips() {
-    Services.PAYMENTS.failuresLeft.set(10);
+  void insufficientFundsIsNotRetriedAndNothingIsDeposited() {
+    bank.balances.put("alice", 100L);
 
-    assertThrows(
-        WorkflowFailedException.class,
-        () -> stub("order-2").fulfill("order-2"),
-        "FulfillmentWorkflowImpl.java: after setMaximumAttempts(4) the Activity failure should"
-            + " fail the Workflow");
+    WorkflowFailedException e =
+        assertThrows(
+            WorkflowFailedException.class,
+            () -> stub("transfer-2").transfer(TRANSFER),
+            "TransferWorkflowImpl.java: insufficient funds should fail the Workflow");
+    ActivityFailure activityFailure = assertInstanceOf(ActivityFailure.class, e.getCause());
+    ApplicationFailure cause =
+        assertInstanceOf(ApplicationFailure.class, activityFailure.getCause());
     assertEquals(
-        4,
-        Services.PAYMENTS.calls.get(),
-        "FulfillmentWorkflowImpl.java: setMaximumAttempts(4) means a fifth attempt is never made");
+        InsufficientFundsException.class.getName(),
+        cause.getType(),
+        "the failure type is the exception's class name, which setDoNotRetry lists");
     assertEquals(
-        0,
-        Services.SHIPPING.calls.get(),
-        "FulfillmentActivitiesImpl.java: an order whose payment never succeeds is never shipped");
+        1,
+        bank.withdrawCalls.get(),
+        "TransferWorkflowImpl.java: setDoNotRetry means one withdrawal attempt, not a retry");
+    assertEquals(0, bank.depositCalls.get(), "nothing is deposited when the withdrawal fails");
   }
 }
diff --git a/docs/adr/0004-temporal-essentials-is-java-master-ported-from-typescript.md b/docs/adr/0004-temporal-essentials-is-java-master-ported-from-typescript.md
index d6ed4b5..d705178 100644
--- a/docs/adr/0004-temporal-essentials-is-java-master-ported-from-typescript.md
+++ b/docs/adr/0004-temporal-essentials-is-java-master-ported-from-typescript.md
@@ -12,6 +12,14 @@ idiomatic Java against SDK 1.40.0 and proven the same way: runnable
 `snippets/`, tests that tie each slide's code to its snippet, runtime tests on
 `TestWorkflowEnvironment`, and a rendered walkthrough check in CI.
 
+On 2026-11-14 the Deck was brought up to `d9fbfcb` of the same source: the
+opening retold as one bank transfer, slides reordered (Design patterns after
+Activities, "Keep it in the Workflow" in Workflows, Resumable Activity after
+Updates, the idempotency slides closing the Saga section), new Worker,
+idempotency-key and compensation-Activity slides, and the Saga implementation
+taught as pseudocode before the real Java. Later syncs follow the same way:
+diff the source Deck from the last synced commit and port each change.
+
 ## Considered Options
 
 `decks/temporal-essentials/` was rejected: the Python and TypeScript repos both
diff --git a/docs/authoring/java-master-deck-sync.md b/docs/authoring/java-master-deck-sync.md
new file mode 100644
index 0000000..ecc95f0
--- /dev/null
+++ b/docs/authoring/java-master-deck-sync.md
@@ -0,0 +1,29 @@
+# Deck cost: Temporal Essentials (Java), sync to d9fbfcb
+
+Measured 2026-11-14 to 2026-11-14.
+
+README model: Opus 5.5 (100%)
+
+| Scope | Cost | Active | Messages | Transcripts |
+|---|--:|--:|--:|--:|
+| Main session | $13.13 | 0.3 h | 171 | 1 |
+
+> Active time is summed gaps under 5 minutes, so an idle session does not inflate it.
+> Main and subagent time overlap when they run concurrently — do not add the two.
+
+## Main session — by model
+
+| Model | Msgs | Input | Output | Thinking | Cache write | Cache read | Cost |
+|---|--:|--:|--:|--:|--:|--:|--:|
+| `claude-opus-5-5` | 171 | 354 | 156,126 | 34,295 | 494,264 | 30,259,168 | $13.13 |
+
+## Human time
+
+_Not measured. Fill in by hand._
+
+| Activity | Hours |
+|---|--:|
+| Review and correction | |
+| Deck rehearsal | |
+
+> The agent figures above are a **floor**, not the Deck cost.
diff --git a/docs/authoring/java-master-log.md b/docs/authoring/java-master-log.md
index 5f63760..d02c44a 100644
--- a/docs/authoring/java-master-log.md
+++ b/docs/authoring/java-master-log.md
@@ -11,3 +11,12 @@ One session, `a0e1b034-893b-48fc-b549-5d0192dac511`, measured with
 | Design interview, scaffold, proof harness | 2026-11-04T15:41:52Z | 2026-11-04T15:52:00Z |
 | Eight parallel Segment workers (worktrees), merges | 2026-11-04T15:52:00Z | 2026-11-04T16:26:22Z |
 | Full test run, rendered check, whole-Deck review, fixes | 2026-11-04T16:26:22Z | 2026-11-04T16:50:04Z |
+
+## Sync with the source Deck at `d9fbfcb` (2026-11-14)
+
+Ported the source Deck's changes since `a61bcf9` (ADR 0004). One session,
+`94463784-8f51-41aa-bec2-1d7ef03209e8`, no subagents, measured with
+`--transcript 94463784` into [`java-master-deck-sync.md`](java-master-deck-sync.md):
+$13.13. The README's Deck cost stays the original Port's figure; this record
+sits beside it.
+