检查技术资源目录收到的新提交

## 以一份目录文件为唯一来源，网站和数据都由它生成 将一份人类可读的目录文档视为唯一事实来源。 从该来源生成索引、结构化数据集和静态页面，不要单独编辑派生制品。 按主题类别而非实现语言标题组织条目。 将语言支持记录为每个条目的内联标签，使一个资源无需改变主题类别即可声明多种语言。 记录数据流： 1. 目录文档保存经过筛选的条目。 2. 解析器验证条目、补充已获批准的外部元数据，并写入结构化数据集。 3. 站点生成器在数据集可用时读取它，否则直接解析目录以供本地预览。 4. 持续集成运行解析器和生成器，然后仅发布生成的站点目录。 使解析器、生成器和部署行为与此契约保持一致。 不要让生成页面或数据集成为相互竞争的事实来源。 ## 用带语言标签的统一格式写每个条目 定义一种解析器可识别的条目结构，并将标点视为契约的一部分。 典型条目包含带链接的名称、一个或多个内联语言标签以及说明：``- [Name](https://example.org) - `Language` - Description.`` 应用以下规则： - 新增的非商业条目必须包含至少一个语言标签，后接规定的分隔符； - 说明必须在可选的源代码仓库链接之前以句点结束； - 新链接必须使用`https://`； - 商业或专有资源应放入专门类别； - 只有商业类别或明确与语言无关的类别才能省略语言标签； - 面向提交者的贡献指南始终是提交规则的权威来源。 在不改变周围结构的情况下接受多个语言标签。 允许在完整说明之后添加可选的代码仓库链接。 生态系统特定的软件包链接只要遵循相同条目语法，就应保持有效。 不要为了一个格式错误的提交而放宽解析器模式。 ## 新条目严格检查，旧条目只作为警告报告 使用仓库中记录的环境和任务封装器进行验证、解析和发布。 遵守规定的运行时版本，并通过规范的依赖命令安装依赖项。 使用两种验证模式： 1. 变更验证只检查相对于所选基准修订新增的条目。 2. 全目录验证检查每个条目。 对于新增条目，将重复、链接格式错误和URL政策问题视为错误。 对于整个目录，除非明确选择严格标志，否则将同类旧问题报告为警告。 不要让容忍的旧债务降低新条目的准入标准。 仅在所需凭据可用时运行解析器。 允许站点生成器在本地预览中使用现有结构化数据集，或使用文档规定的直接解析后备路径。 ## 只审查你指定的提交，并检查是否重复 将审查范围限制为用户点名的提交。 使用已配置的仓库连接器进行pull request操作，不要使用无关的命令行客户端。 执行任何修改操作之前： 1. 检查提议的文件和差异。 2. 检查类别位置和准确的条目格式。 3. 在事实来源目录中搜索重复项。 4. 验证安全的URL格式。 5. 用证据评估当前项目活跃度和文档状况。 6. 在改变外部状态之前先提出审查结果。 不要仅仅因为其他提交仍处于开放状态就一并审查。 不要仅凭提交说明推断受欢迎程度或维护状态。 区分目录格式合规性与资源质量及持续实用性。 ## 评论或合并 pull request 之前先询问 在评论、添加标签、关闭或合并pull request之前，始终先询问用户。 只有在用户批准审查评论后，才添加审查完成标签。 只有在该次合并获得明确批准后，才执行合并。 使用已连接的仓库工具列出开放请求，检查详情、文件、评论、标签和差异，获取默认分支目录以检查重复项，并执行已批准的变更。 所需连接器不可用时，绝不要改用其他外部工具。 如果连接器缺失，应报告仓库操作受阻，并请用户进行配置。 将只读证据收集与外部状态变更分开。 审查指令本身并不授权评论、添加标签、关闭或合并。 ## 隐藏访问密钥，只通过设定好的自动流程发布网站 将外部元数据补充视为需要凭据的操作。 没有所需访问凭据时不要运行，并且绝不要在命令、报告、生成页面或提交文件中暴露凭据。 保持发布流程可复现： - 将规范目录解析为文档规定的结构化数据集； - 本地预览只能使用文档规定的后备路径； - 从当前已验证输入生成静态页面； - 只通过已配置的持续集成工作流发布； - 解析器或模板行为变化时审查生成的差异。 不要仅凭本地预览就声称发布成功。 分别验证生成制品和发布工作流。 ## 说明检查范围，把新错误和旧警告分开报告 报告已审查的提交、发现、验证模式以及任何受阻操作。 说明检查仅覆盖新增条目还是覆盖整个目录。 将源自旧内容的警告与当前变更引入的错误分开列出。 完成前确认： - 目录仍是事实来源； - 已检查条目语法、标点、标签、类别和安全URL； - 已对照当前默认分支检查重复项； - 对活跃度和文档的判断有证据支持； - 未经批准没有改变外部状态； - 没有把生成制品误当成权威源内容。 报告应足够简洁以支持决策，同时包含每一项可能改变准入结论的发现。