rfcs (astrid-runtime/rfcs)
Searching Database…
这是什么?
这个仓库存放定义 Astrid 内核与用户空间之间契约的任何重大变更的 RFC(设计提案),涵盖主机 ABI、IPC 协议、能力模型、清单 schema、VFS 语义、capsule 接口标准以及 SDK 的公共 API。
这是一个真正的软件库,还是只是一套设计文档?
它纯粹是一组 markdown 规范文档和一套治理流程,不是可运行的代码——README 声明实现必须遵循 RFC,而不是反过来。
如何通过 RFC 提议一项变更?
Fork 仓库,把“0000-template.md”复制为“text/0000-my-feature.md”,填写动机和参考级别的规范,然后使用该文件名发起 pull request 进行讨论。
什么样的变更才真正需要写 RFC?
任何触及 astrid-sys 中系统调用表、IPC topic/payload schema、能力令牌格式、Capsule.toml 清单 schema、VFS 路径解析、新的 capsule 接口标准,或 astrid-sdk 公共 API 破坏性变更的内容。
合并 RFC 就意味着功能可以使用了?
不是——合并后的 RFC 只是“Active”状态;它的类型仍需在 astrid-sdk 的特性开关之后以及参考 capsule 中实现,才能成为“Final”并趋于稳定。
现在有多少个 RFC?
只有一个——RFC 0001“RFC Process”,目前标记为 Active。
RFC 生命周期的各个阶段是什么意思?
Draft 表示 PR 正在开放讨论,Active 表示已合并并正在 astrid-sdk 中实现,Final 表示已实现且稳定,Withdrawn 表示未合并就被关闭,Superseded 表示已被更新的 RFC 取代。
Astrid 中的“capsule”是什么?
从引用的 schema 来看,capsule 似乎是 Astrid 的用户态代码单元,由 Capsule.toml 清单描述,并遵循已定义的 capsule 接口标准,如工具 schema 和跨 capsule 契约。
被接受的 RFC 实际上如何进入 SDK?
达成共识并合并 RFC 后,维护者会为它分配一个顺序编号,随后实现工作在 astrid-sdk 中以特性开关的方式进行,同时也在参考 capsule 中进行。
What are similar projects?
book, EIPs, spec, design, bips, spec, api-guidelines, swift-evolution
Which topics is it in?
spec-driven-development, governance, standards, access-control, specification, protocol, runtime, operating-system, kernel, template, architecture, sandbox