android-publisher-cli 0.2.0-dev → 0.3.0

package/docs/daily-cli-workflow.md

@@ -1,101 +0,0 @@
-# 日常发布、查询与恢复
-
-本页以项目 `demo` 一次更新六个渠道为例。先完成[首次配置](colleague-quickstart.md)。准备各渠道 APK 和更新说明后，再建立本次批次。所有示例路径都要换成本机绝对路径。
-
-## 准备批次
-
-把本次更新说明写入私有文本文件。再创建 `batch.json`，逐个指定 APK；CLI 不搜索目录或猜测“最新”文件。
-
-```json
-{
-  "schema_version": 2,
-  "batch_id": "demo-1-0-0",
-  "project_id": "demo",
-  "release_notes_file": "/absolute/path/release-notes.txt",
-  "apks": {
-    "huawei": "/absolute/path/huawei.apk",
-    "honor": "/absolute/path/honor.apk",
-    "xiaomi": "/absolute/path/xiaomi.apk",
-    "oppo": "/absolute/path/oppo.apk",
-    "vivo": "/absolute/path/vivo.apk",
-    "tencent": "/absolute/path/tencent.apk"
-  }
-}
-```
-
-```sh
-android-release prepare --file "/absolute/path/batch.json"
-```
-
-命令会验签每份 APK，核对项目包名、签名及一致的版本。随后把产物复制到本机私有目录，并保存不可变批次。输出的 `batch_id` 应是 `demo-1-0-0`，`total_targets` 应为 `6`。失败时修正输入，再重新运行。换 APK 或说明时，使用新的批次名。
-
-`prepare` 不访问渠道。下一步才会读取真实账号数据：
-
-```sh
-android-release batch preflight --batch demo-1-0-0
-```
-
-CLI 会在终端提示六个渠道的凭据。预检读取账号和应用状态，并保存与批次绑定的结果。它不上传 APK 或提审。查看 `errors`，逐项处理失败的渠道。某个渠道成功不能代替整个批次通过。
-
-## 审阅与提交
-
-预检全部通过后，先建好仅自己可访问的输出目录，再生成批准文件：
-
-```sh
-android-release batch review --batch demo-1-0-0 \
-  --file "/absolute/path/approval.json"
-```
-
-核对输出中的账号、应用标识、包名、版本、渠道、APK 摘要、签名、说明和 `release_policy`。文件和输出中的 `approval.approval_plan` 是本次计划摘要。批准文件含发布内容，应私下保存。
-
-**下面的命令会上传 APK 并向六个渠道提审。** 确认你已获得覆盖应用、产物和渠道范围的授权。把摘要原样填入命令：
-
-```sh
-android-release batch submit --batch demo-1-0-0 \
-  --approval "/absolute/path/approval.json" \
-  --approve-plan APPROVAL_PLAN_FROM_REVIEW
-```
-
-提交前，CLI 再次核对批准文件、预检和所有选定 APK。每个业务请求都先记录意图，再保存可验证的回执。`accepted_targets` 统计已受理的渠道，不表示审核通过或公开上架。部分失败时保留全部输出和本地状态。
-
-只获准提交部分渠道时，在 `preflight` 和 `review` 使用相同的 `--channels oppo,honor`。提交命令直接使用批准文件绑定的选择，不再传 `--channels`。
-
-## 查询与报告
-
-```sh
-android-release batch status --batch demo-1-0-0 --refresh
-android-release batch report --batch demo-1-0-0 \
-  --file "/absolute/path/report.md"
-android-release history
-```
-
-刷新状态会提示输入凭据，并分别记录执行、审核、上架和查询健康。不加 `--refresh` 时，`status` 只读缓存。理解小米和应用宝的未关联信息，请读[自动查询说明](channels/automatic-observation.md)。
-
-报告文件的父目录也须已存在。报告只含本地摘要和已关联状态，不含渠道密钥、令牌或签名 URL。报告仍可能暴露包名、版本和发布进度；分享前请检查。
-
-## 中断与恢复
-
-网络错误或终端退出后，先看缓存，再运行只读核对：
-
-```sh
-android-release batch status --batch demo-1-0-0
-android-release batch reconcile --batch demo-1-0-0
-```
-
-响应丢失时，请求可能已经生效。当前协议证据不足以自动确认这些写入；`reconcile` 会保留阻塞。不要删除状态库、修改回执或创建新批次来绕过未决写入。核查远端结果后，交给维护者处理。
-
-若没有未决写入，且只是后续步骤未完成，可继续使用原批准文件：
-
-```sh
-android-release batch resume --batch demo-1-0-0 \
-  --approval "/absolute/path/approval.json" \
-  --approve-plan APPROVAL_PLAN_FROM_REVIEW
-```
-
-`resume` 跳过已确认步骤，并复核批准内容。退出码 `3` 表示部分目标失败或结果未决。退出码 `2` 表示输入或配置错误。任何提交错误都要先查看 `recovery_required`。
-
-## 本地数据
-
-新版项目、冻结产物、SQLite 日志、令牌和上传授权位于 `~/Library/Application Support/AndroidPublisherCLI/v2/`。0.1.x Go 版数据仍留在原目录，新版不会读取或迁移它。
-
-当前版本没有状态备份或恢复命令。需要备份时，先停止所有 CLI 进程，再私下复制整个 `v2` 目录及 SQLite 附属文件。恢复后先核对远端结果，再决定是否允许继续发布。备份含敏感状态，不能进入仓库或构建产物。

package/docs/execution-plan.md

@@ -1,14 +0,0 @@
-# 维护路线图
-
-本页记录新版仍需验证和实现的工作。当前命令见 [README](../README.md)。修改规则见[贡献指南](../CONTRIBUTING.md)。
-
-| 工作 | 验收条件 |
-| --- | --- |
-| 逐一验证六个渠道的测试账号 | 保存不含凭据的字段和结果摘要，区分账号权限与公开上架 |
-| 补充响应丢失核对依据 | 只在官方协议能绑定本次操作时解除未决写入 |
-| 增加新版状态备份与恢复 | 恢复后先核对远端，阻止旧备份触发重复写入 |
-| 验收 npm 包交付 | 从实际 tarball 安装，核对文件清单和版本 |
-
-首次上架、定时发布、旧版 Go 状态迁移和 npm 注册表发布不在当前实现范围内。新增范围时，先写明操作者的步骤和验收条件。
-
-0.1.x 公开测试版的历史检查见[归档记录](archive/public-beta-acceptance.md)。归档描述旧版 Go 实现，不能作为新版账号验证结果。

package/docs/mac-cli-delivery.md

@@ -1,36 +0,0 @@
-# 维护者：npm 构建与分发
-
-本页供检查 npm 包的维护者使用。包内包含编译后的 JavaScript 和离线文档。使用者需要安装 [`.node-version`](../.node-version) 指定的 Node.js；npm 包不包含 Node.js、Android SDK 或 JDK。
-
-## 构建并验收
-
-在仓库根目录安装固定依赖，并运行完整检查：
-
-```sh
-npm ci --ignore-scripts
-PUBLISHER_REQUIRE_ANDROID_TESTS=1 npm run check
-npm pack --dry-run --json
-```
-
-最后一条命令列出实际包文件。应看到 `build/`、文档、许可证和 `package.json`。检查列表里没有凭据、APK、状态库、测试私钥或本机路径。npm 包不会运行安装脚本。
-
-需要离线交付时，可以生成 tarball 并保存摘要。下面以 `0.2.0` 为例：
-
-```sh
-mkdir -p dist
-npm pack --pack-destination dist
-cd dist
-shasum -a 256 android-publisher-cli-0.2.0.tgz \
-  > android-publisher-cli-0.2.0.tgz.sha256
-shasum -a 256 -c android-publisher-cli-0.2.0.tgz.sha256
-```
-
-核对输出为 `OK`。安装实际 tarball，再运行 `android-release version --json` 和 `android-release doctor`。CI 也会在独立前缀安装已检查的 tarball，确认命令可运行。
-
-## 分发边界
-
-tarball 没有原生可执行文件，因此旧版 macOS `codesign`、公证和安装脚本不再适用。包内包含 MIT 许可证和[第三方声明](../THIRD_PARTY_NOTICES.md)。Node.js 与 Android 工具由使用者分别安装，并遵守各自许可。
-
-首次预览版由维护者手工发布，用于占用 npm 包名并配置 Trusted Publisher。后续版本由 [publish-npm.yml](../.github/workflows/publish-npm.yml) 发布。工作流安装固定依赖、运行完整检查、打包、独立安装并核对 `android-release`，最后发布同一份 tarball。预发布版本使用 `next` 标签；正式版本使用 `latest`。真实渠道凭据和 APK 不能进入 npm 包、CI 或 GitHub 发布附件。
-
-同一版本号只能发布一次。内容改变时，先更新版本号与 `package-lock.json`，再生成新包。版本 PR、标签和 npm 发布的顺序见[版本发布](release-process.md)。

package/docs/release-process.md

@@ -1,51 +0,0 @@
-# 维护者：版本发布
-
-本流程将 CLI 发布到 npm 注册表，不会向 Android 商店提交应用。构建与检查命令见[构建与分发](mac-cli-delivery.md)。
-
-## 首次占用包名
-
-npm 要求包先存在于注册表，才能配置 Trusted Publisher。本仓库当前版本是 `0.2.0-dev`。首次合并发布工作流后，由拥有 npm 包名的维护者手工发布这个预览版。
-
-先确认 `main` 顶端提交的 CI `check` 已通过，再在同一提交运行：
-
-```sh
-git switch main
-git pull --ff-only origin main
-npm ci --ignore-scripts
-PUBLISHER_REQUIRE_ANDROID_TESTS=1 npm run check
-npm pack --dry-run --json
-mkdir -p dist
-npm pack --pack-destination dist
-npm login
-npm publish ./dist/android-publisher-cli-0.2.0-dev.tgz --access public --tag next
-```
-
-`npm login` 和首次发布由维护者在终端完成，按 npm 提示进行双重验证。发布前核对文件清单、包名和版本。发布后运行 `npm view android-publisher-cli@0.2.0-dev version` 核对注册表。这个版本公开后不能覆盖，也无需为它创建 GitHub Release。
-
-若包名已被他人占用，先修改包名和工作流，再发布。
-
-包存在后，在 npm 的包设置中配置 Trusted Publisher。填写 GitHub 用户 `wangyiliangnet`、仓库 `android-publisher-cli` 和工作流文件名 `publish-npm.yml`，并允许 `npm publish`。工作流使用 OIDC 短期凭据，不需要 `NPM_TOKEN`。
-
-新建 Trusted Publisher 后，应在 2 天内完成一次工作流发布；过期后需删除并重建配置。GitHub 仓库的 Actions 设置还须允许工作流创建 PR。版本工作流需要 `contents: write` 和 `pull-requests: write` 权限。
-
-## 准备版本
-
-在 GitHub Actions 的 [Prepare npm release](../.github/workflows/prepare-npm-release.yml) 页面，从 `main` 运行工作流。输入更高的 SemVer（不带 `v`）和一行公开更新说明。当前 `0.2.0-dev` 的下一个正式版本可填 `0.2.0`。
-
-工作流会更新 `package.json`、`package-lock.json` 和 [CHANGELOG.md](../CHANGELOG.md)，并创建版本 PR。不能重复使用已有版本号。
-
-审阅 PR 中的版本号和更新记录。按实际变化补充状态兼容性、已知限制和安装要求。等待 PR 的必需 CI `check` 通过后再合并。
-
-由 `GITHUB_TOKEN` 创建的 PR 可能需要维护者在 GitHub 上批准工作流运行。
-
-## 发布到 npm
-
-版本 PR 合并后，确认 `main` 顶端提交的 CI `check` 通过。在 GitHub Releases 中建立 `vVERSION`，目标选当前 `main` 顶端提交。说明中列出 Node.js 要求、状态兼容性和六个渠道的真实账号验证情况。
-
-预发布版本（如 `0.2.0-rc.1`）须勾选“Set as a pre-release”；正式版本不要勾选。发布 GitHub Release 后，[publish-npm.yml](../.github/workflows/publish-npm.yml) 会核对标签、包版本、锁文件和 `main` 提交。核对通过后，工作流运行完整检查，并发布已检查的 tarball。若 `main` 已前进，先评估新增改动并使用新版本号。
-
-工作流成功后，在 npm 上核对 `android-publisher-cli@VERSION` 和对应标签。安装该版本，运行 `android-release version --json`，检查包内文档。
-
-发布失败时先看 Actions 日志和 npm 中是否已有同版本。npm 已接受的版本不能覆盖，修复内容须使用新版本号。
-
-PR 和 npm 发布检查只说明对应代码与包通过测试，不代表真实商店账号已验证，也不授权应用提审。