dingtalk-dsh-assistant 0.5.9 → 0.5.11

package/CHANGELOG.md

@@ -2,6 +2,42 @@
 
 本文件记录 `dingtalk-dsh-assistant` 每个正式版本的用户可见变化。版本号遵循[语义化版本](https://semver.org/lang/zh-CN/)，日期使用 `YYYY-MM-DD`。
 
+## [未发布]
+
+## [0.5.11] - 2026-09-02
+
+### 新增
+
+- Task 持久化完整来源消息与参与人历史；后续通知按当前目标、消息上下文和参与人语义选择接收者，不再只依赖最初提出人。
+
+### 变更
+
+- 叶子会话在第一现场自主闭环适用 Skill，移除专用学习信号转发；常驻主会话不再承担重复判断或沉淀。
+- 任务卡移除执行轮次耗时区块，诊断数据继续由 `/state/task-timings` 提供。
+- 完成验收与检查点评审统一作为主会话内部上下文，并缩短 Task 串行锁持有时间，避免模型评审阻塞其他任务。
+
+### 修复
+
+- 检查点只允许逐项推进，任务仍有剩余项时禁止完成；终结工具结果晚到时可按调用 ID 正确闭合，真实缺失结果仍会报警。
+- 群消息 Decision 改为按 DSH step 结构化提交；实时 Steer 打断收口时基于最新上下文重新判断，常驻回复提交前也会再次处理新 Steer。
+- 恢复 DWS 入站 bridge 的断线重连、全量回补、慢回补调度和恢复水位，避免长时间运行后漏收消息或重复扫描。
+- 修复群消息回复提交与引用消息回读链路；非空引用回复可实时处理人工授权，等待人工介入的任务保持阻塞语义一致。
+
+## [0.5.10] - 2026-08-31
+
+### 变更
+
+- Task 创建统一校验简短标题、明确目标、可核验验收标准、来源消息和提出人；验收门禁保持任务类型无关。
+- 任务卡片按当前执行轮次拆分展示总墙钟、排队、运行、等待、可配对工具时间和其他运行时间；历史数据不足时明确标记为估算。
+- 群消息取消静默聚合窗口，改为持久化后逐条、零延迟 `steer`：上一条尚未处理完成时，新消息直接插入当前 Turn 的下一 step 共同处理，不排队到下一 Turn。每条输入只携带事实，稳定协议仅保留在 Resident 系统提示词；单次结构化 JSON 通过 `actions` 支持多个 Task。结构化判断按 coordinator 消息 ID 读取对应回合结果，避免把普通插话回复误判为 JSON 后重复判断。
+- 常驻群聊主会话不再暴露 Goal 工具及其提示；叶子任务仍使用 DSH Goal 管理执行、阻塞、恢复和完成。
+
+### 修复
+
+- 区分插话前投递失败与已插话后的结构化判断失败；DWS 重复事件不再把同一群消息再次送入 Agent。
+- 结构化判断纠错明确使用 `actions` 顶层契约，避免模型重复输出旧的 `kind` 结构。
+- 本地 profile 安装强制刷新当前源码的 `file:` 依赖，并隔离根 workspace，避免部署继续使用旧 pnpm 缓存副本。
+
 ## [0.5.9] - 2026-08-31
 
 ### 修复
@@ -127,6 +163,8 @@
 - assistant、observer 与发行包统一使用同一个产品版本号。
 - Node.js 最低版本与实际 zstd Runtime 要求一致，调整为 24。
 
+[0.5.11]: https://github.com/HiQ-AI/dingtalk-dsh-assistant/releases/tag/v0.5.11
+[0.5.10]: https://github.com/HiQ-AI/dingtalk-dsh-assistant/releases/tag/v0.5.10
 [0.5.9]: https://github.com/HiQ-AI/dingtalk-dsh-assistant/releases/tag/v0.5.9
 [0.5.8]: https://github.com/HiQ-AI/dingtalk-dsh-assistant/releases/tag/v0.5.8
 [0.5.7]: https://github.com/HiQ-AI/dingtalk-dsh-assistant/releases/tag/v0.5.7

package/README.md

@@ -31,10 +31,10 @@
 - `systemPrompt.section`：向主会话注入群名称、群 ID、群职责与决策协议；向叶子会话注入任务流程和证据要求。
 - Agent Registry 与原生 descriptor：在 DSH Web 中展示并打开常驻会话、叶子对话和轨迹。
 - 默认模型、推理深度与权限 preset：由 DSH 原生服务保存和应用。
-- storage domain：持久化群订阅、消息、Task、可靠投递、授权申请和告警。
+- storage domain：持久化群订阅、消息、Task、可靠投递、人工介入事项和告警。
 - attachment service：将钉钉图片作为 DSH 原生多模态附件传入会话。
 
-插件只补充钉钉渠道和群聊工作流特有的能力：DWS 订阅与补拉、消息去重排序、任务准入与关联、可靠 outbox、授权审批、任务看板和运行告警。
+插件只补充钉钉渠道和群聊工作流特有的能力：DWS 订阅与补拉、消息去重排序、任务准入与关联、可靠 outbox、人工介入、任务看板和运行告警。
 
 ```text
 DWS 群消息
@@ -43,15 +43,15 @@ DWS 群消息
   → DSH leaf Session + Goal（独立执行）
   → 主 Session（组织结果）
   → outbox + DWS 回读确认
-  → 原群引用回复并 @任务提出人
+  → 原群引用回复并 @模型从任务历史选出的相关参与人
 ```
 
 不依赖 Agent Studio，也不要再并行启动另一套会话或任务 Runtime。
 
 ## 包结构
 
-- `packages/dingtalk-dsh-assistant`：核心业务插件。负责 DWS 接入、群与 Session 绑定、消息处理、Task 调度、授权审批、可靠回复和配置页面。
-- `packages/dingtalk-dsh-observer`：DSH Web 展示扩展。提供群聊会话、任务看板、归档任务、授权审批和告警页面。
+- `packages/dingtalk-dsh-assistant`：核心业务插件。负责 DWS 接入、群与 Session 绑定、消息处理、Task 调度、阻塞时的人工介入、可靠回复和配置页面。
+- `packages/dingtalk-dsh-observer`：DSH Web 展示扩展。提供群聊会话、任务看板、归档任务、人工介入和告警页面。
 - `.dsh/profiles/resident`：resident Runtime 的参考 profile 与 Cordis patch。
 - `.dsh/profiles/web`：Web contribution 的参考 profile。
 - `docs/spec`：关键状态机和工作流设计说明。
@@ -174,7 +174,7 @@ Set-Location D:\path\to\dingtalk-dsh-assistant
 pwsh -NoProfile -File .\scripts\start-web.ps1
 ```
 
-默认 Web 地址由 DSH 提供；resident 插件监听 `127.0.0.1:18998`。`GET http://127.0.0.1:18998/health` 可检查插件 Runtime 状态。
+默认 Web 地址由 DSH 提供；resident 插件监听 `127.0.0.1:18998`。通过 `GET http://127.0.0.1:18998/health` 和 `GET http://127.0.0.1:18998/state/dws-bridge` 分别检查 Runtime 与真实 DWS bridge 状态；完整判定和排障步骤见[安装手册](docs/manual/install-and-configure-dsh-web.md)。
 
 `scripts/start-web.ps1` 使用当前用户的 `%USERPROFILE%\.dsh` 作为默认 `DSH_HOME`；若需要隔离 profile，可在启动前显式设置 `DSH_HOME`。脚本从当前项目根启动，并自动发现 `PATH` 中的 Node.js 和全局安装的 DSH。
 
@@ -209,7 +209,13 @@ dws:
 
 每个群唯一绑定一个 resident Session。群名称、群 ID、职责和稳定决策协议通过 DSH `systemPrompt.section` 注入。消息明确指向已配置的 Agent 名称/别名、使用 `cc:`，或明确确认此前“是否需要我处理”的询问，并形成职责范围内的可验证目标时，主会话可以创建 Task；未明确指名但判断事项应形成任务时，主会话先在群里询问“这个事项是否需要我处理？”，收到肯定答复后再结合原消息和后续补充创建。主会话只负责选择 Task 路由；Runtime 使用原始群消息生成来源证据信封交给叶子，主会话生成的根因、完成度、方案优劣或排除性判断不作为叶子事实。
 
-新消息先立即持久化到 Inbox，5 秒窗口不占用同群决策锁；窗口结束后即使 resident 正在运行，也会通过 DSH `steer` 在下一个 step 边界注入。Task 创建、上下文追加和重开仍按群串行收口，避免多条并发插话的结构化决策相互串线。因此“进入 Inbox / 插话”不再等待上一条群消息处理完成，但业务决策落地仍保持确定顺序。
+每条新消息先立即持久化到 Inbox，正常情况下随后零延迟、逐条调用 DSH `steer`；不设置聚合窗口，也不等待上一条消息完成推理。唯一例外是同群已有回复正在从结构化 Decision 提交到可靠 Outbox：新消息会停在 `steer` admission 前，等该回复可靠落库后立即进入下一 step。这个门禁只排序同群的“当前回复提交”和“下一条 Steer”，不阻塞其他群，也不是全局 Task 串行锁。Resident 正在运行时，获准进入的消息会插入当前 Turn 的下一个 step，与本轮已经收到的消息和会话上下文共同处理，而不是排队到下一 Turn。每条 `steer` 只携带消息事实，判断规则和 JSON 契约只存在于 Resident 系统提示词。
+
+`group_decision_submit` 的 submission 中已提交的普通请求天然计入模型的观察集合；顶层 `observedRequestIds` 只需补充模型已经审阅、但本批不提交并准备稍后处理的其他普通 pending 请求，重复列出已提交 ID 仍兼容。影响回复的消息必须与原请求放进同一 submission 并重新生成 Decision；独立且已经完成的事项使用独立 submission。若提交瞬间存在未观察的新 Steer，工具返回无副作用的结构化 `stale` 结果，模型在下一 step 结合 `missingRequestIds` 重生成，不再把预期并发控制显示为工具 Failed。附件缺失拦截形成的提示和关联复核回复使用同一门禁。结构化业务落地仍按群串行收口；单次 Decision 的 `actions` 可同时关联、重开或新建多个 Task，顶层最多生成一条群回复。每个 Task 动作必须用 `sourceMessageIds` 明确列出完整相关消息：可以包含本群已持久化的历史消息，但至少包含一条当前正在处理的消息；同一消息可关联多个 Task，不同 Task 也可选择不同消息集合。
+
+Task 完成和信息阻塞通知也不再从 turn 的最后一段 assistant 文本取值。Runtime 为每次 `[TASK_COORDINATION]` 创建独立回复请求，Resident 必须调用 `group_reply_submit`，并用 `observedRequestIds` 声明生成通知前已审阅的全部普通 pending 请求；漏观察时返回结构化 `stale`，旧候选不提交，并在下一 step 结合新消息重生成，已观察的普通消息仍保留给自己的 Decision。Task 通知还必须从完整消息时间线中结构化提交 `replyToMessageId` 和 `atOpenDingTalkIds`：Resident 按语义选择承接消息和一位或多位相关参与人，Runtime 校验二者都真实属于该 Task，不再固定使用最后触发人。工具只在通知可靠写入 Outbox 后返回。通知生成和提交不占用全局 Task 串行尾链，避免新消息的任务动作与通知相互等待。首次及后续完成通知使用与正常提交一致的稳定结果键，Outbox 写入失败后可由完成通知补偿流程重新发起；Outbox 已落库后的发送监听器异常不会反向否定 Decision。上述门禁保证当前进程内同群事件顺序，不是跨进程事务，也不承诺进程崩溃窗口的 exactly-once。
+
+普通群消息 Decision 产生非空回复时，Runtime 也使用 DWS 原生引用回复：单消息回复引用当前入站消息；多消息合并回复引用本 submission 中最新且具备稳定发送人 ID 的入站消息，并结构化 @ 该发送人。入站消息本身引用的历史消息只作为语义上下文，不会被错误地再次用作出站引用目标。发送人 ID 缺失时安全降级为普通群消息，不猜测引用参数。Outbox 写入只证明可靠待发送；实际投递仍必须通过 DWS 回读正文和引用消息 ID 后才标记为 `sent`。
 
 ### 叶子任务
 
@@ -217,26 +223,30 @@ Task 可设置独立的简短标题用于看板展示；标题与 objective 分
 
 运行看板 Header 的高度和字体规格与 Session 页面一致。各页不再重复显示页面标题和子标题；任务列按 Header 与主内容实际占用计算剩余视口高度，卡片在列内独立滚动，页面本身不会因状态桶高度产生额外补白或纵向滚动。
 
-Runtime 使用 DSH 原生 subagent 和 Goal 创建叶子 Session。主会话不执行具体工作。Task 将简短任务名、当前有效目标和叶子执行用的来源证据信封分开持久化；任务看板和原生子会话展示任务名，叶子 Goal 同时接收当前目标与完整来源证据。来源信封包含消息 ID、发送者、时间、引用 ID、原始正文和附件异常，并明确要求结合当前代码、运行态和工具证据独立核验。Task 正式执行状态为 `running`、`waiting`、`completed`，超过并行上限时进入产品层 `queued`。归档只影响看板展示，不删除 Task、Session、Goal 或历史上下文；已完成或已归档 Task 收到关联上下文时会重新打开原 Task，并复用同一个叶子 Session，但创建独立的新执行轮次和全新 Goal。新轮次会覆盖当前目标、来源消息与发送人、验收标准、阶段任务、开始时间、阻塞和结果；上一轮的 Session、目标、来源、验收、阶段和结果快照进入 `runHistory`，只作为历史参考。后续消息明确扩大或收窄动作范围时，Runtime 在同一 Task 中修订当前有效目标并保留旧目标历史；普通事实补充不会修改目标。每轮重开会把新的群消息与发送人记录为当前触发来源，同时保留历次触发历史；该轮完成通知引用并 @当前触发人。
+Runtime 使用 DSH 原生 subagent 和 Goal 创建叶子 Session。主会话不执行具体工作。Task 创建统一要求简短标题、当前有效目标、至少一条可逐项核验的验收标准、可回溯来源消息和明确提出人；这些门禁与开发、分析、部署等任务类型无关。Task 将任务名、目标和叶子执行用的来源证据信封分开持久化；任务看板和原生子会话展示任务名，叶子 Goal 同时接收当前目标与完整来源证据。结构化 `messageHistory` 按群消息时序保存所有已关联消息的 ID、原文、发送人姓名和稳定 ID、时间、引用关系、执行轮次与关联时间；新增上下文和重开只追加、不覆盖，叶子系统提示词与主会话任务索引都读取这份完整时间线。来源信封包含同一批消息事实和附件异常，并明确要求结合当前代码、运行态和工具证据独立核验。Task 正式执行状态为 `running`、`waiting`、`completed`，超过并行上限时进入产品层 `queued`。归档只影响看板展示，不删除 Task、Session、Goal 或历史上下文；已完成或已归档 Task 收到关联上下文时会重新打开原 Task，并复用同一个叶子 Session，但创建独立的新执行轮次和全新 Goal。新轮次会更新当前目标、兼容来源字段、验收标准、阶段任务、开始时间、阻塞和结果；上一轮快照进入 `runHistory`，完整消息时间线则跨轮持续累积。后续消息明确扩大或收窄动作范围时，Runtime 在同一 Task 中修订当前有效目标并保留旧目标历史；普通事实补充不会修改目标。
+
+群消息进入常驻会话后立即记录为 `steered`，结构化判断成功后转为 `delivered`。如果消息已经插话但结构化判断失败，则记录为 `decision-failed` 并保留错误供排查，DWS 重复事件和增量补拉都不会再次投递该消息；只有插话前失败的 `failed` 消息允许自动重试，避免同一消息重复进入 Agent。
+
+常驻群聊主会话只负责上下文理解和结构化选路，不暴露 `get_goal`、`create_goal`、`update_goal`，也不注入 Goal 工具说明。Task 叶子会话仍由 Runtime 使用 DSH Goal 管理执行、阻塞、恢复与完成。
 
 主会话向运行中或等待中的叶子传递任务上下文、目标修订、真人批复、恢复提示和结果驳回时统一使用 DSH `steer`，在叶子的下一个 step 边界插入，不使用 `followup` 排队到下一 Turn。
 
-### 阻塞与授权
+### 阻塞与人工介入
 
-- 缺少任务信息：叶子进入 information waiting，由主会话回群向任务提出人询问。
-- 受控操作或必须真人确认：叶子创建授权申请，页面“授权审批”和 DWS 登录人本人私聊共享同一申请状态机。
-- 钉钉批复必须引用申请消息并明确回复“批准”或“拒绝”；等待不设超时。
-- 相同操作范围复用原申请，已批准范围不会重复申请；范围变化才创建新申请。
+- 缺少任务信息：叶子进入 information waiting，由主会话结合 Task 完整消息时间线，向真正能够补充该信息的一位或多位参与人询问。
+- Task 遇到操作红线、环境异常或需要真人判断时进入 `human-intervention`，页面“人工介入”和 DWS 登录人本人私聊共享同一阻塞状态机。
+- 钉钉人工处理必须引用阻塞消息并提供非空意见；明确回复“拒绝”“不同意”或“不批准”时记为不执行，其余回复使 Task 继续，并保留完整原文。Runtime 使用独立的个人 IM 实时订阅按被引用消息的 `messageId` 精确关联并恢复 Task，历史查询仅用于离线恢复；等待不设超时。
+- 相同阻塞范围复用原记录，已经人工确认可继续的范围不会重复请求；范围变化才创建新的人工介入事项。
 
 ### 完成通知
 
-任务完成后，叶子把结构化结果交回主会话。Runtime 使用 DWS 原生引用回复任务发起消息，并通过结构化 `atOpenDingTalkIds` @任务提出人。发送后必须回读钉钉真实消息才将 outbox 标记为已投递。
+任务完成后，叶子把结构化结果交回主会话。主会话结合 Task 完整消息时间线选择最适合承接结果的历史消息，并通过结构化 `atOpenDingTalkIds` 通知所有确实需要获知结果或采取后续行动的参与人；Runtime 只接受 Task 历史中的消息和稳定人员 ID。发送后必须回读钉钉真实消息才将 outbox 标记为已投递。
 
-任务进度、阻塞和完成通知只有 Runtime 一个群聊发送出口；叶子会话不得自行调用 DWS 向来源群发送通知。叶子提交完成结果后，Runtime 会把摘要、证据、交付物及部署信息完整交给常驻主会话组织群通知；通知可合并重复表述，但必须保留不同关注点、限定条件、失败项和未验证/未部署边界，不能为了简短只复述摘要。完成通知优先引用当前真实群触发消息；Web 与内部恢复来源只用于触发内部操作，不得覆盖 Task 当前真实消息及发送人，也不得写入消息触发历史；发现旧数据中的伪来源时会回溯最近一条带真实发送人 ID 的群消息并清理伪触发记录。通知层仍会独立回溯真实来源，避免旧数据清理前丢失引用和结构化 @。同事或其 AI 助理发送的回复、任务回执和状态通知不会按文案或发送者在模型外过滤，而是进入常驻模型，由模型结合引用、上下文和任务索引决定忽略、回答或关联任务。判断复用已有任务还是新建任务时，必须综合消息前后文、连续消息的信息组、当时场景，以及候选任务的目标、动作范围、状态、历史触发和已记录上下文；关键词、词面重合或标题相似只用于寻找候选任务，不能直接作为关联或新建结论。
+任务进度、阻塞和完成通知只有 Runtime 一个群聊发送出口；叶子会话不得自行调用 DWS 向来源群发送通知。叶子提交完成结果后，Runtime 会把摘要、证据、交付物、部署信息和完整 Task 消息时间线交给常驻主会话组织群通知。叶子根据 DSH 注入的 Skill 描述自主选择适用 Skill；Runtime 不绑定具体 Skill，只要求已加载的 Skill 完成其资格判断、必要操作和验证闭环。工作区规则授权范围内的内部维护不扩大业务 Task 授权，也不得借此修改未授权的业务代码、业务数据、环境或外部系统。通知可合并重复表述，但必须保留不同关注点、限定条件、失败项和未验证/未部署边界，不能为了简短只复述摘要。Web 与内部恢复来源只用于触发内部操作，不得伪造群消息或参与人；旧 Task 只从仍能可靠回读的来源消息补齐时间线，不猜测缺失历史。同事或其 AI 助理发送的回复、任务回执和状态通知不会按文案或发送者在模型外过滤，而是进入常驻模型，由模型结合引用、上下文和任务索引决定忽略、回答或关联任务。判断复用已有任务还是新建任务时，必须综合消息前后文、连续消息的信息组、当时场景，以及候选任务的目标、动作范围、状态、完整消息历史和已记录上下文；关键词、词面重合或标题相似只用于寻找候选任务，不能直接作为关联或新建结论。
 
 群消息中的图片、文档、文件、链接或其他外部资源如果承载任务所需信息，Resident 必须先完整读取。无法访问、下载、解析或读取不完整时，Resident 会先明确回复未获取到的具体信息并要求重新提供，不创建、不续接、不重开 Task；不得根据文件名、链接标题、缩略图或零散文字猜测资源正文。Runtime 还会对已知附件读取失败执行硬拦截，避免模型误判后提前启动任务。
 
-叶子提交 `completed` 后，Runtime 会先让常驻模型对照当前最新目标审查本轮结果和证据。若新增或修订范围未完成、缺少验证，Task 保持 `running`，缺口反馈给原叶子继续执行，不生成完成通知。
+叶子提交 `completed` 后，Runtime 会先以 coordinator 内部上下文注入的方式，让常驻模型对照当前最新目标审查本轮结果和证据；该验收不是群成员消息，不得回复群聊或写入发信箱。若新增或修订范围未完成、缺少验证，Task 保持 `running`，缺口反馈给原叶子继续执行，不生成完成通知。
 
 `running` 和 `waiting`（包括阻塞中）任务收到新增信息时只追加 `task-context`，继续同一执行轮次；只有 `completed` 任务（包括已归档展示）才允许 reopen 并初始化下一轮。
 
@@ -247,9 +257,9 @@ Runtime 使用 DSH 原生 subagent 和 Goal 创建叶子 Session。主会话不
 ![钉钉个人助理任务看板](docs/manual/images/dsh-web-task-board-annotated.png)
 
 - 群聊会话：查看不同 resident Session 的分页收信箱和发信箱；状态固定在最左列，长内容最多显示两行，完整内容可通过悬停标题或详情查看。
-- 任务看板：按待执行、执行中、等待中、已完成展示 Task，并打开 DSH 原生叶子对话和轨迹。活动任务卡片中的“任务”面板默认收起，只显示完成数/总数和进度；展开后显示各阶段任务、状态和耗时。
+- 任务看板：按待执行、执行中、等待中、已完成展示 Task，并打开 DSH 原生叶子对话和轨迹。活动任务卡片中的“任务”面板默认收起，只显示完成数/总数和进度；展开后显示各阶段任务、状态和耗时。执行轮次耗时统计不占用任务卡片空间，仍可通过 `/state/task-timings` 接口用于诊断。
 - 归档任务：查看已归档 Task，相关群消息仍可重新打开原任务。
-- 授权审批：以与消息表格一致的状态列、行高和内容密度分页查看申请单，并在页面批准或拒绝。
+- 人工介入：以与消息表格一致的状态列、行高和内容密度分页查看阻塞事项，并在页面选择继续任务或不执行。
 - 告警：按类型查看当前异常和分页的已恢复历史。
 
 看板不读取或重建 DSH Session JSONL，只通过插件状态接口展示业务投影；对话与轨迹仍由 DSH 原生页面负责。
@@ -277,5 +287,6 @@ pnpm test
 
 - [DSH 原生常驻闭环](docs/spec/dsh-native-resident-closure.md)
 - [任务 Supervisor](docs/spec/running-task-supervisor.md)
-- [授权审批中心](docs/spec/authorization-approval-center.md)
+- [人工介入中心](docs/spec/authorization-approval-center.md)
+- [钉钉人工介入回复实时生效](docs/spec/approval-reply-live-events.md)
 - [运行看板](docs/spec/dingtalk-resident-observer.md)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dingtalk-dsh-assistant",
-  "version": "0.5.9",
+  "version": "0.5.11",
   "description": "在 DeepSeek Harness 中运行的钉钉群聊个人助理与任务看板",
   "license": "UNLICENSED",
   "type": "module",
@@ -41,8 +41,8 @@
     "node": ">=24"
   },
   "dependencies": {
-    "@zzusp/dingtalk-dsh-assistant": "0.5.9",
-    "@zzusp/dingtalk-dsh-observer": "0.5.9"
+    "@zzusp/dingtalk-dsh-assistant": "0.5.11",
+    "@zzusp/dingtalk-dsh-observer": "0.5.11"
   },
   "devDependencies": {
     "@deepseek-ai/dsh-agent": "0.1.1-rc.2",