Add "MONITOR_CONTENTS"

MONITOR_CONTENTS.md

@@ -0,0 +1,45 @@
+# 助理巡檢目錄
+
+> 由 `jsc-assist` 維護。這是目錄頁 `MONITOR_CONTENTS`。
+> 一列代表一台機器。雜湊來源是 `{主機名}/{登入帳號}`，所以一台機器一列、一頁，換一支 CLI 不另開列。
+> `MONITOR_{HASH}` 的 `{HASH}` 交給 `jsc-gitea/tools/hash-id` 產生，雜湊來源見 `jsc-meta` 的 `references/guidelines.md`「Wiki 頁命名總表」。
+
+| 監控頁 | 主機 | 帳號 | 心跳 | 最後巡檢 | 待辦筆數 | 連續失敗項 |
+| --- | --- | --- | --- | --- | ---: | ---: |
+| [[MONITOR_FF96B7BF]] | default | coder | 不存在 | 2026-09-01 08:34 | 0 | 0 |
+| [[MONITOR_87EC88F6C076B4F655975D8DF71BB84C97A0AE7B]] | 112C753 | root | 新鮮 | 2026-09-02 12:45 | 0 | 0 |
+
+## 欄位說明
+
+| 欄位 | 內容 | 為什麼留這一欄 |
+| --- | --- | --- |
+| 監控頁 | 指向 `MONITOR_{HASH}` 的同 wiki 連結 | 少了連結就要人自己算雜湊才翻得到內容頁 |
+| 主機 | 這台機器的主機名，與雜湊第一段相同 | 比對用的兩欄之一，決定要更新哪一列 |
+| 帳號 | 助理執行時的登入帳號，與雜湊第二段相同 | 比對用的兩欄之一。同一台機器換帳號就是另一個巡檢對象 |
+| 心跳 | 巡檢當下（本輪寫入前）的心跳判定，判準只看 `ts` 距現在有沒有超過門檻，預設 300 秒 | 一眼看出這台機器上一輪巡檢有沒有跑完，不必逐頁翻 |
+| 最後巡檢 | 該頁最新一節的時間戳 | 心跳由巡檢寫，兩欄理當一致；差很多就代表有一輪寫了心跳卻沒寫頁，那是缺陷 |
+| 待辦筆數 | 待辦簿現有筆數 | 心跳新鮮而筆數為 0，代表助理空轉，沒有東西可跑 |
+| 連續失敗項 | 該頁最新一節裡 `fail_count` 大於 0 的筆數 | 待辦簿的項目失敗不會自動暫停，每輪都重試。這一欄讓壞掉的項目在目錄頁就現形 |
+
+## 寫入規則
+
+這一頁是共用目錄，別台機器的列一律原樣保留。
+
+```mermaid
+flowchart TD
+  A[整頁讀回來] --> B{讀得到舊內容}
+  B -- 否 --> C[中止：不新增列，也不寫入]
+  B -- 是 --> D{主機與帳號兩欄都對得上}
+  D -- 是 --> E[只覆寫那一列的其餘欄位]
+  D -- 否 --> F[新增一列]
+  E --> G[其他機器的列原樣送回]
+  F --> G
+```
+
+- 先整頁讀回來，再比對主機與帳號兩欄。
+- 兩欄都相同就更新那一列，其餘欄位覆寫成本次巡檢結果。
+- 找不到兩欄都相同的列，才新增一列。
+- 只動自己那一列，別台機器的列一個字都不改。
+- 禁止整頁覆蓋。整頁覆蓋等於刪掉別台機器的紀錄。
+- 讀不到舊內容就中止，不新增列，也不寫入。
+- 內容頁 `MONITOR_{HASH}` 的寫入語意相反，那頁只附加一節、不覆寫，兩者不要混用。