jianf/HomeAgent
1
0
Fork 0
mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-11-01 14:57:38 +00:00
Code Issues Packages Projects Releases Wiki Activity
936 Commits 5 Branches 29 Tags
c963d8466f2ab2c7de3ad51aae4e5eff5bcc57d0
Commit Graph

14 Commits

Author SHA1 Message Date
JianFeeeee
f256098c9f refactor: 全面改名为 HologramAgent + 提示词技术内容下沉到 skill/工具描述 + 修 21 处乱码 
## ① 全面改名 HomeAgent → HologramAgent

仓库已改名，但代码与文档里仍有大量旧名。本次按"用户能看到的优先"全量替换：

- 用户可见：登录页标题/页脚、默认人格第一句、CLI 状态输出、启动日志、
  plugin_install 的工具描述、AI 图片插件的 User-Agent
- 文档与脚本：README、assets/docs、docs/zh、deploy/*.sh、.github/workflows
- 鸿蒙工程：cmd/ohos/HomeAgent → cmd/ohos/HologramAgent（git mv）
  目录内的 module/app 描述同步；**证书路径原样保留**
  （default_HomeAgent_xxx.cer/p7b/p12 是签名材料的实际文件名，改了会找不到证书）
- 插件元数据：plugin.json 的 author

★ 必须保持原样的两处（改了会坏）：
  · legacySeededPromptSignature = "你是 HomeAgent 的看板娘「小宅」…"
    —— 那是识别历史播种人格卡的**原文锚点**，改了就识别不出旧数据
  · 公开 SDK 的 ProxyAuthHomeAgent = "homeagent"
    —— 那是 SDK 契约里的值，属独立仓库，本仓不改

## ② 修 21 处乱码（U+FFFD）

这些是历史编辑留下的编码破坏，全在注释里，例如：
  「赌注重下���遍」→「赌注重下一遍」
  「「不��滤」」  →「「不过滤」」
  「**待��退场**」→「**待退场**」

★ 保留 providers/chineseclip/tokenizer.go 里的 2 处：那是**故意**用
  U+FFFD 演示"非法 UTF-8 字节被归一成 U+FFFD"，不是乱码。

## ③ 提示词技术内容下沉（用户：技术性内容应该收敛到 skill 与 -help 中）

实测系统提示词 2309 字，其中两段几乎全是**模型无法据以行动的实现细节**：

  【工具执行顺序】1272 字（ParallelSafe 声明、批内降级、batchRunnable 判据…）
  【三层记忆】   1069 字（L1/L2/L3 编号、消费式删除、向量空间、指纹…）

收敛后 **2309 → 1723 字（-25%）**，保留的全是"模型据此做什么不同的事"：

  工具顺序：默认并行 / 不要依赖先后 / 同通道保序 / 写类工具可能串行
  三层记忆：时序里能看最近 / doc_query 把历史事件按原始时间戳插回时序 /
           关系用 memory_recall / 成文知识用 knowledge_search

判断口径写进判据：新加一段提示词前先问"模型会据此做什么不同的事"，
答不上来就该进 skill 或工具描述。

## 判据

prompt_memory_test.go 新增 2 条：
- TestSystemPromptHasNoImplementationJargon
  黑名单：ParallelSafe / batchRunnable / 消费式 / DenseCosine / fingerprint /
  向量空间 / 批内降级 / 自激
- TestSystemPromptStaysCompact：上限 2000 字（当前 1723）

变异：把 "ParallelSafe 声明、批内降级" 加回工具顺序段 ⇒ 第一条立刻红。

## 验证

- go build ./... / go vet ./... 干净
- go test ./... -count=1：58 包 0 失败
- make check-client-versions：客户端与内核版本一致
 2026-10-22 20:49:44 +08:00
xiao-zhai
75b4c50fa2 Merge main into refactor/rename-batch6-site-docs：吸收前置检查重试脚本，GC_REPO 收为 job 级单一定义点 
PR #19 合入后 main 上 ci.yml / release.yml 的前置检查换成了公共脚本
.github/scripts/check-gitcode-repo.sh，与本批「GC_REPO 收为单一定义点」
改了同一段代码，故冲突。解决口径：

- 前置检查主体取 main 的重试脚本版本（不保留本批内联的那份长 case，
  重试/退避/notfound-优先于-403 的能力保留）
- GC_REPO 仍收为 job 级 env 单一定义处：main 上 ci.yml 两处、release.yml
  三处字面量（含 upload_assets 调用里那处）全部改为走 ${GC_REPO}
- 结果：每个文件内部只有 1 个定义点，注释里的实测清单同步为当前状态

零代码改动：.go/.lua/go.mod/go.sum/third_party 变更数 0。
YAML safe_load 两文件通过；check-gitcode-repo.sh bash -n 通过。
 2026-10-22 07:17:57 +08:00
JianFeeeee
777f2f810d fix(ci): gitcode 目标仓前置检查加有界重试（网络抖动不再误判） 
2026-10-21 的 main 流水线（dfc4e16）里，「前置检查 gitcode 目标仓是否存在」
首次执行时 gitcode 没有给出预期响应，一次 ls-remote 判失败 ⇒ sync job 红；
重跑立刻全绿。把一次网络抖动翻译成「镜像同步坏了」，是纯噪声。

改法：只对**网络层**失败重试，其余立即失败。
- 网络层（DNS/连接重置/TLS/超时/EOF）→ 最多 3 次，退避 5s、10s
- 仓不存在（gitcode 实测：could not be found + **403**，不是 404）
  → 立即失败，不重试。重试只会把「去建仓」拖成十几秒空等
- 凭据问题（401/403 但不带 not-found 特征）→ 立即失败，不重试
  （token 错了等 15 秒也不会变对）
- 分类顺序上 notfound 必须先于 403：gitcode 的「仓不存在」响应里
  **同时**含 could not be found 与 error: 403，先判 403 会把真问题贴上
  「凭据问题」的错误标签
- 每次尝试打一行「第 N/M 次探测失败（类别）：摘要」；重试提示打到 stderr
  （⏳ … 秒后重试），Actions 日志里一眼看得出发生过重试
- 耗尽重试时整段回放每次尝试的摘要，并明确写「判定：网络问题」
  —— 与「仓不存在」/「凭据问题」的判定措辞互不相同，可直接 grep 区分

同口径：**抽成 .github/scripts/check-gitcode-repo.sh，两个 workflow 共用同一个
文件**，而不是两边各写一份「逐字一致」的脚本 —— 后者迟早会漂。ci.yml 的
sync-gitcode-main 与 release.yml 的 sync-gitcode 各留 1 行 bash 调用。
（抽得出公共片段，故没有采用「两边逐字改」的方案。）

token 安全：GC_URL 含 token，永不 echo；所有输出先过 redact()。脱敏两道：
先按字面量遮 token（BRE 元字符先转义），再按 URL 结构遮 userinfo@。
结构式的 password 段**不能排除 `/`** —— 真实 token 可以含 `/`，第一版写成
[^@/[:space:]]* 时 `https://user:tok/en@host` 匹配不上，只剩字面量一道兜住
（判据 C6 首次就是红的）。

判据与变异（9 组正向 / 8 条变异，全部咬住）：
判据脚本与变异脚本见 commondev 台账 criteria/b7-gitcode-precheck-retry{,.mutations}.sh。
正向覆盖：重试次数上限（恰好 3 次探测）、仓不存在时 1 次即失败无重试痕迹、
首次成功无重试噪声、抖动后第 2 次成功、凭据问题不重试、token 不进日志、
默认退避真的是 5s/10s（用假 sleep 记录入参，不真等 15 秒）、
两处 workflow 都调同一脚本事 yaml 可解析 + bash -n。
变异 8/8 咬住：默认次数 3→1、退避→0、仓不存在也重试、去掉上限、
去掉重试提示、清空 notfound 特征串、去掉结构式脱敏、ci.yml 退回内联 ls-remote。

过程中修掉三处自己判据的盲区（都不是改产物去迁就判据，而是补判据）：
1. M2（退避→0/0）首次未被咬住 ⇒ 补 C7「默认退避 = 5 10」（假 sleep 记录入参）
2. M7（删结构式脱敏）首次未被咬住 ⇒ 补 C7b：userinfo 密码用**别的** secret
   且**含 `/`**。C6 用当前 token 的字面量做输入，字面量替换本身就能抹掉，
   于是结构式规则删了也照样绿；且密码不含 `/` 时兜底的裸 user@ 规则会顶上，
   同样验不出来
3. C7b 第一版断言 grep 'JianFeeeee' 会误报 —— 脚本正常输出里就有
   gitcode.com/JianFeeeee/HologramAgent（那是路径不是凭据），改为断言
   userinfo 形态（://JianFeeeee[:@]）

真实网络实测（不是只跑假 git）：
- 仓存在：目标仓可访问，rc=0
- 仓不存在：1 次探测即失败，日志含 could not be found + 403，rc=1
- 网络失败：3 次探测 + 2 次退避，总耗时 5.7s（退避调成 1s/1s），rc=1

yaml.safe_load 三个 workflow 全部可解析；bash -n 通过。

未改动（留待裁决）：deploy/scripts/upload_assets.py docstring 里
「SDK 仓传 JianFeeeee/homeagent-sdk」指 gitcode 侧、与实测一致
（gitcode: homeagent-sdk=200 / homeagentsdk=404；GitHub 相反），保持原样。
 2026-10-21 23:46:01 +08:00
JianFeeeee
ffe9bc2cff refactor(ci,docs): gitcode 镜像仓改名 HomeAgent→HologramAgent，定义点取值对齐 
gitcode 侧镜像仓已完成改名，旧名 HomeAgent 变成 301 跳转，真仓是
HologramAgent。dbb787a 里三处 GC_REPO 定义点仍取旧名（命中 301），本批只
改取值与说明，**不改变 dbb787a 已建立的「每个文件恰一个定义点」结构**，
不引入任何新字面量。

实测（2026-10-21 20:1x，直连不带代理，非推测）：
  $ curl -s -o /dev/null -w '%{http_code}' https://gitcode.com/JianFeeeee/<repo>

  HologramAgent     → 200  ← 当前取值
  HomeAgent         → 301  ← 旧名，跳转到 HologramAgent
  homeagent-sdk     → 200（SDK 仓，另一对象）
  hologramagentsdk  → 200（SDK 仓，另一对象）
  homeagentsdk      → 404
  HologramAgent-sdk → 404

「301 不是另一个仓，就是同一仓改名」的判定依据：两个地址 `git ls-remote`
得到的 refs 列表 md5 相同（同一组分支与 SHA），且 curl 页面 title 一致。

三个定义点（各文件恰好 1 处，消费点全部走变量，本次只改这三行的取值）：
1. .github/workflows/ci.yml   job sync-gitcode-main 的 env.GC_REPO
2. .github/workflows/release.yml job sync-gitcode   的 env.GC_REPO
3. deploy/scripts/upload_assets.py 的 os.environ.get("GITCODE_REPO", ...) 默认值
消费点未动：ci.yml 2 处、release.yml 4 处命令行，仍全部是 ${GC_REPO}。

注释同步改准（原来把 301 的仓写成「200 ← 当前用这个」，是错的）：
- 两个 workflow 的取值依据清单换成上面六个仓的现状，注明实测时间与 curl 命令
- 明确 HomeAgent = 301 跳转、HologramAgent = 当前取值
- 「以后再改名只改这三行」的说明保留

docs/zh/ci-cd-runbook.md 同步：
- 总览表 gitcode 镜像改为 HologramAgent（与主仓同名）
- 「当前取值」段与六仓实测表、301 判定依据
- API 侧口径也改准：/api/v5/repos/JianFeeeee/{HomeAgent,HologramAgent}
  不带 token 均 400（需鉴权，非仓不存在）；/releases/tags/v1.3.13
  两名字均 200 且响应体一致。旧文档写「HologramAgent→404 是死链」已不成立。
- §3.3 curl 验活地址、§3.4 手工上传示例的 GITCODE_REPO 同步为新值

判据（正向 14 项 + 变异 11 条，全部实跑）：
- 两个 workflow yaml.safe_load 解析通过；每个 env.GC_REPO 恰好 1 处
- 三处定义点取值完全一致（P4）；消费点计数 ci=2/release=4（P6）
- P8 改为「不带 -L 的 200」：这正是本次误判的根因——之前用 curl -L 测，
  301 跟随后也是 200，把「旧名跳转」误读成「旧名是真仓、新名 404」
- 变异 M11「三处一致改回旧名 HomeAgent」只被 P8 抓住（P4 仍绿），
  证明该判据能单独区分「一致但指向 301 旧名」
- 所有 step run 块过 bash -n（30 个 run 块，0 错）
- gitcode 作 import host 残留 0；工作区无 .go/.lua/go.mod/go.sum 变更

零代码改动：packaging_test.go 里「禁止历史模块路径」的反向断言未动，
third_party 未动，systemd 相关行未动。
 2026-10-21 20:15:41 +08:00
JianFeeeee
dbb787a658 refactor(ci,docs): gitcode 镜像仓名收为单一定义点，取值 HomeAgent（实测 200） 
gitcode 镜像目标仓名此前在 3 个文件里各写死多份字面量，改名时要遍改且极
易漏（漏一处 = 一个静默死链，而且失败面在 release 里只有一格）。本批只做
「收成单点」，不改任何取值、不碰代码。

三个定义点（每个文件恰好 1 处，消费点全部走变量）：
1. .github/workflows/ci.yml → job `sync-gitcode-main` 的 env.GC_REPO:232
   消费点 2 处命令行：git ls-remote 探测、git push main。
2. .github/workflows/release.yml → job `sync-gitcode` 的 env.GC_REPO:375
   消费点 4 处命令行：git ls-remote 探测、push tag、POST /releases、
   upload_assets.py 的 GITCODE_REPO 传入。
   （两个 workflow 是独立文件，不能共享 env，故各自一处定义。）
3. deploy/scripts/upload_assets.py → os.environ.get("GITCODE_REPO", ...) 默认值。
   手工跑脚本时的兜底，与两个 workflow 同值。

为什么取值 JianFeeeee/HomeAgent 而不是 HologramAgent：
GitHub 主仓已改名 HologramAgent，但 **gitcode 侧镜像仓没有跟着改名**。
curl 直连实测（2026-10-21）：
  https://gitcode.com/JianFeeeee/HomeAgent      → 200   ← 当前取值
  https://gitcode.com/JianFeeeee/HologramAgent  → 404
指向 HologramAgent 会让每次发版/推 main 都在镜像同步这步红掉，且国内镜像
停止更新。

两个 job 的失败面不同（容易搞混，此处写明）：
- release.yml 的 sync-gitcode：needs [prepare, publish]。探测 exit 1 ⇒
  **只红「镜像同步」这一格**；GitHub 侧 release 产物已经发出去了。
- ci.yml 的 sync-gitcode-main：needs [go, race, cross, gui, csrc, docs] 全绿
  后才跑。探测 exit 1 ⇒ **main 的整条 CI 红**（不是一格）。
所以仓名写错的真实后果是「必红一格 + 国内镜像不更新」，不是「发不出包」。

何时切回 HologramAgent：等 gitcode 上把镜像仓真正改名/新建成功、
https://gitcode.com/JianFeeeee/HologramAgent 返回 200 之后，
**只改上面这三行**即可，两个 workflow 的消费点与 runbook 均无需再动。

docs/zh/ci-cd-runbook.md 同步三节：单点化表格（定义处/消费点）、当前取值与
200/404 实测依据、两个 job 的失败面差异；并把 §3.4 的 curl 验活地址与
upload_assets 手工调用示例同步到 HomeAgent（原写法是已 404 的死链）。

判据（含变异，全部实跑）：
- 两个 workflow 可被 yaml.safe_load 解析；每个 jobs[..].env.GC_REPO 恰好 1 处
- 每个 step 的 run 块抽出来喂 bash -n，全部无语法错
- 可执行形态里的 gitcode 目标仓名不含 HologramAgent（注释行豁免）
- 变异：把任一 GC_REPO 定义改回 HologramAgent、或把某消费点还原成字面量，
  判据均报红
- 零代码改动：git status 无 .go/.lua/go.mod/go.sum；go build ./... 通过
 2026-10-21 19:55:59 +08:00
commondev
a7331251ab refactor(ci): 批4b 清理 CI/镜像链路旧仓名，并加 gitcode 目标仓前置检查 
改名 HomeAgent → HologramAgent 后，CI 里仍写死旧仓库路径，且镜像链路
一旦目标仓缺失只会得到 git 的原始报错，看不出「仓没建」。

改动：
- ci.yml: sync-gitcode-main 推 main 目标改为 JianFeeeee/HologramAgent，
  并在 push 前新增「前置检查 gitcode 目标仓是否存在」独立 step。
- release.yml: sync-gitcode 的 push / releases API / GITCODE_REPO 统一
  走 GC_REPO=JianFeeeee/HologramAgent 变量；同样新增前置检查 step。

前置检查语义：
- GITCODE_TOKEN 未配置 → 沿用既有「跳过镜像同步」（可选项，不算错误）；
- token 有但目标仓不存在 → 打印要建的仓与地址，exit 1 硬失败；
- 探测与 push 用同一 URL、同一凭据（git ls-remote），贴近真实失败面；
- 日志对 URL userinfo 做结构脱敏，避免 token 被 git 报错带出。

gitcode 报错文本按 2026-10 实测校准：目标仓不存在时返回
  remote: <CH...> The project you were looking for could not be found.
  fatal: ... The requested URL returned error: 403
是 "could not be found" + 403，不是 GitHub 那种 404 / Repository not found，
故分类同时匹配这两种形态（401/403 单列一支，提示仓未建或 token 无权限）。

未执行任何线上动作：不重命名 GitHub 仓、不建 gitcode 镜像仓、不 push/开 PR/打 tag。
 2026-10-21 18:11:59 +08:00
JianFeeeee
be5192d956 refactor(ci): release 流水线产物名同步为 hologramagent-*（批 4-a） 
批 2 已把打包产物改名为 hologramagent-*（8380fcbb），但 release.yml 仍按
homeagent-* 找包，main 处于「下次发版必挂」的中间态。本批只补 workflows。

运行时真读包（改错即发版即挂）：
- 253/256 行 dpkg-deb -c hologramagent-full_*_amd64.deb
- 259 行    dpkg-deb -c hologramagent-server_*_amd64.deb
依据 deploy/packaging/package-linux.sh:675 的 deb 产物模板
hologramagent-${variant}_${PKG_VERSION}_${DEB_ARCH}.deb（variant 见 845 行，
CI 跑 amd64 ⇒ DEB_ARCH=amd64）。

release notes 文本（须与脚本产出名逐字一致）：
- 314 行 hologramagent_${VERSION}_linux_amd64.tar.gz
  依据 714 行 hologramagent_${PKG_VERSION}_linux_${TAR_ARCH}.tar.gz，
  amd64 ⇒ TAR_ARCH=amd64（非 x86_64）
- 315/316/317 行 hologramagent-client/server/full_${VERSION}_amd64.deb
rpm 未列：CI 只上传 ./*.deb ./*.tar.gz ./SHA256SUMS，不含 rpm。

未改动：notes 首行 "HomeAgent $VERSION"（展示名，规格只点名产物名，归批 4-b）；
ci.yml 的 mirror push 路径与首行注释（平台改名/展示名，归批 4-b）。
 2026-10-21 16:22:33 +08:00
JianFeeeee
e60870c969 ci(release): gh release download 需显式 --repo（非 git 目录无法推断） 
## 症状（第三次试发布）

Build 全绿、tag 已建、release 已建、2.40GB 附件全部上传成功 ——
唯独最后一道「回读校验」失败，整个 workflow 因此标记为 failure：

    failed to run git: fatal: not a git repository (or any of the
    parent directories): .git
    ##[error]Process completed with exit code 1.

## 根因

回读校验为了"下一份干净副本"先 `cd /tmp/back`，那里不是 git 仓库。
而 `gh release download` 默认从**当前目录的 git 上下文**推断仓库与
host（GITHUB_REPOSITORY / GH_HOST 之类环境变量不足以让它跳过推断），
于是报 "not a git repository"。

## 修法

    gh release download "$TAG" --repo "$GITHUB_REPOSITORY"

两个仓的 workflow 都有同一处（主仓 + SDK），一并修。

## 顺带

`third_party/homeagent-sdk/.github/` 加入 .gitignore —— 与 skills/ 同类：
SDK 仓自己的 workflow 由 SDK 仓跟踪管理（那边已跟踪），本仓不参与
构建，不需要在这边重复一份。未加规则时它会出现在本仓的未跟踪列表里。
 2026-09-29 14:39:08 +08:00
JianFeeeee
503f5e7737 ci(release): 验证产物改用 >/dev/null 而非 grep -q —— SIGPIPE 误杀检测 
## 问题（第二次试发布实测）

打包成功后，「验证产物」步骤失败：

    tar: stdout: write error
    dpkg-deb: error: tar subprocess returned error exit status 2

而三个 deb 的元数据其实已全部正确打印（Package/Version/Architecture）。

## 根因

`dpkg-deb -c <800M 的 full 包> | grep -q <模型文件>`：

grep -q 匹配到目标行后**立即退出**、关闭管道读端 ⇒ dpkg-deb 内部的
tar 继续写 stdout 时收到 EPIPE ⇒ pipefail 判整条 pipeline 失败。

⇒ 检测项本身是好的（模型确实在包里），却被检测手段误杀。

本地用 CI 上同一个 800M full 包复现：
    grep -q 版    → dpkg-deb: error: tar subprocess was killed by
                    signal (Broken pipe)
    >/dev/null 版 → 通过

client（80M）没炸、full（800M）炸 —— 包越大越容易触发（内容越多，
grep -q 提前退出的窗口越大）。这正是它没在本地小规模测试里暴露的原因。

## 改法

检测存在性时用 `grep <pattern> >/dev/null`（读完整个输入再退出），
不用 `grep -q`。顺带补了 server 包的模型在位检测（原来只测了 full）。
 2026-09-29 14:19:29 +08:00
JianFeeeee
c55d35ca23 ci(release): 修 gitcode 同步的路径拼法（原写法必然找不到文件） 
upload_assets.py 的路径语义是 `os.path.join(ASSET_DIR, name)`，
而原写法先 `cd dist` 再传 `./*.deb` ⇒ 拼成 `dist/dist/...`，
必然 "资产目录不存在" 或逐个 skip。token 一配上就会炸，属隐患。

改为：cd 进资产目录 + `ASSET_DIR=.` + **不传文件名**（让它扫描当前目录，
.deb/.tar.gz/SHA256SUMS 都在它的产物白名单里）。

SDK 侧另有一处同类问题，但那里**必须显式列名** —— hmapdev 的产物多数
没有扩展名（只有 windows 那个是 .exe），自动扫描会静默地一个都不传。
已同步修在 SDK 仓的 workflow 里。
 2026-09-29 14:09:19 +08:00
JianFeeeee
1978fa6c97 ci(release): [skip-release-tests] 标记改查发版提交，不再查 HEAD 
原实现用 `git log -1 --pretty=%B`（即 HEAD）找标记。但发版提交之后
往往还会跟几个提交（同步 workflow、改文档、修脚本），HEAD 一移动，
标记就被顶掉 —— 跳过机制**静默失效**，流水线又回去撞旧线的红测试。

改为查**改动 internal/meta/meta.go 的那个提交**（语义上正是「发版提交」）：
  REL_COMMIT=$(git log -1 --format=%H -- internal/meta/meta.go)

顺带把 grep -qF 换成 case 匹配，避免多层引号嵌套。

自测（本地 worktree）：
  发版提交 23a98f1 → 命中标记 ✓
  HEAD      df0d4b0 → 不命中（旧逻辑会在此静默失效）

actionlint 全绿。
 2026-09-29 14:03:25 +08:00
JianFeeeee
f56c3c9324 ci(release): 打包前装 Electron，否则 GUI 被静默跳过 
## 问题

打包脚本从两处找 Electron 运行时：
  1) ~/.cache/electron 里的 electron-v<ver>-linux-<arch>.zip
  2) cmd/gui/node_modules/electron/dist（目标架构 == host 时）

全新 GitHub runner **两处都没有** —— 脚本在都没有时只能跳过 GUI，
于是 client/full 包会**静默地不含界面**（正是脚本作者担心的「假包」）。
实测：本地移走缓存后 GUI 被跳过，包仍能产出。

## 改法

打包前在 cmd/gui 执行 `npm ci`，让 electron 落到 node_modules。
runner 是 amd64 == 目标架构，脚本便走第 2 条路径。

**用 npm ci 而不是 `npm install electron@<range>`**：后者是非确定性的
（range 会随上游漂移，也锁不住传递依赖），zizmor 也把它标为
adhoc-packages 风险。package-lock.json（lockfileVersion 3）已锁定
electron，ci 严格按 lock 安装 ⇒ 同一 commit 永远得到同一套依赖。

不能用 `npm install --production`：那会跳过 devDependencies，
而 electron 正是 devDependency（这正是脚本自己那条命令找不到它的原因）。

## 验证

- 无声 cache + 有 node_modules/electron 时，脚本走 host-arch 回退并
  成功构建 GUI（263M / x86-64）—— 已本地实测
- 两者都无时改为打印明确原因并跳过（配合上一个 commit 的 find 修复）
- npm ci --dry-run 通过；actionlint 全绿
 2026-09-29 14:02:18 +08:00
JianFeeeee
7798bf3f00 ci(release): go test 门可显式跳过（默认仍严格） 
## 问题（试发布实测暴露）

把 CI/Release 带到 release/v1.3.x 后，CI 三个 job 全红，但**每个失败都是
该分支自身的旧状态，与改动无关**：

| job | 失败原因 | main 上 |
|---|---|---|
| GUI (node) | `npm error Missing script: "test"`（1.3.x 尚无该脚本）| 正常 |
| Go test | TestRealPlugin_DeepSearchKeepsSharedBackendOnStop | **通过** |
| C gates | exit 2（1.3.x 无 csrc 基础设施）| 正常 |

⇒ 给已存在的发布线补新流水线 = 用今天的门去量旧代码。硬门会让该历史
维护线**完全无法发版**，正是用户要的「推 rel 分支就出产物」被挡死。

## 改法

拆开两道门，语义不同：

- `go build ./...` —— **硬门**，不可跳过。产物不可能建立在编译失败的代码上。
- `go test ./...` —— 默认跑，但可跳过。两个来源：
  1. workflow_dispatch 的 `skip_tests` 输入
  2. **发版 commit 里写 `[skip-release-tests]`**

第二个来源是关键：决定落在**定义该次发版的那个 commit** 里，`git log` 可审计，
而不是一个随手勾的开关。跳过时输出 `::warning` 注释，让后果在 run 页可见。

## 未决（留给用户）

`release/v1.3.x` 的 deepsearch 测试失败属该线既存状态（main 已修）。是否把它
cherry-pick 回 1.3.x 属产品决策（1.3.x 是历史维护线，main 已是 1.4.0），
故本次不擅自拉回绿，只提供显式跳过通道。

actionlint 全绿。
 2026-09-29 13:40:25 +08:00
JianFeeeee
80aac5ec4d ci: 发布流水线 —— release/** 推送即发版（tag/打包/发布/镜像全自动化） 
## 设计

版本号唯一事实源是 internal/meta/meta.go 的 Version（仓库纪律），
所以发版动作 = 在 release/vX.Y.x 上把 meta.Version 改成目标版本后推送：

  prepare      读版本号；tag 已存在则整轮跳过（幂等闸门，改文档不会重发）
  build-linux  go build + go test 过门 → 下载资产 → 打包 3 deb + 1 tar.gz
               → 平铺 → 验证（deb 元数据/模型在位/校验和自验）→ artifact
  publish      打 tag → gh release create 传附件 → 回读下载验证校验和
  sync-gitcode 有 GITCODE_TOKEN 时同步 tag+附件到 gitcode（无则跳过不阻断）

## 关键事实（全部本地实测过才写进 workflow）

1. **编译不需要 ONNX Runtime**：onnxruntime_go 是 dlopen 方式（运行期才
   加载 .so），本地在清空 ORT 相关环境变量的条件下带 -tags=onnxruntime
   编译通过（83M）。CI 只需在**打包**时有 ORT（要打进 deb）。
2. **构建资产托管在 release ci-assets-v1**（已上传）：
   chinese-clip-vit-b16-onnx.tar 719MB + onnxruntime-linux-amd64-1.28.0.tar
   24MB + SHA256SUMS。模型内容不随版本变 ⇒ 一次上传反复复用，CI 打包前
   下载并 sha256sum -c 校验。上传实测 3.2MB/s，构建期下载同源更快。
3. **打包链路在干净 worktree 全程实跑通过**（release/v1.3.x + VERSION=1.3.13）：
   full 800M / server 726M / client 80M / tar.gz 841M，SHA256SUMS 平铺自验
   4/4 OK，full 包内确认含 TextEncoder/VisionEncoder.onnx 与 libonnxruntime.so。
4. **SHA256SUMS 的坑**：脚本把校验和写成平铺名（./xxx.deb），而产物在
   deb/ tar/ 子目录 ⇒ 直接 -c 会全 FAILED。workflow 里显式平铺后再验。
   （呼应 git-branching.md §七「校验和必须覆盖全部附件、只传一次」。）
5. ORT 资产补齐了缺失的 LICENSE + ThirdPartyNotices.txt（取自
   microsoft/onnxruntime v1.28.0 tag，与本地 .so 的内嵌版本号一致）——
   打包脚本的 stage_multimodal_assets 对这两文件非空校验，缺失即失败。
6. actionlint 全绿（修掉了 shellcheck SC2012：ls 改 stat 循环）。

## 已知边界

- arm64 发布产物暂缺（package-linux.sh 支持，但 CI 未配 QEMU 交叉；待需要时加 matrix）。
- Windows 安装器未纳入（需 electron-builder win 打包，单独验证后接入）。
- sync-gitcode 依赖 secret GITCODE_TOKEN（待用户配置；未配置时该 job 显式跳过）。
 2026-09-29 13:07:36 +08:00