القائمة
Manage L2 constraint layer - knowledge stabilization, protection, and indexing
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Automatically discover modules and partition knowledge into modular structure
Create and manage L0 prescriptive design specs before writing code
Compile knowledge increments into project snapshot with conflict detection
Auto-scan project structure and sync L1 knowledge layer with codebase
Compress knowledge window by merging, deduping, and summarizing buffer entries
Flush knowledge buffer into versioned increment files with source tracing
| name | lore-constraint |
| description | Manage L2 constraint layer - knowledge stabilization, protection, and indexing |
| category | ai-context |
L2 是介于 L1（结构层）和 L3（过程层）之间的"稳定层"。它存储那些经过验证、长期有效、一旦错了影响大的知识。
L3 过程知识（高频变化）
↓ 多次验证 + 长期稳定
L2 约束知识（低频变化，高影响）
↓ 组织级约定 / 架构边界
L1 结构知识（代码可表达）
L2 的特点：
## L2 Constraints
### Architecture Boundaries
- 订单模块不能直接调用库存模块，必须通过 MQ
- 支付回调必须幂等，防止重复扣款
### Data Constraints
- order 表不能加唯一索引（并发写入场景）
- 用户 ID 必须通过 UserService 获取，禁止本地缓存
### Business Rules
- 图片最少 3 张（ICBU 发品要求）
- 类目预测失败时走 QP 兜底
### External Contracts
- HSF 接口 OpenApiCategoryPredictService 是对外接口，不可随意修改签名
/evolve 编译时，自动检测哪些 L3 知识可以提升为 L2：
提升条件（全部满足）：
自动标记：
### [PROMOTION CANDIDATE] 支付回调必须幂等
- 存在时间: 45 天
- 验证次数: 5 次
- 状态: pending_promotion
L2 提升需要人工确认（不能全自动）：
[AI-CONTEXT] 检测到 2 条知识可提升为 L2 约束：
1. "支付回调必须幂等" (45 天, 5 次验证)
2. "订单表不能加唯一索引" (60 天, 3 次验证)
是否确认提升？确认后修改需要更高阈值。
用户确认后，写入 .ai-context/constraints.md。
L2 知识变更需要更高阈值：
| 变更类型 | L3 阈值 | L2 阈值 |
|---|---|---|
| 新增 | 对话中说出即可 | 需要 L3 验证 + 人工确认 |
| 修改 | 新 increment 覆盖 | 需要 PR review + 2 人确认 |
| 删除 | 新 increment 推翻 | 需要 PR review + 架构师确认 |
实现方式：
pre-edit-guard.sh 检测到 L2 知识关联时，输出更强的警告/evolve 编译时，L2 变更需要额外的确认步骤L2 约束独立存储，不与 snapshot 混在一起：
.ai-context/
├── snapshot.md ← L1 + L3 混合（agent 入场读取）
├── constraints.md ← L2 独立（优先加载，高保护）
├── buffer.md
└── increments/
constraints.md 格式：
# L2 Constraints
> Last updated: 2026-04-24
> Total: 8 constraints
## Architecture Boundaries
### 订单-库存解耦
- 规则: 订单模块不能直接调用库存模块，必须通过 MQ
- 原因: 防止库存服务故障导致订单不可用
- 来源: 利普, 2026-03-15, 架构评审
- 验证: 5 次, 从未推翻
- 保护级别: high (修改需架构师确认)
## Data Constraints
### order 表无唯一索引
- 规则: order 表不能加唯一索引
- 原因: 并发写入场景，唯一索引会导致死锁
- 来源: 张三, 2026-02-20, 线上事故复盘
- 验证: 3 次, 从未推翻
- 保护级别: critical (修改需 CTO 确认)
session-start.sh 优先加载 constraints：
[AI-CONTEXT] Loading L2 constraints (8 rules)...
[AI-CONTEXT] Loading snapshot (L1 + L3)...
[AI-CONTEXT] Execute /health to validate...
优先级：L2 > L3 > L1。约束知识优先于过程知识。
/health 校验时，L2 知识有特殊处理：
| L2 状态 | 处理 |
|---|---|
| contradicted | 强制输出警告，不自动修复，等待人工裁决 |
| stale | 标记但保留，不删除 |
| healthy | 正常 |
L2 知识不会因为"代码里找不到"就标记 stale——它的权威性来自业务/架构约定，不是代码。
手动触发知识提升检查：
/constraint promote
→ 扫描 L3 知识，列出可提升候选
→ 等待用户确认
→ 写入 constraints.md
列出所有 L2 约束：
/constraint list
→ 输出 constraints.md 内容摘要
→ 按保护级别分组
检查文件是否违反 L2 约束：
/constraint check OrderService.java
→ 扫描代码
→ 检查是否违反"订单-库存解耦"约束
→ 输出结果
L2 约束层是 Lore 的"安全带"：