|
|
d3590192e7
|
fix(outputch): 内核不再替插件判断载荷语义 —— 空 payload 是合法占位
## 实测踩到的真 bug（生产环境）
QQ 插件重装后首次实测 `sticker_index` 用法，直接失败：
output_send__qq result: 参数有误，未发送任何内容：payload 不能为空
而插件侧明明有这个放行分支：
if payload == "" && !(rawType == "sticker" && stickerIndex > 0) {
return nil, fmt.Errorf("payload 不能为空")
}
分支永远走不到 —— 内核先拒了。
## 根因：两处内核越权判断
| 位置 | 旧判断 | 问题 |
|---|---|---|
| `parseOutputItems` | `strings.TrimSpace(p) == ""` ⇒ 拒绝 | 内核不知道 payload 语义。`type=sticker` + `meta.sticker_index` 要求 payload 留空占位，真实 URL 由插件从收藏表情取 |
| `sendOneOutput` | `stageCtx.FinalText == ""` ⇒ "输出被插件清空" | 原本就空的占位被判成异常 |
**正确边界**：参数**是否存在**归内核（没传 `payload` 键 ⇒ 拒绝，结构性错误内核能判）；参数**值是否合法**归插件（空串 ⇒ 交插件判断并返回 error）。
这与本轮 outputch 的另一条改动是同一条原则（`type` 的能力校验下放插件）：
**内核只透传与对齐，不解释插件自定义字段的含义**。
## 连带修正：`stringOrArray("")` 不再返回 nil
原来 `payload: ""` 被当成"未提供"，与"没传 payload 键"混为一谈。
现在空串**保留为一个元素**：前者是模型明确给的空占位（须走到插件），
后者才是真的没提供（由 `len(payloads) == 0` 拦下）。
## 判据调整（原有判据与正确设计冲突）
`TestOutputSend_RejectsEmptyEntries` 断言"含空条目必须整 call 拒绝" —— 那是
按旧的越权设计写的，**与正确边界冲突**。改写为三条分别钉住边界：
| 判据 | 断言 |
|---|---|
| `EmptyPayloadDeferredToPlugin` | 内核不拦空条目，交插件判断（2 条都要送到） |
| `EmptyStringIsNotMissing` | `payload: ""` 是占位而非缺失，必须走到插件且原样透传空串 |
| `MissingPayloadStillRejected` | 完全没传 payload 键仍拒绝（内核能判的结构性错误） |
变异验证（把 trim 判空加回 `parseOutputItems`）⇒ 两条同时变红：
- 「内核不该拦空条目，应交插件判断，实际只发 0 条」
- 「空字符串 payload 应交给插件（sticker_index 用法依赖它），实际 0 次调用」
## 验证
- `go test ./internal/agent/core/` 全绿（含新 3 条）
- 生产实测修复前后对照（journalctl 原文）：
21:54:35 output_send__qq result: 参数有误，未发送任何内容：payload 不能为空 ← 修复前
21:56:34 output_send__qq result: ok ← 修复后
- webui / agent-core 全绿
|
2026-10-22 22:42:02 +08:00 |
|
|
|
55dfa959aa
|
ci: 触发重跑 —— 上一轮 C infrastructure gates 因 runner 卡在 apt-get 超时（本地同门禁全通过）
|
2026-10-22 21:40:48 +08:00 |
|
|
|
b20e32d81d
|
feat(outputch): 提示词显式声明「必须调 outputch 才送达」+ 契约值改名 Agent
## ① 提示词：只有显式调用 outputch 才会送达用户（用户明确要求）
模型最常见的错误不是不会调工具，而是**以为返回文本就等于回复了** ——
在异步通道（qq/wechat/群聊）上那等于自言自语，用户永远收不到。
改动前【输出规则】开篇是「消息不会自动发送到对话来源通道，你必须自己决定
如何回复」，语气偏描述。改为开篇总述句：
**只有显式调用 `output_send__{通道名}` 才会把内容送达用户。**
返回纯文本只是在这次推理里说话，用户看不到 —— 除非是下面说的同步通道。
同时补上本次内核新增能力：payload 传数组可一次发多条。
## ② 契约值改名：ProxyAuthHomeAgent="homeagent" → ProxyAuthAgent="agent"
用户指示契约值一起改。常量名与字符串值同时改，但**保留旧值读取路径**：
ProxyAuthAgent = "agent" ← 新值
ProxyAuthAgentLegacy = "homeagent" ← 只用于兼容读取
ProxyAuthHomeAgent = ProxyAuthAgent （Deprecated 别名，存量源码可编译）
为什么必须保留：`Auth` 是**写进 plugin.json 的持久化声明值**。存量配置里
写着旧值 —— 本机实测 `/home/newqqagent/plugins/huawei_smarthome/plugin.json:19`
就是 `"auth": "homeagent"`。只认新值 ⇒ 该插件加载时被判为非法声明 ⇒
反代不生效，症状是「插件好好的但页面打不开」，且无任何报错指向改名。
### 归一化是安全关键
`EffectiveProxyAuth` 把**空串与旧值都归一化为 ProxyAuthAgent**。
判断点全都写成 `auth == ProxyAuthAgent`。若不归一化，就得每点写两遍比较
—— **漏一处就是鉴权绕过**：旧值被判为「非门户鉴权」⇒ 跳过 authorizeProxy
⇒ 请求直接透传给上游。所以兼容收在一个函数里，不散落在调用点。
### 顺带修掉两处隐患
1. `webui/proxy.go` 的裸字面量 `"homeagent"`（非法行占位）改为
`sdk.ProxyAuthAgent` —— 裸字面量在改名时会被漏掉，届时它悄悄变成
未知值，而未知值在旧代码里等于「无鉴权」。
2. 两处鉴权判断改用 `EffectiveProxyAuth(...)`，堵住旧值绕过。
## 判据
| 判据 | 覆盖 | 变异自证 |
|---|---|---|
| `TestSystemPromptRequiresExplicitOutputCall` | 总述句必须存在、必须说明「返回文本用户看不到」、同步通道是唯一例外、payload 可传数组 | 删掉总述句 ⇒ 红 |
| `TestProxyAuthLegacyValueStillAccepted` | 旧值仍被接受 + 必须归一化为新值 | 去掉归一化分支 ⇒ 「旧值应归一化为 "agent"，实际 "homeagent"」红 |
## 验证
- `go build ./...` / `go vet ./...` 干净
- webui / internal-sdk / agent-core 全绿
- SDK 仓（独立提交 acd1166）：`go build` + `go test ./...` 0 失败
|
2026-10-22 21:17:05 +08:00 |
|
|
|
f850d754c1
|
feat(outputch): 一 call 多发 + 多类型 —— 内核级通用能力（非某插件专属）
用户要求：内核 outputch 是通用基础，传入 meta/payload/type（三者均为**插件自定义
字段**）。要支持一次调用发多条、多种类型消息，通过 payload 数组 + type 数组实现。
## 内核原有形态的限制
output_send__<ch> 每次只能发一条单类型：
payload: string / type: string / meta: string
带附件或多段内容的通道只能额外注册独立 tool（如 QQ 的 qq_send_file），
而这不该是插件的职责 —— "发一条消息"本来就是输出门的语义。
## 改法
### ① 工具 schema：oneOf [string, array]
payload / type / meta 三者的 schema 改为同时接受字符串与数组。
payload 是字符串时走单条路径，**行为与改动前逐字相同**（向后兼容，用户拍板）。
### ② 解析规则（parseOutputItems）
- payload 与 type 必须等长；type 省略或单值 ⇒ 广播
- meta 允许**单值广播**（用户拍板）
- 长度不符 ⇒ **整 call 拒绝，一条都不发**
- 含空条目 ⇒ 同样整 call 拒绝（不能静默发空消息）
### ③ 能力校验下放插件（用户拍板）
删掉内核里的 `switch rawType { case text/voice/image/file: 查 caps }`：
· type 是**插件自定义枚举**，内核不认识它。写死四个值 = 内核在理解插件语义；
· 且插件的自定义类型（如 QQ 的 sticker）会被内核无端拒绝。
内核只保留两件它确实该管的校验：**授权闸**（IsOutputAllowed）与
**通道存在性**。type 与能力的匹配由插件在 handler 里判断并**返回 error**。
### ④ 部分失败：继续发剩余的，如实逐项汇报
用户要求"部分失败向 agent 返回失败项"。实现选择"继续发完"而不是"中止"：
第 2 条图片失败不该把第 3 条文字也丢掉，否则"一次发多条"失去意义。
返回形态：
全部成功（多条） 已通过 [qq] 通道发送 3 条
部分失败 已通过 [qq] 通道发送 2/3 条：
[1] text ok
[2] image 失败：<插件返回的错误原文>
[3] text ok
失败的条目请单独重发。
单条成功仍返回 "ok"（与旧版完全一致，避免富回执驱动回声效应 ——
output.go 里有实测依据）。
### ⑤ 拆出 sendOneOutput
before_output / 安全回填 / after_output 这套顺序对**每一条**都必须完整走一遍。
混在批量循环里极易漏环（例如只给第一条跑 stage），所以把单条路径独立成函数，
批量只是循环调用它。
## 判据（8 条，全部有变异自证）
| 判据 | 覆盖 |
|---|---|
| SingleValueUnchanged | 单值 payload 行为与旧版逐字相同（返回 "ok"） |
| ArraySendsInOrder | 数组按顺序发 N 条，type 一一对应 |
| MetaBroadcast | meta 单值广播给所有条 |
| LengthMismatchRejectsWholeCall | 长度不符 ⇒ 一条都不发 |
| PartialFailureReportsAndContinues | 第 2 条失败仍尝试第 3 条 + 如实列出失败项与插件错误原文 |
| KernelDoesNotInterpretType | 自定义 type "sticker" 原样透传，内核不拦 |
| RejectsEmptyEntries | 含空条目整 call 拒绝 |
| UnauthorizedStillBlocked | 授权闸不被批量绕过 |
变异全部被抓：
- 第 2 条失败即中止 → 「实际只调用 2 次」
- 恢复内核 type 能力校验 → 「内核不该对 type 做能力判断」
- meta 不广播 → 「meta 未广播到」
## 验证
- go build ./... / go vet ./... 干净
- go test ./... -count=1：58 包 0 失败
- 现有 output 相关测试（output_grant / output_rules / resident_output）全绿
## 未做（下一步）
- example 插件（qq）收回 qq_send_file / qq_send_sticker，改走 outputch
- outputch 说明迁入各插件 skill（保留 _help 机制）
- 插件侧补 type 能力自校验（校验已下放，需要它们真的做）
|
2026-10-22 21:05:17 +08:00 |
|
|
|
881f3c34df
|
Merge pull request #23 from JianFeeeee/feat/rename-and-prompt-convergence
refactor: 全面改名 HologramAgent + 提示词技术内容下沉 + 修 21 处乱码 + 回填数据完整性
|
2026-10-22 21:04:34 +08:00 |
|
|
|
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 |
|
|
|
6bea130639
|
fix(memory): 回填事件必须照常归档 —— 纠正 NoMemory 语义被错误扩大到存储层
用户指出：doc 召回部分需要回填记忆，因为 doc 召回后原文在 doc 层已经删除了。
## 我上一轮的错误（PR #22）
把「工具输出不进记忆」与「回填事件不归档」塞进了同一个 NoMemory 标记：
doc_query → Consume（L2 副本删除）→ 回填 L1（标记 NoMemory）
→ L1 裁掉它 → Prune 跳过归档（错误实现）
→ 三层都不在 ⇒ 内容永久丢失
Consume 已经把 L2 副本删掉，**L1 是唯一副本**。裁掉时不归档 = 丢数据。
这不是自激防护，这是把数据丢掉当成防护。
## 正确区分（两件事不能共用一个标记）
| 对象 | 进计算层 | 进归档 | 理由 |
|---|---|---|---|
| doc_query 的**工具返回值**（正文摘录） | ❌ | ❌ | 它是事件的摘录副本，再向量化 = 重复注入 ⇒ 自激 |
| **回填的事件本身**（原文） | ❌ | ✅ **必须** | L2 副本已删，L1 是唯一副本；不归档即丢失 |
## 修法
ContextEvent.NoMemory 语义定为「**不参与计算，照常归档**」，
与 ToolDef.NoMemory 一致：只影响计算层，不影响存储层。
自激的入口在"重新计算向量"那一侧（textForVector 返回空），
不在"归档"这一侧 —— 删掉 Prune 里的跳过逻辑。
## 判据（改写了那条断言错误行为的判据）
TestSelfExcite_RestoredEventsNotReArchived 现在断言三件事：
1. 回填事件带 NoMemory 标记且未被向量化（不参与计算）
2. 前提成立：L2 里确实已无该事件（Consume 删掉了）
3. ★ 被裁掉后必须能落回 L2（否则内容永久丢失）
变异验证：
- Prune 重新跳过 NoMemory ⇒ 红，报「三层都不在，内容永久丢失」
- restoreDocEvents 不置 NoMemory ⇒ 红（会重复加权）
## 验证
- go build ./... / go vet ./... 干净
- go test ./... -count=1：58 包 0 失败
|
2026-10-22 20:37:34 +08:00 |
|
|
|
41921c0b6d
|
Merge pull request #22 from JianFeeeee/fix/doc-query-self-excitation
fix(memory): 掐断 doc_query 的自激震荡 —— 工具输出与回填事件都不进记忆
|
2026-10-22 20:30:51 +08:00 |
|
|
|
71e2b83a76
|
fix(memory): 掐断 doc_query 的自激震荡 —— 工具输出与回填事件都不进记忆
用户指出（2026-10-22）：doc_query 的结果走 NoMemory 路径，否则会对记忆块
产生自激震荡。核实后确认**两个入口都开着**。
## 回路
doc_query
├─ ① 工具返回值含被召回事件的正文片段 → 作为 ToolResults 进 context
│ → 参与向量化/关键词/蒸馏 → 同一内容被**重新注入**记忆
├─ ② 回填事件本身（带原 Source、完整 Blocks）进 L1
│ → Prune 因相关而保留它们（挤掉真正的新事件）
│ → 下一轮 Prune 又把它们归档回 L2
└─ ⇒ 下次 doc_query 再召回同一批：块在 L1↔L2 之间反复搬迁
## ① 工具输出：doc_query 未声明 NoMemory
基础设施早就有（textForVector 里按 ToolDef.NoMemory 跳过工具输出），
但 doc_query 是**内置工具**，它的声明无处安放：
StageHost.ToolDef 只覆盖插件工具，内置工具由 executeToolCallInner 的
switch 分派，不经过注册。
修法：
- internal/sdk/tool.go：BuiltinToolDef 加 NoMemory 字段（与 ToolDef.NoMemory
同义，两条路必须能声明同一件事）
- internal/agent/core/tooldefs.go：declareNoMemoryTool + noMemoryOf，
由 init() 里**显式名单**登记 doc_query
- internal/agent/core/context.go：textForVector 同时查插件 ToolDef 与
内置声明表（原来只查前者）
★ 为什么在 init 显式登记、不靠 toolDefWith 构造时登记：
工具表是按需构造的（受 `if a.docStore != nil` 之类条件控制），
而 textForVector 可能在构造之前被调用 ⇒ 声明会"时有时无"。
实测踩到：构造前查 noMemoryOf("doc_query") 得到 false。
★ declareParallelTool 顺带改为**按字段合并**（原来整体覆盖）：
同一工具可能同时声明 parallel 与 noMemory，覆盖会让后登记的那项
静默丢失 —— 声明丢一个是最难察觉的一类问题。
## ② 回填事件：加 ContextEvent.NoMemory
ContextEvent 新增 NoMemory 字段（此前只有 ToolDef/ChannelDef 有）。
restoreDocEvents 回填时置位（含存量降级路径），于是：
- textForVector 直接返回 "" ⇒ 不向量化、不参与关键词/蒸馏
- PruneWithProtected 归档前过滤掉它们 ⇒ 不再产生新的 L2 副本
语义与 ToolDef.NoMemory 一致：**原文仍在上下文可读**，只是不进计算、
不再产生新记忆。这是「回填是为了让模型读到原文」的本意。
## 判据（3 条，钉住两个入口 + 一个后果）
selfexcite_test.go：
- DocQueryDeclaresNoMemory：声明可查 + 工具输出不进 textForVector
- RestoredEventsNotReArchived：回填事件带 NoMemory 标记 + Prune 后
L2 里不出现含回填内容的新文档（真跑 Prune 验证回路）
- RestoredEventsDontCrowdOutNewOnes：回填事件不被向量化（否则会
参与相关性打分、挤掉新事件）
变异全部被抓住：
- Prune 不过滤 NoMemory → 「回填事件被 Prune 又归档回了 L2」
- restoreDocEvents 不置 NoMemory → 「没有 NoMemory 标记」+ 回路成立
- init 不登记 doc_query → 「未声明 NoMemory」
## 验证
- go build ./... / go vet ./... 干净
- go test ./... -count=1：58 包 0 失败
- 公开 SDK（third_party/homeagent-sdk）未改动 —— 改的是 internal/sdk
|
2026-10-22 20:16:57 +08:00 |
|
|
|
9c668ceeb1
|
Merge pull request #21 from JianFeeeee/feature/memory-usability
feat(memory): doc 层去掉 jieba 摘要 + doc_query 返回真实内容 + 三层记忆提示词
|
2026-10-22 19:51:54 +08:00 |
|
|
|
e2cb6e70e0
|
feat(memory): doc 层去掉 jieba 摘要 + doc_query 返回真实内容 + 三层记忆提示词
上一轮（memory-blockflow-repair-plan）修好了 L1↔L2 结构，但功能不可用。
用生产数据实测：三个互不相关查询分数全挤在 0.75~0.79，区分度≈0，
命中内容与查询无关。本次修四层。
## ① 向量输入：Summary + Content → 事件正文
denseFor 原用 `VectorizeDense(doc.Summary + " " + doc.Content)`，而 Summary
由 summarizeEntries → memory.ExtractKeywords → TokenizeContentWords → jieba.Tag()
生成。同一来源的摘要逐字同质：
来自 1 个来源的 1 条对话 (src0) 涉及: 用户, 提问
来自 1 个来源的 1 条对话 (src1) 涉及: 用户, 提问
真实 chineseclip 实测（4 篇主题完全不同的短正文）：两两余弦 0.85~0.95。
这与设计矛盾 —— ARCHITECTURE 写的是「统一多模态空间（主）」，而 Summary
是主路径的输入，却由最末一级的词法分词产出。
改为 documentTextForVector(doc)：按事件顺序拼原文（块里的正文）。
存量无 Events 的文档退回 Content。
★ 媒体不单独生成摘要：媒体块与文本块在同一事件内
（Doc.Events[i].Blocks），事件正文进入向量即覆盖其语义。
为媒体单独写描述正是 CAS 时代「描述式索引」的错误，v1.2.0 已拆除。
「按图搜图」是视觉路（RecallBlocks）的职责，已有独立通路。
## ② doc 层移除 jieba 语义生成
- summarizeEntries：jieba 词袋 → 取首条事件正文首行（真实内容，可读）
- 删除 extractTags / extractEntities（纯 jieba 词袋）
- 删除 Doc.Tags / Doc.Entities（前者唯一消费点是 doc_query 返回的
「标签: map, content」噪声行；后者零消费点）
- doc_commit 删除 tags 参数（无处可存，留着会骗模型）
★ TF-IDF 回退路径**保留**（Store.tfidfEmb/tfidfIdx/ensureTFIDF/Reindex）：
它是「稠密空间没加载」时的兜底，按 ARCHITECTURE「统一多模态空间（主）
→ 词嵌入 → TF-IDF（回退）」必须保留。但它不能是主路径 —— 一旦稠密空间
可用，jieba 就不参与。
## ③ doc_query 返回真实内容
旧返回：「已加载 3 篇文档记忆: #1(来自 1 个来源的 1 条对话 (agent) 涉及: ok)」
——全 jieba 词袋，模型无法判断有没有用（这是它几乎不调用 doc_query 的直接原因）。
新返回：
已召回 3 篇历史记忆，原文已按各自**原始时间戳**插回对话时序（不是当前对话）：
[1] 2026-06-07 08:09 · webui · 2 条事件 · 含 1 份媒体
配色方案怎么定？
结论：紫蓝红三色带按六比三比一…
共回填 N 条事件。要引用其中的细节，直接看对话时序里对应时间点即可。
每条给出「时间 · 来源 · 事件数 · 媒体数」+ 真实正文前几行。
## ④ 提示词：agent 终于能理解三层记忆
- doc_query 描述：一句话 → 覆盖「L2 是什么 / 何时用 / 调用后原文回填到时序 /
与 memory_recall 分工 / 消费式副作用」
- doc_commit 描述：说清「适合写整段过程结论，不适合写单个事实」
- 系统提示词新增【三层记忆】段（内核运行时块）：L1 对话时序 / L2 历史记忆 /
L3 图记忆各自是什么、怎么取、如何选择
- 预填充文案（crossModalMarkdown）：统计描述 → 时间+来源+正文开头，
并在块尾明确引导「要完整原文用 doc_query」
## ⑤ 向量算法版本（否则修复对存量无效）
实测踩到的坑：改完 denseFor 后，1055 篇存量文档分数纹丝不动（0.78/0.79/0.76，
区分度 0.003）—— 因为 DenseFP 只记「哪个向量空间」，不记「用什么文本算的」，
指纹不变 ⇒ 全部命中跳过条件 ⇒ 永不重算。
修法：DenseFP = 空间指纹 + "|" + docVectorAlgoVersion(v2)。
算法一变，存量自动重算一次。
## 判据（每条都有变异自证）
document/retrieval_quality_test.go（6 条）：
- Top1HitsCorrectDoc / DistinctQueriesHitDistinctDocs / ScoreGapIsSignificant
- VectorInputIsBodyNotSummary（正文哨兵必须进向量）
- SummaryNoiseMustNotPolluteVector（主题不同的短正文，两两余弦 <0.80）
- AlgoVersionChangeForcesRecompute（换算法必须触发存量重算）
core/recalldoc_test.go（+2）：返回值必须含时间/来源/真实正文/时序说明
core/prompt_memory_test.go（5 条）：工具描述五项覆盖、doc_commit 范围、
三层记忆段落、tags 参数已删、预填充文案含内容与 doc_query 引导
变异全部被抓住（截断落库 / Summary+Content / 去掉算法版本 / 旧预填充文案 /
一句话工具描述 / 删三层记忆段）。
## 验证
- go build ./... 通过；go vet ./... 干净
- go test ./... -count=1：58 包 0 失败
- go test -race ./internal/memory/document/ ./internal/agent/core/：通过
- 真实数据（chineseclip 512 维）：
· 旧格式存量（1055 篇，无 Events）：4/5 → 仍是旧分数，等自然冲刷
· 新格式文档（走 ContextToDoc）：4/5 top1 命中正确，
区分度最高 0.18（旧实现 0.003）
|
2026-10-22 19:49:25 +08:00 |
|
|
|
b1f02a22b6
|
fix(memory): 向量输入改用事件正文 —— 摘要是 jieba 词袋，把全库拉成同一方向
## 实测缺陷（真实 chineseclip，4 篇主题完全不同的短正文）
[1][3] 0.9478 [2][3] 0.9427
[1][2] 0.9316 [0][3] 0.8614
两两余弦 0.85~0.95，几乎同向。查询分数 0.70~0.78 挤在一起，区分度 0.08。
根因：denseFor 用 `doc.Summary + " " + doc.Content`，而 Summary 由
summarizeEntries → memory.ExtractKeywords → TokenizeContentWords → jieba.Tag()
生成，同一来源的摘要**逐字同质**：
来自 1 个来源的 1 条对话 (src0) 涉及: 用户, 提问
来自 1 个来源的 1 条对话 (src1) 涉及: 用户, 提问
这与设计直接矛盾：ARCHITECTURE L131/L174 写的向量层级是
「统一多模态空间（主）→ StaticEmbedder → TF-IDF（回退）」，
而 Summary 是**主路径的输入**，却由**最末一级的词法分词**产出。
## 修法
denseFor 改用 documentTextForVector(doc)：按事件顺序拼原文（来自块里的正文）。
存量无 Events 的文档退回 Content（渲染视图，但比 Summary 更接近内容）。
★ 绝不含 Summary —— 它是词袋，会把全库拉向同一方向。
## 媒体为什么不单独生成摘要
媒体块与文本块**在同一事件内**（Doc.Events[i].Blocks），事件正文进入向量
即覆盖其语义。为媒体单独生成描述正是 CAS 时代「描述式索引」的错误
（描述是二手信息），v1.2.0 已整体拆除，不重走。
「按图搜图」是视觉路（RecallBlocks 读块自己的向量）的职责，已有独立通路。
## 判据
- TestRetrieval_SummaryNoiseMustNotPolluteVector：主题不同的短正文文档，
两两余弦必须 <0.80。修复前 0.82~0.86。
- TestRetrieval_VectorInputIsBodyNotSummary：正文里的唯一哨兵必须能检索到。
变异：denseFor 改回 Summary+Content ⇒ 前者立刻红（实测 0.8225~0.8573）。
|
2026-10-22 19:33:50 +08:00 |
|
|
|
1dcd3ced03
|
test(memory): 先写检索质量判据 —— 当前红，量化「检索不可用」
上一轮（memory-blockflow-repair-plan）写了 16 条结构判据、6 个变异全绿，
然后用生产数据实测发现检索**完全不可用**：
查询 "doc 层召回是怎么设计的" → 0.7834 内容无关
查询 "hmap 插件安装验签" → 0.7922 内容无关
查询 "QQ 头像" → 0.7601 内容无关
三个互不相关的查询分数全挤在 0.75~0.79，区分度≈0。
★ 教训：结构判据不能替代质量判据。
「字段非空」「条数正确」「不 panic」在检索完全失效时依然全绿。
## 本文件
5 条判据，其中 2 条当前**红**（这就是要修的缺陷）：
- Top1HitsCorrectDoc / DistinctQueriesHitDistinctDocs / ScoreGapIsSignificant
→ 用 fakeDenseSpace（按主题词投影），验证排序与区分度骨架
- **VectorInputIsBodyNotSummary**（红）→ 正文哨兵必须进向量
- **SummaryNoiseMustNotPolluteVector**（红）→ 主题不同的文档不得接近同向
## 第 5 条的实测依据（真实 chineseclip，4 篇短正文）
[1][3] 0.9478 [2][3] 0.9427
[1][2] 0.9316 [0][3] 0.8614
四篇主题完全不同的文档，两两余弦 0.85~0.95 —— 几乎同向。
根因：denseFor 用 doc.Summary + doc.Content，而 Summary 由 jieba 词袋生成，
同一来源的摘要逐字同质：
来自 1 个来源的 1 条对话 (src0) 涉及: 用户, 提问
来自 1 个来源的 1 条对话 (src1) 涉及: 用户, 提问
判据用 bigramSpace（字符 bigram 归一化直方图）模拟该行为，
不依赖模型文件，CI 可跑；阈值 0.80，实测缺陷态 0.82~0.86。
★ 正文必须**短**：正文越长 Summary 噪声占比越小、缺陷越隐蔽 ——
这正是生产上只有短文档受害的原因。
|
2026-10-22 19:32:59 +08:00 |
|
|
|
37bece97cb
|
fix(packaging): tar 包漏拷 depgraph.bin —— 装完 homed 一启动就死
内核启动时比对「磁盘上的启动依赖图 digest」与「二进制内嵌 digest」，
用于拦住「图文件完好但描述的是旧代码」这类静默顺序错（Makefile build 段注释）。
build_tar 只拷了二进制，没拷 $BUILD_DIR/depgraph.bin ⇒ 装 tar 包的机器
homed 读不到图，直接拒绝启动（退出码 1）。
修法：与 homed 同目录拷 depgraph.bin（/usr/bin/depgraph.bin）；
缺图时**显式报错并 return 1**，而不是打出一个注定起不来的包 ——
静默产出坏包比打包失败更难查。
|
2026-10-22 19:30:05 +08:00 |
|
|
|
47c95efb80
|
feat(memory): L2 与 L1 同构 —— 事件列表承载原文，正文内联在块里
块化重构（memory-restructure-plan）换了底层数据结构，但 L1↔L2 的流动没跟着改，
导致这条链出现结构性失效。本次按设计原文修复。
## 断点（生产实测）
**① L2 只存渲染视图，事件本体丢失**
ContextToDoc 把每条事件拍平成一行：truncate(Response,100)、truncate(工具输出,200)。
生产库 1000 篇归档文档实测：
- response 段恰好 103 字符（=100+"..."）：311/2094 = 15.1%
- 工具输出段恰好 203 字符：7593/13261
- ToolsUsed 完全不存
⇒ 原文在落库那一刻就不存在了，召回再全也拿不回来。
**② L2 里没有文本块，与 L1 不同构**
L2 块分布 image 437 / audio 7 / text 0 —— 文本全靠 Content 这个视图。
**③ 召回造合成事件，时间戳用归档时刻**
doc_query 用 d.CreatedAt 造一条 cold_storage 事件、正文取 Content 再截 2000 字、
且完全不回填 Blocks。块自带 created_at（捕获时刻），实测与 doc.created_at
差近两小时，却没人用。
**④ 块在 Consume 时两层同时消失**
Consume 从内存与磁盘同时删除文档，而块的字节只存在于那个 .json 里。
生产 L2 有 444 个块，其中 396 个不在 L3（约 248MB）—— 一旦被命中即永久丢失。
## 修法（按设计，不是按我的推断）
设计前提（写进 ARCHITECTURE 与计划文档）：
· 记忆块是唯一物理载体，层是持有关系
· L1 与 L2 结构同构，唯一区别是「是否直接投喂给模型」
· 正文（含多媒体正文）内联在块里；事件只是块的容器
· 任何一层都不压缩（视图不是记忆）
· 内核不得硬编码任何插件行为
1. Doc 增加 Events []DocEvent（与 ContextEvent 同构），成为文档主体
2. 正文各自成块：Input 一块、Response 一块（BlockText，Text 即正文）
3. restoreDocEvents 逐条按原始时间戳迁回 L1，块随事件迁回
4. Content 保留为渲染视图（contentFromEvents 生成），不再是原文载体
5. 蒸馏 docToTriples 改用 documentOriginalText：从块读原文，不再用视图
6. 删掉 ARCHITECTURE 里「过滤 agentcli/terminal 来源」——那是内核硬编码
插件名，改由插件经 NoMemory/Cleaner 声明
## 顺带修掉的真实缺陷
simpleHash 是 O(n²) 且哈希串长度正比于内容：
for _, c := range s { h += fmt.Sprintf("%x", c) }
压力测试实测 1.25MB 正文归档耗时 **270 秒**；生产实测 content_hash
是 content 的 2.2 倍（52072 字 → 114491 字）。
换成 sha256 前 16 字节：**270s → 0.52s（520 倍）**，定长 32 hex。
## 存量
按拍板不迁移，等系统自然冲刷。降级路径：无 Events 的旧文档仍按旧行为召回
（整篇渲成一条事件），不伪造成「有原始事件」。生产副本实测 1104 篇旧文档
全部正常加载。
## 判据（16 条，全部有变异自证）
document/blockflow_test.go（11 条）：正文完整性、文本块粒度、逐条保留、
视图定位、幂等、存量兼容、原文可用性、hash 线性、3 条压力
core/recalldoc_test.go（5 条）：逐条回填、原始时间戳、块迁回、
回填不截断、存量降级、批量压力
变异全部被抓：
· 落库 truncate(100) → ArchivePreservesFullText（实测 len=303/原 10215）
· Input/Response 合成一块 → InputAndResponseAreSeparateTextBlocks（实际 1）
· 召回用 d.CreatedAt → RestoresEachEventAtOriginalTimestamp（回填 1/期望 3）
· 召回不回填 Blocks → MigratesBlocksBackToContext
· 召回再截 2000 字 → TextIsNotTruncatedOnTheWayBack（2003/原 18020）
· 恢复 O(n²) hash → HashIsLinearAndFixedLength（超时 >300s）
## 验证
- go build ./... 通过
- go test ./... -count=1：58 包 0 失败
- go test -race ./internal/memory/document/ ./internal/agent/core/：通过
- 生产数据副本实际启动：1104 篇文档加载正常、0 崩溃、干净退出
- 副本 e2e：新归档 2 事件 / 4 文本块、正文 3207 字完整回读、时间戳精确
## 不改
- 公开 SDK 契约（TextEvent / DocMemoryAPI / InsertWithMedia 已等价）
- 存量文档（等自然冲刷）
- 渲染层截断常数（独立议题，避免与本次修复互相掩盖）
|
2026-10-22 11:09:13 +08:00 |
|
|
|
9faae921ba
|
Merge pull request #20 from JianFeeeee/refactor/rename-batch7-sdk-docs
docs(rename-batch7): SDK 仓名引用统一为 hologramagentsdk（module 路径按发布 tag 保留旧名）
|
2026-10-22 07:29:22 +08:00 |
|
|
|
8040586daa
|
docs(rename-batch7): SDK 仓名引用统一为 hologramagentsdk，module 路径按发布 tag 保持旧名
SDK 仓已在 GitHub 改名为 JianFeeeee/hologramagentsdk（旧名 homeagentsdk
301 跳转，仓 id 与提交未变）。本批把仓内**指向该仓的引用**跟上：
- 仓库链接 / 克隆地址 / 示例目录链接：homeagentsdk → hologramagentsdk
（README zh+en、PLUGIN_DEV zh+en、OVERVIEW zh+en、site/index.html）
- package-linux.sh 的 fallback clone URL 同步新名（仅 URL 与注释）
- ci-cd-runbook：仓库表与 secret 配置命令用当前名，并注明历史改名点
**刻意保留旧名的三处**，都是事实而非遗漏：
1. Go import / go.mod replace 与文档里的 import 示例——已发布 tag
（v1.3.0 及更早）的 go.mod 仍是 module github.com/JianFeeeee/homeagentsdk，
改了直接编译不过。PLUGIN_DEV 里加了显式注记说明这条边界。
2. gitcode 的 homeagentsdk → 404 实测行（那是实测事实表）
3. runbook 里「配置时还叫 homeagentsdk」的历史说明
实测（2026-10-22）：github.com/JianFeeeee/hologramagentsdk 的 /tree/v1.1.0、
/tree/v1.3.0、/blob/main/LICENSE 均 200；example/* 为 301→tree 200
（GitHub 对目录自动从 blob 跳 tree，非死链）；ls-remote 取到
refs/tags/v1.1.0 = 49f9957。
零代码改动：.go/.lua/go.mod/go.sum/third_party 变更数 0。
|
2026-10-22 07:25:53 +08:00 |
|
|
|
f408448c37
|
Merge pull request #18 from JianFeeeee/refactor/rename-batch6-site-docs
refactor(rename-batch6): 文档/静态站旧仓名清理 + gitcode 镜像仓名对齐 HologramAgent
|
2026-10-22 07:20:29 +08:00 |
|
|
|
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 |
|
|
|
f65408dadb
|
Merge pull request #19 from JianFeeeee/fix/gitcode-precheck-retry
fix(ci): gitcode 目标仓前置检查加有界重试，区分网络抖动与仓不存在
|
2026-10-22 07:16:00 +08:00 |
|
|
|
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 |
|
|
|
a3ab6e5cfa
|
docs(deploy): SDK 镜像仓示例统一为 hologramagentsdk
upload_assets.py docstring 与 docs/git-branching.md 的上传示例里，SDK 仓
仍写 homeagent-sdk；按已定口径（SDK 仓名 hologramagentsdk，gitcode/GitHub
两侧均 200 实测）统一，避免与 sdk-docs 线合并后出现两种说法。
纯注释/文档改动，零代码逻辑变更。
|
2026-10-21 20:18:30 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
aafd971b7a
|
fix(docs): PLUGIN_DEV 与 SKILL 的 module 路径 host 改为 github
|
2026-10-21 19:42:28 +08:00 |
|
|
|
ee2b7d7bac
|
fix(docs,site): 回退上一批错误口径 —— SDK 仓名与站点域名改回实际活链
上一批（37b8c26 / 228fae2）把文档与站点里的 SDK 仓名统一改成了
`JianFeeeee/HologramAgent-sdk`、把站点域名改成了 `*.hologramagent.jianfgit.xyz`，
前提「本机无外网、无法验证」是错的。实测外网通畅，两处改动都是真实死链，本批全部回退。
## 一、SDK 仓名 HologramAgent-sdk → homeagentsdk（104 处）
| 文件 | 处数 |
|---|---|
| site/index.html | 23 |
| README.md | 7 |
| README_EN.md | 7 |
| assets/docs/zh/PLUGIN_DEV.md | 29 |
| assets/docs/en/PLUGIN_DEV.md | 29 |
| assets/docs/zh/OVERVIEW.md | 2 |
| assets/docs/en/OVERVIEW.md | 2 |
| docs/git-branching.md | 2 |
| docs/zh/ci-cd-runbook.md | 3 |
| **合计** | **104** |
含 `.git` 形态与 `cd homeagentsdk` 目录名。PLUGIN_DEV.md 里原本就是
`import "github.com/JianFeeeee/homeagentsdk/sdk"` 的两处示例（zh 253/448、en 255/455）
与 6a 前基线逐行 diff 无差异，未被改动成第三种形态。
## 二、站点域名 hologramagent.jianfgit.xyz → homeagent.jianfgit.xyz（15 处）
| 文件 | 处数 |
|---|---|
| README.md | 4 |
| README_EN.md | 4 |
| docs/zh/deploy-runbook.md | 2 |
| deploy/scripts/deploy-sdk-site.sh | 5 |
| **合计** | **15** |
deploy-sdk-site.sh 只改探活/注释里的域名，nginx 语义（SNI 透传、
server_name → root 的链路描述）未变。
## 三、明确未动
- go.mod 两行、third_party/homeagent-sdk 路径、internal/**/*.go 的 import —— 零改动
- deploy/scripts/upload_assets.py:23 默认值 `JianFeeeee/HologramAgent` 保留（主仓确已改名）
- cmd/gui/package.json homepage 保留 HologramAgent（GitHub 200）
- docs/git-branching.md:420 的 GITCODE_REPO 改为 `JianFeeeee/homeagent-sdk`：
gitcode 上只有 homeagent-sdk(200) 与 HomeAgent(200)，HologramAgent-sdk 与
HologramAgent 在 gitcode 均为 404
## 四、实测证据（curl -L -o /dev/null -m 25 -w '%{http_code}'）
GitHub 侧（经 http://127.0.0.1:7890 出口）：
200 https://github.com/JianFeeeee/homeagentsdk ← 回退目标，活链
200 https://github.com/JianFeeeee/HologramAgent ← 主仓，确已改名
404 https://github.com/JianFeeeee/HologramAgent-sdk ← 上一批写成这个，死链
404 https://github.com/JianFeeeee/homeagent-sdk ← 不是这个名字
200 https://github.com/JianFeeeee/HomeAgent ← 301 → HologramAgent
深链抽查（回退后全部 200）：
200 .../homeagentsdk/tree/main/example/weather
200 .../homeagentsdk/tree/main/example/plugindev
200 .../homeagentsdk/tree/main/example/luademo
200 .../homeagentsdk/blob/main/LICENSE
200 .../homeagentsdk/tree/v1.1.0
站点域名（直连，不走代理）：
200 https://sdk.homeagent.jianfgit.xyz/ ← 回退目标，已部署
200 https://introduce.homeagent.jianfgit.xyz/
200 https://sdk.homeagent.jianfgit.xyz/llms.txt
200 https://sdk.homeagent.jianfgit.xyz/llms-full.txt
404 https://sdk.hologramagent.jianfgit.xyz/ ← 上一批写成这个，未部署
新子域 404 的原因不是网络：证书是 CN=*.jianfgit.xyz 通配符可用，
但 nginx 里没有 hologramagent 的 server_name，站点根本没部署。
gitcode 侧（决定 §三 那行的连字符形态）：
200 https://gitcode.com/JianFeeeee/homeagent-sdk
200 https://gitcode.com/JianFeeeee/HomeAgent
404 https://gitcode.com/JianFeeeee/HologramAgent-sdk
404 https://gitcode.com/JianFeeeee/HologramAgent
## 五、验收
1. 全仓 `HologramAgent-sdk` 计数 = 0（.md/.html/.py/.sh/.yml/.yaml/.txt/.json/.go/.mod/.sum）
2. 全仓 `hologramagent.jianfgit.xyz` 计数 = 0
3. site/index.html 23 条 SDK 链接全指向 homeagentsdk，0 条指向 HologramAgent-sdk
4. curl -L 三条必测均 200（见 §四）
5. `TMPDIR=/home/newqqagent/tmpbuild6 go build ./...` 退出码 0
（/tmp 已 98% 满，用独立 TMPDIR 避开 No space left on device）
6. git status 干净；11 个改动文件全为 .md/.html/.sh，零 .go 改动
|
2026-10-21 19:36:53 +08:00 |
|
|
|
228fae252d
|
fix(docs): 回退 PLUGIN_DEV 的 SDK import 示例，并修正 upload_assets/gui homepage 的仓名
上一批 37b8c26 把文档里 4 处 Go import 示例改成了
`github.com/JianFeeeee/HologramAgent-sdk/sdk`，但该 module 路径并不存在：
主仓 go.mod:16 仍是 `github.com/JianFeeeee/homeagentsdk v0.9.2`，:46 replace
目标未变，third_party/homeagent-sdk/go.mod 首行仍是
`module github.com/JianFeeeee/homeagentsdk`，GitHub 上 HologramAgent-sdk
与 hologramagentsdk 均 404。照着文档抄这行 import 会直接 module not found，
比不改更坏。本次回退成真实可编译的 homeagentsdk。
改动：
- assets/docs/{zh,en}/PLUGIN_DEV.md 各 2 处（zh:253、448；en:255、455）
import 路径回退为 github.com/JianFeeeee/homeagentsdk/sdk。该行附近未加任何
「已改名」说明——等 SDK 仓真改名、主仓 go.mod 与第三方 module 一起改时
再统一处理，属另一批。全仓已无 HologramAgent-sdk/sdk 形态。
- deploy/scripts/upload_assets.py:8、:23 默认目标仓
JianFeeeee/HomeAgent → JianFeeeee/HologramAgent（主仓确已改名，HomeAgent
在 GitHub 上 301）。:8 括号里「SDK 仓传 JianFeeeee/homeagent-sdk」按要求保留。
- cmd/gui/package.json:5 homepage 元数据同步为 HologramAgent；该文件仅此
1 行变更，name/author/description 等其它字段未动。
保留不动（已获确认属正确形态）：
- go.mod 两行与 deploy/packaging/package-linux.sh 六处 homeagentsdk
（必须与 go.mod 逐字一致）
- internal/**/*.go 的 74 处真实依赖 import
- deploy/packaging/packaging_test.go:99,101 对 gitcode.com/JianFeeeee/HomeAgent
的反向断言（它断言 build.sh 不得使用历史路径）
- internal/plugins/webui 三处注释里的 homeagent.jianfgit.xyz（历史实测记录）
- cd HologramAgent-sdk / clone ...HologramAgent-sdk.git（操作指令目录名与 URL，
非 import 路径）
判据：7 条正向（含「文档 import 路径必须与 go.mod 的 SDK module 同源」）；
变异 4 次均按预期报红——分别还原 zh:253 import、upload_assets.py:23 默认值、
gui homepage、以及把 packaging_test.go 反向断言那两行也改名。
go build ./... 通过，go test ./deploy/packaging/ 通过。
|
2026-10-21 19:25:05 +08:00 |
|
|
|
37b8c26675
|
refactor(docs): 批6a 清理介绍站与文档的旧仓名/旧链接
改名 HomeAgent → HologramAgent 后，介绍站与仓内文档仍指向旧仓地址、旧站点
域名，点击即 404 / 落回旧站。本批只动文档与静态站，代码零改动。
映射（严格按主管给定的唯一权威口径）：
- github.com/JianFeeeee/HomeAgent → .../HologramAgent（含 /blob /releases /tree）
- github.com/JianFeeeee/homeagentsdk → .../HologramAgent-sdk
- introduce.homeagent.jianfgit.xyz → introduce.hologramagent.jianfgit.xyz
- sdk.homeagent.jianfgit.xyz → sdk.hologramagent.jianfgit.xyz
- 品牌名/链接文本 homeagent-sdk → HologramAgent-sdk（含 `cd homeagent-sdk`
克隆后的本地目录名，跟随新仓名）
改动面（12 个文件，138 行，纯替换无逻辑变更）：
- site/index.html 36 处：13 处主仓链接 + 23 处 SDK 仓链接（22 个 example/
与 LICENSE、仓库首页）
- README.md / README_EN.md 各 12 处（9 处 URL + 3 处链接文本）
- assets/docs/{zh,en}/PLUGIN_DEV.md 各 34 处、OVERVIEW.md 各 2 处
- docs/zh/ci-cd-runbook.md 9 处、docs/zh/deploy-runbook.md 2 处（站点域名）
- deploy/scripts/deploy-sdk-site.sh 5 处（注释里的 server_name + 3 处 curl
探活地址，否则改完站脚本仍在验旧域名）
- docs/git-branching.md 2 处、assets/skills/commondev-discipline/SKILL.md 1 处
（gitcode module 路径）
刻意不动（动了会坏）：
- 真实目录 third_party/homeagent-sdk（只改 URL 里的 homeagentsdk）
- go.mod 的 module / replace、所有 .go import（module 仍是
github.com/JianFeeeee/HologramAgent，SDK 仍 homeagentsdk）
- deploy/packaging/package-linux.sh 里的 `replace github.com/JianFeeeee/
homeagentsdk` 与 clone URL —— 它必须与未改动的 go.mod 逐字一致，属代码非文档
- 数据目录 ~/.homeagent、二进制 homed、产物名 hologramagent_*、
插件名 homeagent-mail-bridge
- systemd 相关行（homeagent.service / systemctl / journalctl）—— 待上级确认，
本批不动，清单见汇报
- docs/api/*.md（首行「请勿手改」，生成型）
判据（含变异验证）：
- 三条旧串 grep 全仓清零；third_party/homeagent-sdk 目录仍在
- site/index.html 标签配平（HEAD/WORK 双跑）+ section 数 13→13 未减
- 变异：分别还原 deploy-sdk-site.sh:206、site/index.html:3041、README.md:243、
ci-cd-runbook.md:11 各一处，以及删一个 </footer>，判据均按预期报红
- go build ./... 通过（仅把 TMPDIR 指到 /var/tmp 规避 /tmp tmpfs 满，仓内文件无关）
未执行任何线上动作：不 push、不开 PR、不重命名 GitHub 仓。注意 SDK 仓在
GitHub 侧目前仍叫 homeagentsdk，本批把文档指向 HologramAgent-sdk 是「改名
在路上」，该仓改名完成前这批 SDK 链接会 404。
|
2026-10-21 19:22:02 +08:00 |
|
|
|
dfc4e16e65
|
Merge pull request #16 from JianFeeeee/refactor/rename-batch4b-ci-mirror
refactor(ci): 批4b 清理 CI/镜像链路旧仓名，并加 gitcode 目标仓前置检查
|
2026-10-21 19:09:45 +08:00 |
|
|
|
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 |
|
|
|
5d7e26edf2
|
Merge pull request #15 from JianFeeeee/refactor/rename-batch5-docs-site
改名批 5-a：仓库内文档与站点改名 + 修 make install 真破损
|
2026-10-21 17:11:09 +08:00 |
|
|
|
9bc2687972
|
refactor(docs): 补正 git-branching 主仓名，接上批 5-a 改名
批 5-a 复核发现 docs/git-branching.md 两处仍以 TrueAgent 指代主仓，漏改。
只动这两行，`third_party/homeagent-sdk` 是 SDK 仓目录名，原样保留。
- 第 4 行：`本仓（TrueAgent/HomeAgent）` → `本仓（HologramAgent）`
（整段收敛成一个名字，不再留 "旧目录名/旧展示名" 的复合写法）
- 第 183 行：`### 主仓（TrueAgent）` → `### 主仓（HologramAgent）`
TrueAgent 在本仓其余 6 个文件里都是磁盘上真实存在的路径 /home/program/TrueAgent
或本机工作副本名，一行未动：deploy/systemd/embed-sidecar.service、
assets/skills/commondev-discipline/SKILL.md、docs/zh/commondev-design.md、
docs/zh/commondev-agent-runtime-design.md、internal/security/store_test.go、site/README.md。
判据口径同步收紧（判据 2）：
- 豁免只允许三类并逐条打印 —— A 仓库 URL（批 4-b）、B 本机真实路径、C 既有契约
（HOMEAGENT_*、homeagent-sdk/homeagentsdk、homeagent.service、插件名）；
~/.homeagent 单列为 D 遗留项（须与 cmd/ 侧同改）
- 原 `TrueAgent/HomeAgent` 常驻豁免已撤销（该串已不存在，留着会掩盖它复活）
- 新增 TrueAgent 守卫：git-branching 内 TrueAgent 必须 0；全仓 TrueAgent 逐行集合
必须 == base e3584bb 集合减去这两行，命中文件数 7→6
- 新增安装路径断言：/usr/lib、/usr/share/doc、/etc、/var/lib 旧值必须 0
自证：docs/git-branching.md 里 HologramAgent 3 处、TrueAgent 0 处；全仓 TrueAgent
文件数 7→6，逐行与基线 diff 仅这两行。四条判据正向全绿，13 条变异全部被咬住。
|
2026-10-21 17:07:46 +08:00 |
|
|
|
931c803421
|
refactor(docs): 核心仓文档与介绍站展示名改名为 HologramAgent
只改仓库内文件的纯展示品牌名与已随批 2 落地的安装路径；运行时契约、仓库 URL、
域名、环境变量、可执行名、插件名一律不动。
一、纯展示名（HomeAgent → HologramAgent，共 44 处 / 18 个文件）
- README.md 4、README_EN.md 4（标题、client 变体说明、Windows 安装包名、AGPL 段）
- docs/ 8 个文件 14 处（git-branching 1、ci-cd-runbook 1、commondev-design 3、
commondev-agent-runtime-design 4、deploy-runbook 1、legacy-issues 1、
prod-migration-checklist 1、triple-extract-attention 2）
- assets/docs/ 6 个文件 14 处（zh/en 的 OVERVIEW 2+2、ARCHITECTURE 2+2、
PLUGIN_DEV 3+3）
- assets/branding/mascot-xiaozhai-guide.md 2 处（身份行、标志名）
- site/index.html 6 处（title、meta description、og:title、logo alt、页头字、
插件卡片文案 "HologramAgent 接入 AgentMail"）
二、安装路径对齐批 2 产物（共 10 处）
- /usr/lib/homeagent → /usr/lib/hologram（7 处：README 2、README_EN 2、
multimodal-space 3）
- /usr/share/doc/homeagent → /usr/share/doc/hologramagent（3 处：README 1、
README_EN 1、multimodal-space 1；注意 Doc 路径带 agent 后缀）
- site/index.html 的 19 处 HomeAgent 里，13 处是 github.com/JianFeeeee/HomeAgent
仓库 URL，属红线整串保留；只改 URL 之外的展示文案（其余 13 处零改动）
三、明确不改（红线 / 一致性冲突）
- site/index.html 的 23 个 github.com/JianFeeeee/homeagentsdk 外链（21 条
example + 2 条纯仓库），SDK 仓改名属批 4-b，一个未动
- 核心仓仓库 URL、sdk./introduce.homeagent.jianfgit.xyz 域名、HOMEAGENT_ 前缀、
homed/waiter/hmapdev、.hmap、homeagent-mail-bridge 等插件名、third_party/、
internal/ 与 cmd/ 全部零改动
- ~/.homeagent 路径本批保持原样：cmd/waiter/main.go:109、daemon.go:290 硬编码
仍为 .homeagent，全仓无 .hologram 命中；照规格改文档会指向程序不用的目录，
需与代码侧那条线一起改（遗留项，已单独上报）
判据：文档区展示名残留归零（44 文件）、红线计数与 base e3584bb 逐项相同、
三条变异均被咬住且还原后复绿。
|
2026-10-21 17:00:48 +08:00 |
|
|
|
2b4b29a995
|
refactor(docs): 修复 make install 真破损（服务单元名与安装路径对齐批 2 产物）
批 2 已把 deploy/homeagent.service 改名为 hologramagent.service，但 Makefile
install 目标仍引用旧文件名 —— cp 源不存在，make install 直接失败。这是本批
唯一的真破损。
- Makefile:374 cp 源 deploy/homeagent.service → deploy/hologramagent.service，
目标单元名同步为 /etc/systemd/system/hologramagent.service
- Makefile:371 systemctl stop homeagent → hologramagent（与 374 行装出去的
单元名逐字一致；只改一半会变成"停 A 装 B"）
- Makefile:373 /etc/homeagent /var/lib/homeagent → /etc/hologram /var/lib/hologram
- Makefile:376 安装提示语里的服务名
- Makefile:23 GUI_BINARY=homeagent-gui → hologram-gui（批 2 产物已叫 hologram-gui）
- Makefile:438 run 目标 -data /tmp/homeagent → /tmp/hologram
验证：make -n install 展开的 recipe 里 cp 源全部存在；判据 1 全绿，
变异回旧文件名必红。仅改值，未动 Makefile 结构。
|
2026-10-21 17:00:24 +08:00 |
|
|
|
e3584bb9b6
|
Merge pull request #14 from JianFeeeee/refactor/rename-batch4-ci
改名批 4-a：CI 产物名同步为 hologramagent-*（修 main 上的发版即挂破损）
|
2026-10-21 16:37:40 +08:00 |
|
|
|
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 |
|
|
|
8380fcbb0d
|
Merge pull request #13 from JianFeeeee/refactor/rename-batch2-packaging
refactor(deploy): 改名批 2 · 打包发行（deploy/ 品牌落地）
|
2026-10-21 16:10:42 +08:00 |
|
|
|
350e92057f
|
Merge remote-tracking branch 'origin/main' into refactor/rename-batch2-packaging
|
2026-10-21 16:01:07 +08:00 |
|
|
|
746fad4402
|
Merge pull request #12 from JianFeeeee/refactor/rename-batch1-module
改名批 1：核心仓 Go module 路径 HomeAgent → HologramAgent（不含 SDK 仓与目录改名）
|
2026-10-21 15:58:30 +08:00 |
|
|
|
67d0d90888
|
refactor(deploy): Windows 安装器与 WSL 引导脚本改名，并修两处跨脚本不同源
installer.nsi / install-via-wsl.ps1：产品名、输出名
HologramAgent_v*_win64.exe、GUI 目录 hologram-gui-win32-x64、快捷方式、
自启注册表项、HOMEAGENT_* → HOLOGRAM_*（安装器写、setup.sh 读，必须同改）、
WSL 内数据目录 /var/lib/hologram 与 hologramagent.service。
package-windows.sh 两处顺带修：
1. GUI payload 目录名**不假设上游已改名**。它由 Makefile:331
（GUI_BINARY=homeagent-gui）或 build.sh 的 electron-builder
（productName=HomeAgent）产出，两者都归别的批；而 .nsi 现在期望
hologram-gui-win32-x64。直接改引用会让 Windows 包以
"[FAIL] 需要 GUI payload" 挂掉（或者更糟：有人放宽检查，安装器
File 一个不存在的目录）。改成找到哪个用哪个、统一 stage 成 .nsi 期望名。
2. 版本号解析与 package-linux.sh/build.sh 同源。原先直接
`git describe --tags`，无 tag 分支上拿到的是分支名，于是拼出的
DEB_GLOB 永远找不到包 —— 报错信息看起来像"Linux 包没打出来"，
真因是版本号被解析成分支名。现改为「形如 vX.Y.Z 才采用，否则回退
meta.Version」，并加数字开头守卫。
deploy/scripts/deploy.sh：单元文件名与 systemctl 提示改成 hologramagent。
（deploy-plan.sh 不动：它的 SVC 指的是**本机正在跑的那个**旧单元，
归部署 runbook；deploy-sdk-site.sh 的域名归批 5；upload_assets.py 的
仓库名归批 4。）
|
2026-10-21 13:21:12 +08:00 |
|
|
|
79688386b1
|
refactor(deploy): package-linux.sh/spec 产物与安装布局改名，并补结构判据
package-linux.sh（只动包名/安装路径，不动 SDK module 路径）：
- 产物名 hologramagent-{variant}_*.deb / hologramagent-*.rpm /
hologramagent_*.tar.gz
- 安装路径 /usr/lib/hologram/{sdk,models,onnxruntime,setup.sh}、
/usr/share/doc/hologramagent/（DEP-5 惯例按包名）
- GUI：build/hologram-gui-linux-<arch>、/usr/bin/hologram-gui、
/usr/lib/hologram-gui、hologram-gui.desktop
- 单元从 deploy/hologramagent.service 取，装成 hologramagent.service
- staging /var/lib/hologram
**故意没动** prepare_gomod 里那段 replace 的匹配串
（github.com/JianFeeeee/homeagentsdk）：那是批 3 的 module 改名，
匹配串先改而 module 未改，sed 会整段不匹配且**不报错**，继续用旧路径编
—— 正是清单第四节第 2 条点名的静默失效。等批 3 一起改才安全。
spec：homeagent.spec → hologramagent.spec（git mv），包名/unit/datadir/
changelog 同步；%{_varlibdir} = /var/lib/hologram。
packaging_test.go：第 171 行的 toolchain 关键字跟着改；**第 99-106 行那两处
module 路径断言一行未动**（批 1 的地盘）。另新增四条结构判据，把本批
「日志全绿但包内容还是旧路径」这一类钉住：
· TestPackagingUsesRenamedInstallPaths —— 脚本里不许残留旧路径，且新值必须真出现
· TestDebMaintainerScriptsUseRenamedService —— postinst/prerm 的 SERVICE_NAME
· TestDebControlFilesUseRenamedPackage —— 四个 control 的 Package 与 SDK 路径
· TestSystemdUnitUsesRenamedPaths —— 单元指令行（注释除外）+ 旧单元已删
判据形态仍沿用本文件的原则：断言的是「某个必需处置存在」，不是接线/顺序。
端到端（真装再看内核）由发版流程做。
|
2026-10-21 13:21:06 +08:00 |
|
|
|
503579ae18
|
refactor(deploy): deb control 与 postinst/prerm 改用 hologramagent 包名与 /var/lib/hologram
四个 control：Package: homeagent-{client,server,full,toolchain} →
hologramagent-*，Maintainer/Homepage 品牌名，toolchain 的 SDK 安装路径
/usr/lib/homeagent/sdk → /usr/lib/hologram/sdk。
postinst/prerm：SERVICE_NAME="hologramagent"。
这一行是「改一半就静默失效」的典型：
systemctl enable/start/stop 全部带 2>/dev/null || true，
单元名不对时**不报错**——装完既不 enable 也不 start，用户以为装好了。
现在 postinst 的 DATA_DIR/SETUP_SH 也一起指向 /var/lib/hologram、
/usr/lib/hologram/setup.sh，否则 setup.sh 会在旧目录里初始化凭据，
而内核按新单元从新目录读 —— 表现为「装完登录不上，credentials.txt 找不到」。
setup.sh 同步：HOLOGRAM_DATA / HOLOGRAM_API_KEY 前缀、模型目录
/usr/lib/hologram/models/...。与 postinst 传的变量名必须一致，
否则 DATA_DIR 回落到默认值、凭据写到另一个目录。
Homepage/Documentation 用 trueagent/HologramAgent（与原值同源，只换品牌词）；
仓库 owner 与地址本身归批 4，这里不动。
|
2026-10-21 13:21:00 +08:00 |
|
|
|
3748d01094
|
refactor(deploy): systemd 单元改名 hologramagent.service + 路径品牌化（改名批 2/5）
批 2 的范围只有 deploy/ 的品牌落地：包名、单元名、安装路径、control、
spec、nsi、ps1。域名归批 5、仓库名归批 4、SDK module 路径归批 3，
LDFLAGS/Makefile 的 module 注入归批 1 —— 本批一行未碰。
单元：deploy/homeagent.service → deploy/hologramagent.service（git mv）
- Description/Documentation 品牌名
- ExecStart --data /var/lib/hologram、WorkingDirectory 同步
- StateDirectory=homeagent → hologram（不跟着改的话，systemd 会按旧名
建 /var/lib/private/homeagent 并把 ReadWritePaths 指向另一个目录，
内核起得来但写的位置是错的）
- ONNXRUNTIME_DIR=/usr/lib/hologram/onnxruntime
- LoadCredential :/etc/hologram/security.key、ReadOnlyPaths=/etc/hologram
注释里刻意保留一条 /var/lib/homeagent（"从旧版磁盘钥升级时"的说明）：
那条讲的就是**旧路径**上的历史密钥，改成新路径反而会误导升级操作。
embed-sidecar.service 只改 Description 里的品牌名（它与内核安装布局无关）。
|
2026-10-21 13:20:56 +08:00 |
|
|
|
ed8d5d83a7
|
fix(sdk-meta): 清掉旧 module 路径的注释残留，使判据4 口径可含 third_party
批 1，不含 SDK 仓与目录改名。
背景（复核意见一）：原判据4 为
grep -rl 旧路径 --include=*.go . | grep -v ^./third_party | wc -l == 0
而 M3 的变异点 CoreModule 就在 third_party 内 ⇒ 被判据自身排除，
口径恒真、M3 永远咬不住。改为全仓 *.go（含 third_party）后，
meta.go:80 的这行注释会成为永久命中，使判据恒假 —— 同样不可用。
故连同常量一起把该行注释里的旧路径换掉（它本就描述 CoreModule，
属批 1 改动的必然附属，不是批 5 的品牌展示名）。
改后两个口径均为 0：
- 全仓 *.go 含 third_party：0
- 排除 third_party（旧口径，保留对照）：0
M3 自证：把 CoreModule 改回旧路径 ⇒ 新口径计数 = 1（红），旧口径仍 = 0（恒真已复现）。
|
2026-10-21 12:34:30 +08:00 |
|
|
|
f8adf246c5
|
refactor(sdk-meta): CoreModule 常量跟随核心仓 module 路径
批 1，不含 SDK 仓与目录改名。
CoreModule 喂给 hmapdev 生成插件 go.mod；漏改会让生成的 go.mod
指向不存在的模块路径。
只改这一个常量串：
github.com/JianFeeeee/HomeAgent → github.com/JianFeeeee/HologramAgent
未动（按批 1 边界）：
- SDK 自身 go.mod module 与 SDKModule/LegacySDKModule 常量（批 3）
- 同文件第 80 行注释里的旧路径字样（文档性，批 3/批 5）
- go.mod:46 replace 目标路径
★ 待办：SDK 主仓（github.com/JianFeeeee/homeagentsdk）里同样的 CoreModule
常量需在批 3 同步。
|
2026-10-21 12:19:03 +08:00 |
|
|
|
db6753ee2b
|
build(ldflags): 版本注入串同步到新 module 路径（Makefile:62/318、build.sh:69/230/240）
批 1，不含 SDK 仓与目录改名。
不同步的后果：go build 全绿但 -X 对未知路径静默忽略，
homed --version 的 Version/Commit/BuildTime 回落成默认值。
- Makefile:62 -X .../internal/meta.{Version,Commit,BuildTime}
- Makefile:318 -X .../internal/kernelboot.EmbeddedGraphHash
- build.sh:69 同上三个 meta 变量
- build.sh:230 -X .../internal/security.embeddedKeyHex
- build.sh:240 -X .../internal/kernelboot.EmbeddedGraphHash
|
2026-10-21 12:17:32 +08:00 |
|
|
|
4e70b8d5d8
|
refactor(module): 核心仓 Go module 路径改为 github.com/JianFeeeee/HologramAgent
批 1，不含 SDK 仓与目录改名。
- go.mod 第 1 行 module 路径
- 366 个 .go 文件的完整前缀 github.com/JianFeeeee/HomeAgent 机械替换
（857 处，仅完整前缀；展示名/注释里的 HomeAgent 字样留给批 5）
- 未改：third_party 目录名、SDK 自身 go.mod module、go.mod replace 目标、
homed/waiter 可执行名、.hmap 后缀
|
2026-10-21 12:17:19 +08:00 |
|
|
|
4e66e644da
|
test(security): 修 -race 下 TempDir 清理假红 —— 断言已过却被清理判失败
## CI 实证（run #86 / #87，Race detector 连续两次红）
失败信息自相矛盾：
--- FAIL: TestE2E_ResponseSecretNeverReachesContext (0.00s)
persist_leak_test.go:94: ✅ 回复侧明文未进 context；变量库 1 条
testing.go:1369: TempDir RemoveAll cleanup: unlinkat /tmp/TestE2E_.../001: directory not empty
断言全过、变量库也拦住了，唯一失败点是 `t.TempDir()` 的严格清理：RemoveAll
要 rmdir 那一刻，变量库还有一次落盘（saveLocked 的 tmp→rename）在途/刚落完，
于是判 "directory not empty"。本地不复现是因为机器快、时序不同；CI 在 -race
下慢一拍就撞上。
## 修法
`newScrubStore` 改为自建 MkdirTemp + 重试清理（50×20ms），最后尽力删除且
**不让清理失败污染判据**。安全判据本身没有放宽——只修测试基础设施。
## 验证
本地 `go test -race ./internal/agent/core/ ./cmd/waiter/ -count=1`：
两个包全绿（16.2s / 1.0s）。
|
2026-10-20 10:24:31 +08:00 |
|
|
|
8a2503796e
|
feat(persona): 说话方式增加「主动发表情包」——情绪到位别只干说话
配套 QQ 表情能力（qq_list_stickers / qq_send_sticker / qq_add_sticker）：
人格里补一条表达习惯，让模型在有表情能力时**主动**用，而不是等用户点名要。
分寸也写进人格（一轮最多一两张、要真对得上情绪、没合适的不发），避免刷屏。
实例 personal.md 同步。
注：人格只写"表达习惯"，不写工具名/调用方式——那些在 qq-tools 技能里。
|
2026-10-20 10:06:49 +08:00 |
|
|
|
679536692f
|
fix(pluginmgr): 升级后恢复运行状态 —— 重装不该把正在用的插件静默停掉
## 日志实证（2026-10-20 09:54）
重装 qq 插件后，agent 的工具清单里 qq_* 全消失，它只能：
terminal_list → get_plugin_tools ×2 → plugin_start(qq) → plugin_status
→ output_send__qq_help → get_plugin_tools → 才摸到 qq_list_stickers
根因：升级路径 `installFromData` 里 StopAndUnload 停掉旧实例后，**再也没有
把它拉回来**。安装的语义应当是"换个包"，不是"把正在用的插件关掉"。
## 修法
- 升级前通过 ListPluginRuntimes 记录 `wasLoaded`
- 解压成功、skill 交接完成后，若升级前在跑则 StartPlugin 拉回
- 返回体暴露 `was_running` / `running_restored`，失败不阻断安装（插件已装好）
实测：`reinstalled qq, was_running=true, running_restored=true`，装完
loaded/alive 均为 true、PID 更新。
## 测试
- TestUpgradeRestoresRunningState：升级前在跑 ⇒ StartPlugin 恰好调用一次
- TestUpgradeDoesNotStartStoppedPlugin：升级前没跑 ⇒ 不得强行拉起
## 同批日志里的另外两条（非代码问题，仅记录）
1. llmsproxy 在 09:52:21 / 09:53:14 被重启，其间 homed 收到 connection refused，
经「stream 失败→非流式 + 2s 重试→换 provider」兜底，用户侧无失败但多耗一轮。
2. 上游返回 404「The model is not registered」与 429 限流（channels-codearts），
属 llmsproxy 侧渠道配置/配额问题，建议在 llmsproxy 里核对该模型注册。
|
2026-10-20 10:01:59 +08:00 |
|
