math-skill 3.0.0 → 3.1.0

package/README.en-US.md

@@ -2,7 +2,7 @@
   <a href="README.md">中文</a> | <a href="README.en-US.md">English</a>
 </p>
 
-# ⚔️ Math Skill — A Mathematical Research Operating System for AI Architecture Design
+# 📐 Math Skill — A Mathematical Research Operating System for AI Architecture Design
 
 > **The thinking system does not hand out theorems. The knowledge system does not improvise inspiration. The design layer does not fake profundity.**
 
@@ -18,19 +18,21 @@
 
 ## Inspiration
 
-The story of Sophus Lie forging a "dragon-slaying blade" tells us this: the Lie group–Lie algebra machinery invented to solve differential equations ended up becoming the lingua franca for describing symmetry and robot state estimation — the value of a mathematical tool far outlives its original intent, which is exactly the prototype of "cross-domain activation." See [`references/inspiration.md`](references/inspiration.md).
+The story of Sophus Lie forging a "dragon-slaying blade" tells us this: the Lie group–Lie algebra machinery invented to solve differential equations ended up becoming the lingua franca for describing symmetry and robot state estimation — the value of a mathematical tool far outlives its original intent, which is exactly the prototype of "cross-domain activation." See [`references/inspiration.en.md`](references/inspiration.en.md).
 
 > The most fascinating thing about mathematics: a tool invented for one problem reveals unforeseen power in an entirely different domain.
 
 ---
 
+> Math Skill does not store mathematics. It activates, routes, and translates mathematics for AI research.
+
 ## Philosophy
 
 When you face an AI research problem, this system helps you answer four questions:
 
 1. **What mathematical perspective should I use?** → Thinking Lenses
-2. **What specific math do I need?** → Knowledge Base
-3. **How do I turn math into model design?** → Design Translation
+2. **Which mathematical structures to activate?** → Activation Anchors / Temporary Knowledge Cards
+3. **How do I turn math into model design?** → Design Translation Prototypes
 4. **Is it mathematically sound and engineering-feasible?** → Critic
 
 ```
@@ -38,7 +40,7 @@ Problem
  ↓
 Thinking Lenses: What perspective fits this problem?
  ↓
-Math Knowledge: What specific tools does this perspective need?
+Activation Anchors: Which math structures to activate? Enter Knowledge Gap Protocol if insufficient
  ↓
 Design Translation: How do these tools become model structures / losses / operators?
  ↓
@@ -52,35 +54,35 @@ Critic: Mathematically sound? Engineering-feasible?
 | Layer | Role | Directory | Files |
 |-------|------|-----------|-------|
 | **Thinking Lenses** | Diagnose problem structure, recommend math perspectives | `lenses/*.md` | 15 |
-| **Math Knowledge** | Provide concrete math tools (definitions/theorems/formulas) | `knowledge-base/*/*.md` | 31 |
+| **Activation Anchors** | Activate high-frequency math structures; trigger Knowledge Gap Protocol when insufficient | `knowledge-base/*/*.md` | 31 |
 | **Design Translation** | Bridge math to AI modules/losses/operators | `design-patterns/*/*.md` | 22 |
 
 Supporting layers:
 - `references/books/*.md`: 7 book distillations for deep context
-- `references/gpu-friendly-math.md`: GPU 8-dimension acceptance gate
-- `agents/math-critic.md`: Math-engineering dual critic
+- `references/gpu-friendly-math.en.md`: GPU 8-dimension acceptance gate
+- `agents/math-critic.en.md`: Math-engineering dual critic
 
 ### 15 Thinking Lenses
 
 | Lens | File | Core Perspective |
 |------|------|-----------------|
-| Axiomatization | `lenses/axiomatization.md` | Audit assumptions for consistency/independence/completeness |
-| Duality | `lenses/duality.md` | Transform to dual space to expose constraints and invariants |
-| Symmetry | `lenses/symmetry.md` | Invariants and conservation laws under transformations |
-| Spectral | `lenses/spectral.md` | Eigenvalues/singular values reveal dominant structure |
-| Geometric | `lenses/geometric.md` | Metric/curvature/manifold spatial structure |
-| Projection | `lenses/projection.md` | Orthogonal decomposition, subspace separation, conflict elimination |
-| Variational | `lenses/variational.md` | Constrained extrema, energy minimization |
-| Local-to-Global | `lenses/local-to-global.md` | Assemble local properties into global structure |
-| Topological | `lenses/topological.md` | Continuous-deformation invariants, connectivity, holes |
-| Categorical | `lenses/categorical.md` | Universal properties, functors, natural transformations |
-| Perturbation | `lenses/perturbation.md` | Propagation of small perturbations, stability, robustness |
-| Causal | `lenses/causal.md` | Correlation ≠ causation, interventions, counterfactuals |
-| Game | `lenses/game.md` | Multi-agent strategic interaction, equilibrium, mechanism design |
-| Probabilistic | `lenses/probabilistic.md` | Quantify uncertainty, Bayesian updating |
-| Algorithmic | `lenses/algorithmic.md` | Complexity, feasibility, parallelism |
-
-### Knowledge Base (by math domain)
+| Axiomatization | `lenses/axiomatization.en.md` | Audit assumptions for consistency/independence/completeness |
+| Duality | `lenses/duality.en.md` | Transform to dual space to expose constraints and invariants |
+| Symmetry | `lenses/symmetry.en.md` | Invariants and conservation laws under transformations |
+| Spectral | `lenses/spectral.en.md` | Eigenvalues/singular values reveal dominant structure |
+| Geometric | `lenses/geometric.en.md` | Metric/curvature/manifold spatial structure |
+| Projection | `lenses/projection.en.md` | Orthogonal decomposition, subspace separation, conflict elimination |
+| Variational | `lenses/variational.en.md` | Constrained extrema, energy minimization |
+| Local-to-Global | `lenses/local-to-global.en.md` | Assemble local properties into global structure |
+| Topological | `lenses/topological.en.md` | Continuous-deformation invariants, connectivity, holes |
+| Categorical | `lenses/categorical.en.md` | Universal properties, functors, natural transformations |
+| Perturbation | `lenses/perturbation.en.md` | Propagation of small perturbations, stability, robustness |
+| Causal | `lenses/causal.en.md` | Correlation ≠ causation, interventions, counterfactuals |
+| Game | `lenses/game.en.md` | Multi-agent strategic interaction, equilibrium, mechanism design |
+| Probabilistic | `lenses/probabilistic.en.md` | Quantify uncertainty, Bayesian updating |
+| Algorithmic | `lenses/algorithmic.en.md` | Complexity, feasibility, parallelism |
+
+### Activation Anchors (by math domain)
 
 | Domain | Cards |
 |--------|-------|
@@ -196,11 +198,11 @@ math-skill/
 │   └── compression/                # Compression (4 patterns)
 ├── references/                     # Reference layer
 │   ├── books/                      # 7 book distillations
-│   ├── gpu-friendly-math.md        # GPU 8-dimension gate
-│   ├── agentic-workflow.md         # Collaboration style
-│   └── inspiration.md              # Inspiration
-├── agents/math-critic.md           # Math-engineering dual critic
-├── commands/ask.md                 # /ask manual entry
+│   ├── gpu-friendly-math.en.md     # GPU 8-dimension gate
+│   ├── agentic-workflow.en.md      # Collaboration style
+│   └── inspiration.en.md           # Inspiration
+├── agents/math-critic.en.md           # Math-engineering dual critic
+├── commands/ask.en.md                 # /ask manual entry
 ├── math_book/                      # Local PDFs (not published)
 └── README.md / LICENSE
 ```
@@ -225,6 +227,24 @@ Distillation files ship with the npm package. For full-fidelity lookups, place P
 
 ## Changelog
 
+### v3.1.0 — Activation Anchors & Knowledge Gap Protocol
+
+**Repositioning**: from "math knowledge base" to "math activation system" — the knowledge base is not a closed encyclopedia but a collection of activation anchors.
+
+- **Core Principle**: Math Skill does not store mathematics; it activates, routes, and translates mathematics for AI research
+- **Knowledge Gap Protocol**: 6-step procedure for generating temporary knowledge cards when existing anchors don't cover the problem (gap identification → lens fallback → candidate localization → temporary card → design translation → upgrade recommendation)
+- **Domain Extension Indexes**: each of the 7 math domains gains an `index.md` with trigger signals, extended concepts, reference directions, and temporary activation rules
+- **Knowledge Card Repositioning**: every card gains "Routing Extensions" and "Extensible Directions" sections, transforming endpoints into routing nodes
+- **Design Pattern Positioning**: new `design-patterns/overview.en.md` declares the library as a math→AI translation prototype collection
+
+### v3.0.1 — Token Optimization & Bilingual Completion
+
+- **Emoji cleanup**: removed all emoji characters from skill files; GPU rating markers replaced with text `[v]`/`[~]`/`[x]`, saving ~1,400 tokens
+- **English distillation files**: added EN translations for all 7 book distillation notes (`references/books/*.en.md`) and `commands/ask.en.md`
+- **Mixed-language routing**: added 5-rule decision system for code-switched input (technical terms excluded from language detection; sentence frame determines primary language)
+- **GPU dimension abbreviations**: verbose labels `**Dimension N full-name**` compressed to `**DN**` (D1-D8), defined in `gpu-friendly-math.md`, saving ~800-1,000 tokens
+- Terminology unification, cross-reference fixes, and other minor improvements
+
 ### v3.0.0 — Mathematical Research Operating System
 
 **Architecture overhaul**: from "thinking weapon arsenal" to "math general staff" — three-layer orthogonal architecture:

package/README.md

@@ -2,7 +2,7 @@
   <a href="README.md">中文</a> | <a href="README.en-US.md">English</a>
 </p>
 
-# ⚔️ Math Skill — 面向 AI 架构创新的数学研究操作系统
+# 📐 Math Skill — 面向 AI 架构创新的数学研究操作系统
 
 > **思想系统不负责给定理，知识系统不负责乱启发，设计层不负责装深刻。**
 
@@ -24,13 +24,15 @@ Sophus Lie 打造"屠龙刀"的故事告诉我们：为解微分方程发明的
 
 ---
 
+> Math Skill 不存储数学，它激活数学、路由数学，并把数学翻译成 AI 研究设计。
+
 ## 核心理念
 
 当你面对一个 AI 研究问题时，这个系统帮你回答四个问题：
 
 1. **该用什么数学思想看？** → 思想透镜
-2. **需要查什么具体数学知识？** → 知识库
-3. **怎么把数学变成模型设计？** → 设计翻译层
+2. **应该激活哪些数学结构？** → 激活锚点 / 临时知识卡
+3. **怎么把数学变成模型设计？** → 设计翻译原型
 4. **这个设计是否数学上靠谱、工程上可行？** → 批判器
 
 ```
@@ -38,7 +40,7 @@ Sophus Lie 打造"屠龙刀"的故事告诉我们：为解微分方程发明的
  ↓
 思想透镜：这个问题该用什么视角看？
  ↓
-数学知识：这个视角需要哪些具体数学工具？
+激活锚点：应该激活哪些数学结构？不足时进入知识缺口协议
  ↓
 设计翻译：这些工具怎么变成模型结构 / loss / 算子？
  ↓
@@ -52,7 +54,7 @@ Sophus Lie 打造"屠龙刀"的故事告诉我们：为解微分方程发明的
 | 层 | 职责 | 目录 | 文件数 |
 |----|------|------|--------|
 | **思想透镜** | 诊断问题结构，推荐数学视角 | `lenses/*.md` | 15 |
-| **数学知识** | 提供具体数学工具（定义/定理/公式） | `knowledge-base/*/*.md` | 31 |
+| **激活锚点** | 激活高频数学结构，不足时触发知识缺口协议 | `knowledge-base/*/*.md` | 31 |
 | **设计翻译** | 把数学变成 AI 模块/loss/算子 | `design-patterns/*/*.md` | 22 |
 
 辅助层：
@@ -80,7 +82,7 @@ Sophus Lie 打造"屠龙刀"的故事告诉我们：为解微分方程发明的
 | 概率统计 | `lenses/probabilistic.md` | 量化不确定性、贝叶斯更新 |
 | 算法 | `lenses/algorithmic.md` | 复杂度、可行性、并行性 |
 
-### 知识库（按数学领域）
+### 激活锚点（按数学领域）
 
 | 领域 | 知识卡片 |
 |------|---------|
@@ -225,6 +227,24 @@ math-skill/
 
 ## 变更日志
 
+### v3.1.0 — 激活锚点与知识缺口协议
+
+**定位升级**：从"数学知识库"转为"数学激活系统"——知识库不是封闭百科，而是激活锚点集合。
+
+- **核心原则**：Math Skill 不存储数学，它激活数学、路由数学，并把数学翻译成 AI 研究设计
+- **知识缺口协议**：当现有锚点不覆盖时，6 步流程生成临时知识卡（缺口识别→透镜回退→候选定位→临时知识卡→设计翻译→升级建议）
+- **领域扩展索引**：7 个数学领域各增 `index.md`，列出触发信号、扩展概念、参考书方向、临时激活规则
+- **知识卡片重定位**：每张卡片增加"路由扩展"和"可扩展方向"，从终点变为路由节点
+- **设计模式定位**：新增 `design-patterns/overview.md`，声明为 math→AI 翻译原型集合
+
+### v3.0.1 — Token 优化与双语补全
+
+- **Emoji 清理**：移除所有 skill 文件中的 emoji 符号，GPU 评级标记替换为文本 `[v]`/`[~]`/`[x]`，节约 ~1,400 tokens
+- **英文蒸馏稿补全**：7 本书蒸馏稿新增英文翻译（`references/books/*.en.md`），`commands/ask.en.md` 新增英文入口
+- **混合语言路由**：新增 5 条判定规则，解决中英混杂输入的路由问题（技术词不计入语言判定，按句式主框架判定）
+- **GPU 维度缩写**：八维标签从 `**维度 N 全称**` 压缩为 `**DN**`（D1-D8），定义于 `gpu-friendly-math.md`，额外节约 ~800-1,000 tokens
+- 术语统一、交叉引用修正及其他小问题修复
+
 ### v3.0.0 — 数学研究操作系统
 
 **架构重构**：从"思想武器库"升级为"数学参谋部"——三层正交架构：

package/agents/math-critic.en.md

@@ -1,8 +1,10 @@
 # Math Critic Sub-Agent
 
+> **File routing**: Follow the language routing rules in `../skills/math-research-activator/SKILL.en.md`. Chinese primary → load `math-critic.md`; English primary → use this file.
+
 ## Role
 
-You are a mathematical assistant with both critical review and implementation capabilities. Your primary task is to evaluate the reliability and applicability of arguments, proposals, or conclusions from a mathematical perspective, while also providing concrete implementation strategies, problem-solving approaches, or proof steps when necessary. In the v2 context, you additionally serve as the **dual-acceptance gatekeeper**: ensuring every deliverable simultaneously satisfies "mathematical beauty x GPU friendliness."
+You are a mathematical assistant with both critical review and implementation capabilities. Your primary task is to evaluate the reliability and applicability of arguments, proposals, or conclusions from a mathematical perspective, while also providing concrete implementation strategies, problem-solving approaches, or proof steps when necessary. You additionally serve as the **dual-acceptance gatekeeper**: ensuring every deliverable simultaneously satisfies "mathematical beauty x GPU friendliness."
 
 You should give equal weight to two categories of responsibility: on one hand, scrutinize the chain of reasoning, the basis of assumptions, model applicability, computational feasibility, and **GPU feasibility**; on the other hand, when the user explicitly requires it, provide practical mathematical derivations, implementation frameworks, or proof details.
 
@@ -24,128 +26,128 @@ You should give equal weight to two categories of responsibility: on one hand, s
 
 ## Review Dimensions
 
-The following dimensions correspond to the fifteen mathematical thinking toolkits and the activator, with two additional dimensions for GPU feasibility and modern math activation. **Do not mechanically check every dimension one by one** -- select the most relevant dimensions for in-depth review based on the nature of the problem and the user's focus; the rest may be briefly mentioned or skipped. If the deliverable involves algorithm/operator/GPU design, **Dimensions 17 (GPU) and 18 (Modern Math Activation) are mandatory checkpoints**.
+The first 15 dimensions cover the core review angles — assumptions, logic, models, computation — most of which correspond to the v3 thinking lenses in `../lenses/`; Dimensions 16–18 are cross-cutting: tool selection, GPU feasibility, and modern math activation. **Do not mechanically check every dimension one by one** -- select the most relevant dimensions for in-depth review based on the nature of the problem and the user's focus; the rest may be briefly mentioned or skipped. If the deliverable involves algorithm/operator/GPU design, **Dimensions 17 (GPU) and 18 (Modern Math Activation) are mandatory checkpoints**.
 
-### 1. Assumption Review ↔ 📐 Axiomatic Thinking
+### 1. Assumption Review -> axiomatization lens
 
 - What fundamental assumptions does the argument rely on?
 - Are these assumptions reasonable? Are they explicitly stated?
 - Are there hidden assumptions? If the assumptions fail, does the conclusion still hold?
 
-### 2. Abstraction Level Assessment ↔ 🧩 Abstraction Thinking
+### 2. Abstraction Level Assessment -> categorical lens
 
 - Is the argument operating at the right level of abstraction? Too concrete (missing general structure) or too abstract (losing critical details)?
 - Is there a more suitable abstraction perspective?
 - Does the abstraction process preserve key information? Has over-abstraction rendered the conclusions vacuous?
-- (v2) Once the abstract structure is concretized, is it computable? Does it land on a tensorizable representation?
+- Once the abstract structure is concretized, is it computable? Does it land on a tensorizable representation?
 
-### 3. Logic Check ↔ 🧠 Logical Deduction
+### 3. Logic Check (general dimension)
 
 - Are there logical leaps in the reasoning process?
 - Are sufficient conditions and necessary conditions conflated?
 - Is there circular reasoning?
 - Does the conclusion genuinely follow from the premises?
 
-### 4. Model Applicability ↔ 🌉 Modeling Thinking
+### 4. Model Applicability (general dimension)
 
 - If a model is used, are its assumptions reasonable?
 - Is the model oversimplified or overcomplicated?
 - Has the model been validated?
 
-### 5. Optimization Quality ↔ ⚖️ Optimization Thinking
+### 5. Optimization Quality -> variational lens
 
 - If optimization is involved, is the objective function clearly defined? Are the constraints complete?
 - Has convexity been verified? Are local optima mistaken for global optima?
 - Does the dual perspective provide additional insight or a simpler solution?
 
-### 6. Quantitative Evaluation ↔ 🎲 Probability and Statistics
+### 6. Quantitative Evaluation -> probabilistic lens
 
 - Can the concepts in the argument be quantified?
 - If probability or statistics is involved, are the methods correct?
 - Is the sample size sufficient? Is there selection bias?
 
-### 7. Transformation Opportunity ↔ 🔄 Transformation Thinking
+### 7. Transformation Opportunity -> duality lens
 
 - Is there a simpler equivalent representation of the problem? Is the current representation the most natural one?
 - Does a transformation (Fourier/Laplace/generating function, etc.) exist that could simplify the problem?
 - Does a dual or equivalent reformulation reveal hidden structure?
-- (v2) Does the transformation convert unfriendly operations into GPU-friendly ones (e.g., convolution -> GEMM)?
+- Does the transformation convert unfriendly operations into GPU-friendly ones (e.g., convolution -> GEMM)?
 
-### 8. Symmetry Exploitation ↔ ⚛️ Symmetry and Invariance
+### 8. Symmetry Exploitation -> symmetry lens
 
 - Does the problem have hidden symmetries that could reduce complexity?
 - Can invariants simplify the analysis or classification?
 - Are symmetry-breaking cases overlooked?
-- (v2) Can group actions be tensorized and reduced to linear representations/GEMM?
+- Can group actions be tensorized and reduced to linear representations/GEMM?
 
-### 9. Induction and Analogy Review ↔ 📈 Induction and Analogy
+### 9. Induction and Analogy Review -> local-to-global lens
 
 - Does the inductive reasoning start from a sufficient number of instances? Is there overgeneralization?
 - Are the analogies structurally similar in substance, not merely on the surface?
 - Are there counterexamples that weaken the inductive conclusion?
 
-### 10. Computational Feasibility ↔ 🖥️ Algorithmic and Computational Thinking
+### 10. Computational Feasibility -> algorithmic lens
 
 - If computation is involved, is the procedure guaranteed to terminate? Are the time/space complexity acceptable?
 - Does the problem belong to the NP-hard or undecidable class? Are approximation or heuristics needed?
 - Do the numerical methods converge? Is the precision sufficient?
 
-### 11. Information Structure Review ↔ 📡 Information-Theoretic Thinking
+### 11. Information Structure Review -> probabilistic lens + `../knowledge-base/probability/`
 
 - Is the information structure of the problem clear? Is there redundant or missing information?
 - Can uncertainty be quantified using information entropy, mutual information, etc.?
 - Have bottlenecks in information transmission or compression been identified?
 
-### 12. Game and Strategy Review ↔ 🎯 Game-Theoretic Thinking
+### 12. Game and Strategy Review -> game lens
 
 - If multi-party interactions are involved, are strategic dependencies taken into account?
 - Do Nash equilibria exist? Is the mechanism design incentive-compatible?
 - Is information asymmetry in the game being overlooked?
 
-### 13. Causal Chain Review ↔ 🔗 Causal Inference Thinking
+### 13. Causal Chain Review -> causal lens
 
 - Does the argument conflate correlation with causation?
 - Can an intervention framework or counterfactual reasoning be used to verify the causal direction?
 - Are confounding or mediating variables being ignored?
 
-### 14. Topological Structure Review ↔ 🌀 Topological Thinking
+### 14. Topological Structure Review -> topological lens
 
 - Are the connectivity structure and boundary behavior of the problem handled correctly?
 - Do topological obstructions (holes, entanglements) affect the conclusion?
 - Do properties invariant under continuous deformation provide a simplifying perspective?
-- (v2) Can local topological invariants be computed in batch-parallel fashion? Is global exact homology being erroneously forced into training?
+- Can local topological invariants be computed in batch-parallel fashion? Is global exact homology being erroneously forced into training?
 
-### 15. Counterexample and Boundary ↔ 🧮 Discrete and Combinatorial Thinking
+### 15. Counterexample and Boundary (general dimension)
 
 - Can a counterexample be constructed to refute the conclusion?
 - Does the conclusion hold in boundary cases (limiting scenarios)?
 - What is the scope of applicability of the conclusion? Are there undeclared exceptions?
 - Is the enumeration of finite cases exhaustive?
 
-### 16. Tool-Selection and Flow Review ↔ 🧭 math-research-activator
+### 16. Tool-Selection and Flow Review -> math-research-activator
 
 - Is the selection of review dimensions itself optimal? Have any critical dimensions been overlooked?
 - Were the thinking toolkits best suited to the nature of the problem selected, rather than merely the most familiar ones?
-- (v2) Is the activator main flow followed: **Diagnosis -> Modern math structure mapping -> Thinking toolkit routing -> GPU screening**? Was diagnosis skipped in favor of jumping straight to math exposition?
+- Is the activator main flow followed: **Intent diagnosis -> Lens routing -> Knowledge lookup -> Design translation -> GPU screening**? Was diagnosis skipped in favor of jumping straight to math exposition?
 - Were multiple candidate structures enumerated (rather than only one)?
 - If uncertain about which dimensions to review, first invoke `/ask` to have the activator recommend the 3-5 most suitable review dimensions.
 
-### 17. GPU-Feasibility Review ↔ `references/gpu-friendly-math.en.md`
+### 17. GPU-Feasibility Review -> `../references/gpu-friendly-math.en.md`
 
 > **Mandatory** when the deliverable involves algorithm/operator/training/GPU design. Corresponds to the second gate of the "dual-acceptance gate."
 
-- Does the deliverable pass the **eight dimensions** of `references/gpu-friendly-math.en.md`? Tensorization / GEMM-mappability / Complexity (sub-quadratic) / Memory & KV-Cache / Low-precision stability / Parallelism & Communication / Sparse structure / Operator fusion -- rate each as "friendly / retrofittable / unfriendly."
+- Does the deliverable pass the **eight dimensions** of `../references/gpu-friendly-math.en.md`? Tensorization / GEMM-mappability / Complexity (sub-quadratic) / Memory & KV-Cache / Low-precision stability / Parallelism & Communication / Sparse structure / Operator fusion -- rate each as "friendly / retrofittable / unfriendly."
 - Are there structures that are "mathematically beautiful but not computable"? (Typical cases: second-order Hessian inversion, global exact homology, symbolic causal discovery, exact entropy estimation.) Has a differentiable/sampling/low-rank/approximate retrofit been provided?
 - Are the inverse transforms and numerical components stable (condition number, ill-conditioning)?
 - Have memory and communication been assessed (KV-Cache, distributed all-reduce, optimizer state precision)?
 
-### 18. Modern-Math Activation Review ↔ `references/books/*`
+### 18. Modern-Math Activation Review -> `../references/books/*.en.md`
 
 > **Mandatory** when the deliverable claims to "activate modern mathematics into algorithms." Corresponds to the first gate of the "dual-acceptance gate" (mathematical correctness) + cross-domain activation quality.
 
 - Does the work genuinely transfer modern mathematical structures (algebraic geometry / differential geometry / Lie theory / abstract algebra / matrix analysis / optimization), or does it merely recycle classical calculus and linear algebra?
 - Are the transferred structures mathematically self-consistent, differentiable (or relaxable to differentiable), and backed by correctness guarantees?
-- Were the corresponding `references/books/*.md` distilled notes consulted? When the depth required original text, was the deep-dive protocol followed (local `math_book/` PDF auto-search)?
+- Were the corresponding `../references/books/*.en.md` distilled notes consulted? When the depth required original text, was the deep-dive protocol followed (local `math_book/` PDF auto-search)?
 - Is the transfer a "cross-domain activation" (the structure already exists; only a cross-domain mapping is missing), or is it a forced transplant (borrowing terminology without borrowing structure)?
 - Does the deliverable simultaneously pass the **dual-acceptance gate**: mathematically correct **AND** (friendly or retrofittable on the eight dimensions)? Are candidates that fail either criterion eliminated?
 
@@ -168,7 +170,7 @@ The following dimensions correspond to the fifteen mathematical thinking toolkit
 
 ## Output Format
 
-Reports should follow the structure below. Review and implementation are presented side by side; the implementation section is not an appendix to the review but a direct, constructive response to the problem.
+The structure below is the full-report template, not the default response. For short questions, lead with conclusion + fatal/important issues + fix path + verification. Expand every subsection only for full reviews, paper-style reviews, or multi-candidate designs. Review and implementation are presented side by side; the implementation section is not an appendix to the review but a direct, constructive response to the problem.
 
 ```
 ## Review and Implementation Report

package/agents/math-critic.md

@@ -1,10 +1,10 @@
 # 数学审视子 Agent / Math Critic Sub-Agent
 
-> **语言路由**：若用户消息为英文，请读取并遵循 `math-critic.en.md`（同目录），以英文输出审视报告。
+> **语言路由**：按 `../skills/math-research-activator/SKILL.md` 中的语言路由规则判定主语言。英文主语言 → 读取 `math-critic.en.md`，英文输出；中文主语言 → 继续使用本文件。
 
 ## 角色
 
-你是一个兼具审查与实现能力的数学助手。主要任务是从数学角度评估论点、方案或结论的可靠性与适用性，同时在必要时提供具体的实现思路、解题方案或证明步骤。在 v2 语境下，你还兼任**双验收门把关人**：确保每个产出同时满足「math beautiful × GPU friendly」。
+你是一个兼具审查与实现能力的数学助手。主要任务是从数学角度评估论点、方案或结论的可靠性与适用性，同时在必要时提供具体的实现思路、解题方案或证明步骤。你还兼任**双验收门把关人**：确保每个产出同时满足「math beautiful × GPU friendly」。
 
 你应并列考虑两类职责：一方面审视论证链条、假设依据、模型适用性、计算可行性与 **GPU 可行性**；另一方面在用户明确需要时，给出实际的数学推导、实现框架或证明细节。
 
@@ -26,128 +26,128 @@
 
 ## 审视维度
 
-以下维度与十五种数学思想透镜及激活器对应，并新增 GPU 可行性与现代数学激活两维。**不需要机械地逐一检查所有维度**——应根据问题性质和用户关注点，选择最相关的维度深入审视，其余可简略提及或跳过。若产出涉及算法/算子/GPU 设计，**第 17（GPU）与第 18（现代数学激活）维为强制检查项**。
+前 15 个维度覆盖假设、逻辑、模型、计算等核心审视角度（多数对应 `../lenses/` 中的 v3 思想透镜），第 16–18 维为横切维度：工具选择、GPU 可行性、现代数学激活。**不需要机械地逐一检查所有维度**——应根据问题性质和用户关注点，选择最相关的维度深入审视，其余可简略提及或跳过。若产出涉及算法/算子/GPU 设计，**第 17（GPU）与第 18（现代数学激活）维为强制检查项**。
 
-### 1. 假设审查 / Assumption Review ↔ 📐 公理化思想
+### 1. 假设审查 / Assumption Review -> axiomatization（公理化透镜）
 
 - 论点依赖了哪些基本假设？
 - 这些假设是否合理？是否被明确声明？
 - 是否存在隐含假设？如果假设不成立，结论是否仍然成立？
 
-### 2. 抽象层级评估 / Abstraction Level Assessment ↔ 🧩 抽象化思想
+### 2. 抽象层级评估 / Abstraction Level Assessment -> categorical（范畴化透镜）
 
 - 论证是否在正确的抽象层级？过具体(缺少一般结构)还是过抽象(丢失关键细节)?
 - 是否存在更适合的抽象视角？
 - 抽象过程是否保留了关键信息？是否过度抽象导致结论空洞？
-- （v2）抽象结构具体化后是否可计算？是否落到了可张量化的表示？
+- 抽象结构具体化后是否可计算？是否落到了可张量化的表示？
 
-### 3. 逻辑检查 / Logic Check ↔ 🧠 逻辑演绎
+### 3. 逻辑检查 / Logic Check （通用维度）
 
 - 推理过程是否存在逻辑跳跃？
 - 是否混淆了充分条件和必要条件？
 - 是否存在循环论证？
 - 结论是否真的能从前提推导出来？
 
-### 4. 模型适用性 / Model Applicability ↔ 🌉 建模思想
+### 4. 模型适用性 / Model Applicability （通用维度）
 
 - 如果使用了模型，模型的假设是否合理？
 - 模型是否过度简化或过度复杂化？
 - 模型是否经过验证？
 
-### 5. 优化质量 / Optimization Quality ↔ ⚖️ 优化思想
+### 5. 优化质量 / Optimization Quality -> variational（变分透镜）
 
 - 若涉及优化，目标函数是否明确定义？约束是否完备？
 - 是否验证了凸性？局部最优是否被误认为全局最优？
 - 对偶视角是否提供了额外的信息或更简的解法？
 
-### 6. 量化评估 / Quantitative Evaluation ↔ 🎲 概率与统计
+### 6. 量化评估 / Quantitative Evaluation -> probabilistic（概率统计透镜）
 
 - 论点中的概念是否可以量化？
 - 如果涉及概率或统计，方法是否正确？
 - 样本量是否足够？是否存在选择偏差？
 
-### 7. 变换机会 / Transformation Opportunity ↔ 🔄 变换思想
+### 7. 变换机会 / Transformation Opportunity -> duality（对偶透镜）
 
 - 问题是否有更简的等价表示？当前表示是否最自然？
 - 是否存在变换(傅里叶/拉普拉斯/生成函数等)可简化问题？
 - 对偶或等价重述是否揭示了隐藏结构？
-- （v2）变换是否把不友好的运算变成 GPU 友好的运算（如卷积→GEMM）？
+- 变换是否把不友好的运算变成 GPU 友好的运算（如卷积→GEMM）？
 
-### 8. 对称性利用 / Symmetry Exploitation ↔ ⚛️ 对称与不变性
+### 8. 对称性利用 / Symmetry Exploitation -> symmetry（对称透镜）
 
 - 问题是否有隐藏对称性可降低复杂度？
 - 不变量是否可简化分析或分类？
 - 是否遗漏了对称破缺的情况？
-- （v2）群作用是否可张量化、落到线性表示/GEMM？
+- 群作用是否可张量化、落到线性表示/GEMM？
 
-### 9. 归纳与类比审视 / Induction & Analogy Review ↔ 📈 归纳与类比
+### 9. 归纳与类比审视 / Induction & Analogy Review -> local-to-global（局部到整体透镜）
 
 - 归纳推理是否从足够多的实例出发？是否存在过度推广？
 - 类比是否在结构上真正相似，而非仅表面相似？
 - 是否有反例削弱归纳结论？
 
-### 10. 计算可行性 / Computational Feasibility ↔ 🖥️ 算法与计算思想
+### 10. 计算可行性 / Computational Feasibility -> algorithmic（算法透镜）
 
 - 若涉及计算，程序是否可保证终止？时间/空间复杂度是否可接受？
 - 问题是否属于NP-hard或不可判定类别？是否需要近似或启发式？
 - 数值方法是否收敛？精度是否足够？
 
-### 11. 信息结构审视 / Information Structure Review ↔ 📡 信息论思想
+### 11. 信息结构审视 / Information Structure Review -> probabilistic（概率统计透镜）+ `../knowledge-base/probability/`
 
 - 问题的信息结构是否清晰？是否存在冗余或缺失的信息？
 - 是否可以用信息熵、互信息等量化不确定性？
 - 信息传输或压缩的瓶颈是否被识别？
 
-### 12. 博弈与策略审视 / Game & Strategy Review ↔ 🎯 博弈论思想
+### 12. 博弈与策略审视 / Game & Strategy Review -> game（博弈透镜）
 
 - 若涉及多方互动，是否考虑了策略依赖性？
 - 是否存在纳什均衡？机制设计是否激励相容？
 - 是否忽略了博弈中的信息不对称？
 
-### 13. 因果链条审视 / Causal Chain Review ↔ 🔗 因果推断思想
+### 13. 因果链条审视 / Causal Chain Review -> causal（因果透镜）
 
 - 论证是否混淆了相关与因果？
 - 是否可以用干预框架或反事实推理验证因果方向？
 - 是否存在混杂变量或中介变量被忽略？
 
-### 14. 拓扑结构审视 / Topological Structure Review ↔ 🌀 拓扑思想
+### 14. 拓扑结构审视 / Topological Structure Review -> topological（拓扑透镜）
 
 - 问题的连通结构、边界行为是否被正确处理？
 - 是否存在拓扑障碍（空洞、纠缠）影响结论？
 - 连续变形下的不变性质是否提供了简化视角？
-- （v2）局部拓扑量是否可批量并行？全局精确同调是否被误塞进训练？
+- 局部拓扑量是否可批量并行？全局精确同调是否被误塞进训练？
 
-### 15. 反例与边界 / Counterexample & Boundary ↔ 🧮 离散与组合思想
+### 15. 反例与边界 / Counterexample & Boundary （通用维度）
 
 - 能否构造一个反例来推翻结论？
 - 在边界情况（极限情形）下结论是否成立？
 - 结论的适用范围是什么？是否存在未声明的例外？
 - 有限情况下的枚举是否穷尽？
 
-### 16. 工具选择与流程审视 / Tool-Selection & Flow Review ↔ 🧭 math-research-activator
+### 16. 工具选择与流程审视 / Tool-Selection & Flow Review -> math-research-activator
 
 - 审视维度的选择本身是否最优？是否遗漏了关键维度？
 - 是否选择了最适合问题性质的思想透镜，而非仅仅选择最熟悉的？
-- （v2）是否遵循激活器主流程：**诊断 → 现代数学结构映射 → 思想透镜路由 → GPU 筛选**？是否跳过了诊断就堆数学科普？
+- 是否遵循激活器主流程：**意图诊断 → 透镜路由 → 知识调用 → 设计翻译 → GPU 筛选**？是否跳过了诊断就堆数学科普？
 - 是否枚举了多个候选结构（而非只给一个）？
 - 若不确定该审视哪些维度，先调用 `/ask` 让激活器推荐最合适的 3–5 个审视维度。
 
-### 17. GPU 可行性审视 / GPU-Feasibility Review ↔ `references/gpu-friendly-math.md`
+### 17. GPU 可行性审视 / GPU-Feasibility Review -> `../references/gpu-friendly-math.md`
 
 > 产出涉及算法/算子/训练/GPU 设计时为**强制项**。对应「双验收门」的第二道门。
 
-- 产出是否过 `references/gpu-friendly-math.md` 的**八维**？张量化 / GEMM 可映射 / 复杂度（亚二次）/ 显存与 KV-Cache / 低精度稳定 / 并行与通信 / 稀疏结构 / 算子融合——逐项给「友好/可改造/不友好」。
+- 产出是否过 `../references/gpu-friendly-math.md` 的**八维**？张量化 / GEMM 可映射 / 复杂度（亚二次）/ 显存与 KV-Cache / 低精度稳定 / 并行与通信 / 稀疏结构 / 算子融合——逐项给「友好/可改造/不友好」。
 - 是否存在「数学美但不可算」的结构？（典型：二阶法 Hessian 求逆、全局精确同调、符号因果发现、精确熵估计）——是否给出了可微/采样/低秩/近似改造？
 - 逆变换/数值部分是否稳定（条件数、病态）？
 - 显存与通信是否被评估（KV-Cache、分布式 all-reduce、optimizer state 精度）？
 
-### 18. 现代数学激活审视 / Modern-Math Activation Review ↔ `references/books/*`
+### 18. 现代数学激活审视 / Modern-Math Activation Review -> `../references/books/*`
 
 > 产出声称「把现代数学激活进算法」时为**强制项**。对应「双验收门」的第一道门（数学正确）+ 跨域激活质量。
 
 - 是否真的迁移了现代数学结构（代数几何/微分几何/李理论/抽象代数/矩阵分析/最优化），还是只用了经典微积分/线代打转？
 - 迁移的结构在数学上是否自洽、可微（或可松弛为可微）、有正确性保证？
-- 是否查阅了对应 `references/books/*.md` 蒸馏稿？深度需要原文时是否走了深挖回查协议（本机 `math_book/` PDF 自动搜索）？
+- 是否查阅了对应 `../references/books/*.md` 蒸馏稿？深度需要原文时是否走了深挖回查协议（本机 `math_book/` PDF 自动搜索）？
 - 迁移是否是「跨领域激活」（结构本就在那里，只差一次跨域映射），还是生搬硬套（只借名词不借结构）？
 - 产出是否同时通过**双验收门**：数学正确 **AND**（八维友好或可改造）？未同时通过的候选是否被剔除？
 
@@ -170,7 +170,7 @@
 
 ## 输出格式
 
-建议按以下结构进行报告。审视与实现并列呈现，实现部分不是审视的附属，而是对问题的正面回应。
+以下结构是完整报告模板，不是默认输出。短问题优先给“结论 + 致命/重要问题 + 修法 + 验证”，只有在用户要求完整审查、论文级审稿或多候选设计时才展开所有小节。审视与实现并列呈现，实现部分不是审视的附属，而是对问题的正面回应。
 
 ```
 ## 审视与实现报告
@@ -184,7 +184,7 @@
 - [列出本次选择深入审视的 3–5 个维度及原因；若涉算法/GPU，标注 17/18 已纳入]
 
 #### 双验收门结果
-- [候选1]: 数学正确[✓/✗] | GPU 八维[友好/可改造/不友好] | 通过[是/否]
+- [候选1]: 数学正确[v/x] | GPU 八维[友好/可改造/不友好] | 通过[是/否]
 - [候选2]: ...
 
 #### 做得好的地方

package/commands/ask.en.md

@@ -0,0 +1,15 @@
+---
+name: ask
+description: |
+  Math Research OS entry: auto-diagnose user intent, route to thinking lenses, math knowledge base, or design translation layer.
+---
+
+## Language Routing (inline)
+
+Determine primary language: judge by sentence frame, verbs, mood particles. AI/math/engineering terms (attention, loss, routing, etc.) do not count as language signals. Code, paths, formulas do not count. When CN/EN ratio is close, follow the previous turn's language; default to Chinese if no context. Explicit "in English/in Chinese" takes priority.
+
+- Chinese primary → load `../skills/math-research-activator/SKILL.md`
+- English primary → load `../skills/math-research-activator/SKILL.en.md`
+
+Current question:
+$ARGUMENTS

package/commands/ask.md

@@ -5,7 +5,12 @@ description: |
   English: Math Research OS entry: auto-diagnose user intent, route to thinking lenses, math knowledge base, or design translation layer.
 ---
 
-若用户消息为英文，读取并遵循 `../skills/math-research-activator/SKILL.en.md`；否则读取并遵循 `../skills/math-research-activator/SKILL.md`。
+## 语言路由（内联）
+
+判定主语言：看句式、动词、语气词的主框架。AI/数学/工程术语（attention、loss、routing 等）不计入语言判定。代码、路径、公式不计入。中英比例接近时沿用上一轮语言，无上下文默认中文。显式"用英文/用中文"优先。
+
+- 中文主语言 → 读取 `../skills/math-research-activator/SKILL.md`
+- 英文主语言 → 读取 `../skills/math-research-activator/SKILL.en.md`
 
 当前问题：
 $ARGUMENTS