math-skill 3.2.0 → 3.3.1

package/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: math-research-activator
+description: |
+  数学研究路由器：为 AI 架构/算子设计、理论性质分析、数学结构迁移，以及密码学定义、构造、归约与协议审查，选择必要的数学透镜、知识锚点和设计检查。也用于与 AI 研究有关的数学查询。纯实现型 debug、重构、调参和一般代码审查不触发。
+  English: Route AI architecture/operator design, theoretical analysis, math-to-AI transfer, and cryptographic definitions, constructions, reductions, or protocol reviews to the minimum necessary mathematical lenses, anchors, and design checks. Do not use for implementation-only debugging, refactoring, tuning, or general code review.
+---
+
+# 数学研究路由器
+
+本文件是 Codex 的权威入口。按用户主语言回答；技术词、代码、路径和公式不决定语言。`SKILL.en.md` 只供 `/ask` 英文入口等显式英文兼容路径加载，两者不同时加载——在本文档内即可中英作答。
+
+## 目标与硬约束
+
+把问题路由到**最少但足够**的数学材料，并给出可证伪、带条件的结论。
+
+- 区分定理、建模假设、经验规律和探索性猜想；不得把后两者写成保证。
+- 数学锚点先讲数学结构；AI 设计模式和密码学安全语义分域加载。
+- 不因目录中存在材料而整目录加载。书稿只用于卡片不足、需核对定理条件或用户要求出处时。
+- 必须收敛到结论；不要只列视角、术语或加载清单。
+
+## 何时介入
+
+先看用户要求的**目标与保证**，不要按单个关键词投票。
+
+1. 若任务只要求修 import/shape/OOM、重构、改配置、调参、部署或一般代码质量审查，归为 **E 纯工程**，不介入。
+2. 若任务虽含代码，但要求验证数学正确性、复杂度、收敛性、数值稳定性或密码学安全性，仍应介入。
+3. 用户直接要求设计、分析、验证或解释相关数学时，任务信号本身足够；工作区文件只用于消歧，不是必需门槛。
+4. `/ask` 或显式点名本 skill 时，跳过自动触发判断，但仍排除与数学/安全语义无关的纯工程工作。
+
+| 场景 | 用户目标 | 最小路径 |
+|---|---|---|
+| A 分析 | 判断设计、假设或论证是否合理 | 1–2 透镜 → 条件/反例审查 |
+| B 设计 | 构造新机制、算子、loss、路由或协议 | 1–2 透镜 → 1–3 锚点 → 0–2 设计原型 → 审查 |
+| C 查询 | 理解与研究问题相关的数学概念 | 通常 1 张锚点 |
+| D 验证 | 判断公式、保证、归约或复杂度声称是否成立 | 1–2 锚点 → 条件/边界/反例 |
+| E 工程 | 仅实现与维护 | 不加载本系统材料 |
+
+## Domain Router
+
+按目标对象和所需保证判域：
+
+| 域 | 加载范围 | 禁止污染 |
+|---|---|---|
+| 共用数学 | `lenses/` + `knowledge-base/` 中除 `knowledge-base/cryptography/` 外的 8 域 33 锚点 | 不自动加载 AI 模式或密码书稿 |
+| AI 研究 | 共用数学按需 + `design-patterns/` 中相关的 0–2 个原型 | 不加载密码学锚点/书稿 |
+| 密码学 | `knowledge-base/cryptography/` 中相关锚点；不足时再查 3 本密码书稿；共用数学按结构按需 | 不加载 AI 设计模式，不以 GPU 清单作安全门 |
+| AI×密码 | 同时满足“密码学原语/形式安全性质”和“AI 对象/功能需求”，且问题要求迁移或组合 | 只加载交叉点实际需要的两侧材料 |
+
+判定细则：
+
+- `hashing`、`attack`、`security` 等表面词不足以判密码域。特征哈希通常是 AI；对抗样本只有在要求攻击游戏、证书或归约时才进入密码/交叉域。
+- 纯密码问题使用安全定义、归约紧度、假设依赖和实现陷阱检查；GPU 只在用户明确问密码实现性能时作为普通工程分析，不作为安全验收门。
+- 交叉问题输出一次四元组：①原语+安全性质；②AI 对象+功能需求；③迁移方向；④迁移后假设是否仍可满足。非交叉问题不要输出该模板。
+
+完整索引与语言边界例见 `references/skill-index.md`；不要为了路由而默认读取它。
+
+## 渐进加载与 token 预算
+
+默认遵循下列上限；只有用户要求全面审查、多个候选或原材料确实不足时才扩展。
+
+| 场景 | 默认加载预算 | 默认回答预算 |
+|---|---|---|
+| A | 1–2 透镜；必要时 1 锚点 | 结论 + 2–4 个关键问题 + 修法 |
+| B | 1–2 透镜、1–3 锚点、0–2 模式 | 1 个主方案；备选只写关键差异 |
+| C | 1 锚点 | 定义 + 公式/直觉 + 适用边界 |
+| D | 1–2 锚点 | 短结论 + 成立条件 + 不能保证什么 |
+
+- 不复述卡片全文，不展示内部加载路径，除非用户在调试路由、问题跨域或存在歧义。
+- 简单问题不套完整报告模板；每个标题必须承载新信息。
+- 用户只问概念时，不主动展开 AI 翻译、GPU 评分或长参考书目。
+- 若一个锚点已足够，不再加载同主题书稿。若卡片和自身可靠知识足够，不进入 PDF。
+
+## 执行流程
+
+1. **判场景与域**：提取目标、约束、需要保留/抑制的性质和所求保证。
+2. **选最小材料**：只读最相关文件；目录表见 `references/skill-index.md`，但仅在无法从文件名定位时读取索引。
+3. **求解或设计**：先写数学对象、假设和可检验目标，再做 AI/密码翻译。
+4. **审查**：至少检查假设、逻辑和边界；涉及算法实现再检查复杂度/显存/数值稳定，涉及密码再检查安全定义/归约/假设。
+5. **结论优先输出**：先回答“成立吗/选什么/下一步是什么”，再给必要依据。
+
+### AI 设计
+
+- 设计原型是翻译示例，不是可直接复制的完整模型。
+- 只有涉及算子、训练或推理实现时才读取 `references/gpu-friendly-math.md`。
+- GPU 输出只报告适用且会改变决策的维度；至少量化主要 FLOPs、峰值中间张量/状态量和低精度风险。无关维度标 N/A，不为凑八项制造文字。
+
+### 密码学
+
+- 先明确攻击者能力、安全游戏和优势，再谈“安全”。
+- 把标准模型中的定理、基于原语的归约、具体算法（如 AES）的经验假设分开。
+- 报告归约损失和参数补偿；检查 nonce/IV、密钥分离、组合顺序、侧信道等实现前提。
+
+### Knowledge Gap Protocol
+
+现有锚点不覆盖时，不得强行套卡：
+
+1. 指明缺口类型；2. 回退到 1–2 个透镜；3. 给出具体概念/定理族；4. 写最小临时卡；5. 需要时做设计翻译；6. 高频缺口才建议升级正式卡。
+
+临时卡必须标注 domain、来源（Agent 推断/透镜推导/参考外推/待外部验证）、置信度和未核验结论。详细字段见 `references/skill-index.md`。
+
+## 输出质量检查
+
+提交答案前确认：
+
+- 结论是否回答了用户真正的问题，而非只展示数学知识？
+- 每个“保证/最优/安全/稳定/等价”是否附有充分条件？
+- 是否给出至少一个边界、反例或可证伪实验？
+- 是否把相关性、类比或经验现象误写成因果/定理？
+- 是否加载或输出了无关域内容？
+- 是否能删去一节而不损失决策信息？能则删。
+
+用户要求论文级或全面审查时，再读取 `agents/math-critic.md`；普通 A/B/D 场景使用上述检查即可，避免默认加载完整 19 维模板。
+
+## 直接资源
+
+- 透镜：`lenses/`
+- 共用数学锚点：`knowledge-base/`（排除 `knowledge-base/cryptography/`）
+- 密码学锚点：`knowledge-base/cryptography/`
+- AI 设计原型：`design-patterns/`
+- GPU 深查：`references/gpu-friendly-math.md`
+- 深度审查：`agents/math-critic.md`
+- 书稿：`references/books/`（仅按需）

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,9 @@ 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` (canonical entry, can answer in either language)
+- English primary → load `../SKILL.en.md` (English compatibility entry)
+- Do not load both simultaneously
 
 Current question:
 $ARGUMENTS

package/commands/ask.md

@@ -9,8 +9,9 @@ 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