rework-proof

REWORK Proof Check

以作业摘要的形式报告拉取请求中的提交实际由谁编写——签名状态、作者归属，以及声明的 AI 协助情况。

默认情况下，它不会向任何地方发送任何内容。它会使用你的工作流已有的令牌读取拉取请求中的提交，并写入摘要。无需账户、API 密钥，也不会有第三方访问你的代码库。

name: Proof
on: pull_request

jobs:
  proof:
    runs-on: ubuntu-latest
    steps:
      - uses: reworkio/REWORK-Proof@v1

设置就这么简单。

刚接触？ GETTING-STARTED.md 会引导一个全新的代码库配置此操作和 GitHub App——该选哪个、每个会授予什么权限，以及一组涵盖所有情况的提交，让你在信任报告之前先了解它实际会如何处理。

一键设置

将 OWNER/REPO 替换为你自己的值，然后打开此链接——GitHub 会打开编辑器，其中已写好工作流，你只需按下 Commit：

https://github.com/OWNER/REPO/new/main?filename=.github/workflows/proof.yml&value=name%3A%20Proof%0Aon%3A%20pull_request%0A%0Ajobs%3A%0A%20%20proof%3A%0A%20%20%20%20runs-on%3A%20ubuntu-latest%0A%20%20%20%20steps%3A%0A%20%20%20%20%20%20-%20uses%3A%20reworkio%2FREWORK-Proof%40v1%0A

如果你的默认分支不是 main，请将 /new/main 部分改为对应的分支名。

报告内容

针对拉取请求中的每个提交：

• 签名状态——GitHub 是否能够以加密方式验证该提交。
• 作者归属——GitHub 将提交归属到的账户是否是拉取请求的作者。如果提交的电子邮件从未与 GitHub 账户匹配，则不会标记；这很常见，若因此标记只会造成检查噪声。机器人账户（带有 [bot] 后缀，例如 dependabot、github-actions）会被归类为自动化，并与人类共同作者分开列出。
• 声明的 AI 协助——提交消息中提及编码助手的内容：Co-Authored-By: Claude（或 Copilot、Codex、Gemini、Cursor、Devin、aider，……）尾注、Claude-Session: 或 Amp-Thread-ID: 尾注，或 Generated with <tool> 行。完整列表见 src/ai-trailers.json，GitHub App 检查也会读取同一文件，因此无论哪种方式，提交都会得到相同的识别结果。

声明 AI 协助不会降低检查结果。作者选择如实说明，这是良好的做法；惩罚尾注只会教人们把它删掉——这会破坏对需要它的人有用的信号。

“未声明”就是未声明。 此操作会读取提交消息。没有尾注的消息看起来都一样，无论是否有工具编写了代码，因此计数为零只表示没有任何声明，绝不表示没有使用工具。

未签名的提交也不会被视为问题。大多数代码库从未启用签名。检查会报告能够证明的内容，并明确说明无法证明的内容。

合并后应用会记录的内容

该 Action 会针对一个拉取请求生成报告，然后结束。接收拉取请求关闭事件的 GitHub App 也会记录处理结果：

• 合并情况。 当 GitHub 报告某个已检查的拉取请求已合并时，应用会将其记录到此前已运行的检查中，并一并记录仓库的其他检查对该拉取请求最终提交的结论。应用不会凭空记录它从未检查过的工作已合并。
• 仓库徽章随后会显示“已验证 N 个 PR · S% 已签名 · 已合并 M 个”：已检查的不同拉取请求数量、GitHub 报告为已签名的所有已检查提交所占比例，以及其中已合并的拉取请求数量。徽章不会根据判定结果选择颜色；合并是维护者促成的结果，不是评分。
• 压缩合并说明。 如果拉取请求声明了 AI 辅助，或包含非作者提交的提交，而压缩后的合并提交不再带有该说明，应用会在合并提交上发布第二个中性的检查运行，标题为“已保留拉取请求中的披露信息”。它会重述拉取请求的提交中声明的内容，确保默认分支仍能显示这些信息。真正的合并提交或变基不会丢失信息，也不会收到说明。
• 重新验证。 GitHub 验证通过的签名之后可能不再通过，因此应用每晚都会重新读取近期结果所涉及的提交（每晚最多 200 条结果，且每条结果的时间不超过 90 天）。如果某条结果此前因所有提交都已签名而显示为“成功”，当这一条件不再成立时，就会降为“中性”。读取未能完成时，不会更改任何内容。

有关这些计数如何影响 REWORK 成员自己的评分和徽章，请参阅 reworkdigital.io/docs/proof。

签名证明（可选）

将 attest: true 设为启用后，该 Action 会向 REWORK 请求本次运行的签名时间戳证明：

jobs:
  proof:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write        # required for attestation
    steps:
      - uses: reworkio/REWORK-Proof@v1
        with:
          attest: true

仍然不需要 API 密钥。 工作流会生成一个短期有效的 OIDC 令牌，由 GitHub 授权证明本次运行所属的仓库和工作流。仓库设置中不会存储任何长期凭据，因此无需担心泄露或轮换。

只会发送计数，不会发送代码，也不会发送提交消息。

生成的结果是紧凑型 JWT 格式的 W3C 可验证凭证。任何人都可以离线使用 REWORK 发布的密钥进行验证，密钥地址为 https://api.reworkdigital.io/api/v1/proofs/credentials/jwks.json；无需回连 REWORK，因此从未听说过我们的读者也能验证。

证明失败绝不会导致构建失败。本地结果仍然有效。

证明声明的内容与不声明的内容

凭证的 assurance 字段会标明以下某个级别。文本由 mcp/src/assurance.json 呈现；MCP 服务通过该文件响应 explain_rework_assurance，reworkdigital.io/github 页面也会呈现该文件，因此所有展示位置声明的上限一致。

工作流身份（workflow-identity），中等：身份方面有力，不涉及质量

证明：GitHub 以密码学方式确认，某次特定工作流运行属于特定仓库和提交；REWORK 记录了该运行观察到的作者身份信号：提交签名状态、每个提交是否对应拉取请求作者，以及有多少条提交消息声明了 AI 辅助。

不证明：没有人审查代码、运行代码或评判其质量。它不表示成果很好，只说明 git 历史记录显示由谁编写。AI 计数依据的是作者在提交消息中声明的内容：计数为零表示没有人声明使用 AI，并不代表没有使用任何工具。

经审查的参考材料（reviewed-reference），中等：经人工检查，但检查对象是演示，而非制品

证明：REWORK 审查人员观看了演示视频，并确认视频与所声称的成果相符；视频还经过指纹标记，因此可以检测是否被重复使用。

不证明：审查人员没有审计源代码、复现结果，也没有核实视频中口头陈述的内容。

跨平台关联（cross-platform-join），中等：清楚说明哪些字节存放在何处，以及谁控制两端；不涉及这些字节是如何生成的

证明：清单摘要指定的确切字节，已存在于指定的 Hugging Face 仓库中、指定的提交上，并且是在指定的 GitHub Actions 运行结束后立即确认的；确认依据是 REWORK 自己对 Hub 的独立读取。一个 REWORK 账户同时持有该 GitHub 仓库所有者的 App 安装，并拥有对 Hugging Face 仓库已验证的写入控制权。

不证明：它不能证明工作流生成、训练或评估了这些内容。即使某次运行只是下载他人的文件再上传，也会携带这些字节。请阅读工作流引用，判断该运行实际做了什么。

凭证在自己的免责声明中也说明了这一点。

输入

输入	默认值	描述
github-token	${{ github.token }}	用于读取拉取请求的提交。无需额外权限。
attest	false	请求签名证明。需要 id-token: write。
api-url	https://api.reworkdigital.io/api/v1	仅用于可自托管的 REWORK 覆盖设置。
require-signed	false	如果有任何提交未签名，则失败。建议保持关闭。参见设为阻止条件。
require-ai-disclosure	false	如果没有提交说明是否使用了 AI 辅助，则失败。参见设为阻止条件。
fail-on-unsigned	false	require-signed 的旧名称；仍然有效。

设为阻断条件

默认情况下，这里的任何检查都不会导致构建失败；对大多数仓库来说，这也是正确的设置。希望报告阻断检查的仓库，只需启用两个键，并为 Action 和 App 各设置一次：

# .github/rework-proof.yml
require_signed: true
require_ai_disclosure: true

• require_signed: true：如果任何提交都没有 GitHub 能验证的签名，则检查失败。
• require_ai_disclosure: true：如果拉取请求中没有任何提交说明是否使用了 AI 辅助，则检查失败。注明助手名称的 Co-Authored-By: 尾注可以满足此要求，提交消息中的 AI-Assisted: none 也可以。因此，即使拉取请求是在没有使用 AI 的情况下编写的，也有办法说明这一点，而不至于因此失败。

只有字面值 true 才会启用策略；带引号的 "true" 不会。App 会从默认分支读取该文件，因此拉取请求无法为自身启用或关闭策略。只要工作流中有检出步骤，Action 就会从检出内容中读取同一个文件；没有检出步骤的工作流则可以改为通过输入传入相同的两个开关：

jobs:
  proof:
    runs-on: ubuntu-latest
    steps:
      - uses: reworkio/REWORK-Proof@v1
        with:
          require-signed: true
          require-ai-disclosure: true

如果文件存在且设置了任一键，文件中的设置就是完整声明，不会再查询输入。无论是否会阻断，检查结果的报告方式都相同；策略只会改变最终结论，失败消息会指出是哪个文件或输入要求启用该策略。

输出

输出	描述
commits-total	检查的提交数。
commits-signed	带有可验证签名的提交数。
commits-foreign	归属于 PR 作者以外的人类账户的提交数。
commits-automation	由机器人账户（后缀为 [bot]）编写的提交数。
ai-disclosed	在消息中声明使用了 AI 辅助的提交数。零表示没有声明，不代表没有使用。
credential	启用 attest 时生成的已签名 VC-JWT。

限制

提交读取最多处理 300 个提交。更大的拉取请求会被报告为无法确定，而非检查通过——若只读取了部分提交却声称“全部已验证”，才是真正会主动误导人的失败情形。

指向此处的证明不会自动持续保持已验证状态

Action 会针对一个拉取请求生成报告，然后就此结束。引用 GitHub 仓库的 REWORK 证明则不同：它会被重新观测；如果仓库后来被删除、设为私有、转移或封锁，证明就会失效，而不是继续显示“已验证”，却指向任何人都无法再打开的证据。

这些具体规则比大范围检查更重要：

• 同一所有者进行重命名时会继续追踪，而不会因此处罚，因为工作内容没有改变
• 服务中断、超时和速率限制都不会导致证明失效——这些问题由我们负责处理
• 必须出现连续两次明确失败，才会撤销任何内容

重新检查时会有意匿名读取仓库。验证是在作者自己的令牌下运行的；之后要确认的是，买家是否仍能打开证据。

检查的 Details 链接会指向哪里

仅适用于 App，且这是有意采取的严格限制。检查运行是公开的，且显示在他人的拉取请求上，因此将其链接到 REWORK 个人资料，就相当于在对方同事面前作出身份声明。只有在两端都已验证时才会建立链接：GitHub 告诉我们哪个账户安装了 App，而该账户也通过设置链接登录了 REWORK。否则，链接会指向公开证明页面，并在摘要中附上邀请，不作任何身份声明。

绝不会查询自行填写的个人资料字段。若信任此类字段，任何人都能在陌生人的拉取请求上为自己打广告。

实现

一个不依赖任何外部依赖的 Node 文件：src/main.js。没有打包后的 dist/，没有 node_modules，也没有构建步骤。你读到的内容就是实际运行的内容。

相关内容

无需添加工作流，即可在每个拉取请求上自动验证；REWORK Proof GitHub App 会发布与检查运行相同的结果。

• GETTING-STARTED.md — Action、App，以及如何将 Hugging Face 发布内容与生成它的构建关联起来
• reworkdigital.io/github — GitHub 端会检查什么，以及它刻意不声称什么
• reworkdigital.io/huggingface — Hub 端：控制流程，以及 REWORK 自行运行的可复现评估，而不是轻信下载量
• mcp/ — 通过 MCP 为 AI Agent 执行相同的检查

许可证

MIT — 详见 LICENSE。