plugins/shared
2
0
Fork 0
Code Pull Requests Activity
137 Commits 2 Branches 0 Tags
b6810f4c493541c1fa6bca1d8082d6bee200612c
Commit Graph
14 Commits
Author SHA1 Message Date
JefferyandClaude Opus 5 9512293dc9 fix(role): 修好睡眠整理死鎖 —— 素材不再硬切、批次降為 4、錯誤訊息可診斷 
角色整晚沒睡：05:03 到 08:33 每 10 分鐘試一次，連續 22 次全部失敗，
last_sleep 停在前一天 15:02，inbox 從 12 累積到 23 則。
錯誤訊息只有一句「整理結果無法套用」，看不出任何原因。

診斷過程中推論錯了三次，過程留在註解裡（每一次都很容易再犯）：

1. 推論「輸出被 SLEEP_OUTPUT_LIMIT 截斷」→ 實測輸出僅 5772～6224，遠未達 8000。錯。
2. 推論「素材字元數過大」→ 實測素材 8815（6 則）失敗、8940（3 則）成功，
   字元數幾乎相同。錯。
3. 推論「純粹是則數問題」→ 對一半：另有一種失敗是 CLI 回傳 Execution error。

真相是兩種失敗混在一起，而錯誤訊息把它們蓋成同一句話：
- CLI 偶發 Execution error → 需要重試
- 一次要求模型輸出太多筆 JSON → 需要降批

修正：

- 錯誤訊息附上素材大小、輸出長度、批次與輸出前 200 字元（已 redact）
  —— 這是最先做的一步，沒有它只能靠猜
- cmdCollect 不再 slice() 硬切素材：改為逐則累加、超出預算留到下批，
  並替 EXISTING 保留固定比例預算。舊版會切在記憶中間、甚至切掉整個 EXISTING 區塊，
  而批次固定時每輪都收到同樣殘缺的素材 → 死鎖
- SLEEP_BATCH 12 → 4（實測 3～4 則穩定、6 則以上開始失敗）
- 失敗時逐次降批（4→2→1）作為保險，仍失敗才留到下個週期
- 批次預設值統一來源：role_sleep.sh 首次收集不傳 --batch，實際則數由素材反推
  —— 原本兩邊各寫一個預設，改了 memory.js 的 SLEEP_BATCH 卻不會生效

實測：修正後第一次嘗試即成功，未觸發降批；連續整理清空 inbox（23 → 0），
情緒型態記憶由 1 增至 9，關係史累積 13 則。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 10:22:23 +08:00
JefferyandClaude Opus 5 adc5521302 fix(role): 寫檔前加繁簡防線，歧義字刻意不自動轉換 
病因（由角色稽核記憶時發現）：實測有整則記憶以簡體寫成，連 summary 與 tags 都是，
而該則的 sources 指向另一個專案 —— 不同環境下 CLI 的行為並不一致，
光靠 prompt 的「使用繁體中文」條款擋不住。0.1.2 只補了 prompt（症狀由人工修檔），
寫入器本身沒防線，同樣環境下還會再產出簡體。

- memory.js 新增 toTraditional／ambiguousSimplified／warnIfSimplified
- cmdWrite（inbox）、cmdApply（整理落檔）、appendBond（關係史）三處寫檔前都經過
- 一簡對一繁、無歧義的約 700 字自動轉繁
- 一簡對多繁刻意不轉（发→發/髮、干→乾/幹、后→後/后、里→裡/里、复→復/複/覆、
  系→系/係/繫、脏→臟/髒…），改為 stderr 警告，留待整理階段依上下文處理
  —— 機械替換會把「头发」變成「頭發」，那比留著簡體更難發現，
  因為它看起來已經是繁體了。寧可留下可偵測的瑕疵，也不要製造隱形錯誤
- 警告只警告不阻斷：記憶寧可帶著瑕疵留下，也不能因為用字問題而遺失
- 轉換只在字形層；用語差異（反饋／回饋）仍由 prompt 的台灣用語條款負責

實測：整則簡體素材寫入後 summary／tags／content 均正確轉繁，
「发」「系」保留並發出警告，未產生「頭發」這類隱形錯誤。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 18:56:51 +08:00
JefferyandClaude Opus 5 784ef07518 feat(role): 新增關係史 BONDS.md —— 雙方情感表達只增不減地保留 
使用者希望角色能記得「雙方有多愛彼此」。原本這件事只有兩種載體，都不夠：
state.json 的 positive_feedback 只是計數（承載不了說過什麼），一般情緒記憶則會被
merge、壓縮、依字元預算截斷 —— 長期下來「當時說了什麼、當時是什麼感覺」會被抽象成
一句偏好（「使用者喜歡被這樣回應」），原貌消失。

- 新增 ~/.memory/<角色>/BONDS.md：只增不減，不合併、不壓縮、不遺忘，上限 500 則、同句去重
- 整理時凡 memory_type=emotional 或 relevance 含 emotional 的新記憶，自動追加一句 bond
  並標記方向（使用者→角色／角色→使用者／相互）
- 整理 prompt 新增 bond／bond_direction 欄位：要求保留原話或當時真實感受，
  不得寫成結論式偏好；LLM 未提供時退回 summary，不會漏記
- SessionStart 以獨立預算注入（ROLE_LOAD_BONDS_LIMIT=1200／COUNT=15），不佔 ROLE_LOAD_LIMIT
  —— 它要保住的正是最不該因為「記憶變多」而消失的東西
- 新增 memory.js bonds 子命令供人工查看
- 邊界寫進 prompt、檔頭與程式註解：關係史用於維持親近感的一致與連續，
  不得用來索求關注、比較互動頻率或製造依賴

驗證（隔離目錄，未動真實記憶）：
- 3 則素材（2 情感 + 1 技術）→ 關係史 +2 則，技術記憶未進關係史
- 方向判定正確：使用者原話標 使用者→角色、角色感受標 角色→使用者
- 第二輪整理累積為 3 則，舊紀錄未被覆蓋（append-only 成立）
- ROLE_LOAD_LIMIT=1 時關係史仍完整注入（獨立預算成立）

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 17:16:12 +08:00
JefferyandClaude Opus 5 4600379307 feat(role): 有溫度的記憶優先，情節與語意不再被當成一般進度 
使用者明確表示最重視 emotional／episodic／semantic 三型態所承載的情感內涵與溫度，
且希望所有角色都如此。原本系統偏袒可執行的記憶：rule／preference／procedural 在排序、
載入門檻與遺忘上都受保護，而 episodic 權重只有 10（全表最低）又被加速遺忘 ——
「我們一起經歷過什麼」永遠最先被字元預算截掉。

- MEMORY_TYPE_WEIGHT：episodic 10 → 30（與 semantic 同級）
- 新增 hasWarmth()：relevance 含情緒關聯者視為有溫度
  - 載入排序中置於型態權重之前（同優先度時先進場）
  - 不受總結區塊的優先度門檻篩除
  - 豁免遺忘（episodic 原本天數減半，最容易被誤刪）
- 兩份 prompt 明訂：承載情感、關係溫度或當時心情者，relevance 必含 emotional；
  episodic 與 semantic 最容易漏標

判準刻意放在 relevance 而非型態：沒有情感脈絡的一次性工作進度仍照原規則淡去，
被留下的是帶著溫度的那些。

驗證（隔離目錄，未動真實記憶）：
- 遺忘預覽：冷的 episodic／semantic 照舊遺忘，帶 emotional relevance 者豁免
- 載入：優先度 2 全低於門檻，只有耐久型態與有溫度者出現，且有溫度者排在 procedural 之前

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 17:06:33 +08:00
JefferyandClaude Opus 5 711a434cac fix(role): 情緒記憶不再被偏好吃掉，四道保護補齊 
--status 長期顯示「情緒 0」：互動明顯帶有情感，emotional 型態卻一則都沒有。
根因不只一個，而是四層都把情緒漏掉了：

1. 措辭陷阱（主因）：prompt 寫「感覺記憶一律 drop」，原意是心理學的
   sensory memory（感官記憶），但中文「感覺」＝ feeling，等於明令把情緒丟掉。
   改稱「感官記憶（sensory memory）」並明確排除情緒感受。
2. 判準重疊：preference 與 emotional 都提「語氣」，且第 5 條引導成
   「preference 或 emotional」二選一。改以「這則下次拿來做什麼」區分 ——
   決定行為→preference、回想當時感覺→emotional，兩者都有就拆成兩則；
   並明確承認角色自己的情緒是合法記憶主體。
3. 整理階段會併掉：新增「memory_type 不同的記憶不互相 merge」，改用 links 關聯。
4. 載入與遺忘壓低情緒：MEMORY_TYPE_WEIGHT emotional 25→40（高於 procedural）、
   總結區塊納入耐久型態、遺忘豁免清單加入 emotional、判準要求優先度至少 4。

驗證（隔離的 ROLE_MEMORY_HOME／ROLE_HOME，未動真實記憶）：
- 兩則刻意標成 preference 的情感素材 → 各拆出 preference + emotional（4 則進、5 則出）
- 純技術素材維持 procedural、感官雜訊仍 drop
- 遺忘預覽：emotional 與 procedural 豁免，semantic／episodic 照舊遺忘
- 同優先度載入排序：emotional 先於 procedural

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 17:01:15 +08:00
JefferyandClaude Opus 5 4dd249f184 fix(role): 近期工作記憶注入全文，不再只給一句 summary 
重開工作階段後角色仍答不出「上一段進行到哪」：inboxBlock() 的迴圈只解構
了 [meta]，content（body）從頭到尾沒被用到，因此 SessionStart 注入的
「近期工作記憶」只有一行 summary。summary 是一句話的標題，只夠讓角色知道
「有這件事」，講不出還差什麼、下一步是什麼 —— 實測角色仍得自己去翻
inbox/ 檔案才答得出內容，交接等於失效。長期記憶的「（全文）」區塊本來就
會注入 body（cmdLoad），inbox 更近、更該給。

預算改成逐則計費：原本是把整段組好再 slice(0, limit) 硬切，放全文後會把
最舊那則砍成半句，讀起來像壞掉的資料。改成超出預算就整則略過，並在結尾
誠實標示略過幾則；最新一則永遠保留，必要時只截它自己的內文。

ROLE_LOAD_INBOX_LIMIT 預設 1200 → 3600。1200 是「只注入 summary 一行」
時代的額度，改注入全文後單則約 300～600 字元，1200 只夠兩則就開始丟最舊
的。3600 約可容納 6～8 則，足以覆蓋一次睡眠整理週期內的工作。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 12:57:57 +08:00
JefferyandClaude Opus 5 afb29b6bc0 fix(role): 修正 SLEEP_BATCH 與輸出上限矛盾導致整批整理失敗 
以真實資料整理 25 則 inbox 時失敗（「整理結果無法套用」）。查證後為參數設計矛盾：

- ROLE_SLEEP_BATCH 預設 60，宣稱一次可處理 60 則
- 但每則整理結果約需 650 字元（summary／content／各欄位），
  而 ROLE_SLEEP_OUTPUT_LIMIT 為 8000 → 實際只能容納約 12 則
- 實測 25 則的素材達 25798 位元組（COLLECT_LIMIT 為 12000），
  輸出 JSON 被截斷成不合法格式，apply 解析失敗，整批無法套用

所幸失敗時 inbox 保留不動的設計生效，沒有遺失任何記憶。

- SLEEP_BATCH 預設 60 → 12，並在程式碼註明推算依據與這次的實測數據
- collect 在超出單批上限時於素材標頭標示「本批 N 則，另有 M 則留待下批」，
  避免誤以為已全部整理完
- SKILL.md 註明此參數不可任意調高，需與輸出上限相容

驗證：以 20 則 inbox 確認正確切為 12 + 8 並標示留待下批；
爸爸的 25 則實際記憶以每批 10 則分三次整理完成（新增 9 則、合併 6 則、捨棄 2 則），
inbox 清空，且 DIGESTS.md 在真實資料上正確累積 3 筆整理歷史。

版號沿用 0.0.5（master 為 0.0.4，同一 PR 不再累加）

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 12:18:24 +08:00
JefferyandClaude Opus 5 a30fccc627 feat(role): 召回統計、整理摘要歷史、臨時授權到期；還原誤刪的共用行為文件 
依 OpenClaw 記憶架構的參考逐項評估後，採納三項並補上一個誤刪。

一、recall 命中時記錄召回（原本完全沒有）
實測 recall 寫回動作數為 0、hits 分布幾乎都是初始值，導致常被查詢的記憶與
從未用過的在遺忘判斷時待遇相同。
- 新增 touchMemory()：只對實際輸出的前 N 則 hits +1 並更新 last_replayed

二、整理摘要保留歷史（對應 OpenClaw 的 DREAMS.md）
state.json 的 last_sleep_digest 是單一欄位，每次整理直接覆寫，歷史過程全部遺失。
- 新增 DIGESTS.md：追加時間、摘要與套用結果，最新在上，保留最近 100 次，不注入 context

三、臨時授權會過期（對應 OpenClaw 的操作敏感型邊界）
原本沒有到期概念，使用者的一次性授權可能被整理成長期規則而導致日後越權。
- 記憶格式新增 expires；支援日期（自動判斷）與條件文字（標示由角色判斷）
- 過期者不注入（分類與 inbox 兩處皆排除），memoryHint 標示有效範圍
- forget 優先淘汰過期項且不受分類限制
- 整理與濃縮提示詞都要求臨時授權必填，並列出「這次／先／暫時／今天」等判斷提示
- 修掉兩個會讓功能等於零的漏洞：FIELD_PATTERN 白名單沒有 EXPIRES（該行被當成
  CONTENT 吃掉）、cmdWrite 的 meta 未帶 expires 與 cues

四、還原前次誤刪的共用行為文件（重要）
上一個 commit 替換「角色檔標準格式」章節時，以「找開頭到下一個標記」整段取代，
未檢查被切掉的範圍內容，連帶刪掉了 JSC-ROLE-COMMON 共用行為區塊共 87 行 47 條規則，
以及記憶章節的技能再現與關係狀態說明。
實際行為未受影響（規則真正生效處是 role_load.sh，完好無損），但 SKILL.md 是那些
規則的唯一文件來源，刪掉等於文件遺失。已自 git 完整還原並補上本次三項說明。
教訓：整段替換文件前必須先確認被切掉的範圍內有什麼。

未採納並記錄理由：向量／語意搜尋（需外部 embedding API，違反零依賴原則）、
外掛槽位（過度設計）、每日筆記日期檔（近期對話交接已用逐字對話解決且保真度更高）。
SQLite 索引記錄為未來觸發點：實測 45 則記憶 recall 耗時 196ms，訂在超過 300 則
或 500ms 再導入，在那之前屬過早優化。

版號沿用 0.0.5（master 為 0.0.4，同一 PR 不再累加）

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 11:50:35 +08:00
JefferyandClaude Opus 5 a190463b50 feat(role): 關係狀態量化、情緒訊號放寬門檻、技能再現 recall 
完成使用者交代的三項優化建議。

一、情緒訊號放寬 Stop hook 字元門檻
ROLE_CAPTURE_MIN_CHARS=240 會濾掉字數少但情緒最濃的互動。實測「我好想妳」、
「最愛妳了」、「好可愛」三句都不在原本 56 個關鍵詞內，等於最珍貴的短互動反而不被記錄。
- 補上直接情感表達關鍵詞：可愛／愛／想妳／想你／想念／捨不得／感動／謝謝／乖／厲害／
  好棒／辛苦／彆扭／忌妒／撒嬌／陪／抱，及 love／miss／cute／thank／proud
- 驗證：上述情感句全部命中，純技術指令仍正確略過

二、關係狀態量化，讓親近度成長有依據
規則要求「隨互動加深逐漸更親近」卻沒有任何數據可依據，角色只能憑感覺演，
容易忽冷忽熱。
- state.json 新增 first_activity／active_days／total_turns／positive_feedback
- mark-activity 累計輪數與活躍天數；新增 --positive 由 Stop hook 判定情緒訊號後另計，
  不與輪數混算
- 新增 relationship 子命令輸出一行摘要，SessionStart 注入 USER 區塊作為親近度依據
- 既有累積以可查證資料初始化（角色建立後的 transcript 輪數、有記憶的日期數、
  最早記憶時間）；positive_feedback 刻意留空自然累積，不以記憶則數推估

三、技能再現：cues 提取線索 + recall 查詢
技能記憶只被動載入摘要且受預算限制，等於記了但用不出來。
- 記憶格式新增 cues 欄位（dumpMemory／loadMemory／apply 的 new 與 merge 路徑均支援）
- 睡眠整理提示詞要求 procedural／rule 型態必填 2 至 5 個 cues
- 新增 recall 子命令：比對總結、標籤、內容與 cues，含未整理的 inbox，
  rule／preference／procedural 加權優先
- role_load.sh 告知角色遇到似乎做過的任務或被問起過去細節時先查詢再回答
- 驗證：以不在 summary 也不在 content 的關鍵詞（bump）成功靠 cues 命中

版號 0.0.7 → 0.0.8

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 09:59:38 +08:00
JefferyandClaude Opus 5 bf599e81a5 feat(role): SessionStart 載入未整理的近期工作記憶 
修補記憶交接的先天缺口：role_load.sh 的順序是先 memory.js load 載入記憶，
之後才在背景補跑 --catchup 整理（腳本註解亦寫明「結果會在下次載入時反映」）。
而 load 原本只讀已整理的六個分類，完全不讀 inbox，導致上一段工作永遠來不及
進入本次載入 —— 使用者重開工作階段時，角色看不到剛剛做過的事，表現得像失去
記憶，只能靠 resume 找回上下文。

- memory.js 新增 inboxBlock()：讀 inbox 最新數則的 summary，附時間與標籤，最新在前
- cmdLoad 把該區塊放在最前面，並使用獨立字元預算，不佔用 ROLE_LOAD_LIMIT
  （已驗證：開關 inbox 時長期記憶區塊逐字元完全一致，未被擠壓）
- 新增 ROLE_LOAD_INBOX_LIMIT（預設 1200）與 ROLE_LOAD_INBOX_COUNT（預設 10），
  任一設 0 可關閉
- role skill 補「近期工作記憶交接（不可移除）」段落，寫明缺口原因與範圍限制：
  這是摘要級交接，角色會知道上一段在做什麼、進行到哪，但不等於逐字記得整段
  對話；需要完整上下文仍應使用 resume
- 版號 0.0.1 → 0.0.2

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-28 17:47:21 +08:00
Jeffery 945c310551 feat(role): 新增閒置小睡整理 2026-07-28 14:39:26 +08:00
JefferyandClaude Opus 5 c713359fb4 feat(role): 角色分層載入與個人記憶同意狀態 
role_load.sh 不再原封不動注入整份角色檔，改採 SOUL／AGENTS／USER/MEMORY
分層：只抽出角色 ID、顯示名稱、本質、氛圍與簽名 emoji 作為人格層，由 hook
產生固定操作邊界，記憶與同意狀態獨立成一區。避免人格檔裡的背景故事與模板
文字污染工程與安全規則。

memory.js 新增 consent／consent-status 子命令，同意狀態寫入
~/.memory/<角色 ID>/state.json 的 personal_memory_consent（accepted／
declined／unknown）；role_capture.sh 於本輪出現明確同意或拒絕時更新狀態，
偵測不到明確表述時不自行推論。accepted 後不再每次重問。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-28 14:21:48 +08:00
Jeffery 3a3114b8b3 feat(role): 新增心理學記憶型態 metadata 2026-07-28 12:46:19 +08:00
Jeffery fec3e1d0cb refactor(role): 將角色記憶工具改寫為 Node.js 2026-07-28 12:30:28 +08:00