MbappeWU · Oct 2, 2026 · Oct 2, 2026
diff --git a/README.md b/README.md
@@ -23,7 +23,7 @@ Does overtime get more done? Do AI coding tools really make teams faster? Is rem
 | [AI coding tools make developers faster.](chapters/01-ai.md#ai-faster) | Randomised trials found real but modest gains, such as about 21% less time at Google. Two trials found none. | ✓ Supported · B |
 | [Developers can tell whether AI is speeding them up.](chapters/01-ai.md#ai-self-estimate) | In METR's trial, developers believed AI saved them 20% of their time. The clock said it cost them 19%. | ✗ Not supported · C |
 | [Working longer hours gets more done.](chapters/03-hours.md#hours-more-output) | In the best-known study, output rose ever more slowly once weekly hours passed a threshold. | ~ It depends · B |
-| [It takes 23 minutes to recover from every interruption.](chapters/04-meetings.md#meetings-23-minutes) | The 23 minutes is how long people took to return to the task in one 24-person study, not how long they needed to refocus. | ✗ Not supported · B |
+| [It takes 23 minutes to recover from every interruption.](chapters/04-meetings.md#meetings-23-minutes) | In one 24-person observation, same-day returns averaged 25 minutes 26 seconds. It did not measure time to refocus. | ✗ Not supported · B |
 | [Open-plan offices increase collaboration.](chapters/04-meetings.md#meetings-open-plan-collaboration) | After two firms moved to open plan, face-to-face talk fell by about 70% and electronic messages rose. | ✗ Not supported · B |
 | [Working from home lowers productivity.](chapters/05-remote.md#remote-wfh-productivity) | Two randomised trials found a gain or no loss. A pandemic-era study of IT staff found output per hour fell 8 to 19%. | ~ It depends · B |
 | [70% of IT projects fail.](chapters/06-estimation.md#estimation-chaos-failure-rate) | The 70% counts any gap from the original estimate as failure, and two peer-reviewed critiques call the figures misleading. | ✗ Not supported · B |

diff --git a/README.zh-CN.md b/README.zh-CN.md
@@ -23,7 +23,7 @@
 | [AI 编程工具能让开发者更快完成工作。](chapters/01-ai.zh-CN.md#ai-faster) | 随机试验发现提速确实存在但幅度不大，比如谷歌那项约省 21% 的时间；另有两项试验没发现提速。 | ✓ 成立 · B |
 | [开发者自己能判断 AI 有没有让自己变快。](chapters/01-ai.zh-CN.md#ai-self-estimate) | METR 试验里，开发者以为 AI 帮自己省了 20% 的时间，实测反而多花了 19%。 | ✗ 不成立 · C |
 | [工作时间越长，做的事越多。](chapters/03-hours.zh-CN.md#hours-more-output) | 在最有名的研究里，每周工时超过某个门槛后，产出越涨越慢。 | ~ 视情况 · B |
-| [每被打断一次，就要花 23 分钟才能恢复专注。](chapters/04-meetings.zh-CN.md#meetings-23-minutes) | 23 分钟出自一项 24 人的观察，指的是回到原任务所用的时间，不是重新集中注意力需要的时间。 | ✗ 不成立 · B |
+| [每被打断一次，就要花 23 分钟才能恢复专注。](chapters/04-meetings.zh-CN.md#meetings-23-minutes) | 一项 24 人观察中，同日回到原工作的平均间隔是 25 分 26 秒，没有测量恢复专注时间。 | ✗ 不成立 · B |
 | [开放式办公室能促进协作。](chapters/04-meetings.zh-CN.md#meetings-open-plan-collaboration) | 两家公司改成开放式办公后，面对面交流下降约 70%，电子沟通反而增加。 | ✗ 不成立 · B |
 | [在家办公会降低工作效率。](chapters/05-remote.zh-CN.md#remote-wfh-productivity) | 两项随机试验发现居家有提升或没有损失；一项疫情期间的 IT 员工研究发现每小时产出下降 8% 至 19%。 | ~ 视情况 · B |
 | [70% 的 IT 项目都会失败。](chapters/06-estimation.zh-CN.md#estimation-chaos-failure-rate) | “70%”把任何偏离最初预估的项目都算作失败，两篇同行评审的批评认为这些数字有误导性。 | ✗ 不成立 · B |

diff --git a/assets/cards/en/meetings-23-minutes.png b/assets/cards/en/meetings-23-minutes.png
diff --git a/assets/cards/zh/meetings-23-minutes.png b/assets/cards/zh/meetings-23-minutes.png
diff --git a/chapters/04-meetings.md b/chapters/04-meetings.md
@@ -13,15 +13,15 @@ Key: ✓ supported · ~ it depends · ✗ not supported · ? unknown. After a so
 
 **✗ Not supported · Grade B** (Three designs (field observation, a lab experiment, programmer logs) fit together, and none measured a fixed 23-minute recovery, but each is small or indirect.)
 
-**What the research says.** The figure traces to Gloria Mark's field observation of 24 information workers (2005). Interrupted work was resumed after roughly 23 to 25 minutes on average, and people did about two other things first. That is time until return, not time to refocus. In a 2008 lab experiment with 48 participants, interrupted work was finished faster with no loss of quality, but with more stress, frustration and effort. A log study of 86 programmers found only 10% of sessions resumed coding within 1 minute of an interruption. Resuming is often slow, but none of these studies supports a fixed 23-minute cost.
+**What the research says.** In Mark, Gonzalez and Harris's 2005 observation of 24 information workers, same-day resumptions averaged 25 minutes 26 seconds (paper p. 326). People visited about two other working spheres before returning. That is time until return, not time to refocus. In a 2008 lab experiment with 48 participants, interrupted work was finished faster with no loss of quality, but with more stress, frustration and effort. A log study of 86 programmers found only 10% of sessions resumed coding within 1 minute of an interruption. Resuming is often slow, but none of these studies supports a fixed 23-minute cost.
 
-**Limits.** The field study had 24 information workers, not only developers. The lab study used a short email task with 48 participants. The log study measured when editing resumed, not how well people worked. None of them measured developers' recovery time directly, and sources quote the field average as both 23 and 25 minutes.
+**Limits.** The observation covered 24 information workers, not only developers; the lab used 48 people on email tasks; programmer logs tracked resumed editing, not output quality. The 2005 estimate counts same-day returns and excludes interruptions in the last work hour (SD 54 min 48 sec). None directly measured developers' time to refocus.
 
-> **Say this to your boss:** The 23 minutes is how long people took on average to get back to interrupted work in one observation study, not how long they needed to refocus. Interruptions do cost something, so let's batch non-urgent pings instead of quoting a number.
+> **Say this to your boss:** The 2005 observation found an average 25 minutes 26 seconds until same-day return to interrupted work. It did not measure time to refocus. Let's batch non-urgent pings instead of treating a study average as a fixed recovery cost.
 
 **What would change my mind.** A study that times how long developers take to get back to full speed after an interruption, using task time or error rates, and finds a stable figure near 23 minutes.
 
-**Sources** (checked 2026-10-01):
+**Sources** (checked 2026-10-02):
 
 1. Gloria Mark, Victor M. Gonzalez, Justin Harris (2005). No task left behind? Examining the nature of fragmented work. CHI 2005. [link](https://doi.org/10.1145/1054972.1055017) <sub>✓✓ metadata compared and registered quote snippets matched in the abstract</sub> (primary)
 2. Gloria Mark, Daniela Gudith, Ulrich Klocke (2008). The cost of interrupted work: more speed and stress. CHI 2008. [link](https://doi.org/10.1145/1357054.1357072) <sub>✓ metadata checked (title, authors, year)</sub> (primary)

diff --git a/chapters/04-meetings.zh-CN.md b/chapters/04-meetings.zh-CN.md
@@ -13,15 +13,15 @@
 
 **✗ 不成立 · 证据等级 B** （现场观察、实验室实验和程序员日志三类研究互相吻合，都没有测出固定的 23 分钟恢复时间，但样本较小或只是间接证据。）
 
-**研究怎么说.** 这个数字源自 Gloria Mark 2005 年对 24 名信息工作者的现场观察：被打断的工作平均隔约 23 到 25 分钟才被重新拾起，其间人们会先做约两件别的事。这是“隔多久回到原任务”，不是“多久才能重新专注”。2008 年一项 48 人的实验室实验发现，被打断的任务完成得更快、质量没有下降，但压力、挫败感和付出的努力更高。对 86 名程序员的日志研究发现，只有 10% 的会话在被打断后 1 分钟内恢复编码。恢复往往不快，但这些研究都不支持“固定 23 分钟”这个代价。
+**研究怎么说.** Mark、Gonzalez 和 Harris 2005 年对 24 名信息工作者的观察中，同日重新拾起被打断工作的平均间隔是 25 分 26 秒（论文第 326 页），其间人们会先处理约两项别的工作。这是“隔多久回到原任务”，不是“多久才能重新专注”。2008 年一项 48 人的实验室实验发现，被打断的任务完成得更快、质量没有下降，但压力、挫败感和付出的努力更高。对 86 名程序员的日志研究发现，只有 10% 的会话在被打断后 1 分钟内恢复编码。恢复往往不快，但这些研究都不支持“固定 23 分钟”这个代价。
 
-**局限.** 现场研究的 24 名信息工作者并非都是开发者；实验室研究是 48 人做的短时邮件任务；日志研究测的是何时恢复编辑，不是工作质量。它们都没有直接测过开发者的恢复时间。现场平均值在不同来源里有 23 分钟和 25 分钟两种说法。
+**局限.** 现场研究的 24 名信息工作者并非都是开发者；实验室研究是 48 人做的短时邮件任务；日志研究测的是何时恢复编辑，不是工作质量。它们都没有直接测过开发者的恢复时间。2005 年的返回间隔只统计同日恢复的工作，并排除了最后一个工作小时发生的打断。标准差为 54 分 48 秒，均值不是固定代价。
 
-> **对老板可以这样说:** 23 分钟是一项观察研究里人们平均隔多久才回到被打断的工作，不是重新专注所需的时间。打断确实有代价，所以我们把不紧急的消息集中处理，而不是引用这个数字。
+> **对老板可以这样说:** 2005 年那项观察中，同日回到被打断工作的平均间隔为 25 分 26 秒，没有测量恢复专注所需时间。我们把不紧急的消息集中处理，不把研究均值当成固定恢复代价。
 
 **什么证据会让我改口.** 有研究用任务耗时或错误率，直接测量开发者被打断后恢复到正常效率所需的时间，并得到一个稳定的、接近 23 分钟的数字。
 
-**出处** (核对于 2026-10-01):
+**出处** (核对于 2026-10-02):
 
 1. Gloria Mark, Victor M. Gonzalez, Justin Harris (2005). No task left behind? Examining the nature of fragmented work. CHI 2005. [link](https://doi.org/10.1145/1054972.1055017) <sub>✓✓ 元数据已比对，登记的引文片段已在摘要中匹配</sub> (主要来源)
 2. Gloria Mark, Daniela Gudith, Ulrich Klocke (2008). The cost of interrupted work: more speed and stress. CHI 2008. [link](https://doi.org/10.1145/1357054.1357072) <sub>✓ 元数据已核对（标题、作者、年份）</sub> (主要来源)

diff --git a/data/claims/meetings-23-minutes.json b/data/claims/meetings-23-minutes.json
@@ -12,16 +12,16 @@
     "zh": "现场观察、实验室实验和程序员日志三类研究互相吻合，都没有测出固定的 23 分钟恢复时间，但样本较小或只是间接证据。"
   },
   "evidence": {
-    "en": "The figure traces to Gloria Mark's field observation of 24 information workers (2005). Interrupted work was resumed after roughly 23 to 25 minutes on average, and people did about two other things first. That is time until return, not time to refocus. In a 2008 lab experiment with 48 participants, interrupted work was finished faster with no loss of quality, but with more stress, frustration and effort. A log study of 86 programmers found only 10% of sessions resumed coding within 1 minute of an interruption. Resuming is often slow, but none of these studies supports a fixed 23-minute cost.",
-    "zh": "这个数字源自 Gloria Mark 2005 年对 24 名信息工作者的现场观察：被打断的工作平均隔约 23 到 25 分钟才被重新拾起，其间人们会先做约两件别的事。这是“隔多久回到原任务”，不是“多久才能重新专注”。2008 年一项 48 人的实验室实验发现，被打断的任务完成得更快、质量没有下降，但压力、挫败感和付出的努力更高。对 86 名程序员的日志研究发现，只有 10% 的会话在被打断后 1 分钟内恢复编码。恢复往往不快，但这些研究都不支持“固定 23 分钟”这个代价。"
+    "en": "In Mark, Gonzalez and Harris's 2005 observation of 24 information workers, same-day resumptions averaged 25 minutes 26 seconds (paper p. 326). People visited about two other working spheres before returning. That is time until return, not time to refocus. In a 2008 lab experiment with 48 participants, interrupted work was finished faster with no loss of quality, but with more stress, frustration and effort. A log study of 86 programmers found only 10% of sessions resumed coding within 1 minute of an interruption. Resuming is often slow, but none of these studies supports a fixed 23-minute cost.",
+    "zh": "Mark、Gonzalez 和 Harris 2005 年对 24 名信息工作者的观察中，同日重新拾起被打断工作的平均间隔是 25 分 26 秒（论文第 326 页），其间人们会先处理约两项别的工作。这是“隔多久回到原任务”，不是“多久才能重新专注”。2008 年一项 48 人的实验室实验发现，被打断的任务完成得更快、质量没有下降，但压力、挫败感和付出的努力更高。对 86 名程序员的日志研究发现，只有 10% 的会话在被打断后 1 分钟内恢复编码。恢复往往不快，但这些研究都不支持“固定 23 分钟”这个代价。"
   },
   "caveats": {
-    "en": "The field study had 24 information workers, not only developers. The lab study used a short email task with 48 participants. The log study measured when editing resumed, not how well people worked. None of them measured developers' recovery time directly, and sources quote the field average as both 23 and 25 minutes.",
-    "zh": "现场研究的 24 名信息工作者并非都是开发者；实验室研究是 48 人做的短时邮件任务；日志研究测的是何时恢复编辑，不是工作质量。它们都没有直接测过开发者的恢复时间。现场平均值在不同来源里有 23 分钟和 25 分钟两种说法。"
+    "en": "The observation covered 24 information workers, not only developers; the lab used 48 people on email tasks; programmer logs tracked resumed editing, not output quality. The 2005 estimate counts same-day returns and excludes interruptions in the last work hour (SD 54 min 48 sec). None directly measured developers' time to refocus.",
+    "zh": "现场研究的 24 名信息工作者并非都是开发者；实验室研究是 48 人做的短时邮件任务；日志研究测的是何时恢复编辑，不是工作质量。它们都没有直接测过开发者的恢复时间。2005 年的返回间隔只统计同日恢复的工作，并排除了最后一个工作小时发生的打断。标准差为 54 分 48 秒，均值不是固定代价。"
   },
   "boss_line": {
-    "en": "The 23 minutes is how long people took on average to get back to interrupted work in one observation study, not how long they needed to refocus. Interruptions do cost something, so let's batch non-urgent pings instead of quoting a number.",
-    "zh": "23 分钟是一项观察研究里人们平均隔多久才回到被打断的工作，不是重新专注所需的时间。打断确实有代价，所以我们把不紧急的消息集中处理，而不是引用这个数字。"
+    "en": "The 2005 observation found an average 25 minutes 26 seconds until same-day return to interrupted work. It did not measure time to refocus. Let's batch non-urgent pings instead of treating a study average as a fixed recovery cost.",
+    "zh": "2005 年那项观察中，同日回到被打断工作的平均间隔为 25 分 26 秒，没有测量恢复专注所需时间。我们把不紧急的消息集中处理，不把研究均值当成固定恢复代价。"
   },
   "change_my_mind": {
     "en": "A study that times how long developers take to get back to full speed after an interruption, using task time or error rates, and finds a stable figure near 23 minutes.",
@@ -44,10 +44,10 @@
       "role": "context"
     }
   ],
-  "verified_on": "2026-10-01",
+  "verified_on": "2026-10-02",
   "headline": true,
   "hook": {
-    "en": "The 23 minutes is how long people took to return to the task in one 24-person study, not how long they needed to refocus.",
-    "zh": "23 分钟出自一项 24 人的观察，指的是回到原任务所用的时间，不是重新集中注意力需要的时间。"
+    "en": "In one 24-person observation, same-day returns averaged 25 minutes 26 seconds. It did not measure time to refocus.",
+    "zh": "一项 24 人观察中，同日回到原工作的平均间隔是 25 分 26 秒，没有测量恢复专注时间。"
   }
 }