kenaz 0.3.22 → 0.3.23

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

@@ -1,146 +0,0 @@
-phase: 8
-name: "陣型判斷 + Dispatch"
-goal: "選擇最輕量可行陣型，dispatch agent 執行"
-
-judgment:
-  principle: "能 unit 不 solo，能 solo 不 squad，能 squad 不 legion"
-  guide:
-    unit: "目標明確、單一 scope → do/think/plan"
-    solo: "需要多角度分析 → strategy/diagnosis"
-    squad: "可拆成獨立子任務並行 → blitz/sweep"
-    legion: "有順序依賴或即時協調 → forge/hive"
-
-execution:
-  tool: ".formation/tools/headless.js"
-  max_parallel: 5
-  cli:
-    unit: "node {CORE}/.formation/tools/headless.js --skill=do --task=TASK_XXX [--project-path {PROJECT_PATH}]"
-    solo: "node {CORE}/.formation/tools/headless.js --formation=solo --skill=strategy --task=TASK_XXX [--project-path {PROJECT_PATH}]"
-    squad: "node {CORE}/.formation/tools/headless.js --formation=squad --skill=blitz --task=TASK_XXX [--project-path {PROJECT_PATH}]"
-    legion: "node {CORE}/.formation/tools/headless.js --formation=legion --skill=forge --task=TASK_XXX [--project-path {PROJECT_PATH}]"
-  patterns:
-    single: "Bash(run_in_background=true): node headless.js --task=TASK_XXX"
-    parallel: "多個無依賴 → 多個 Bash(background) 同時啟動（上限 5，超過排隊）"
-    sequential: "有依賴 → 前一個完成再 dispatch"
-  anti_pattern: "❌ 禁止用 Task tool 直接開 subagent — 繞過 Formation 失去 prompt 組裝和 log"
-  post_dispatch_branch_guard:
-    rule: "每個 dispatch 完成（背景任務通知回來）後，必須立即執行 git checkout {user_branch}"
-    why: "headless.js subprocess 的 post-complete 會 checkout 回 user branch，但 Ansuz 的 shell session 可能不同步（尤其 crash 或 timeout 時）"
-    enforcement: "硬性規則 — 不是建議。漏做 = 後續所有操作在錯誤 branch 上"
-    pattern: |
-      # 每個 dispatch 背景通知回來後，第一個動作：
-      git checkout {user_branch}
-      # 然後才讀 log、驗證結果、dispatch 下一個
-
-scope_rules:
-  - "同檔案 → 一個實例處理整個檔案"
-  - "跨檔案 → fan_out，按模組/目錄切"
-  - "派工前確認 scope 無重疊"
-
-dispatch_decision_gate:
-  rule: |
-    ⚠️ DISPATCH vs IN-SESSION — 必須在每次 dispatch 前判斷：
-    分析 / 審計 / 策略 / 討論     → in-session Skill tool（/Amelia、/Huginn 等），不 dispatch
-    實作 / 執行 / 寫代碼 / 長跑   → headless dispatch（headless.js）
-    「sub agent」「讓 X 做」本身不代表 dispatch。判斷依據是任務性質，不是用詞。
-    長 session（已 dispatch ≥3 個任務）時特別警惕 pattern contamination — 重新確認。
-
-pre_dispatch:
-  - "node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] claim TASK_XXX"
-  - "確認狀態已變為 active"
-  - |
-    # ── Symbol-Level Prediction Recording（TASK_932 升級）──
-    # 對每個即將 dispatch 的任務，在 dispatch 前執行：
-    #
-    # 1. 取得任務的 scope_paths（主要目標檔案/目錄）
-    # 2. 對 scope_paths 中的主要 symbol 執行 kenaz_lsp_callers：
-    #      kenaz_lsp_callers({ symbol: "<primary_symbol>", projectPath: "{PROJECT_PATH}" })
-    # 3. 從 LSP 結果萃取 predicted_symbols（最多 20 個）：
-    #      - callers（呼叫此 symbol 的函數）
-    #      - references（引用此 symbol 的位置）
-    #    合併去重後取前 20 個 symbol name
-    # 4. 將 predicted_symbols 寫入任務 YAML（dispatch 前，作為 TASK_931 比對基線）：
-    #      node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] \
-    #        update TASK_XXX --field predicted_symbols --value "[\"sym_a\",\"sym_b\",...]"
-    #    或用 technical_notes 暫代（若 task-api 尚未支援 --field predicted_symbols）：
-    #      node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] \
-    #        update TASK_XXX --technical-notes "predicted_symbols: [sym_a, sym_b, ...]"
-    #
-    # ⚠️ 若 scope_paths 無明確 symbol（例如整個目錄），以目錄中最核心的檔案名稱作為 symbol 查詢
-    # ⚠️ kenaz_lsp_callers 不可用時 → 跳過此步，在 Phase 9 outcome 中標記 predicted_symbols: []
-    # ⚠️ 此步驟產出的 predicted_symbols 供 Phase 9 / TASK_931 做 symbol-level 比對用
-
-monitoring:
-  tools:
-    - "node {CORE}/.formation/tools/log-reader.js --latest unit --tail 30"
-    - "node {CORE}/.formation/tools/log-reader.js --task TASK_XXX --tail 50"
-  rules:
-    - "❌ 禁止用 TaskOutput 讀取 headless 結果 — stdout 可能數萬行，會爆 context"
-    - "✅ 用 log-reader.js 或 Read tool + offset"
-
-actions:
-  - "根據 judgment.principle 選擇最輕量陣型"
-  - "task-api.js claim → Bash(background): node headless.js --task=TASK_XXX"
-  - "多任務無依賴 → 多個 Bash(background) 同時啟動（上限 5）"
-
-# ═══════════════════════════════════════
-#  Completion Tracking Mandate（強制）
-# ═══════════════════════════════════════
-# Ansuz 作為全生命週期引擎，dispatch 後 MUST 自動跑完 Phase 9-10-11。
-# 不可中途插入「還有其他事嗎？」或等用戶推動。
-completion_tracking:
-  mandate: |
-    ❌ 禁止在 dispatch 後向用戶提問或建議停下來
-    ❌ 禁止輸出「需要我做其他事情嗎？」「還要繼續嗎？」等中斷性問題
-    ✅ dispatch 後靜默等待背景通知（不輸出任何文字直到通知到達）
-    ✅ 通知到達 → 自動 Phase 9 → Phase 10 → 有下一個 task? → Phase 8 → 全完成 → Phase 11
-  on_notification:
-    step_1: "git checkout {user_branch}（branch guard — 硬性規則）"
-    step_2: "讀 log（log-reader.js --task TASK_XXX --tail 50）"
-    step_3: "Phase 9 驗證（自動，不問用戶）"
-    step_4: "Phase 10 post-complete（自動）"
-    step_5: "檢查是否有下一個待 dispatch 的 task（相同需求的 task 列表）"
-    step_5a: "有 → 回 Phase 8 dispatch 下一個（自動）"
-    step_5b: "沒有 → Phase 11 回報（此時才向用戶匯報 + 問下一步）"
-  multi_task_loop: |
-    當 Phase 7 建立了多個任務時，Phase 8 進入 dispatch 迴圈：
-    for task in tasks_sorted_by_dependency:
-      claim → dispatch(background) → 等通知 → branch guard → Phase 9 → Phase 10
-    全部完成 → Phase 11（一次回報所有結果）
-  anti_pattern:
-    - "❌ dispatch 一個就報告 → 等用戶 → dispatch 下一個（transactional 斷裂）"
-    - "❌ 通知到了但問用戶「要追蹤嗎？」（Phase 9 是自動的，不需要許可）"
-    - "❌ 多任務時每個任務分開做 Phase 11（應合併成一次回報）"
-
-cli_format: |
-  🚀 Dispatch
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  TASK_XXX → unit/do（目標明確、單一 scope）
-  TASK_YYY → unit/do（獨立任務、可並行）
-
-  並行: 2 個 headless 進程
-  監控: node {CORE}/.formation/tools/log-reader.js --latest unit --tail 30
-  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-interaction:
-  type: "auto"
-  instruction: "輸出 cli_format 後直接 dispatch，不問用戶。dispatch 後靜默等待通知，自動跑完 Phase 9-10-11。"
-
-checklist:
-  - "⚠️ DISPATCH DECISION GATE: 確認任務性質是「實作/執行」而非「分析/審計/討論」。分析類 → in-session Skill，不 dispatch。長 session 中尤其注意 pattern contamination。"
-  - "陣型已選擇（最輕量原則）"
-  - "所有任務已 claim（active 狀態）+ scope 無重疊"
-  - "⚠️ SYMBOL PREDICTION（dispatch 前必做）: 對每個任務的 scope_paths 執行 kenaz_lsp_callers → 萃取 predicted_symbols（≤20）→ task-api update 寫入任務 YAML"
-  - "dispatch 數量 ≤5"
-  - "cli_format 已輸出後立即執行 Bash(run_in_background=true)"
-  - "⚠️ POST-DISPATCH BRANCH GUARD: 每個背景任務通知回來後，第一個動作必須是 git checkout {user_branch}"
-  - "⚠️ COMPLETION TRACKING: dispatch 後不輸出任何中斷性問題，靜默等通知 → 自動 Phase 9-10-11"
-
-context_hints:
-  input_from: "phase_7"
-  key_data: ["task_ids", "formation_choice", "parallel_groups"]
-
-inject:
-  rules: []
-  specialist: []

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

@@ -1,424 +0,0 @@
-phase: 9
-name: "結果驗證"
-goal: "驗證 agent 產出，確保符合任務要求"
-
-ddx_trigger:
-  when: "agent 輸出不確定、或結果與預期不符時"
-  action: "懶載入 modules/ddx.yaml — 問『如果不是 agent 說的原因，還可能是什麼？』"
-
-# ─────────────────────────────────────────────────────────────────
-# Forseti Verification — Three-Level Automated Verification Engine
-# ─────────────────────────────────────────────────────────────────
-
-forseti_verification:
-  description: |
-    Forseti is a three-level automated verification engine that runs
-    CLI commands (L1), service probes (L2), and Playwright E2E (L3).
-    Dispatch only when task meets trigger threshold — otherwise fall
-    back to minimal_verification.
-
-  trigger_threshold:
-    description: "Forseti is triggered if ANY of the following conditions is true"
-    conditions:
-      - priority is P0 or P1
-      - rigor is "high"
-      - tags contain "fix" or "regression"
-      - task has a non-empty verification spec (verification.level_1 or level_2 or level_3)
-    skip_when:
-      - priority is P2 with rigor "low" or "medium"
-      - priority is P3
-      - task is documentation-only (role: docs, no scope_paths with code files)
-      - task is design/style-only with no logic changes
-
-  dispatch:
-    command: |
-      node {CORE}/.formation/tools/forseti-verify.js \
-        --task=TASK_XXX \
-        [--project-path={PROJECT_PATH}]
-    note: "直接執行 forseti-verify.js，不走 headless.js formation skill"
-    verdict_path: "{PROJECT_PATH}/.formation/logs/forseti/TASK_XXX/verdict.json"
-
-  verdict_handling:
-    read_verdict: |
-      Read verdict JSON from: .formation/logs/forseti/TASK_XXX/verdict.json
-      Fields: overall (PASS|PARTIAL|FAIL), level_results[], evidence_dir, generated_at
-    on_PASS: "→ 繼續正常 on_success 流程 → Phase 10"
-    on_PARTIAL: |
-      ⚠️ Partial verification (some levels skipped — service offline or no E2E spec)
-      → PARTIAL is NOT automatic success. Map every required acceptance criterion to passing evidence.
-      → Continue on_success only when all required checks passed and every skipped check is
-        explicitly optional or not applicable, with a recorded reason. Keep the raw verdict PARTIAL.
-      → Missing spec, unavailable service, or missing evidence for any required check → UNVERIFIED.
-        Do not downgrade a required check to optional merely because it cannot run.
-    on_UNVERIFIED: |
-      Record missing required checks and the blocking condition; keep the task open.
-      Restore the prerequisite or supplement the verification plan and rerun.
-      Do not call on_success, complete, archive, or merge based on missing evidence.
-      UNVERIFIED is an Ansuz assessment, not a new Forseti CLI verdict or task status.
-    on_FAIL: |
-      ❌ Forseti reported FAIL → 觸發 FIX 閉環
-      → 執行 fix_loop 流程（見下方）
-
-  fix_loop:
-    description: "FAIL 閉環：建 FIX 任務 → 回 Phase 8 → Forseti 再驗。max 3 輪防無限迴圈。"
-    max_fix_rounds: 3
-    loop_guard: |
-      在 task context 中追蹤 fix_round（從 technical_notes.fix_round 讀取，預設 0）
-      if fix_round >= max_fix_rounds:
-        → 停止自動建 FIX
-        → escalate 給用戶，附上全部 verdict evidence
-    steps:
-      1_read_evidence: |
-        讀取 verdict JSON 中的 level_results[].failures 和 evidence_dir
-        提取失敗命令、exit codes、stdout/stderr（各取前 1000 chars）
-      2_create_fix_task: |
-        node {CORE}/.collaboration/core/task-api.js \
-          [--project-path {PROJECT_PATH}] create \
-          --title "[FIX] {原任務標題} — Forseti L{N} FAIL" \
-          --source=TASK_XXX \
-          --tags="fix,verification,forseti" \
-          --priority={原任務 priority} \
-          --role={原任務 role} \
-          --scope_paths={原任務 scope_paths}
-        context 欄位必須包含：
-          - forseti_evidence: {verdict JSON 完整路徑}
-          - fix_round: {current_round + 1}
-          - failure_summary: {level_results failures 摘要}
-          - original_task_id: TASK_XXX
-      3_update_anchor: |
-        Read-modify-write ansuz_motivational_state.json (graceful degradation):
-          file: {PROJECT_PATH}/.kenaz/ansuz_motivational_state.json
-          if file not found → skip silently, continue to next step
-          match_logic: FIX_task.tags ∩ anchor.source_tags — OR logic (any tag overlap = match)
-            note: anchor.source_tags must contain domain-specific tags only (e.g. tunnel, pty, synapse).
-              Generic tags like "fix", "code", "feature" must NOT be in source_tags — they cause all anchors to match.
-          on_match:
-            if anchor.resolved === true:
-              resolved = false
-              resolved_at = null
-              incompleteness = 0.3  ← problem recurred; reset base before increment
-            incompleteness = min(anchor.incompleteness + 0.15, 1.0)
-              note: resolved anchor starts at 0.3 → +0.15 = 0.45 total
-            fix_cycle_count = anchor.fix_cycle_count + 1
-            last_touched = today (ISO8601 date, YYYY-MM-DD)
-          on_no_match → create new anchor:
-            concept = FIX task title stripped of '[FIX] ' prefix, truncated to 50 chars
-            source_tags = FIX task tags (array)
-            incompleteness = 0.3
-            fix_cycle_count = 1
-            last_touched = today (ISO8601 date)
-          write_back:
-            update anchors[] with the matched/new anchor
-            session_count = session_count + 1
-            last_updated = ISO8601 datetime now
-            preserve personality_seed unchanged
-            on IO error / file lock → skip silently, do NOT abort fix_loop
-      4_preserve_original: |
-        Keep the original task open and link the FIX task and failed evidence.
-        Creating a FIX task does not satisfy the original acceptance criteria.
-        Only after the FIX is verified, rerun the original required checks and
-        complete the original through the normal authorized completion lifecycle.
-      5_dispatch_fix: |
-        ⚠️ 立即回到 Phase 8 dispatch FIX 任務，不可停在 backlog
-        → Phase 8(FIX) → dispatch → Phase 9(FIX) → Forseti 再驗
-        Only verified tasks may proceed to authorized post-complete archive + git.
-    escalate_when: |
-      fix_round >= max_fix_rounds:
-        ❌ 自動修復已達上限（{max_fix_rounds} 輪）
-        → 停止迴圈，升級給用戶
-        輸出：
-          - 所有 verdict JSON 路徑
-          - 每輪失敗摘要
-          - 建議：人工介入或換策略
-
-# ─────────────────────────────────────────────────────────────────
-# Minimal Verification — For tasks that skip Forseti
-# ─────────────────────────────────────────────────────────────────
-
-minimal_verification:
-  description: |
-    When task does NOT meet Forseti trigger threshold, run applicable local
-    checks from the owning package and task acceptance criteria. Compilation,
-    typechecking, lint and grep do not prove changed runtime behavior.
-    Record concrete commands, working directories, exit codes and evidence.
-    If acceptance requires a service or E2E check, it remains required even on
-    this path; do not waive it because the task was routed to minimal verification.
-  when: "Forseti trigger_threshold NOT met"
-  checks:
-    rust_project: |
-      if scope_paths contain .rs files:
-        Resolve the owning Cargo.toml within PROJECT_PATH; run cargo check with
-        that manifest and relevant tests covering changed behavior.
-    typescript_project: |
-      if scope_paths contain .ts or .tsx files:
-        Resolve the owning package and tsconfig; run its installed typechecker
-        and relevant behavioral tests. Do not assume the repository root owns
-        the code or that typechecking alone meets behavioral acceptance criteria.
-    javascript_project: |
-      if scope_paths contain .js, .jsx, .mjs or .cjs files:
-        Resolve the owning package.json, test configuration and concrete tests.
-        Run the existing configured test runner with the relevant test targets.
-        For node:test suites, use node --test <explicit test paths>; for Jest,
-        Vitest or another runner use the installed project runner and its config.
-        Do not invent an npm test script, install packages automatically, or use
-        syntax-only checks as behavioral proof. Missing runner/tests → UNVERIFIED
-        until equivalent executable acceptance evidence exists or tests are added.
-    documentation_only: |
-      Only when scope contains no executable code or behavior-bearing config:
-        Check diff/scope, referenced paths and links, and document consistency.
-        For YAML policy/config changes, parse the file and check relevant contract
-        invariants; text checks verify policy consistency, not agent compliance.
-        Behavior-bearing configuration additionally needs applicable behavior checks.
-    fallback: |
-      For other executable artifacts, select the owning toolchain's relevant checks.
-      If required checks cannot be identified or run, record UNVERIFIED, not PASS.
-      For mixed scopes, run every applicable branch; do not stop at the first match.
-      Only optional/not-applicable checks may be skipped, with a recorded reason.
-  on_FAIL: "→ 同 on_failure 流程（retry / create_fix / escalate）"
-  on_UNVERIFIED: "Keep task open; report missing required evidence, supplement checks or restore prerequisites; no on_success/complete/archive/merge."
-  on_PASS: "Only when every required acceptance criterion has passing evidence → on_success → authorized Phase 10."
-
-# ─────────────────────────────────────────────────────────────────
-# Standard Verification Actions
-# ─────────────────────────────────────────────────────────────────
-
-actions:
-  - "檔案變更符合任務 scope_paths？"
-  - "git commit 存在？（git log --oneline | grep TASK_XXX）"
-  - "acceptance_criteria 全部滿足？"
-  - "交叉比對原始碼 — 不盲信 agent 輸出"
-  - "kenaz_lsp_callers — 分析變更的影響範圍"
-  - "無引入 regression？"
-  - |
-    DIFF-ISOLATION verification (derived from VC33 session insight):
-    Run `git diff {BASE_COMMIT}...{TASK_BRANCH} -- {file_path}` per scope_path file
-    to isolate agent's actual changes from file noise. Use this BEFORE full-file
-    re-read — diff-based verification is cheaper (O(Δ) vs O(file)) and catches
-    silent deletions/reverts that grep alone misses. If diff for any requirement-
-    named file is empty when it should not be → INCOMPLETE → create FIX task.
-  - |
-    phantom reconciliation check（若任務 technical_notes 含 phantom_ids）:
-      1. parse phantom_ids from task YAML technical_notes
-      2. for each phantom_id:
-           check: kenaz_lsp_symbols / Grep 該 symbol 是否已出現在預定檔案
-           reconciled: 已出現在預定位置
-           pending:    找不到 → ⚠️ agent 可能未在預定位置寫入代碼
-      3. 無 phantom_ids → skipped
-      note: post-complete.js 已觸發 reindex，reconcile_phantom 應已自動執行
-
-cognitive_checkpoint:
-  rule: "驗證完成後，必須判斷是否需要 inscribe。不可跳過此判斷"
-  check: |
-    - bug 根因 non-obvious？ → inscribe type=fix
-    - 隱藏 side-effect 或使用限制？ → inscribe type=risk
-    - 非顯然的設計決策？ → inscribe type=decision
-    - 跨 3+ symbol 的概念？ → forge Sigil
-    - 以上都沒有 → 跳過，不為了寫而寫
-  verify_runes: "agent 寫了 rune → 交叉比對原始碼；不準確的 rune 用 supersedes 取代"
-  mem0_protocol:
-    description: "Mem0-style ADD/MERGE/DELETE protocol for session insights (TASK_940)"
-    trigger: "Before inscribing any rune, execute this protocol"
-
-    # ─── Step 0: Rule-level recall (ansuz_rules.yaml) ───
-    # Before inscribing a rune, check if a behavioral RULE already covers this insight.
-    # If a rule exists, rune inscription is redundant — skip or reference the rule instead.
-    rule_recall:
-      file: "{PROJECT_PATH}/.kenaz/specialist/ansuz_rules.yaml"
-      steps:
-        - |
-          0a. READ ansuz_rules.yaml → parse rules[] array
-        - |
-          0b. For each rule where status is "active" or "proposed":
-              Compare semantically: does this rule already cover the insight you are about to inscribe?
-              - YES (>70% overlap with active rule) → SKIP inscription entirely.
-                The rule is authoritative; a rune would be redundant.
-              - YES (>70% overlap with proposed rule) → SKIP inscription.
-                Instead, note the rule_id for Phase 11 sessions_observed increment.
-              - PARTIAL overlap → Proceed to rune inscription, but reference the rule_id
-                in the rune's related_rune_ids or context field.
-              - NO overlap → Proceed to standard rune recall (Step 1 below).
-        - |
-          0c. If ansuz_rules.yaml is unreadable or missing → skip rule recall,
-              proceed to standard rune recall. Do NOT abort.
-
-    # ─── Steps 1-6: Rune-level recall and inscription ───
-    steps:
-      - |
-        1. RECALL: synapse_recall(query=<insight topic>, limit=5, projectPath=PROJECT_PATH)
-           Find existing runes on the same symbol or concept.
-      - |
-        2. EVALUATE overlap:
-           - If existing rune covers >70% of the same insight → MERGE
-           - If existing rune contradicts the new insight → FLAG for review
-           - If no relevant runes exist → ADD as new
-           - If new evidence invalidates an existing rune → DELETE (supersede)
-      - |
-        3. MERGE: synapse_inscribe(... supersedes=<old_rune_id>, related_rune_ids=[<old_rune_id>])
-           Combine content from both runes. Increment confidence if corroborated.
-      - |
-        4. FLAG contradiction: inscribe new rune with type=risk, content includes
-           "CONTRADICTION with rune {old_rune_id}: {description}".
-           Do NOT auto-delete the old rune — let deliberate review decide.
-      - |
-        5. ADD: synapse_inscribe(... confidence >= 0.6) as normal.
-      - |
-        6. DELETE: synapse_inscribe(... supersedes=<invalidated_rune_id>,
-           content="INVALIDATED: {reason}"). The old rune is excluded from future recall.
-    rules:
-      - "Always recall before inscribing — duplicates waste recall bandwidth"
-      - "Overlap is semantic, not literal — two runes about the same concept count even if worded differently"
-      - "Rule-level recall (Step 0) takes precedence — if a rule covers the insight, do not create a redundant rune"
-      - "MEM-LANG-001 applies — all inscribe content in English"
-  phantom_reconciled: |
-    parse phantom_ids from task YAML technical_notes
-    for each phantom_id:
-      check: kenaz_lsp_symbols / Grep for the symbol at the intended file
-      reconciled: symbol present at intended location → ✅ verified
-      pending:    symbol not found                    → ⚠️ agent may not have written code at intended location
-    no phantom_ids: skipped
-
-  self_reflection_detection:
-    description: "Detect moments during task execution that warrant a self-model update in Phase 11"
-    rule: "Only flag when trigger is concrete and evidenced — do not flag speculatively"
-    triggers:
-      user_correction:
-        detect: "User explicitly corrects agent behavior, judgment, or output during this session"
-        example: "User says 'no, don't do that', overrides agent's decision, or points out a systematic mistake"
-        flag_type: "user_correction"
-      decision_surprise:
-        detect: "Outcome of an agent decision differs significantly from the agent's own expectation"
-        example: "Agent predicted approach X would work; actual result revealed a flawed assumption"
-        flag_type: "decision_surprise"
-      principle_conflict:
-        detect: "Agent action contradicted a stated principle or known tendency in its own self-model"
-        example: "Agent skipped cognitive checkpoint despite B-001 naming exactly this blind spot"
-        flag_type: "principle_conflict"
-      first_time_encounter:
-        detect: "Agent encounters a pattern, constraint, or domain it has not handled before"
-        example: "New cross-language coupling pattern not previously observed in any tendency entry"
-        flag_type: "first_time_encounter"
-      new_observation_category:
-        detect: "Agent observes a behavioral pattern about itself that does not fit any existing tendencies[], blind_spots[], or growth_edges[] category"
-        example: "Agent notices it consistently front-loads verification steps before writing code — this is a distinct pattern not yet in tendencies"
-        flag_type: "new_observation_category"
-    output:
-      variable: "self_reflection_flags"
-      schema: "list of {type: string, description: string, evidence: string}"
-      note: "Empty list if no triggers fire. Non-empty list is passed to Phase 11 self_reflection_protocol."
-
-outcome_comparison:
-  description: |
-    After verification passes, compare Phase 3 predictions with actual outcomes.
-    Computes surprise_score and valence, updates cumulative accuracy stats,
-    and injects high-surprise events as outcome neurons into Thalamus.
-  trigger: "on_success — after task verification passes"
-  note: "Actual comparison logic lives in post-complete.js (compareOutcomePrediction). Phase 9 triggers it conceptually; post-complete executes it."
-  metrics:
-    surprise_score: |
-      Normalized Jaccard distance between predicted files and actual files:
-        intersection = predicted ∩ actual
-        union = predicted ∪ actual
-        surprise_score = 1 - (|intersection| / |union|)
-      Range: 0.0 (perfect prediction) to 1.0 (complete miss)
-    valence: |
-      positive: actual outcome succeeded and surprise_score < 0.3
-      negative: actual outcome failed OR surprise_score >= 0.5
-      neutral: otherwise
-  accuracy_tracking:
-    file: "{PROJECT_PATH}/.kenaz/specialist/ansuz_accuracy.json"
-    schema: |
-      {
-        "total_predictions": N,
-        "accurate_predictions": N,      // surprise_score < 0.3
-        "running_accuracy": 0.0-1.0,    // accurate / total
-        "last_updated": "ISO-8601",
-        "recent_surprises": [            // last 10 high-surprise events
-          { "task_id": "TASK_XXX", "surprise_score": 0.8, "valence": "negative", "timestamp": "ISO-8601" }
-        ]
-      }
-prevention_analysis:
-  when: "任務 P0/P1，或 fix/regression，或核心路徑"
-  action: "懶載入 modules/prevention.yaml — 三級預防分析"
-  skip_when: "P2/P3 新功能、文件/設計任務、typo/style 修復"
-
-loop_guard:
-  when: "同一 source/feature_id 的 FIX 任務累計 >= 2 次"
-  action: "懶載入 modules/loop_guard.yaml — 強制 Socratic Thinking，暫停 dispatch"
-
-on_success:
-  - "node {CORE}/.collaboration/core/task-api.js [--project-path {PROJECT_PATH}] complete TASK_XXX"
-  - |
-    anchor_decay (graceful degradation):
-      file: {PROJECT_PATH}/.kenaz/ansuz_motivational_state.json
-      if file not found → skip silently
-      match_logic: task.tags ∩ anchor.source_tags — OR logic (any tag overlap = match)
-        same matching strategy as FIX path (fix_loop.3_update_anchor)
-        note: anchor.source_tags must contain domain-specific tags only — see fix_loop.3_update_anchor note.
-      decay: incompleteness = max(anchor.incompleteness - 0.05, 0.0)
-      write_back:
-        update matched anchors[]
-        session_count = session_count + 1
-        last_updated = ISO8601 datetime now
-        preserve personality_seed unchanged
-        on IO error / file lock → skip silently, do NOT abort on_success
-  - "→ 觸發 prevention_analysis（如符合條件）→ Phase 10"
-
-on_failure:
-  analysis:
-    - "讀 log 找失敗根因"
-    - "判斷：可重試 | 需補 context | 需建 FIX | 需換策略 | 需升級"
-  actions:
-    retry: "重派同任務 — 補充失敗原因和缺失 context"
-    create_fix_and_dispatch: |
-      1. task-api.js create 建立 [FIX] 任務（tags: fix,verification）
-      2. Keep the original task open; link the FIX task and failed evidence.
-      3. Do not complete/archive the original until the FIX passes and the original
-         required acceptance checks are rerun successfully through the authorized lifecycle.
-      4. ⚠️ 立即回到 Phase 8 dispatch FIX — 不可停在 backlog
-    change_strategy: "換陣型（如 unit → solo 增加分析深度）"
-    escalate: "升級給用戶 — 附上已嘗試的方法和失敗原因"
-    block: "node {CORE}/.collaboration/core/task-api.js --project-path={PROJECT_PATH} move TASK_XXX blocked"
-  critical_rule: "⚠️ 建完 FIX 後「必須」立即 dispatch。Phase 9 → 建 FIX → Phase 8(FIX) → dispatch → Phase 9(FIX) → ..."
-
-cli_format:
-  success: |
-    ✅ TASK_XXX 驗證通過
-    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-    變更: {檔案清單}
-    Commit: {commit hash}
-    驗收: {N}/{N} 通過
-    Forseti: {PASS|PARTIAL|SKIPPED}
-    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  failure: |
-    ❌ TASK_XXX 驗證失敗
-    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-    根因: {分析結果}
-    Forseti: {FAIL — level_results 摘要}
-    行動: {重派/建FIX並dispatch/換策略/升級}
-    FIX Round: {N}/{max_fix_rounds}
-    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  unverified: |
-    ⚠️ TASK_XXX 尚未驗證完成 (UNVERIFIED)
-    Required checks missing: {checks_and_reasons}
-    Raw Forseti verdict: {verdict_or_not_run}
-    Next action: {restore_prerequisite_or_supplement_checks}
-    Task remains open; this is not a successful completion.
-
-interaction:
-  type: "auto"
-  instruction: "自動執行，結果併入 Phase 11。若建 FIX 任務，必須迴圈回 Phase 8 dispatch，不可停在 backlog"
-
-checklist:
-  - "acceptance_criteria 全部驗證（逐條核對）"
-  - "git commit 存在且對應 TASK_XXX"
-  - "forseti_verification 觸發判斷已完成（觸發 Forseti 或執行 minimal_verification）"
-  - "cognitive_checkpoint 已判斷（inscribe 或明確跳過）"
-
-context_hints:
-  input_from: "phase_8"
-  key_data: ["dispatched_tasks", "expected_branches"]
-
-inject:
-  rules:
-    - synapse-cognitive-fusion.yaml
-  specialist: []

package/core/dev/archive/ansuz/specs/INDEX_bifrost_hook_parity.yaml

@@ -1,92 +0,0 @@
-index_version: "1.0"
-series: "Bifrost Hook Parity Task Series"
-produced_by: TASK_1234
-architecture_source: ".formation/bifrost/CGDD_hook_lifecycle.js"
-
-# ─────────────────────────────────────────────────────────────────
-# CRITICAL: CGDD task number labels are WRONG
-# ─────────────────────────────────────────────────────────────────
-cgdd_number_mismatch: >
-  CGDD_hook_lifecycle.js was written before backlog was finalized. The task numbers
-  inside CGDD (TASK_1228 = SessionStart, TASK_1229 = UserPromptSubmit, etc.) do NOT
-  match actual backlog assignments. Use this index, not the CGDD task labels.
-
-# ─────────────────────────────────────────────────────────────────
-# TASK BRIEFS
-# ─────────────────────────────────────────────────────────────────
-tasks:
-  TASK_1228:
-    brief: ".specialist/Ansuz/specs/brief_TASK_1228_userpromptsubmit.yaml"
-    event: UserPromptSubmit
-    file: ".formation/bifrost/session.js"
-    creates: "dispatchBifrostHook() + normalizeUserPromptSubmit()"
-    parallel_with: [TASK_1229]
-    blocks: [TASK_1230, TASK_1231]
-
-  TASK_1229:
-    brief: ".specialist/Ansuz/specs/brief_TASK_1229_pretooluse_posttooluse.yaml"
-    events: [PreToolUse, PostToolUse]
-    file: ".formation/bifrost/openai/relay.js"
-    creates: "relay.js dispatchBifrostHook() + capturedThreadId + normalizeToolEvent() + 8 call sites"
-    parallel_with: [TASK_1228, TASK_1230]
-    blocks: [TASK_1231]
-
-  TASK_1230:
-    brief: ".specialist/Ansuz/specs/brief_TASK_1230_sessionstart_stop.yaml"
-    events: [SessionStart, Stop]
-    file: ".formation/bifrost/session.js"
-    creates: "normalizeSessionStart() + normalizeStop() + sessionStartedAt + resultCapture + stdout tee"
-    prerequisite: TASK_1228  # needs dispatchBifrostHook to exist
-    parallel_with: [TASK_1229]
-    blocks: [TASK_1231]
-
-  TASK_1231:
-    brief: ".specialist/Ansuz/specs/brief_TASK_1231_verification.yaml"
-    role: verification_gate
-    produces: ".formation/bifrost/VERIFICATION_hook_parity.md"
-    prerequisites: [TASK_1228, TASK_1229, TASK_1230]
-    no_code_changes: true
-
-# ─────────────────────────────────────────────────────────────────
-# RECOMMENDED DISPATCH ORDER
-# ─────────────────────────────────────────────────────────────────
-dispatch_order:
-  wave_1:
-    tasks: [TASK_1228, TASK_1229]
-    note: "TASK_1228 and TASK_1229 touch different files — safe to dispatch in parallel"
-  wave_2:
-    tasks: [TASK_1230]
-    note: "Depends on TASK_1228 (dispatchBifrostHook must exist in session.js)"
-  wave_3:
-    tasks: [TASK_1231]
-    note: "Verification gate — all three implementation tasks must be done first"
-
-# ─────────────────────────────────────────────────────────────────
-# EVENT → FILE OWNERSHIP QUICK REFERENCE
-# ─────────────────────────────────────────────────────────────────
-event_ownership:
-  SessionStart:
-    dispatcher: ".formation/bifrost/session.js::normalizeSessionStart()"
-    consumer: ".specialist/tools/task-bridge.js::handleHookEvent() → no-op"
-  UserPromptSubmit:
-    dispatcher: ".formation/bifrost/session.js::normalizeUserPromptSubmit()"
-    consumer: ".specialist/tools/task-bridge.js::handleHookEvent() → maybeEmitReminder() [EXISTING]"
-  PreToolUse:
-    dispatcher: ".formation/bifrost/openai/relay.js::normalizeToolEvent()"
-    consumer: ".specialist/tools/task-bridge.js::handleHookEvent() → no-op"
-  PostToolUse:
-    dispatcher: ".formation/bifrost/openai/relay.js::normalizeToolEvent()"
-    consumer: ".specialist/tools/task-bridge.js::handleHookEvent() → createLinked/syncStatus [EXISTING]"
-  Stop:
-    dispatcher: ".formation/bifrost/session.js::normalizeStop()"
-    consumer: ".specialist/tools/task-bridge.js::handleHookEvent() → no-op"
-
-# ─────────────────────────────────────────────────────────────────
-# SHARED UTILITY
-# ─────────────────────────────────────────────────────────────────
-shared_utility:
-  dispatchBifrostHook:
-    exists_in: [session.js, relay.js]
-    note: "Two separate implementations — same pattern, different require paths. session.js version created by TASK_1228. relay.js version created by TASK_1229."
-    session_require: "path.resolve(__dirname, '../..', '.specialist/tools/task-bridge.js')"
-    relay_require: "path.resolve(__dirname, '../../..', '.specialist/tools/task-bridge.js')"