port-github-app-to-origin

将 GitHub App 移植为 Origin App

请在应用的代码库中运行此操作。输出是一份供团队参考的移植简报，以及一个可直接发送的「给 Cursor 的反馈」部分（references/brief.md）。此技能用于制定计划，不会编写或更改代码，除非用户阅读简报后提出要求。请遵循 origin-api 技能中的文档和首先需要核查的规则。另有两条规则：

1. 在代码中查找，不要提问。 阅读应用源码，确认它实际使用了什么。任何无法查明的内容都整理成问题，留给团队回答。
2. 反馈描述用例，而非团队的代码。 简报中介绍团队代码的部分可以引用 file:line。给 Cursor 的反馈只说明应用需要做什么，以及 Origin 缺少哪些能力，并使用 Origin 术语；不得包含文件路径、模块名称、框架细节或仓库名称。

需要查明的内容

为每个项目记录 file:line，并注明你查找过但未找到的内容。

• 声明的权限和事件：从清单或已提交到代码库的基础设施代码中查找；如果没有，则根据调用推断。
• 应用处理的每个 Webhook 事件，以及每个处理程序读取的每个负载字段，包括仅用于日志记录的字段。
• 每个 REST 和 GraphQL 调用，包括代码传入的参数和筛选条件、读取的响应字段、调用是在每次 Webhook 中执行还是在循环中执行，以及分页方式。
• 身份验证：JWT 算法、应用安装后如何获取安装 ID、如何处理令牌过期、是否有用户登录及其用途，以及是否会克隆或推送 git。
• Webhook 接收器：如何验证签名、验证时是否有原始请求正文，以及如何对投递去重。
• 框架或库代表应用发出的调用。Probot 的接收器、令牌缓存和配置加载器；Octokit App 的安装和仓库列表；应用身份验证库。阅读依赖项文档，并将这些调用标记为「来自 <dependency>」。

如何映射

简报需要完整规范，但 openapi.yaml 和 llms-full.txt 都有几十万字节，太大了，无法一次性完整读入上下文。如果可以，请将它们保存在本地的临时位置，且放在应用仓库之外，以免覆盖或遗留工作树中的文件，然后搜索并只阅读匹配的部分：

• openapi.yaml 中的 x-origin-scopes: 标记每个操作所需的权限范围；operationId 在上一行。
• openapi.yaml 中的 x-origin-webhook-events: 标记每个 Webhook 负载架构及其对应的事件 slug。
• llms-full.txt 中的 ### <Endpoint name> 和 ### <Payload type> 标题会开启相应端点或负载字段的说明部分，字段以点分隔路径表示；从标题开始读到下一个 ###。

之后遇到单个问题时，从 llms.txt 开始，只获取相关部分。

• 匹配的名称只是候选项，不代表答案。请对照代码传递和读取的内容，检查操作说明、参数和响应字段。如果代码依赖的参数或字段缺失，这就是一种变通方案或缺口，而不是匹配项。
• GitHub 中位于 /issues/{n}/… 下的拉取请求调用（评论、标签）在 Origin 上对应拉取请求端点。如果代码将这些调用用于实际议题，请参阅 references/brief.md 中的“Where GitHub features live on Origin”。
• Origin 不支持 GraphQL。请将每个查询拆分为 REST 调用，并记录扇出情况。
• 要请求的权限范围，是你列出的各项操作的 x-origin-scopes.scopes 的并集。不要翻译 GitHub 清单。
• 每对 GitHub 事件和操作最多只对应“Events”中的一个 slug。操作是 slug 的一部分。没有对应 slug 的事件和操作对，不属于 Origin 上的事件。
• 对于代码读取的每个负载字段，请记录该字段是位于负载中、位于负载外围的投递封套中（event.type 携带操作）、需要额外读取（注明操作以及每个事件需要的调用次数）、可根据其他字段计算，还是缺失。负载是快照。如果 REST 资源中有某字段，但负载中没有，就需要额外读取。
• 文档从未提及的能力当前不可用。请向团队询问。文档既未确认也未否认的行为，需要提出问题，并在端到端测试中加入检查该行为的步骤。不要假定它的工作方式与 GitHub 上相同。

完成前

每项关于 Origin 的说法都应指向已保存文档中的依据。每个缺口都应有一条反馈记录，并注明其代价。反馈不得透露团队的内部信息。摘要应点明原生还是镜像这一问题。