kenaz 0.3.5 → 0.3.7

package/core/.formation/legion/forge.yaml

@@ -1,299 +0,0 @@
-skill: forge
-formation: legion
-version: "1.0"
-
-name: Forge
-description: |
-  順序流水線：設計 → 打造 → 淬煉。
-  一個人設計藍圖，多個人照藍圖打造，一個人驗收淬煉。
-  每個階段的產出是下一階段的輸入。階段之間有回饋循環 — 打造時發現設計問題可以即時回報修正。
-  這是 Legion 最經典的模式：有序、有回饋、有品質把關。
-
-# ─────────────────────────────────────────
-# 溝通模式（核心設計）
-# ─────────────────────────────────────────
-
-topology: pipeline
-# designer → implementer(s) → reviewer
-#     ↑ 回饋修正 ←─────────────↓
-
-communication:
-  core_pattern: |
-    順序傳遞 + 回饋循環：
-    1. Designer 產出藍圖（介面契約、架構設計、遷移計劃）
-    2. Implementer(s) 按藍圖執行，遇到問題即時回報 Designer
-    3. Reviewer 驗收每個 Implementer 的產出，不通過則打回修正
-    4. 全部通過後，Reviewer 通知 Team Lead
-
-  triggers:
-    - name: 藍圖發布
-      when: Designer 完成或更新設計
-      who: designer → all implementers + reviewer
-      content: 介面契約、架構設計、分工建議
-
-    - name: 問題回報
-      when: Implementer 發現藍圖有問題（設計不可行、漏洞、矛盾）
-      who: implementer → designer
-      content: 問題描述、影響範圍、建議修正
-
-    - name: 跨邊界通知
-      when: Implementer 修改了影響其他 Implementer 的介面
-      who: implementer → implementer
-      content: 修改的介面、舊 → 新、需要對方配合的變更
-
-    - name: 完成通知
-      when: Implementer 完成分配的工作
-      who: implementer → reviewer
-      content: 完成的模組、修改的檔案、風險點
-
-    - name: 審查結果
-      when: Reviewer 完成審查
-      who: reviewer → implementer
-      content: 通過 / 需修正（附具體問題和位置）
-
-    - name: 全部通過
-      when: 所有 Implementer 的產出都通過審查
-      who: reviewer → team-lead
-      content: 審查摘要、整體品質評估
-
-  broadcast_policy: |
-    只在以下情況 broadcast：
-    - 藍圖有破壞性變更（所有人都要更新認知）
-    - Team Lead 調整分工
-    其他一律用 message 直接溝通。
-
-# ─────────────────────────────────────────
-# 成員定義（動態，由 Lead 根據任務決定）
-# ─────────────────────────────────────────
-
-members:
-  roles:
-    - id: designer
-      name: Designer
-      count: 1
-      description: |
-        設計藍圖的人。可以是架構師、API 設計師、遷移規劃者 — 取決於任務。
-        核心產出：藍圖（介面契約、架構圖、遷移步驟、分工建議）。
-      responsibilities:
-        - 分析需求，設計解決方案
-        - 定義介面契約（型別、函數簽名、模組邊界）
-        - 規劃實作順序和分工建議
-        - 回應 Implementer 的問題回報，必要時更新藍圖
-      sends_to: [implementers, reviewer]
-      receives_from: [implementers, reviewer]
-
-    - id: implementer
-      name: Implementer
-      count: "1-3（由 Lead 根據任務規模決定）"
-      description: |
-        按藍圖打造的人。拿到 Designer 的藍圖和分配的範圍，執行實作。
-        發現問題即時回報 Designer，不要自己猜。
-      responsibilities:
-        - 按藍圖和分配的範圍執行實作
-        - 更新所有受影響的引用和依賴
-        - 跨邊界變更時通知其他 Implementer
-        - 完成後通知 Reviewer
-      sends_to: [designer, other_implementers, reviewer]
-      receives_from: [designer, other_implementers, reviewer]
-
-    - id: reviewer
-      name: Reviewer
-      count: 1
-      description: |
-        淬煉品質的人。驗收每個 Implementer 的產出，確保符合藍圖、無遺漏、品質達標。
-        發現問題直接打回對應 Implementer，架構層級問題升級給 Designer。
-      responsibilities:
-        - 審查每個 Implementer 的產出
-        - 驗證介面一致性（新介面在所有消費端正確使用）
-        - 檢查舊名稱/舊路徑殘留
-        - 執行測試，確認不破壞現有功能
-      sends_to: [implementers, designer, team-lead]
-      receives_from: [implementers, designer]
-
-# ─────────────────────────────────────────
-# 生命週期
-# ─────────────────────────────────────────
-
-lifecycle:
-  phases:
-    - phase: design
-      description: Designer 分析需求、產出藍圖
-      lead_actions:
-        - 建立團隊（TeamCreate）
-        - 派出 Designer
-        - 等待藍圖產出
-      exit_criteria:
-        - Designer 產出完整藍圖（介面契約 + 分工建議）
-        - Lead 確認藍圖合理
-
-    - phase: build
-      description: Implementer(s) 按藍圖執行，Reviewer 同步就位
-      lead_actions:
-        - 根據藍圖的分工建議，派出 Implementer(s) 和 Reviewer
-        - Broadcast 藍圖給所有成員
-        - 監控跨邊界溝通，協調衝突
-      member_actions:
-        - Implementer(s) 按分配的範圍執行
-        - 遇到問題 → SendMessage 給 Designer
-        - 完成 → SendMessage 給 Reviewer
-        - Reviewer 逐一審查
-
-    - phase: temper
-      description: 全面驗證、修正、淬煉品質
-      lead_actions:
-        - 確認所有 Implementer 的產出通過 Reviewer 審查
-        - 處理未通過的修正循環（Reviewer → Implementer → Reviewer）
-        - 全量測試
-      exit_criteria:
-        - 所有模組通過審查
-        - 無編譯/型別錯誤
-        - 測試通過
-        - Grep 確認無舊名稱殘留
-
-    - phase: teardown
-      description: 收集成果、關閉團隊
-      lead_actions:
-        - 收集 Designer 的藍圖文件
-        - 收集 Implementer 的變更清單
-        - 收集 Reviewer 的審查結果
-        - 整合為完成報告
-        - shutdown_request 給所有成員
-
-# ─────────────────────────────────────────
-# 輸入輸出
-# ─────────────────────────────────────────
-
-input:
-  required:
-    - task: 任務 ID 或描述
-  optional:
-    - blueprint: 已有的設計藍圖（如有，跳過 design 階段）
-    - scope: 限制範圍
-    - preserve: 不可修改的檔案或介面
-
-output:
-  primary: |
-    完成報告：
-    - 藍圖摘要（Designer 產出）
-    - 修改的檔案列表（按 Implementer 分組）
-    - 審查結果（Reviewer 產出）
-    - 測試結果
-  secondary: |
-    - 發現但未處理的技術債
-    - 建議的後續任務
-
-# ─────────────────────────────────────────
-# 行為準則（Team Lead）
-# ─────────────────────────────────────────
-
-behavior:
-  - 先 design 再 build — 不要跳過藍圖直接開工
-  - Designer 的藍圖是唯一的真相來源（single source of truth）
-  - Implementer 之間的分工要明確，避免改同一個檔案
-  - Reviewer 說「需修正」時，必須修完才能進入 temper
-  - 控制團隊規模：1 Designer + 1~3 Implementers + 1 Reviewer（最多 5 人）
-  - 結束前用 Grep 掃描舊名稱殘留
-
-# ─────────────────────────────────────────
-# 成員 Prompt 模板
-# ─────────────────────────────────────────
-
-member_prompts:
-  designer: |
-    ## Role
-    你是 Forge 的 Designer — 鍛造的第一步，設計藍圖。
-
-    ## 你的職責
-    - 分析需求，設計解決方案
-    - 產出藍圖：介面契約、架構設計、實作步驟、分工建議
-    - 回應 Implementer 的問題回報
-
-    ## 溝通
-    - 藍圖完成 → broadcast 給所有成員
-    - 收到問題回報 → 評估後更新藍圖並通知
-    - 藍圖有破壞性變更 → broadcast
-
-    ## 任務
-    {designer_task_description}
-
-  implementer: |
-    ## Role
-    你是 Forge 的 Implementer — 鍛造的核心，按藍圖打造。
-
-    ## 你的職責
-    - 按 Designer 的藍圖執行你負責的部分
-    - 更新所有受影響的引用和依賴
-    - 發現問題即時回報 Designer，不要自己猜
-
-    ## 溝通
-    - 跨邊界變更 → SendMessage 給其他 Implementer
-    - 發現藍圖問題 → SendMessage 給 Designer
-    - 完成 → SendMessage 給 Reviewer
-    - 收到審查意見 → 修正後回覆 Reviewer
-
-    ## 你負責的範圍
-    {implementer_scope}
-
-    ## 藍圖
-    {blueprint}
-
-  reviewer: |
-    ## Role
-    你是 Forge 的 Reviewer — 鍛造的最後一步，淬煉品質。
-
-    ## 你的職責
-    - 審查每個 Implementer 的產出
-    - 驗證介面一致性
-    - 檢查舊名稱/舊路徑殘留
-    - 執行測試
-
-    ## 溝通
-    - 審查通過 → SendMessage 給對應 Implementer 確認
-    - 需要修正 → SendMessage 給對應 Implementer（附問題詳情）
-    - 架構問題 → SendMessage 給 Designer
-    - 全部通過 → SendMessage 給 team-lead
-
-    ## 藍圖
-    {blueprint}
-
-# ─────────────────────────────────────────
-# 任務系統整合
-# ─────────────────────────────────────────
-
-collaboration:
-  task_api: node .collaboration/core/task-api.js
-
-  workflow:
-    - step: 讀取任務
-      run: node .collaboration/core/task-api.js get {task_id}
-
-    - step: 認領任務
-      run: node .collaboration/core/task-api.js claim {task_id}
-
-    - step: design 階段
-      actions:
-        - 建立團隊（TeamCreate）
-        - 派出 Designer 分析並設計
-        - 等待藍圖產出
-
-    - step: build 階段
-      actions:
-        - 根據藍圖分工，派出 Implementer(s) 和 Reviewer
-        - Broadcast 藍圖
-        - 監控溝通，協調衝突
-
-    - step: temper 階段
-      actions:
-        - 確認所有產出通過審查
-        - 處理修正循環
-        - 全量測試
-
-    - step: teardown
-      actions:
-        - 收集成果，關閉團隊
-
-    - step: 完成任務
-      run: node .collaboration/core/task-api.js complete {task_id}
-
-  on_blocked:
-    run: node .collaboration/core/task-api.js move {task_id} blocked

package/core/.formation/legion/hive.yaml

@@ -1,238 +0,0 @@
-skill: hive
-formation: legion
-version: "1.0"
-
-name: Hive
-description: |
-  網狀即時協調：所有成員互相連接，任何人的變更都即時影響其他人。
-  沒有固定的流水線順序，沒有「先設計再實作」的階段。
-  所有人同時工作、同時溝通、即時調整。
-  這是 Legion 最重量級的模式 — 只在成員之間的工作高度耦合時使用。
-
-# ─────────────────────────────────────────
-# 溝通模式（核心設計）
-# ─────────────────────────────────────────
-
-topology: mesh
-# A ←→ B
-# ↕    ↕
-# C ←→ D
-# 所有人可以直接跟所有人溝通
-
-communication:
-  core_pattern: |
-    全連接 + 即時同步：
-    1. 所有成員同時開始工作
-    2. 任何人修改了影響他人的東西 → 立即通知受影響的成員
-    3. 收到通知 → 評估影響 → 調整自己的工作 → 如有連鎖影響再通知
-    4. 遇到無法自行解決的衝突 → 升級給 Team Lead 裁決
-    持續循環直到所有成員確認自己的部分完成且與他人一致。
-
-  triggers:
-    - name: 變更通知
-      when: 成員修改了可能影響其他人的介面、型別、或行為
-      who: any → affected members
-      content: 修改的內容、舊 → 新、影響範圍、需要對方做的調整
-
-    - name: 衝突發現
-      when: 兩個成員的修改互相矛盾
-      who: discoverer → conflicting member
-      content: 衝突描述、雙方的修改、建議的解法
-
-    - name: 衝突升級
-      when: 成員之間無法自行解決衝突
-      who: any → team-lead
-      content: 衝突描述、雙方的立場、各自的理由
-
-    - name: 同步確認
-      when: 成員完成一個階段性的修改，需要確認與其他人一致
-      who: any → all related members
-      content: 完成的修改摘要、當前的介面狀態
-
-    - name: 完成宣告
-      when: 成員確認自己的部分已完成且與所有人一致
-      who: member → team-lead
-      content: 完成的工作摘要、已確認一致的成員名單
-
-  broadcast_policy: |
-    Hive 的 broadcast 使用頻率比 Forge 高，但仍需節制：
-    - ✅ 全局介面變更（影響所有人）
-    - ✅ Team Lead 裁決衝突後的結論
-    - ✅ 整體方向調整
-    - ❌ 只影響一兩個人的局部變更（用 message）
-
-# ─────────────────────────────────────────
-# 成員定義（動態，由 Lead 根據任務決定）
-# ─────────────────────────────────────────
-
-members:
-  roles:
-    - id: worker
-      name: Worker
-      count: "2-4（由 Lead 根據任務決定）"
-      description: |
-        Hive 的成員沒有固定角色（不是 Designer/Implementer/Reviewer）。
-        每個人都是 Worker，各自負責一塊範圍，但所有人的工作互相影響。
-        差別只在分配到的 scope，不在角色。
-      responsibilities:
-        - 在分配的範圍內完成工作
-        - 修改影響他人的內容時即時通知
-        - 收到他人的變更通知時評估影響並調整
-        - 發現衝突時嘗試自行解決，解決不了就升級
-        - 完成後確認與所有相關成員的介面一致
-      sends_to: [all_workers, team-lead]
-      receives_from: [all_workers, team-lead]
-
-# ─────────────────────────────────────────
-# 生命週期
-# ─────────────────────────────────────────
-
-lifecycle:
-  phases:
-    - phase: deploy
-      description: 建立團隊、分工、同步初始狀態
-      lead_actions:
-        - 建立團隊（TeamCreate）
-        - 分析任務，劃分工作範圍（scope 可以有少量重疊，因為有溝通能力）
-        - 同時派出所有 Worker
-        - Broadcast 整體目標和每個人的範圍
-      exit_criteria:
-        - 所有 Worker 已啟動
-        - 每個人知道自己的範圍和隊友的範圍
-
-    - phase: swarm
-      description: 所有人同時工作、即時溝通、持續調整
-      lead_actions:
-        - 監控成員之間的溝通
-        - 收到衝突升級時裁決
-        - 定期檢查整體進度（不微管理）
-      member_actions:
-        - 在自己的範圍內工作
-        - 變更影響他人 → 通知
-        - 收到通知 → 評估 → 調整
-        - 衝突 → 先嘗試自行解決 → 解決不了升級
-      exit_criteria:
-        - 所有 Worker 宣告完成
-        - 所有跨邊界介面已確認一致
-
-    - phase: converge
-      description: 收斂驗證 — 確認所有人的產出整合正確
-      lead_actions:
-        - 全量測試
-        - 檢查跨邊界的介面一致性
-        - 處理最後的整合問題
-      exit_criteria:
-        - 無編譯/型別錯誤
-        - 測試通過
-        - 所有 Worker 確認完成
-
-    - phase: teardown
-      description: 收集成果、關閉團隊
-      lead_actions:
-        - 收集每個 Worker 的工作摘要
-        - 整合為完成報告
-        - shutdown_request 給所有成員
-
-# ─────────────────────────────────────────
-# 輸入輸出
-# ─────────────────────────────────────────
-
-input:
-  required:
-    - task: 任務 ID 或描述
-  optional:
-    - scope_map: 預先劃分的工作範圍（如有，跳過 Lead 的範圍劃分）
-    - constraints: 全局約束
-
-output:
-  primary: |
-    完成報告：
-    - 各 Worker 的工作摘要
-    - 跨邊界介面最終狀態
-    - 測試結果
-  secondary: |
-    - 發生的衝突和解決方式
-    - 建議的後續任務
-
-# ─────────────────────────────────────────
-# 行為準則（Team Lead）
-# ─────────────────────────────────────────
-
-behavior:
-  - Hive 是最昂貴的模式 — 只在工作真的高度耦合時使用
-  - 控制團隊規模：2-4 個 Worker（超過 4 個溝通開銷會爆炸）
-  - scope 可以有少量重疊（Hive 的溝通能力可以處理），但盡量減少
-  - 不微管理 — 讓成員自己協調，只在衝突升級時介入
-  - 裁決衝突時要快、要明確，不要模棱兩可
-  - swarm 階段可能持續較久，這是正常的 — 即時協調本來就需要時間
-
-# ─────────────────────────────────────────
-# 成員 Prompt 模板
-# ─────────────────────────────────────────
-
-member_prompts:
-  worker: |
-    ## Role
-    你是 Hive 的 Worker — 蜂巢的一員，與所有隊友即時協作。
-
-    ## 你的職責
-    - 在分配的範圍內完成工作
-    - **修改任何可能影響隊友的東西時，立即通知**
-    - 收到隊友的變更通知 → 評估影響 → 調整自己的工作
-    - 發現衝突 → 先跟對方溝通解決 → 解決不了升級給 team-lead
-
-    ## 溝通規則（重要）
-    - 你可以跟任何隊友直接溝通（SendMessage）
-    - 修改了介面、型別、或可能影響他人的行為 → **必須通知**
-    - 不確定會不會影響 → **寧可通知，不要不通知**
-    - 收到通知後要回覆確認（「已調整」或「不影響我」）
-
-    ## 你的隊友
-    {teammates_info}
-
-    ## 你負責的範圍
-    {worker_scope}
-
-    ## 整體目標
-    {overall_goal}
-
-# ─────────────────────────────────────────
-# 任務系統整合
-# ─────────────────────────────────────────
-
-collaboration:
-  task_api: node .collaboration/core/task-api.js
-
-  workflow:
-    - step: 讀取任務
-      run: node .collaboration/core/task-api.js get {task_id}
-
-    - step: 認領任務
-      run: node .collaboration/core/task-api.js claim {task_id}
-
-    - step: deploy 階段
-      actions:
-        - 建立團隊（TeamCreate）
-        - 分析任務、劃分範圍
-        - 同時派出所有 Worker
-        - Broadcast 目標和範圍
-
-    - step: swarm 階段
-      actions:
-        - 監控溝通、裁決衝突
-        - 等待所有 Worker 宣告完成
-
-    - step: converge 階段
-      actions:
-        - 全量測試
-        - 處理最後整合問題
-
-    - step: teardown
-      actions:
-        - 收集成果，關閉團隊
-
-    - step: 完成任務
-      run: node .collaboration/core/task-api.js complete {task_id}
-
-  on_blocked:
-    run: node .collaboration/core/task-api.js move {task_id} blocked