StarryOS 系统调用兼容性

1. 强制输出契约

本技能用于完成语义审查或实现、修复、调试任务时，最终结论必须汇总每个直接或间接受影响的系统调用。默认每个系统调用单独一行；只有先分别核实各入口的 Linux 语义、StarryOS 入口至状态所有者的完整调用链和实现结论三者都完全相同，才可合并。只要权限门禁、参数检查、辅助函数、状态所有者、支持范围或结论中任一项不同，就必须拆行；不得用一条组级 部分正确 或 不正确 掩盖其中入口各自不同的状态。合并后仍须列全系统调用名称及各目标体系结构的编号。

同一系统调用受到多项独立改动影响时，表中必须逐项覆盖各参数、flag、体系结构入口或状态语义；一行无法同时给出准确调用链和结论时，按 系统调用(flag-or-path) 拆成多行。不得因为已经记录该系统调用的另一项语义而省略其余受影响行为。

1.1 审查结论

在线拉取请求审查在既有总审查正文之后增加 ## 系统调用兼容性对照，再输出本节规定的表格。离线审查把同一表格写入 review.json 的 summary；可锚定的缺陷仍写入 findings，不得用汇总表替代问题、严重性、变更行和修复方向。本技能只规定系统调用语义与输出，不反向加载或要求任何审查编排技能。

收敛审查问题前先逐入口完成对照表草稿，再用表中的语义差异驱动 findings；不得先凭已发现的问题列表反推表格范围。表中结论为 部分正确 或 不正确 时，必须对应至少一条当前变更行上的 finding 或行内评论；实现缺陷必须由实现 finding 锚定，不能用“缺少测试”的 finding 代替。finding 只解释具体根因，不重复整张表。CI_DEFERRED、CI_SKIPPED 等尚未进入语义审查的前置门禁报告不是审查结论，不要求输出对照表。

1.2 实施总结

实现、修复或调试完成后，在面向用户的最终交付总结中输出同一张表，填写修改后的实际状态和已经取得的验证证据。未执行的测试、只证明构建成功的检查或计划中的验证不能写成已通过；证据不足时使用 无法确认，并在测试列写明缺口。

1.3 对照表

对照表必须逐字使用以下六列，不得改名、删列或把 StarryOS 入口与调用链 和 实现结论 合并：

系统调用/编号	Linux 基准与稳定链接	Linux 可观察语义	StarryOS 入口与调用链	实现结论	测试与证据
<name>/<arch-number>	<version-or-commit> 与固定源码链接	参数、检查顺序、返回值、错误码和副作用	入口、关键辅助函数与状态所有者；涉及共享时注明线程、线程组、进程、命名空间或全局层级	正确、部分正确、不正确 或 无法确认	直接回归、命令、关键结果或证据缺口

Linux 基准列至少包含一个固定到明确 tag 或提交的源码链接，并指向系统调用入口或决定语义的关键辅助函数；不得使用浮动分支链接。手册页可以补充公开约定，但不能代替用于判断检查顺序、状态或竞争语义的固定 Linux 源码。

实现结论 单元格只能原样填写以下四个值之一，不得写成“方向正确”、把结论夹在实现描述中，或附加其他修饰：

• 正确：固定 Linux 源码、完整 StarryOS 调用链和直接系统级回归共同证明本次审查范围内的可观察行为一致；
• 部分正确：部分路径、参数、体系结构或状态语义一致，但仍有明确缺口；
• 不正确：已有具体输入或状态证明 StarryOS 与选定 Linux 基准不一致，预期支持但未实现时也使用此结论并注明“未实现”；
• 无法确认：源码、调用链、运行证据或适用范围不足，不能据此宣称兼容。

输出前逐项拒收不合格草稿：六个固定列必须齐全；每行列出了名称和各目标体系结构编号；每个受影响入口及其独立 flag 或状态语义已经覆盖；不同调用链或不同结论没有合并；每条 部分正确、不正确 已映射到具体 finding 或行内评论；没有直接系统级回归的入口未被标成 正确。缺少任一项时不得结束审查或实施任务。

2. 适用范围

是否触发本技能按用户可见语义判断，不按系统调用入口文件判断。任务、虚拟文件系统、命名空间、凭据、信号、套接字、内存管理、文件描述符、进程状态和辅助代码只要改变系统调用返回值、错误码、检查顺序、状态或可观察结果，都属于本技能范围。

实现或审查前完整阅读 Linux 语义与证据。改动涉及状态、权限、并发、复制用户内存或测试时完整阅读 状态与测试。新增系统调用或扩大用户可见能力时同时使用 feature-development。

3. 语义目标

目标是对齐选定 Linux 版本的可观察行为，而不是只让调用成功。参数解释、检查顺序、权限、命名空间、阻塞、部分完成、错误码、状态提交和并发竞争都属于接口。

未实现行为返回明确且与 Linux 语义一致的错误。不得静默成功、伪造状态、用占位 procfs 值宣称完整支持，或在错误路径留下部分提交状态。

4. 完成条件

每个受影响系统调用都要有可追踪的语义记录和系统级功能证明；按 test-quality 复用或增强已有回归，不要求每个入口或参数各建用例。记录 Linux 版本或提交、权威源码位置、StarryOS 入口与辅助调用链、预期检查顺序、状态变化和测试。测试必须通过项目 StarryOS 测试入口真实运行，并证明错误实现失败、修复后同一用例通过。