scopechk

在某个条目进入目标范围之前，先检查它是否属于该目标现有的范围。

目标

某个条目往往会进入当下开放的归属地，一旦进入，就会被视为该归属地约定的一部分。scopechk 会根据每个候选目标对自身的现有说明，为某个条目给出归属判定：依据目标已有的书面资料，或在这些资料未作说明时，依据其现有成员的共同特征。它会对照已存在的范围检查条目，绝不设定或缩小某项工作的范围。它只提出建议；由人来决定和移置。

工作流

1. 确定对象。 列出条目、每个候选目标，以及请求执行的操作（添加、移动、提升、合并、上游）。将条目附带的任何指向信息（链接、一行引用）与它指向的内容分开；两者分别给出判定。如果无法读取条目或某个目标，就为其报告 MISS，并在此处停止。
2. 读取范围。 根据目标自身的资料（README、AGENTS.md、CONTRIBUTING、目录结构、命名规则、安装方式、目标受众）记录每项标准及其所在文件和章节。若资料没有说明，则根据现有成员的共同特征推断标准，标记为 inferred，并列出这些成员。只有目标负责人才能决定的标准，应作为负责人问题提出。
3. 比较最接近的成员。 选出一个面向相同类型用户或执行相同类型工作的现有成员，并说明它为何最接近。针对每项标准，将条目与其进行比较。如果没有可比较的成员，请明确说明；这一缺失本身就是不适配的依据。
4. 列出目标将承担的事项。 列出清单，而不是打分：新增依赖；该条目会触达每个安装或克隆目标的人；它将带来的每项公开承诺（稳定的安装方式、发布节奏、公开接口）；以及新增的维护工作。
5. 检查可访问性。 列出条目指向的所有内容（仓库、路径、服务、账户、工具），并通过实际打开，或查看其可见性，确认目标用户能否访问每一项。用户无法访问的内容（例如，公开目标中的私有仓库，或某台机器上的路径）都属于失败。无法检查的内容标记为 unverified，并注明具体内容。
6. 给出判定， 对每个条目、指向信息和目标分别作出判定：
   • in scope：所有标准均符合，且可访问性检查通过；
   • in scope after change：明确提出要做的具体变更（删去一行、替换某个路径、移除某项依赖），以及该变更满足的标准；
   • split：列出各个部分及其归属地；
   • out of scope：指出适配的归属地，并在该归属地上执行步骤 2 至 5；
   • pending owner：某个尚待回答的负责人问题会决定判定结果；说明问题，并说明每种回答对应的判定。
7. 停止。 以 Approval stop 结束：列出各个部分建议的归属地、任何负责人问题，并声明没有移动、复制、重命名、注册或删除任何内容。由提出请求的人决定是否将其放入某处，以及放在哪里。

规则

• 标准只能来自目标的资料，或来自标记为 inferred 的现有成员。品味、作者意愿、受欢迎程度、星标数和节省的工作量都不能作为标准。
• out of scope 是成功的结果。应直截了当地说明，并指出适配的归属地。
• 可访问性检查失败或存在未解决的负责人问题，都不能判为 in scope；推断不能代替负责人回答问题。
• 只提出建议。在执行过程中绝不编辑、移动、复制、重命名、注册或删除条目或目标。

验证

1. 每项标准都注明其在目标资料中的位置，或标记为 inferred 并列出其来源成员。
2. 指出最接近的成员并说明其最接近的原因，或明确说明不存在此类成员。
3. 每项指向信息都经过可访问性检查，或标记为 unverified；in scope 判定中不得存在检查失败。
4. 除 in scope 外的每项判定，都要说明相应变更、归属地或负责人问题。
5. 流程以审批停止结束，且没有任何内容被移动。