审查单个拉取请求

强制要求

将本技能视为强制性审查规范，而不是建议清单。触发后完整阅读本文件，再作出审查结论；除非更高优先级指令冲突，否则执行所有适用要求。

判断代码质量、可维护性或可合入状态前，先按“适用技能路由”识别全部适用项目技能并完整读取。是否适用以行为语义为准，不以文件路径、拉取请求标题或作者声明代替判断。上下文被压缩、从摘要恢复或无法确信仍完整记得适用技能时，重新完整读取，不能依赖记忆或旧的局部阅读。

没有完整阅读本技能和所有适用项目技能时，不得提交 APPROVE、REQUEST_CHANGES、不提交审查的总结或任何面向拉取请求的评论。唯一例外是“当前提交持续集成前置门禁”返回 CI_DEFERRED 或 CI_SKIPPED 时，只向用户报告当前提交散列值、相关检查和状态或证据缺口；该门禁报告不是审查结论，也不得写入拉取请求。规则重叠时采用更严格者；跳过要求时记录具体理由和证据。

输出任何审查文本前，先执行“中文审查文本规范”。要求修改的评论先复制“为什么需要改动、改动收益、改动前逻辑（基准分支）、改动后逻辑（当前拉取请求）、触发场景与证据、问题级别、建议修改方式”七个粗体 Markdown 标题再填写；缺少任一标题、标题下为空或用连续段落代替标题时，禁止输出或提交，必须重写。总审查正文先复制前四个二级 Markdown 标题再填写；缺少任一标题时同样禁止输出或提交。

适用技能路由

持续集成前置门禁通过后，先取得当前项目技能目录中全部技能的名称与 description，再根据变更文件、补丁、调用链和用户可见语义自行选择所有适用技能。技能选择是多选：一个改动同时涉及代码质量、公共接口、并发、非安全代码、平台或领域语义时，必须叠加读取，不能只选择其中一项。

建立技能适用台账，每项记录触发事实、适用或不适用、已完整读取的 SKILL.md 与按入口要求读取的参考资料、预期证据和实际结论。技能说明已经能够明确排除时记录具体理由，不为凑齐目录逐项加载无关正文；出现新技能时直接依据其当前说明判断，不修改本技能中的固定清单。

读取其他技能只提供审查规则，不扩大本次任务权限。普通在线审查仍受“持续集成与应用验证”限制；离线基准模式只读使用同一选择机制，并忽略与离线禁止事项冲突的执行步骤。任何构建、测试、部署、板卡操作、注册表更新、议题修复、审查人修改或其他外部写入，都必须同时满足本技能的明确流程条件和用户授权，不能因为某项技能被读取而自动执行。

审查清单门禁

在线拉取请求在详细判断、完整加载领域技能、创建清单、建立工作树或运行本地命令前，先按“当前提交持续集成前置门禁”读取最少的当前提交、变更路径和检查状态。门禁返回 CI_DEFERRED 或 CI_SKIPPED 时，不创建拉取请求专属清单，也不继续处理该拉取请求。

持续集成门禁通过后，读取足以识别审查范围的拉取请求描述、提交记录和语义范围，然后完整读取本技能、仓库指令、路由台账命中的项目技能，以及规划验证所需的应用文档或操作手册。

完成这些读取后，立即通过可用的任务清单工具创建用户可见、拉取请求专属的完整清单，并等待调用成功。持续使用同一个工具，最多一个项目处于进行中；发现新范围时先追加清单再调查。工具返回空结果但未报错时视为成功。只有工具不可用或确认失败时才改用可见的 Markdown 清单，并说明原因。

每个清单项写明具体受影响范围和预期证据，覆盖：当前提交信息、既有审查讨论、持续集成覆盖台账、技能路由台账、工作树、必要时的冲突、每个受影响模块及审查视角、代码质量基线、功能开发适用性、领域语义、测试的位置/构建/发现/选择/持续集成执行、重复与重叠分析、直接修改 apps/** 时的应用运行证据、阻塞问题与评论、当前提交刷新、审查提交、审查人分配和清理。每个受影响应用及每个新增或迁移测试都建立独立证据项目；普通验证项目以当前提交的检查名、任务、命令、架构或配置、日志和后置条件关闭。禁止使用“审查代码”“运行测试”之类泛化项目。

提交任何审查结论前逐项审计，只能以“有证据地完成”“给出具体理由的不适用”或“有证据的阻塞结论”关闭。阻塞结论会完成调查项，但必须进入中文审查文本和最终决定。任何必需项仍为 pending、不可验证或缺少证据时禁止 APPROVE；若缺口由拉取请求引入则提交 REQUEST_CHANGES，若外部审查系统限制阻止完成则明确不提交审查。提交审查、分配审查人和清理后，再做一次最终清单审计，向用户汇报完成项、不适用项、阻塞项和未完成项。

离线基准模式

仅当以精确参数 offline-benchmark 调用，且仓库存在 .agent-review-context/reviewer.md 时启用。否则执行正常在线流程。

以 bench-base..HEAD 为唯一被审变更。完整阅读本技能、AGENTS.md，按“适用技能路由”读取全部命中的项目技能与参考资料，并读取离线约定与输出格式。应用本技能的审查重点、测试质量、阻塞问题、硬件与二进制接口、安全与健全性、可维护性和文档要求。

离线环境没有真实拉取请求：拉取请求元数据、审查讨论、远端持续集成、开放拉取请求搜索、工作树、冲突修复、联网语义研究、命令验证、GitHub 提交、审查人分配和远端清理均标为不适用。禁止推断拉取请求编号、访问仓库外路径或网络、修改文件、创建提交或分支、运行构建或测试。只使用只读仓库检查和测试框架允许的 Git 历史与差异命令。

只返回 .agent-review-context/review.schema.json 要求的 JSON。问题必须由 bench-base..HEAD 引入并锚定 HEAD 侧变更行；没有问题时返回空 findings。禁止提交或起草任何面向 GitHub 的审查文本。仍须创建并审计清单；若无任务清单工具，在内部跟踪，不能破坏只返回 JSON 的约定。

目标与工具优先级

只审查指定的一个拉取请求，先分析当前精确提交的持续集成任务、步骤和日志，再在隔离工作树中完成静态代码分析；普通审查不运行本地格式化、构建、clippy、测试、QEMU 测试、元数据、打包或发布演练。只有拉取请求直接新增、修改或重命名进入 apps/** 的可运行应用，且当前提交持续集成未执行同一应用和目标时，才按“持续集成与应用验证”运行真实应用。审查同时判断它是否重复基准分支已有功能、与其他开放拉取请求重叠、冲突或已被取代。没有阻塞问题时提交 APPROVE；存在正确性、规范、重复、测试或持续集成问题时，以中文行内评论提交 REQUEST_CHANGES。审查完成后，仅在仍需领域跟进时依据 .github/MAINTAINERS.md 分配合适的人类审查人。

本技能是 review-open-prs 的单拉取请求权威流程。不要完整审查所有开放拉取请求，但读取足够的相关拉取请求上下文来分类重复和重叠。

GitHub 操作优先遵循系统技能：

• github:github：仓库定位、拉取请求元数据、补丁、评论、标签、反应和连接器优先行为；
• github:gh-address-comments：未解决讨论、请求修改、行内上下文、锚点和讨论解决状态；
• github:gh-fix-ci：失败的 GitHub 持续集成检查和日志。

优先使用 GitHub 连接器获取结构化数据，本地 git 用于获取、工作树和静态差异分析；只有连接器无法满足当前分支发现、图形查询语言讨论、持续集成日志或带锚点提交等需求时才使用 gh。除直接修改 apps/** 的应用运行例外外，不用本地命令填补持续集成证据缺口。

拉取请求信息收集

1. 通过 github:github 获取仓库身份、当前用户、拉取请求编号或网址、标题、描述、作者、基准与来源分支、headRefOid、草稿状态、合并状态、变更文件、补丁、提交、既有审查或评论和检查结果。 2.拉取请求作者是当前 GitHub 用户时，提交正式审查前先征询用户。
2. 除非用户明确排除，否则包含草稿拉取请求。
3. 创建工作树前确保连接器状态和本地检出内容一致。

连接器缺少必要数据时才回退：

gh auth status
gh repo view --json nameWithOwner,defaultBranchRef,url
gh pr view <pr> --json number,title,body,author,baseRefName,headRefName,headRefOid,headRepositoryOwner,isDraft,mergeStateStatus,maintainerCanModify,reviewDecision,url,commits
gh pr diff <pr> --patch --color=never
gh pr checks <pr> --watch=false
gh api --paginate "repos/<owner>/<repo>/pulls/<pr>/reviews?per_page=100"
gh api --paginate "repos/<owner>/<repo>/pulls/<pr>/files?per_page=100"

当前提交持续集成前置门禁

本节只适用于存在真实在线拉取请求的正常模式；离线基准模式保持原约定。先解析当前精确 headRefOid 或 head.sha，再用最少的变更路径和拉取请求声明判断哪些检查与本拉取请求相关。任何详细代码审查、领域规范加载、任务清单、工作树、应用运行或拉取请求写操作都必须等待本门禁完成。

优先查询 statusCheckRollup、检查套件和检查运行；传统提交状态接口也必须绑定同一提交散列值。不能单独用 GET /repos/<owner>/<repo>/commits/<sha>/status 判断 GitHub 持续集成状态，因为它可能显示 pending 且 statuses 为空，而对应的持续集成任务已经结束。

gh pr checks <pr> --repo <owner>/<repo> --watch=false
gh api --paginate "repos/<owner>/<repo>/commits/<head-sha>/check-runs?per_page=100"
gh api --paginate "repos/<owner>/<repo>/actions/runs?head_sha=<head-sha>&per_page=100"
gh api --paginate "repos/<owner>/<repo>/actions/runs/<run-id>/jobs?per_page=100"

若任一相关检查或任务为 queued、pending、waiting 或 in_progress，将结果标为 CI_DEFERRED 并立即停止。不得等待或轮询到结束，不得完整审查、创建工作树、运行应用、创建拉取请求专属清单、解决讨论、提交评论或审查、创建或更新议题、修复冲突或更改审查人；只向用户报告拉取请求、当前提交散列值、未结束检查名和状态。无关发布任务或按变更范围明确不适用的任务不触发暂缓，但必须记录不相关理由。

没有相关运行中检查时，建立持续集成覆盖台账。每项台账记录受影响行为或声明、检查与任务名、当前提交散列值、结论、实际命令、架构或配置、用例或二进制、关键日志和可观察后置条件。只有 success 且工作流定义与日志表明当前精确提交实际执行了同一命令、架构或配置和目标行为，成功标记真实出现且失败能传播到任务结论时，才接受为覆盖；检查名或宽泛汇总绿灯、旧提交散列值、路径或矩阵跳过、架构或功能不同、命令不等价、未达到成功标记，或无法证明新增用例被发现和执行，都不算覆盖。摘要不足时必须检查任务、步骤和完整相关日志，不能只看检查汇总。

使用四种稳定结果：CI_DEFERRED、CI_SKIPPED、APPROVE、REQUEST_CHANGES。相关持续集成失败时进入后续日志归因和详细审查。对非应用运行项，只要相关持续集成缺失、取消、陈旧、被跳过、覆盖可疑或日志不能证明真实执行，就标为 CI_SKIPPED 并立即停止：不创建工作树或拉取请求专属清单，不做详细代码审查，不提交 GitHub 审查，只向用户报告拉取请求、当前提交散列值、检查或任务、证据缺口和跳过原因。只有直接新增、修改或重命名进入 apps/** 可运行应用目录的应用执行缺口可以进入后续真实应用运行；其他相关持续集成缺口仍会使整个拉取请求成为 CI_SKIPPED。持续集成证据和应用运行都不能替代代码、架构、二进制接口、生命周期、安全性、文档和测试可信度审查。

审查讨论与终态持续集成分类

涉及既有请求修改、未解决讨论、行内位置或解决状态时，遵循 github:gh-address-comments。扁平评论列表不能代表完整讨论状态。需要时使用带分页的完整 GraphQL 查询：

gh api graphql --paginate \
  -F owner="$owner" -F repo="$repo" -F number="$pr" \
  -f query='query($owner:String!,$repo:String!,$number:Int!,$endCursor:String){repository(owner:$owner,name:$repo){pullRequest(number:$number){reviewThreads(first:100,after:$endCursor){nodes{id isResolved isOutdated path line diffSide comments(first:100){nodes{author{login} body createdAt}pageInfo{hasNextPage endCursor}}}pageInfo{hasNextPage endCursor}}}}}'

若任一讨论的 comments.pageInfo.hasNextPage=true，再以该讨论的 id 分页取得剩余评论，不能把前 100 条当作完整讨论：

gh api graphql --paginate \
  -F threadId="$thread_id" \
  -f query='query($threadId:ID!,$endCursor:String){node(id:$threadId){... on PullRequestReviewThread{comments(first:100,after:$endCursor){nodes{author{login} body createdAt}pageInfo{hasNextPage endCursor}}}}}'

检查所有未解决讨论。具体问题已在当前提交修复时解决讨论；修复不完整、测试未接入运行器或评论仍有效时保持未解决。操作后重新查询并确认 isResolved=true：

thread_id='<thread-id>'
gh api graphql \
  -f query='mutation($threadId:ID!){resolveReviewThread(input:{threadId:$threadId}){thread{id isResolved}}}' \
  -f threadId="$thread_id"

区分预期的矩阵或路径过滤 skipped 与整个相关工作流未运行。本仓库互斥的 run_host/run_container、分支限制发布任务或路径过滤任务可以为 skipped，其成功的同级任务足以说明工作流运行。以 success=N, skipped=M, failure=0 汇报，并命名关键检查。只有变更范围应由该检查覆盖、路径过滤跳过必需覆盖或所有相关检查均被跳过时，才把 skipped 视为可疑。

取消、缺失、陈旧、跳过或不可证实的相关检查已在前置门禁返回 CI_SKIPPED，不进入本节。对门禁允许继续的每个失败检查，提交审查前检查任务、步骤、完整相关日志和基准分支状态，并分类为“与拉取请求相关”“与拉取请求无关”或“无法确定”：

• 与拉取请求相关：失败任务覆盖本拉取请求的文件、软件包、用例、命令、平台或行为；在拉取请求当前提交可复现而基准分支不失败；或新增/修改的测试、配置、工作流导致失败、挂起、跳过或超时。提交 REQUEST_CHANGES，说明检查项、失败模式、归因和修复方向。
• 与拉取请求无关：提供具体证据，例如变更范围外、基准分支同样失败、已知偶发失败、基础设施问题或已有议题。用工作流或任务、特征错误、运行器或平台、用例或命令等多个关键词搜索并检查候选议题；更新合适的现有议题，或在确无匹配时创建唯一议题，并在审查正文链接它。
• 无法确定：合理检查任务、步骤、完整相关日志和基准分支状态后仍无法判断归因时，标为 CI_SKIPPED；不提交 GitHub 审查，只向用户报告当前提交散列值、失败任务、已检查证据和无法确定的原因。

gh pr checks <pr> --repo <owner>/<repo> --watch=false
gh run view <run-id> --repo <owner>/<repo> --log-failed
gh issue list --repo <owner>/<repo> --state open --search '<workflow-or-job-name>'
gh issue list --repo <owner>/<repo> --state open --search '<distinctive error excerpt>'
gh issue list --repo <owner>/<repo> --state open --search '<runner platform, case, or command>'
gh issue view <issue-number> --repo <owner>/<repo> --comments
gh issue comment <issue-number> --repo <owner>/<repo> --body-file issue-update.md
gh issue edit <issue-number> --repo <owner>/<repo> --title '<updated neutral title>' --body-file issue.md
gh issue create --repo <owner>/<repo> --title '<neutral-ci-issue-title>' --body-file issue.md

日志下载为空时不能推断通过或无关；用 gh pr checks 和 gh run view <run-id> --json headSha,jobs 确认当前提交、失败任务、结论和步骤。

工作树

获取拉取请求和基准分支，然后在分离状态工作树中审查：

repo_root="$(git rev-parse --show-toplevel)"
repo_parent="$(dirname "$repo_root")"
review_wt="$repo_parent/$(basename "$repo_root")-review-pr<pr>"
git fetch origin '+refs/pull/<pr>/head:refs/remotes/origin/pr/<pr>' '+refs/heads/*:refs/remotes/origin/*'
git worktree add --detach "$review_wt" origin/pr/<pr>

已有工作树仅在无改动且位于当前拉取请求提交时复用：

git -C "$review_wt" status --short
git -C "$review_wt" rev-parse HEAD
git rev-parse refs/remotes/origin/pr/<pr>

陈旧且无改动时无损更新；有本地改动时新建工作树或询问用户。禁止修改或回滚用户主工作树。并行审查不同拉取请求时使用不同工作树；同一检出目录内不得并发运行多个 StarryOS QEMU 用例。

合并冲突

仅在用户明确要求，或审查没有其他阻塞问题、本应 APPROVE 且当前 mergeStateStatus=DIRTY、maintainerCanModify=true 时修复。修复并推送、对新提交重新执行持续集成门禁和日志分析前不得批准。

只有 reviewDecision=APPROVED 才代表当前汇总批准。历史 APPROVED 审查只能作为上下文；汇总批准为空、为 CHANGES_REQUESTED，或仍有未解决讨论时，冲突修复只能做不提交的本地演练，除非用户明确要求推送修复。

先刷新拉取请求元数据、审查和远端当前提交。mergeStateStatus=UNKNOWN 时等待并重查。DIRTY 且 maintainerCanModify=false 时不得修复：用户明确要求处理冲突时提交 REQUEST_CHANGES，说明作者需合并或变基到最新基准分支，并建议启用“允许维护者修改”；否则在正文或总结中记录限制。DIRTY 且可修改时使用独立冲突工作树，并确认派生仓库分支仍等于 headRefOid。

gh pr view <pr> --json number,baseRefName,headRefName,headRepositoryOwner,headRefOid,mergeStateStatus,maintainerCanModify,reviewDecision,reviews
gh api --paginate "repos/<owner>/<repo>/pulls/<pr>/reviews?per_page=100"
git fetch origin '+refs/pull/<pr>/head:refs/remotes/origin/pr/<pr>' '+refs/heads/<base>:refs/remotes/origin/<base>'
git ls-remote "https://github.com/<head-owner>/<repo>.git" "refs/heads/<headRefName>"
git worktree add --detach "$conflict_wt" origin/pr/<pr>
git -C "$conflict_wt" merge --no-ff --no-commit "origin/<base>"
git -C "$conflict_wt" diff --name-only --diff-filter=U

在分离状态的冲突工作树中，暂存区第 2 阶段（ours）是拉取请求，第 3 阶段（theirs）是基准分支；不清楚时使用 git show :1:<path>、:2:、:3:。按拉取请求意图和当前基准语义解决，禁止简单保留两边或复活基准分支已替换的接口。拉取请求 #837 是参照：保留 /proc/kallsyms 功能，但适配 SeqObject 与 SpecialFsFile::new_regular_with_perm，并同时保留 ktracepoint/ksym、.tracepoint/.kallsyms 等独立改动，而不是恢复旧 SeqFile。

提交修复前只运行冲突标记扫描和差异卫生检查，不运行格式化、构建、clippy、测试、QEMU、元数据、打包或发布演练。解决 Cargo.lock 冲突时先处理其他文件，再由 Cargo 重新生成，禁止手工拼接；重新生成属于冲突解法，不作为本地验证证据。

rg -n '<<<<<<<|=======|>>>>>>>' <conflicted-files>
git -C "$conflict_wt" diff --check
git -C "$conflict_wt" add <resolved-files>
git -C "$conflict_wt" commit

推送前确认合并提交第一父节点仍是当前 headRefOid，并再次执行 git ls-remote。远端变化时停止并重新审查。只能普通推送，禁止强制推送：

git push https://github.com/<head-owner>/<repo>.git HEAD:<headRefName>

推送后刷新拉取请求，并对新 headRefOid 重新执行“当前提交持续集成前置门禁”。相关持续集成仍在运行时返回 CI_DEFERRED；相关持续集成缺失、跳过、陈旧或不可证实时返回 CI_SKIPPED。不得在新提交散列值上运行本地验证来替代持续集成；只有新提交直接改变 apps/** 可运行应用且缺少同应用、同目标的持续集成执行时，才适用应用运行例外。冲突消失后，BLOCKED 或 UNSTABLE 仍可能由持续集成或审查状态导致，不能仅据此判定冲突修复失败。只做冲突演练时不得推送或提交审查；记录拉取请求、批准状态、冲突文件、语义解法、差异卫生结果和未修改 GitHub 的事实，然后清理工作树。

审查重点

按拉取请求意图、当前基准分支、项目既有模式和适用外部语义理解完整实现逻辑：

• 系统调用、进程、会话、信号、文件系统错误码和套接字行为，对照可移植操作系统接口与 Linux；
• 网络行为对照征求意见稿与 Linux，包括第六版互联网协议邻居发现、第四版互联网协议映射到第六版互联网协议、双协议栈、路由或监听冲突和错误码；
• 驱动改动检查虚拟输入输出规范、外围部件互连总线、直接内存访问、内存映射输入输出、中断和所有权；
• Axvisor 配置检查 entry_point、kernel_load_addr、memory_regions、map_type 和客户机镜像布局；
• 所有命中的代码、接口、并发、非安全代码、功能和领域要求均按“适用技能路由”应用；技能只提供审查规则，不改变本技能的持续集成证据和本地运行限制。

影响 StarryOS 系统调用或 Linux 二进制接口时，按 starry-syscall-compatibility 的证据层级追踪间接辅助代码到每个受影响的系统调用入口；行为随版本变化时记录对照的 Linux 版本或提交。

新功能设计门禁

新增或扩展功能时，按 feature-development 分类为局部、共享或高风险，并在清单记录分类和证据位置。按以下顺序审查：必要性、重复性、语义与既有方案、替代方案、整体架构或接口、实现、验证与交付。

核对具体问题、目标用户或调用方、真实场景、成功标准、不包含项、仓库内部研究、适用的权威外部研究、现实替代方案和不实现成本。高风险功能必须有可独立审查的设计材料，覆盖适用的所有权、依赖、兼容性、迁移、回滚、可观测性、性能和安全。先提交重大设计阻塞问题，再处理低层细节。测试通过不能替代“为什么项目需要它、为什么优于复用或扩展、为什么现在值得承担复杂度”的解释。

审查视角与问题纪律

优先找全变更范围内的真实缺陷，不为简短而漏报，也不臆造问题。对可疑缺陷构造具体输入、并发交错、设备状态、客户机配置或测试路径；若场景不可能则说明原因。

除非变更显然不涉及，否则应用五类审查视角：

• 可维护性：流程、提交卫生、范围、软件包或模块边界、命名、可见性、注释和可理解性；
• 正确性：正常路径、错误路径、并发、热路径、边界偏差、可达的 unwrap/expect/panic、溢出、错误判断条件、保护条件、唤醒和资源泄漏；
• 安全与健全性：unsafe 契约、指针来源、别名、用户内存、信任边界、权限、检查与使用时序竞争、释放后使用；
• 硬件与二进制接口：汇编、目标描述文件、陷阱与上下文、对称多处理启动、内存映射输入输出、直接内存访问、中断、缓存一致性、虚拟输入输出规范、外围部件互连总线、设备树或配置、调用约定与对齐；
• 文档与用户可见兼容性：文档、操作手册、应用流程、测试套件指南、兼容性说明和用户可见行为。

同一根因不要在每个视角重复报告；多个症状可以分别锚定，但只完整解释一次共享修复。提交前复核所有承重前提、引用代码和权威外部来源；明确不确定性，撤回前提错误的问题。

测试与行为门禁

错误修复必须有确定性回归或复现：未修复实现必然失败，修复后同一测试通过；除非有具体证据说明环境不可能做到，否则缺少失败/通过证明即阻塞。普通的当前提交成功持续集成只证明修复后通过；修复前失败只能由测试逻辑必然失败的推导、作者提供的同一测试先失败后通过记录，或明确执行未修复变体的专门持续集成提供，不运行本地基准验证。原始系统调用修复优先直接覆盖 syscall(SYS_...)，避免标准 C 运行库封装掩盖返回值或错误码。

按 test-quality 判断变更是否缺少完整功能证明，优先接受已有或增强后的通用功能测试，不以有没有新增测试文件作为充分性标准。单元测试应位于对应源码末尾，{crate}/tests/ 只通过公开 API 验证能力；测试通过 #[path] 或其他源码包含方式绕过生产接口属于边界错误。验证运行器能够发现、构建或安装、选择、执行，并且回归时会失败。错放、孤立、仅手工执行、可选执行或被持续集成静默跳过的必需测试按证据缺失处理。

StarryOS 应用支持分层：

• 面向操作人员的冒烟、演示、根文件系统、板卡或 QEMU 脚本、长运行或可选流程放 apps/starry/<app-or-scenario>/；
• 内核二进制接口、系统调用、文件系统、进程、网络或错误修复语义覆盖放 test-suit/starryos/<case> 或既有分组封装；
• 系统调用变化必须有直接测试套件回归；应用冒烟不足以证明系统调用；
• 应用暴露的内核错误尽量提取为无需完整应用的测试套件回归，应用场景保留为集成证据。

每个直接新增、修改或重命名进入 apps/** 可运行应用目录的 StarryOS 或 ArceOS 应用，都建立独立证据项，列明文档化环境准备、体系结构、运行命令和可观察后置条件。当前精确提交的成功持续集成若证明实际执行了同一准备、应用、命令、目标和后置条件，则关闭为持续集成已覆盖；否则按“持续集成与应用验证”运行真实应用。纯删除不触发应用运行。apps/** 之外的应用支持声明、运行器、根文件系统、打包、日志解析或配置改动只分析持续集成和源码，不触发本地应用运行；相关持续集成存在缺口时返回 CI_SKIPPED。文档本身无法让用户准备环境、需要未记录的临时绕过或声明范围与证据不一致时，仍提交 REQUEST_CHANGES。

禁止测试外形的伪修复、硬编码特例、伪状态、空操作兼容层或未实现真实语义的逻辑。成功路径测试遇到 ENOMEM/EAGAIN 等意外失败时不得静默返回；合法跳过必须打印明确标记并解释原因。不得通过丢弃独特功能证明、漏跑必需架构、放宽 success_regex/fail_regex、把失败变成跳过或超时、修改路径过滤或改为仅手工执行来制造通过结果。按 test-quality 删除冗余用例或合并回归时，核对原有独特失败信号仍被保留，不要求为没有独立功能价值的测试再写替代测试。

Starry QEMU 失败必须传播到 cargo xtask starry test qemu ...：封装脚本在命令后立即保存 $?，失败时打印 STARRY_GROUPED_TEST_FAILED 或配置标记，不得再打印全部通过标记，并让外层命令失败。success_regex/fail_regex 必须可靠分类。当前 qemu/system 分组 C 子用例的 CMakeLists.txt 与 src/ 必须直接位于 system/<subcase>/；system/<subcase>/c/ 默认阻塞，除非同时更新根 CMakeLists.txt、运行器发现逻辑、指南和规则测试并验证。

可发布 Cargo 补丁策略

拉取请求触及 Cargo.toml、Cargo.lock、已提交的 .cargo/config/.cargo/config.toml、依赖元数据、重复版本、第三方接口或跨依赖类型边界时，检查所有 [patch] 和变更的依赖来源。按来源是否能由本仓库或 crates.io 重现、工作区是否可发布来判断；存在 [patch.crates-io] 本身不阻塞。

允许但必须通过解析与发布检查的来源：

• 相对于声明清单或配置解析并规范化后仍位于当前仓库内的 path；
• crates.io 已发布的精确版本，包括普通依赖中的 version = "=1.2.3"，以及用该版本替代其他来源的注册表补丁。

以下情况阻塞：任意 git、绝对 path、逃逸仓库的相对路径、非 crates.io 注册表；元数据未解析到预期软件包、版本或来源；请求版本未发布；依赖统一破坏接口或类型语义；完整工作区发布演练失败。

发布软件包可使用 { path = "...", version = "..." }，打包时 Cargo 使用 crates.io 版本要求；只有 path 的普通依赖对需要发布的软件包是阻塞项。根 [patch] 中的仓库相对路径自身不要求版本回退，但发布软件包的普通依赖声明仍然要求。

补丁若只为掩盖依赖方与工作区各自拥有的类型不一致，优先使用正常 crates.io 解析和显式边界：使用依赖公开类型；在边界添加软件包私有适配器；使用 .map_err(...)、TryFrom、封装新类型或扩展特征；未知错误码提供明确回退。根 [patch.crates-io] ax-errno = { path = "components/axerrno" } 的来源形态允许，并可在元数据与完整发布演练证明时统一发布依赖图；若目的只是让 kbpf-basic 错误与另一份本地错误类型隐式互换，则保留 kbpf_basic::BpfError/BpfResult 到 LinuxError/AxError/AxResult 的显式转换。

重复与重叠分析

每个拉取请求必做。先建立意图指纹：标题、描述、议题、提交、变更的软件包/模块/测试/配置/持续集成/生成资产、公共接口、系统调用、错误码、协议、设备、运行器、功能，以及功能、修复、覆盖、重构、配置、持续集成、依赖元数据等语义声明。

先查当前基准分支是否已有等价或更新实现，再用多个意图指纹关键词搜索开放拉取请求；不能只搜标题。读取候选的意图、文件和差异后分类：

• 重复：同一问题或同一接口、测试、配置，无实质差异；
• 部分重叠：同一受影响范围，但互补、可排序或可拆分；
• 冲突风险：修改同一契约、运行器、生成资产或二进制接口，存在合并或语义冲突；
• 已被取代：基准分支或其他拉取请求更完整、更符合项目方向；
• 检查后无关：关键词命中但审阅后无关。

git grep -n -E '<relevant symbols|paths|commands>' origin/<base> -- <likely paths>
git log --oneline --decorate -- <likely paths>
gh pr list --state open --limit 200 --search '<symbol OR path OR issue keyword>'
gh pr view <related-pr> --json number,title,body,author,baseRefName,headRefName,isDraft,updatedAt,files,commits
gh pr diff <related-pr> --patch --color=never
git diff --name-only origin/<base>...origin/pr/<related-pr>

依赖另一拉取请求先落地时，在描述或审查中明确依赖前不得批准。重复或已被取代时请求修改，或中性说明应优先采用的基准实现或拉取请求。使用 git diff origin/<base>...origin/pr/<pr> 查看拉取请求补丁；只有检查陈旧分支影响时才用 ..。用户要求关闭时，先执行 gh pr comment <pr> --body-file comment.md，再执行 gh pr close <pr>。

持续集成与应用验证

普通审查只使用当前精确提交的远端持续集成和只读源码分析。允许读取 Git 历史、差异、清单、工作流定义、持续集成任务、步骤和日志，也允许用 rg 等只读搜索定位证据；禁止运行本地格式化检查、构建、clippy、测试、QEMU 测试、模拟器、元数据解析、依赖树、打包、发布演练或拉取请求声明的其他验证命令。持续集成缺口不能由这些本地命令填补。

对每项相关持续集成核对当前提交散列值、任务和步骤结论、实际命令、架构或配置、用例或二进制、成功标记、可观察后置条件及失败传播。成功汇总不够；日志必须证明目标行为真实运行，新测试被发现和选择，客户机或工具输出达到通过条件，且内部失败不会被命令解释器、超时包装层或正则分类吞掉。失败、取消、缺失、陈旧、跳过或不可证实的处理遵循“当前提交持续集成前置门禁”和“审查讨论与终态持续集成分类”。

依赖元数据变更仍须静态扫描所有 [patch]、普通依赖来源、相对路径、版本和发布边界，并从当前提交持续集成取得元数据解析、依赖树及适用的完整工作区发布演练证据。相关持续集成没有执行或日志不能证明预期软件包、版本、来源和发布结果时返回 CI_SKIPPED，不在本地运行 cargo metadata、cargo tree 或 cargo publish。

只有直接新增、修改或重命名进入 apps/** 可运行应用目录的内容允许本地运行。以拉取请求文件状态识别范围：纯删除不触发；不属于可运行应用目录的 apps/** 文件不触发。在详细代码审查前，对每个受影响的可运行应用执行以下流程：

1. 从仓库文档和应用目录确定环境准备、应用名、架构或板卡、真实运行命令、配置和可观察后置条件；不使用未记录的机器知识补全命令。
2. 当前精确提交持续集成已成功执行同一应用、目标、准备、命令和后置条件时，接受持续集成证据，不再本地运行。
3. 持续集成只缺少该应用执行时，运行文档规定的真实入口，例如 cargo xtask starry app qemu ...、cargo xtask starry app board ...、cargo xtask arceos qemu ...、cargo xtask arceos board ... 或应用自带且文档指定的运行封装。不能用只构建、测试套件、语法检查、解析、app list 或 --help 代替。
4. 架构或板卡专属文件运行对应目标；共享内容对每个受影响应用运行一次文档默认目标。一次只运行一个 Starry QEMU 应用。
5. 检查客户机标记、应用输出、服务就绪、日志、符号化位置或产物等真实后置条件；退出码为 0 但目标行为未发生不算通过。
6. QEMU 应用因外部环境、权限、凭据、服务或宿主能力而不能运行时返回 CI_SKIPPED，报告命令、环境缺口和未取得的后置条件；可归因于拉取请求的真实运行失败进入 REQUEST_CHANGES。
7. 只能通过实体板卡运行且当前没有可用板卡时，记录未运行的 app board 命令、缺少的板卡和风险，继续静态审查；该限制本身不阻塞 APPROVE。已有当前提交散列值板卡持续集成时仍按同应用、同目标标准记录证据。

apps/** 之外的应用运行器、根文件系统、QEMU 或板卡配置、准备、打包、符号化或日志解析改动不触发本地应用运行；只能依靠当前提交持续集成和静态分析，持续集成缺口返回 CI_SKIPPED。应用支持同时包含系统调用或内核错误修复时，对应测试套件执行必须由当前提交持续集成单独证明，应用运行不能替代。

分组 QEMU 及其他新增或迁移测试必须核对位置、发现、构建或安装、子用例选择、功能门控、正则分类和失败传播，并从当前提交持续集成日志证明具体用例、子用例或二进制真实执行。宽泛汇总、确定性发现推导或本地测试都不能替代执行日志；证据缺失时返回 CI_SKIPPED。测试位置错误、静默跳过、覆盖层级不对或错误修复缺少必然失败的回归逻辑仍是代码审查阻塞问题。

远端持续集成是普通审查的必需运行证据；没有相关检查不等于通过，而是 CI_SKIPPED。持续集成不能替代静态分析、语义审查、覆盖真实性检查，也不能自动提供错误修复的修复前失败证据。应用本地运行只能填补对应应用执行项，不能填补其他相关持续集成缺口。

阻塞问题

前置门禁产生的 CI_DEFERRED 或 CI_SKIPPED 在详细审查前停止；失败归因无法确定或必要 QEMU 应用运行受外部环境阻止时，也以 CI_SKIPPED 停止后续处理。以上状态都不进入阻塞判断，也不提交 GitHub 审查。只有流程仍可继续时，才判断以下阻塞问题；除非有明确证据表明不阻塞，否则：

• 与可移植操作系统接口、Linux、征求意见稿或 VirtIO 语义不符；
• 新功能缺少问题、用户或调用方、成功标准、不包含项、内部重复搜索、适用权威研究或现实替代方案；
• 高风险功能缺少可独立审查设计或合格领域审查人；
• 跨层捷径、硬编码特殊路径、重复真相源、伪成功、静默回退、无当前使用者的投机接口、配置或扩展；
• 当前提交持续集成中针对性测试、格式化、静态检查或其他相关任务失败；
• 当前提交的 StarryOS 或 ArceOS 应用在持续集成或允许的真实本地应用运行中按文档失败，或失败未传播到 xtask；
• 应用或 QEMU 声明只验证发现、TOML 解析、旧提交或他人结果；
• 直接新增、修改或重命名进入 apps/** 的可运行 QEMU 应用缺少当前精确提交的同目标成功持续集成或允许的真实应用运行证据，或文档缺环境、命令、参数、就绪条件；
• 真实应用运行失败可归因于拉取请求，或需要未记录的临时绕过才能通过；仅板卡应用因无可用板卡而未运行不属于该阻塞项；
• 新行为、语义或错误修复缺测试，或测试错位、未发现、未构建或安装、未选择、未直接覆盖二进制接口；
• 拉取请求通过布局、路径过滤、功能门控、子用例、安装规则或仅手工执行的位置削弱或跳过既有覆盖；
• 拉取请求声明的持续集成验证与实际命令、目标、输出或通过条件不匹配；
• success_regex/fail_regex 不能可靠分类；
• 错误修复缺少必然失败与通过的回归或复现，且未证明不可能；
• Cargo 补丁使用 git、绝对路径、仓库外路径、非 crates.io 注册表，普通可发布依赖只有路径，请求的 crates.io 版本不存在，解析到非预期软件包、版本或来源，或完整工作区发布演练失败；
• 合并冲突未解决，修复复活过时的基准接口，或推送后的新提交未重新通过持续集成前置门禁和适用的应用运行例外；
• 应用流程与测试套件的语义覆盖层级错误；
• 仅测试的伪修复未实现真实行为；
• 缓冲区、直接内存访问内存、队列令牌、中断所有权泄漏、过早释放或跨错抽象层；
• 持续集成以超时等终态失败、跳过新覆盖，或削弱既有用例、体系结构、匹配规则、路径过滤或正常回归；
• 重复基准分支、削弱已有实现、与开放拉取请求冲突或已被取代；
• 无法解释与候选相关拉取请求的差异；
• 必需清单项仍为 pending、不可验证或缺少证据或具体不适用理由。

中文审查文本规范

所有 GitHub 审查文本，包括总审查正文、行内评论和讨论回复，均使用中文、中性且项目导向的表达。命令、路径、代码符号、接口字段、产品名和标准正式名称可以保留原文；在叙述中用中文说明其作用，不连续堆叠英文术语。面向第一次接触相关模块的读者，先说明对象在调用链中的角色，再说明状态变化、触发条件和可观察结果。禁止使用“请优化”“测试通过”“这里不正确”等缺少原因、逻辑和证据的结论。

要求修改的评论模板

凡是要求继续修改代码、测试、文档或配置的行内评论和讨论回复，先复制以下七项粗体 Markdown 标题骨架，再逐项填写具体内容。输出时保留 **标题** 语法，不得删除标题、留空、合并成含糊短句、改成连续段落或依赖总审查正文代替：

• 为什么需要改动：说明当前问题、不修改会产生的实际后果和受影响对象。
• 改动收益：说明修复后恢复或新增的可观察保证，以及对正确性、可维护性、安全性、兼容性或测试可信度的收益。
• 改动前逻辑（基准分支）：只说明基准分支在拉取请求之前的入口、关键状态变化、所有权或错误传播和最终结果。若属于新增路径或缺失测试，写明基准分支此前没有该路径或覆盖。
• 改动后逻辑（当前拉取请求）：只说明当前拉取请求已经引入的入口、关键状态变化和结果，并指出问题出现在哪一步。新增测试场景应写“拉取请求添加了文件，但当前布局使运行器无法发现”；绝不把期望修复后的未来逻辑写在此处，未来逻辑只放“建议修改方式”。
• 触发场景与证据：给出具体输入、状态、并发交错、设备状态、调用链、日志、测试或规范依据；引用当前提交的路径、行号和符号。
• 问题级别：说明是否阻塞以及影响范围。阻塞问题明确写出会导致的错误结果、崩溃、死锁、资源泄漏、二进制接口不兼容、测试失效或其他可观察后果。
• 建议修改方式：描述应恢复的语义、顺序、所有权、错误传播或测试契约，以及修改完成后的验收条件。只约束根因和必要边界，不替作者扩展无关重构。

同一根因只在最贴切的评论中完整解释一次。若其他变更行只是同一根因的症状，引用该评论并说明本行的局部影响，不再发布重复的修改要求；若该评论本身仍要求修改，则仍须包含七个标题。纯信息说明和批准结论不强制使用七段模板，但仍须使用中文并给出必要依据。

总审查正文

总审查正文先复制 ## 为什么需要改动、## 改动收益、## 改动前逻辑（基准分支）、## 改动后逻辑（当前拉取请求） 四个二级 Markdown 标题，再逐项填写，形成完整的整体叙事，并通过路径或评论引用汇总行内问题，避免机械复制。正文还覆盖适用的以下内容：

• 拉取请求改动、功能开发技能适用性、风险分类和设计材料位置；
• 新功能的问题、用户、成功标准、不包含项、研究、替代方案和取舍；
• 实现逻辑、项目语义、当前提交散列值的持续集成命令、任务、步骤、日志与结果；
• 测试要求、位置、构建、发现、选择和执行证据；
• 每个直接变更应用的当前提交、准备文档来源、体系结构、运行命令、可观察后置条件，以及精确持续集成或允许的真实应用运行证据；板卡端未运行时列出缺少的板卡和剩余风险；
• 审查清单审计、无测试时复核的声明、四态审查结果、持续集成状态、无关失败证据和跟踪议题；
• 重复与重叠分类、冲突处理、与拉取请求相关的持续集成失败和修复方向；
• 错误修复的失败/通过证据、已解决与未解决讨论、未实现或后续项、环境限制。

不能只写“测试通过”。没有阻塞问题的批准正文也说明审查范围、改动前后逻辑、主要收益、验证证据和剩余风险。

回复已修复问题

仅确认问题已修复的回复可以缩短为“状态”“逻辑变化”“验证证据”三部分，写明当前提交、原问题如何被修复、修改前后的关键差异和同一回归测试的结果。作者只有解释而没有修改代码或测试时，不把解释当作修复证据。仍要求继续修改或只修复一部分时，使用完整七段模板并保持讨论未解决。

发布前后格式检查

发布前逐条检查未发布草稿：

• 中文叙述是否完整，英文是否仅为允许保留的精确标识；
• 必填标题是否齐全且顺序正确，各节是否非空并面向初学者解释上下文；
• 是否残留 TODO、TBD、<placeholder> 或模板说明文字；
• Markdown 标题、列表、空行、代码围栏、反引号和链接是否闭合且层级正确；
• 行内评论的 path、line、side=RIGHT 是否存在并绑定当前 headRefOid；
• 总审查正文、行内评论和回复之间是否重复、矛盾或遗漏阻塞问题。

任一检查不满足时丢弃草稿并重写，不得以“语义已经包含”为由省略固定标题。

提交后重新读取实际发布的总审查正文、行内评论和回复，检查 GitHub 上的显示、标题、列表、代码块、链接、内容完整性和讨论状态。接口调用成功不等于格式正确。发现格式错误时优先编辑原评论；无法编辑时发布一条完整修正版，并明确原评论已被替代。格式修正不得改变问题语义或掩盖当前提交已经变化的事实。

提交审查

提交前用同一个任务清单工具逐项审计。任何必需项仍为 pending、不可验证或无证据时不得 APPROVE。拉取请求导致的测试缺失或真实应用运行失败进入 REQUEST_CHANGES；外部 QEMU 环境阻止必要应用运行时返回 CI_SKIPPED，板卡端无可用板卡时记录风险并允许继续。CI_DEFERRED 或 CI_SKIPPED 都不得提交 GitHub 审查。

通过连接器确认拉取请求的 headRefOid 未变化；回退命令：

gh pr view <pr> --json number,headRefOid,reviewDecision

当前提交变化时先对新提交散列值重新执行持续集成前置门禁；相关持续集成仍在运行时返回 CI_DEFERRED，相关证据缺失或不可证实时返回 CI_SKIPPED。门禁通过后再重新获取、更新工作树并在新的右侧变更行复核每个问题；除新提交直接改变 apps/** 可运行应用且缺少同应用、同目标持续集成证据外，不运行本地验证。

先按“中文审查文本规范”完成草稿和发布前格式检查。优先用连接器一次提交审查事件和带锚点评论；连接器无法保持锚点时使用 GitHub 拉取请求审查接口：

gh api --method POST repos/<owner>/<repo>/pulls/<pr>/reviews --input review.json

请求载荷使用当前 headRefOid、side=RIGHT；有任何阻塞问题时使用 REQUEST_CHANGES，无阻塞问题时才使用 APPROVE：

{
  "commit_id": "<headRefOid>",
  "event": "REQUEST_CHANGES",
  "body": "...",
  "comments": [
    {"path": "path/to/file.rs", "line": 123, "side": "RIGHT", "body": "..."}
  ]
}

禁止提交针对旧提交的问题。提交后重新查询审查和评论，执行发布后格式检查；若期间出现新提交，仅在问题对新提交仍成立时提交后续审查。

gh pr view <pr> --json number,reviewDecision,latestReviews

推荐审查人分配

普通单项审查不自动修改审查人。仅在已经提交在线审查、仍需领域跟进，或用户明确要求分配、删除或重新平衡审查人时，完整读取并执行 reassign-pr-reviewers。该技能负责 .github/MAINTAINERS.md 的 R: 允许列表、F:/K: 匹配、现有机器人保留、写入前演练、权限处理和 GitHub 接口选择，本技能不重复维护这些规则。

离线基准模式不得触发审查人分配。在线执行后重新读取实际审查请求，向用户汇报匹配依据、已请求、已存在、已保留、已跳过和被拒绝的账号；分配失败不能改变已经提交的代码审查结论。

清理

提交审查或明确不提交审查后：

• 删除无改动的审查或冲突工作树，并从主仓库运行 git worktree prune；
• 删除审查请求载荷、GraphQL 查询、评论、日志、冲突说明等临时文件，除非用户要求保留；
• 工作树有未提交的冲突修复、需要保留的诊断或用户改动时不得删除，向用户报告路径和原因；
• 确认主工作树未被审查流程修改；
• 清理后在同一个任务清单工具做最终审计，汇报已完成、不适用、阻塞和未完成项目。