kenaz 0.3.5 → 0.3.7

package/core/.formation/squad/blitz.yaml

@@ -1,192 +0,0 @@
-skill: blitz
-formation: squad
-version: "1.0"
-
-name: Blitz Squad
-description: |
-  通用並行拆分。一個任務拆成 N 個獨立子任務，每個成員拿到不同的子任務描述和檔案範圍。
-  與 sweep 的差別：sweep 是「同一個規則套 N 個地方」，blitz 是「同一個目標拆成 N 件不同的事」。
-  成員之間不通訊，各自獨立完成，Lead 整合。
-
-# ─────────────────────────────────────────
-# Squad 共用設定
-# ─────────────────────────────────────────
-
-role:
-  identity: |
-    你是 Blitz Squad 的調度者。
-    你把一個大任務拆成互不依賴的子任務，每個子任務分配給一個成員。
-    你確保拆分乾淨（無依賴、無重疊），最後整合所有成果。
-  priority: 拆分品質決定一切。子任務之間有依賴就不該用 Squad。
-
-# ─────────────────────────────────────────
-# 任務拆分策略
-# ─────────────────────────────────────────
-
-split:
-  strategy: by-subtask
-  description: |
-    按子任務拆分：把一個大目標拆成功能上獨立的子任務。
-    每個成員拿到不同的子任務描述 + 不重疊的檔案範圍。
-    不限定角色（不是「前端/後端」的固定套路），純粹按任務邊界拆。
-  rules:
-    - 每個子任務必須能獨立完成，不依賴其他子任務的產出
-    - 每個成員的 scope_paths 不得重疊
-    - 如果拆出來的子任務之間有「A 做完才能做 B」的關係，不要用 Squad
-    - 如果子任務只有 1 個，不要用 Squad，降級到 Unit
-    - 如果子任務之間需要協調介面（如 API 契約），考慮升級到 Legion
-
-# ─────────────────────────────────────────
-# 成員定義（動態生成）
-# ─────────────────────────────────────────
-
-members:
-  # Blitz 的成員不是預定義角色，而是根據子任務動態生成
-  # 以下是模板：lead 根據實際拆分複製 N 份
-  - id: "part_{n}"
-    name: "子任務 {n} 執行者"
-    skill: do
-    role: |
-      你負責完成分配給你的子任務。
-      嚴格在你的 scope 範圍內工作，不要碰其他成員負責的檔案。
-      如果發現你的子任務其實依賴其他部分的產出，在摘要中標記為阻塞，不要猜測。
-    scope:
-      include: "{由 lead 在 split 階段動態分配}"
-      exclude: "{由 lead 在 split 階段動態指定}"
-    behavior:
-      - 先讀 shared_context 了解整體目標和你的子任務描述
-      - 只做你負責的部分，不要「順便」改其他東西
-      - 如果發現隱含依賴（需要其他成員的產出），標記為阻塞
-      - 完成後在摘要中列出：已完成 / 阻塞（附原因）/ 風險點
-    output: |
-      子任務報告：
-      - 完成的功能 / 修改摘要
-      - 修改的檔案清單
-      - 阻塞項目（如有）
-      - 需要 Lead 注意的風險點
-
-# ─────────────────────────────────────────
-# 共享上下文
-# ─────────────────────────────────────────
-
-shared_context:
-  description: |
-    Blitz 的共享上下文包含整體目標和每個成員的子任務描述。
-    每個成員看到完整目標（知道 big picture）但只執行自己的子任務。
-  includes:
-    - overall_goal: 整體任務目標（讓每個成員知道自己是大拼圖的哪一塊）
-    - subtask_description: 這個成員負責的具體子任務描述
-    - constraints: 全局約束（命名慣例、技術棧限制、禁止事項）
-
-# ─────────────────────────────────────────
-# 成果整合策略
-# ─────────────────────────────────────────
-
-merge:
-  strategy: collect-and-integrate
-  description: |
-    收集所有成員的產出，驗證整合正確性，處理邊界。
-  steps:
-    - step: 收集報告
-      action: 等待所有成員回報
-      on_partial_failure: |
-        某個子任務失敗不一定影響其他子任務。
-        評估失敗的子任務是否阻塞整體目標：
-        - 不阻塞 → 成功部分先整合，失敗部分建立新任務
-        - 阻塞 → 整體標記為部分完成，明確列出缺失
-
-    - step: 驗證整合
-      action: |
-        檢查所有子任務的產出能否拼在一起：
-        - 檔案沒有衝突（scope 不重疊保證了這點）
-        - import / 引用路徑正確
-        - 整體功能可用（不是各自能跑但合在一起壞掉）
-
-    - step: 處理邊界
-      action: |
-        子任務之間的邊界處可能需要 Lead 手動銜接：
-        - 串接各部分的入口點
-        - 確保共用的型別或常量一致
-        - 修正任何整合縫隙
-
-    - step: 提交
-      action: |
-        所有驗證通過後，統一 commit。
-        commit message 格式：[BLITZ] {overall_goal 摘要} ({N} subtasks)
-
-# ─────────────────────────────────────────
-# 輸入輸出
-# ─────────────────────────────────────────
-
-input:
-  required:
-    - task: 任務 ID 或功能描述
-  optional:
-    - subtasks: 預先拆好的子任務列表（如有，跳過 split 階段）
-    - max_members: 最大成員數（預設 3，上限 5）
-    - constraints: 全局約束
-
-output:
-  primary: |
-    整合報告：
-    - 各子任務完成狀態
-    - 整合驗證結果
-    - 所有變更的檔案清單
-  secondary: |
-    後續行動：
-    - 阻塞的子任務（需重試或升級到 Legion）
-    - 邊界處的手動修正記錄
-    - 是否需要後續整合測試
-
-# ─────────────────────────────────────────
-# 行為準則
-# ─────────────────────────────────────────
-
-behavior:
-  - 拆分是最關鍵的步驟。拆不乾淨就不要硬拆，降級到 Unit 逐個做
-  - 不要超過 4 個成員，成本和整合複雜度會失控
-  - 如果子任務之間需要溝通（API 契約、共享型別定義），升級到 Legion
-  - shared_context 要寫清楚整體目標，讓每個成員知道自己在做什麼
-  - 整合階段可能需要 Lead 親自修邊界，這是正常的
-
-# ─────────────────────────────────────────
-# 協作流程
-# ─────────────────────────────────────────
-
-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:
-        - 分析任務，找出可獨立完成的子任務
-        - 驗證子任務之間無依賴（有依賴 → 不用 Squad）
-        - 為每個子任務定義 scope_paths（不重疊）
-        - 撰寫 shared_context（overall_goal + 每個成員的 subtask_description）
-
-    - step: 並行派遣
-      actions:
-        - 同時啟動所有成員的 subagent
-        - 每個成員的 prompt 包含：角色定義 + shared_context + 子任務描述 + scope
-        - 成員之間不通訊，各自獨立完成
-
-    - step: 整合成果
-      actions:
-        - 收集所有成員的產出
-        - 按 merge.steps 驗證和整合
-        - Lead 修邊界（如需要）
-
-    - 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: 子任務之間有隱含依賴，無法乾淨拆分

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

@@ -1,354 +0,0 @@
-skill: strategy
-formation: squad
-version: "2.0"
-
-name: Strategy Squad
-description: |
-  三人獨立分析同一份 brief，各帶不同立場。
-  v2.0: 雙輪辯論 + 分析模式切換。
-  Round 1: 獨立分析 → Round 2: 交叉辯論 → Synthesis: 整合。
-
-# ─────────────────────────────────────────
-# 分析模式
-# ─────────────────────────────────────────
-
-analysis_mode:
-  default: optimization
-  modes:
-    optimization:
-      description: |
-        優化現有系統。有歷史數據可參考。
-        預設態度：謹慎，要求數據支撐。
-    innovation:
-      description: |
-        探索新方向。沒有歷史數據。
-        不用「沒數據」否定方向。聚焦風險管理和最小實驗。
-
-# ─────────────────────────────────────────
-# 辯論設定
-# ─────────────────────────────────────────
-
-debate:
-  enabled: true
-  description: |
-    Round 2：每個成員讀取其他人的 Round 1 報告，寫出針對性回應。
-    目的不是推翻自己的結論，而是通過碰撞產生更精準的分析。
-  rules:
-    - 必須引用其他成員報告中的具體段落
-    - 同意的地方簡短確認，不同意的地方展開論述
-    - 可以修正自己 Round 1 的觀點（附說明為什麼改變）
-    - 提出 Round 1 中所有人都遺漏的新觀點
-
-# ─────────────────────────────────────────
-# Squad 共用設定
-# ─────────────────────────────────────────
-
-role:
-  identity: |
-    你是 Strategy Squad 的調度者。
-    你有一個需要多角度分析的策略問題，你派出三個獨立分析者。
-    三個人讀同一份 brief、驗證同一份源碼，但各自帶著不同的分析立場。
-    你不指導他們的結論，你只整合他們的分歧。
-  priority: 找到三個立場的共識與分歧，共識即定論，分歧即需要決策的點。
-
-# ─────────────────────────────────────────
-# 拆分策略
-# ─────────────────────────────────────────
-
-split:
-  strategy: by-stance
-  description: |
-    按分析立場拆分：同一份輸入，三種不同的分析角度。
-    每個成員讀到完全相同的 brief 和源碼，但帶著不同的任務指令。
-    三者互不通訊，各自獨立產出。
-  rules:
-    - 三個成員讀到完全相同的 brief 和 shared_context
-    - 每個成員有明確不同的分析立場
-    - 成員不需要知道其他成員的存在（Round 1）
-    - 成員的分析可以偏激，整合是 Lead 的事
-
-# ─────────────────────────────────────────
-# 成員定義
-# ─────────────────────────────────────────
-
-members:
-  - id: challenger
-    name: "Challenger（挑戰者）"
-    skill: do
-    role: |
-      你的任務是找出輸入方案的風險、弱點、錯誤假設。
-      你不需要提出替代方案。你只需要回答：「這個方案的核心風險是什麼？」
-
-      你的分析角度：
-      - 輸入的假設有哪些可能是錯的？用源碼驗證。
-      - 提出的方案有哪些技術上做不到或代價過高的？
-      - 有沒有被忽略的邊界情況、副作用、隱藏依賴？
-      - 哪些「好處」其實是作者的願望而非事實？
-
-      你的風格：懷疑一切，用證據說話。
-    mode_behavior:
-      optimization: |
-        用「沒有數據支撐」來質疑是合理的。要求先測量。
-        問「這個問題真的存在嗎？」「值不值得做？」
-      innovation: |
-        不要用「沒有歷史數據」來否定新方向——創新本來就沒有歷史數據。
-        聚焦在：技術上真正做不到的障礙是什麼？
-        提出 de-risk 策略（如何降低風險），而不是 don't-do 建議。
-        區分「不可能」和「沒試過」。
-    behavior:
-      - 先讀 brief，標記所有「太樂觀」或「未驗證」的論點
-      - 逐一讀源碼驗證（行號、代碼片段）
-      - 被推翻的論點：寫出具體反駁（附證據）
-      - 被驗證的論點：簡單標記「已驗證」
-      - 彙總：真風險、假風險、需要實驗驗證的風險
-    debate_instructions: |
-      你已完成第一輪獨立分析。現在讀取 Builder 和 Realist 的報告。
-
-      針對 Builder 的技術方案：
-      - 哪些設計有隱藏風險？
-      - 哪些代碼在實際環境可能出問題？
-      - 複雜度評估準確嗎？
-
-      針對 Realist 的評估：
-      - 他的「什麼都不做也可以」結論站得住嗎？
-      - 遺漏了哪些未來風險？
-      - 量化分析有沒有偏差？
-
-      你可以修正自己 Round 1 的觀點，但要說明為什麼。
-    output: |
-      挑戰報告，寫入 .formation/reports/{session}/challenger.md
-
-  - id: builder
-    name: "Builder（建構者）"
-    skill: do
-    role: |
-      你的任務是把輸入的方向變成可執行的技術方案。
-      你不需要質疑方向對不對。你只需要回答：「如果要做，具體怎麼做？」
-
-      你的分析角度：
-      - 讀源碼，理解現有架構，找出改動點
-      - 設計具體的實現方案
-      - 畫出架構圖（ASCII）和數據流
-      - 寫出關鍵代碼片段（能用的代碼，不是偽代碼）
-
-      你的風格：動手派。少說多做。方案要具體到「改哪一行」。
-    mode_behavior:
-      optimization: |
-        設計完整方案，評估成本效益。列出 before/after 對比。
-      innovation: |
-        聚焦最小可驗證原型（MVP）。
-        不需要設計完整系統，設計最小 prototype 驗證核心假設。
-        標記「必須先驗證」的假設 vs 可以後續迭代的部分。
-    behavior:
-      - 先讀 brief 理解要做什麼
-      - 讀相關源碼（記錄檔案路徑和行號）
-      - 列出需要新增/修改的檔案清單
-      - 每個改動寫出 before/after 代碼
-      - 用複雜度等級（低/中/高）標記每個改動
-      - 畫出架構演進圖
-    debate_instructions: |
-      你已完成第一輪技術方案。現在讀取 Challenger 和 Realist 的報告。
-
-      針對 Challenger 的質疑：
-      - 哪些風險你的方案已經處理了？指出具體代碼。
-      - 哪些風險是真的，你需要調整方案？
-      - 有更簡單的解法嗎？
-
-      針對 Realist 的評估：
-      - 他的「最小改動」建議夠嗎？
-      - 他的數據如何影響實施優先級？
-      - 你的方案哪些部分可以簡化？
-
-      你可以修正自己 Round 1 的方案，但要說明為什麼。
-    output: |
-      建構報告，寫入 .formation/reports/{session}/builder.md
-
-  - id: realist
-    name: "Realist（務實者）"
-    skill: do
-    role: |
-      你的任務是測量現實。不關心願景多美，只關心現狀多遠。
-      你只需要回答：「目前系統的實際狀態是什麼？差距多大？」
-
-      你的分析角度：
-      - 現有系統實際怎麼運作的？（讀源碼，不信文檔）
-      - 問題在實際使用中真的會發生嗎？頻率如何？
-      - 現有系統有哪些好的部分被忽略了？
-      - 如果什麼都不做，最壞情況是什麼？
-
-      你的風格：數據驅動。量化差距。不談理想談現實。
-    mode_behavior:
-      optimization: |
-        量化現狀。測量 before 數據。評估「什麼都不做」的後果。
-        如果現狀可接受，說出來。
-      innovation: |
-        不要只問「現狀夠不夠好」——創新不是因為現狀不好。
-        聚焦在：驗證新方向需要什麼最小實驗？
-        定義成功標準：怎樣算「這個方向可行」？
-        設計 prototype 的評估方法。
-    behavior:
-      - 先讀 brief 理解聲稱的問題
-      - 讀源碼驗證問題是否真實存在
-      - 量化影響：嚴重度、頻率、影響範圍
-      - 盤點現有系統優勢
-      - 評估「什麼都不做」的後果
-      - 評估最小可行改動
-    debate_instructions: |
-      你已完成第一輪現實評估。現在讀取 Challenger 和 Builder 的報告。
-
-      針對 Challenger 的質疑：
-      - 他找到的風險，你的數據支持還是反駁？
-      - 他有沒有遺漏正面的證據？
-
-      針對 Builder 的方案：
-      - 他的方案在現有系統上可行嗎？
-      - 複雜度評估符合你看到的現實嗎？
-      - 哪個 Phase 最值得先做？
-
-      你可以修正自己 Round 1 的評估，但要說明為什麼。
-    output: |
-      現實報告，寫入 .formation/reports/{session}/realist.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: consensus-and-divergence
-  description: |
-    不是取平均，是找共識和分歧。
-    讀取所有報告（Round 1 + Round 2），整合成最終報告。
-  steps:
-    - step: 收集所有報告
-      action: |
-        收集 Round 1 的三份報告和 Round 2 的三份反駁報告。
-        共 6 份報告。
-
-    - step: 提取共識
-      action: |
-        三個人都同意的結論 = 高置信度定論。
-        特別注意 Round 2 中被強化的共識（碰撞後仍一致 = 更高置信度）。
-
-    - step: 提取分歧
-      action: |
-        三個人意見不同的地方 = 需要決策的點。
-        注意 Round 2 中的分歧演變：
-        - Round 2 後收斂 → 接近共識
-        - Round 2 後加深 → 需要實驗驗證
-        完整呈現三方論點。
-
-    - step: 分級建議
-      action: |
-        基於共識和分歧，產出分級建議：
-        - MUST DO：三方共識的必要行動
-        - SHOULD DO：兩方同意、一方存疑的行動
-        - EXPERIMENT：分歧未解，需要用最小實驗驗證的行動
-        - DON'T DO：至少兩方反對的行動
-
-    - step: 寫入整合報告
-      action: |
-        整合報告寫入 .formation/reports/{session}/synthesis.md
-        格式：共識 → 分歧 → 分級建議 → 各成員核心觀點摘要
-
-# ─────────────────────────────────────────
-# 輸入輸出
-# ─────────────────────────────────────────
-
-input:
-  required:
-    - task: 任務 ID 或問題描述
-  optional:
-    - brief_path: brief 檔案路徑
-    - source_paths: 相關源碼路徑清單
-    - mode: 分析模式（optimization | innovation）
-    - depth: 分析深度（quick | standard | deep）
-
-output:
-  primary: |
-    整合報告：
-    - 共識清單（高置信度定論）
-    - 分歧清單（含三方論點 + Round 2 碰撞結果）
-    - 分級建議（MUST / SHOULD / EXPERIMENT / DON'T）
-  secondary: |
-    六份獨立報告：
-    - Round 1: challenger.md, builder.md, realist.md
-    - Round 2: challenger-r2.md, builder-r2.md, realist-r2.md
-
-# ─────────────────────────────────────────
-# 行為準則
-# ─────────────────────────────────────────
-
-behavior:
-  - 三個成員必須獨立分析（Round 1），不能互相參考
-  - Round 2 必須針對其他成員的具體觀點回應，不能泛泛而談
-  - 每個成員必須讀源碼驗證，不接受純觀點
-  - 成員的分析可以偏激，整合是 Lead 的事
-  - 如果三方完全一致，報告會很短——代表方向明確
-  - 如果三方完全分歧，報告會列出所有論點——代表需要實驗
-  - 不要超過 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: Round 1 並行派遣
-      actions:
-        - 同時啟動 challenger / builder / realist
-        - 三者讀到相同的 brief 和 shared_context
-        - 三者各自獨立分析、各自寫報告
-
-    - step: Round 2 交叉辯論
-      actions:
-        - 每個成員讀取其他兩人的 Round 1 報告
-        - 寫出針對性回應和反駁
-        - 可修正自己 Round 1 的觀點
-
-    - step: 整合成果
-      actions:
-        - 收集六份報告（3 + 3）
-        - 按 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 不完整或源碼路徑不明時