osFoundry / Platform
Pull Request
覆盖整个工作区的 PR 仪表盘。CI 状态、评审人、冲突——一目了然。
简介
Pull requests 是 osFoundry 的 Code & Build 区域中的代码审阅看板。你不必再在多个仓库之间来回切换，去弄清哪些 PR 是绿的、谁的审阅还没交、哪个卡在冲突上，而是得到一份覆盖整个工作区的列表，把你真正用来做判断的信号推到眼前：CI 状态、已请求和已完成的审阅人，以及合并冲突。维护者一天要问上十几遍的那个问题——「哪些能合、哪些卡住了？」——它都能回答，无需逐个打开 PR。
由于 osFoundry 以 local-first 桌面工作区的形态运行，这份看板与你的聊天、智能体、代码、知识和数据同处一地，而不在另开的浏览器标签页里。你读 PR 的那个窗口，也正是你可以让 AI 模型总结 diff、起草审阅意见、解释某项检查为何失败的窗口。而那个模型就是你自己接入的那一个，可以是 local、云端或自托管，用你自己的 API key，没有任何转售加价。为了得到这份一览，代码和审阅无需离开你的机器。
这之所以重要，是因为多数团队的时间都耗在审阅延迟上，而根源往往是看不见，而非不肯出力。一个 PR 明明是绿的、可以合，却因没人留意而搁置两天；另一个因冲突从未被暴露而卡住了发布。把 CI、审阅人和冲突汇入一份有序的视图，就把「四处去找」变成了「看一眼就动手」，而且这份视图就留在你本就工作的地方，而不是藏在又一次登录和又一份按席位计费的账单背后。
主要功能
- 在一份列表里看清工作区内每一个开放的拉取请求，无需逐个打开仓库
- 一眼读出 CI 状态，随即知道哪些 PR 是绿的、可合并，哪些检查未通过
- 按 PR 跟踪审阅人：请求了谁、谁已批准、还有什么在等审阅
- 及早发现合并冲突，而不是等到合并时或发布途中才撞上
- 就在你的 local-first 桌面工作区里审阅，紧挨着聊天、智能体、代码和数据，用你自己的 AI 模型和 API key
使用场景
- 维护者：每天早上打开看板，找出那些已是绿的、已审阅的 PR，直接合并，无需在各仓库间翻找
- 团队负责人：扫一眼审阅人列，看清哪些拉取请求在等审阅，然后提醒对的那个人
- 发布负责人：在切发布之前就抓出带合并冲突的 PR，而不是在合并途中撞个正着
常见问题
看板会显示来自多个仓库的拉取请求吗？
会。这是一份覆盖整个工作区的视图，因此你工作区中各仓库的开放 PR 会汇在同一份列表里，而不是一个仓库一个仓库地看。这正是看板的意义：一处看全，而不必在仓库之间来回切换。
每个拉取请求一眼能看到些什么？
就是你通常据以行动的三个信号：CI 状态（是否通过）、审阅人（请求了谁、谁已批准、还有什么待处理）以及合并冲突（能否干净地合并）。目标是不必打开每个 PR，就能分辨哪些已就绪、哪些被卡住。
使用它需要另外订阅或按席位付费吗？
不需要。Pull requests 是 osFoundry 桌面工作区的一部分，采用 bring-your-own-key，没有按席位计费。你在 PR 上用到的任何 AI 协助，都跑在你自己接入的模型和 API key 上，可以是 local、云端或自托管，没有转售加价，而你的代码可以留在你自己的设备上。