文章里能看到一个玩法完成，不代表发布包已经验收。编译成功、签名通过、安装成功、页面可用和平台审核是不同检查。《拼棋派对》这一轮系列实操把源码、包、模拟器操作和问题记录分别保存，让每个结论都有对应范围。
本篇以主App1.0.19、API26为基线，梳理签名打包和代表玩法回归。构建记录来自2026年10月14日；系列操作在10月14---15日完成。本文没有再次构建新版本，也没有把文章发布当作App上架。
本文目录
固定本次交付的身份
基线主包为1.0.19、versionCode1000019，target26、compatible20，设备声明phone、tablet、2in1。编译SDK为26.0.0.105 Release，工具为DevEco Studio26.0.0.851。模拟器镜像版本与编译SDK版本分别记录。
外层.app用于对应分发流程，独立签名HAP用于设备安装。手表模块单独交付，手机元服务也有自己的标识和版本；不能把它们合并成"一个包支持所有设备"。
把版本、产品名、构建模式与包哈希写进记录，可以防止截图来自A包、最终上传B包，却没有说明变化。截图和日志应指明实际运行包，而不是只写"最新版"。
构建、签名和包内核验
基线使用明确的SDK、JBR、Node和Hvigor路径执行clean assembleApp。多版本IDE环境尤其需要绝对路径，避免命令来自旧编辑器。
powershell
& "$ideRoot/tools/hvigor/bin/hvigorw.bat" clean assembleApp `
-p product=multidevice -p buildMode=release --no-daemon命令中的ideRoot需要预先指向实际安装目录。证书、密钥与Profile使用本机签名配置，不应写进公开文章。遇到Java找不到，先检查JAVA_HOME与当前进程PATH，而不是替换业务代码。
构建后检查APP和HAP的ZIP完整性、包内版本、设备声明与release配置。再用官方hap-sign-tool验签。当前归档记录APP和独立HAP均通过verify-app。
外层签名APP中的内部HAP与独立签名HAP不是同一个交付对象。内部检查文件不能拿来当作设备可安装签名包；应使用已经单独签名并核验的HAP。
通过HDC验证实际操作
先列设备，再显式指定模拟器。连接列表同时有真机时，不能省略目标，让自动选择决定安装到哪里。
powershell
hdc list targets
hdc -t 127.0.0.1:5555 install -r entry-default-signed.hap
hdc -t 127.0.0.1:5555 shell aa start `
-a EntryAbility -b com.leson.pinqipartygame本系列使用HDC的uitest读取布局、点击可见控件，通过snapshot_display获取截图。操作依据当前可见文字与位置，不直接写应用私有存储来制造完成画面。
代表路径包括单人24点五题、双人24点双方计分换题、象棋移动悔棋、拼图完成、五子棋九手五连、翻牌配对、算术十题和诗词八题。各篇明确哪些是本轮实测、哪些是源码边界。
让截图和GIF对应测试
测试至少记录初始条件、动作、预期和结果。比如算术首题故意答错，后九题答对，预期A4:B5；实际结果也显示B获胜，这比只放一张结果页更能说明计分正确。
GIF用于展示操作变化，关键结果适当停留。来源和帧顺序在内部清单中保留；文章不需要加入大量制作方式解释，但也不能把离散取证说成精确反应时录屏。
离线HTML内嵌图片和GIF，发布到平台时还需把本地路径替换成平台素材地址。上传成功后再确认动图没有变成静态图、图片没有404，代码和表格没有丢失。
保留失败与待修项
本轮文章检查发现了一些产品问题，它们没有因为打包和签名成功而消失：
| 问题 | 当前证据与边界 |
|---|---|
| 五子棋悔棋删除最大索引 | 已复现，历史栈方案写在第10篇，未接入产品 |
| 跳棋允许跳回原位 | 连跳实测，缺少已访问点限制 |
| 跳棋部分状态文案刷新延后 | 点提示后更新，记录待修 |
| 双屏双人24点A工具裁切 | 状态保留，但布局可用性未通过 |
| 双人拼图完全同成绩判A胜 | 源码规则边界，公平性待改进 |
| 本地保存异常被吞掉 | 源码缺少可观察失败反馈 |
这些问题意味着不能把当前包描述为"所有页面与规则全部通过发布验收"。文章可以如实交付实践过程，产品若要重新发布，应先修复影响操作与规则正确性的缺口，构建后重新验收。
区分文章完成与App发布
系列交付包括可编辑正文、统一封面、GIF和离线预览；产品交付包括正式签名包、包内版本、验签与实际运行证据。两者相关，却没有互相替代关系。
版本号一旦改变，就需要重新构建正式签名APP、核验包内版本并交付。只改文章不应为了"更新"而随意加版本；上传AGC也需要用户明确授权和对应包验证。
这套26篇系列围绕同一工程展开，从入口、状态、规则到多端布局、存储与元服务。最有价值的结果是把用户动作和数据变化对应起来：哪里成功、哪里有问题、修改后该如何复测，都有可继续使用的记录。
源码入口：工程build-profile、AppScope、module和 tools/release_device_qa.py；基线记录位于项目release目录。本轮文章发布到CBI的地址与状态另列发布清单，不在正文预先宣称审核通过。参考HarmonyOS官方文档。