dsh-plugin-tool-management 0.16.6 → 0.17.0

package/lib/op-registry.js

@@ -12,6 +12,8 @@
 //                 而 service 不再自报 → 也红。两边谁改了都必须动另一边。
 //   write         需要访问令牌。判据是"会不会改**宿主或外部系统**的状态" —— 注意这**不是**
 //                 "会不会写盘"：见下方 readonly 那一段。
+//   writeWhen     仅对"两态 op"（一个名字兼读与写）生效：**这次调用**算不算写。判据不成立
+//                 = 纯读，免令牌也不记流水。没带这一项的 op，标了 write 就一律按写处理。
 //   sensitive     会泄露明文凭据 / 完整配置。**必须**带对的令牌，没配令牌就一律拒绝。
 //   frozen        任一场景 locked=true 时整体拒绝（五个管理域冻结）。
 //   frozenScope   frozen 的三种口径，默认 'all'：
@@ -43,7 +45,7 @@ export const OP_REGISTRY = Object.freeze({
     'mcpm-import': { write: true, frozen: true },
     'mcpm-compact': { write: true, frozen: true },
     'mcpm-note': { write: true, frozen: true },
-    'mcpm-settings': { write: true, frozen: true },
+    'mcpm-settings': { write: true, frozen: true, writeWhen: (a) => a.set === true },
     'mcpm-set-enabled': { write: true, frozen: true, syncsArchive: true },
     'mcpm-set-all': { write: true, frozen: true, syncsArchive: true },
     'mcpm-tool-enabled': { write: true, frozen: true, syncsArchive: true },
@@ -56,7 +58,10 @@ export const OP_REGISTRY = Object.freeze({
     'mcpm-tools-refresh': { write: true },
     'mcpm-tools': { readonly: true },
     // 配置体检：只读补丁文件 + 一次 PATH 查询（`where`/`which`，不执行配置里的命令）。
-    // 返回的是检查项 id，不回任何字段值 —— 与 `mcpm-list` 同档，不带令牌。
+    // 回的是检查项 id + 少量**打码后**的字段值（URL 查询串走 `maskUrlQuery`，与 `mcpm-list`
+    // 同口径；`command` 明文，理由同 `mcpm-list`：命令名不是凭据，`args` 两边都不回）。
+    // 与 `mcpm-list` 同档，不带令牌 —— 0.16.6 之前这里回的是 URL 原文，等于让免令牌的请求
+    // 拿到 `?api_key=…`，绕过了 `mcpm-reveal` 那道防线（审查 P0-5，0.17.0 修）。
     'mcpm-inspect': { readonly: true },
     // ── 技能域（22，含内联的 skill-open）───────────────────────────────────────
     'skill-state': { annotatesLock: true },
@@ -187,14 +192,19 @@ export const OP_REGISTRY = Object.freeze({
     'injection-live': { readonly: true },
     'backups-list': { readonly: true },
     // 注入设置（各域开关 / 压制型预设口径）写侧车。它是"配置"不是"宿主状态"，但改的是
-    // 投递语义，按写操作门禁。
-    'inject-settings': { write: true },
+    // 投递语义，按写操作门禁。读侧（不带 `set:true`）只回当前设置，是纯读。
+    'inject-settings': { write: true, writeWhen: (a) => a.set === true },
     // 模型工具表（哪些工具根本不发给模型）也写侧车，改的是每轮请求的内容 —— 同上按写门禁。
-    'tool-table': { write: true },
+    // 三条写触发：`set` 换名单；`presetSave` / `presetDelete` 只动 `presets`、**不动 `hidden`**
+    // —— 后两条不经过 `set`，只认 `set` 的判据会把它们当成读放行（审查 F2）。
+    'tool-table': {
+        write: true,
+        writeWhen: (a) => a.set === true || a.presetSave !== undefined || a.presetDelete !== undefined,
+    },
     // 场景页的界面设置（进入场景前要不要弹「会改什么」的预览卡）：写侧车，按写门禁。
     // **刻意不冻结**：它只是界面提示，锁着场景的人在场景页照样该能关掉提醒 —— 冻结的是五个
     // 管理域的改动，不是这个页面的显示偏好（判据见文件头 write/frozen 两段的边界）。
-    'scene-settings': { write: true },
+    'scene-settings': { write: true, writeWhen: (a) => a.set === true },
     // 清理 patch 备份：删磁盘文件（备份里含明文凭据副本），按写操作门禁。
     'backups-clean': { write: true },
     // ── 场景候选源（4）与内联（1）──────────────────────────────────────────────
@@ -230,6 +240,27 @@ export function frozenOps(scope) {
     }
     return out;
 }
+/**
+ * 这次调用是不是「读侧」（免令牌、不记流水）。
+ *
+ * 判据只有一个来源：登记表的 `writeWhen`。**没带 `writeWhen` 的 op 一律返回 false**
+ * —— 即"标了 write 就是写"，不知道就别放行。
+ *
+ * 判据抛错也返回 false（按写处理）：一个会抛的谓词说明这次调用的形状没人设计过，
+ * 那种时候**要求令牌**才是安全的方向 —— 反过来会让"某个畸形 args 恰好免门禁"成为漏洞。
+ */
+export function isReadCall(op, args) {
+    const cls = OP_REGISTRY[op];
+    if (!cls || cls.writeWhen === undefined)
+        return false;
+    const bag = (args && typeof args === 'object' ? args : {});
+    try {
+        return cls.writeWhen(bag) !== true;
+    }
+    catch {
+        return false;
+    }
+}
 /**
  * 对账：真实 op 表里**没在登记表出现**的键。
  *
@@ -256,10 +287,20 @@ export function serviceWriteMismatch(reported) {
         extra: [...declared].filter((op) => !actual.has(op)).sort(),
     };
 }
-/** 自相矛盾的条目：既声明只读又声明要令牌 / 泄露明文。（登记时手滑的兜底。） */
+/** 自相矛盾的条目：既声明只读又声明要令牌 / 泄露明文 / 带写判据。（登记时手滑的兜底。） */
 export function contradictoryEntries() {
     return Object.entries(OP_REGISTRY)
-        .filter(([, cls]) => cls.readonly === true && (cls.write === true || cls.sensitive === true))
+        .filter(([, cls]) => cls.readonly === true && (cls.write === true || cls.sensitive === true || cls.writeWhen !== undefined))
+        .map(([op]) => op)
+        .sort();
+}
+/**
+ * 标了 `writeWhen` 却没标 `write` 的条目：写判据写了，可这条 op 根本不进写门禁
+ * —— 那份判据永远不会被问一次，等于没写（静默失效，正是 F2 的形状）。
+ */
+export function writeWhenUnwritten() {
+    return Object.entries(OP_REGISTRY)
+        .filter(([, cls]) => cls.writeWhen !== undefined && cls.write !== true)
         .map(([op]) => op)
         .sort();
 }
@@ -278,6 +319,7 @@ export function auditOpRegistry(opNames, serviceWriteOps) {
         serviceWriteMissing: mismatch.missing,
         serviceWriteExtra: mismatch.extra,
         contradictory: contradictoryEntries(),
+        writeWhenUnwritten: writeWhenUnwritten(),
         total: names.length,
     };
 }
@@ -289,5 +331,6 @@ export function auditProblems(audit) {
         ...audit.serviceWriteMissing.map((op) => op + '（service 自报写、登记表未标）'),
         ...audit.serviceWriteExtra.map((op) => op + '（登记表标了写、service 未自报）'),
         ...audit.contradictory.map((op) => op + '（只读与写自相矛盾）'),
+        ...audit.writeWhenUnwritten.map((op) => op + '（有写判据却没标写）'),
     ];
 }

package/lib/ops/compat.js

@@ -8,6 +8,7 @@
 // 守卫仍作用在组装后的整张表上，见 index.ts）。
 import { EXPECTED_MIN_HOST_VERSION, EXPECTED_PEER_RANGE, VERIFIED_HOST_VERSION, isSourceInstall, routeFor, summarize, } from '../compat/probe.js';
 import { INJECT_DOMAIN_KEYS } from '../context-inject.js';
+import { MCP_TOOL_PREFIX } from '../host-names.js';
 import { assessPresetReach } from '../compat/preset-reach.js';
 import { runtimeNotes } from '../compat/runtime-notes.js';
 import { pluginLog } from '../skills/service.js';
@@ -99,7 +100,7 @@ export function buildCompatOps(deps) {
                 let mcpTools;
                 try {
                     const schemas = (await deps.tools.schemas());
-                    mcpTools = schemas.filter((s) => String(s && s.name || '').startsWith('mcp__')).length;
+                    mcpTools = schemas.filter((s) => String(s && s.name || '').startsWith(MCP_TOOL_PREFIX)).length;
                 }
                 catch {
                     mcpTools = undefined;
@@ -175,7 +176,10 @@ export function buildCompatOps(deps) {
                     ['mcp-tool-visibility', '工具表可见性（停用 / 关掉的工具不下发）', 'mcp'],
                 ];
                 for (const [noteId, label, tab] of assemblyRows) {
-                    const note = notes.get(noteId);
+                    // 注入通道有**两类**上报：装配失败（`context-injection`）与运行期失败
+                    // （`context-injection-runtime`，2026-09-30 P1-8：某域取数抛异常 / 整段注入抛异常）。
+                    // 合并到同一行 —— 用户关心的是"这条通道现在好不好"，不是"哪一类失败"。
+                    const note = notes.get(noteId) ?? (noteId === 'context-injection' ? notes.get('context-injection-runtime') : undefined);
                     push({
                         key: noteId, label, tab, state: note === undefined ? 'ok' : 'degraded',
                         detail: note === undefined ? '装配正常，无降级上报' : note.detail,

package/lib/ops/prompts.js

@@ -76,14 +76,27 @@ export function buildPromptOps(deps) {
         // 场景绑定（含恒常的 `_shared` / `global`）、`~/.dsh/AGENTS.md` 的当前内容、
         // 进场景前保存的基线（退出场景后要恢复的那一份）。拒绝时逐条说明「谁在用」，
         // 用户知道该先改哪里。引用清单由 scene-prompt-sync 与显示/注入同源算出。
-        // 探测失败（refs() 返回 null）时放行并记 warn：删预设不动 ~/.dsh/AGENTS.md，
-        // 最坏是少一份副本，可重建 —— 不因一次探测故障把删除堵死。
+        //
+        // 探测**失败**时改为拒绝（2026-09-30 审查 F13）。原来的取舍是「放行并记 warn：删预设不动
+        // ~/.dsh/AGENTS.md，最坏是少一份副本，可重建」—— 这对「副本」成立，对**场景态**不成立：
+        // 删掉场景绑定的那一份，场景驱动会因为找不到预设而静默失效（`driver()` 返回 null），
+        // 而 AGENTS.md 停在场景态，用户看到的是「没场景驱动所以什么都没做」。
+        // `refs()` 返回 null 只代表**三类探测里至少一类读盘失败**（全新环境没有场景时它返回的是
+        // **空表**而不是 null），所以拒绝不会堵住正常路径。文案必须说清是「探测失败」而不是
+        // 「有引用」—— 否则用户会去改一堆并不存在的引用。
         'agentsmd-remove': async (args) => {
             const id = String((args && args.id) || '');
             const refs = await deps.scenePromptSync.refs();
-            if (refs === null)
-                deps.warn('prompts: reference probe failed; remove allowed');
-            const why = refs ? refs.get(id) || [] : [];
+            if (refs === null) {
+                deps.warn('prompts: reference probe failed; remove refused');
+                return {
+                    ok: false,
+                    code: 'error.agentsMd.refProbeFailed',
+                    error: `无法确认「${id}」是否被引用，已拒绝删除：引用探测失败（场景绑定 / AGENTS.md 当前内容 / 进场景前的基线，这三类里至少有一类没读到）。请稍后重试。`,
+                    params: { id },
+                };
+            }
+            const why = refs.get(id) || [];
             if (why.length) {
                 const refsText = why.map(deps.promptRefReason).join('；');
                 return {

package/lib/ops/scene-records.js

@@ -4,13 +4,13 @@
 // 提示词改绑。动的是 index 的 scenes / active 切片与 AGENTS.md 投影，与记忆正文 ops 互不调用。
 import { mkdir, readdir, rename, rm } from 'node:fs/promises';
 import { join } from 'node:path';
-import { listTrashEntries, moveOutOfTrash, moveToTrash, purgeTrashEntry, readTrashEntry } from '../hub.js';
+import { listTrashEntries, moveIntoTrash, moveOutOfTrash, moveToTrash, purgeTrashEntry, readTrashEntry } from '../hub.js';
 import { MAX_DESCRIPTION_LENGTH, DEFAULT_GROUP_ORDER, GLOBAL_SCENE, GLOBAL_SCENE_LABEL, SHARED_GROUP, SEGMENT_RULE_HINT, isValidGroupSegment, isValidGroupPath, message, fail } from '../memories/constants.js';
 import { normalizeActive, collapseActiveForNewScene } from '../memories/projection.js';
 import { readIndex, writeIndex, sceneRecordOf, normalizeScenePromptId, pathExists } from '../memories/index-io.js';
 /** 组装本域 op。rc 由 createMemoriesService 组装，契约见 ./ctx.ts。 */
 export function buildSceneRecordOps(rc) {
-    const { ensureLayout, invalidateSnapshot, presetExistsSync, memoriesRoot, sceneRows, snapshot, stateDir } = rc;
+    const { ensureLayout, invalidateSnapshot, presetExistsSync, memoriesRoot, refuseOutsideRoot, sceneRows, snapshot, stateDir } = rc;
     /**
      * 设置"启用场景"（全局持久化，切换后**下一个请求即生效**，§4 对照表）。
      *   - `args.scenes` 数组 → 启用集合；**至多一个非保留场景**（用户裁定：除「全局」外
@@ -39,7 +39,13 @@ export function buildSceneRecordOps(rc) {
             // 恒常启用的保留场景不入显式集合：`_shared`（公共基线）与 `global`（「全局」）。
             if (name === '' || name === SHARED_GROUP || name === GLOBAL_SCENE)
                 continue;
-            if (!isValidGroupPath(name)) {
+            // 启用集合里的场景名必须是**单个路径段**（2026-09-30 审查 P2-4）。此前这里走
+            // `isValidGroupPath`，于是 `a/b` 这种多段名**通过校验并被写进 `active`**，但它压根
+            // 不是一个场景：场景恒等于一级目录（见 `snapshot.ts` 的 `depth === 1` 与
+            // `projection.ts` 的 `sceneOf`），注入时桶名是 `a`、`active` 里写的是 `a/b` ——
+            // 两边对不上，用户看到的是"开关点了、场景没生效"，且**没有任何报错**。
+            // 改成单段后这种名字会当场被拒（响亮地失败），与创建/改名的口径一致。
+            if (!isValidGroupSegment(name)) {
                 return fail('error.rules.invalidGroup', `场景名非法：${name}（${SEGMENT_RULE_HINT}）`);
             }
             if (seen.has(name))
@@ -63,8 +69,14 @@ export function buildSceneRecordOps(rc) {
     /**
      * 新建场景：写一条场景记录（索引 scenes 切片）+ 建空目录 `memories/<场景>/`。
      * 场景是**显式实体**——空场景（还没有记忆）也是合法场景，会出现在场景列表里。
-     * 场景名是**单个路径段**（不允许 `a/b`）：界面把场景当一级列表展示，
-     * 允许多段只会让「记忆的场景」与「目录层级」两套语义互相打架。
+     *
+     * 场景名的统一口径（2026-09-30 审查 P2-4 收敛，此前全仓分成两派）：
+     *   - **命名路径**（新建 / 改名目标 / 启用集合）一律是**单个路径段**。场景恒等于一级目录
+     *     （见 `snapshot.ts` 的 `depth === 1` 与 `projection.ts` 的 `sceneOf`），允许 `a/b`
+     *     只会让「场景」与「场景内的分组」两套语义互相打架，而且启用时桶名对不上（静默失效）。
+     *   - **定位路径**（改名的旧名 / 锁定 / 删除 / 回收站恢复）按**完整路径**寻址，`isValidGroupPath`。
+     *     历史与导入留下的多段记录因此仍能被改名或删除 —— 否则它们成了"看得见、动不了"的死条目。
+     *
      * 幂等：已存在则更新描述/标签，不报错。`_shared` 与 `global` 是保留名。
      */
     async function rulesCreateScene(args) {
@@ -249,6 +261,18 @@ export function buildSceneRecordOps(rc) {
                     index.archives[nextRaw] = index.archives[name];
                     delete index.archives[name];
                 }
+                // 该场景下的**记忆条目**也要跟着换前缀（2026-09-30 审查 P1-1）。不迁的话：改名后
+                // 旧键 `<旧场景>/<名>` 在磁盘上找不到对应文件，`buildSnapshot` 的清理会把它删掉
+                // （见 `memories/snapshot.ts` 的"索引有记录但文件已删"分支）→ 那条记忆失去索引条目
+                // → `projectRule` 的 `enabled ?? true` 把它**重新启用** —— 用户显式停用的记忆复活，
+                // 且 order / tags / pinned / note 一并丢失。记忆自己的改名路径（`ops/memory.ts`）
+                // 一直是迁索引的，场景这条漏了同一件事。
+                // 只换前缀、原值不动；`nextRaw` 的场景名已被上面的占用检查保证为空，不会覆盖。
+                const sceneRules = index.rules || {};
+                for (const id of Object.keys(sceneRules).filter((k) => k.startsWith(name + '/'))) {
+                    sceneRules[nextRaw + id.slice(name.length)] = sceneRules[id];
+                    delete sceneRules[id];
+                }
                 const act = normalizeActive(index.active);
                 if (act !== null && act.indexOf(name) >= 0)
                     index.active = act.map((n) => (n === name ? nextRaw : n));
@@ -308,11 +332,15 @@ export function buildSceneRecordOps(rc) {
     /**
      * 删除场景：**仅空目录可删**（避免一次操作带走整组记忆）。
      * 同时删掉场景记录、把它从 `active` 集合里摘掉、清掉它的档案，避免悬空引用。
-     * 保留场景 `global` 不可删除；场景名口径与创建一致（单个路径段）。
+     * 保留场景 `global` 不可删除。
+     *
+     * 场景名在这里按**完整路径**寻址（`isValidGroupPath`，2026-09-30 审查 P2-4）：命名路径
+     * （创建 / 改名目标 / 启用集合）一律要求单段，而历史与导入留下的多段记录得能**被清掉** ——
+     * 否则它就成了"看得见、动不了"的死条目。删除只是定位 + 移入回收站，多段名不会造成歧义。
      */
     async function rulesRemoveScene(args) {
         const name = String((args && args.name) || '').trim();
-        if (!isValidGroupSegment(name))
+        if (!isValidGroupPath(name))
             return fail('error.rules.invalidGroup', `场景名非法：${name || '(空)'}`);
         if (name === SHARED_GROUP)
             return fail('error.rules.invalidGroup', `_shared 是保留场景名，不可删除`);
@@ -333,6 +361,15 @@ export function buildSceneRecordOps(rc) {
         // 但一律**先移入回收站**（与场景记录、档案装在同一条条目里），所以「删错了」还能整条恢复：
         // 记忆文件按原来的相对路径放回，场景记录与档案也一起回来。
         const sceneDir = join(memoriesRoot, name);
+        // 删除前先确认落点仍在根内（realpath 口径）—— 与 `rulesRemove` / `rulesRestore` 同一道闸。
+        // 为什么删除侧最需要它（2026-09-30 审查 P1-2，已实测复现）：`memories/<场景>` 若是指向根外的
+        // 目录链接（用户手工建、或旧布局迁移带进来的），下面 `collect` 的 `readdir` 会**列出链接目标
+        // 的内容**，于是 `from` 拼成 `<memoriesRoot>/<场景>/x.md` 看着在根内、`rename` 实际作用于
+        // **根外的真实文件** —— 删除场景会把 `D:\重要数据` 里的文件搬进回收站。`isValidGroupSegment`
+        // 挡不住（名字本身合法），`lstat` 也挡不住（只看末级）。
+        const deniedDir = await refuseOutsideRoot(sceneDir);
+        if (deniedDir)
+            return deniedDir;
         const moves = [];
         const collect = async (abs, rel) => {
             let items = [];
@@ -343,6 +380,12 @@ export function buildSceneRecordOps(rc) {
                 return; // 目录不存在（只有记录的场景）或读不了 → 当作没有文件
             }
             for (const item of items) {
+                // 跳过符号链接（含 Windows junction），与 `snapshot.ts` 的 `discover` 同口径。
+                // 上面那道 realpath 断言挡的是「场景目录本身是链接」；这一条挡的是「场景目录内的某一项是
+                // 链接」—— 两者是不同的路径，缺一条就漏一条。链接本身也不搬走（它是环境相关的，
+                // 不该被回收站带到另一台机器上），留给后面的 `rm` 清掉。
+                if (item.isSymbolicLink())
+                    continue;
                 const childAbs = join(abs, item.name);
                 const childRel = rel === '' ? item.name : `${rel}/${item.name}`;
                 if (item.isDirectory())
@@ -352,10 +395,19 @@ export function buildSceneRecordOps(rc) {
             }
         };
         await collect(sceneDir, '');
+        // 该场景下每条记忆的索引条目（enabled / order / tags / pinned / note）一并收进回收站条目
+        // 的 `data`（2026-09-30 审查 P1-1）。不带的话：恢复出来的记忆全部按 `enabled ?? true`
+        // 重置 —— 用户停用的会复活，其余元数据归零。文件在回收站、元数据也得跟着在。
+        const sceneRuleSubset = {};
+        for (const id of Object.keys(index.rules || {})) {
+            if (id.startsWith(name + '/'))
+                sceneRuleSubset[id] = index.rules[id];
+        }
         const trashed = await moveToTrash('scenes', name, moves, {
             record: (index.scenes && index.scenes[name]) || null,
             archive: (index.archives && index.archives[name]) || null,
             memories: moves.map((m) => m.dest),
+            rules: sceneRuleSubset,
         });
         if (trashed.ok === false) {
             return fail('error.rules.ioFailed', `移入回收站失败：${trashed.error}`);
@@ -366,11 +418,21 @@ export function buildSceneRecordOps(rc) {
         }
         catch (e) {
             // 目录没清掉就把记忆放回去：宁可整个操作失败，也不要「文件在回收站、场景还留在列表里」。
+            let rollbackFailed = 0;
             for (const move of moves) {
                 try {
                     await moveOutOfTrash('scenes', trashed.id, move.dest, move.from);
                 }
-                catch { /* 尽力而为 */ }
+                catch {
+                    rollbackFailed += 1;
+                }
+            }
+            // **回滚没做完就绝不 purge**：purge 会把条目整目录删掉，而没能放回的那些文件还在里面
+            // —— 那是一次静默的**永久删除**（用户记忆），且场景目录还留在原地（一个被掏空的场景）。
+            // 宁可留一条脏条目（界面看得见、能再点一次恢复），也不要"删干净"（审查 P0-2）。
+            if (rollbackFailed > 0) {
+                return fail('error.rules.ioFailed', `删除场景目录失败：${message(e)}；另有 ${rollbackFailed} 个记忆文件没能放回原位，`
+                    + `它们仍在回收站条目 ${trashed.id} 里（未删除），可从回收站恢复`);
             }
             try {
                 await purgeTrashEntry('scenes', trashed.id);
@@ -392,6 +454,17 @@ export function buildSceneRecordOps(rc) {
             delete index.archives[name];
             dirty = true;
         }
+        // 记忆条目也跟着进了回收站（见上面的 `sceneRuleSubset`）→ 索引里同步删掉。不删的话会留下
+        // "索引有记录、磁盘没文件"的悬空键：`buildSnapshot` 下一轮也会清掉，但中间那一轮界面会
+        // 把它显示成"这条记忆不存在"，且恢复时 `data.rules` 合并回来会与残留键打架。显式删干净。
+        if (index.rules) {
+            for (const id of Object.keys(index.rules)) {
+                if (id.startsWith(name + '/')) {
+                    delete index.rules[id];
+                    dirty = true;
+                }
+            }
+        }
         if (dirty)
             await writeIndex(stateDir, index);
         invalidateSnapshot();
@@ -404,6 +477,9 @@ export function buildSceneRecordOps(rc) {
     /**
      * 从回收站恢复一个场景：重建记忆目录 + 写回记录与档案。
      * 同名场景已存在时**拒绝**（绝不覆盖既有场景）。
+     *
+     * 场景名按**完整路径**寻址（2026-09-30 审查 P2-4，与删除侧同口径）：回收站里的名字来自
+     * 当初删掉的那条记录，多段名同样得能恢复回来 —— 否则删得掉、恢复不了，数据就卡在回收站里。
      */
     async function sceneTrashRestore(args) {
         const id = String((args && args.id) || '').trim();
@@ -411,12 +487,18 @@ export function buildSceneRecordOps(rc) {
         if (!entry)
             return fail('error.rules.notFound', `回收站条目不存在：${id}`);
         const name = String(entry.name || '').trim();
-        if (!isValidGroupSegment(name))
+        if (!isValidGroupPath(name))
             return fail('error.rules.invalidGroup', `回收站里的场景名非法：${name || '(空)'}`);
         const index = await readIndex(stateDir);
         if (index.scenes?.[name])
             return fail('error.rules.invalidGroup', `无法恢复，同名场景已存在：${name}`);
         const dir = join(memoriesRoot, name);
+        // 恢复是**写入**方向：落点若是指向根外的目录链接，`mkdir` 会顺着链接成功、随后
+        // `moveOutOfTrash` 把记忆文件写到**根外**去。与删除侧同一个根因（缺 realpath 根内断言），
+        // 2026-09-30 审查 P1-2 的相邻面 —— 修一处必须一起修，否则只是把同一个洞挪了个方向。
+        const deniedDir = await refuseOutsideRoot(dir);
+        if (deniedDir)
+            return deniedDir;
         let entries = [];
         try {
             entries = await readdir(dir);
@@ -443,13 +525,38 @@ export function buildSceneRecordOps(rc) {
                 restored.push(String(rel));
             }
             catch (e) {
-                return fail('error.rules.ioFailed', `恢复记忆文件失败（已放回 ${restored.length}/${files.length}）：${message(e)}`);
+                // 已放回的文件**搬回回收站**再报错：原来这里是直接 return，已放回的那几个留在记忆目录里
+                // —— 下一次点恢复会撞上面那条「目录里已有内容」的检查，于是这个场景**永远恢复不了**
+                // （审查 P0-2）。回滚失败也如实说清楚，别让用户以为还能原样重试。
+                let backFailed = 0;
+                for (const doneRel of [...restored].reverse()) {
+                    try {
+                        await moveIntoTrash('scenes', id, join(dir, doneRel), doneRel);
+                    }
+                    catch {
+                        backFailed += 1;
+                    }
+                }
+                const tail = backFailed === 0
+                    ? '（已放回的记忆文件已退回回收站，可重试）'
+                    : `（另有 ${backFailed} 个文件没能退回回收站，它们现在在记忆目录「${name}」里，请先手工处理再重试）`;
+                return fail('error.rules.ioFailed', `恢复记忆文件失败：${message(e)}${tail}`);
             }
         }
         if (data.record && typeof data.record === 'object')
             index.scenes = { ...(index.scenes || {}), [name]: data.record };
         if (data.archive && typeof data.archive === 'object')
             index.archives = { ...(index.archives || {}), [name]: data.archive };
+        // 记忆条目随文件一起回来（删除时存进 `data.rules`，见 `rulesRemoveScene`）——
+        // 否则恢复出来的记忆全部按 `enabled ?? true` 重置，用户停用的会复活（审查 P1-1）。
+        // **只补不覆盖**：同名键若已存在以现有为准（上面已拒绝同名场景，正常情况下不会撞）。
+        if (data.rules && typeof data.rules === 'object' && !Array.isArray(data.rules)) {
+            const rules = index.rules || (index.rules = {});
+            for (const [ruleId, ruleEntry] of Object.entries(data.rules)) {
+                if (rules[ruleId] === undefined)
+                    rules[ruleId] = ruleEntry;
+            }
+        }
         await writeIndex(stateDir, index);
         await purgeTrashEntry('scenes', id);
         invalidateSnapshot();

package/lib/ops/sessions.js

@@ -220,9 +220,47 @@ export function buildSessionOps(deps) {
             const sessionId = String((args && args.sessionId) || '').trim();
             if (!sessionId)
                 return { ok: false, error: '缺少 sessionId' };
+            // 范围收敛（2026-09-30 审查 P1-7）：单删也只允许删**已归档**的会话 —— 与批量路径
+            // （`deleteArchivedSessions` → `archivedSessionIdsForTarget` 的四种 scope 全部与
+            // `archivedSessionIds` 求交）同一口径，也与界面对齐（`history-list` 只回已归档会话，
+            // 删除按钮只出现在那份列表里）。原先这里直接 `registry.deleteSession(sessionId)`，而
+            // `deleteLocalSession` 只问「这个 id 在持久化里存在吗」—— 于是一个客户端 bug 或一次
+            // 手工请求就能**永久删除任意已持久化会话**，包括未归档的和当前正开着的。
+            // 判据必须是**权威归档集合**，不是摘要投影（2026-09-30 审查 F9）。
+            // `archivedSessionMetadata()` 是**有损**的：逐条 try，读不到 header 或 `createdAt`
+            // 非有限就 `continue` 且不抛（`workspace.ts` 的 `archivedSessionMetadata`）。拿它的
+            // `items` 拼门禁集合，就会把「确实已归档、只是头部暂时读不到」的会话判成未归档 →
+            // 回一句「只能删除已归档的会话：请先归档，再删除」——**诊断是错的**（真因是读失败）。
+            // 而批量路径（`deleteArchivedSessions` → `archivedSessionIdsForTarget`）用的是
+            // `requireState().archivedSessionIds`，同一份数据两条路给出相反结论。
+            // 这里改成与批量路径同源；`requireState` 缺失（旧宿主）才退回投影 —— 投影只会**更小**，
+            // 方向仍是 fail-closed（宁可这次删不掉，也不要凭未知状态做不可逆操作）。
+            let archived;
             try {
-                await registry.deleteSession(sessionId);
-                return { ok: true, sessionId, deleted: true };
+                const authoritative = typeof registry.requireState === 'function' ? registry.requireState() : undefined;
+                if (authoritative && Array.isArray(authoritative.archivedSessionIds)) {
+                    archived = new Set(authoritative.archivedSessionIds.map((id) => String(id)));
+                }
+                else {
+                    const meta = await registry.archivedSessionMetadata();
+                    const items = meta && Array.isArray(meta.items) ? meta.items : [];
+                    archived = new Set(items.map((i) => String(i && i.sessionId)));
+                }
+            }
+            catch (e) {
+                // 查不到归档状态 → **拒绝删除**（fail-closed）：宁可这次删不掉，也不要凭一个未知状态
+                // 去执行不可逆操作。
+                return { ok: false, error: '无法确认会话的归档状态，已拒绝删除：' + deps.message(e) };
+            }
+            if (!archived.has(sessionId)) {
+                return { ok: false, error: '只能删除已归档的会话：请先归档，再删除' };
+            }
+            try {
+                const r = await registry.deleteSession(sessionId);
+                // 级联只吃已归档的子会话（见 `deleteDescendants`）：未归档的会被**保留**，
+                // 这里如实带出去，界面/模型才不会以为「这一支已经全没了」。
+                const kept = (r && Array.isArray(r.keptUnarchivedDescendants)) ? r.keptUnarchivedDescendants : [];
+                return { ok: true, sessionId, deleted: true, ...(kept.length ? { keptUnarchivedDescendants: kept } : {}) };
             }
             catch (e) {
                 return { ok: false, error: deps.message(e) };
@@ -294,8 +332,9 @@ export function buildSessionOps(deps) {
             if (!fileName || !content.trim())
                 return { ok: false, error: '缺少文件内容' };
             let turns;
+            let format;
             try {
-                const format = detectFormat(fileName, content);
+                format = detectFormat(fileName, content);
                 turns = format === 'jsonl' ? parseJsonlTranscript(content)
                     : format === 'markdown' ? parseMarkdownTranscript(content)
                         : parseGenericText(content);
@@ -305,6 +344,13 @@ export function buildSessionOps(deps) {
             }
             if (!turns.length)
                 return { ok: false, error: '未能从该文件中识别出对话内容' };
+            // 「折成一条 user 消息」这件事本身要出声（2026-09-30 审查 F12）。
+            // 嗅探（`detectFormat`）已经能救回「JSONL / Markdown 被改名成 .txt」那一种，但**真的**
+            // 没有说话人标记的文本仍会走 generic：多行内容全塞进 1 条 user turn、结构全失，
+            // 而 op 此前回的是 `{ok:true,count:1}` —— 零警告。这里把它标出来（`lossy` 给界面出
+            // 本地化文案，`warning` 给模型看原因原文）。
+            const lossy = format === 'generic' && turns.length === 1
+                && content.split(/\r?\n/).filter((line) => line.trim()).length >= 5;
             if (typeof deps.createSession !== 'function')
                 return { ok: false, error: '当前环境不支持创建会话（agents.create 不可用）' };
             // 仅接受绝对路径的 cwd；非法或缺失时会话不带目录（归入未分组）。
@@ -334,7 +380,7 @@ export function buildSessionOps(deps) {
                 if (live === undefined || live === null) {
                     return { ok: false, error: `创建会话失败：宿主未登记该会话（${id}），未导入任何内容` };
                 }
-                return { ok: true, sessionId: id, count: turns.length };
+                return { ok: true, sessionId: id, count: turns.length, ...(lossy ? { format, lossy: true, warning: '整份文本没有识别出任何说话人标记（如 User: / Assistant:），已折成一条用户消息：原对话的分轮结构可能已丢失。若源文件是 JSONL 或 Markdown 转录稿，请按原扩展名（.jsonl / .md）重新导入。' } : {}) };
             }
             catch (e) {
                 return { ok: false, error: '创建会话失败: ' + deps.message(e) };