上下文源自 SOP
slop-is-a-context-deficit 把上下文包定为主控变量——这篇笔记给出构造方法：上下文管理不是设计出来的，而是从 SOP 里读出来的，因为一份 SOP 本身就是一张数据流图。每一步要么消耗信息，要么产生信息；上下文包就是这张图的边，被具体化出来的样子。
推导流程
- 解析每一步的名词。 祈使句本身就说明了它需要哪些信息。举例——reddit-sop 第 5 步（"回复刚发出的匹配帖"）消耗的是：关键词列表、帖子原文、这个圈子里什么样的回复能赢、与所述问题相关的产品事实、语气。
- 给每个对象标注易变性和权威来源。 分层结构就此浮现：
| layer | contents | refresh | source of truth |
|---|---|---|---|
| L0 (per-execution) | the live target (thread, query, trend) | fetched fresh, never cached | the platform, now |
| L1 (weekly) | winners-scan findings, experiment-log summary | the SOP's own weekly cadence | the instruments |
| L2 (per-project) | channel kit, product-facts pack | on product change | vault project notes |
| L3 (near-permanent) | arena SOP + case files, voice/stance corpus | with vault versions | the vault |
- 把生产者步骤识别成刷新任务。 每周赢家扫描步骤的输出，就是下周的 L1；每帖的日志又把校准反馈回去。刷新节奏其实一直都写在 SOP 里——维护类步骤是上下文的生产者，产出类步骤是上下文的消费者。
清单——可被 lint 的产物
用这套流程编译一份 SOP，会得到它的上下文清单：每一步对应 {consumes: 对象、层级、来源、TTL（存活时间）} / {produces: 对象、层级}。这带来两个结果：
- 内容 lint 补上了输入侧的那一半：生成之前，可以拿这份清单去核对某个包——清单上列的每一个对象是否都在场、都是新鲜的？
- slop（劣质产出）事件变成了 diff（slop-is-a-context-deficit 推论 2）：一篇写崩了的稿子，要么是清单违规（包不全），要么是清单本身有缺口（某一步需要的对象，清单从未列出——修清单，也就是修 SOP）。
哪些层真正扛着抗 slop 的负荷（有实验依据）
一次盲测三臂实验（slop-is-a-context-deficit，该实验）发现，各层并不是同等重要的：只加上 L2 产品事实包，几乎没有让 slop 减少（基础模型本来就懂这些品类常识），而 L3 层——语气/语域、这个圈子的规范，以及具体的、情境化的动作（例如 SOP 里"主动提供免费方法"这条规则）——才做了几乎全部的功。对编译清单的实际影响是：把 L3（语气、规范、这一步该做的那个具体的、非显然的动作）当成主要的抗 slop 输入；把 L2 事实包当成必要但不充分的脚手架。 一份只列了产品事实、却没列语气/规范/具体动作对象的清单，会通过自己的检查，却依然产出 slop。
底层设施已经存在
L2/L3 的检索走的是 vault + StandMeet 语料栈：单一权威来源在 vault 里，同步时按体裁路由，用 glob 做准入门控——连语气类素材的 ACL（访问控制）问题也已经在那边解决了（subjectivity 的读/展示门控）。这里所实例化的外部学科是上下文工程（context engineering，约 2025 年被命名为一种实践）；这篇笔记新增的是这条构造性规则：从 SOP 自身的数据流里推导清单，而不是凭感觉去筹备上下文。