Backup/ARTEX
1
0
Fork 0
mirror of https://github.com/BaaRai/ARTEX.git synced 2026-11-15 04:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity
574 Commits 132 Branches 4 Tags
feat/php2shell-skill
Commit Graph
50 Commits
Author SHA1 Message Date
BaaRai e233c02314 Translate all Chinese text to English 
Comments, doc comments, UI labels, log and error messages, LLM prompt
strings, markdown docs, test data and assertions. Identifiers, enum
keys, routes, placeholders and code structure are unchanged.

Notes:
- docs/漏洞流量证据.md renamed to docs/vulnerability-traffic-evidence.md
- tests that exercised CJK specific handling (GBK zip names, Chinese
  full text search) now use ASCII equivalents; go build passes and the
  test suite matches the pre translation baseline (remaining failures
  need a PostgreSQL DSN and fail identically on the original)
- frontend mention syntax now uses English kinds (finding, asset, ...)
  matching the backend, chat mentions tests pass
 2026-10-08 23:14:34 +02:00
Autumn-27 d1196853dc docs(changelog): 定版 0.3.15 2026-10-07 08:54:02 -04:00
luckoneandClaude Code 765c0e99e3 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 <noreply@anthropic.com>
 2026-09-30 16:25:06 +08:00
luckoneandClaude Code 4eb5311998 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 <noreply@anthropic.com>
 2026-09-30 16:25:06 +08:00
Autumn-27 587ef91f68 fix(findings): 「按资产」视图资产列表溢出时补回滚动条 
左侧资产树的滚动容器靠 height:100% 取高，但外层卡片只给了 max-height
没有确定高度，百分比高度解析失败，资产多时列表撑破卡片或被截断且无法
滚动。改为把高度上限直接放到资产树的原生滚动容器上（overflow-y-auto +
max-h，随窗口自适应），资产少随内容收缩、资产多封顶并出滚动条。

Closes #170
 2026-09-30 04:16:43 -04:00
Autumn-27 5825b3f80c 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 eb347d5965 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 e50f5a3083 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
榆木 6b146d6c1b 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 68ebf51698 docs(changelog): 定版 0.3.14 2026-09-24 13:35:48 -04:00
Autumn b926b7a5d1 Update CHANGELOG.md 2026-09-19 23:37:57 +08:00
Autumn-27 d6a873f075 docs(changelog): 版本号改为 0.3.13 2026-09-19 11:23:33 -04:00
Autumn-27 f9990dd7be docs(changelog): 定版 0.4.0 2026-09-19 11:20:03 -04:00
Autumn-27 420530caa5 docs(changelog): 定版 0.3.12 2026-09-17 13:17:39 -04:00
Autumn-27 84ec5b2217 fix(changelog): 移除历史遗留的裸 NUL 字节，恢复文本格式 
0.3.10 的 /btw 条目把 NUL 字符本身字面写进了反引号，导致整个
CHANGELOG.md 被 git 和编辑器判为二进制/显示乱码。改为可读的 \u0000。
 2026-09-15 12:39:49 -04:00
Autumn-27 b83e9711e5 docs(changelog): 定版 0.3.11 2026-09-15 12:37:19 -04:00
Autumn-27 8157d475f0 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 ac02283c94 docs(changelog): 定版 0.3.10 2026-09-13 12:37:37 -04:00
Autumn-27 8746af82e5 docs(changelog): 补齐 Unreleased —— worker 回看工具/node_detail/add_hint 播报、回看工具补绑修复、/btw NUL 修复、合并触发去重 2026-09-13 12:22:21 -04:00
Autumn-27 c4297854c6 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 0961f347b4 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 1f759bea3d 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 d8761d1c62 docs(changelog): 定版 0.3.9 2026-09-11 12:59:32 -04:00
Autumn-27 421eb78ddd docs(changelog): 补齐 0.3.8 以来的变更条目 2026-09-11 12:45:23 -04:00
Autumn-27 b42ec8aeed 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 70747230ac 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 77b2002039 docs(changelog): 发布 0.3.8 2026-09-09 14:10:07 -04:00
Autumn-27 bcded623c1 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 76bdf4c3d2 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 d09b545495 docs(changelog): 发布 0.3.7 2026-08-31 12:24:38 -04:00
Autumn-27 e241ded1d1 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 3730e1411d 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 1f90ba13e7 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 24bbe497dd feat(findings): 发现页新增平铺大表视图并设为默认 
分组视图要逐个任务展开才看得到漏洞，跨任务扫列表时反而绕路。新增
「全部发现」平铺视图作为默认视图，与「按任务分组」通过页头 Tab 切换。

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

终态任务保存时不再重开额度阻塞意图:那些意图会从 blocked 挪到 open,既没有
worker 执行、也不再满足「重跑意图」的可重跑条件,反而变成死状态。终态任务想
继续跑仍走重跑意图/新增目标,由它们把任务重新 admit 回运行态。
 2026-08-31 09:26:33 -04:00
Autumn-27 311b29d303 docs(changelog): 发布 0.3.6 2026-08-27 12:34:51 -04:00
Autumn-27 82c63dece0 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 ea6f1af53d docs(changelog): 发布 0.3.5 2026-08-25 12:22:06 -04:00
Autumn-27 67b7ea59eb 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 b04dbb9b6a 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 0918fa079f docs(changelog): 发布 0.3.4 2026-08-24 12:41:47 -04:00
Autumn-27 7c328764af 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 01022c679f 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 6dd8897f88 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 6a14b606ed 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 56538bc3ef 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 43ff830d91 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 a4e20b9033 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 8f0e13ffbc docs: align changelog with implemented features 2026-08-24 19:59:55 +08:00
pphua 259a0ae965 同步 2026-08-24 14:14:15 +08:00