kenaz 0.3.22 → 0.3.24

package/core/dev/archive/ansuz/legacy/phases/phase_2.yaml

@@ -1,94 +0,0 @@
-phase: 2
-name: "背景調研"
-goal: "用神經脈衝建立完整 context — 圖譜先行，再設計任務"
-
-actions:
-  - |
-    【Metacognitive Planning Check】(TASK_973 Metacognitive Planning Layer)
-    Before starting research, consult metacognitive_state.json to adapt strategy:
-      1. Read {PROJECT_PATH}/.kenaz/specialist/metacognitive_state.json
-         → If file missing or empty: skip this step silently (cold start — no history yet)
-      2. Check knowledge.task_type_performance for the current task's type (from Phase 1 requirement_type):
-         → If avg_accuracy < 0.5: flag as "weak area" — allocate deeper Phase 2 research
-         → If avg_accuracy > 0.8: flag as "strong area" — can use lighter research
-      3. Check knowledge.learning_strategy_effectiveness:
-         → Deprioritize strategies with effectiveness_rate < 0.3
-         → Prefer strategies with effectiveness_rate > 0.7
-      4. Check knowledge.domain_familiarity for scope_paths domains:
-         → Unfamiliar domains (confidence < 0.4): add extra Grep/Glob exploratory queries
-      5. Check planning.current_priorities:
-         → If current task aligns with a priority, note the recommended approach
-      6. Apply planning.strategy_selection_rules to determine research order
-      7. Output one-line summary: "📊 Metacognitive: {strategy adjustment or 'baseline — no history'}"
-    This step is informational — it adjusts research intensity, not phase gates.
-  - "搜尋相關 Feature ID（Grep dev/PRODUCT_SPEC.md）"
-  - "synapse_recall(目標 symbol / 主題) — 已知 risk/decision/fix rune"
-  - "kenaz_lsp_callers / kenaz_lsp_references(目標 symbol) — 誰呼叫、誰引用（爆炸半徑）"
-  - "Grep/Glob — 探索相關代碼與檔案結構"
-  - "cortex_recall — 查跨專案歷史知識（mandatory，與 synapse_recall 並行）"
-  - "cortex_search — 找其他專案的相似實現"
-  - "Grep — 僅用於精確字串匹配"
-  - "查閱類似已完成任務（task-api.js search）+ 檢查 .failure/ 相關失敗模式"
-
-caller_driven_research:
-  rule: "Phase 3 的 scope_paths 和 dependencies 必須有 LSP callers / recall 結果支撐，不靠推斷"
-  note: "核心 symbol 來源：需求描述或 scope_paths 推斷"
-  scope_from_callers: "scope_paths = kenaz_lsp_callers / kenaz_lsp_references 結果所在的文件路徑"
-  complexity_from_callers: |
-    simple: callers < 10 且無跨模組呼叫
-    medium: callers 10-30 或跨 1-2 個模組
-    complex: callers > 30 或跨 3+ 個模組
-
-empty_result:
-  when: "synapse_recall 與 kenaz_lsp_callers 都回空"
-  action: "懶載入 modules/pulse_empty.yaml"
-
-prophetic_comparison:
-  when: "Phase 2 偵測到 2+ 方案"
-  action: "懶載入 modules/prophecy.yaml — 各方案跑 kenaz_lsp_callers + recall，結構數據選方案"
-
-cross_project_mandatory:
-  rule: "Phase 2 開始時，與 synapse_recall 同步執行 cortex_recall（並行）"
-  why: "跨專案 risk/fix/decision rune 是免費經驗值"
-
-fallbacks:
-  lsp: "kenaz_lsp_* 失敗 → 降級用 Grep/Glob"
-  cortex: "cortex 不可用 → 跳過跨專案查詢，不阻塞"
-
-cli_format: |
-  🔍 背景調研 + 神經脈衝
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  相關 Feature: {F-XXX}
-
-  ⚡ 脈衝結果: {symbol_name}
-  爆炸半徑: {total_impacted} symbols, {community_crossings} 跨模組
-  風險等級: {overall_risk}
-  受影響流程: {affected_processes}
-  歷史風險: {known_risks 摘要}
-  建議: {recommendations}
-
-  相關代碼: {檔案路徑}
-  類似任務: {TASK_XXX}
-  已知風險: {.failure 相關模式}
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-interaction:
-  type: "auto"
-  instruction: "靜默執行，結果併入 Phase 3 輸出"
-
-checklist:
-  - "metacognitive_planning_check 已執行（或 cold start 靜默跳過）"
-  - "context-injection 已執行：node .specialist/tools/context-injection.js --phase=2 --task={task_id} [--project-path=PATH]，取得 pulse_targets 後對其執行 synapse_recall + kenaz_lsp_callers"
-  - "kenaz_lsp_callers 已對核心 symbol 執行（或已 fallback 到 Grep）"
-  - "scope_paths 從 callers / references 提取（非推斷）"
-  - "cortex_recall 已並行執行"
-
-context_hints:
-  input_from: "phase_1"
-  key_data: ["requirement_type", "priority", "summary"]
-
-inject:
-  rules:
-    - synapse-code-intelligence.yaml
-    - cortex-tools.yaml
-  specialist: []

package/core/dev/archive/ansuz/legacy/phases/phase_3.yaml

@@ -1,274 +0,0 @@
-phase: 3
-name: "任務設計"
-goal: "用脈衝結果拆解需求為獨立、可執行的任務 — 圖譜驅動，不靠推斷"
-
-# TASK_1020: Phase 3 exit self-annotation requirement.
-# phase-gate.js reads `required_exit_args` metadata and emits a stderr warning
-# when the listed args are absent on `phase-gate.js exit --phase=3`. Grace
-# period: warning-only until TASK_1018 attribution pipeline has ≥5 sessions of
-# data, then promoted to hard-block in a follow-up task.
-required_exit_args:
-  - name: thinking_tag
-    cli_flag: "--thinking-tag"
-    required: true
-    enforcement: warn  # warn | block — grace period uses warn
-    min_count: 1
-    max_count: 3
-    value_source: "kernel.yaml principles keys (e.g. differential_over_intuition, wire_over_rewrite)"
-    purpose: |
-      Capture which 1-3 principles guided the decide phase in Phase 3 (任務設計).
-      Feeds TASK_1018 attribution pipeline: links task-design decisions back to
-      principles so post-complete can measure which principles correlate with
-      successful outcomes.
-    warning_message: |
-      ⚠️  Phase 3 exit without --thinking-tag — principle attribution data lost.
-          Add --thinking-tag=<principle>[,<principle>...] naming 1-3 principles
-          that guided task breakdown. Examples: see phase_3.yaml thinking_tag_usage.
-
-thinking_tag_usage:
-  description: |
-    Self-annotation: after finalizing the task list, tag this decide phase with
-    the principles that shaped the breakdown. This is NOT decoration — it
-    closes the feedback loop between principles (kernel.yaml) and outcomes
-    (post-complete health_delta).
-  cli_syntax: |
-    node .specialist/tools/phase-gate.js exit --phase=3 --task=TASK_XXX \
-      --data='{...}' --thinking-tag=differential_over_intuition,wire_over_rewrite
-  how_to_choose:
-    - "Pick the 1-3 principles you actually leaned on while deciding — not all principles, not none"
-    - "Tag names must match kernel.yaml principles keys (snake_case, no prefix)"
-    - "If you honestly cannot name a principle, something is wrong — go back to Phase 2"
-  common_scenarios:
-    diagnosed_competing_hypotheses:
-      when: "You weighed 2+ implementation approaches and eliminated some with evidence"
-      tag: "differential_over_intuition"
-      example: "Considered monolith task vs split-by-role → chose split after scope overlap analysis"
-    chose_existing_over_new:
-      when: "You scoped tasks around existing code/APIs instead of introducing new abstractions"
-      tag: "wire_over_rewrite"
-      example: "Reused phase-gate.js exit hook instead of creating new validator module"
-    split_by_graph_structure:
-      when: "Task boundaries came from pulse/impact data, not estimation"
-      tag: "structural_over_estimation"
-      example: "scope_paths derived from kenaz_lsp_callers results, not guessed"
-    surfaced_ambiguity:
-      when: "You exposed a design problem to the user rather than picking silently"
-      tag: "expose_problems"
-      example: "Two valid task splits existed → surfaced both in AskUserQuestion rather than choosing"
-    made_acceptance_grep_verifiable:
-      when: "Acceptance criteria written as executable greps, not subjective checks"
-      tag: "verifiable_over_explainable"
-      example: "'grep kernel.yaml thinking.tag returns non-empty' instead of 'kernel mentions thinking tag'"
-    followed_evidence_against_default:
-      when: "You chose something because data said so, even if it contradicted the obvious path"
-      tag: "evidence_over_authority"
-      example: "Kept 2 tasks instead of merging, because scope_paths overlap would cause conflicts"
-    true_dep_vs_false_dep:
-      when: "You identified which tasks can parallelize vs which must serialize"
-      tag: "real_dependency_over_perceived"
-      example: "Frontend task marked dependencies=[] because it uses mock API — no real dep on backend"
-    user_intent_not_literal:
-      when: "You reframed the user ask to match their underlying goal"
-      tag: "intent_over_literal"
-      example: "User said 'add logging' → actual need was observability metrics, scoped accordingly"
-  anti_patterns:
-    - "❌ Tagging all 8 principles 'to be safe' — max 3, max_count enforced by phase-gate.js"
-    - "❌ Picking tags that sound good but didn't actually drive the decision — defeats attribution"
-    - "❌ Using freeform strings instead of principle keys — phase-gate.js warns on unknown tags"
-    - "❌ Skipping --thinking-tag because 'I didn't really think about principles' — then Phase 3 was cargo-culted"
-
-
-ddx_trigger:
-  when: "需求有多種實作方案、或涉及架構決策時"
-  action: "懶載入 modules/ddx.yaml → modules/prophecy.yaml — 量化風險後選方案"
-
-amelia_review:
-  trigger: "Phase 3 用戶批准後，根據複雜度決定是否啟動"
-  skip: "任務 ≤2 + 同 role + 無 P0 + scope 無重疊 → Ansuz 自行分配 role"
-  full_protocol: "懶載入 modules/amelia_review.yaml — 複雜任務兩階段審查"
-
-phantom_declaration:
-  description: "在任務設計時，為每個計畫新增的 symbol 呼叫 synapse_declare 建立 phantom 節點，實現「設計先於實作」的圖譜預覽"
-  trigger:
-    graph_maturity_gate:
-      rule: "Phase 0 的 synapse_status 回傳 total_symbols ≥ 50 時才啟用 CGDD。低於此閾值 → phantoms_declared: skipped (graph_immature)"
-      why: "全 phantom 圖的 impact 是自我循環 — CGDD 的價值來自 phantom 與 real symbol 的交互。圖譜太小時直接寫代碼 + index 建圖更高效"
-      threshold: 50
-      check: "synapse_status → total_symbols（Phase 0 已取得，不需重複呼叫）"
-    cross_module_gate:
-      rule: "單函數新增 → GDD（pulse）夠用，跳過 CGDD。跨模組新增 2+ 個互相呼叫的新 symbol → 啟用 CGDD"
-      why: "CGDD 不可替代的價值在跨模組架構設計。單函數場景 overhead > benefit"
-    keyword_heuristic: "requirements 中出現 add|create|implement|new|introduce 關鍵字時觸發"
-    skip_condition: "需求為 bug-fix / refactor / optimize（僅修改現有 symbol）→ 跳過，phantoms_declared: skipped"
-  kind_mapping:
-    "add|create|new": "function 或 class（視 scope_paths 決定）"
-    "implement|introduce": "function 或 interface 或 struct"
-    "*.ts|*.tsx": "function / class / interface"
-    "*.rs": "function / struct / impl"
-    "*.py": "function / class"
-  per_symbol_actions:
-    - "推導 symbol_id：{file_path}:{name}:{kind}（例 src/foo.ts:newHandler:function）"
-    - "推導 name 和 signature：從 requirements 文字提取 — 語義命名，不猜測實作細節"
-    - "推導 intended_file_path：從 scope_paths 推斷最合理的目標檔案"
-    - "呼叫 synapse_declare(symbol_id, name, kind, intended_file_path, signature, calls=[], called_by=[], implements=[])"
-    - "邊接線：從 Phase 2 kenaz_lsp_callers 結果中找 callers/callees symbol_id → 填入 calls / called_by"
-    - "呼叫 kenaz_lsp_callers / kenaz_lsp_references → 記錄爆炸半徑（caller 數, affected_files）"
-  output:
-    phantom_ids_format: "[PHANTOM] symbol_id_1, symbol_id_2（寫入 task YAML technical_notes，供 appendPhantomContext 解析）"
-    cli_section: "在 cli_format 中輸出 ## 👻 Phantom Symbols 段落（僅當有 phantom 時）"
-    design_benefit: "blast radius 預覽讓任務設計可基於衝擊數據調整 scope_paths 和 dependencies"
-  edge_wiring:
-    source: "Phase 2 kenaz_lsp_callers 結果中的 callers / callees symbol_id"
-    validation: "synapse_declare 回報 edges_created vs edges_failed — 失敗邊記入 known_risks"
-    fallback: "callers 無結果時，calls/called_by 留空（phantom 仍建立，但無邊）"
-    caller_branch_coverage:
-      rule: "聲明 called_by edge 前，必須 Read caller 原始碼確認 caller 的所有執行分支是否都需要呼叫新 symbol"
-      why: "TASK_761 教訓 — cleanup_orphan_phantoms 只放在 run_full_index，遺漏 run_incremental_index。讀 caller 原始碼可看到所有分支，一眼看出是否有遺漏"
-      protocol: |
-        1. Read(caller_symbol 所在檔案) → 看 callees 列表
-        2. 問：caller 有幾條執行路徑（如 full vs incremental）？
-        3. 新 symbol 應該在哪些路徑被呼叫？全部？還是特定條件？
-        4. 在 requirement 中明確寫出呼叫位置（共享路徑 vs 特定分支）
-
-cgdd_contract_analysis:
-  description: "CGDD（Contract-Graph Driven Design）— 在 dispatch 前為 code-touching 任務映射 dispatcher/normalizer/consumer 邊界合約，預見跨邊界風險"
-  trigger:
-    code_touching_gate:
-      rule: "任務會修改程式碼（role = backend/frontend/developer/sre）時啟用。design-only/research/qa 任務跳過"
-      why: "CGDD 的價值在預見程式碼邊界合約破壞。純設計/研究任務無程式碼邊界"
-    complexity_gate:
-      rule: "scope_paths 跨 2+ 個檔案 OR requirements 涉及修改函數簽名/新增 boundary 時啟用。單檔 trivial fix 跳過"
-      why: "CGDD 對單檔 fix 的 overhead > benefit（同 phantom_declaration 的 cross_module_gate 精神）"
-  protocol:
-    step_1:
-      action: "為每個 scope_path 中的修改目標，用 kenaz_lsp_callers 或 Read 識別現有 data flow"
-      output: "Data Flow Graph — 從 input source 到 output sink 的完整路徑"
-    step_2:
-      action: "在 flow 中標記每個跨檔案/跨模組 boundary 的 contract（Producer → Consumer → 輸入/輸出格式）"
-      output: "Contracts 表 — | Boundary | Producer | Consumer | Contract | Bug/Risk |"
-    step_3:
-      action: "識別 [NEW] boundary（任務會新增的邊界）和 [BREAK] boundary（任務會改變的既有合約）"
-      output: "風險標記 — 哪些 consumer 可能因合約變更而壞掉"
-    step_4:
-      action: "將 CGDD 分析結果注入任務的 technical_notes（供 dispatch agent 帶著認知開工）"
-      format: |
-        technical_notes 追加：
-        [CGDD] Data flow: {Producer} → {Boundary} → {Consumer}
-        [CGDD] New boundary: {description}
-        [CGDD] Risk: {consumer} depends on {contract} — verify after modification
-  output:
-    cli_section: |
-      ## 🔗 CGDD Contract Analysis
-      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-      | Boundary | Producer | Consumer | Contract | Risk |
-      |----------|----------|----------|----------|------|
-      ...
-      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-    inject_to_task: "CGDD 結果寫入每個任務的 technical_notes，格式化為 [CGDD] prefix 行"
-  skip_annotation: "cgdd_analysis: skipped (design-only | single-file trivial | qa/research)"
-  rules:
-    - "✅ CGDD 在 phantom_declaration 之後執行（phantom 提供新 symbol 的邊界資訊）"
-    - "✅ 識別 [NEW] boundary 時，requirements 必須明確指出 consumer 端的驗證方式"
-    - "✅ 識別 [BREAK] boundary 時，acceptance_criteria 必須包含 consumer 端回歸驗證"
-    - "❌ 不為 CGDD 開獨立任務 — 它是 Phase 3 的內建分析步驟，不是額外工作"
-
-actions:
-  - "每個任務 1-8 小時可完成"
-  - "任務之間盡量獨立 — 真依賴才序列，假依賴並行"
-  - "scope_paths 從 callers / references 結果提取，確保並行安全"
-  - "分配 agent_type（frontend/backend/sre/qa/designer/developer）"
-  - "執行 phantom_declaration — 偵測 new-symbol keywords → synapse_declare → kenaz_lsp_callers"
-  - "執行 cgdd_contract_analysis — code-touching 任務映射邊界合約，注入 technical_notes"
-
-scope_safety:
-  rule: "輸出任務列表前，檢查所有任務的 scope_paths 是否有交集"
-  overlap: "有交集 → 必須標記 dependencies 或調整 scope 使其不重疊"
-
-dependency_rules:
-  rule: "每個任務必須分析真依賴：它是否需要其他任務的產出才能開始？"
-  examples:
-    - "API 端點 → 前端呼叫 → 前端任務 depends_on 後端任務"
-    - "設計稿 → 實作 → 前端任務 depends_on 設計任務"
-  no_deps: "確實無依賴 → dependencies: [] 且註明「獨立任務，無前置依賴」"
-
-sizing_rules:
-  - "單一任務不應跨越 2 個以上 role — 如果需要修改前端+後端 → 拆成 2 個"
-  - "每個任務最多 8 小時 — 超過必須拆分"
-
-cli_format: |
-  📐 任務設計
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  共拆解為 {N} 個任務：
-
-  | # | 標題 | Agent | Priority | Hours | 陣型 |
-  |---|------|-------|----------|-------|------|
-  | 1 | ... | frontend | P1 | 4h | unit |
-  | 2 | ... | frontend | P2 | 2h | unit |
-
-  依賴關係: {TASK_B → TASK_A}
-  並行策略: {N 個可並行，M 個需序列}
-
-  ## 👻 Phantom Symbols（設計預覽）
-  ─ 僅當 phantom_declaration 觸發時輸出 ─
-  | Symbol ID | Kind | 目標檔案 | 爆炸半徑 | 風險等級 |
-  |-----------|------|----------|----------|----------|
-  | src/foo.ts:newFn:function | function | src/foo.ts | 5 symbols | MEDIUM |
-
-  Phantom IDs → technical_notes: [PHANTOM] symbol_id_1, symbol_id_2
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-interaction:
-  type: "ask"
-  instruction: |
-    輸出 cli_format 後，用 AskUserQuestion 工具提問，提供選項：
-    「任務拆解是否合理？
-    [A] 合理，繼續
-    [B] 調整任務數或範圍（請說明）
-    [C] 調整優先級
-    [D] 調整 Agent 分配
-    [E] 重新設計」
-  on_A: "→ Phase 3.5（簡單任務跳過）→ Phase 4-5 → Phase 6"
-  on_B_E: "根據用戶說明調整，再次輸出 cli_format + 再次詢問"
-
-checklist:
-  - "scope_paths 無重疊（或重疊已用 dependencies 解決）"
-  - "每個任務有 role 分配"
-  - "依賴關係已標記（真依賴 only）"
-  - "每個任務 ≤8h"
-  - "phantoms_declared: true（有 new-symbol keywords）| skipped（bug-fix/refactor only）"
-  - "cgdd_analysis: done（code-touching 跨檔案任務）| skipped（design-only/trivial/qa/research）"
-
-prediction_recording:
-  description: |
-    After task design is finalized, record a prediction object for each task.
-    This enables outcome tracking: comparing what Ansuz predicted at design time
-    with what actually happened at post-complete (Phase 10).
-  trigger: "Phase 3 task list finalized (user approved)"
-  per_task_actions:
-    - "Collect expected_files from scope_paths (normalized, forward slashes)"
-    - "Collect risk from known_risks (high/medium/low, default: medium)"
-    - "Collect confidence from pulse confidence or default 0.7"
-    - "Write prediction object to .kenaz/specialist/ansuz_predictions.json"
-  prediction_schema:
-    task_id: "TASK_XXX"
-    timestamp: "ISO-8601"
-    expected_files: ["scope_paths as predicted touch set"]
-    risk: "high|medium|low"
-    confidence: 0.7
-    predicted_health_delta: "positive|neutral|negative (from pulse risk assessment)"
-  storage:
-    file: "{PROJECT_PATH}/.kenaz/specialist/ansuz_predictions.json"
-    format: |
-      { "predictions": [ { ...prediction_schema } ] }
-    write_mode: "append to predictions array (atomic read-modify-write)"
-    mkdir: "create .kenaz/specialist/ if absent"
-  output_note: "prediction_id logged in cli_format for traceability"
-
-context_hints:
-  input_from: "phase_2"
-  key_data: ["pulse_targets", "scope_paths", "known_risks", "feature_ids"]
-
-inject:
-  rules:
-    - pipeline.yaml
-  specialist: []

package/core/dev/archive/ansuz/legacy/phases/phase_4.yaml

@@ -1,67 +0,0 @@
-phase: 4
-name: "規格撰寫"
-goal: "為每個任務撰寫詳細 YAML 規格"
-
-required_fields:
-  - "id, title, description, priority, role, acceptance_criteria（必填）"
-  - "scope_paths, requirements, technical_notes, estimated_hours"
-  - "dependencies（真依賴 only）+ feature_ids（關聯 PRODUCT_SPEC）"
-
-task_template_note: "完整 YAML 範例見 workflow.yaml.bak Phase 4 task_template"
-
-design_skill_selection:
-  when: "任務 role = frontend 或 designer 且涉及 UI 變更"
-  action: "懶載入 modules/design_checks.yaml → 選 skill → 寫入 technical_notes [DESIGN_CHECK]"
-  skip_when: "role = backend/sre/qa/security/code_reviewer/incident_response/developer"
-
-verification_inference:
-  description: "根據 scope_paths 副檔名自動推導 verification 欄位（預設值，可被 Ansuz 手動覆蓋）"
-  override_note: "Ansuz 可在任務 YAML 手動定義 verification 欄位以覆蓋推導結果"
-  skip_when: "scope_paths 僅含 .md / .yaml（純文件任務不產生 verification）"
-  rules:
-    - match: "scope_paths 含 *.rs"
-      infer:
-        level_1: "cargo check && cargo test"
-    - match: "scope_paths 含 *.ts 或 *.tsx"
-      infer:
-        level_1: "tsc --noEmit"
-    - match: "scope_paths 含 API route（路徑包含 /api/ 或 routes/）"
-      infer:
-        level_2: "probe endpoint"
-    - match: "scope_paths 含 UI component（路徑包含 components/ 且副檔名為 .tsx）"
-      infer:
-        level_3: "Playwright scenario（optional）"
-  multi_match_note: "多條規則可同時命中，合併所有 infer 欄位（level_1/level_2/level_3）"
-
-actions:
-  - "為每個任務撰寫完整 YAML 規格（必填欄位齊全）"
-  - "role = frontend/designer + UI 變更 → 懶載入 modules/design_checks.yaml"
-  - "acceptance_criteria 每項可測試（非模糊描述）"
-  - "根據 scope_paths 副檔名執行 verification_inference → 寫入任務 verification 欄位（已有手動定義則跳過）"
-
-cli_format: |
-  📝 規格撰寫
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  TASK_XXX: {標題}
-  Requirements: ✓ {需求 1}
-  Acceptance Criteria: ✓ {標準 1}
-  Design Checks: {skill 列表，僅 frontend/designer 任務}
-  Verification: {level_1/level_2/level_3 推導結果，純文件任務顯示 N/A}
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-interaction:
-  type: "auto"
-  instruction: "靜默執行，結果併入 Phase 6 輸出"
-
-checklist:
-  - "所有必填欄位完整（id/title/description/priority/role/acceptance_criteria）"
-  - "scope_paths 合理，dependencies 已設定"
-  - "verification 欄位已填（由 verification_inference 推導，或 Ansuz 手動定義；純文件任務可無）"
-
-context_hints:
-  input_from: "phase_3"
-  key_data: ["task_list", "roles", "dependencies"]
-
-inject:
-  rules: []
-  specialist: []

package/core/dev/archive/ansuz/legacy/phases/phase_5.yaml

@@ -1,32 +0,0 @@
-phase: 5
-name: "驗證"
-goal: "驗證任務完整性和正確性"
-
-actions:
-  - "必填欄位完整？（id, title, description, priority, role, acceptance_criteria）"
-  - "Feature ID 存在於 PRODUCT_SPEC.md？"
-  - "依賴任務存在且狀態正確？"
-  - "scope_paths 合理？（無重疊衝突）"
-  - "agent_type / role 分配正確？"
-  - "acceptance_criteria 可測試？（非模糊描述）"
-  - ".failure/ 相關模式已考慮？"
-
-on_fail: "列出錯誤 → 返回 Phase 4 修正"
-
-cli_format: |
-  ✅ 驗證通過 / ❌ 驗證失敗: {pass/fail 逐條列出}
-
-interaction:
-  type: "auto"
-  instruction: "靜默執行，驗證失敗 → 返回 Phase 4。結果併入 Phase 6 輸出"
-
-checklist:
-  - "全部 7 項驗證通過"
-
-context_hints:
-  input_from: "phase_4"
-  key_data: ["task_yaml_specs"]
-
-inject:
-  rules: []
-  specialist: []

package/core/dev/archive/ansuz/legacy/phases/phase_6.yaml

@@ -1,91 +0,0 @@
-phase: 6
-name: "用戶批准"
-goal: "展示任務摘要，等用戶批准後建立任務卡（auto mode 自動跳過）"
-
-auto_approve:
-  description: "在 auto loop mode 下，自動跳過用戶批准，直接進入 Phase 7"
-  condition:
-    loop_mode: "auto"
-    source_match: "task.source starts with 'wish_'"
-  read_loop_json: |
-    node -e "const fs=require('fs'); const p='.kenaz/loop.json'; console.log(JSON.stringify(fs.existsSync(p) ? JSON.parse(fs.readFileSync(p,'utf8')) : {mode:'manual'}))"
-  behavior:
-    - "讀取 .kenaz/loop.json，取得 mode（不存在時預設 manual）"
-    - "檢查 task source tag（wish_* 前綴）"
-    - "若 mode=auto 且 source 符合條件，輸出 AUTO-APPROVE 稽核日誌後直接進入 Phase 7"
-    - "若不符合條件，走正常 manual 流程（AskUserQuestion）"
-  audit_log_format: |
-    🤖 AUTO-APPROVE [Phase 6]
-    ─────────────────────────────
-    task_id : {task_id}
-    source  : {source_tag}
-    loop    : auto
-    decision: APPROVED — proceeding to Phase 7
-    ─────────────────────────────
-
-actions:
-  - "【第一步】讀取 .kenaz/loop.json，判斷當前 loop mode"
-  - "【auto mode + wish_* source】輸出 AUTO-APPROVE 稽核日誌，跳過 AskUserQuestion，直接 → Phase 7"
-  - "【manual mode 或其他 source】展示任務摘要表格（ID、標題、Agent、Priority、Hours、陣型）"
-  - "展示依賴關係和並行策略"
-  - "展示雙時間估算（人類 vs Agent）"
-  - "用 AskUserQuestion 詢問批准"
-
-time_estimation:
-  agent_rules:
-    "1-4h": "3-5 min"
-    "4-8h": "5-8 min"
-    "8-16h": "8-12 min"
-    "16h+": "12-30 min"
-
-cli_format: |
-  🔍 任務摘要（等待批准）
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  | # | 標題 | Agent | Priority | 人類預估 | Agent 預估 |
-  |---|------|-------|----------|---------|-----------|
-  | 1 | ... | frontend | P1 | 4h | ~5 min |
-
-  依賴: TASK_B → TASK_A
-  並行: 2 個可並行
-  陣型: unit × 2（並行 dispatch）
-
-  ⏱️ 效率提升: ~{ratio}x（{human_hours}h → {agent_min} min）
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-interaction:
-  type: "conditional"
-  auto_mode:
-    condition: "loop mode = auto AND source matches wish_*"
-    action: "輸出 AUTO-APPROVE 稽核日誌（含 task_id + source tag），直接 → Phase 7"
-    note: "禁止呼叫 AskUserQuestion — 這是 headless 自動化流程"
-  manual_mode:
-    instruction: |
-      輸出 cli_format 後，用 AskUserQuestion 工具提問，提供選項：
-      「批准建立任務卡嗎？
-      [A] 批准，開始建立
-      [B] 需要調整規格（請說明）
-      [C] 返回重新設計任務拆解
-      [D] 取消」
-    on_A: "→ Phase 7（建立任務卡）→ Phase 8（自動 dispatch）"
-    on_B: "根據說明調整規格，重走 Phase 4-5，再次詢問批准"
-    on_C: "→ 返回 Phase 3 重新設計"
-    on_D: "停止，回到 Phase 0 待命"
-
-rules:
-  - "✅ 進入 Phase 6 先讀 loop.json，判斷 auto/manual"
-  - "✅ auto mode + 符合 source → AUTO-APPROVE，記錄 task_id + source，直接進 Phase 7"
-  - "✅ manual mode → 等用戶批准後才建立任務卡"
-  - "✅ 批准後 Phase 7→8 全程自動，不再詢問"
-  - "❌ auto mode 下禁止呼叫 AskUserQuestion — 這會阻塞 headless loop"
-
-checklist:
-  - "已讀取 loop.json，確認當前 mode（auto/manual）"
-  - "用戶已批准建立任務卡（manual mode）或 AUTO-APPROVE 日誌已輸出（auto mode）"
-
-context_hints:
-  input_from: "phase_5"
-  key_data: ["validated_specs"]
-
-inject:
-  rules: []
-  specialist: []

package/core/dev/archive/ansuz/legacy/phases/phase_7.yaml

@@ -1,58 +0,0 @@
-phase: 7
-name: "任務建立"
-goal: "在任務系統中建立 YAML 任務"
-
-system: ".collaboration/core/task-api.js"
-note: "子專案時所有 task-api.js 呼叫必須加 --project-path {PROJECT_PATH}"
-
-actions:
-  - "執行 task-api.js create（見 create_command）"
-  - "執行 task-api.js list 確認建立結果"
-  - "驗證 YAML 文件已建立（task-api.js get TASK_XXX）"
-  - "確認任務狀態已更新（task-api.js list）"
-  - "更新 dev/pipeline/PROGRESS.md — Last Update + Recent Activity（僅 Core 專案）"
-
-quality_gate:
-  requirements_min: 3  # ⚠️ 最少 3 條 requirements，否則 task create 會被拒絕
-  note: "kenaz_task_create MCP 和 task-api.js create 都執行品質檢查：requirements < 3 → 拒絕。必須補齊！"
-
-create_command: |
-  node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] create \
-    --title "任務名稱" \
-    --priority P1 \
-    --role frontend \
-    --rigor medium \
-    --complexity medium \
-    --tags code \
-    --scope-paths "dashboard/src/" \
-    --dependencies TASK_YYY \
-    --feature-ids F-001 \
-    --estimated-hours 4 \
-    --acceptance-criteria "AC 1" --acceptance-criteria "AC 2" \
-    --requirements "需求 1" --requirements "需求 2" --requirements "需求 3"
-
-verify_command: "node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] list"
-
-cli_format: |
-  📦 任務建立
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  ✓ TASK_XXX 已建立 → .collaboration/tasks/backlog/
-  ✓ 任務統計: 待處理 {N} | 進行中 {N} | 已完成 {N}
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-interaction:
-  type: "auto"
-  instruction: "Phase 6 批准後自動建立任務卡，不問"
-
-checklist:
-  - "所有任務已建立（task-api.js list 確認）"
-  - "每個任務已用 task-api.js get 驗證存在"
-  - "PROGRESS.md 已更新（Core 專案）"
-
-context_hints:
-  input_from: "phase_6"
-  key_data: ["approved_specs"]
-
-inject:
-  rules: []
-  specialist: []