kenaz 0.3.5 → 0.3.6

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

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: 子任務之間有隱含依賴，無法乾淨拆分