GitHub API 工具 xinvxueyuan/cordis-plugin-github

cordis-plugin-github

Cordis（DeepSeek Harness）插件：给 AI 智能体注册规范化的 GitHub API 工具。

默认走本机已登录的 gh CLI 执行（gh api，参数数组 spawn、不经 shell，杜绝引号/转义错误）； gh 缺失或未登录时自动回退原生 HTTP（Node fetch + token）。

覆盖 gh CLI 没有专门子命令的全部端点 —— 任意 REST 端点 + GraphQL 均可调用。

安全不变量与副作用披露

本插件是 GitHub API 的透传层，不隐藏任何破坏性能力。以下按真实实现逐条列出：

- 写操作会真实修改远端数据：github_api 的 POST / PATCH / PUT / DELETE 直接作用于 GitHub 上的真实仓库与账号（包括更新引用、删分支、改 issue、上传 release asset 等），没有 dry-run、没有二次确认、失败也不回滚。调用前的确认责任在调用方。
- github_graphql 同样是写通道：它把 query 原样 POST 到 /graphql，因此里面写 GraphQL mutation 一样会真实改远端数据（并非只读查询工具）。
- 会 spawn 本机外部命令：gh 后端会启动 gh api（参数以数组传递，不经过 shell）。mode: auto 下还会先执行 gh --version 与 gh auth status 各一次（各 5 秒超时）来判断 gh 是否可用。
- 会在系统临时目录落一个文件：带 body 的 gh 调用会把 JSON 请求体写入 <系统临时目录>/cordis-gh-/body.json，供 gh api --input 读取；调用结束（含抛错）即在 finally 中递归删除该临时目录。
- 需要凭据：gh 后端依赖 gh auth login 的登录态；HTTP 回退按 tokenEnv → GH_TOKEN → GITHUB_TOKEN → gh auth token 的顺序解析 token，并以 Authorization: Bearer 请求头发送。token 只进环境变量与请求头，插件从不打印它；两者都拿不到时抛 status: 401 的错误。
- 网络出口仅限目标 GitHub 主机：HTTP 回退只请求 https://<host>/<endpoint>（默认 api.github.com，企业版用配置的 host），不经过任何第三方服务。
- 会把远端数据带回模型上下文：工具返回值（含 paginate 合并后的数组、raw: true 的原始文本）会进入智能体上下文；对大型仓库列表或原始文件调用一次就可能占用大量 token。
- 不自动重试：限流（403/429）不会被自动重试或退避，错误对象里附 rateLimitReset（epoch 秒）供调用方自行等待。
- 不碰本地 git 状态：插件不执行 clone / commit / push / checkout，也不读写当前仓库的工作区（临时目录除外）。

安装

在配置档的 cordis.patch.yml 中插入（路径用绝对路径，loader 直接加载 TS 源码）：

- insert:
- id: github
name: 'C:/dev/dsh/src/index.ts'
config:
mode: auto

重启后智能体即可调用 github_api 与 github_graphql。

组合节点（官方）

本插件在 bundle patch（cordis.patch.yml）里显式声明它消费的官方服务节点；inject: 在 bundle patch 与 src/index.ts 中必须保持一致（由 test/manifest.test.ts 守护：从两处文本提取名单并断言集合相等）。

| 服务键 | 官方提供方（Loader row / 包） | 必需性 | 本插件用途 |
| tools | row tools / @deepseek-ai/dsh-tools | 必需 | 注册 gh 系工具（github_api / github_graphql / github_ci_watch） |
| jobs | row jobs / @deepseek-ai/dsh-jobs-local | 可选（reactive） | 长任务轮询：github_ci_watch 的 mode: background 与前台超时转后台句柄；缺它时插件仍激活，只退化为内联前台轮询 |

tools 缺失时插件无法注册任何工具，因此写进 inject；jobs 走 ctx.inject(['jobs'], …) 的 reactive 注入，不在 inject 列表里，缺少该服务时插件照常激活。

配置（Config）

| 字段 | 默认 | 说明 |
| mode | auto | auto：gh 已安装且已登录则走 gh，否则 HTTP；gh / http 强制后端 |
| ghPath | gh | gh 可执行文件路径 |
| host | api.github.com | HTTP 回退的 API 主机（企业版填 github.example.com） |
| tokenEnv | | 存放 token 的环境变量名（如 GH_TOKEN）；HTTP 回退时按 tokenEnv → GH_TOKEN → GITHUB_TOKEN → gh auth token 顺序解析 |
| timeoutMs | 60000 | 单次调用超时（同时作为工具的 timeoutMs 预算） |
| maxPages | 50 | 分页页数上限（防失控），超出截断 |
| perPage | 100 | 分页每页条数 |
| ciIntervalMs | 15000 | CI 监控的轮询间隔（下限 5000ms，避免打爆速率限制） |
| ciWaitMs | 300000 | 前台 CI 监控的等待预算（硬上限 600000ms；超时转后台句柄） |
| ciMaxLogLines | 200 | 报告里每个失败单元的日志尾部行数上限 |
| ciMaxLogBytes | 65536 | 报告里每个失败单元的日志尾部的字节上限 |

工具

github_api（任意 REST 端点）

- endpoint（必填）：不带前导斜杠，如 repos/owner/repo/issues
- method：GET / POST / PATCH / PUT / DELETE / HEAD（默认 GET）
- query：查询参数对象
- body：JSON 请求体（写操作）
- paginate：自动翻页合并数组（默认 per_page=100，最多 maxPages 页）
- raw：以原始文本返回响应体（raw 文件内容、tarball 等非 JSON 端点）
- host：单次调用覆盖 API 主机

github_graphql

- query（必填）：GraphQL 查询
- variables：查询变量对象（可选）
- host：覆盖 API 主机

github_ci_watch（长生命周期 CI 监控）

给一个 CI 标识，持续轮询到终态并回报结论、失败单元与日志尾部。

目标解析（四选一，歧义或缺失会明确报错）

| 输入 | 含义 |
| repo + run_id | Actions run |
| run_url | https://github.com/<owner>/<repo>/actions/runs/<id>，可带 /job/<job_id>；企业版主机从 URL 推导 |
| repo + check_suite_id | check suite（汇总其 check runs） |
| repo + check_run_id | 单个 check run（输出 + annotations） |

参数：mode（foreground 默认 / background）、timeout_ms（仅前台，默认 ciWaitMs，硬上限 600000）、interval_ms（默认 ciIntervalMs，下限 5000）、log_tail（failure 默认 / always / none）、max_log_lines（默认 ciMaxLogLines）、host（企业版 API 主机）。

两种模式

- mode: "foreground"：在调用内阻塞等待，CI 到终态即返回最终报告；超过 timeout_ms 仍在跑则返回 promoted 句柄（作业 id），监控继续在后台运行。正常结束的调用不留下作业记录。
- mode: "background"：立即返回作业句柄（形如 ci-<id>，具体形态由上游 dsh-jobs-local 决定），随后用内置 job_output 读状态时间线与最终报告、job_list 列出、job_kill 停止；终态会由既有作业唤醒机制在后续轮次自动回报。

状态约定（重要）

- CI 自身成功或失败都使作业结算为 completed，CI 的结论写在 detail / result / 报告里。
- 只有监控自身故障（鉴权失败、404、连续网络失败超过阈值）才结算为 failed，并附最后一次错误。
- 日志抓取失败只写入 stderr 通道并降级为「无日志尾部」，不影响结算。
- 状态变更行走默认通道（模型可见）；纯叙述走 log 通道（仅 UI）；错误走 stderr；实时进度走 updateProgress。

示例

// 前台：等一次历史 run 的结论 { "repo": "xinvxueyuan/cordis-plugin-github", "run_id": 37439750365, "mode": "foreground" }

// 后台：拿到 ci-<id> 后用 job_output / job_kill 管理 { "run_url": "https://github.com/owner/repo/actions/runs/123456", "mode": "background" }

// 失败时抓取日志尾部（前台或后台都可） { "repo": "owner/repo", "check_run_id": 987654321, "log_tail": "always", "max_log_lines": 80 }

依赖：后台模式需要宿主组合里有 ctx.jobs（@deepseek-ai/dsh-jobs + @deepseek-ai/dsh-jobs-local，作业句柄由内置 job_output / job_list / job_kill 消费）。本插件把它声明为可选 peer：没有作业注册表时 mode=background 会明确报错，mode=foreground 仍以纯内联轮询工作（不产生作业，也不触发唤醒）。内联前台路径还需要宿主提供 agent 上下文：真实 profile 恒有 dsh-agent，只有「作业注册表存在、agent 上下文缺失」这种畸形装配下，前台才会直接报错。

gh 无子命令的常用端点速查

| 领域 | 端点示例 |
| Actions | repos/{o}/{r}/actions/runs、.../actions/runs/{id}/jobs、.../actions/artifacts、.../actions/workflows/{id}/dispatches（POST） |
| Codespaces | user/codespaces、user/codespaces/{name}/start（POST） |
| Environments | repos/{o}/{r}/environments、.../environments/{name}/secrets |
| Org | orgs/{org}/members、orgs/{org}/teams、orgs/{org}/audit-log、orgs/{org}/actions/runner-groups |
| Repos | repos/{o}/{r}/commits、.../compare/{base}...{head}、.../contents/{path}（raw: true）、.../releases、.../releases/{id}/assets（POST 上传） |
| Issues/PR | search/issues?q=...、repos/{o}/{r}/issues/{n}/timeline、.../labels、.../milestones |
| 用户/杂项 | user/gists、notifications、user/ssh_keys、rate_limit、meta |

边界与已知限制

- 只是 API 透传，不是 gh 的高层封装：不实现 gh pr create / gh release create 这类子命令语义，只表达 gh api 能表达的一次 HTTP 调用。
- 必须已认证：gh 未登录，且 tokenEnv / GH_TOKEN / GITHUB_TOKEN / gh auth token 全都拿不到 token 时，两条后端都不可用（抛 status: 401）。此时 mode: gh 不会静默回退 HTTP，而是直接报错。
- raw: true 不是二进制通道：raw 请求走 Accept: application/vnd.github.raw+json 并返回文本；gh 后端的 stdout 按 UTF-8 解码，因此 tarball 之类的二进制响应无法被无损取回。另外 raw: true 时 paginate 不生效（raw 不做翻页）。
- 分页有硬上限：paginate 按 page / per_page 循环，最多 maxPages 页；触顶时返回值带 truncated: true，不会继续翻页。
- 超时是调用级预算：timeoutMs（默认 60s）既是工具的调用预算，也是 HTTP 回退下每次 fetch 的超时；gh 后端自身不设子进程超时，只由工具层的取消信号终止。分页页数多时整体可能触及调用预算而中止。
- 非 JSON 端点必须显式 raw: true：否则解析失败并抛错（错误信息会提示改用 raw）。
- host 只影响 API 主机名：HTTP 回退固定使用 https://，不支持自定义端口、自签证书或代理设置。
- GraphQL 不做游标分页：github_graphql 是单次查询直通，连接（connection）分页需要调用方自己在 query 里写 after 游标。
- gh 的可用性是探测式判定：auto 模式用 gh --version + gh auth status 判定，判定失败就静默回退 HTTP，不会区分「没装 gh」和「装了但坏了」。
- 企业版细节交给 gh：--hostname 只透传给 gh，多主机凭据管理不在插件职责内；HTTP 回退使用单一 host 配置。
- CI 监控是轮询，不是 webhook：间隔由 interval_ms / ciIntervalMs 控制（默认 15s，下限 5s）；作业运行期间每次轮询发 1–2 个 GitHub 请求，同一账号下与 github_api 共享同一 GitHub 速率预算（长期监控请按 rate limit 预算设置间隔）。
- CI 监控只存在于当前进程：作业记录、状态时间线、快照都保存在本进程的作业注册表（ctx.jobs，进程内实现）里；宿主重启即失去全部监控——句柄不可恢复、时间线不可再读、也不会自动续跑。CI 的真相始终在 GitHub 侧，重启后重新调用一次 github_ci_watch 即可（已到终态的目标会立刻返回结论）。
- 连续失败只退避 4 档，第 5 次即报错：可观测的退避序列是 5s → 10s → 20s → 40s（backoffMs 的 60s 封顶要等阈值调到 6 次以上才会出现）；默认阈值下连续第 5 次失败不再等待，直接结算 failed 并附最后一次错误。失败即报错优先于「退避到封顶」。
- 终态只唤醒一次：后台作业结算时由既有 dsh-tool-jobs 机制向 owner 交付一次通知（前提是 settled.awaited=false 且有 owner）；前台调用自己把结果收走（awaited=true）因此不再打扰，被 job_kill 停止的作业也不发通知。插件不实现第二套唤醒机制。
- CI 监控的日志端点：Actions 日志走 GET repos/{r}/actions/jobs/{id}/logs（302 到签名 URL，客户端跟随重定向）。gh 后端默认拒绝含终端转义序列的响应，插件对该端点显式加 --allow-escape-sequences，并在写入报告前剥掉 ANSI 颜色码。check suite / check run 没有 job 日志，改为取 output.title/summary/text 与 annotations。
- 日志按需抓取且有界：默认 log_tail=failure 只抓失败单元（always 抓所有带 job id 的单元，none 完全不抓）；max_log_lines 与 ciMaxLogBytes 分别限制每个单元的尾部行数与字节数，超限只保留尾部并在报告里标注「（已截断：原文 N 行）」。
- log 通道不进模型可见输出：状态变更与结论走默认通道（模型可见），纯叙述（如「抓取单元 … 的日志尾部…」）走 log 通道；job_output 只返回 stdout / stderr 与终态 result，所以叙述不占用模型上下文。
- 日志尾部可能含敏感内容：插件只做 ANSI 剥离与截断，不做脱敏——构建日志里可能有环境变量、token 片段、内部主机名，这些内容会原样进入报告、作业输出环与模型上下文；转发、提交或粘贴前请自行检查。
- 超量输出可能被宿主落盘（spill）：作业输出环按字节保留（宿主默认活动期 256 KiB、结算后 16 KiB），超出部分的最旧字节被丢弃（读取会报告 lossy）；当输出被 harness spill 到临时文件时，job_output 结果里会带 spillPaths 指向该文件——它同样可能含敏感内容。本插件的 CI 作业只用 append、不提供 pull source，因此自身不产生 spill 文件。
- 无作业注册表时的 timeout_ms：该装配下 timeout_ms 仍会校验（非法值一律报错），但不参与等待——前台内联轮询由工具级超时兜底。

开发

npm install
npm run typecheck # tsc 类型检查（erasable-syntax-only，兼容 Node 原生 type stripping）
npm test # 单元 + 注册 + CI 监控单元 + CI 作业集成（真实 dsh-jobs-local + 假客户端，无网络）
npm run test:integration # 只读集成冒烟：gh/http/404/分页/GraphQL（需要 gh 或 token）

设计要点

- 不经 shell：gh 与子进程参数均以数组传递（spawn），请求体写临时文件经 --input，无任何引号/转义注入面。
- 错误契约：失败抛 GithubApiError（status + 消息；403/429 附 rateLimitReset）；404 与空列表区分；非 JSON 响应需 raw: true。
- 分页统一：两条后端都按 page/per_page 循环，遵守 maxPages 上限。
- 取消：工具执行尊重 exec.signal（spawn 挂 signal；fetch 用 AbortSignal.any 合并超时）。
- 安全：token 只进环境变量/请求头，永不打印。

npm 发布（@xinvxueyuan/cordis-plugin-github）

- 仓库: https://github.com/xinvxueyuan/cordis-plugin-github
- npm: npm install @xinvxueyuan/cordis-plugin-github
- 许可: MIT OR Apache-2.0（见 LICENSE-MIT / LICENSE-APACHE）

通过 npm 包接入 Harness 时，先安装到配置档：

dsh plugin add @xinvxueyuan/cordis-plugin-github

再在 cordis.patch.yml 中引用包名（替代 file URL）：

- insert:
- id: github
name: '@xinvxueyuan/cordis-plugin-github'
config:
mode: auto

发布流程（维护者）— staged publishing

采用 npm staged publishing：CI 用 npm stage publish（OIDC 可信发布，无需 token / 2FA）把版本放入 registry 的 stage 队列，维护者用 2FA 批准后版本才真正上线（proof-of-presence）。

1) 构建 + 本地核对
npm run build
npm pack --dry-run

2) 打签名标签并只推 tag → GitHub Actions 自动跑测试 + npm stage publish（进入 stage 队列）
git tag -s v0.2.0 -m "release: v0.2.0" && git push origin v0.2.0

3) 人工 2FA 批准上线
npm stage list @xinvxueyuan/cordis-plugin-github # 取 <stage-id>
npm stage approve <stage-id> # 需要 2FA

（旧版 npm publish 直发流程已被 CI 的 staged 流程取代。）

publish.yml 在两个发布 job 前都有幂等守卫：先用 npm view "<包名>@<package.json 的 version>" version 判断该版本是否已存在于目标 registry，已存在就跳过发布（并在 Step Summary 写明"该版本已存在，跳过发布"），因此对已发布版本重推 tag 不会产生必然失败的公开红叉。其它检查错误（网络、鉴权、registry 故障）仍会让 job 失败。

GitHub Release 与签名

现状（务必如实理解）：以下机制已在真实发布中执行过，不再是纸面流程。
已发布的 Release：v0.1.1、v0.1.2、v0.2.0、v0.2.1 —— 每次都创建 annotated + GPG 签名 tag，附件为 .tgz、SHA256SUMS 与分离签名 SHA256SUMS.asc，tgz 与 SHA256SUMS 都带构建来源证明。
上一版 v0.2.0（2026-10-12）：tag 对象 f3c73ff09a18c92d7b9e604b09a51cdb42139ac9（指向提交 62cff266b93fddb82cdc05cf9856840c248b3bb9，GitHub 侧 verification.verified=true / reason=valid）；Publish run 38266407874 的三个 job（Test / Stage for npm / GitHub Packages）全 success；Release run 38266407771 全 success。

当前发布事实（2026-10-19，v0.2.1）

| 项目 | 状态 |
| npm registry（registry.npmjs.org） | latest = 0.2.1（已上线 2026-10-19）。入队来源：stage id 70154233-22c3-4b78-9229-c22c9ba0a621、shasum 2cd0da2b31b92299937e84dc2ef83347316ab8cd、staged by: GitHub Actions (trusted automation)；批准（npm stage approve 70154233-…）由维护者本人在 2FA 下执行，发布者未代做；批准后 npm stage list 已清空 |
| GitHub Packages（npm.pkg.github.com） | cordis-plugin-github 已有 0.2.1（本轮 CI 的 Publish to GitHub Packages job success），以及更早的 0.2.0（version id 1374076839）与 0.1.2 |
| GitHub Release | <https://github.com/xinvxueyuan/cordis-plugin-github/releases/tag/v0.2.1>，资产 xinvxueyuan-cordis-plugin-github-0.2.1.tgz（56 481 B）与 SHA256SUMS；tgz sha256 = b5554fcbd4a91218a71ff675d9da346221edf46fccfe57069ff11ed5e7e85af7，其 SHA1 = 2cd0da2b31b92299937e84dc2ef83347316ab8cd == npm 上 published shasum ⇒ 同一份字节 |
| tag | annotated + GPG v0.2.1；tag 对象 cf7c0f29376f50a6e4a6c205fbb41375362f44c4，指向提交 bad95d0a8c3afff46efc619507e3a85918752761 |
| CI | Publish run 39146370024 success；Release run 39146370022 success |
| 构建来源证明 | gh attestation verify <tgz> --repo xinvxueyuan/cordis-plugin-github --source-ref refs/tags/v0.2.1 退出 0；负向对照 refs/heads/main 退出 1 ⇒ 证明只命中本 tag |
| 本轮源码 | 发布提交 bad95d0a…，其后的合并提交 8e3e412（把两个 Dependabot 提交并入 main）。本版把 dsh- peer 加宽为 ^0.2.0-rc.2 \|\| ^0.2.1-rc.2 与 ^0.1.0-rc.6 \|\| ^0.2.0-rc.1 \|\| ^0.2.1-rc.2、devDeps 升到 ^0.2.1-rc.2，并跟随上游 dsh-jobs-local@0.2.1-rc.2 的 job id 形态变化（ci-<计数> → ci-<16位hex>）：把测试断言放宽为 /^ci-[\da-f]+$/（该断言原本锁的是上游实现细节；句柄可用性仍由 jobs.wait/jobs.read 端到端回环把关），并同步 3 处文字与 2 处 README 示例为 ci-<id>。tag 指向的提交不带后续 Dependabot 的 @types/node 26.6.4（仅 devDependency，不影响运行时与 peer 契约），该提升由 8e3e412 带入 main |

上一版发布事实（2026-10-12，v0.2.0）

| 项目 | 状态 |
| npm registry（registry.npmjs.org） | latest = 0.1.2；0.2.0 处于 stage 队列（stage id c90b9adb-a813-4ff5-9dcb-b48b12bb0399，shasum 70ff32ec1a700b06cce3dfcfe0da464589baf1af），等维护者 2FA 批准后才上线 |
| GitHub Packages（npm.pkg.github.com） | cordis-plugin-github 已有 0.2.0（version id 1374076839，2026-10-12）与 0.1.2（version id 1340095936） |
| GitHub Release | v0.1.1、v0.1.2、v0.2.0；v0.2.0 的 tgz sha256 = 9f966811953b161fb26935b8d1be6bea2c71a1be6d05e0cc77a92786a5a19bff |
| 本轮源码 | 提交 62cff266b93fddb82cdc05cf9856840c248b3bb9（github_ci_watch，18 文件），tag v0.2.0 指向该提交 |

| 环节 | 将采用的机制 |
| tag | annotated 且 GPG 签名的 tag（git tag -s），GitHub 上会显示 Verified 徽标。tag 由维护者在本机用私钥创建并推送，私钥永不进入 CI。 |
| Release 附件 | .github/workflows/release.yml 在 tag 推送（或手动 workflow_dispatch 指定 tag）时执行 npm pack，把产出的 .tgz 与 SHA256SUMS 上传为 Release 附件。Release 标题即 tag，正文由 gh release create --generate-notes 依据 commit 列表自动生成。 |
| 校验和 | SHA256SUMS 记录该 tgz 的 sha256（工作流内以 sha256sum -c 自校验）。 |
| 校验和的分离签名 | 维护者在本机用私钥对 SHA256SUMS 生成分离签名 SHA256SUMS.asc（gpg --armor --detach-sign SHA256SUMS），再手工把 .asc 附到 Release 上。这一步目前没有自动化，私钥也不进 CI；校验方用 gpg --verify 验签。 |
| 构建来源证明 | release.yml 调用 actions/attest-build-provenance（pin 到 commit SHA），为 tgz 与 SHA256SUMS 两者生成 Sigstore 签名的 SLSA 构建来源证明，可用 gh attestation verify 校验。 |
| npm 侧 | release.yml 完全不执行任何 npm publish；npm 发布只由上面的 publish.yml staged publishing 负责。 |

维护者操作顺序（v0.2.0 实际执行的顺序）：

1) 本机确认工作区干净、package.json 的 version 已就位（版本号由发布者手工提升）
git status --porcelain
npm run build && npm run typecheck && npm test

2) 提交并推 main —— main 的 push 不触发任何发布工作流（发布只认 tag）
git push origin main

3) 创建 annotated + GPG 签名 tag（私钥仅在本机使用；本机需能完成 GPG 签名）
git tag -s v0.2.0 -m "release: v0.2.0"

4) 只推 tag —— publish.yml 跑测试 + npm stage publish；release.yml 构建产物、生成来源证明并创建 Release
git push origin v0.2.0

5) 本机对从 Release 下载的 SHA256SUMS 做分离签名，再附回 Release（release.yml 不自动做这一步） gpg --armor --detach-sign -o SHA256SUMS.asc SHA256SUMS gh release upload v0.2.0 SHA256SUMS.asc

校验方式：

校验附件未被篡改 sha256sum -c SHA256SUMS

校验分离签名（需要维护者的公钥） gpg --verify SHA256SUMS.asc SHA256SUMS

校验构建来源证明（需要 gh CLI） gh attestation verify xinvxueyuan-cordis-plugin-github-0.2.0.tgz --repo xinvxueyuan/cordis-plugin-github gh attestation verify SHA256SUMS --repo xinvxueyuan/cordis-plugin-github

补充说明：

- release.yml 使用 gh release create --verify-tag，要求 tag 已存在、不会自行创建 tag；重复运行会转为「覆盖上传附件」。
- 所有 workflow 的 uses: 都 pin 到完整 40 位 commit SHA（当前：actions/checkout v4.4.0、actions/setup-node v4.4.0、actions/attest-build-provenance v4.2.2），由 .github/dependabot.yml 的 github-actions 生态负责推进。

发布记录：v0.3.0（2026-10-20）—— 以官方 bundle 形态发布

| 项 | 事实 |
| 内容 | 新增 cordis.patch.yml（Loader row github + 显式 inject: [tools]、默认 config.mode: auto）、package.json 的 dsh.bundle.patch 与顶层 icon、locale/{en,zh}.json、icon.svg、test/manifest.test.ts（守护 patch、inject 与源码集合相等、显示资源与打包面） |
| 提交 / tag | ca240ac「feat: ship as an official DSH bundle (v0.3.0)」，8 条显式路径；annotated + GPG v0.3.0，tag 对象 f84d11f6e1a8534a14bd1a4fbda7400d2465633f，git tag -v = Good（6C6FD9B2…B35A） |
| CI | Publish run 39387248504（Test ✅ / Publish to GitHub Packages ✅ / Stage package (with provenance) ✅）、Release run 39387248500 ✅ |
| stage / 上线（现查） | stage id 7573c49c-8b71-46b3-b627-0dd14685b860、shasum b1f576dd64383ad69e1c5ad0ddd110cd0a896120；dist-tags.latest = 0.3.0、dist.shasum 与 stage shasum、Release tgz 的 SHA1 逐字相同、provenance https://slsa.dev/provenance/v1、dsh.bundle.patch = ./cordis.patch.yml；上线时间 2026-10-20T07:41:45.099Z；npm stage list 已空 |
| Release | <https://github.com/xinvxueyuan/cordis-plugin-github/releases/tag/v0.3.0>，本轮为 CI 两资产：tgz（58 960 B）与 SHA256SUMS（109 B）；本地复算 SHA256 逐字一致（本轮未附手签 .asc） |

许可

本仓库采用 MIT OR Apache-2.0 双许可（与 package.json 的 license 字段一致），许可证原文见 LICENSE-MIT 与 LICENSE-APACHE。