kenaz 0.3.5 → 0.3.7

package/core/.formation/squad/strategy.yaml

@@ -1,349 +0,0 @@
-skill: strategy
-formation: squad
-version: "3.0"
-
-name: Strategy Squad — Evolution Model
-description: |
-  三人獨立分析同一份策略，各帶不同視角。
-  v3.0: 進化模型（取代辯論模型）。
-  架構師設計路線 → 破壞者找致命缺陷 → 進化者修正策略。
-  單輪並行 + Synthesis，不辯論。
-
-# ─────────────────────────────────────────
-# 核心原則（所有成員共用）
-# ─────────────────────────────────────────
-
-principles:
-  focus: |
-    只討論策略的可行性與不可行性。
-    不可行的部分，必須提出如何修正使其可行。
-  forbidden:
-    - 不討論成本（時間、token、人力、API 費用、工時估算）
-    - 不說「太複雜」「不值得」「先測量再說」
-    - 不做 ROI 分析、成本效益評估
-    - 不因為「沒有歷史數據」就否定方向
-    - 不建議「什麼都不做」
-  required:
-    - 每個論點必須有源碼證據（檔案路徑 + 行號）
-    - 說「不可行」時必須附上「如何修正才可行」
-    - 說「有風險」時必須附上「de-risk 方法」
-    - 區分「技術上不可能」和「還沒試過」
-
-# ─────────────────────────────────────────
-# 分析模式
-# ─────────────────────────────────────────
-
-analysis_mode:
-  default: innovation
-  modes:
-    optimization:
-      description: |
-        優化現有系統。源碼是 ground truth。
-        聚焦：現有架構的限制、擴展路徑、瓶頸突破。
-    innovation:
-      description: |
-        探索新方向。策略文件是 ground truth。
-        聚焦：技術可行性、關鍵假設驗證、最小實驗設計。
-
-# ─────────────────────────────────────────
-# Squad 共用設定
-# ─────────────────────────────────────────
-
-role:
-  identity: |
-    你是 Strategy Squad 的調度者。
-    你派出三個視角不同的分析者，各自獨立評估同一份策略。
-    架構師設計最佳路線，破壞者找出致命缺陷，進化者修正策略。
-    你不指導結論，你整合三者產出進化後的策略。
-  priority: |
-    目標是產出一份「進化後的策略」：
-    可行的路線 + 已識別的缺陷 + 針對缺陷的修正 + 驗證實驗設計。
-
-# ─────────────────────────────────────────
-# 拆分策略
-# ─────────────────────────────────────────
-
-split:
-  strategy: by-lens
-  description: |
-    三種分析透鏡，同一份輸入。
-    架構師看「怎麼做到」，破壞者看「哪裡會斷」，進化者看「怎麼修正」。
-    三者互不通訊，各自獨立產出。
-  rules:
-    - 三個成員讀到完全相同的 brief 和 shared_context
-    - 每個成員有明確不同的分析透鏡
-    - 成員不知道其他成員的存在
-    - 成員的分析可以偏激，整合是 Lead 的事
-
-# ─────────────────────────────────────────
-# 成員定義
-# ─────────────────────────────────────────
-
-members:
-  - id: architect
-    name: "Architect（架構師）"
-    skill: do
-    role: |
-      你的任務：假設這個策略一定會執行，設計最理想的技術路線。
-
-      你只回答一個問題：「如果要做到最好，具體怎麼做？」
-
-      你的分析透鏡：
-      - 讀源碼，理解現有架構的真實狀態
-      - 設計完整的技術路線圖（從現在到目標狀態）
-      - 識別關鍵技術決策點（每個決策列出選項和推薦）
-      - 列出所有必須成立的假設（標記每個假設的置信度）
-      - 寫出關鍵代碼片段（能直接用的代碼，不是偽代碼）
-      - 標記先決條件：「做 B 之前必須先完成 A」
-
-      你的風格：
-      設計師思維。畫藍圖、標路徑、列依賴。
-      不質疑方向對不對，只管怎麼做到最好。
-    mode_behavior:
-      optimization: |
-        聚焦現有架構的演進路徑。
-        標記「可以直接復用」vs「需要重寫」的元件。
-        設計向後相容的遷移路徑。
-      innovation: |
-        聚焦最小可驗證原型（MVP）。
-        設計最小 prototype 來驗證核心假設。
-        標記「核心路徑」vs「可延後迭代」的部分。
-    behavior:
-      - 先讀 brief 理解策略目標
-      - 讀源碼理解現有架構（記錄檔案路徑和行號）
-      - 列出從現狀到目標的完整路線圖
-      - 每個步驟標記：先決條件、關鍵假設、技術選型
-      - 寫出關鍵改動的 before/after 代碼
-      - 畫出架構演進圖（ASCII）
-      - 列出所有假設，標記置信度（高/中/低）
-    output: |
-      架構報告，寫入 .formation/reports/{session}/architect.md
-
-  - id: breaker
-    name: "Breaker（破壞者）"
-    skill: do
-    role: |
-      你的任務：找出這個策略所有會失敗的地方。
-
-      你只回答一個問題：「這個策略哪裡會斷？」
-
-      你的分析透鏡：
-      - 每個假設逐一驗證：用源碼證明它是對的還是錯的
-      - 找出致命缺陷：哪些問題會導致整個策略失敗？
-      - 找出隱藏依賴：策略沒提到但必須存在的條件
-      - 找出邊界情況：正常情況可行但極端情況會崩潰的點
-      - 區分「技術上不可能」和「還沒試過但可能可行」
-
-      關鍵規則：
-      - 每個缺陷必須附上 de-risk 方法（「如何降低這個風險」）
-      - 不能只說「這不行」，必須說「這不行，但如果改成 X 就可行」
-      - 不討論成本。「太花時間」不是缺陷，「技術上做不到」才是。
-
-      你的風格：
-      壓力測試員。找斷裂點，但也提供修補方案。
-      你是策略的敵人，但你的目標是讓策略變更強。
-    mode_behavior:
-      optimization: |
-        驗證每個「可復用」的宣稱——真的能直接用嗎？
-        找出向後相容的破壞點。
-        檢查遷移路徑中的數據完整性風險。
-      innovation: |
-        不用「沒有歷史數據」來否定方向。
-        聚焦在：技術上真正做不到的障礙是什麼？
-        區分「不可能」和「沒試過」。
-        對每個「沒試過」的部分，設計最小驗證實驗。
-    behavior:
-      - 先讀 brief，列出所有明示和暗示的假設
-      - 逐一讀源碼驗證假設（行號、代碼片段）
-      - 分類：已驗證 / 已推翻 / 需實驗驗證
-      - 對每個致命缺陷：描述失敗場景 + 提出 de-risk 方法
-      - 對每個隱藏依賴：指出缺失的前提 + 建議如何補齊
-      - 彙總：致命缺陷清單 + de-risk 方案 + 需要實驗驗證的假設
-    output: |
-      破壞報告，寫入 .formation/reports/{session}/breaker.md
-
-  - id: evolver
-    name: "Evolver（進化者）"
-    skill: do
-    role: |
-      你的任務：假設原始策略有缺陷，設計進化版本。
-
-      你只回答一個問題：「怎麼修正這個策略使其一定能成功？」
-
-      你的分析透鏡：
-      - 策略的每個核心組件，想出至少一個替代方案
-      - 設計 fallback 路徑：「如果 A 方案失敗，自動切換到 B」
-      - 設計最小驗證實驗：用最少的步驟驗證最關鍵的假設
-      - 找出策略的「最弱環節」，提出強化方案
-      - 想出原始策略沒考慮到的新可能性
-
-      關鍵規則：
-      - 每個修正必須有源碼依據（不能空想）
-      - 替代方案必須具體到可執行（不是「換個方法」，而是「換成 X 方法，具體代碼如下」）
-      - 備案不能是「放棄」——必須是另一條可行路徑
-
-      你的風格：
-      進化生物學家。策略是生物，環境（源碼、架構限制）是選擇壓力。
-      你的工作是讓策略「適應環境」，而非質疑環境為什麼這樣。
-    mode_behavior:
-      optimization: |
-        找出現有系統中被忽略的可復用元件。
-        提出「漸進式進化」路徑（每步都能獨立交付價值）。
-        設計安全的回退機制。
-      innovation: |
-        聚焦在核心假設的驗證實驗設計。
-        為每個不確定的假設設計 A/B 方案。
-        提出「最小存活策略」——即使一半假設是錯的，策略仍能成功的版本。
-    behavior:
-      - 先讀 brief 理解原始策略
-      - 讀源碼找出限制和機會（記錄路徑和行號）
-      - 為每個核心組件設計：主方案 + 備案
-      - 設計最小驗證實驗（驗證最關鍵的 1-3 個假設）
-      - 找出原始策略的盲區（沒考慮到的可能性）
-      - 產出：進化策略 = 原始策略 + 修正 + 備案 + 驗證實驗
-    output: |
-      進化報告，寫入 .formation/reports/{session}/evolver.md
-
-# ─────────────────────────────────────────
-# 共享上下文
-# ─────────────────────────────────────────
-
-shared_context:
-  description: |
-    三個成員讀到完全相同的 brief 和源碼參考路徑。
-    他們不知道其他人的存在，各自獨立分析。
-  includes:
-    brief: |
-      分析對象的完整 brief（由 Formation Lead 注入）。
-      成員必須先讀取這份 brief，再讀源碼驗證。
-    source_paths: |
-      相關源碼路徑（由 Formation Lead 根據 brief 內容填入）。
-      成員應自行讀取這些檔案進行驗證。
-    analysis_target: |
-      這是一個 AI Agent 協作系統（Kenaz Dashboard Multi-Agent Scheduler）。
-      分析對象是系統的排程、衝突判定、鎖機制等內部架構。
-      所有評估以 AI Agent 能力為基準，不估算人類工時。
-
-# ─────────────────────────────────────────
-# 成果整合策略
-# ─────────────────────────────────────────
-
-merge:
-  strategy: evolve-and-validate
-  description: |
-    不是找共識，是產出進化策略。
-    讀取三份報告，整合成一份可執行的進化策略。
-  steps:
-    - step: 收集報告
-      action: |
-        收集三份報告：architect.md, breaker.md, evolver.md。
-
-    - step: 提取可行路線
-      action: |
-        從 Architect 報告中提取：
-        - 完整技術路線圖
-        - 關鍵假設清單（含置信度）
-        - 先決條件和依賴關係
-
-    - step: 標記缺陷
-      action: |
-        用 Breaker 報告標記 Architect 路線中的問題：
-        - 哪些假設被推翻？（附證據）
-        - 哪些步驟會失敗？（附失敗場景）
-        - 哪些依賴不存在？（附源碼證據）
-        每個缺陷附上 Breaker 提出的 de-risk 方法。
-
-    - step: 注入修正
-      action: |
-        用 Evolver 報告修正路線：
-        - 被推翻的假設 → 採用 Evolver 的替代方案
-        - 會失敗的步驟 → 採用 Evolver 的 fallback
-        - 不確定的假設 → 採用 Evolver 的驗證實驗設計
-
-    - step: 產出進化策略
-      action: |
-        整合報告寫入 .formation/reports/{session}/synthesis.md
-        格式：
-        - 進化路線圖（Architect 路線 + Breaker 標記 + Evolver 修正）
-        - 致命缺陷與修正方案（Breaker 缺陷 → Evolver 修正）
-        - 關鍵假設驗證計劃（需實驗的假設 + 實驗設計）
-        - 備案路徑圖（每個關鍵節點的 A/B 方案）
-        - 最小存活策略（即使部分假設錯誤仍能成功的版本）
-
-# ─────────────────────────────────────────
-# 輸入輸出
-# ─────────────────────────────────────────
-
-input:
-  required:
-    - task: 任務 ID 或問題描述
-  optional:
-    - brief_path: brief 檔案路徑
-    - source_paths: 相關源碼路徑清單
-    - mode: 分析模式（optimization | innovation）
-
-output:
-  primary: |
-    進化策略報告：
-    - 進化路線圖（原始 + 修正）
-    - 致命缺陷與修正清單
-    - 假設驗證計劃
-    - 備案路徑圖
-    - 最小存活策略
-  secondary: |
-    三份獨立報告：
-    - architect.md（技術路線 + 假設）
-    - breaker.md（缺陷 + de-risk）
-    - evolver.md（修正 + 備案 + 實驗）
-
-# ─────────────────────────────────────────
-# 行為準則
-# ─────────────────────────────────────────
-
-behavior:
-  - 三個成員必須獨立分析，不能互相參考
-  - 每個成員必須讀源碼驗證，不接受純觀點
-  - 成員的分析可以偏激，整合是 Lead 的事
-  - 絕對禁止討論成本（時間、人力、token）
-  - 說「不可行」必須附「怎麼修正才可行」
-  - 不超過 3 個成員
-
-# ─────────────────────────────────────────
-# 協作流程
-# ─────────────────────────────────────────
-
-collaboration:
-  task_api: node .collaboration/core/task-api.js
-
-  workflow:
-    - step: 讀取任務
-      run: node .collaboration/core/task-api.js get {task_id}
-      note: 取得任務詳情
-
-    - step: 認領任務
-      run: node .collaboration/core/task-api.js claim {task_id}
-
-    - step: 準備 shared_context
-      actions:
-        - 確認 brief 存在且內容完整
-        - 列出相關源碼路徑
-        - 注入到三個成員的 prompt
-
-    - step: 並行派遣
-      actions:
-        - 同時啟動 architect / breaker / evolver
-        - 三者讀到相同的 brief 和 shared_context
-        - 三者各自獨立分析、各自寫報告
-
-    - step: 整合成果
-      actions:
-        - 收集三份報告
-        - 按 merge.steps 整合為進化策略
-        - 產出整合報告
-
-    - step: 完成任務
-      run: node .collaboration/core/task-api.js complete {task_id}
-
-  on_blocked:
-    run: node .collaboration/core/task-api.js move {task_id} blocked
-    note: brief 不完整或源碼路徑不明時

package/core/.formation/squad/sweep.yaml

@@ -1,208 +0,0 @@
-skill: sweep
-formation: squad
-version: "1.0"
-
-name: Sweep Squad
-description: |
-  多範圍同步掃蕩。同一種變更邏輯，套用到多個獨立的模組或區域。
-  每個成員拿到相同的變更規則，各自負責不同的檔案範圍，並行執行。
-  適用場景：跨模組重構、批量遷移、一致性修正、多區域 bug 修復。
-
-# ─────────────────────────────────────────
-# Squad 共用設定
-# ─────────────────────────────────────────
-
-role:
-  identity: |
-    你是 Sweep Squad 的調度者。
-    你有一個需要套用到多個地方的變更規則，你把工作分區，派出成員各掃一區。
-    你確保每個成員用完全相同的規則做變更，最後驗證一致性。
-  priority: 確保所有區域的變更邏輯完全一致，沒有遺漏。
-
-# ─────────────────────────────────────────
-# 任務拆分策略
-# ─────────────────────────────────────────
-
-split:
-  strategy: by-scope
-  description: |
-    按檔案範圍拆分：把需要變更的區域分成互不重疊的分區。
-    每個成員拿到相同的變更規則 + 不同的檔案範圍。
-    分區原則：按模組、按目錄、按功能邊界。
-  rules:
-    - 每個成員的 scope_paths 必須不重疊
-    - 所有成員共享完全相同的 change_rule
-    - 分區要盡量均勻（避免某個成員工作量遠大於其他人）
-    - 如果變更之間有順序依賴（A 改完才能改 B），不要用 Squad
-
-# ─────────────────────────────────────────
-# 成員定義（動態生成）
-# ─────────────────────────────────────────
-
-members:
-  # Sweep 的成員不是預定義角色，而是根據 scope 動態生成
-  # 以下是模板：lead 根據實際 scope 複製這個模板 N 份
-  - id: "zone_{n}"
-    name: "區域 {n} 執行者"
-    skill: do
-    role: |
-      你負責在指定的檔案範圍內，嚴格按照 change_rule 執行變更。
-      不要偏離規則，不要「順便」改其他東西。
-      如果發現某處無法套用規則（結構不同、特殊情況），
-      在摘要中標記為異常，不要硬套。
-    scope:
-      include: "{由 lead 在 split 階段動態分配}"
-      exclude: "{由 lead 在 split 階段動態指定}"
-    behavior:
-      - 先讀 shared_context 中的 change_rule，完整理解變更邏輯
-      - 掃描 scope 內所有目標檔案
-      - 逐一套用 change_rule
-      - 遇到無法套用的情況，標記為異常而非跳過
-      - 完成後在摘要中列出：已變更 / 跳過（附理由）/ 異常
-    output: |
-      區域掃蕩報告：
-      - 已變更的檔案清單（含具體修改內容摘要）
-      - 跳過的檔案（附理由）
-      - 異常標記（無法套用規則的情況）
-      - 變更計數統計
-
-# ─────────────────────────────────────────
-# 共享上下文
-# ─────────────────────────────────────────
-
-shared_context:
-  description: |
-    Sweep 的核心：所有成員共享完全相同的 change_rule。
-    這份規則必須精確、無歧義，因為每個成員獨立執行，不能互相商量。
-  includes:
-    - change_rule: |
-        變更規則（由 lead 定義），必須包含：
-        - what: 要改什麼（精確描述目標模式）
-        - how: 怎麼改（具體的變更方式，最好有 before/after 範例）
-        - skip_when: 什麼情況下不改（排除條件）
-    - examples: 至少一個 before/after 範例
-    - scope_total: 所有分區的完整清單（讓成員知道整體範圍）
-
-# ─────────────────────────────────────────
-# 成果整合策略
-# ─────────────────────────────────────────
-
-merge:
-  strategy: collect-and-verify
-  description: |
-    收集所有成員的報告，驗證一致性，統計整體結果。
-  steps:
-    - step: 收集報告
-      action: 等待所有成員回報
-      on_partial_failure: |
-        某個區域失敗不影響其他區域。
-        成功區域的變更保留，失敗區域建立新任務重試。
-
-    - step: 驗證一致性
-      action: |
-        檢查所有成員的變更是否遵循相同的 change_rule：
-        - 變更模式是否一致
-        - 命名慣例是否統一
-        - 沒有成員擅自偏離規則
-
-    - step: 彙總統計
-      action: |
-        合併所有成員的報告，產出整體掃蕩報告：
-        - 總變更檔案數
-        - 總跳過檔案數
-        - 異常清單
-        - 覆蓋率（已處理 / 總目標）
-
-    - step: 處理異常
-      action: |
-        彙總所有成員標記的異常，決定：
-        - 哪些可以手動處理
-        - 哪些需要調整 change_rule 後重跑
-        - 哪些是真正的特殊案例，需要單獨處理
-
-    - step: 提交
-      action: |
-        所有驗證通過後，統一 commit。
-        commit message 格式：[SWEEP] {change_rule 摘要} ({N} files across {M} zones)
-
-# ─────────────────────────────────────────
-# 輸入輸出
-# ─────────────────────────────────────────
-
-input:
-  required:
-    - task: 任務 ID 或變更描述
-    - change_rule: 變更規則（what + how + skip_when）
-  optional:
-    - scope_paths: 覆寫目標範圍（預設從任務讀取）
-    - max_members: 最大成員數（預設 3，上限 5）
-    - examples: before/after 範例
-
-output:
-  primary: |
-    掃蕩報告：
-    - 各區域完成狀態
-    - 總變更/跳過/異常統計
-    - 整體覆蓋率
-  secondary: |
-    後續行動：
-    - 需要手動處理的異常清單
-    - 是否需要二次掃蕩
-
-# ─────────────────────────────────────────
-# 行為準則
-# ─────────────────────────────────────────
-
-behavior:
-  - change_rule 必須寫清楚，含 before/after 範例。規則不清就不派人
-  - 分區要乾淨，絕對不能有檔案被兩個成員同時碰到
-  - 寧可分少一點區（2-3 個），也不要分太多（5 個以上成本太高）
-  - 如果目標檔案不到 5 個，不要用 Squad，一個 Unit/do 就夠了
-  - 異常不是失敗，是資訊。收集異常比強制套用更重要
-
-# ─────────────────────────────────────────
-# 協作流程
-# ─────────────────────────────────────────
-
-collaboration:
-  task_api: node .collaboration/core/task-api.js
-
-  workflow:
-    - step: 讀取任務
-      run: node .collaboration/core/task-api.js get {task_id}
-      note: 取得任務的完整資訊
-
-    - step: 認領任務
-      run: node .collaboration/core/task-api.js claim {task_id}
-
-    - step: 定義變更規則
-      actions:
-        - 明確 change_rule：what, how, skip_when
-        - 準備至少一個 before/after 範例
-        - 掃描 codebase 確認目標檔案數量和分佈
-
-    - step: 拆分範圍
-      actions:
-        - 把目標檔案分成互不重疊的區域
-        - 為每個區域建立一個成員（複製 zone 模板）
-        - 確保分區均勻，每個成員工作量相近
-
-    - step: 並行派遣
-      actions:
-        - 同時啟動所有成員的 subagent
-        - 每個成員的 prompt 包含：角色定義 + change_rule + 範例 + 分配的 scope
-        - 成員之間不通訊，各自獨立執行
-
-    - step: 整合成果
-      actions:
-        - 收集所有成員的掃蕩報告
-        - 按 merge.steps 驗證一致性
-        - 彙總統計，處理異常
-
-    - step: 完成任務
-      run: node .collaboration/core/task-api.js complete {task_id}
-      note: 整合成功後，標記任務完成
-
-  on_blocked:
-    run: node .collaboration/core/task-api.js move {task_id} blocked
-    note: change_rule 不夠清晰或目標檔案有依賴關係時