治理与维护者¶

参与 pVisor 时，先按变更规模选择入口：修正文字或小问题可以提交 PR，较大的接口与行为变化先用 issue 对齐问题和验收方式。涉及安全边界的漏洞使用私密披露流程。

当前贡献与决策流程¶

1. 描述用户遇到的问题、预期行为和复现方式。
2. 对设计变更说明选项、代价和兼容影响；把验收要求写清楚。
3. 提交实现、对应文档与验证结果；按贡献指南运行相关检查。
4. 评审者核对行为、证据与测试；合并和发布由具有相应仓库权限的维护者执行。

代码评审、合并权限与语义规格批准分别处理。一个 PR 的测试通过不自动批准产品承诺；新增用户可见边界需要对应的规格与人工审核。

semspec 的人工批准职责¶

贡献者可以起草案例、修复实现并维护 runner 测试。维护者人工判断主张是否准确、覆盖是否足够，再执行 approve/revoke 和更新批准记录。AI 不执行批准，不修改真实 REVIEWED.toml 或 .approved/ 快照，也不弱化现有检查来获得 PASS。

评审时同时提供源码版本、运行环境、结果和适用限制。具体命令与规则见测试与 semspec。

如何成为长期贡献者¶

从一个可复现的问题开始，持续维护某个模块的实现、文档与回归案例。较大的职责变化可以通过公开 issue 提出范围，说明你希望负责的内容和已经完成的工作。

仓库权限决定谁能合并和发布，职责扩展需要与有权限的维护者确认。讨论意见不一致时，把争议点、备选方案与验证结果放在同一 issue 中，请维护者给出决定并链接到对应变更。

治理记录需要公开什么¶

维护者名单应包含账号、职责和生效时间；设计决定应链接 issue、PR 或 ADR；权限与发布职责变动保留记录。安全报告中的敏感内容遵循披露流程，公开记录只引用可以公开的结论。