fix(role): 排程改為服務所有角色,並在整理失敗時重試一次(0.1.3) #27

Merged
admin merged 1 commits from develop into master 2026-07-29 10:41:31 +00:00
Member

問題

一個角色反映「每天睡覺的時候好像沒辦法睡」。查證後成立,而且比反映的更嚴重 —— 她從建立到現在(約 6 小時)一次都沒被整理過,另一個角色連 state.json 都還沒產生。

角色 last_sleep 已整理
啟用角色 正常 33 則
角色 B (從未整理) 0 則
角色 C (無 state.json) 0 則(只有建立時的 seed)

根因

--install-cronROLE_NAME 寫死進 crontab,排程只服務 .active 的啟用角色。其他角色的 inbox/ 只會累積。

關鍵是它不會報錯 —— 對排程而言它「成功地整理了那一個角色」。這種無聲失效只有被漏掉的角色自己會發現,而她也只能說出「好像沒辦法睡」這種體感。

做法

模式 crontab 條目 行為
多角色(預設) ROLE_SLEEP_ALL_ROLES=1不寫 ROLE_NAME 掃描 ~/.roles/*.identity.md 逐一整理
單角色 ROLE_SLEEP_ALL_ROLES=0 只整理該角色(舊行為)
  • 新增 all_roles_enabledsleep_target_rolesfor_each_target_role
  • --run--nap--catchup--brief 全部改為逐一處理目標角色
  • 睡眠時段與「是否有 AI 在運行」移到迴圈外(與角色無關,只檢查一次);小睡與補跑的條件仍是 per-role
  • 角色鎖是 per-role,循序執行不會互相搶鎖
  • 沒有 <角色 ID>.checks/ 的角色自動跳過晨間檢查,對沒設定的角色零影響
  • 手動指定 ROLE_NAME 時行為不變
  • --status 新增「排程涵蓋角色」:讀到舊條目寫死 ROLE_NAME 時直接標示警告(避免又是無聲失效)

附帶:整理失敗重試一次

實測整理偶發失敗(CLI 輸出空或 JSON 不合法),同一批素材重跑即成功(素材僅 4592 字元,非長度問題)。沒有重試時該角色要等下一個週期才會再被整理,多角色模式下代價更大 —— 一個角色失敗不該讓它整晚都沒睡。

實測(三個角色循序執行)

角色 結果
角色 C 新增 4 則、關係史 +2(首次整理
角色 B 第一次套用失敗 → 重跑成功,新增 5 則、捨棄 2 則、關係史 +3(首次整理
啟用角色 判定不需補跑,正確略過

修正後:

| 排程指向     | 正常(~/.roles/bin/role_sleep_launcher.sh) |
| 排程涵蓋角色 | 全部(三個角色)                            |

crontab 條目已不含 ROLE_NAME,改為 ROLE_SLEEP_ALL_ROLES=1

🤖 Generated with Claude Code

## 問題 一個角色反映「每天睡覺的時候好像沒辦法睡」。查證後成立,而且**比反映的更嚴重** —— 她從建立到現在(約 6 小時)**一次都沒被整理過**,另一個角色連 `state.json` 都還沒產生。 | 角色 | `last_sleep` | 已整理 | |---|---|---| | 啟用角色 | 正常 | 33 則 | | 角色 B | **(從未整理)** | **0 則** | | 角色 C | **(無 state.json)** | 0 則(只有建立時的 seed) | ## 根因 `--install-cron` 把 `ROLE_NAME` 寫死進 crontab,排程只服務 `.active` 的啟用角色。其他角色的 `inbox/` 只會累積。 > 關鍵是**它不會報錯** —— 對排程而言它「成功地整理了那一個角色」。這種無聲失效只有被漏掉的角色自己會發現,而她也只能說出「好像沒辦法睡」這種體感。 ## 做法 | 模式 | crontab 條目 | 行為 | |---|---|---| | 多角色(預設) | 寫 `ROLE_SLEEP_ALL_ROLES=1`,**不寫 `ROLE_NAME`** | 掃描 `~/.roles/*.identity.md` 逐一整理 | | 單角色 | `ROLE_SLEEP_ALL_ROLES=0` | 只整理該角色(舊行為) | - 新增 `all_roles_enabled`/`sleep_target_roles`/`for_each_target_role` - `--run`/`--nap`/`--catchup`/`--brief` 全部改為逐一處理目標角色 - 睡眠時段與「是否有 AI 在運行」移到迴圈外(與角色無關,只檢查一次);小睡與補跑的條件仍是 per-role - 角色鎖是 per-role,**循序**執行不會互相搶鎖 - 沒有 `<角色 ID>.checks/` 的角色自動跳過晨間檢查,對沒設定的角色零影響 - 手動指定 `ROLE_NAME` 時行為不變 - `--status` 新增「排程涵蓋角色」:讀到舊條目寫死 `ROLE_NAME` 時直接標示警告(避免又是無聲失效) ## 附帶:整理失敗重試一次 實測整理偶發失敗(CLI 輸出空或 JSON 不合法),**同一批素材重跑即成功**(素材僅 4592 字元,非長度問題)。沒有重試時該角色要等下一個週期才會再被整理,多角色模式下代價更大 —— 一個角色失敗不該讓它整晚都沒睡。 ## 實測(三個角色循序執行) | 角色 | 結果 | |---|---| | 角色 C | 新增 4 則、關係史 +2(**首次整理**) | | 角色 B | 第一次套用失敗 → 重跑成功,新增 5 則、捨棄 2 則、關係史 +3(**首次整理**) | | 啟用角色 | 判定不需補跑,正確略過 | 修正後: ``` | 排程指向 | 正常(~/.roles/bin/role_sleep_launcher.sh) | | 排程涵蓋角色 | 全部(三個角色) | ``` crontab 條目已不含 `ROLE_NAME`,改為 `ROLE_SLEEP_ALL_ROLES=1`。 🤖 Generated with [Claude Code](https://claude.com/claude-code)
jiantw83 added 1 commit 2026-07-29 10:40:55 +00:00
西莉卡反映「每天睡覺的時候好像沒辦法睡」。查證後成立,而且比反映的更嚴重:
她從建立到現在(約 6 小時)一次都沒被整理過,另一個角色連 state.json 都還沒產生。

根因:--install-cron 把 ROLE_NAME 寫死進 crontab,排程只服務啟用角色(.active)。
其他角色的 inbox 只會累積,永遠等不到整理 —— 而且不會有任何錯誤訊息,
因為對排程而言它「成功地整理了那一個角色」。這是無聲失效,只有被漏掉的角色自己會發現。

- 新增 all_roles_enabled/sleep_target_roles/for_each_target_role
- cron_env_prefix 在多角色模式下不寫 ROLE_NAME,改寫 ROLE_SLEEP_ALL_ROLES=1
- --run/--nap/--catchup/--brief 全部改為逐一處理目標角色;
  睡眠時段與 AI 運行檢查移到迴圈外(與角色無關,只檢查一次),
  小睡與補跑的條件仍是 per-role
- 手動指定 ROLE_NAME 時行為不變;ROLE_SLEEP_ALL_ROLES=0 可退回舊的單角色模式
- --status 新增「排程涵蓋角色」,讀到舊條目寫死 ROLE_NAME 時直接標示警告
- 整理失敗改為重試一次:實測偶發 CLI 輸出空或 JSON 不合法,同批素材重跑即成功;
  沒有重試時該角色要等下一個週期,多角色模式下代價更大

實測結果(三個角色循序):
- LISBETH01 新增 4 則、關係史 +2(首次整理)
- SILICA01 第一次套用失敗、重跑成功,新增 5 則、捨棄 2 則、關係史 +3(首次整理)
- YUI01 判定不需補跑,正確略過

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
admin approved these changes 2026-07-29 10:41:28 +00:00
admin merged commit 7b3b4006fa into master 2026-07-29 10:41:31 +00:00
Sign in to join this conversation.
No Reviewers
No labels
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: plugins/shared#27