kenaz 0.3.9 → 0.3.11

package/core/.rule/general/memory-source-priority.yaml

@@ -1,207 +0,0 @@
-# .rule/general/memory-source-priority.yaml
-# Memory Source Priority and Recall Trigger Rules (TASK_1077)
-#
-# Formalizes the deterministic priority ordering and mandatory trigger points
-# for specialist memory recall. Prevents the "last-source-wins" silent failure
-# mode where overlapping claims from different memory layers are resolved by
-# load order rather than evidence quality.
-#
-# Priority: This rule applies to all specialists (Ansuz, Amelia, Huginn)
-#           that use the memory stack (Synapse + Hippocampus + Handoff).
-# Conflicts: This rule supersedes ad-hoc recall decisions in phase files.
-#            Phase files may define WHEN to recall; this file defines
-#            HOW to arbitrate when sources disagree.
-
-_meta:
-  category: "general"
-  priority: 1
-  applies_to:
-    - "ai_agent"
-    - "ansuz"
-    - "amelia"
-    - "huginn"
-  last_updated: "2026-04-11"
-  created_by: "TASK_1077 — Memory source priority and trigger map"
-  contract_file: ".kenaz/specialist/memory_source_priority.yaml"
-  trigger_map: ".specialist/tools/MEMORY_RECALL_TRIGGERS.md"
-
-rules:
-
-  # =============================================================================
-  # MSP-001: Priority Ordering is Mandatory
-  # =============================================================================
-  - id: "MSP-001"
-    title: "Memory source priority ordering must be applied at every conflict"
-    description: |
-      When two or more recalled items address the same topic (symbol, file, or
-      decision), the agent MUST resolve the conflict using the priority order
-      defined in `.kenaz/specialist/memory_source_priority.yaml`.
-
-      Priority order (high → low):
-        100  user_session_context     (current conversation — beats all)
-         90  verified_decision_rune   (shipped architectural commitments)
-         80  session_handoff          (uncommitted work from prior session)
-         70  self_model_lesson        (identity-layer learning)
-         60  risk_or_fix_rune         (active risk warnings and fixes)
-         50  sigil                    (architectural patterns, general)
-         40  insight_or_pattern_rune  (observations)
-         30  episode                  (raw narrative)
-         20  summary_or_ash_rune      (distilled principles)
-         10  lesson_guard             (advisory checklist, already surfaced by phase-gate)
-
-      Silent "last source wins" is a violation of this rule.
-    severity: "must"
-    rationale: |
-      Without explicit ordering, the agent silently prefers whichever source
-      happened to load last. This produces non-deterministic decisions that
-      cannot be reviewed or debugged. Deterministic ordering makes
-      disagreements visible and auditable.
-    test: |
-      Given two recalled items on the same topic, can the agent name the winning
-      source, its priority_rank, and the conflict_mode applied?
-      YES → compliant. NO → violation.
-
-  # =============================================================================
-  # MSP-002: Conflict Mode Must Be Honoured
-  # =============================================================================
-  - id: "MSP-002"
-    title: "strict vs advisory conflict modes must be applied as specified"
-    description: |
-      Each source type has a conflict_mode in memory_source_priority.yaml:
-        - strict:    highest-priority item wins; competing view hidden from agent
-                     but logged with conflict_with: <winner_id>
-        - advisory:  highest-priority item wins; competing view surfaced to agent
-                     labelled as "competing view (rank: N)"
-
-      Agents must NOT:
-        - apply advisory mode to a strict-mode source
-        - apply strict mode when the source specifies advisory
-        - silently ignore either the winner or the loser
-
-      Overriding a strict-mode winner requires an explicit user statement in the
-      current session (user_session_context, rank 100).
-    severity: "must"
-    rationale: |
-      Strict mode exists precisely for risk/fix runes: an agent that surfaces a
-      risk warning as a "competing view" invites rationalizing it away. Advisory
-      mode exists for cases where nuance matters more than uniformity.
-    test: |
-      When a risk_or_fix_rune (strict) conflicts with an episode (advisory),
-      does the agent follow the rune without showing the episode as an option?
-      YES (unless user overrides) → compliant.
-
-  # =============================================================================
-  # MSP-003: Required Recall Triggers Must Fire
-  # =============================================================================
-  - id: "MSP-003"
-    title: "Required recall triggers must execute at their specified phase boundary"
-    description: |
-      The following triggers are non-optional; skipping them requires an explicit
-      documented reason (analogous to CANARY_CHECK — "SKIP — reason"):
-
-      Phase 0 (Boot):
-        - cortex_recall(type=ash, limit=5) → load ash runes
-        - synapse_sigils(projectPath) → load sigils
-        - Read ansuz_self_model.json → load self_model_lesson
-
-      Phase 1 (Requirements):
-        - synapse_recall(query=task_title+scope_keywords) → check rune history
-
-      Before editing a non-trivial symbol (> 5 lines, non-config):
-        - synapse_recall(symbol_name) → check risk/fix runes; kenaz_lsp_references(symbol_name) → check blast radius
-
-      Phase 3 (Decomposition):
-        - kenaz_lsp_references on the key scope symbols → check blast radius; synapse_recall(scope keywords) → check risk runes
-
-      Phase 9 (Verification):
-        - synapse_recall on touched symbols → check risk runes post-edit
-
-      Phase-gate blocked exit:
-        - lesson_guards auto-surfaced by phase-gate.js (agent does NOT need to call manually)
-
-      Optional (conditional):
-        - session_handoff: load only if a per-session slot exists under
-          .kenaz/specialist/handoffs/ (latest generated_at wins; resolved via
-          handoff-resolver readLatestHandoff — the legacy singular
-          ansuz_session_handoff.json is retired read-only fallback, M3/TASK_1760)
-          AND its generated_at is within ttl_hours: 72
-        - episode: load at Phase 0 if hippocampus_episode_recall returns ≥ 1 result;
-          at Phase 1 if relevant task_id appears in Phase 0 summary
-    severity: "must"
-    rationale: |
-      FAIL-009 records cases where the pre-edit impact check was skipped under time pressure
-      and caused regressions. Required triggers exist because their decision-point
-      value is unconditional — the question is not "might this matter?" but "this
-      always matters."
-    test: |
-      Did the agent fire cortex_recall(ash) and synapse_sigils during Phase 0?
-      Did it call synapse_recall (and check kenaz_lsp_references) before modifying a non-trivial symbol?
-      YES → compliant. NO → violation (must state SKIP reason if consciously skipping).
-
-  # =============================================================================
-  # MSP-004: TTL Violations Must Be Caught at Load Time
-  # =============================================================================
-  - id: "MSP-004"
-    title: "Expired memory items must not be used as primary evidence"
-    description: |
-      Each source type has a TTL (time-to-live):
-        user_session_context:    24h
-        verified_decision_rune:  180 days
-        session_handoff:          72h
-        self_model_lesson:       365 days
-        risk_or_fix_rune:         90 days
-        sigil:                   180 days
-        insight_or_pattern_rune:  90 days
-        episode:                  30 days
-        summary_or_ash_rune:      45 days
-        lesson_guard:            180 days
-
-      An item past its TTL:
-        - MAY be shown to the agent as background context
-        - MUST NOT be treated as primary evidence for a current decision
-        - MUST be labelled as "expired (N days old)" when shown
-
-      TTL expiration does NOT mean the information is wrong — it means
-      the information has not been refreshed and may be stale relative
-      to current code. The agent should re-verify before acting on it.
-    severity: "should"
-    rationale: |
-      A 90-day-old risk rune may have been resolved by a later fix. A 72h+
-      handoff describes a session context that is no longer the active cycle.
-      TTLs prevent stale guidance from silently overriding fresh evidence.
-    test: |
-      Does the agent check freshness_seconds against source TTL before
-      treating a recalled item as primary evidence?
-      YES → compliant. Stale item used without staleness label → violation.
-
-  # =============================================================================
-  # MSP-005: Conflict Audit Trail Must Exist
-  # =============================================================================
-  - id: "MSP-005"
-    title: "Conflict arbitration outcomes must be traceable"
-    description: |
-      When a conflict is resolved (winner selected over loser), the losing
-      item must be recorded in a way that can be audited later:
-        - In strict mode: log conflict_with: <winner_source_id> to the event log
-        - In advisory mode: surface the competing view in agent output so the
-          user can observe that a conflict existed and how it was resolved
-
-      Silent conflict resolution — where the agent picks a winner and shows
-      nothing about the loser — is a violation of this rule, even in strict mode
-      (the log entry must still exist).
-
-      Instrumentation: .specialist/tools/memory-action-log.js (TASK_1072)
-      exposes `recordConflict()` for this purpose. If unavailable, a plain
-      in-response note is sufficient — the key is that the conflict is visible.
-    severity: "should"
-    rationale: |
-      Without an audit trail, post-hoc review cannot determine whether a bad
-      decision was caused by wrong priority ordering, wrong source data, or
-      correct reasoning from correct data. The audit trail makes the arbitration
-      falsifiable.
-    test: |
-      After a conflict resolution event, can a reviewer identify:
-        (a) which sources conflicted?
-        (b) which won and why (priority_rank + conflict_mode)?
-        (c) what happened to the loser?
-      ALL YES → compliant. Any NO → violation.

package/core/.rule/general/synapse-cognitive-fusion.yaml

@@ -1,301 +0,0 @@
-# .rule/general/synapse-cognitive-fusion.yaml
-# Synapse 認知融合洞察 — Agent 在工作過程中主動識別 Rune/Sigil 融合時機
-# 優先級：此規則凌駕於 CLAUDE.md 和 .claude/skills/ 中的定義
-# 前置依賴：SYN-001（可用性偵測）、SYN-007（認知層基本規則）
-
-_meta:
-  category: "general"
-  priority: 1
-  applies_to:
-    - "ai_agent"
-  last_updated: "2026-03-15"
-  depends_on: ["SYN-001", "SYN-007"]
-
-rules:
-  # =============================================================================
-  # SYN-008: 認知融合洞察（Cognitive Fusion Awareness）
-  # =============================================================================
-  - id: "SYN-008"
-    title: "認知融合洞察"
-    description: |
-      所有 Agent 在工作過程中必須保持「認知雷達」開啟。
-      不是做完才想「要不要寫 rune」，而是工作中持續偵測融合時機。
-      原則：稀缺但不遲鈍 — 不為寫而寫，但發現值得的瞬間不能錯過。
-    severity: "should"
-
-    # ─────────────────────────────────────────────────
-    #  認知雷達：6 種融合信號
-    # ─────────────────────────────────────────────────
-    #  工作中遇到這些信號時，暫停 0.5 秒評估是否值得融合。
-    #  不是 checklist — 是持續運行的背景偵測。
-
-    cognitive_radar:
-      signals:
-        - id: "surprise"
-          name: "意外發現"
-          description: "代碼行為與預期不符、隱藏的 side-effect、非直覺的設計"
-          examples:
-            - "這個函數看起來是 pure，但內部修改了全域狀態"
-            - "刪除這個「無用」的 import 會導致 side-effect 消失"
-            - "這個 timeout 不是 bug，是故意的 race condition workaround"
-          action: "→ inscribe type=risk 或 type=insight"
-
-        - id: "pain_point"
-          name: "反覆踩坑"
-          description: "同一個區域、同一種錯誤模式，已經或即將被多次觸發"
-          examples:
-            - "第二次在這個模組遇到序列化問題"
-            - "這個 API 的錯誤處理每次都被忘記"
-            - "這個 config 的預設值在 dev/prod 不同，每次部署都出問題"
-          action: "→ inscribe type=fix 或 type=pattern（標記反覆出錯的模式）"
-
-        - id: "design_fork"
-          name: "設計分歧點"
-          description: "面對 2+ 方案做出了非顯然的選擇，且理由不在代碼中"
-          examples:
-            - "選了 polling 而非 WebSocket — 因為後端不支援長連接"
-            - "用了 SQLite WAL 而非 default journal — 因為需要併發讀"
-            - "不用 ORM 直接寫 SQL — 因為 KuzuDB 的 Cypher 沒有 ORM"
-          action: "→ inscribe type=decision（記錄選擇和理由）"
-
-        - id: "cross_boundary"
-          name: "跨模組洞察"
-          description: "發現 3+ 個 symbol 共同構成一個未命名的概念或流程"
-          examples:
-            - "scanner → indexer → graph_builder 構成 'synapse indexing pipeline'"
-            - "auth_middleware → session_store → token_refresh 構成 'auth flow'"
-            - "dispatch → prompt_assembly → log_writer 構成 'formation execution'"
-          action: "→ forge Sigil（建立概念節點，連接相關 symbols）"
-
-        - id: "hidden_constraint"
-          name: "隱藏約束"
-          description: "代碼中存在未文檔化的約束、順序依賴、或環境假設"
-          examples:
-            - "必須先 init embedding engine 才能 search — 否則 silent failure"
-            - "這個函數只能在主線程呼叫 — 沒有 assert 但會 deadlock"
-            - "Windows 上路徑必須用 \\ 但這個函數假設了 /"
-          action: "→ inscribe type=risk（標記危險區域）"
-
-        - id: "evolution_trace"
-          name: "演化軌跡"
-          description: "一段代碼經歷了顯著的設計演化，當前狀態需要歷史 context 才能理解"
-          examples:
-            - "這個 fallback 邏輯是因為 v1 API 還有 client 在用"
-            - "雙 session 架構是從單 session 演化來的 — 解決 reindex blocking"
-            - "這個 cache 層是後加的 — 原本直接查 DB，因為 P99 > 2s"
-          action: "→ inscribe type=insight（記錄演化脈絡）"
-
-      activation: |
-        認知雷達不是每個 tool call 後都跑一次。
-        它在以下自然工作節點自動活化：
-        - 讀完一段陌生代碼後（「這裡怎麼這樣寫？」→ surprise / hidden_constraint）
-        - 定位到 bug 根因後（「原來是這個原因」→ pain_point / surprise）
-        - 做出技術選擇後（「選 A 不選 B 因為...」→ design_fork）
-        - 完成跨模組理解後（「原來這三個模組一起構成了...」→ cross_boundary）
-        - 讀到歷史 commit 或 comment 後（「所以當初是因為...」→ evolution_trace）
-
-    red_flags: |
-      如果你發現自己在想以下任何一句話 — 立刻停下，這是跳過認知融合的前兆：
-      - 「這次沒什麼特別的發現」— 真的嗎？還是你根本沒啟動雷達？
-      - 「都是標準工作，不需要記錄」— FAIL-010 的 5 個 non-obvious pattern 也是「標準工作」中發現的
-      - 「太忙了，先做下一個任務」— 多任務並行時認知融合最容易被犧牲，但此時發現往往最有價值
-      - 「等一下再補」— 你不會回來的。上下文一旦切換，洞察就消失了
-      - 「這個之前應該有人寫過了」— 查了嗎？沒查就是猜測，猜測不是理由
-      - 「只改了幾行，不值得記」— 改動大小 ≠ 洞察價值。一行 fix 可能藏著最關鍵的 risk rune
-
-    anti_rationalization:
-      - excuse: "沒什麼值得記錄的"
-        reality: "FAIL-010 中 Ansuz 跨 3 個任務發現 5 個 non-obvious pattern，一個都沒記。「沒什麼」是最危險的自我欺騙"
-      - excuse: "這是標準操作，大家都知道"
-        reality: "下一個 agent 不是你，它沒有你此刻的上下文。標準操作中的例外才是最需要記的"
-      - excuse: "多任務並行，沒時間做 checkpoint"
-        reality: "並行正是 FAIL-010 的根因。越忙越要做 — checkpoint 是 hard gate，不是軟性建議"
-      - excuse: "完成任務比較重要，認知融合是附加的"
-        reality: "認知融合是任務完成的一部分。沒有 rune 的任務 = 一次性消耗，不產生複利"
-
-  # =============================================================================
-  # SYN-009: 融合適性分析（Fusion Fitness Analysis）
-  # =============================================================================
-  - id: "SYN-009"
-    title: "融合適性分析"
-    description: |
-      偵測到信號後，快速評估這段知識是否值得注入 Synapse 認知層。
-      不是所有發現都值得寫 — 過度注入會污染認知層，降低 recall 品質。
-    severity: "should"
-
-    # ─── 三維評分 ───
-    fitness_dimensions:
-      future_utility:
-        question: "未來 agent 在這個 symbol 附近工作時，需要知道這件事嗎？"
-        high: "不知道會踩坑、會做錯決策、會重複排查"
-        low: "知道了也不影響工作結果"
-        weight: 0.5
-
-      non_obviousness:
-        question: "這個知識能從代碼本身直接讀出來嗎？"
-        high: "看代碼看不出來，需要額外 context（歷史、環境、業務）"
-        low: "代碼自解釋，docstring 已說明，命名就能看懂"
-        weight: 0.3
-
-      stability:
-        question: "這個知識的保質期有多長？"
-        high: "架構級決策、持久的設計約束、反覆出現的模式"
-        low: "臨時 workaround、即將重構的代碼、版本特定的 hack"
-        weight: 0.2
-
-    # ─── 決策門檻 ───
-    decision_gate:
-      inscribe_threshold: |
-        三維加權 ≥ 0.6 → inscribe
-        任一維度 = high 且其他不是 low → inscribe
-        全部 low → 跳過
-      forge_threshold: |
-        cross_boundary 信號 + 涉及 3+ symbol + future_utility=high → forge
-        只有 2 個 symbol → 考慮只 inscribe，不建 sigil
-
-    # ─── 快速判斷捷徑 ───
-    shortcuts:
-      always_inscribe:
-        - "bug 根因是 non-obvious 的（不看代碼會再踩）"
-        - "函數有未文檔化的 precondition 或 side-effect"
-        - "做了會影響其他模組的架構決策"
-      never_inscribe:
-        - "docstring 或 comment 已經說明的事"
-        - "標準 library 用法（不是專案特有的）"
-        - "純 style/formatting 的觀察"
-        - "confidence < 0.6 的推測（等驗證後再寫）"
-
-  # =============================================================================
-  # SYN-010: Sigil 湧現偵測（Sigil Emergence Detection）
-  # =============================================================================
-  - id: "SYN-010"
-    title: "Sigil 湧現偵測"
-    description: |
-      Sigil 是跨 symbol 的語義概念節點 — 比 Rune 更稀缺、更有價值。
-      Sigil 不是設計出來的，而是從工作中「湧現」的。
-      當你發現散落的 symbol 之間有未命名的概念連結時，就是 forge 的時機。
-    severity: "should"
-
-    # ─── 湧現條件 ───
-    emergence_conditions:
-      must_all:
-        - "涉及 3+ 個 symbol（跨越至少 2 個檔案）"
-        - "這些 symbol 共同構成一個可命名的概念或流程"
-        - "概念名稱不是已有的 class/module 名（否則用 MEMBER_OF 關係就夠了）"
-        - "未來 agent 用這個概念名搜尋時，應該能找到所有相關 symbol"
-
-    # ─── 湧現場景 ───
-    emergence_scenarios:
-      pipeline_discovery: |
-        工作中發現 A → B → C → D 的資料流或控制流，
-        但這四個 symbol 分散在不同檔案，沒有統一的 entry point。
-        → forge Sigil: name="xxx_pipeline", members=[A, B, C, D]
-      pattern_crystallization: |
-        在不同模組中發現相同的設計模式被反覆使用（如 retry-with-backoff），
-        但沒有共用的 base class 或 utility。
-        → forge Sigil: name="retry_pattern", members=[impl_1, impl_2, impl_3]
-      concept_naming: |
-        多個 rune 指向同一個抽象概念（如「auth 相關的所有安全檢查」），
-        但沒有一個統一的名字。
-        → forge Sigil: name="auth_security_checks", abstract="All security validations in the auth flow"
-      failure_cluster: |
-        多個 fix rune 集中在相關的 symbol 群，暗示一個脆弱區域。
-        → forge Sigil: name="xxx_fragile_zone", members=[affected symbols]
-
-    # ─── Sigil 品質標準 ───
-    quality_criteria:
-      name: "簡潔英文、snake_case、概念性（不是技術細節）"
-      abstract: "一句話說明這個概念是什麼、為什麼重要"
-      members: "至少 3 個 symbol，每個都和概念有真關聯（不湊數）"
-
-    # ─── 與 recall 的閉環 ───
-    recall_integration: |
-      forge 完 Sigil 後，未來 agent 用 synapse_recall 搜尋概念名，
-      就能一次拉出所有相關 symbol + rune。
-      這是認知層的核心價值：把散落的知識凝結成可搜尋的概念。
-
-  # =============================================================================
-  # SYN-012: Acted-On 回溯鏈（Recall → Inscribe Linkage）
-  # =============================================================================
-  - id: "SYN-012"
-    title: "Acted-On 回溯鏈"
-    description: |
-      synapse_inscribe 時必須回溯本 session 先前 recall 過的 rune，
-      將相關的 rune_id 傳入 related_rune_ids 參數。這閉合了
-      recall → acted_on → confidence_boost 的學習迴路。
-      沒有 related_rune_ids 的 inscribe = 斷鏈，metaplasticity
-      confidence 更新無法運作。
-    severity: "must"
-
-    why: |
-      TASK_1245 simulation 發現 90 天內 6333 次 recall 只有 22 次
-      acted_on（0.35%）。根因：agent inscribe 時從不傳 related_rune_ids，
-      導致 rune_usage_log 中 acted_on 永遠為 0。confidence 更新規則
-      無法觸發（需要 acted_on_rate > 0.5）。
-
-    protocol:
-      when: "每次呼叫 synapse_inscribe 時"
-      how: |
-        1. 回顧本 session 中你已經 recall 過的 rune（synapse_recall 結果）
-        2. 從中選出與當前 inscribe 直接相關的 rune_id（你讀了它、它影響了你的決策或行動）
-        3. 傳入 related_rune_ids=[rune_id_1, rune_id_2, ...]
-      examples:
-        recall_then_fix: |
-          synapse_recall("connection timeout") → 返回 rune_abc123（risk rune）
-          你讀了它，避開了已知的 timeout 地雷，然後 inscribe 了新的 fix rune
-          → synapse_inscribe(... related_rune_ids=["rune_abc123"])
-        recall_symbol_then_inscribe: |
-          synapse_recall("parseConfig") → 返回 rune_def456（decision rune）
-          你修改了 parseConfig 並留下新的 decision rune
-          → synapse_inscribe(... related_rune_ids=["rune_def456"])
-        no_prior_recall: |
-          本 session 沒有做過任何 recall → related_rune_ids=[] 或省略
-          這是合理的 — 不要為了填而填
-
-    rules:
-      - "✅ 每次 inscribe 前回顧：本 session recall 過哪些 rune？哪些影響了這次 inscribe？"
-      - "✅ 只傳真正相關的 rune_id — 你讀了它且它影響了你的行動"
-      - "❌ 不要為了填 related_rune_ids 而額外 recall — 自然工作流中已經 recall 的才算"
-      - "❌ 不要把所有 recall 過的 rune 都塞進去 — 只選直接相關的"
-
-  # =============================================================================
-  # SYN-011: 認知層應用（Cognitive Layer Application）
-  # =============================================================================
-  - id: "SYN-011"
-    title: "認知層應用"
-    description: |
-      不只是寫入 — 更重要的是在工作中主動應用已有的認知。
-      每個 agent 開始觸碰 symbol 前，都應該先查詢認知層。
-    severity: "should"
-
-    # ─── 應用時機 ───
-    application_triggers:
-      pre_modify: |
-        準備修改任何 symbol 前：
-        1. synapse_recall 查詢該 symbol / 該模組的已知 rune
-        2. 如有 risk rune → 小心處理，避免踩已知地雷
-        3. 如有 decision rune → 理解當初為什麼這樣設計，避免破壞意圖
-        4. 如有 fix rune → 確認你的修改不會 reintroduce 已修過的 bug
-      pre_design: |
-        設計新功能或架構時：
-        1. synapse_sigils 瀏覽概念地圖 → 理解系統高層結構
-        2. synapse_recall 搜尋相關概念 → 找已有的 pattern 和 decision
-        3. 基於已有認知做設計，而非從零開始
-      during_debug: |
-        Debug 過程中：
-        1. 定位到可疑 symbol 後，先 synapse_recall 查 fix/risk rune
-        2. 如果有「上次也是這裡出問題」的 rune → 直接讀根因，跳過重複排查
-        3. 節省的不只是時間，更是避免走入錯誤的假設
-
-    # ─── 認知循環 ───
-    cognitive_loop: |
-      工作中的認知不是線性的，而是一個循環：
-
-      recall（帶著已知開始）
-        → 工作（偵測信號）
-          → 評估（融合適性分析）
-            → inscribe/forge（注入新知識）
-              → 下次 recall 時可用
-
-      每一輪工作都在豐富認知層，讓下一輪工作更有效。
-      Agent 不是工具，是有記憶的協作者。

package/core/.specialist/Ansuz/concepts/cognitive_systems_hippocampus.yaml

@@ -1,14 +0,0 @@
-id: cognitive_systems_hippocampus
-priority: P1
-always_load: false
-triggers:
-  - "episodes"
-  - "memory"
-  - "consolidation"
-size_kb: 0.44
-evolution_status: operational
----
-  hippocampus_consolidation:
-    what: "Spaced repetition for episodes — consolidation_scores ranks episodes by review urgency (recency × access × richness). Cool tier (>30 days) and Archive tier (>90 days) compress old episodes."
-    tools: "hippocampus_consolidation_scores, hippocampus_consolidate, hippocampus_due_episodes"
-    auto: "Auto-consolidation runs on Dashboard startup and on hippocampus_consolidation_scores/consolidate calls."

package/core/.specialist/Ansuz/concepts/write_verification.yaml

@@ -1,26 +0,0 @@
-id: write_verification
-priority: P0
-always_load: true
-triggers:
-  always: true
-size_kb: 1.23
-evolution_status: immutable
----
-write_verification_protocol:
-  trigger: "After every synapse_inscribe call"
-  description: "Verify the rune was actually written — eliminates silent write failures (TASK_946)"
-  steps:
-    - "1. Extract first 8 words of inscribed content (strip punctuation for FTS5 safety)"
-    - "2. Call synapse_recall(query=<8_words>, limit=1, projectPath=PROJECT_PATH)"
-    - "3. If result_count > 0 → write confirmed, continue normally (silent)"
-    - |
-      4. If result_count = 0:
-         a. Distinguish failure type:
-            - Connection refused / timeout → Synapse unavailable → log warning only, do NOT push ambient_signal
-            - Empty results with successful response → genuine write failure → proceed to step b
-         b. Push to ambient_signals: {signal_type: 'write_failure', summary: 'inscribe failed: {symbol_stable_id} — recall returned 0 results', detected_at: ISO, symbols: [symbol_stable_id]}
-         c. Notify user: "⚠️ Memory write could not be verified for {symbol_stable_id}"
-  notes:
-    - "MEM-LANG-001: verify query must be in English — same rule as inscribe content"
-    - "Max verify query length: 8 words, no special characters"
-    - "This protocol applies to ALL synapse_inscribe calls — no exceptions"

package/core/.specialist/Ansuz/modules/recall.yaml

@@ -1,45 +0,0 @@
-name: recall
-description: "Ansuz episodic memory recall protocol — when and how to use hippocampus"
-auto_inject: "Phase 1 enter（強制注入，確保 Ansuz 帶著歷史認知進入需求分析）"
-
-# ═══════════════════════════════════════
-#  三層回憶機制（Phase 0 Tiered Recall）
-#  Redesigned: TASK_685 — cold-start fix
-# ═══════════════════════════════════════
-tiers:
-  tier_1_ash:
-    tool: "synapse_recall"
-    params: "type=ash, limit=5, projectPath=當前專案絕對路徑"
-    when: "Phase 0 無條件執行 — 不依賴 query 關鍵字"
-    purpose: "載入 Ash 哲學/架構 Rune（系統設計原則、跨 session 洞見）。冷啟動也保證命中，解決新 session 遺漏高價值 rune 的問題"
-    gate_signal: "ash_loaded=true（Phase 0 exit 必要條件）"
-
-  tier_2_sigils:
-    tool: "synapse_sigils"
-    params: "projectPath=當前專案絕對路徑"
-    when: "Phase 0 無條件執行"
-    purpose: "載入全域架構 Sigil 概念圖（跨 symbol 的系統級概念）。Ansuz 必須在後續工作中主動應用，不只是存儲"
-
-  tier_3_contextual:
-    tool: "hippocampus_episode_recall"
-    params: "projectPath=當前專案絕對路徑, limit=3（不帶 query — FTS5 非語義搜尋，無 query 時按時間倒序，命中率最高）"
-    when: "情境觸發 — 需要歷史 episode 脈絡時才呼叫"
-    trigger_conditions:
-      - "Phase 0：想了解近期 session 的結論與教訓"
-      - "Phase 1：需求與歷史 episode 相關，需要當時的決策細節"
-      - "Phase 9：驗證失敗，需要比對歷史同類問題的修復過程"
-      - "任何時候：Ash/Sigil 觸發了疑問，需要追蹤完整的 episode 細節"
-    skip_when: "純任務繼續（無需歷史 context）→ 可跳過"
-
-# ═══════════════════════════════════════
-#  Phase 1 回憶協議
-# ═══════════════════════════════════════
-phase_1_protocol:
-  step_1: "讀 Phase 0 已載入的 Ash rune（ash_loaded=true 確認）— 有無相關 lesson/pattern？"
-  step_2: "執行 synapse_recall(query=需求關鍵字) — 查 rune/sigil 歷史知識（Phase 1 必做）"
-  step_3: |
-    如果 Phase 0 的 episode 摘要中有與本次需求相關的 task_id：
-    → hippocampus_episode_recall(task_id=that_episode_task_id)
-    → 讀完整 entries，提取相關 decision/risk
-  step_4: "將回憶結果整合進需求分析（避免重蹈歷史坑）"
-  rule: "synapse_recall 是必做的；hippocampus 細節召回是條件觸發的"