feat: pending-finish proposals and QQ image input

Proposal semantics: worker results no longer distinguish success/fail;
only an explicit finish settles a pending proposal. Pending owner input
follows up by resuming the original worker session. Dirty pending blocks
start_next globally; clean pending only blocks its owner.

QQ adapter now downloads image attachments and passes them as ACP image
content blocks; video/file attachments degrade to link text.

README.md

@@ -13,7 +13,7 @@ Config v3 只支持以下边界：
 - 一份运行配置对应一个固定 Bot 身份。
 - 一个 Bot 只有一个 workspace、persona、ACP agent、skill 列表和 permission policy。
 - 每个 chat 一个无工具 Assistant 会话；它只对话、创建 Proposal 并解释 Worker 反馈，自己从不执行。
-- 同一时刻全实例只有一个 Worker 在 `bot.workspace` 执行一个已确认 Proposal；success 与 failure 都需要用户确认后才收尾，系统不会自动开始下一个 Proposal。
+- 同一时刻全实例只有一个 Worker 在 `bot.workspace` 执行一个已确认 Proposal；Worker 每轮只交回 result（pending），由用户决定 finish 结束还是继续说要求继续，系统不会自动开始下一个 Proposal。
 - 一个实例只绑定一个平台；多平台使用多个实例。
 - 不再有 `roles[]`、`defaultRole`、`backends[]`、动态 `/role` 切换、单主任务/近似 BTW 或 Config v1/v2 迁移。
 - `configVersion` 非 `3` 会明确失败，旧 state v1/v2 也不会自动改写。
@@ -173,6 +173,8 @@ QQ websocket 示例：
 
 正式 Bot 应通过 `gateway.policy.allowedUsers` / `allowedChats` 限制入口。QQ 群 chat ID 为 `group:<group_openid>`；用户 ID 按 QQ 官方语义取值：群聊作者用 `member_openid`，C2C 私聊作者用 `user_openid`。
 
+QQ 入站附件：`image/*` 附件会被下载（每条消息最多 3 张、单张超过 5MB 跳过、10 秒下载超时、缺 scheme 的 URL 自动补 `https:`）并转成 base64 随消息传给 Agent；agent 声明 `promptCapabilities.image` 时作为 ACP image content block 发送，否则降级为文本说明。视频/文件等非图片附件不下载，仅以 `[视频] <url>` / `[文件] <url>` 文本拼进消息，交给模型自由使用；纯图片消息使用占位文本「（发来一张图片）」。日志只记录附件类型/大小/数量，不记录 URL 全文或 base64。
+
 ### ACP 生命周期
 
 默认 `runtime.acp.promptTimeoutMs` 是 `14400000`（4 小时），适合长构建/部署任务。其他默认值：
@@ -190,16 +192,17 @@ QQ websocket 示例：
 
 运行链路是三层：
 
-- **Assistant**：每个 conversation（chat + user）一个无工具 ACP 会话，只与用户对话；同群不同用户的会话互相隔离。它把用户意图整理成 Proposal（title、goal、steps），并解释 Worker 的反馈。Assistant 每条回复必须以隐藏 `GORI_ASSISTANT_ACTION_V1` envelope 结尾（`reply` + `actions`），action 只有 `create_proposal`、`confirm`、`start_next`、`cancel`、`stop`；格式错误只修复一次。
-- **Proposal**：一份待确认的工作单，owner 是 chat + 发起用户；只有发起人本人可以 confirm/stop/cancel/list 它，`start_next` 也只启动发起人自己的 queued Proposal。状态流为 `proposed → queued → working → awaiting_user_confirmation → completed | failed | cancelled`。`proposed` 只有用户确认后才进入 `queued`；空闲时最早确认的 queued Proposal 才开始执行。
-- **Worker**：同一时刻全实例只有一个，在 `bot.workspace` 用 `bot.permissions` policy 执行一个已确认 Proposal。每轮必须以隐藏 `GORI_WORKER_RESULT_V1` envelope 收尾：`SUCCESS`、`FAILED` 或 `NEEDS_CONFIRMATION`（可带 `question`、`nextStep`、`dirty`）。
+- **Assistant**：每个 conversation（chat + user）一个无工具 ACP 会话，只与用户对话；同群不同用户的会话互相隔离。它把用户意图整理成 Proposal（title、goal、steps），并解释 Worker 的反馈。Assistant 每条回复必须以隐藏 `GORI_ASSISTANT_ACTION_V2` envelope 结尾（`reply` + `actions`），action 只有 `create_proposal`、`confirm`、`adjust_proposal`、`follow_up`、`finish`、`start_next`、`cancel`、`stop`；格式错误只修复一次。
+- **Proposal**：一份工作单，owner 是 chat + 发起用户；只有发起人本人可以 confirm/adjust/follow_up/finish/stop/cancel/list 它，`start_next` 也只启动发起人自己的 queued Proposal。状态流为 `proposed → queued → working → pending → finished`。`proposed` 只有用户确认后才进入 `queued`；`pending` 就是「等用户决定」，不再区分 success/failure；只有 `finish` 把 pending 落定为 `finished(done)`，`cancel` 落定为 `finished(cancelled)`。
+- **Worker**：同一时刻全实例只有一个，在 `bot.workspace` 用 `bot.permissions` policy 执行一个已确认 Proposal。每轮必须以隐藏 `GORI_WORKER_RESULT_V2` envelope 收尾：`PENDING`（`summary` 必填，可带 `question`、`workspaceDirty`），不区分成功/失败，只把结果交给用户。
 
 确认语义是刻意的：
 
-- `SUCCESS` 和 `FAILED` 都进入 `awaiting_user_confirmation`，都需要用户确认后才分别落定为 `completed` / `failed`；对 failed Proposal 用 answer `retry` 确认可以重试。
-- 系统**不会**在一个 Proposal 完成后自动开始下一个；只有用户确认新 Proposal 或 Assistant 发出 `start_next` 才会推进队列。
-- Worker 执行中遇到 dirty 或意外目标时报告 `NEEDS_CONFIRMATION`，这是正常的执行中确认点，不是 blocked 终态；用户回答后同一 Worker 继续执行。
-- `stop` 对 `awaiting_user_confirmation` 的 Proposal 有兜底语义：pending success 落定为 `completed`，pending failure 落定为 `failed`，pending step 落定为 `cancelled`（并清理 worker 状态）；不会自动开始下一个 Proposal。
+- Worker 落定后 Proposal 进入 `pending`，记录 `summary`、可选 `question` 和 `workspaceDirty`；用户说 `finish`（可带 note）落定为 `finished(done)`，或直接继续说要求：Assistant 发 `follow_up`，runtime 优先 resume 原 worker native session 继续（resume 失败则带 Proposal 上下文新起 session），用户输入的图片附件也随 prompt 给 Worker。
+- 系统**不会**在一个 Proposal 落定后自动开始下一个；只有用户确认新 Proposal 或 Assistant 发出 `start_next` 才会推进队列。
+- 阻塞规则：任何 `working` 全局拒绝 `start_next`/`follow_up`；owner 自己有 `pending` 时拒绝该 owner 的 `start_next`（提示先 finish 或 follow_up）；任何 `workspaceDirty` 的 `pending` 全局拒绝 `start_next`（提示先处理 dirty 工作区）。非 dirty 的 pending 不挡其他用户。
+- `stop` 只对 `working` 生效：停掉 Worker（含进程组清理）并把 Proposal 标记为 `pending`（summary 为「被用户中止」、`workspaceDirty: true`）。
+- Assistant 有 pending 时每轮 prompt 注入 pending card（id/title/summary/question）；Assistant 回复没提到 pending 时，runtime 在回复末尾追加一条人话兜底提醒。
 - Gateway 不再有 15/60/180/480 秒的固定时间提醒；Worker 落定结果时通过 Assistant 生成一条事件说明，由平台 adapter 作为**新消息**发给 owner chat（QQ 同样是新消息，不引用原消息）。
 
 Assistant 隔离与旧 side Session 一致且更严格：
@@ -208,9 +211,9 @@ Assistant 隔离与旧 side Session 一致且更严格：
 - 项目级 `agent.md` override 显式设置 `tools: []` 与 `subagents: []`；ACP 传入空 `mcpServers`；Assistant 只接受 Kimi Code ACP，并强制 permission deny 作为附加层。
 - 除非 `bot.agent.env` 已显式设置，Assistant 进程的 `KIMI_CODE_HOME` 指向实例私有 `state/kimi/assistant/`（`0700`），与真实用户配置隔离。
 - 一旦出现 tool update 或 permission request，即视为隔离违约：当前 turn fail closed、终止整个 ACP 进程组并删除 binding。Worker 的 cancel、timeout、crash 同样按进程组清理工具后代；bootstrap 禁止 `setsid`、`nohup`、detached/daemon/background 遗留进程，主动脱离进程组仍属于无 Bubblewrap/cgroup 方案的信任边界。
-- 每个 ACP worker 以独立进程组运行并携带随机 `GORI_AGENT_WORKER_TOKEN`；runner 重启时会把仍处于 `working` 的 Proposal 校验 token 后清理旧进程组，并标记为 failed（`worker_lost`），交给用户确认或重试。
+- 每个 ACP worker 以独立进程组运行并携带随机 `GORI_AGENT_WORKER_TOKEN`；runner 重启时会把仍处于 `working` 的 Proposal 校验 token 后清理旧进程组，并标记为 `pending`（`worker_lost`、`workspaceDirty: true`），交给用户 finish 或 follow_up。
 
-state v3（`acp-sessions.json`）只保存 header（version 3、`botId`、platform）和 Assistant binding：conversation key（chat + user）、agent ID、native session ID、assistant workspace、Bot fingerprint 与时间戳。`proposals.json`（version 1）保存 Proposal 记录：title/goal/steps、owner chat、发起用户、状态、pending（`step | success | failure`）、worker native session ID 与进程组 PGID/token、时间戳；不保存消息正文。两个 store 都做单 writer lock、串行持久化、临时文件 + fsync + 原子 rename；version 或 identity 不匹配（含旧 state v1/v2）一律拒绝启动并保留原文件，不清空、不迁移。
+state v3（`acp-sessions.json`）只保存 header（version 3、`botId`、platform）和 Assistant binding：conversation key（chat + user）、agent ID、native session ID、assistant workspace、Bot fingerprint 与时间戳。`proposals.json`（version 2）保存 Proposal 记录：title/goal/steps、owner chat、发起用户、状态（`proposed | queued | working | pending | finished`）、pending（`summary`/`question?`/`workspaceDirty?`/`receivedAt`）、finished 的 `finishKind`（`done | cancelled`）/`finishNote?`、worker native session ID 与进程组 PGID/token、时间戳；不保存消息正文。两个 store 都做单 writer lock、串行持久化、临时文件 + fsync + 原子 rename；version 或 identity 不匹配（含旧 state v1/v2）一律拒绝启动并保留原文件，不清空。唯一例外是 proposals v1：打开时先在同目录写 `proposals.json.v1-<timestamp>.bak`（0600）备份，再按固定映射迁移为 v2（SUCCESS/FAILED/NEEDS_CONFIRMATION → pending，completed/failed → finished(done)，cancelled → finished(cancelled)）。
 
 Bot fingerprint 包含 bootstrap schema version、Bot ID、workspace、persona、assistantPersona、agent 定义、permission policy 和 skill 路径/内容 hash；fingerprint 或 agent 不匹配的 binding 会被丢弃并重建 Assistant 会话。失败 prompt 不会自动重放，因为工具操作可能已有副作用。
 
@@ -225,18 +228,20 @@ Bot fingerprint 包含 bootstrap schema version、Bot ID、workspace、persona
 /status
 /list
 /confirm
+/finish
 /stop
 /cancel
 ```
 
 - `/help`：显示自然语言使用说明和兜底命令列表。
-- `/status`：显示固定 Bot、agent、workspace、Assistant 会话数、各状态 Proposal 计数、Worker 是否在执行及当前用户是否 owner；另含当前用户维度（`myQueuedProposals`、`myPendingConfirmations`、`schedulerState`、`blockedReason`、`nextAction`，他人 Proposal 只给脱敏原因，不暴露 title/id）与当前 chat 的事件投递状态（`lastEventDelivery`、`lastEventError`、`lastEventAt`）。
-- `/list`：列出当前 chat 中当前用户拥有的 Proposal（id、状态、title）。
-- `/confirm`：确认当前用户最近待确认的 Proposal（`proposed` 进入队列，`awaiting_user_confirmation` 落定完成/失败或带着回答继续）。
-- `/stop`：停止当前用户正在执行的 Worker 并将其 Proposal 标记为 cancelled；对等待确认的 Proposal 按 pending 类型兜底落定（success→completed、failure→failed、step→cancelled）；只有 Proposal 发起人可用。
-- `/cancel`：取消当前用户最近未开始的 Proposal（`proposed` / `queued`）。
+- `/status`：显示固定 Bot、agent、workspace、Assistant 会话数、各状态 Proposal 计数、Worker 是否在执行及当前用户是否 owner；另含当前用户维度（`myQueuedProposals`、`myPendingProposals`、`schedulerState`、`blockedReason`、`nextAction`，他人 Proposal 只给脱敏原因，不暴露 title/id）与当前 chat 的事件投递状态（`lastEventDelivery`、`lastEventError`、`lastEventAt`）。
+- `/list`：当前用户拥有的 Proposal 面板，按 待确认（pending 优先）→ 进行中 → 排队中 → 未确认（proposed）→ 最近结束 排列。
+- `/confirm`：确认当前用户最近待确认的 `proposed` Proposal（进入队列）。
+- `/finish`：把当前用户最近的 `pending` Proposal 落定为 `finished(done)`。
+- `/stop`：停止当前用户正在执行的 Worker，Proposal 转为 `pending`（被用户中止、dirty）；只有 Proposal 发起人可用。
+- `/cancel`：取消当前用户最近的 `proposed` / `queued` / `pending` Proposal，落定为 `finished(cancelled)`。
 
-日常操作以自然语言为主，Assistant 会自己生成 confirm/cancel/stop 等 action；这些命令是旁路 Assistant 的兜底入口。未识别的 `/` 命令按普通消息交给 Assistant。
+日常操作以自然语言为主，Assistant 会自己生成 confirm/follow_up/finish/cancel/stop 等 action；这些命令是旁路 Assistant 的兜底入口。未识别的 `/` 命令按普通消息交给 Assistant。
 
 Gateway 不维护普通消息队列或 per-chat task lock，也不再有固定时间（15/60/180/480 秒）的处理中提醒；每条 allowlist 普通消息按 conversation（chat + user）串行交给 AssistantManager。Worker 落定结果（成功、失败或提问）时，AssistantManager 生成事件文案并经 `Gateway.sendEvent` 发出。QQ 无主动消息权限（HTTP 400 / code 40034105）时事件走被动回复窗口：`sendEvent` 引用该 chat 最近一次入站消息（`msg_id` + 递增 `msg_seq`），群聊窗口 5 分钟（按 4.5 分钟保守判定）、C2C 窗口 60 分钟（按 55 分钟保守判定）；超过窗口或没有 messageId 时不发主动消息，记录为 skipped 并在该 chat 下次入站时补发。发送失败只记录不含消息正文或 provider 错误详情的安全日志（仅 HTTP status / QQ code），不影响任务或后续发送。
 
@@ -274,6 +279,6 @@ git diff --check
 bash -n install.sh gori-agent.sh bin/gori-agent
 ```
 
-测试使用 Node `node:test` + `tsx` 和本地 fake ACP 子进程，覆盖 Config v3、permission、Assistant/Worker envelope 协议、Proposal 状态流与确认语义、timeout/cancel、worker_lost 恢复、state v3 identity、workspace 重叠扫描、Gateway 无队列语义、QQ normalization 和单平台 route。真实 Kimi ACP 的执行层兼容性可用 `node scripts/side-session-spike.mjs` 复验（assistant no-tool spike：私有 cwd 在项目外、`mcpServers: []`、toolUpdates/permissionRequests/fsRequests 全为 0、`GORI_ASSISTANT_ACTION_V1` envelope 可解析）；该脚本使用临时 cwd/profile，不读取或输出真实配置、凭据、日志正文。
+测试使用 Node `node:test` + `tsx` 和本地 fake ACP 子进程，覆盖 Config v3、permission、Assistant/Worker envelope 协议（V2）、Proposal 状态流与 pending 语义、proposals v1→v2 迁移、timeout/cancel、worker_lost 恢复、state v3 identity、workspace 重叠扫描、Gateway 无队列语义、QQ normalization 与图片附件、ACP prompt content blocks 和单平台 route。真实 Kimi ACP 的执行层兼容性可用 `node scripts/side-session-spike.mjs` 复验（assistant no-tool spike：私有 cwd 在项目外、`mcpServers: []`、toolUpdates/permissionRequests/fsRequests 全为 0、`GORI_ASSISTANT_ACTION_V2` envelope 可解析）；图片输入链路可用 `node scripts/acp-image-capability-spike.mjs` 与 `node scripts/acp-image-e2e-spike.mjs` 复验；这些脚本使用临时 cwd/profile，不读取或输出真实配置、凭据、日志正文。
 
 `src/agents/*` 与 `src/core/session-store.ts` 仅为 legacy compatibility/reference，不在当前运行链路。运行时没有单轮 CLI fallback。