fix/run-due-rows-path-must-be-passed-in
develop
tools/patrol.sh
collect
due_rows_file=
tools/run-due.sh
--rows
skills/assistant/SKILL.md
references/behaviors.md
判到期與執行是兩支腳本,中間靠一個檔案交棒:
--out
不是同一個地方。所以執行那一支每一輪讀的都是「上一次有人手動跑判定留下的那一份」。
那份舊清單產生的當下是對的,內容剛好沒變,所以每一輪的報告都合理:到期 15 筆、跑 2 筆、held 1 筆,數字都對得上。
顯形是因為我手動跑了一次重新種入,那一筆的識別碼跟著換了。下一輪的報告仍然報著舊識別碼——它跑了一筆已經不存在的待辦,那才看得出來讀的不是同一份資料。
一、把被吞掉的那個路徑轉出去。 判到期那一支本來就印 rows_file=,是巡檢那一步只轉出給人看的 due_file=,機器可讀的那一份被吞掉了。呼叫端於是只能靠預設值猜。
rows_file=
due_file=
二、拿掉預設值。 少帶那個選項就回用法錯誤。吵一次總比安靜地對舊資料動手好——而且預設值指向的位置在單機手動跑過一次之後就會有檔案,那個檔案讀起來跟新的一模一樣。
判到期與執行之間隔著呼叫端,那一段有可能斷掉:判定失敗了而那一輪照樣往下走,或呼叫端餵進上一輪的路徑。
門檻取心跳的過期門檻——那是這台機器認定「一輪跑完的紀錄還算新鮮」的長度,一份比它還舊的到期清單本來就不可能是這一輪產生的。讀不到門檻就退回 300 秒,跟心跳那一支的預設一致。
NOW
set -u
lint-scripts.sh
check-behaviors.sh
ste100-lint.sh
check-skill-paths.sh
判到期與執行是兩支腳本,中間靠一個檔案交棒。判到期那一支是被巡檢用 --out 叫的,輸出寫進那一輪自己的暫存目錄;而執行那一支留了一個預設路徑,指向助理 狀態目錄底下那一份。兩邊不是同一個位置。 於是執行那一支從上線到現在,每一輪讀的都是「上一次有人手動跑判定留下的那一 份」。實測那份清單在機器上放了 67 小時,每一輪都被拿去動手,其中一輪還跑了 一筆已經被移除的待辦——那一筆的識別碼在重新種入時換過了。 而它看起來完全正常。那份舊清單產生的當下是對的,內容剛好沒變,所以每一輪的 報告都合理。錯了 67 小時才顯形。 兩處改動。判到期那一步本來只把給人看的那個檔案轉出去,機器可讀的那一份被 吞掉了,現在一起印成 due_rows_file=。執行那一支拿掉預設值:少帶那個選項就 回用法錯誤,吵一次總比安靜地對舊資料動手好。 另外加一道時效保護。判到期與執行之間隔著呼叫端,那一段有可能斷掉——判定失敗 了而那一輪照樣往下走,或呼叫端餵進上一輪的路徑。門檻取心跳的過期門檻:那是 這台機器認定「一輪跑完的紀錄還算新鮮」的長度,一份比它還舊的到期清單本來就 不可能是這一輪產生的。讀不到門檻就退回 300 秒,跟心跳那一支的預設一致。 實測:不帶選項回 6,清單不存在回 2,兩小時前的清單回 2 且訊息帶出實際秒數與 門檻,新的空清單回 0;拿真機那份 67 小時前的舊清單餵進去,確實被擋下。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
巡檢步驟五改成帶 --rows,值取步驟一印的那個新欄位,並寫明那不是選用的、 也沒有預設值。步驟一的記錄清單跟著補上那個欄位,並註明它是空的時候代表判到期 那一步沒有產出清單,步驟五就沒有東西可動,要照實說而不是退回任何預設。 會把「為什麼不能有預設」寫進本文,是因為這個缺陷的形狀值得留下來:預設值指向 的位置在單機手動跑過一次之後就會有檔案,而那個檔案讀起來跟新的一模一樣。 三份 manifest 版號 0.2.7 升到 0.2.8。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
No dependencies set.
The note is not visible to the blocked user.
摘要
變更內容
tools/patrol.shcollect除了給人看的那個檔案,也轉出機器可讀的due_rows_file=tools/run-due.sh--rows的預設值,一律要指定;再加一道時效保護skills/assistant/SKILL.md--rows,步驟一的記錄清單補上那個欄位references/behaviors.md兩邊各自預設了不同位置
判到期與執行是兩支腳本,中間靠一個檔案交棒:
--out不是同一個地方。所以執行那一支每一輪讀的都是「上一次有人手動跑判定留下的那一份」。
為什麼 67 小時都沒被發現
那份舊清單產生的當下是對的,內容剛好沒變,所以每一輪的報告都合理:到期 15 筆、跑 2 筆、held 1 筆,數字都對得上。
顯形是因為我手動跑了一次重新種入,那一筆的識別碼跟著換了。下一輪的報告仍然報著舊識別碼——它跑了一筆已經不存在的待辦,那才看得出來讀的不是同一份資料。
兩處改動
一、把被吞掉的那個路徑轉出去。 判到期那一支本來就印
rows_file=,是巡檢那一步只轉出給人看的due_file=,機器可讀的那一份被吞掉了。呼叫端於是只能靠預設值猜。二、拿掉預設值。 少帶那個選項就回用法錯誤。吵一次總比安靜地對舊資料動手好——而且預設值指向的位置在單機手動跑過一次之後就會有檔案,那個檔案讀起來跟新的一模一樣。
再加一道時效保護
判到期與執行之間隔著呼叫端,那一段有可能斷掉:判定失敗了而那一輪照樣往下走,或呼叫端餵進上一輪的路徑。
門檻取心跳的過期門檻——那是這台機器認定「一輪跑完的紀錄還算新鮮」的長度,一份比它還舊的到期清單本來就不可能是這一輪產生的。讀不到門檻就退回 300 秒,跟心跳那一支的預設一致。
測試結果
--rowsNOW與工具搜尋函式定義之前,set -u之下會直接炸。移到兩者之後才通過語法與實測。lint-scripts.sh、check-behaviors.sh、ste100-lint.sh、check-skill-paths.sh四支都回結束碼 0。前置 Push Request