发布与签名
发版要用的凭据是最不想到处散落的那种：GPG 私钥、p12 证书密码、Apple 专用密码、Sonatype Portal 口令。它们通常被塞进 ~/.m2/settings.xml、CI 的环境变量、某个 .env，然后被忘掉。
Sigil 把这两类凭据收进金库，需要时再临时落地。
Maven Central 发布
凭据类型 maven_central，一条记录装齐一套发布身份：命名空间、Portal 账号口令、GPG 密钥 ID 与口令、GPG 私钥。
| 能力 | 用途 |
|---|---|
maven_import_from_settings | 从本机 ~/.m2/settings.xml 把现成配置收编进金库 |
maven_settings_materialize | 临时渲染一份 settings.xml 供构建使用 |
maven_deployment_status | 查某次上传的部署状态 |
maven_deployment_publish | 正式发布到 Central |
maven_deployment_drop | 丢弃一次尚未发布的部署 |
maven_artifact_exists | 核对某个坐标是否已出现在 Central 主仓 |
为什么发布比删仓库还慎重
maven_deployment_publish 走阻塞式确认，而且理由比删仓库更硬：删掉的仓库还能重建，发到 Central 的构件不可删、不可改、永久留存。版本号写错、打包漏文件，都只能靠发下一个版本来盖，历史上那个错版本会一直挂在那里。
maven_deployment_drop 也要确认 —— 它可恢复，但代价是重跑一整轮构建。
两条要注意的
maven_artifact_exists不需要凭据。它打的是 Central 的公开主仓，谁都能查。所以即使你没存发布凭据，这个工具也照样露出，可以用来核对某个依赖在不在。- 同步有延迟。Portal 显示已发布，主仓要十几分钟到几小时才能解析到，这期间
maven_artifact_exists查不到属正常。
代码签名
凭据类型 code_signing，把 Windows 与 macOS 两套签名配置聚在一条记录里（签名身份、Team ID、Apple ID 与专用密码、p12 证书及其口令等）。
| 能力 | 用途 |
|---|---|
codesign_import_from_dir | 从本地签名资产目录导入（读取密钥 / 证书 / 密码文件） |
codesign_push_windows_secrets | 把 Windows 签名所需的值灌进 GitHub 仓库 Secrets |
codesign_push_apple_secrets | 把 macOS 签名 / 公证所需的值灌进 GitHub 仓库 Secrets |
codesign_materialize_local | 把证书与口令明文落到本地目录，供本机构建使用 |
三个高危动作都要确认
- 导入会让 Sigil 读取你指定目录下的密钥文件 —— 这是新增的本地文件读取面，弹窗里会显示完整路径，看清了再放行。
- 灌 CI Secrets 是把凭据送到 GitHub 上，属于外发。
- 本地落地会把证书和密码以明文写到磁盘。出了金库就不再受保护，用完请自行删除。
导入类工具不受凭据门控
codesign_import_from_dir 与 maven_import_from_settings 的作用恰恰是创建这两类凭据。如果它们也按「没有该凭据就隐藏」来处理，就成了鸡生蛋 —— 永远导不进来。所以这两个工具始终露出。
配合 GitHub Actions 用
典型的发版链路：
codesign_push_windows_secrets → 把签名材料灌进仓库 Secrets
codesign_push_apple_secrets
github_ref_create → 打 tag 触发 CI
github_runs_list → 盯构建状态
github_run_jobs → 失败了看是哪个 step
github_release_asset_upload → 补传产物（如果 CI 没传全）GitHub 侧的能力清单见 Git 平台能力。