扫描聚焦 codewiki/mcp/ 包 · 目标：找出可深化的摩擦点，供挑选后逐一深挖
knowledge_loop.py capture_conversation.py distill_conversation.py doc_writer.py同一段「解析 output_dir → 解析/恢复 session → 派生 repo_path → 失败抛错」的逻辑在多个 handler 里各写一份。调用方想改一处行为（比如 session 恢复策略）要同步改 7 个文件。
注意：workspace_result.py 里已存在 resolve_session() 公共辅助，但多数 handler 没有复用，仍各自手写。
resolve_workspace(arguments) → WorkspaceContext 辅助（封装 output_dir / session / repo_path 三元组解析），7 处改为单点调用。纯删减、无行为变化，风险最低。cache.py doc_writer.py knowledge_loop.py source_ingest.py wiki_lint.py …「读 YAML frontmatter → 取某 key」的辅助函数分别存在于 cache.py（_parse_frontmatter_dict、_extract_frontmatter）、doc_writer.py（74 处引用 frontmatter）、knowledge_loop.py（42 处）、source_ingest.py（32 处）、wiki_lint.py（20 处）等。
同样字段（type / title / related_modules…）在不同文件的解析容错行为可能不一致——这是潜在的隐性 bug 来源。
codewiki/mcp/wiki_fm.py（或并入现有公共模块）统一 frontmatter 读写，所有文件改为 import 单点。收效面最广。registry.py（2108 行） vs tools/*.py2108 行里约 85% 是 纯 schema 数据（超长 description 字符串 + inputSchema dict），真正的 dispatch 逻辑只有 ~60 行。每个工具的知识被拆在两处：schema 在 registry.py，handler 在 tools/xxx.py。改一个工具要跳两个文件、对齐两处。
TOOL_DEF = Tool(...) + REGISTER(tool) 声明式注册），registry 只留 dispatch 与汇总。让「一个工具的完整知识就近可见」。_ide_hook.py（可 python -m 直接跑）名义上是 mcp 包的内部模块，实际是 独立 CLI 入口：直接 import handle_capture_conversation，手工组装 arguments dict，绕过 registry 的 schema 校验与 dispatch 管线。
后果：hook 路径与 MCP 路径的 参数行为可能漂移（校验、默认值、错误格式），同一个 capture_conversation 语义在两处不同。
workspace.py模块 docstring 声明目录布局是 .codewiki/sessions/{session_id}/，但实际实现已改为 固定的 .codewiki/workspace/（见 __init__ 注释「Use a fixed directory per repo instead of per-session」）。同时构造器接收 session_id 参数但完全未使用——死参数。
session_id 死参数（改调用方），消除「文档 vs 行为」漂移。session.py knowledge_loop.py查询类工具只传 repo_path 时，find_or_restore() 会静默从 SQLite 恢复 session。knowledge_loop.py 里甚至有一段注释承认：该恢复可能返回 stale/incorrect path，然后手动用 repo_path 覆盖。
「调用查询工具 → 静默重建分析 session」对外部是不可见的魔法行为。
registry.py cbm_integration.pydispatch 中对 analyze_repo / analyze_impact / query_cross_service 的结果做 CBM 增强改写（解析 JSON 后注入）。这是对 handler 返回值的 隐式契约：非 JSON 字符串的返回会静默跳过增强。
每个方向都会先做「删除测试 / 概念收敛」，确认复杂度真的消失而不是搬走，然后给出一份实施方案供你 grill。