math-skill 3.2.0 → 3.3.0

package/agents/math-critic.en.md

@@ -1,12 +1,12 @@
 # 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.
+> **File routing**: Follow the language routing rules in root `../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. 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 serve as an **acceptance gatekeeper**: require mathematical correctness first; check GPU/engineering feasibility only when the deliverable involves algorithm, operator, training, or inference implementation. Pure concept queries and pure cryptographic security reviews must not use the GPU checklist as an acceptance gate.
 
-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.
+You should give equal weight to two categories of responsibility: on one hand, scrutinize the chain of reasoning, the basis of assumptions, model applicability, and any task-relevant computational/engineering constraints; on the other hand, when the user explicitly requires it, provide practical mathematical derivations, implementation frameworks, or proof details.
 
 ## Applicable Scenarios
 
@@ -14,7 +14,7 @@ You should give equal weight to two categories of responsibility: on one hand, s
 - Evaluating whether mathematical models, assumptions, and derivations are self-consistent
 - Analyzing implicit mathematical risks and GPU feasibility in algorithm/operator/training designs
 - Verifying whether computational or statistical conclusions hold
-- Gatekeeping "modern math activation" deliverables: checking whether structure mappings are correct and whether they pass the dual-acceptance gate
+- Gatekeeping "modern math activation" deliverables: checking whether structure mappings are correct and whether they satisfy mathematical correctness plus task-relevant engineering constraints
 - Evaluating logic, probability, optimization, and mechanism design in real-world problems
 
 ## Inapplicable Scenarios
@@ -26,7 +26,20 @@ You should give equal weight to two categories of responsibility: on one hand, s
 
 ## Review Dimensions
 
-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–19 are cross-cutting: tool selection, GPU feasibility, modern math activation, and cryptographic security. **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**; if the deliverable involves cryptographic constructions / security proofs / protocols, **Dimension 19 (Cryptographic Security) is a mandatory checkpoint**.
+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–19 are cross-cutting: tool selection, GPU feasibility, modern math activation, and cryptographic security. **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.
+
+### Dimension Layering (since v3.2.1; aligned with Domain Router in v3.3.0)
+
+To reduce Agent cognitive load and guide dimension selection, the 19 dimensions are organized into four tiers:
+
+| Tier | Dimensions | Selection Strategy |
+|------|------------|-------------------|
+| **Core tier** (in-depth for most problems) | 1 Assumption Review, 3 Logic Check, 4 Model Applicability, 15 Counterexample & Boundary | Select at least 2 core dimensions per review |
+| **Situational tier** (select 2-3 by problem nature) | 2 Abstraction Level, 5 Optimization Quality, 6 Quantitative Evaluation, 7 Transformation Opportunity, 8 Symmetry Exploitation, 9 Induction & Analogy, 10 Computational Feasibility, 11 Information Structure, 12 Game & Strategy, 13 Causal Chain, 14 Topological Structure | Match to relevant lenses by problem type |
+| **Mandatory tier** (must-select when triggered) | 17 GPU Feasibility (mandatory when algorithm/operator/GPU is involved), 18 Modern Math Activation (mandatory when "activating modern math" is claimed), 19 Cryptographic Security (mandatory for crypto constructions/proofs/protocols) | Cannot be skipped when trigger conditions are met |
+| **Meta tier** (reviewing the review itself) | 16 Tool-Selection & Flow Review | When unsure which dimensions to pick, invoke this dimension first for self-check |
+
+If the deliverable involves algorithm/operator/GPU design, **Dimension 17 (GPU) is mandatory**. Dimension 18 is mandatory only when the deliverable claims to transfer or activate a modern mathematical structure. If it involves cryptographic constructions, proofs, or protocols, **Dimension 19 (Cryptographic Security) is mandatory**.
 
 ### 1. Assumption Review -> axiomatization lens
 
@@ -134,26 +147,26 @@ The first 15 dimensions cover the core review angles — assumptions, logic, mod
 
 ### 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."
+> **Mandatory** when the deliverable involves algorithm/operator/training/GPU design. Corresponds to the relevant engineering-feasibility checks; mark unrelated dimensions `N/A` and do not treat them as vetoes.
 
-- 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."
+- Evaluate only the applicable dimensions in `../references/gpu-friendly-math.en.md`: tensorization, GEMM-mappability, complexity, memory/KV cache, low-precision stability, parallelism/communication, sparsity, and fusion. Mark irrelevant dimensions `N/A`; quantify decisive items with shapes, operation counts, bytes, or communication volume. GEMM-mappability alone does not imply speed.
 - 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/*.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.
+> **Mandatory** when the deliverable claims to "activate modern mathematics into algorithms." Corresponds to mathematical-correctness review plus cross-domain activation quality; irrelevant GPU dimensions must not veto exploratory candidates.
 
 - 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/*.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?
+- Is the deliverable mathematically correct and compatible with the task-critical engineering constraints? Irrelevant GPU dimensions must not reject a candidate, and experimental cross-domain mappings must be labeled as hypotheses rather than established theorems.
 
-### 19. Cryptographic Security Review -> `../references/books/` (3 crypto books)
+### 19. Cryptographic Security Review -> `../knowledge-base/cryptography/` first, then `../references/books/` if needed
 
-> **Mandatory** when the deliverable involves cryptographic constructions / security proofs / protocol design (triggered when Domain Router determines the problem is cryptography or AI×crypto intersection). Corresponds to the cryptographic version of the "dual-acceptance gate": security definitions correct **AND** reduction tightness acceptable.
+> **Mandatory** when the deliverable involves cryptographic constructions / security proofs / protocol design (triggered when Domain Router determines the problem is cryptography or AI×crypto intersection). Cryptographic acceptance means: security definitions correct **AND** reduction tightness acceptable. Load relevant crypto anchors first; open crypto books only when cards are insufficient, theorem conditions need checking, or the user asks for sources. Never use the GPU checklist as a security gate.
 
 - **Security definitions**: Is the security goal defined via a formal attack game? Does the threat-model tier (CPA/CCA/AE/EUF-CMA) match the requirement? Avoid "intuitively secure" hand-waving.
 - **Reduction tightness**: How large is Q in the reduction loss ε_scheme ≈ Q·ε_assumption? Are parameters compensated? Does the proof claim "loose reduction = secure"?
@@ -161,7 +174,7 @@ The first 15 dimensions cover the core review angles — assumptions, logic, mod
 - **Composition & implementation pitfalls**: Is EtM/MtE/EaM chosen correctly? Are keys independent? Are IVs/nonces unique? Is MAC comparison constant-time? Is context (identity/transcript) bound?
 - **Anti-pattern check**: Is ROM treated as an absolute guarantee? Is deterministic encryption treated as CPA-secure? Is Merkle-Damgård treated as ROM? Plain RSA signatures?
 - **Cross-domain transfer validity** (AI×crypto only): When transferring cryptographic concepts to ML (e.g., PRF for watermarking, reductions for robustness certificates), are security semantics preserved, or is only terminology borrowed? Are assumptions still achievable after transfer?
-- **Domain Router consistency**: Does a pure crypto problem avoid loading AI design-patterns? Does a pure AI problem avoid loading crypto books? Does an intersection problem load both and annotate intersection points?
+- **Domain Router consistency**: Does a pure crypto problem avoid loading AI design-patterns? Does a pure AI problem avoid loading `../knowledge-base/cryptography/` and crypto books? Does an intersection problem load only the material needed at the intersection and emit the four-tuple?
 
 ## Workflow
 
@@ -169,9 +182,9 @@ The first 15 dimensions cover the core review angles — assumptions, logic, mod
 
 1. **Summarize the conclusion**: First, state the core claim of the argument or proposal in one sentence.
 2. **List assumptions**: Enumerate all explicit, implicit, and background assumptions one by one.
-3. **Select dimensions**: Based on the nature of the problem, choose the 3-5 most relevant review dimensions from the nineteen for in-depth inspection; if algorithm/GPU design is involved, **Dimensions 17 and 18 are mandatory**; if cryptography is involved, **Dimension 19 is mandatory**. The remaining dimensions may be briefly mentioned or skipped.
+3. **Select dimensions**: Choose the 3-5 most relevant dimensions. If algorithm/GPU design is involved, **Dimension 17 is mandatory**; if modern-math activation is explicitly claimed, Dimension 18 is mandatory; if cryptography is involved, **Dimension 19 is mandatory**.
 4. **Check the logical chain**: Verify whether the reasoning is complete and whether there are any leaps.
-5. **Apply the dual-acceptance gate**: For each candidate deliverable, separately assess mathematical correctness and GPU feasibility; retain only those that pass both.
+5. **Apply the acceptance gates**: Check mathematical correctness first, then the task-relevant engineering constraints. Mark irrelevant dimensions `N/A`; an exploratory candidate may remain if clearly downgraded and paired with a validation plan.
 6. **Assess severity**: Classify the impact of discovered issues on the reliability of the conclusion.
 
 ### Implementation Phase
@@ -195,9 +208,10 @@ The structure below is the full-report template, not the default response. For s
 #### Dimensions Focused on in This Review
 - [List the 3-5 dimensions selected for in-depth review and the rationale; if algorithm/GPU is involved, note that Dimensions 17/18 are included; if cryptography is involved, note that Dimension 19 is included]
 
-#### Dual-Acceptance Gate Results
-- [Candidate 1]: Math correctness [pass/fail] | GPU eight-dimension [friendly / retrofittable / unfriendly] | Passed [yes/no]
-- [Candidate 2]: ...
+#### Acceptance Results
+- Mathematical correctness: [pass / conditional pass / fail]
+- Task-relevant engineering constraints (if applicable): [pass / N/A / needs retrofit]
+- Cryptographic security (if applicable): [pass / conditional pass / fail / N/A]
 
 #### Strengths
 - [Specific commendations]
@@ -231,7 +245,7 @@ The structure below is the full-report template, not the default response. For s
 - [The thinking toolkits actually used in this review and implementation, and where each was applied]
 
 ### Overall Assessment
-- [Whether the objective was met + primary correction path + dual-acceptance gate result]
+- [Whether the objective was met + primary correction path + acceptance result]
 ```
 
 Notes:

package/agents/math-critic.md

@@ -1,12 +1,12 @@
 # 数学审视子 Agent / Math Critic Sub-Agent
 
-> **语言路由**：按 `../skills/math-research-activator/SKILL.md` 中的语言路由规则判定主语言。英文主语言 → 读取 `math-critic.en.md`，英文输出；中文主语言 → 继续使用本文件。
+> **语言路由**：按根目录 `../SKILL.md` 中的语言路由规则判定主语言。英文主语言 → 读取 `math-critic.en.md`，英文输出；中文主语言 → 继续使用本文件。
 
 ## 角色
 
-你是一个兼具审查与实现能力的数学助手。主要任务是从数学角度评估论点、方案或结论的可靠性与适用性，同时在必要时提供具体的实现思路、解题方案或证明步骤。你还兼任**双验收门把关人**：确保每个产出同时满足「math beautiful × GPU friendly」。
+你是一个兼具审查与实现能力的数学助手。主要任务是从数学角度评估论点、方案或结论的可靠性与适用性，同时在必要时提供具体的实现思路、解题方案或证明步骤。你兼任**验收把关人**：先保证数学正确；仅当产出涉及算法/算子/训练/推理实现时，再按相关维度检查 GPU/工程可行性。纯概念查询与纯密码安全审查不以 GPU 清单作验收门。
 
-你应并列考虑两类职责：一方面审视论证链条、假设依据、模型适用性、计算可行性与 **GPU 可行性**；另一方面在用户明确需要时，给出实际的数学推导、实现框架或证明细节。
+你应并列考虑两类职责：一方面审视论证链条、假设依据、模型适用性与必要的计算/工程可行性；另一方面在用户明确需要时，给出实际的数学推导、实现框架或证明细节。
 
 ## 适用场景
 
@@ -14,7 +14,7 @@
 - 评估数学模型、假设、推导过程是否自洽
 - 分析算法/算子/训练设计中的隐含数学风险与 GPU 可行性
 - 验证计算/统计结论是否成立
-- 把关「现代数学激活」产出：结构映射是否正确、是否过双验收门
+- 把关「现代数学激活」产出：结构映射是否正确、是否满足数学正确性与任务相关的工程约束
 - 评估现实问题中的逻辑、概率、优化和机制设计
 
 ## 不适用场景
@@ -26,7 +26,20 @@
 
 ## 审视维度
 
-前 15 个维度覆盖假设、逻辑、模型、计算等核心审视角度（多数对应 `../lenses/` 中的 v3 思想透镜），第 16–19 维为横切维度：工具选择、GPU 可行性、现代数学激活、密码学安全。**不需要机械地逐一检查所有维度**——应根据问题性质和用户关注点，选择最相关的维度深入审视，其余可简略提及或跳过。若产出涉及算法/算子/GPU 设计，**第 17（GPU）与第 18（现代数学激活）维为强制检查项**；若产出涉及密码学构造/安全证明/协议，**第 19（密码学安全）维为强制检查项**。
+前 15 个维度覆盖假设、逻辑、模型、计算等核心审视角度（多数对应 `../lenses/` 中的 v3 思想透镜），第 16–19 维为横切维度：工具选择、GPU 可行性、现代数学激活、密码学安全。**不需要机械地逐一检查所有维度**——应根据问题性质和用户关注点，选择最相关的维度深入审视，其余可简略提及或跳过。
+
+### 维度分层（v3.2.1 起；v3.3.0 对齐 Domain Router）
+
+为降低 Agent 的认知负担并指导维度选择，19 维分为四层：
+
+| 层级 | 维度 | 选择策略 |
+|------|------|---------|
+| **核心层**（多数问题都应深入检查） | 1 假设审查、3 逻辑检查、4 模型适用性、15 反例与边界 | 每次审视至少选 2 个核心维度 |
+| **情境层**（按问题性质选择 2-3 个） | 2 抽象层级、5 优化质量、6 量化评估、7 变换机会、8 对称性利用、9 归纳与类比、10 计算可行性、11 信息结构、12 博弈与策略、13 因果链条、14 拓扑结构 | 根据问题类型匹配相关透镜 |
+| **强制层**（满足触发条件必选） | 17 GPU 可行性（涉算法/算子/GPU 时必选）、18 现代数学激活（涉"激活现代数学"声称时必选）、19 密码学安全（涉密码学构造/证明/协议时必选） | 触发条件满足时不可跳过 |
+| **元层**（审视审视本身） | 16 工具选择与流程审视 | 当不确定选哪些维度时，先调用此维度自检 |
+
+若产出涉及算法/算子/GPU 设计，**第 17（GPU）为强制检查项**；只有在产出声称迁移或激活现代数学结构时，第 18 维才强制。若产出涉及密码学构造/安全证明/协议，**第 19（密码学安全）维为强制检查项**。
 
 ### 1. 假设审查 / Assumption Review -> axiomatization（公理化透镜）
 
@@ -134,26 +147,26 @@
 
 ### 17. GPU 可行性审视 / GPU-Feasibility Review -> `../references/gpu-friendly-math.md`
 
-> 产出涉及算法/算子/训练/GPU 设计时为**强制项**。对应「双验收门」的第二道门。
+> 产出涉及算法/算子/训练/GPU 设计时为**强制项**。对应工程验收的相关维度检查；无关维度标 `N/A`，不作否决项。
 
-- 产出是否过 `../references/gpu-friendly-math.md` 的**八维**？张量化 / GEMM 可映射 / 复杂度（亚二次）/ 显存与 KV-Cache / 低精度稳定 / 并行与通信 / 稀疏结构 / 算子融合——逐项给「友好/可改造/不友好」。
+- 只评估 `../references/gpu-friendly-math.md` 中与该候选有关的维度：张量化 / GEMM 可映射 / 复杂度 / 显存与 KV-Cache / 低精度稳定 / 并行与通信 / 稀疏结构 / 算子融合。无关项标 `N/A`，关键项应给形状、复杂度、字节量或通信量等可核查信号；不能把“可写成 GEMM”直接等同于“更快”。
 - 是否存在「数学美但不可算」的结构？（典型：二阶法 Hessian 求逆、全局精确同调、符号因果发现、精确熵估计）——是否给出了可微/采样/低秩/近似改造？
 - 逆变换/数值部分是否稳定（条件数、病态）？
 - 显存与通信是否被评估（KV-Cache、分布式 all-reduce、optimizer state 精度）？
 
 ### 18. 现代数学激活审视 / Modern-Math Activation Review -> `../references/books/*`
 
-> 产出声称「把现代数学激活进算法」时为**强制项**。对应「双验收门」的第一道门（数学正确）+ 跨域激活质量。
+> 产出声称「把现代数学激活进算法」时为**强制项**。对应数学正确性检查 + 跨域激活质量；不相关 GPU 维度不得否决探索性候选。
 
 - 是否真的迁移了现代数学结构（代数几何/微分几何/李理论/抽象代数/矩阵分析/最优化），还是只用了经典微积分/线代打转？
 - 迁移的结构在数学上是否自洽、可微（或可松弛为可微）、有正确性保证？
 - 是否查阅了对应 `../references/books/*.md` 蒸馏稿？深度需要原文时是否走了深挖回查协议（本机 `math_book/` PDF 自动搜索）？
 - 迁移是否是「跨领域激活」（结构本就在那里，只差一次跨域映射），还是生搬硬套（只借名词不借结构）？
-- 产出是否同时通过**双验收门**：数学正确 **AND**（八维友好或可改造）？未同时通过的候选是否被剔除？
+- 产出是否同时满足数学正确性与任务关键的工程约束？不相关 GPU 维度不得成为否决项；实验性跨域映射须标注为假设或研究方向，而不是伪装成已有定理。
 
-### 19. 密码学安全审视 / Cryptographic Security Review -> `../references/books/`（密码学 3 本）
+### 19. 密码学安全审视 / Cryptographic Security Review -> `../knowledge-base/cryptography/`（优先）+ `../references/books/`（锚点不足或需文献深度时）
 
-> 产出涉及密码学构造/安全证明/协议设计时为**强制项**（Domain Router 判定为密码学或 AI×密码交叉时触发）。对应「双验收门」的密码学版：安全定义正确 **AND** 归约紧度可接受。
+> 产出涉及密码学构造/安全证明/协议设计时为**强制项**（Domain Router 判定为密码学或 AI×密码交叉时触发）。对应密码学验收：安全定义正确 **AND** 归约紧度可接受。默认先读相关密码学锚点；只有卡片不足、需核对定理条件或用户要求出处时才加载密码书稿。不以 GPU 清单作安全门。
 
 - **安全定义**：是否用形式化攻击游戏定义了安全目标？威胁模型层级（CPA/CCA/AE/EUF-CMA）是否匹配需求？避免"直觉上安全"的空话。
 - **归约紧度**：归约损失 ε_scheme ≈ Q·ε_assumption 中的 Q 多大？参数是否补偿？是否声称"松归约=安全"？
@@ -161,7 +174,7 @@
 - **合成与实现陷阱**：EtM/MtE/EaM 选对了吗？密钥是否独立？IV/nonce 是否唯一？MAC 比较是否常数时间？上下文（身份/转录）是否绑定？
 - **反模式检查**：是否把 ROM 当绝对保证？确定性加密当 CPA 安全？Merkle-Damgård 当 ROM？plain RSA 签名？
 - **跨域迁移合理性**（仅 AI×密码交叉）：把密码学概念迁移到 ML（如 PRF 做水印、归约做鲁棒性证书）时，是否保留了安全语义，还是只借名词？迁移后假设是否仍可达成？
-- **Domain Router 一致性**：纯密码问题是否避免加载 AI design-patterns？纯 AI 问题是否避免加载密码学书稿？交叉问题是否双 domain 加载并标注交叉点？
+- **Domain Router 一致性**：纯密码问题是否避免加载 AI design-patterns？纯 AI 问题是否避免加载 `../knowledge-base/cryptography/` 与密码书稿？交叉问题是否只加载交叉点所需材料并标注四元组？
 
 ## 工作流程
 
@@ -169,9 +182,9 @@
 
 1. **概括结论**：先一句话概述该论点或方案的核心主张。
 2. **列出假设**：显式、隐式和背景假设一一列出。
-3. **选择维度**：根据问题性质，从十九个审视维度中选择最相关的 3–5 个深入检查；若涉算法/GPU，**第 17、18 维必选**；若涉密码学，**第 19 维必选**。其余可简略提及或跳过。
+3. **选择维度**：根据问题性质，从十九个审视维度中选择最相关的 3–5 个深入检查；若涉算法/GPU，**第 17 维必选**；若明确声称激活现代数学，第 18 维必选；若涉密码学，**第 19 维必选**。其余可简略提及或跳过。
 4. **检查逻辑链**：验证推理是否完整、是否存在跳跃。
-5. **过双验收门**：对每个候选产出，分别判数学正确性与 GPU 可行性，只保留同时通过的。
+5. **过验收门**：先判数学正确性，再检查与任务有关的工程硬约束；不相关维度标 `N/A`，探索性候选可以保留但须降级标注并给验证方法。
 6. **评估严重性**：根据发现的问题对结论可靠性的影响分级。
 
 ### 实现阶段
@@ -195,9 +208,11 @@
 #### 本次重点审视维度
 - [列出本次选择深入审视的 3–5 个维度及原因；若涉算法/GPU，标注 17/18 已纳入；若涉密码学，标注 19 已纳入]
 
-#### 双验收门结果
-- [候选1]: 数学正确[v/x] | GPU 八维[友好/可改造/不友好] | 通过[是/否]
-- [候选2]: ...
+#### 验收结果
+- 数学正确性：[通过 / 有条件通过 / 不通过]
+- 任务相关工程约束（若适用）：[通过 / N/A / 需改造]
+- 密码学安全（若适用）：[通过 / 有条件通过 / 不通过 / N/A]
+- 多候选时按上三项分行比较；无关 GPU 维度标 N/A，不作否决项
 
 #### 做得好的地方
 - [具体肯定]
@@ -231,7 +246,7 @@
 - [本次审视与实现中实际使用的思想透镜及其在哪个环节发挥作用]
 
 ### 总体评估
-- [是否达标 + 主要修正路径 + 双验收门是否通过]
+- [是否达标 + 主要修正路径 + 验收结果]
 ```
 
 说明：

package/commands/ask.en.md

@@ -8,8 +8,8 @@ description: |
 
 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`
+- Chinese primary → load `../SKILL.md`
+- English primary → load `../SKILL.en.md`
 
 Current question:
 $ARGUMENTS

package/commands/ask.md

@@ -9,8 +9,8 @@ description: |
 
 判定主语言：看句式、动词、语气词的主框架。AI/数学/工程术语（attention、loss、routing 等）不计入语言判定。代码、路径、公式不计入。中英比例接近时沿用上一轮语言，无上下文默认中文。显式"用英文/用中文"优先。
 
-- 中文主语言 → 读取 `../skills/math-research-activator/SKILL.md`
-- 英文主语言 → 读取 `../skills/math-research-activator/SKILL.en.md`
+- 中文主语言 → 读取 `../SKILL.md`
+- 英文主语言 → 读取 `../SKILL.en.md`
 
 当前问题：
 $ARGUMENTS

package/design-patterns/compression/low-rank-kv-cache.en.md

@@ -76,6 +76,7 @@ Method 3 - Layer-wise adaptive: allocate per-layer, per-head k based on effectiv
 - D4: KV-Cache from O(n·d) = 2048·128·2B ≈ 512KB; factor format O(n·k + k·d) ≈ 2048·64·2B + 64·128·2B ≈ 278KB (compression ratio ~1.8x); final-left-factor + coefficient format ($Q_{\text{final}} \in \mathbb{R}^{n \times k}$ columns + $B_k \in \mathbb{R}^{k \times d}$) total parameters $nk + kd$, compression ratio $nd/(nk+kd) = d/k \cdot 1/(1+d/n) \approx d/k = 2x$, V-Cache requires independent compression
 - D5: Truncated SVD under bf16 amplifies singular value errors near σ_k by ~κ(A), requires caution
 - D8: SVD → matmul can be fused; online updates use incremental SVD to avoid full recomputation
+- Sparsity: when the effective rank $r_{\text{eff}}$ is much smaller than $k$, the factor matrices $Q_{\text{final}}$ and $B_k$ have implicit sparsity in their spectral structure; explicit block-sparse formats are typically unnecessary for KV-Cache compression, but pruning near-zero coefficients in $B_k$ can use structured sparsity (block-sparse BSR) for additional memory savings
 
 ## Paper-Worthy Formulation
 "Building on the Eckart--Young--Mirsky theorem, we employ randomized SVD to project the KV-Cache onto a rank-$k$ subspace, compressing storage from $O(Ld)$ to $O(Lk + kd)$ (basis+coefficient format) at $O(Ldk)$ complexity. For standard softmax attention, low-rank factors cannot be interpreted as $k$ compressed tokens; softmax is still normalized over length $L$, but factorized GEMMs can compute logits and value aggregation without materializing a full $L \times d$ reconstruction, reducing the QK/AV inner dimension from $d$ to $k$. Only in linear attention, and only when compressing additive statistics such as $\phi(K)^T V$ and $\phi(K)^T\mathbf{1}$, can the historical state truly shrink from $L$ tokens to $k$ statistical factors. The Eckart--Young spectral-norm error gives $\sigma_{k+1}$ as the optimal rank-$k$ compression error for the K/V matrices themselves; the end-to-end attention output error bound further depends on query norms, the softmax Lipschitz constant, and the temperature parameter. The actual memory compression ratio depends on storage format and the independent V-Cache compression strategy."

package/design-patterns/loss/orthogonality-loss.en.md

@@ -45,14 +45,14 @@ Method 3 - Efficient Normalized-Gram Decorrelation:
 - **Block Computation**: When $K$ is large, perform mini-batch sampling over $(i,j)$ pairs, computing only $B$ out of $\binom{K}{2}$ pairs per step
 
 ## GPU Feasibility
-- **D1[v]**: Core operation is matmul ($W^T W$) -- standard GEMM, perfectly mapped to Tensor Cores
+- **D1[~]**: The core operation is expressible as GEMM, but small $Kr$ can be launch-bound or underutilize Tensor Cores.
 - **D2[v]**: Method 3 requires only 1 GEMM + 1 element-wise mask + Frobenius norm
-- **D3[v]**: $O(K \cdot d \cdot r)$ storage + $O(d \cdot r^2 \cdot K)$ or $O(K^2 \cdot d \cdot r^2)$ computation; negligible when $K < 16$
-- **D4[v]**: Intermediate matrices are on the order of $d \times r \cdot K$, adding no KV-Cache overhead
-- **D5[v]**: Frobenius norm is a sum of squares, safe under fp16; Grassmann SVD is recommended in fp32
-- **D6[v]**: The $K$ pairs are embarrassingly parallel; can be distributed across GPUs with all-reduce
-- **D7[v]**: If $W_k$ is itself sparse (e.g., MoE gate), masking further increases sparsity
-- **D8[v]**: matmul -> mask -> square -> sum can be fused into a single CUDA kernel
+- **D3[~]**: Method 3 costs $O(d(Kr)^2)$ for the GEMM and stores both $O(dKr)$ inputs and an $O((Kr)^2)$ Gram matrix. It is negligible only when $Kr$ is small enough.
+- **D4[~]**: It avoids an explicit $d\times d$ projector but materializes a $(Kr)\times(Kr)$ Gram matrix. KV-cache is not an applicable metric here.
+- **D5[~]**: Square sums can overflow or accumulate error in fp16; use fp32 accumulation. Run QR/SVD in at least fp32 and test gradients near repeated singular values.
+- **D6[~]**: The $\binom K2$ pairs are parallel. A reduction is needed only if this auxiliary loss is split across devices; keeping it local is usually cheaper.
+- **D7[N/A]**: This loss normally uses small dense matrices. Removing the Gram diagonal does not create useful structured sparsity, and sparse $W_k$ does not in general imply a sparse Gram matrix.
+- **D8[~]**: Masking and square-sum reduction can use a fused epilogue or a separate fused reduction, but they do not automatically fuse into a vendor GEMM kernel. Verify launch and memory-traffic savings with a profiler.
 
 ## Paper Phrasing
 "We introduce an orthogonality regularizer L_orth = Sum_{i<j} ||Q_i^T Q_j||_F^2, where Q_i is an orthonormal basis for W_i, to penalize overlap between feature subspaces of different submodules. This can reduce linear redundancy, but any redundancy-decay rate requires random-subspace or data-distribution assumptions and should be reported through principal angles, mutual-information estimates, or downstream ablations."

package/design-patterns/loss/orthogonality-loss.md

@@ -48,14 +48,14 @@ MoE 专家差异化、多任务 head 去相关。核心诉求：**让不同模
 - **分块计算**：当 K 很大时，对 (i,j) 对做 mini-batch 采样，每步只算 C(K,2) 中的 B 对
 
 ## GPU 可行性
-- **D1[v]**：核心操作为 matmul（W^T W）→ 标准 GEMM，完美映射 Tensor Core
+- **D1[~]**：核心操作可写成 GEMM；但 $Kr$ 很小时可能受 kernel launch 和低占用率限制，不能默认吃满 Tensor Core
 - **D2[v]**：方法3 只需 1 次 GEMM + 1 次 element-wise mask + Frobenius 范数
-- **D3[v]**：O(K·d·r) 存储 + O(d·r²·K) 或 O(K²·d·r²) 计算，K<16 时 negligible
-- **D4[v]**：中间矩阵 d×r·K 量级，不增加 KV-Cache 负担
-- **D5[v]**：Frobenius 范数为平方和，fp16 下 OK；Grassmann SVD 建议 fp32
-- **D6[v]**：K 对之间 embarrassingly parallel，可分 GPU 计算后 all-reduce
-- **D7[v]**：若 W_k 本身稀疏（如 MoE gate），mask 后稀疏度进一步提升
-- **D8[v]**：matmul → mask → square → sum 可融合为单个 CUDA kernel
+- **D3[~]**：方法3 的 GEMM 复杂度为 $O(d(Kr)^2)$，除输入 $O(dKr)$ 外还需 $O((Kr)^2)$ Gram 矩阵；只有 $Kr$ 相对较小时才可忽略
+- **D4[~]**：无需物化 $d\times d$ 投影，但会物化 $(Kr)\times(Kr)$ Gram；与 KV-Cache 无直接关系
+- **D5[~]**：平方和可能在 fp16 溢出或累积误差，建议 fp32 accumulation；QR/SVD 至少用 fp32，并对接近重根的梯度做稳定性测试
+- **D6[~]**：$\binom K2$ 个 pair 可并行；只有跨设备拆分该辅助损失时才需要归约，通常留在单卡更合算
+- **D7[N/A]**：该损失通常处理稠密小矩阵；mask 对角线不会产生值得利用的结构化稀疏，也不能由 $W_k$ 稀疏推出 Gram 稀疏
+- **D8[~]**：mask、平方和归约可做融合 epilogue 或单独 fused reduction，但不能默认与供应商 GEMM 合成一个 kernel；需以 profiler 验证 launch 与读写收益
 
 ## 论文表述方式
 "我们引入正交性正则项 L_orth = Σ_{i<j}‖Q_i^T Q_j‖_F²（其中 Q_i 为 W_i 的正交基），惩罚不同子模块特征子空间的重叠。该项可降低线性相关冗余，但冗余衰减速率需要随机子空间或数据分布假设支撑，应通过主角度、互信息估计或下游消融实测报告。"

package/knowledge-base/algebraic-geometry/grassmannian-plucker.en.md

@@ -0,0 +1,71 @@
+# Grassmannian and Plücker Embedding
+
+## Minimal Definition
+The Grassmannian $\mathsf{Gr}(k,n)$ is the parameter space of all $k$-dimensional linear subspaces of an $n$-dimensional vector space, a smooth projective variety of dimension $k(n-k)$. It parameterizes "subspaces" as geometric points, making subspace operations (projection, intersection, distance) representable as geometric operations.
+
+The Plücker embedding $\mathsf{Gr}(k,n)\hookrightarrow\mathbb{P}(\Lambda^k\mathbb{C}^n)$ maps each subspace $V=\mathsf{span}(v_1,\ldots,v_k)$ to the exterior product of its basis $[v_1\wedge\cdots\wedge v_k]$ (a highest-weight vector), representing subspaces as projective homogeneous coordinates. This is the standard way to turn geometric objects (subspaces) into algebraic objects (exterior algebra elements).
+
+## Core Formulas
+- **Grassmannian definition**: $\mathsf{Gr}(k,n)=\{k\text{-dim subspaces of }\mathbb{C}^n\}$
+- **Dimension**: $\dim\mathsf{Gr}(k,n)=k(n-k)$
+- **Plücker embedding**: $V=\mathsf{span}(v_1,\ldots,v_k)\mapsto[v_1\wedge\cdots\wedge v_k]\in\mathbb{P}(\Lambda^k\mathbb{C}^n)$
+- **Plücker coordinates**: $p_{i_1\cdots i_k}=\det(v_{i_j}^{(i)})$ (the minor of basis vectors at rows $i_1,\ldots,i_k$), totaling $\binom{n}{k}$
+- **Plücker relations** (quadratic relations satisfied by Plücker coordinates): $\sum_{j=1}^{k+1}(-1)^j p_{i_1\cdots\hat{i_j}\cdots i_{k+1}}\cdot p_{j_1\cdots j_{k-1}i_j}=0$
+- **Schubert cell decomposition**: $\mathsf{Gr}(k,n)=\bigsqcup_\lambda\Omega_\lambda$ (stratified by the subspace's relative position to a fixed flag)
+- **Plücker coordinates expand at low rank**: when $k$ approaches $n/2$, $\binom{n}{k}$ explodes; storing the basis $O(Lk)$ is far smaller than storing Plücker coordinates $O(\binom{L}{k})$ — the fundamental reason for "store basis, not Plücker coordinates, at low rank"
+- **Metric**: $\mathsf{Gr}(k,n)$ carries a natural Riemannian metric (projection metric); subspace distance $d(V,W)=\|\sin\Theta\|_F$ ($\Theta$ is the diagonal matrix of principal angles)
+
+## Applicable Problems
+- **Subspace representation compression**: KV-Cache, LoRA, low-rank attention's subspace parameterization — turning "store an $L\times d$ matrix" into "store a $k$-dim subspace point"
+- **Subspace clustering**: union of multiple low-rank subspaces
+- **Geometric structure analysis of representation learning**: feature spaces as subspace families, measuring inter-subspace distances
+- **Distance/metric definitions in feature spaces**: use projection metrics instead of Euclidean distance
+- **Multi-modal alignment**: alignment of per-modality representation subspaces
+- **Principal angles and vectors**: "angles" between subspaces as similarity measures
+
+## AI Design Translation
+- **Subspace representation parameterized by Grassmannian points**: treat KV-Cache, LoRA low-rank subspaces as points on $\mathsf{Gr}(k,d)$, storing basis vectors rather than full matrices
+- **Store basis, not Plücker coordinates, to avoid low-rank expansion**: when low-rank, $\binom{d}{k}\gg dk$; storing Plücker coordinates expands, storing the basis (factors of the exterior product vector) is more economical
+- **Principal angles as subspace similarity**: $d(V,W)=\|\sin\Theta\|_F$ as subspace distance for multi-view alignment
+- See `../../design-patterns/compression/low-rank-kv-cache.en.md`, `../../design-patterns/representation/shared-private-decomposition.en.md`, `../../design-patterns/representation/subspace-alignment.en.md` for corresponding patterns; if no match, label as "temporary design translation."
+
+## Engineering Feasibility
+Grassmannian has moderate GPU friendliness:
+- **D1[v]**: subspaces are represented by basis matrices $V\in\mathbb{R}^{n\times k}$, perfectly tensorizable
+- **D2[v]**: Plücker coordinate computation is exterior products (small matrix determinants), can use batched GEMM
+- **D3[~]**: Plücker coordinate count $\binom{n}{k}$ explodes at $k\approx n/2$; storing basis $O(nk)$ is far smaller than storing Plücker $O(\binom{n}{k})$
+- **D4[v]**: storing basis $O(Lk+kd)$ has high compression ratio; storing Plücker coordinates expands
+- **D5[v]**: orthogonal basis computation (QR) is stable under bf16; Plücker determinants should use fp32
+- **D6[v]**: multiple subspace points are fully parallel
+- **D7[~]**: subspace distance computation involves SVD (principal angles), can use randomized approximations
+- **D8[v]**: QR + exterior products + determinants are fusable
+**Key point**: store basis, not Plücker coordinates; use principal angles as similarity metric; low-rank compression ratio depends on the $k/d$ ratio
+
+## Risks and Failure Conditions
+- **Plücker coordinates explode when $k$ is large**: $\binom{n}{k}$ peaks at $k\approx n/2$ at $\sim 2^n/\sqrt{n}$, unstoreable
+- **Storing Plücker instead of basis expands at low rank**: this is the anti-pattern explicitly warned in `../../design-patterns/compression/low-rank-kv-cache.en.md` — at low rank, Plücker coordinate count far exceeds the basis dimension
+- **Subspace distance definition depends on metric choice**: projection metric, chordal metric, Fubini-Study metric give different results; the choice must be explicit
+- **Non-unique subspace representation**: the same subspace can be represented by different bases (basis choice freedom); must use equivalence classes or canonical forms (e.g., orthonormal bases after QR)
+- **Numerical instability of principal angle computation**: when subspaces nearly coincide, principal angles approach 0, and $\sin\Theta$ is numerically unstable
+- **Schubert cell stratification depends on flag choice**: Schubert decomposition depends on a fixed flag; different flags give different stratifications
+
+## Further References
+- Distilled notes: `../../references/books/algebraic-geometry-rising-sea.en.md`
+- Distilled notes: `../../references/books/matrix-analysis.en.md` (§2.6 SVD, principal angles)
+- Original book: Ravi Vakil, *The Rising Sea*, chapters on Grassmannians
+- Original book: Horn & Johnson, *Matrix Analysis* 2nd Ed., §2.5 (angles between subspaces)
+
+## Routing Extensions
+- If low-rank approximation is needed → `../matrix-analysis/low-rank-approximation.en.md` (Eckart-Young, randomized SVD)
+- If subspace projection is needed → `../matrix-analysis/projection.en.md` (orthogonal projection)
+- If matrix perturbation is needed → `../matrix-analysis/matrix-perturbation.en.md` (Davis-Kahan principal angle perturbation bounds)
+- If a geometric view is needed → `../../lenses/geometric.en.md` (metric/curvature)
+- If a symmetry view is needed → `../../lenses/symmetry.en.md` (GL(n) action)
+
+## Extensible Directions
+- Quantum Grassmannian: Grassmannian under quantum group action
+- Non-commutative geometry: non-commutative Grassmannian
+- Tannakian reconstruction: reconstructing a group from its representation category
+- Moduli spaces: curve moduli, vector bundle moduli
+- Hall algebra: Hall algebra structure on the Grassmannian
+- Persistent Grassmannian: subspace evolution combined with persistent homology

package/knowledge-base/algebraic-geometry/grassmannian-plucker.md

@@ -0,0 +1,71 @@
+# 格拉斯曼流形与 Plücker 嵌入 / Grassmannian and Plücker Embedding
+
+## 最小定义
+格拉斯曼流形 $\mathsf{Gr}(k,n)$ 是 $n$ 维向量空间中所有 $k$ 维线性子空间的参数空间，是一个 $k(n-k)$ 维光滑射影簇。它把"子空间"作为几何点参数化，使子空间运算（投影、求交、距离）可表示为几何运算。
+
+Plücker 嵌入 $\mathsf{Gr}(k,n)\hookrightarrow\mathbb{P}(\Lambda^k\mathbb{C}^n)$ 把每个子空间 $V=\mathsf{span}(v_1,\ldots,v_k)$ 映射为其基底的外积 $[v_1\wedge\cdots\wedge v_k]$（最高权向量），将子空间表示为射影齐次坐标。这是把几何对象（子空间）转化为代数对象（外代数元素）的标准方式。
+
+## 核心公式
+- **格拉斯曼流形定义**：$\mathsf{Gr}(k,n)=\{k\text{-dim subspaces of }\mathbb{C}^n\}$
+- **维数**：$\dim\mathsf{Gr}(k,n)=k(n-k)$
+- **Plücker 嵌入**：$V=\mathsf{span}(v_1,\ldots,v_k)\mapsto[v_1\wedge\cdots\wedge v_k]\in\mathbb{P}(\Lambda^k\mathbb{C}^n)$
+- **Plücker 坐标**：$p_{i_1\cdots i_k}=\det(v_{i_j}^{(i)})$（基底向量在 $i_1,\ldots,i_k$ 行上的子行列式），共 $\binom{n}{k}$ 个
+- **Plücker 关系**（Plücker 坐标满足的二次关系）：$\sum_{j=1}^{k+1}(-1)^j p_{i_1\cdots\hat{i_j}\cdots i_{k+1}}\cdot p_{j_1\cdots j_{k-1}i_j}=0$
+- **Schubert 胞腔分解**：$\mathsf{Gr}(k,n)=\bigsqcup_\lambda\Omega_\lambda$（按子空间与固定 flag 的相对位置分层）
+- **Plücker 坐标在低秩时反扩张**：当 $k$ 接近 $n/2$ 时 $\binom{n}{k}$ 急剧膨胀；存基底 $O(Lk)$ 远小于存 Plücker $O(\binom{L}{k})$——这是"低秩时存基底而非 Plücker 坐标"的根本原因
+- **度量**：$\mathsf{Gr}(k,n)$ 上有自然 Riemannian 度量（投影度量），子空间距离 $d(V,W)=\|\sin\Theta\|_F$（$\Theta$ 为主角度对角矩阵）
+
+## 适用问题
+- **子空间表示压缩**：KV-Cache、LoRA、低秩注意力的子空间参数化——把"存 $L\times d$ 矩阵"转为"存 $k$ 维子空间点"
+- **子空间聚类**：多个低秩子空间的并集表示
+- **表示学习的几何结构分析**：特征空间作为子空间族，度量子空间间距离
+- **特征空间中的距离/度量定义**：用投影度量而非欧氏距离
+- **多模态对齐**：各模态表示子空间的对齐
+- **主角度与主向量**：子空间间的"夹角"作为相似度度量
+
+## AI 设计翻译
+- **子空间表示用格拉斯曼点参数化**：把 KV-Cache、LoRA 的低秩子空间作为 $\mathsf{Gr}(k,d)$ 上的点，存基底向量而非完整矩阵
+- **存基底而非 Plücker 坐标避免低秩反扩张**：低秩时 $\binom{d}{k}\gg dk$，存 Plücker 坐标反扩张，存基底（外积向量的因子）更经济
+- **主角度作为子空间相似度**：$d(V,W)=\|\sin\Theta\|_F$ 作为子空间距离，用于多视图对齐
+- 对应设计模式见 `../../design-patterns/compression/low-rank-kv-cache.md`、`../../design-patterns/representation/shared-private-decomposition.md`、`../../design-patterns/representation/subspace-alignment.md`；无对应模式时标为"临时设计翻译"。
+
+## 工程可行性
+格拉斯曼流形 GPU 友好度中等：
+- **D1[v]**：子空间由基底矩阵 $V\in\mathbb{R}^{n\times k}$ 表示，完美张量化
+- **D2[v]**：Plücker 坐标计算是外积（小矩阵行列式），可用 batched GEMM
+- **D3[~]**：Plücker 坐标数 $\binom{n}{k}$ 在 $k\approx n/2$ 时爆炸；存基底 $O(nk)$ 远小于存 Plücker $O(\binom{n}{k})$
+- **D4[v]**：存基底 $O(Lk+kd)$ 压缩比高；存 Plücker 坐标反扩张
+- **D5[v]**：正交基底计算（QR）在 bf16 下稳定；Plücker 行列式建议 fp32
+- **D6[v]**：多个子空间点完全并行
+- **D7[~]**：子空间距离计算涉及 SVD（主角度），可用随机化近似
+- **D8[v]**：QR + 外积 + 行列式可融合
+**关键点**：存基底而非 Plücker 坐标；用主角度作为相似度度量；低秩时压缩比取决于 $k/d$ 比
+
+## 风险与失效条件
+- **Plücker 坐标在 $k$ 较大时维度爆炸**：$\binom{n}{k}$ 在 $k\approx n/2$ 时达到峰值 $\sim 2^n/\sqrt{n}$，不可存
+- **存 Plücker 而非基底在低秩时反扩张**：这是 `../../design-patterns/compression/low-rank-kv-cache.md` 中明确警告的反模式——低秩时 Plücker 坐标数远大于基底维度
+- **子空间距离定义依赖度量选择**：投影度量、Chordal 度量、Fubini-Study 度量给出不同结果，需明确选择
+- **子空间非唯一表示**：同一子空间可由不同基底表示（基底选择自由），需用等价类或规范形（如 QR 后的正交基）
+- **主角度计算的数值稳定性**：当子空间接近重合时主角度接近 0，$\sin\Theta$ 数值不稳定
+- **Schubert 胞腔分层的选择依赖**：Schubert 分解依赖固定 flag 的选择，不同 flag 给出不同分层
+
+## 深入参考
+- 蒸馏稿：`../../references/books/algebraic-geometry-rising-sea.md`
+- 蒸馏稿：`../../references/books/matrix-analysis.md`（§2.6 SVD、主角度）
+- 原书：Ravi Vakil, *The Rising Sea*, Ch on Grassmannians
+- 原书：Horn & Johnson, *Matrix Analysis* 2nd Ed., §2.5 (angles between subspaces)
+
+## 路由扩展
+- 若需要低秩近似 → `../matrix-analysis/low-rank-approximation.md`（Eckart-Young、随机化 SVD）
+- 若需要子空间投影 → `../matrix-analysis/projection.md`（正交投影）
+- 若需要矩阵扰动 → `../matrix-analysis/matrix-perturbation.md`（Davis-Kahan 主角度扰动界）
+- 若需要几何视角 → `../../lenses/geometric.md`（度量/曲率）
+- 若需要对称性视角 → `../../lenses/symmetry.md`（GL(n) 作用）
+
+## 可扩展方向
+- 量子 Grassmannian（quantum Grassmannian）：量子群作用下的 Grassmannian
+- 非交换几何（non-commutative geometry）：非交换 Grassmannian
+- Tannakian 重建（Tannakian reconstruction）：从表示范畴重建群
+- 模空间参数化（moduli spaces）：曲线模空间、矢量丛模空间
+- Hall 代数（Hall algebra）：Grassmannian 的 Hall 代数结构
+- 持续 Grassmannian（persistent Grassmannian）：结合持续同调的子空间演化

package/knowledge-base/algebraic-geometry/index.en.md

@@ -0,0 +1,47 @@
+# Algebraic Geometry Activation Index
+
+## Domain Signals
+Activate this domain when the problem involves:
+- Subspace parameterization: Grassmannian, Plücker embedding, Schubert cells
+- Local-to-global obstruction: sheaves, sheaf cohomology, Čech complex, H^i vanishing criteria
+- Geometric structure diagnosis: algebraic varieties, schemes, morphisms, fiber products, divisors, line bundles
+- Tropical geometry: piecewise-linear gating, tropical semiring, tropical algebra
+- Spectra and cohomology: Hodge decomposition, de Rham cohomology vs sheaf cohomology
+- Categorical structures: functors, natural transformations, Yoneda lemma, Tannakian reconstruction
+
+## Core Anchors
+- `sheaf-cohomology.en.md` — Sheaf cohomology (local-to-global obstruction diagnosis, Čech complex)
+- `grassmannian-plucker.en.md` — Grassmannian and Plücker embedding (subspace parameterization)
+
+## Extension Concepts
+When core anchors are insufficient, these concepts may require temporary activation:
+- Schemes and morphisms: affine schemes, projective schemes, proper morphism
+- Fiber bundles and vector bundles: sections, connections, curvature
+- Divisors and line bundles: Cartier divisors, Weil divisors, Picard group
+- Hodge theory: Hodge decomposition, Hodge spectral sequence, Calabi-Yau
+- Motives: pure motives, mixed motives, Voevodsky's category
+- Tropical geometry: tropical semiring, tropical polynomials, tropical curves
+- Algebraic groups: linear algebraic groups, Abelian varieties, Picard variety
+- Abelian varieties: Jacobian, Albanese variety
+- Stable maps and Gromov-Witten: moduli spaces, enumerative geometry
+- Characteristic classes: Chern classes, Pontryagin classes, Stiefel-Whitney classes
+- D-modules: differential operators on sheaves, geometric D-module theory
+
+## Reference Book Directions
+- `../../references/books/algebraic-geometry-rising-sea.en.md`: Ravi Vakil, *The Rising Sea*, a modern synthesis of algebraic geometry
+- `../../references/books/abstract-algebra.en.md`: Gallian, *Contemporary Abstract Algebra*, algebra foundations (groups/rings/fields)
+- Original book: Ravi Vakil, *The Rising Sea: Foundations of Algebraic Geometry*
+
+## AI Translation Directions
+- Sheaf cohomology → local-to-global reasoning on feature fields; H¹ as a multi-view fusion consistency measure
+- Grassmannian → subspace representation compression (KV-Cache, LoRA, low-rank attention's subspace parameterization)
+- Tropical geometry → piecewise-linear gating replacing discrete choice (Top-K → tropical max-plus)
+- Cohomology → structure-obstruction diagnosis (topological obstructions in representation spaces)
+- Schubert cells → subspace stratification and routing
+
+## Temporary Activation Rules
+When the required mathematics is not in core anchors:
+1. First check the extension concepts list for a match
+2. If matched, generate a temporary knowledge card using relevant lenses (categorical/local-to-global/topological/spectral/geometric)
+3. If unmatched, enter Knowledge Gap Protocol
+4. Tag the temporary card's domain as "AI" or "shared" for subsequent upgrade

package/knowledge-base/algebraic-geometry/index.md

@@ -0,0 +1,47 @@
+# 代数几何 激活索引 / Algebraic Geometry Activation Index
+
+## 领域信号
+当问题涉及以下信号时，激活本领域方向：
+- 子空间参数化：格拉斯曼流形、Plücker 嵌入、Schubert 胞腔
+- 局部到整体障碍：层、层的上同调、Čech 复形、H^i 消失判据
+- 几何结构诊断：代数簇、概形、态射、纤维积、除子、线丛
+- 热带几何：分段线性门控、tropical semiring、tropical 代数
+- 谱与上同调：Hodge 分解、de Rham 上同调与层上同调关系
+- 范畴论结构：函子、自然变换、Yoneda 引理、Tannakian 重建
+
+## 核心锚点
+- `sheaf-cohomology.md` — 层上同调（局部到整体障碍诊断，Čech 复形）
+- `grassmannian-plucker.md` — 格拉斯曼流形与 Plücker 嵌入（子空间参数化）
+
+## 扩展概念
+当核心锚点不够时，以下概念可能需要临时激活：
+- 概形与态射（schemes and morphisms）：仿射概形、射影概形、proper morphism
+- 纤维丛与向量丛（fiber bundles and vector bundles）：截面、联络、曲率
+- 除子与线丛（divisors and line bundles）：Cartier 除子、Weil 除子、Picard 群
+- Hodge 理论（Hodge theory）：Hodge 分解、Hodge 谱序列、Calabi-Yau
+- Motives（motives）：纯 motive、混合 motive、Voevodsky 的分类
+- 热带几何（tropical geometry）：tropical semiring、tropical 多项式、tropical 曲线
+- 代数群（algebraic groups）：线性代数群、Abelian 簇、Picard 簇
+- Abelian 簇（abelian varieties）：Jacobi 簇、Albanese 簇
+- 稳定映射与 Gromov-Witten（stable maps and Gromov-Witten）：模空间、枚举几何
+- 特征类（characteristic classes）：Chern 类、Pontryagin 类、Stiefel-Whitney 类
+- 层上的微分算子（D-modules）：D-模、微分代数方程的几何
+
+## 参考书方向
+- `../../references/books/algebraic-geometry-rising-sea.md`：Ravi Vakil, *The Rising Sea*，代数几何的现代综合
+- `../../references/books/abstract-algebra.md`：Gallian, *Contemporary Abstract Algebra*，代数基础（群/环/域）
+- 原书：Ravi Vakil, *The Rising Sea: Foundations of Algebraic Geometry*
+
+## AI 翻译方向
+- 层上同调 → 特征场上的局部到整体推理；H¹ 作为多视图融合一致性度量
+- 格拉斯曼 → 子空间表示压缩（KV-Cache、LoRA、低秩注意力的子空间参数化）
+- 热带几何 → 分段线性门控替代离散选择（Top-K → tropical max-plus）
+- 上同调 → 结构障碍诊断（表示空间中的拓扑障碍）
+- Schubert 胞腔 → 子空间分层与路由
+
+## 临时激活规则
+当问题需要的数学不在核心锚点中时：
+1. 先检查扩展概念中是否有匹配
+2. 若有，根据透镜（categorical/local-to-global/topological/spectral/geometric）生成临时知识卡
+3. 若无，进入 Knowledge Gap Protocol
+4. 临时卡标注 domain 为 "AI" 或 "shared"，便于后续升级