kenaz 0.3.3 → 0.3.6

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 不完整或源碼路徑不明時