cordis-plugin-github

Cordis（DeepSeek Harness）插件：为 AI agent 注册规范化的 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 的原始文本）会进入 agent 上下文；对大型仓库列表或原始文件调用一次就可能占用大量 token。
• 不自动重试：限流（403/429）不会被自动重试或退避，错误对象里附 rateLimitReset（epoch 秒）供调用方自行等待。
• 不碰本地 git 状态：插件不执行 clone / commit / push / checkout，也不读写当前仓库的工作区（临时目录除外）。

安装

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

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

重启后 agent 即可调用 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 时，先安装到 profile：

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。