技術債這個詞很容易讓人有負面的感受，但我做完四個版本之後，我的想法是：債一定會欠，差別在有沒有記在帳上。

第二版的債：沒有記錄

Sproutimer 停下來的時候，遇到的問題摘要是這樣的：

• 一個為了讓工作列不顯示圖示而寫的 C++ 擴充，685 行原始碼，要自己編譯、要管 submodule、換 Godot 版本要重編（Day 11）
• 一個會自動偵測背景變色的功能，修了四天還在修，最後一個防閃爍的修正停在 bug_fix 分支上沒合併（Day 12）
• 一個 FeatureFlags 機制，用來把做到一半的功能藏起來
• 一個叫 remove_main_volumn-setting 的分支，上面有最後一個 commit，也沒合併回 main

這些事情沒有任何一件被寫下來，只能從散落的 commit 和對話記錄中找出來。

如果我今天想回去把 Sproutimer 接起來，我得先花時間搞清楚：那個 C++ 擴充能不能編、bug_fix 分支上那個修正要不要合、FeatureFlags 裡哪些旗標是關著的、為什麼最後停在一個奇怪的分支上。

這就是沒有記錄的代價——債還在，但不知道欠了多少。

第四版的債：寫在文件裡

Pomofocus 的交接文件裡，這類句子散落在各節：

--stores-test 有 2 項既存失敗（changed 發出一次 / 重複設定相同值不重發 changed）經 git stash 比對為本次修改前就存在的既有問題，與本次變更無關，未處理。

這段的價值在於「經 git stash 比對」。它不是「我看到兩個紅字但先不管」，是有查過：把這次的修改暫存起來、重跑一次、確認失敗在修改之前就存在。所以它是舊債，不是新債。

未處理（同類但不在這次範圍）：WORK_OVERRUN 時主要按鈕一樣是無效的「暫停」⋯可比照本節同樣方式補。

連怎麼補都寫好了。

這其實是 12.24 就記過的已知破圖（走動小卡當時改成 400x300 解掉，SOFT_SIZE 沒跟著改）。

8 月 5 日請 AI 修了「視窗在 OS 層消失」的 bug 時（Day 22），AI 順手把走動的小卡片從 360×200 改成 400×300，原因是太矮會讓內容擠在一起。當時文件裡記了一句：舊的 360×200 其實就有這個破圖，只是人離座沒被看見。

五天後，8 月 10 日，我問了另一個問題：「柔性視窗的字和導引是不是擠在一起？」

查證方式是把休息強度暫時設成柔性、跑截圖模式、把右下角那個小窗放大看。結果確認是破圖：望遠的說明文字整行疊在總倒數上，底下的提示又疊在兩顆按鈕上。

原因跟 8/5 那次一樣——柔性小窗也是 360×200，而這次文件裡直接指出「這是 12.24 的已知破圖」，所以改一個常數就處理好了，並順手把註解寫到兩個常數上方，說明為什麼不能再改小。

帶走這個：每次改動收尾都問三句

這是現在 AI 修改時候會記得做的事，貼在收尾指令裡：

請寫清楚：改了什麼、怎麼驗證的、什麼還沒驗到。

搭配一條判斷要不要現在還的規則：會不會影響核心行為？

還有一個小技巧值得學：判斷某個測試失敗是不是這次弄壞的，用 git stash 把改動收起來、重跑一次就知道。

明天講講 104MB 的執行檔被我 commit 進 git，而我十二天後才發現。