admin/ARTEX
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
458 Commits 1 Branch 0 Tags
main
Commit Graph
49 Commits
Author SHA1 Message Date
Autumn-27 e6ec569991 docs(changelog): 定版 0.3.15 2026-10-07 08:54:02 -04:00
luckoneandClaude Code a049f09b97 fix(notify): 安全审计修复 —— 掩码绕过、SSRF、静默丢失等 12 项 
对推送功能做了一轮安全审计，每条都先复现、再修、再补回归测试。
以下按严重程度排列。

【严重】掩码可被「改目标地址、保留凭据」绕过
目标地址与凭据是两套独立字段，而配置合并对「未提及的键」保留原值。于是
只改地址、对凭据避而不谈，服务端就会把库里的真凭据发到任意地址。已实测
复现四个渠道：通用 Webhook 的 Authorization 头、Telegram 的 Bot Token
（进请求路径）、邮件的 SMTP 密码（STARTTLS 后交给对端）、钉钉/飞书的加签
密钥（该项不可利用，一并列出仅为说明面）。完全静默、不依赖重定向，所以
上一轮加的「拒绝跨主机跳转」挡不住它。

修法：新增 Channel.DestinationKeys() 声明「消息发往哪」，PrepareConfigUpdate
在地址变化时要求对**每一个**凭据字段显式表态（给新值，或显式留空表示不再
需要）——原样回传掩码值等于「沿用旧凭据」，正是攻击形状，一并拒绝。
刻意不做「自动丢弃凭据」：对可选字段（如 headers）那会变成「鉴权静默没了
但接口返回成功」，比报错更难排查。

【中】markdown 系三渠道对不可信内容零转义
钉钉/企微/飞书此前完全不转义（Telegram 与邮件都做了），而标题与摘要来自
模型输出、资产 url 来自被测目标。一条标题里的 `[文字](http://evil)` 会在
工程师的钉钉里变成可点击外链；`![](http://evil/beacon)` 会被客户端拉取，
泄露阅读者 IP 并暴露「这条已被看过」。现统一单行化 + markdown 元字符转义。

修的过程中还纠了自己一个设计错误：转义一度被放进 markdownTitle，而它被
markdown 正文、Telegram 的 HTML、飞书卡片、Webhook 的 JSON 与邮件主题四种
语境共用，markdown 的反斜杠泄漏到了 Telegram 消息里（用户会看到 `\(1\)`）。
转义必须发生在各自的渲染出口——测试直接抓到了这个回归。

【中】投递地址的 SSRF 面
此前只校验 scheme 与 host，云元数据 169.254.169.254、环回、内网一律可投递；
而失败响应体前 200 字节会进 last_error 并被投递历史接口回显，构成半盲读
原语。现在在**拨号阶段**设防（最终生效点，同时覆盖 DNS 重绑定与同主机
重定向）。环回/链路本地需显式 ARTEX_NOTIFY_ALLOW_LOCAL=1 才放行（本机
SMTP 中继是合法配置）；RFC1918 私网**刻意放行**——内网自建 Mattermost /
SMTP 很常见，做到那个程度会把正常部署一起废掉，这条取舍写进了测试断言。

【中】汇总消息被截断后整批标记已送达 = 静默丢失
渠道都有长度上限（企微 4096 字节最紧）。此前渲染完整篇再截断、然后整批
标记成功：被截掉的那些既不在消息里、也不在失败列表里，投递历史还显示
成功。现改为按**整条**打包，只标记真正装下的，其余回队续发，消息头部
如实写明还有多少条在下一条。被推迟的条目**不消耗重试次数**（领取时乐观
+1 的那次减回去），否则 500 条的积压会在第三段就把尾部判成失败。

【中】其余修复
- min_severity 打错字让过滤器静默失效（未知级别序数为 0 → rank>=0 恒真，
  用户以为「仅高危」实际全推）。改为写入时校验取值。
- rate_per_min=0（不限流）不可达：文档/UI/令牌桶都按 0=不限流解释，唯独
  写库那层 `if <=0 取默认值` 把它改成 20 或 100。默认值改到接口层填。
- digest 渠道完全绕过令牌桶（allow 被扣却没人用）。
- 失败处置按整批 max(attempts) 判断，让老投递连坐同批的新投递。
- 汇总批次里快照无法解析的投递被静默标记成功。
- url.Parse 失败时错误文本仍带完整地址（上一轮只修了 http.Client.Do 那侧；
  且当时的用例全走 scheme 分支、没覆盖解析失败路径，是假保证）。
- 单渠道每轮投递条数可能超出租约时长（多实例下重复发送）。加了防漂移
  断言，写的时候立刻发现原取值 6 恰好用满租约、零余量，已改 5。
- Telegram 截断可能切断 HTML 实体，导致整条被拒收。
- 邮件把 SMTP 4xx（灰名单等临时失败）判成永久失败，最该重试的场景从不重试。
- 提交嵌套结构时会把掩码字面量真的写进库，导致鉴权静默失效。

测试：notify 包从 82% 提到 86%，新增 SSRF 守卫、掩码绕过（用攻击形状的
输入而非「防御逻辑的正确输入」）、分段投递收敛、markdown 转义、SMTP 4xx/5xx
分类等回归用例；端到端补了一条「60 条长标题跨多轮发完且不卡死」的收敛测试。

Co-Authored-By: Claude Code <[email protected]>
 2026-09-30 16:25:06 +08:00
luckoneandClaude Code f3fb37f70d feat(notify): 漏洞发现支持推送到钉钉/飞书/企业微信等六种渠道 
新增「系统 → 通知推送」页，把扫描发现的漏洞推送到钉钉、飞书、企业微信、
通用 Webhook、Telegram、邮件。同一类型可配任意多个机器人实例，每个实例独立
设启停、限流与过滤规则（最低级别 / 任务资产范围 / 漏洞类型关键词 / 是否接收
处置状态变更）。推送时机分实时与汇总两种模式，「高危实时、其余汇总」建两个
渠道即可表达，策略不写死在代码里。带投递历史与失败重发。

三个关键设计：

1. 写漏洞的事务只做一次盲 INSERT。notification_events 由 RecordFindingTx
   在同一事务内写入，保证「漏洞落库」与「推送任务存在」原子一致；这条 INSERT
   刻意不读渠道表、不跑用户的过滤规则，否则一条配错的过滤条件就能污染甚至
   中止事务，让高危漏洞存不进库。为把失败隔离在这一条语句上（PostgreSQL 中
   事务内任一语句报错会让整个事务作废、连 COMMIT 都失败），它被 SAVEPOINT
   包住，失败时只记日志。

2. 投递用租约领取而非长事务。FOR UPDATE SKIP LOCKED 领取后把行置为 sending、
   把 next_attempt_at 推到未来作为租约，提交后再做网络投递，因此投递期间不
   持有数据库锁；崩溃留下的 sending 行会被下一轮重新领取，自愈且不会无限重试。

3. 限流不消耗重试预算。先按渠道令牌桶算出本轮还能发几条，再按这个数量领取；
   顺序反过来会让被限流挡下的投递白计一次尝试，三次预算被等待耗光后落入失败。

审计并修复的四个问题：

- 推送凭据经错误信息外泄：http.Client.Do 返回的 *url.Error 会把完整 URL 打进
  错误文本，而钉钉 access_token、企业微信 key、飞书 hook id、Telegram
  /bot<token>/ 都就在 URL 里。该串流入 last_error（明文落库）、投递历史接口
  （绕过渠道掩码）、服务端日志与前端错误提示。现统一脱敏为 scheme://host
  + 底层原因，并拒绝跨主机重定向。
- 最低级别门槛打错字会让过滤器静默失效：未知级别序数为 0，判定退化成
  rank >= 0 恒真，用户以为限制「仅高危」实际全推。现于写入路径校验取值。
- 汇总批次无上限：一次领取把全部待发行读进内存、消息被渠道长度上限截掉大半
  且静默丢失。现单批上限 500 条，超出部分留库成为下一批。
- 邮件渠道把 SMTP 4xx（灰名单等临时失败）判成永久失败，导致这类最该重试的
  场景从不重试。现按应答码首位区分 4xx/5xx。

测试：notify 包 82% 覆盖（含用自建最小 SMTP 服务器驱动的完整邮件协议会话、
两种签名算法对 OpenSSL 基准值的比对、UTF-8 边界截断、以及模板能力边界的
反射断言）；db 与 server 侧共 29 个用例跑真实 PostgreSQL，其中端到端用例
真发 HTTP 到假接收端并断言消息内容与投递状态。

Co-Authored-By: Claude Code <[email protected]>
 2026-09-30 16:25:06 +08:00
Autumn-27 4b1eda8e92 fix(findings): 「按资产」视图资产列表溢出时补回滚动条 
左侧资产树的滚动容器靠 height:100% 取高，但外层卡片只给了 max-height
没有确定高度，百分比高度解析失败，资产多时列表撑破卡片或被截断且无法
滚动。改为把高度上限直接放到资产树的原生滚动容器上（overflow-y-auto +
max-h，随窗口自适应），资产少随内容收缩、资产多封顶并出滚动条。

Closes #170
 2026-09-30 04:16:43 -04:00
Autumn-27 527092f23b feat(intercept): 新增内置拦截规则「删除类接口路径」 
内置的 HTTP 破坏性规则只认 DELETE 方法（curl -X DELETE、requests.delete(、
method:'DELETE'），路径类规则的词表又只有 /clear /wipe /flush /purge /truncate
/drop /destroy /factory-reset /reset-all。而多数应用的删除接口用 GET/POST 就能
触发，于是 `curl 'http://t/api/user/delete?id=1'` 不命中任何内置规则，会真实删掉
目标数据。

补一条 deny 规则覆盖 /delete /del /remove /unlink /erase /destroy，允许
/deleteAll、/delete_user、/delete-user 这类后缀形式（destroy 是重复覆盖：v1 那条
不允许后缀，/destroyAll 是漏的）。动词后强制跟分隔符，/delivery、/details、
/delta、/delegate 不会被误拦。

种子走独立标记位 intercept_default_rules_v3，已有实例升级后也会拿到——改 v1 的
字面量对老库无效（标记位已是 done）。插入带 WHERE NOT EXISTS 兜底，标记位丢失也
不会插重复。正则提为包级常量，配纯正则单测（不依赖 DB）覆盖命中与误伤两侧。
 2026-09-30 04:12:57 -04:00
Autumn-27 2f5f7c0227 feat(traffic): 流量列表新增「清空全部」，并借空库时机压实索引 
一次删除全部流量记录，忽略当前筛选条件。与按 host 删除的两条路径相比多做
两件事：

- 清理索引已不再记录的历史 host 目录。按 host 删除只能从索引反查目录，
  行已消失的孤立目录会一直留着；「清空全部」既然语义是不留残余，就直接
  扫顶层目录（跳过 _index/_blobs/_ca/_delete_staging）。
- 收尾做一次全量压实（optimize + VACUUM + wal_checkpoint(TRUNCATE)），把
  索引占用的磁盘空间还给系统，并把实际释放量返回给前端提示。

VACUUM 的耗时与临时空间只和它保留的内容成正比，所以空库是做全量压实唯一
免费的时机——也正因如此，这一步顺带成为已有实例的转换途径：auto_vacuum
只能通过 VACUUM 生效，清空一次之后旧库即转为增量回收模式，此后日常按
host 删除就能自行回收空间（TestDeleteAllConvertsLegacyIndex 覆盖）。

已绑定到漏洞的流量证据保存在独立的证据库中，不受影响——绑定时已拷出独立
副本，正是为了让热流量可以随时清空而不带走证据。确认弹窗里明确写了这点。

前端把「清空全部」做成 outline 样式而非第二个 destructive 按钮：它忽略一切
筛选条件，不该看起来和「删除该目标」只差一次误点；无流量时禁用。

测试：新增 TestDeleteAllPurgesAndCompacts（清空后索引、正文、blob 引用与
孤立目录全清，空间回收到 1/8 以下，清空后仍可继续录制）与
TestDeleteAllConvertsLegacyIndex（旧库经清空后转为增量回收，随后普通删除
即可回收）。
 2026-09-30 02:50:49 -04:00
Autumn-27 3227f2e54c fix(traffic): 删除流量后把索引空间真正还给操作系统 
删除流量只让数据不可见，磁盘占用从不下降。两处原因叠加：

1. SQLite 删行仅把页挂到 freelist，而索引库建库时未启用 auto_vacuum，
   文件永不收缩。256KB 以下的正文全部内联在这个库里，所以体积主体就在
   这里，且只增不减。
2. ex_fts 是 contentless_delete 全文索引，DELETE 只写 tombstone、不回收
   原 postings，从来没有合并过——删流量反而让索引变大（实测 exchanges
   清零后 ex_fts_data 仍占 3.3MB / 840 行）。

trigram 索引约为正文体积的 2 倍，加上内联正文，抓包量大的实例会为早已
删掉的流量长期占用数倍磁盘：实测抓 6MB 文本正文 → 索引 16.2MB，删光后
仍是 16.2MB。

修复：
- 新建索引库在建表前启用 auto_vacuum=incremental。该 pragma 只在库中尚
  无表时可设，且只有紧随的 VACUUM 才把它写入文件头，两步都必须落在同一
  条连接上，故新增 initIndex 固定一条 *sql.Conn 串起 pragma 与建表。
- 新增 reclaim/reclaimChunk：删除提交后在后台分块执行全文索引增量合并、
  incremental_vacuum 与 wal_checkpoint(TRUNCATE)（不做 TRUNCATE 则空间
  留在 WAL 里、文件大小不变，PASSIVE 也清不掉）。接入 DeleteHost、
  HostDeleteStage.Commit 与 RecoverHostDeleteStages 三条路径。
- 回收分块进行并在块间释放写锁：record() 由 go-mitmproxy 在把响应写回
  客户端之前同步调用，一次性回收数 GB 会连带卡住被测请求。Close 先发停止
  信号，剩余预算留给下次删除，不拖住进程退出。
- 终止条件按「是否有进展」判定：incremental_vacuum 只能释放挪得到文件
  末尾的页，残留少量空闲页是正常结果；另加步数上限兜底。fts5 无法查询
  索引是否已合并完（其特殊 INSERT 自身即计一次 changes），故改为固定合并
  预算，未做完的留给后续删除。
- busy_timeout 改由 DSN 提供：它是每连接设置，原先的 db.Exec 只配到池中
  碰巧被选中的那一条，其余连接在有写者时会立即失败而非等待。驱动按第一个
  '?' 切分 DSN，故数据目录路径含 '?' 时退回裸路径 DSN。

已有实例的索引库仍是旧模式（auto_vacuum 无法事后开启），incremental_vacuum
在其上为空操作，启动时打印提示；此类库的 tombstone 增长已止住，已占体积
待后续「存储压缩」入口一次性回收。

测试：新增 reclaim_test.go（空间回收回归、tombstone 合并、新库模式、旧库
不卡死）与 upgrade_test.go（旧装机升级后同库同数据、全文与正文可用、
legacy path 行不受影响；以及降级回旧二进制仍可读写）。
 2026-09-30 01:44:44 -04:00
榆木 25b6018818 fix(llm): 一次性 LLM 调用补挂 session id，让自定义会话头真正生效 (#175) 
自定义会话头（profile 的 session_header_key）的头值取自请求 context 上的
session id，而该 id 由 agentcore 仅在挂载 transcript store 时才写入 context
（agentcore.Prompt 中 `if s.writer != nil` 那一行）。

目标拆解（第 0 轮，DecomposeGoalsWithProvider）与冷节点压缩（§4 body 调用）
都是不挂 store 的一次性调用，context 上没有 session id，quotaAwareTransport
因此跳过该头。对 opencode zen 这类「缺 x-opencode-session 直接 400
MissingSessionID」的端点，表现为「第 0 轮目标拆解 400 失败、后续 planner
轮次却完全正常」；压缩失败则只留一行日志，极难关联到本设置。

改为在这两条路径显式挂上按探索稳定的 session id（exp<N>-goals /
exp<N>-compactor），与旁路问答、连接测试已有的做法一致。附带修好用量归因：
这两个 id 能被 llmrec.parseSession 正确解析，此前这两条路径的 token 完全
记不进 llm_usage。
 2026-09-29 18:21:30 +08:00
Autumn-27 86162d7eda docs(changelog): 定版 0.3.14 2026-09-24 13:35:48 -04:00
Autumn bf7f414477 Update CHANGELOG.md 2026-09-19 23:37:57 +08:00
Autumn-27 7b92395aa0 docs(changelog): 版本号改为 0.3.13 2026-09-19 11:23:33 -04:00
Autumn-27 2943eb2ea6 docs(changelog): 定版 0.4.0 2026-09-19 11:20:03 -04:00
Autumn-27 0ec51e3799 docs(changelog): 定版 0.3.12 2026-09-17 13:17:39 -04:00
Autumn-27 7f71f77d16 fix(changelog): 移除历史遗留的裸 NUL 字节，恢复文本格式 
0.3.10 的 /btw 条目把 NUL 字符本身字面写进了反引号，导致整个
CHANGELOG.md 被 git 和编辑器判为二进制/显示乱码。改为可读的 \u0000。
 2026-09-15 12:39:49 -04:00
Autumn-27 8ee890771f docs(changelog): 定版 0.3.11 2026-09-15 12:37:19 -04:00
Autumn-27 f2589ad47c fix(web): 修复 demo 任务详情页旁路提问历史缺失导致的整页崩溃 
mock 模式下 GET /api/tasks/<id>/side-questions 无路由,被读兜底当集合返回
[],data.items 为 undefined,旁路 hook 的 merge() 迭代抛 TypeError: t is not
iterable,异常在 setState updater 中经 render 重抛、catch 接不住,整页被错误
边界接管。mock handler 显式返回空旁路历史,sideAPI.history 同时归一化返回值。
 2026-09-14 09:37:08 -04:00
Autumn-27 90f31577f2 docs(changelog): 定版 0.3.10 2026-09-13 12:37:37 -04:00
Autumn-27 9eefeb3f32 docs(changelog): 补齐 Unreleased —— worker 回看工具/node_detail/add_hint 播报、回看工具补绑修复、/btw NUL 修复、合并触发去重 2026-09-13 12:22:21 -04:00
Autumn-27 e4c744a318 feat(search): 网络搜索新增 DeepSeek 官方来源 
不单独配置凭据，直接复用当前激活的 LLM 配置(base_url/api_key/model)。

这个来源与 ddgs/brave/tavily 性质不同：DeepSeek 没有可直接调用的搜索接口，
搜索只存在于其 Anthropic 兼容 messages 接口内部，以 web_search_20250305
服务端工具的形式由 DeepSeek 服务端执行。由此带来几个必须让用户知道的差异，
已在设置页写明：

- 仅支持 DeepSeek 官方端点 + anthropic 协议。实测其 OpenAI 协议端点会直接以
  "unknown variant, expected `function`" 拒绝一切服务端工具，web_search_options
  之类的顶层字段则被静默忽略，没有可用的替代写法。
- 每次搜索额外消耗一次模型调用。
- 搜索请求由 DeepSeek 服务端发出，不经过搜索出口代理，也不计入流量留痕。
- 返回结果只有标题与链接，没有摘要(DeepSeek 只给 encrypted_content)，需要正文
  时仍由 WebFetch 抓取。

上述条件不做程序校验，仅在界面说明，由用户自行确认——配置不满足时搜索会在实际
调用时报错，与其它来源填错 Key 的反馈路径一致，可用「测试搜索」按钮实跑验证。

依赖 norma v0.3.8。
 2026-09-12 07:13:46 -04:00
Autumn-27 4ccb8f4ff2 fix(agent): list_assets 按任务范围过滤，修复任务间资产互串 (#59) 
list_assets 此前把任务 id 写死为 0、裸查整个共享资产库，模型又无从写出
范围过滤条件，于是把别的任务的资产（尤其 IP）当成本任务目标，测试方向
被带偏。

- 新增 QueryDSLInScope / GetByIDsInScope：只返回落在【本任务及直接关联
  任务】task_scope 内的资产，按归属匹配而非字面值（根域范围含其全部子域/
  服务/接口，网段范围含段内主机及服务）；越权 id 静默丢弃
- 新增 scopeTargetCTE（纯 scope 归属判定，不含 anchor/tested）；whereBuilder
  加占位符偏移，$1 留给 taskID
- 修复 IP 直连主机(http://1.2.3.4/api)无法被网段范围命中的盲区：谓词加
  OR ts.net >>= try_inet(a.domain)
- 非任务上下文(Auto/pentest, taskID<=0)无范围可依，回退全库
- QueryDSL/CountDSL 原样未动，UI 的「测试资产」视图（按生产者过滤）不受影响
 2026-09-12 03:25:47 -04:00
Autumn-27 42f0ff97d3 refactor(agent): 测试范围与资产覆盖度开关解耦，移除 insert_assets 的 related 入参 
task_scope 是任务的授权边界、资产查询的过滤基准，覆盖度开关只该决定要不要
拿它当分母算指标，不该决定要不要累积范围本身。此前关闭覆盖度会让 auto 与
agent 两条写入路径同时失效，task_scope 只剩界面手工添加的行。

- insert_assets 的自动入范围(source='auto')无条件执行，不再判 coverageDisabled
- add_task_scope 移出 coverageOnlyTools，planner / 任务内主 Agent / 目标拆解
  Agent 在覆盖度关闭时照样持有；list_untested_assets 仍随开关隐藏（纯覆盖度视角）
- 移除 insert_assets 每条资产的 related 入参：唯一作用是决定要不要入范围，值又
  不落库（同一资产再次登记即作废、界面上也看不出谁被判为无关），连带删除
  StripCoverageParams 及其专用的 deepCopyJSONMap / nestedMap
- add_task_scope 与 goalsScopeTail 的描述改为「授权边界」优先、「覆盖度分母」其次
 2026-09-11 13:33:44 -04:00
Autumn-27 33d3d00c4b docs(changelog): 定版 0.3.9 2026-09-11 12:59:32 -04:00
Autumn-27 aa3ef63121 docs(changelog): 补齐 0.3.8 以来的变更条目 2026-09-11 12:45:23 -04:00
Autumn-27 44156a0a4c feat(update): 页面一键更新 + 守护启动脚本 
系统配置页新增「版本与更新」卡片，顶栏版本号旁在有新版时亮出提示胶囊。
更新链路：下载发布包 → 比对 SHA256SUMS → -h 冒烟测试 → 暂存 artex.new
→ 以退出码 75 退出 → 守护脚本重新拉起并完成换装，页面轮询 /api/health
等版本号变化后自动刷新。

新增 start.sh / start.bat 作为正式启动入口，只按退出码决定是否重新拉起
（0 停止 / 75 应用新版 / 其余崩溃退避）。校验、冒烟、换装、回滚全部收在
selfupdate 包里而不写进脚本：这些逻辑在 sh 和 bat 上要写两套，而它们恰恰
最不能出错——换上跑不起来的二进制后守护进程会反复拉起它，只能上机器手工救。
Docker 的 ENTRYPOINT 一并改为该脚本，并由它转发 SIGTERM，否则 docker stop
只发给 PID 1，artex 做不了优雅关闭会被 SIGKILL 硬杀。

失败保护两道闸门互补：无法 exec 由换装前的冒烟挡住，能执行但初始化崩溃
由启动计数兜住（连续 3 次失败自动回滚 artex.old，坏的留作 artex.failed）。

GitHub 查询结果后端缓存 30 分钟（失败 2 分钟）。未认证 API 是每 IP 每小时
60 次，且这 60 次是服务器 IP 上所有用户共用的，顶栏每次整页加载都查一次，
不缓存会很快耗光配额导致真想更新时反而查不动。手动「检查更新」带 force=1
绕过缓存。

安全：只认 GitHub 域名且强制 HTTPS（逐跳校验重定向），发布源写死不可配置；
升级文件挂在可执行文件所在目录而非 CWD（服务化运行时 CWD 可能是 /）；
开发构建版本号不可比较，禁用一键更新。

走完整 zip 而非裸二进制，因为现有 Release 的 SHA256SUMS 只覆盖 zip，
这样无需改 CI，也兼容已发布的历史版本。

已知限制：Docker 下只换程序不换镜像（工具链不同步、重建容器会退回镜像
版本）；不同步发布包里的 skills/；更新即重启会中断运行中的任务。
 2026-09-11 12:39:59 -04:00
Autumn-27 3c2a60fba7 fix(agent): 空转回合注入续跑指令，复用空响应重试次数 
模型有时一整轮只输出思考、既不给正文也不调工具，harness 视为自然结束
(end_turn 且无 tool_use)，直接以 completed + 空总结收场，一条未完成的意图
断在半路，表现为「任务正常结束但没有文字总结」。五层 LLM 重试均够不着它
(非错误路径)，SDK 空响应重试也够不着(以是否 yield 过事件判空，而思考增量
本身就是事件)。

work 的 Stop 钩子现识别这种回合并注入一条续跑指令，让模型带着已有思考继续
执行下一步——不选原样重发，因这类空转由提示词与上下文形状决定，是稳定行为
而非随机抽风。次数复用 LLM 页「空响应重试次数」(默认 2、-1 关闭)，是一条
意图的总量闸而非连续次数(harness 已限死连续空转只推一次)。
 2026-09-10 10:49:11 -04:00
Autumn-27 8dae851b9b docs(changelog): 发布 0.3.8 2026-09-09 14:10:07 -04:00
Autumn-27 c585b196b5 docs(changelog): 补全 v0.3.7 以来的未记录变更到 [Unreleased] 
把 v0.3.7 之后除五层重试外的 25 个 commit 归类补入 [Unreleased]：
cold-digest 冷节点压缩、全局出口代理、自定义会话头、墙钟就地收尾、
worker/planner 提示词与工具集调整、graph_overview 改动、意图状态标签
语义修正等。新增「探索图」「网络」两个章节。
 2026-09-09 14:08:48 -04:00
Autumn-27 a50bf02428 feat(llm): 五层重试的次数与间隔可配 
一次模型调用的失败由内到外经过五层重试:建连(SDK)、空响应(SDK)、同 provider
安全窗口、轮询熔断、意图重跑。此前五层的次数与间隔全是写死的常量,遇到脾气各异
的中转站只能改代码。现在都能在 LLM 页配置,不配就是原来的默认值。

配置语义五层统一(db.RetryRule):次数 0=内置默认 / -1=关掉这层 / >0=该值;
间隔 0=原本的指数退避 / >0=改用固定间隔。0 被"未配置"占用,故关闭用 -1。
写库前夹紧到 次数 [-1,20]、间隔 [0,1h],DB 另有 CHECK 兜底。

粒度按层的性质分:前三层跟着端点走,可在每个模型配置里逐字段覆盖全局默认(只钉
间隔的仍继承全局次数);熔断与意图重跑是进程级语义,只有全局一份。

生效路径:①②是 provider 构建参数,保存后重建缓存;③随每次 hooks.current()
解析,故障转移换配置时重试节奏跟着换;④在失败路径上每次都要读,由 applyRetryPolicy
推给 llmpool.Registry;⑤每条意图收尾读一次。全部热生效,无需重启。

连接测试刻意不带这些参数——它有 30s 硬超时,叠上用户配的重试只会把本来能用的
端点测成超时失败。

norma 升 v0.3.5(llm.Config 新增 RetryInterval / EmptyResponseRetries /
EmptyResponseInterval)。旧库升级后行为逐字节不变:新列默认 0,settings 键不
存在即全默认。设计见 docs/LLM重试设计.md。
 2026-09-09 13:35:04 -04:00
Autumn-27 f66ac54fd6 docs(changelog): 发布 0.3.7 2026-08-31 12:24:38 -04:00
Autumn-27 338e77c064 fix(skills): 修复技能压缩包上传失败与中文命名被判非法 
- 补上 bzip2 / Zstandard 解压器(标准库 + 已有的 klauspost/compress,不引新依赖),
  不再对压缩软件非默认档位打出的包抛 "zip: unsupported compression";
  Deflate64/LZMA/XZ/PPMd 等真解不了的方式与加密包改为解压前给出中文提示,
  点名文件、压缩方式与重新打包的办法
- 技能内文件路径校验从 [A-Za-z0-9-_./] 的 ASCII 白名单改为 Unicode 黑名单:
  放行各语言文件名与空格,仍拒绝控制字符、非法 UTF-8、零宽与双向控制字符、
  \ % # ? * : " < > | 及 .. / 绝对路径 / 空路径段,防目录穿越行为不变
- 技能名放开非 ASCII 字母数字(中文可直接作技能名),ASCII 仍守 agentskills.io
  规范,空格、点与路径分隔符照旧拒绝
- Windows 压缩软件按 GBK 写的文件名兜底解码后再校验;frontmatter 的
  name: "中文技能" 去引号
- 新增 8 个测试:zstd 包、GBK 包、不支持的压缩方式、加密包、目录穿越、名称与
  路径校验
 2026-08-31 11:37:44 -04:00
Autumn-27 acd1ac29d7 feat(assets): 去掉企业资产范围 256 条规则上限 
逐个 IP / 域名录范围的企业很容易撞上这个上限,撞上之后只能拆成多个企业,
而范围本身并不因为条数多就更慢。

- db:删掉 MaxCompanyScopeRules 常量、请求条数校验与
  ensureCompanyScopeCapacityTx(每企业持久化总数的事务内校验)
- 前端:去掉 MAX_COMPANY_SCOPE_RULES 与「剩余额度」计算,追加范围弹窗不再
  按剩余条数报错;demo mock 的两处上限一并移除
- 单条规则仍限 1024 字符;请求正文 2 MiB(maxCompanyMutationBodyBytes)保留
  作兜底,约合四五万条规则

测试:原先断言「超容量被拒」的两个用例翻转为「超过旧上限也能写入」——
db 侧批量写 300 条 + 追加 1 条,server 侧一次创建带 300 条范围的企业。
新用例先注册清理再断言,避免断言失败把企业留在共享开发库里。
 2026-08-31 11:22:34 -04:00
Autumn-27 23cfb9ed4e feat(findings): 发现页新增「按资产」视图 
左侧资产树 + 右侧该子树下的发现,与另外两个视图共用同一张表和同一批筛选。

后端
- db/finding_assets.go:按当前筛选构建资产树。只收有发现的资产,祖先链逐层
  补齐(endpoint→service→subdomain/ip→root_domain),父子优先级与
  BuildCoverageGraph 同源;计数沿祖先链去重累加,一条发现挂多个资产不会让
  父节点重复计数
- FindingFilter 加 AssetScope:选中节点=选中整棵子树,解析成资产 id 集合后
  下推 SQL,列表 / 分组 / 导出三个入口共用,导出「当前筛选」自动带上
- 「未关联资产」同时收 asset_ids 为空与指向已删资产的发现,与树上桶的口径
  一致(只判空数组会让桶上的数字大于点开后的条数)
- findingFilterFromQuery 统一四处的筛选解析;新增 GIN 索引
  idx_findings_asset_ids,按资产反查发现不再全表扫

前端
- 树默认展开一层,支持过滤(匹配项自动展开)、面包屑下钻、手动刷新
- 每层只显示相对上一层的增量:子域名去根域名后缀、服务显示 `https :443`、
  接口只留路径。完整值在 title 与面包屑,搜索仍按完整值匹配
- 不轮询:进入视图 / 改筛选 / 页内改动发现 / 点刷新时才查
- 节点超上限时整层丢弃接口/服务并提示,计数已在上层不会丢
 2026-08-31 10:58:32 -04:00
Autumn-27 5fa2ff0b46 feat(findings): 发现页新增平铺大表视图并设为默认 
分组视图要逐个任务展开才看得到漏洞，跨任务扫列表时反而绕路。新增
「全部发现」平铺视图作为默认视图，与「按任务分组」通过页头 Tab 切换。

- 表格主体抽成 FindingsTable，两个视图共用同一份行渲染，勾选/行内展开/
  行内改名与改状态/深入/删除的行为完全一致
- 平铺视图走 findingsPage（后端本就支持不带 task_id 的跨任务分页），
  页码与每页条数独立 state，筛选变更即重置回第一页
- 两视图共用统计卡片与筛选条，当前视图随筛选项一起持久化到 localStorage
- 轮询只打当前视图；行内改动同步写两边缓存，切换视图不会看到过期数据
- 首个请求推迟到偏好水合之后，避免按默认视图白拉一次
 2026-08-31 09:59:15 -04:00
Autumn-27 a2f7ac9747 feat(llm): 任务 LLM 配置链改为任何状态都可修改 
任务结束(done/failed/timeout)后主 Agent 对话仍走任务配置链,链上模型出问题时
既不能改配置链、也就没法继续交互。去掉 HTTP 与 DB 事务两处终态拦截,前端弹窗
对终态任务同样开放编辑与保存(顺带修掉 queued 状态也不能编辑的口子)。

终态任务保存时不再重开额度阻塞意图:那些意图会从 blocked 挪到 open,既没有
worker 执行、也不再满足「重跑意图」的可重跑条件,反而变成死状态。终态任务想
继续跑仍走重跑意图/新增目标,由它们把任务重新 admit 回运行态。
 2026-08-31 09:26:33 -04:00
Autumn-27 051ca84a20 docs(changelog): 发布 0.3.6 2026-08-27 12:34:51 -04:00
Autumn-27 f6c4cbb013 docs(changelog): 补全 0.3.5 遗漏条目 
补上 v0.3.4 以来已合入但未记录的变更：LLM 流式/非流式切换、
OpenAI Responses API 格式、LLM 请求/响应原文录制、会话列表多选模式、
以及 #57 的任务/会话/流量体验增强；0.3.5 贡献者补记 @neouks。
 2026-08-25 12:27:38 -04:00
Autumn-27 48f260fdde docs(changelog): 发布 0.3.5 2026-08-25 12:22:06 -04:00
Autumn-27 99ac96da2f feat(agent): 优化 planner/worker 提示词并加量化验收核对 
- planner 判目标新增「量化验收核对」：覆盖度/flag 数/权限等可量化目标
  未达标时禁止 prove_goal，修复覆盖度要求 100%、实测 40% 却被判完成
- 重写 planner「0 意图」判定：仅在「方向已被现有意图覆盖」或「下一步
  依赖在跑 work 的产出」两种情况才 0 意图，避免目标未达成时过早收手
- 强化 worker 否定结论证据门槛：未穷尽手段/证据弱一律标 inferred，
  避免轻率的 observed 否定把整条路线焊死
- 加 reseedPlannerPrompt / reseedWorkerPrompt 一次性迁移，旧库追加新
  默认版本并切换，旧版保留在历史可恢复
 2026-08-25 12:19:04 -04:00
Autumn-27 4d9580ebfa feat(ops): 新增管理员密码重置脚本 reset-password.sh 
登录用户名固定 ARTEX,密码以 bcrypt 存于 settings 表 auth.password_hash。
脚本连库后用 pgcrypto 在库内生成 bcrypt(gen_salt('bf',10)),与后端
golang.org/x/crypto/bcrypt 校验兼容,写回该键,重置后无需重启。

- 两种部署:local(宿主机 psql)与 docker(compose/exec 在 postgres 容器内跑,
  因 compose 默认不暴露 5432)。
- 连接信息优先级:命令行 > --dsn/$ARTEX_PG_DSN > config.json 的 database.*
  (python3 解析,缺则 grep 后备)。
- 安全:新密码经环境变量 + psql \getenv 传入,不进 argv;SQL 用 :'newpw'
  自动转义防注入;DB 密码走 PGPASSWORD;docker 用 -e 名字继承、不带值。

验证: 临时库实测三条路径(显式 dsn / config.json / 含 ';DROP TABLE' 特殊
字符密码),写回的 hash 均能被 Go bcrypt 接受、错误密码被拒、注入未生效;
bash -n 通过。全程未触碰真实 artex 库。
 2026-08-25 08:47:34 -04:00
Autumn-27 6e40f41051 docs(changelog): 发布 0.3.4 2026-08-24 12:41:47 -04:00
Autumn-27 7299150cfa fix(chat): 会话已选 LLM 时不再被「全局未激活」误拦，提示按状态细分 
发送消息的前置检查只看全局激活配置(chatAgentRef),而真正执行的
runConversationSync 会优先用会话所选/Agent 绑定的配置——两处解析分叉,导致
「会话已选一个有效配置、但全局没有激活配置」时,消息在预检查阶段就被 503
「LLM 未配置」拦下,根本走不到能用所选配置的执行阶段。

- 抽出 resolveChatAgent(conversation) 作为唯一解析入口(会话/Agent 绑定优先、
  全局兜底),send 预检查与后台执行都用它,消除分叉。
- 提示按实际状态细分(chatUnavailableReason):无任何配置→提示添加;有配置但
  未激活→提示激活或为本会话指定一个;而非一律「未配置」。

相邻的 StartTriggeredRun 仍用全局 gate(触发器场景,本次不动)。

验证: 新增两个测试——三态提示区分、会话所选配置在全局无激活时仍能解析出
ChatAgent(回归防护);连本地 PG 实跑通过,server 全量无回归。
 2026-08-24 11:55:50 -04:00
Autumn-27 412a993c25 feat(agent): get_worker_trace 的 step_ids 超限改为降级返回而非报错 
原先 step_ids 超过 5 个直接报错,逼 Agent 重新组织调用、白跑一轮。改为优雅
降级:先去重、剔除非法 id,超出 5 个则返回前 5 步的完整内容,并在结果里用
returned_step_ids / omitted_step_ids / notice 告知本次取了哪些、还有哪些没取,
并提示「若已足够则无需再取剩余」。Agent 立刻拿到数据,是否再取由它自行判断。

保留数量上限的原因不变:detail 是完整原文、不截断,上限用于兜住单个 tool
result 的大小。get_task_worker_trace 经 delegateToTask 复用同一实现,一并生效;
两处工具描述同步更新。

验证: 新增 TestGetWorkerTraceStepIDsDegradeGracefully(含去重/非法 id/前5/
omitted/notice/在限内不加提示),连本地 PG 实跑通过;agent 全量无回归。
 2026-08-24 11:35:49 -04:00
Autumn-27 6a8e13fcbd feat(tasks): 新建任务的分类选择器改为可搜索、可即时新建 
原先是普通下拉,只能从已有分类里选。改成可搜索的输入框(复用 base-ui
Combobox):输入即过滤已有分类,库里没有的名称回车(或点下拉里的「创建」)会
即时调 createTaskCategory 新建并选中,选中项以可移除的 tag 展示。仍限单个
分类——multiple 仅用于 chip 视觉,onValueChange 只保留最新选中的一个。

- 新建的分类要等父层重新拉取才回流到 categories,组件内先本地留一份
  (localExtra),避免选中 chip 和下拉在这段窗口显示成「未知分类」。
- 回车创建仅在完全无匹配时触发,有匹配项时保留 base-ui 的「回车选中高亮项」;
  精确同名已存在则直接选中不重复创建。
- 新建成功通过 onCategoriesChanged 通知父层刷新,分类在筛选器等处随即可见。
- 任务列表筛选和批量改分类仍用下拉(选已有分类,无需创建),保持不变。

验证: tsc / biome / next build 均通过。
 2026-08-24 11:24:17 -04:00
Autumn-27 4cf36c7896 fix(tasks): 任务列表改按 id 降序,消除同刻创建任务的抖动 
原先按 created_at 降序排,但没有二级排序键。同一时刻创建的多个任务时间戳
相同,排序不稳定;叠加前端每 10 秒轮询、以及 Manager 用内存 map 存任务
(遍历顺序随机、每次 List 都要重排),这些任务就会在列表里频繁互换位置。

改用 id 降序:id 由 BIGSERIAL 单调递增分配,即插入顺序,唯一且稳定,最新
创建的在最前。db.ListTasks 的 ORDER BY 与 Manager.List 的内存排序同步改。

验证: 新增 TestListTasksOrderByIDDesc 连本地 PG 实跑通过;db/server 全量
无新增失败(仅剩既有的 TestCompanyScopeInvalid)。
 2026-08-24 11:08:10 -04:00
Autumn-27 dfbbb33069 fix(assets): ip 字段拒收主机名,并告诉调用方该怎么改 
上一次修复让非法 ip 不再打挂企业归属重算,但脏数据仍在持续产生。这次从源头
拦住:assets.ip 会被转成 inet 参与网段归属,存主机名的资产对所有 IP/CIDR
范围规则都是隐形的。

- db 层新增 ValidateAssetIP + ErrAssetIPInvalid,在 UpsertIP /
  UpsertHTTPService / UpsertOtherService / UpsertEndpoint 四个入口校验。
  放在 db 层是因为 Agent 工具和资产 API 都经由它们,不必写两遍;内部调用方
  (enrich 的解析结果、task_assets 的 ParseCIDR 输出、RecordValue 已 ParseIP
  过滤的分支)传的本就是合法地址,不受影响。
- 错误信息给的是改法而不只是「非法」:带上收到的原值,并指出主机名应改用
  type=subdomain 填 domain,或先解析 A/AAAA 记录再填 ip。insert_assets 的
  错误是逐条返回的({index, error}),同批其余资产照常入库,Agent 拿到后能
  定位到具体那条并在下一轮自行修正。
- 同步收紧 insert_assets 的工具描述与 ip 字段说明,在提示层先挡一道。
- 空 ip 仍然合法:service / endpoint 的 ip 是可选字段。

验证: 新增 db 层四类型拒收测试与 agent 层「一批混入一条非法、其余照常入库」
测试,均连 PG 实跑通过;干净库 go test -p 1 ./... 无新增失败(仅剩既有的
TestCompanyScopeInvalid)。
 2026-08-24 10:32:10 -04:00
Autumn-27 9e98407528 fix(assets): 企业归属重算不再被单行非法 ip 打挂,并明确告知是哪些资产 
assets.ip 是自由文本(Agent 的 insert_assets 和资产 API 都可能写进主机名),
而 db/companies.go 的 IP/CIDR 归属匹配裸转 a.ip::inet。只要表里有一行不是
合法 IP,PostgreSQL 就抛 22P02 中断整条语句,连带同事务的新增/修改企业资产
范围、删除企业全部失败回滚。这个裸转从项目初始化提交就存在。

- schema.sql 新增 try_inet(text)：非法值返回 NULL 而不是抛错。没用
  pg_input_is_valid 是因为那要 PG16+,这里要兼容更老的存量库。
- 四处 IP/CIDR 匹配统一改用 try_inet。原先 task_scope.go 和
  task_assets_context.go 用的正则 a.ip !~ '[^0-9a-fA-F:.]' 只检查字符集,
  abc.def 这类全 hex 字母的主机名照样漏过去后炸,一并换掉。
- 跳过不能是静默的:重算会统计并抽样列出这些资产(id + 取值),说明它们不会
  被网段规则归属。信息通过企业范围接口新增的 warnings 字段返回并在前端以
  长停留 toast 展示,同时无条件写入服务端日志,覆盖没有前端响应的路径
  (删除企业、scopesentry 同步、Agent 写入)。
- warnings 与 errors 分开:errors 仍只表示本次提交里不合法的行,既有数据
  问题不该被记到用户这次输入头上。

验证: 干净库上 go test -p 1 ./... 仅剩 1 个既有失败(TestCompanyScopeInvalid,
与本改动无关,stash 后同样失败);改动前在含真实数据的库上有 14 个失败,现已
全部通过。go build / vet / gofmt / tsc / biome 均通过。
 2026-08-24 10:16:17 -04:00
Autumn-27 fea78b2d6f feat(tasks): 任务列表支持批量修改分类 
勾选多个任务后可一次性移动到目标分类,或选「未分类」把它们移出当前分类。

- db: 新增 SetTasksCategory,在单个事务里校验分类存在性并 UPDATE ... WHERE
  id=ANY(...),返回真正被更新的 id 和刷新后的分类(含 task_count)。分类检查
  放在事务内,避免并发删除把 UPDATE 变成外键冲突。单批上限 100。
- server: 新增 POST /api/tasks/category/batch。写入原子,响应里的逐任务失败
  只可能是勾选后又被删掉的任务;顺带把 category_id 的解析(必填但可为 null)
  抽成 parseCategoryIDField 与单任务接口共用。
- server: 把批量 id 的 trim/归一/去重逻辑从 controlTasksBatch 抽成
  normalizeBatchTaskIDs,两个批量端点共用同一套重复判定。
- manager: SetTasksCategory 在 taskStateMu 内完成 DB 写入与运行中任务 DTO
  刷新,防止与单任务更新交错后留下过期的 category_name。
- web: 选中工具栏新增「修改分类」对话框(需确认目标,避免误点批量改动);
  「未分类」哨兵值统一提取为 UNCATEGORIZED_VALUE。

验证: go build / vet / gofmt、db 与 server 新增测试连本地 PG 实跑通过、
tsc --noEmit、biome check、next build 均通过。
 2026-08-24 09:16:44 -04:00
pphua 43cd6b072c docs: align changelog with implemented features 2026-08-24 19:59:55 +08:00
pphua 58f23a2773 同步 2026-08-24 14:14:15 +08:00