diff --git a/docs/en/lectures/lecture-03-why-the-repository-must-become-the-system-of-record/index.md b/docs/en/lectures/lecture-03-why-the-repository-must-become-the-system-of-record/index.md
index 4954f11..3dbf811 100644
--- a/docs/en/lectures/lecture-03-why-the-repository-must-become-the-system-of-record/index.md
+++ b/docs/en/lectures/lecture-03-why-the-repository-must-become-the-system-of-record/index.md
@@ -93,7 +93,7 @@ project/
 
 This analogy comes from database transaction management. You might feel like this is overcomplicating things, but it actually provides a very practical framework:
 
-- **Atomicity**: Each "logical operation" (e.g., "add new endpoint and update tests") gets one git commit. If it fails midway, `git stash` to roll back. All or nothing — no "half done."
+- **Atomicity**: A "logical operation" (say, adding an endpoint and updating its tests) is committed as a whole only once it's complete and verified. A failed or abandoned attempt gets discarded, not partially merged. All or nothing.
 - **Consistency**: Define "consistent state" verification predicates — all tests pass, lint reports zero errors. The agent runs verification after each operation; inconsistent intermediate states should not be committed. After an operation, the system should be in a verifiably correct state.
 - **Isolation**: When multiple agents work concurrently, design state files to avoid race conditions. Simple approach: each agent uses its own progress file, or use git branches for isolation. Concurrent writes to the same file are a common source of trouble.
 - **Durability**: Critical project knowledge lives in git-tracked files. Temporary state can stay in session memory, but knowledge that must survive across sessions has to be written to files. What's in your head doesn't count — only what's written down counts.
diff --git a/docs/zh-TW/lectures/lecture-03-why-the-repository-must-become-the-system-of-record/index.md b/docs/zh-TW/lectures/lecture-03-why-the-repository-must-become-the-system-of-record/index.md
index ae14955..a7c40af 100644
--- a/docs/zh-TW/lectures/lecture-03-why-the-repository-must-become-the-system-of-record/index.md
+++ b/docs/zh-TW/lectures/lecture-03-why-the-repository-must-become-the-system-of-record/index.md
@@ -93,7 +93,7 @@ project/
 
 這個類比來自資料庫的事務管理，你可能覺得這是在把簡單的事情搞複雜，但實際上它給了你一個非常實用的框架。
 
-- **原子性**：每次「邏輯操作」（比如「添加新端點並更新測試」）用一個 git commit 原子化。中途掛了就 `git stash` 回溯。要麼全做，要麼不做，沒有「做了一半」。
+- **原子性**：每個「邏輯操作」（例如新增端點並更新測試）要等全部改完、驗證通過，才提交成一個 commit。做到一半失敗或放棄，直接丟掉，別留半成品。要嘛做完，要嘛當作沒發生過。
 - **一致性**：定義「一致狀態」的驗證謂詞，所有測試通過、lint 無報錯。Agent 每次操作後跑驗證，不一致的中間狀態不要 commit。
 - **隔離性**：多個 agent 併發工作時，狀態檔案要避免競爭條件。簡單方案：每個 agent 用獨立的進度檔案，或者用 git 分支隔離。
 - **持久性**：關鍵的專案知識用 git 跟蹤的檔案持久化。臨時狀態可以只在工作階段的記憶體中，但跨工作階段必須的知識必須寫到檔案裡。