# 助理巡檢目錄

> 由 `jsc-assist` 維護。這是目錄頁 `MONITOR_CONTENTS`。
> 一列代表一台機器。雜湊來源是 `{主機名}/{登入帳號}`，所以一台機器一列、一頁，換一支 CLI 不另開列。
> `MONITOR_{HASH}` 的 `{HASH}` 交給 `jsc-gitea/tools/hash-id` 產生，雜湊來源見 `jsc-meta` 的 `references/guidelines.md`「Wiki 頁命名總表」。

| 監控頁 | 主機 | 帳號 | 心跳 | 最後巡檢 | 待辦筆數 | 連續失敗項 |
| --- | --- | --- | --- | --- | ---: | ---: |
| [[MONITOR_{HASH}]] | {主機名} | {登入帳號} | {新鮮、過期、不存在 三選一} | {yyyy-MM-dd HH:mm} | {n} | {n} |

## 欄位說明

| 欄位 | 內容 | 為什麼留這一欄 |
| --- | --- | --- |
| 監控頁 | 指向 `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}` 的寫入語意相反，那頁只附加一節、不覆寫，兩者不要混用。