不说“做不了”，而问“要去掉哪一项”
目标
把判定范围内外的规则固化成有顺序的文件，并编写判定器。建立前提台账，为每个前提写明被打破时的后果、确认方法和有效期，并找出已过期的确认。对范围外的请求，不用拒绝的话，而用置换表来回答。
为什么重要
启动第一周定下的范围，从第二周开始就会渗漏。协议文本在抽屉里，翻开来看，这个请求是否属于那句话，也含糊不清。把规则写成有顺序的文件并运行判定器，面对“为什么这个不行”，只需要出示一条规则；如果规则错了，改规则就行。这就成了修改文件而不是说服人的对话。 没有被任何规则命中的请求，不是范围外，而是暂缓判断。如果把没被命中的自动推到范围外，规则的空隙就永远不会暴露。暂缓列表就是下一次会议的议题。 前提也一样。以会议上听到的话为前提制订了计划，三周后才发现它是错的，而那时日程已经建立在它上面了。为每个前提写明被打破时什么会崩塌、确认方法、有效期和负责人，过了有效期的前提就会浮现为一份列表。 评分器不会相信你写下的数字。它在每次以不同的规则和请求真实运行你的判定器，核对判定和依据规则；对前提台账，则放入边界日期来确认过期判定。
步骤
- 创建并运行 /root/scope/gen_engagement.py，生成 requests.json（25 条）、baseline.json（10 项，预算 30 天）和 sow.md。
- 阅读协议文本，把规则按顺序写入 /root/scope/scope_rules.json。每条规则包含 id、effect、match 和 reason，窄的规则放在上面。
- 创建 /root/scope/judge.py，让它为每个请求用先匹配的规则分成范围内、范围外和暂缓，并写出 verdicts.json。
- 给 match 增加 action 和 tag，使规则只在条件全部匹配时才命中。判定中还要写明是哪条规则做出的决定。
- 在 /root/scope/assumptions.json 中写入至少五个前提。每个前提包含 statement、if_broken、verify_how、verified_on、valid_days 和 owner。
- 创建 /root/scope/assumptions.py，让它以
--as-of为基准找出已过期的前提，并写出 expired.json。 - 针对新进来的范围外请求 RQ-021-NEW，在 /root/scope/tradeoff.json 中写入置换表。
- 在 /root/scope/scope_report.md 中分四节报告。
参考
- 请求条目：
{"id", "title", "system", "action", "tags": [...], "est_days", "from"}。system 是 wms、crm、billing、bi，action 是 read、fix、change、build、train。 - 规则文件：
{"rules": [{"id": …, "effect": "in"|"out", "match": {"system"?: …, "action"?: …, "tag"?: …}, "reason": …}]}。match 中的条件全部匹配，该规则才会命中请求。tag 在请求的 tags 中含有该值时即为匹配。列表的顺序就是优先级，先匹配的规则获胜。 - 判定运行契约：
python3 /root/scope/judge.py --rules <규칙> --requests <요청> --out <판정 JSON>（占位符依次为规则文件、请求文件、判定 JSON）把一行摘要输出到标准输出，并以退出码 0 结束。无法读取输入时为 3。 - 判定 JSON：
{"counts": {"in", "out", "undecided"}, "verdicts": [{"id", "verdict", "rule"}]}。verdicts 按请求 id 升序排列，rule 是做出决定的规则的 id，暂缓时为 null。 - 前提台账：
{"assumptions": [{"id", "owner", "statement", "if_broken", "verify_how", "verified_on": "YYYY-MM-DD", "valid_days": 정수}]}（占位符为整数）。 - 过期运行契约：
python3 /root/scope/assumptions.py --ledger <원장> --as-of <YYYY-MM-DD> --out <결과 JSON>（占位符依次为台账、日期、结果 JSON）。过期日是확인일 + valid_days（韩文，意为“确认日 + valid_days”），基准日超过过期日才算过期（过期日当天仍然有效）。 - 过期 JSON：
{"as_of", "items": [{"id", "expires_on", "expired"}], "expired": [id...], "valid": [id...]}。items 按 id 升序排列。 - 置换表：
{"request_id", "added_days", "dropped_days", "drop": [{"id", "est_days", "reason"}], "question"}。建议去掉的工作的合计天数必须大于等于新请求的成本，并且从这一组中去掉任何一项都会不够。priority 为 must 的工作不属于可置换的对象。question 是包含全部要去掉的工作 id 的一句话，并以问号结尾。 - 常见错误：把没被命中的请求推到范围外；把宽的规则放在上面，导致窄的规则永远不被命中；把过期边界算错一天；把 must 工作放进置换表。
- 前提基准日 2026-09-17、按天计算有效期的方式，以及置换表的最小性条件，是本实验的假设。它们不是标准规定的，而是团队达成一致并写进文件的值。
- 参考文档：RFC 2119和 RFC 8174讲的是用词语来明确规则语句强度的方法，RFC 3339讲的是日期的书写格式，Python datetime 文档说明了日期计算。
展开启动资料包
创建并运行 /root/scope/gen_engagement.py，生成 /root/scope/requests.json（25 条）、/root/scope/baseline.json（10 项工作、预算 30 天）和 /root/scope/sow.md。
启动时拿到手的是请求列表、已约定的工作列表和协议文本。展开之后，先读 sow.md 的六行：下一步的规则全部来自那里。
把协议文本转换成规则
把规则按顺序写入 /root/scope/scope_rules.json。每条规则包含 id（唯一）、effect（in 或 out）、match（system、action、tag 中至少一项）和 reason（至少十个字符）。规则至少五条，并且把它们应用到 25 条请求上时，范围内、范围外和暂缓都必须至少各有一条。
窄的规则放在上面。涉及个人信息的工作无论在哪个系统里都属于范围外，所以排在最上面，按系统划分的规则在它下面。不要试图覆盖所有请求：没被命中的不是范围外，而是暂缓，暂缓列表会显示规则的空隙。
分成范围内、范围外和暂缓
创建 /root/scope/judge.py，让它为每个请求用先匹配的规则做出判定，并写出 /root/scope/verdicts.json。没有任何规则匹配时，verdict 为 undecided，rule 为 null。
把请求从规则列表的上面开始逐条过一遍，在第一条匹配的规则处停下。一直没被命中就是暂缓：不要把它推到范围外。verdicts 按请求 id 升序排序，counts 中分别统计这三种。
只在条件全部匹配时才命中
给 match 增加 action 和 tag，使规则只在条件全部匹配时才命中请求。tag 在请求的 tags 中含有该值时即为匹配。判定中原样写入做出决定的规则的 id。
如果把条件当作 OR 处理，窄的规则就会表现得像宽的规则，优先级随之崩塌。只看规则中写了的条件，没写的条件任何值都让它通过。评分器会调换窄规则和宽规则的顺序，看优先级是否得到遵守。
建立前提台账
在 /root/scope/assumptions.json 中写入至少五个前提。每个前提包含 id、owner、statement（至少十五个字符）、if_broken（至少十五个字符）、verify_how（至少十个字符）、verified_on（YYYY-MM-DD）和 valid_days（1 以上 365 以下）。以基准日 2026-09-17 来看，必须各至少有一个已经过期的前提和仍然有效的前提。
写一写被打破时什么会崩塌，就会发现有的前提即使错了也没有任何影响，而有的前提上面却承载着整个计划。没有负责人的前提，过了期限也没有人去确认，所以一定要写 owner。确认日和有效期，每个前提都要设得不同。
找出确认已过期的前提
创建 /root/scope/assumptions.py，用 --ledger --as-of --out 判定是否过期，以基准日 2026-09-17 运行，并生成 /root/scope/expired.json。过期日是确认日加上 valid_days 的那一天，基准日超过过期日才算过期。
把过期边界算错一天是常见的错误。过期日当天仍然有效，从第二天起才算过期。结果中还要写下为每个前提计算出的过期日，客户才能看到它到什么时候有效。
要去掉什么
针对新进来的范围外请求 RQ-021-NEW，在 /root/scope/tradeoff.json 中写入置换表。drop 是 baseline 的工作中 priority 不是 must 的那些，合计天数必须大于等于 added_days，并且从中去掉任何一项都会不够。question 是包含全部要去掉的工作 id 的一句话，并以问号结尾。
如果建议去掉得很宽裕，客户会觉得我们想少干活。从大的工作开始放进去，合计超过成本时就停下，然后再检查一遍这一组里有没有可以不必去掉的。必须做的工作不属于可置换的对象。
报告范围与前提
在 /root/scope/scope_report.md 中分 ## 합의한 범위와 판정 결과 ## 판단이 보류된 요청 ## 전제와 만료된 확인 ## 무엇을 빼겠습니까 四节书写（韩文标题，依次意为“约定的范围与判定结果”“判断被暂缓的请求”“前提与已过期的确认”“要去掉什么”）。三种判定的条数、被暂缓的请求 id、已过期的前提 id 及其被打破时什么会崩塌、置换表的数字，都必须出现。
报告不要手写，而是从 verdicts、expired、tradeoff 三个文件生成。不要隐藏暂缓列表：暂缓有五条，就意味着规则有五处空隙，如实报告出来，客户会和我们一起补上。