背景
DESIGN §5.1 规定 Relevance Gate Stage 1 会把所有 enforcement: mandatory 的 asset 无条件放进 packed prompt。若 mandatory asset 本身超过 budget，则 hard error。
同时 DESIGN §8.1 invariant 11 又要求 engram 不对 asset 数量、scope 数量、asset 大小设置硬上限。
问题
这两个目标放在一起会产生长期风险：组织或团队使用一段时间后，mandatory 规则数量可能持续增加。即便每条规则都合理，全部无条件进入上下文也会导致：
- session 启动 token 成本不可控。
- 普通任务因为 mandatory 总量超过 budget 而失败。
- 用户被迫把 mandatory 规则写短，或者把重要规则降级为 default。
这不是 capacity cap 的问题，而是 mandatory asset 缺少“短指令”和“长解释”的分层。
建议
给 mandatory feedback 增加明确的 context contract：
- mandatory asset 必须有短
directive 或 summary 字段，作为无条件进入上下文的内容。
- 正文的
Why / How to apply 只在任务相关、冲突解释、或用户展开时加载。
engram validate 对 mandatory 的 context payload 做预算检查，而不是对完整 body 做无条件预算检查。- 长 mandatory 规则应被建模为 KB/workflow，并由短 mandatory memory 指向它。
示例：
type: feedback
enforcement: mandatory
directive: "Never commit credentials or secret material."
references:
- kb/security-baseline/secret-handling
需要明确的规则
- mandatory body 是否允许超过某个 soft review 阈值。
- mandatory context payload 的 token 估算方式。
- 当 mandatory payload 超预算时，是否允许按 scope 层级只加载 directive 并保留 hard error 给完整 body。
参考
DESIGN.md §5.1 Stage 1：mandatory bypass ranking。DESIGN.md §8.1 invariant 11：No Capacity Caps。SPEC.md §4.3：feedback body 需要 Why / How to apply。
背景
DESIGN §5.1 规定 Relevance Gate Stage 1 会把所有
enforcement: mandatory的 asset 无条件放进 packed prompt。若 mandatory asset 本身超过 budget，则 hard error。同时 DESIGN §8.1 invariant 11 又要求 engram 不对 asset 数量、scope 数量、asset 大小设置硬上限。
问题
这两个目标放在一起会产生长期风险：组织或团队使用一段时间后，mandatory 规则数量可能持续增加。即便每条规则都合理，全部无条件进入上下文也会导致：
这不是 capacity cap 的问题，而是 mandatory asset 缺少“短指令”和“长解释”的分层。
建议
给 mandatory feedback 增加明确的 context contract：
directive或summary字段，作为无条件进入上下文的内容。Why/How to apply只在任务相关、冲突解释、或用户展开时加载。engram validate对 mandatory 的 context payload 做预算检查，而不是对完整 body 做无条件预算检查。示例：
需要明确的规则
参考
DESIGN.md§5.1 Stage 1：mandatory bypass ranking。DESIGN.md§8.1 invariant 11：No Capacity Caps。SPEC.md§4.3：feedback body 需要 Why / How to apply。