@shgroup/dsh-serenity-hooks 1.85.0 → 1.87.0

package/dsh.plugin.json

@@ -1,6 +1,6 @@
 {
   "id": "dsh-serenity-hooks",
-  "version": "1.85.0",
+  "version": "1.87.0",
   "main": "lib/index.js",
   "description": "宁静号 ACC harness（Native Cordis 插件）：给 DSH 装一个「AI 工作区」——14 个工具（container_fs/cognitive_trajectory/dashboard/container_git/msm/praxis/ontology/serenity-skill-creator/cheap-worker/localstore/container_admin；另三个 im-bridge/acc-diag/diagram 按配置条件出现）+ 机械约束（安全模式/工作区围墙/密钥守卫）+ 认知轨迹日志与原地重建 + 网页登录入口/IM 桥/认知轨迹唤醒注册表。轨迹声明 = 轨迹目录下的 trajectory.json（约束面 + 旧标识 uid + CRO 机器绑定 cro.host；旧名 trajectory-constraint.json / skiff.json 仍在读取族里）；轨迹提示词 = 轨迹目录下的 PROMPT.md（一条轨迹「是谁、按什么章程工作」，所有轨迹通用，追加在容器层与质量层之后，不替换它们）。适配 DSH 0.1.7-rc.1 / 0.2.0-rc.1 / 0.2.1-rc.1（三档，deepseek-ai/deepseek-harness）。",
   "engines": {

package/lib/{ccc-roots-VCJ3aYJA.js → ccc-roots-BI_4UVcj.js}

@@ -227,7 +227,7 @@ async function listCccs(ctx, opts = {}) {
 	if (typeof defaultRoot === "string" && defaultRoot !== "" && !c.roots.includes(defaultRoot)) c.roots.unshift(defaultRoot);
 	let rolesOf = null;
 	if (opts.withRoles === true) {
-		const { listTrajectoryConstraints } = await import("./profile-DnLSb7yv.js").then((n) => n.i);
+		const { listTrajectoryConstraints } = await import("./profile-vHheCJiU.js").then((n) => n.a);
 		rolesOf = (root) => {
 			try {
 				return listTrajectoryConstraints(root).map((p) => p.code);

package/lib/im/channels.d.ts

@@ -87,6 +87,39 @@ export interface ImChannel {
     }>;
     /** 通道健康快照（`status` 动作）——必须可 JSON 化（工具返回值契约） */
     status(root: string): ImJson;
+    /**
+     * 列出**与这条 CCC 有过往来的对端用户**（`contacts` 动作，2026-10-22 新增）。
+     *
+     * 🔴 **它存在的理由**（owner 原话：「配路由需要的是账户到轨迹，轨迹 CCC 知道，
+     * 账户 CCC 不知道，需要有个能力让 CCC 查询用户配好的账户」）：
+     * 路由要写 `{ user: "<通道用户 id>", trajectory: "<轨迹编码>" }`。轨迹编码 CCC 知道，
+     * **但"对方是谁"它不知道** —— 那个 id 只存在于聊天记录里。
+     * ⇒ 没有本动作，CCC 配路由时只能去翻日志或猜。
+     *
+     * ⚠️ **可选**：某通道若没有可扫的记录来源（例如未实现记录落盘），不实现即可，
+     * 工具会如实返回 `ACTION_UNSUPPORTED` —— 比返回空数组好（空数组会被读成"确实没有人"）。
+     */
+    listContacts?(root: string): ImContact[];
+}
+/**
+ * 一个"有过往来的对端"（`contacts` 动作的条目）。
+ *
+ * 字段刻意**全部可 JSON 化**（工具返回值契约），且不引用内部类型。
+ */
+export interface ImContact {
+    /** 该对端属于哪个渠道（`weixin` / `feishu`） */
+    channel: string;
+    /** 对端在该通道内的稳定 id（微信 `xxx@im.wechat` / 飞书 `ou_…`） */
+    userId: string;
+    /** 收发过它的账号（本地唯一键，如 `wechat-1`）—— 多账号 CCC 靠它区分 */
+    accountIds: string[];
+    /** 当前路由到的轨迹编码；未配路由 ⇒ `null` */
+    route: string | null;
+    /** 首次/最近出现时间（ISO8601；取不到为 `null`） */
+    firstSeen: string | null;
+    lastSeen: string | null;
+    /** 见过的消息条数 */
+    messages: number;
 }
 /** 注册通道（index.ts apply 调用；重复 id 覆盖——测试与热重载友好） */
 export declare function registerImChannel(channel: ImChannel): void;
@@ -95,8 +128,29 @@ export declare function __resetImChannelsForTest(): void;
 /** 已注册通道 id（工具 `channel` 参数枚举） */
 export declare function imChannelIds(): string[];
 /**
- * 可见性判据：本 CCC 是否启用了**任一** IM 通道。
+ * 可见性判据：本 CCC 是否**有任何可用的 IM 账号**。
  * 未启用 → 工具面对该 agent **不可见**（`tools.restrict` 移除，而非调用时报错）。
+ *
+ * ## 🔴 2026-10-22 判据修正（owner 令：「把开关升级为有任意账号即可，而不是盯着微信」）
+ *
+ * **旧判据** = 遍历已注册通道、任一 `channel.isEnabled(root)` 为真即可见。
+ * **旧判据的缺陷**（实测于一个只配飞书的 CCC）：`feishuChannel.isEnabled()` 首行是
+ * `if (settings.enabled !== true) return false` —— 总开关一关，**后面的账号判断根本不执行**
+ * ⇒ 账号明明配了、`enabled:true`，却因为一个**渠道无关的总开关**被永久判成"未启用"
+ * ⇒ `im-bridge` 在模型清单里彻底消失，而配置面看上去是对的（`accounts[]` 里躺着一条 feishu）。
+ * 这正是 D179 的形态：**配置说它有，行为说它没有**，且零报错。
+ *
+ * **新判据** = **账号即事实**：`readImSettings(root).accounts` 里存在
+ * 「`enabled !== false` 的账号」即视为可见。理由三条：
+ * ① **可见性问的是"这个 CCC 有没有 IM 能力"**，而能力的载体是**账号**，不是总开关；
+ * ② 总开关的语义是"**要不要让桥跑起来**"，把它当成可见性上限，会让"配好了但暂时不想让它跑"
+ *    这种合法状态变成"工具凭空消失"；
+ * ③ 判**按账号判**后，微信与飞书不再各有一套"总开关 + 账号"的双重判据 ⇒ 消除同族漂移。
+ *
+ * ⚠️ **不放宽的部分**：没有账号 ⇒ 仍然不可见（`accounts` 为空即 false）。
+ * ⚠️ 单个通道自己的 `isEnabled` 仍是**发送/启停**判据（那是通道自己的事），
+ *    只是**不再兼任**工具可见性判据 —— 两件事被这次修正分开了。
+ *
  * @param root 本会话 CCC 根（由调用方解析）
  */
 export declare function hasEnabledImChannel(root: string): boolean;

package/lib/im/hook.d.ts

@@ -27,6 +27,19 @@ interface WeixinHookEventBase {
     ts: number;
     /** 触发 CCC 根（多 CCC 一进程可区分） */
     cccRoot: string;
+    /**
+     * 渠道 id（`weixin` / `feishu`）。
+     *
+     * 🔴 2026-10-22 新增（owner：「一个 CCC 绑定多个账户很常见，聊天记录落盘要完善」）。
+     * 此前**没有这个字段** ⇒ 三个后果：① 飞书事件落进同一份 jsonl 后**无法区分渠道**
+     * （只能靠 `ou_` / `@im.wechat` 的形状猜 = D167 违反：认族不认名）；② 一个 CCC 配多个
+     * 账号时**不知是哪个渠道**收发的（`accountId` 是本地命名习惯，不携带渠道信息）；
+     * ③ 按渠道分组统计在字段层就做不到。
+     *
+     * ⚠️ **向后兼容**：存量事件没有它 ⇒ 读侧按 `accountId → im.accounts[].channel`
+     * 回填，仍取不到则按 `weixin`（那是本字段存在之前唯一的渠道）。
+     */
+    channel: string;
     /** 接收账号（incoming）/ 发送账号（outgoing） */
     accountId: string;
     /** 对端用户（from_user_id，形如 userA@im.wechat） */
@@ -71,6 +84,8 @@ type WeixinHookEvent = WeixinHookIncomingEvent | WeixinHookOutgoingEvent;
 /** incoming 事件构造输入（bridge 提供实参） */
 interface IncomingHookInput {
     cccRoot: string;
+    /** 渠道 id（`weixin` / `feishu`）；缺省 `weixin`（存量调用点零改动） */
+    channel?: string;
     accountId: string;
     userId: string;
     sessionId: string;
@@ -81,6 +96,8 @@ interface IncomingHookInput {
 /** outgoing 事件构造输入（bridge 提供实参） */
 interface OutgoingHookInput {
     cccRoot: string;
+    /** 渠道 id（`weixin` / `feishu`）；缺省 `weixin` */
+    channel?: string;
     accountId: string;
     userId: string;
     sessionId: string;

package/lib/im/log-scan.d.ts

@@ -0,0 +1,53 @@
+/**
+ * im/log-scan.ts — 读聊天记录落盘，汇总出「与谁有过往来」（`contacts` 的数据源）
+ *
+ * ## 这个文件解决什么
+ *
+ * owner 2026-10-22：「配路由需要的是**账户到轨迹**，轨迹 CCC 知道，**账户 CCC 不知道**，
+ * 需要有个能力让 CCC 查询用户配好的账户」。这里的"账户"= **通道用户**（对方是谁），
+ * 不是 IM 账号（我们自己登录的身份，`status` 早就能查）。
+ *
+ * 那个 id（微信 `xxx@im.wechat` / 飞书 `ou_…`）不在任何配置文件里 ——
+ * 它**只在聊天记录里出现过**。⇒ 本文件把记录读成联系人表。
+ *
+ * ## 🔴 两条硬边界
+ *
+ * 1. **只读**：本文件不写任何东西。真相源仍是那些 jsonl（append-only 事件流），
+ *    本文件只是它的一次投影 —— ⛔ 不产生第二真相源。
+ * 2. **不猜渠道**：事件的 `channel` 字段为准；缺它（存量事件）⇒ 按
+ *    `accountId → im.accounts[].channel` 回填，仍取不到才落 `weixin`
+ *    （那是该字段存在之前唯一的渠道）。⛔ **绝不按 userId 的形状猜**
+ *    （`ou_` 前缀 / `@im.wechat` 后缀都是命名习惯，不是判据 —— D167 认族不认名）。
+ */
+/** 日志根目录族（**新旧两代并存**：`_im-logs/<channel>/` 与存量 `_weixin-logs/`） */
+export declare const IM_LOG_DIR_NEW = "_im-logs";
+export declare const IM_LOG_DIR_LEGACY = "_weixin-logs";
+/** 汇总结果（可 JSON 化） */
+export interface ScannedContact {
+    channel: string;
+    userId: string;
+    accountIds: string[];
+    /** 事件里记录的路由目标（`role` 字段；它是事件发生当时的轨迹编码，未必等于**当前**路由） */
+    roleAtEvent: string | null;
+    firstSeen: number | null;
+    lastSeen: number | null;
+    messages: number;
+}
+/** 扫描结果（含**扫描域**——否定性结论必须附它） */
+export interface ScanResult {
+    contacts: ScannedContact[];
+    /** 实际读过的文件（相对 CCC 根） */
+    sources: string[];
+    /** 读失败的文件及其原因（不静默） */
+    errors: string[];
+}
+/** 某 CCC 下**存在**的日志目录（相对根），新代在前 */
+export declare function imLogRoots(root: string): string[];
+/**
+ * 扫描本 CCC 的全部聊天记录，按 `(channel, userId)` 汇总。
+ *
+ * @param root CCC 根
+ * @param accountChannel 存量事件缺 `channel` 时的回填表（`accountId → channel`）
+ * @returns 汇总结果 ＋ **扫描域** ＋ 读取错误（三者都不可省）
+ */
+export declare function scanImContacts(root: string, accountChannel?: Record<string, string>): ScanResult;

package/lib/im/route.d.ts

@@ -64,8 +64,15 @@ export declare function readImSettings(root: string, paths?: string[]): ImSettin
  * ⚠️ 2026-10-19 起它是 {@link readImSettings} 的**薄别名**（签名与返回形状不变）：
  * 旧调用点无需改动，但**配置来源已经统一**——`im` 段优先、`weixin` 段回退。
  * 保留名字是为了让既有调用点与测试**逐字不动**（P1 是纯重构，读数必须不变）。
+ *
+ * 🔴 2026-10-22：**返回类型由 `WeixinSettings` 改为 `ImSettings`**。
+ * 此前实现返回的就是 `readImSettings(...)`（已是归一形态：`accounts[].channel` 必填），
+ * 却把它断言成旧类型 —— 于是类型层"看不见"`channel` 字段，
+ * 调用方写 `a.channel` 会报 TS2339，而**运行时它一直在那儿**。
+ * ⇒ 那是**类型声明在撒谎**，不是调用方写错。改成真实类型后，多账户/多渠道的读侧才敢用它。
+ * ⚠️ 附带效应：`WeixinSettings` 的旧形状调用方若用到旧字段，会在此处暴露（好事，早暴露）。
  */
-export declare function readWeixinSettings(root: string, paths?: string[]): WeixinSettings;
+export declare function readWeixinSettings(root: string, paths?: string[]): ImSettings;
 /** 账号凭据（localstore credential scope；baseUrl 缺省 = 官方默认） */
 export interface WeixinAccountCredential {
     token: string;