[Feature Request] scope 标注缺人工入口与提升回路：自动载体标签不该直接吃硬过滤效力

[heptaspirit]

背景与使用场景

我是 #17 的提案作者。日常形态就是 #17 的场景 1 + 场景 2：多个 preset（编码 / 写作 / …）× 多个互不相关的 workspace，mneme 0.8.0。

当前版本落地后我把实现逐条对了一遍（对照 #17 的规格），有两个风险想提出来对齐——都是我自己在 #17 里没说清楚、被实现放大之后才看出来的：

1. agent 维的自动标注范围过宽：它把"这条共享给谁"当成了"写入会话的身份快照"，于是绝大多数本应全局的记忆被自动归属；
2. strictScope 打开之后，错标的记忆缺少纠偏路径——既没有人工改 scope 的入口，也没有能发现"这条其实该全局"的机制。

已查现状

CHANGELOG 0.8.0、README、面板设置页、#153 / #155 / #156 / #157 / #163，以及已关闭的 #17。确认 scopeEnabled / strictScope 默认关；也确认当前不存在任何手动改 scope 的入口（不是没找到开关，是逐条 grep 过）。

环境：@modusensus/dsh-mneme@0.8.0（desktop profile 实际安装版本）、Windows、DSH Desktop。

一、现状核对（v0.8.0 / b852323）

1. 两维都只有"写入载体"一个来源，没有人工入口。 memory_save 参数 = type / title / content / tags / importance / source / sensitivity / occurred_at，memory_update 参数 = id / title / content / type / tags / importance / reason——两处都没有 scope；agent_scope / workspace_scope 在 tools.js 里只出现在输出 item schema；面板只有 group.scope = [scopeEnabled, strictScope] 两个开关加只读展示；全 src/ 搜索 promote|scope_set|setScope 无命中，即没有任何修改 scope 的代码路径。
2. 自动标注的键 = 写入会话的 preset 快照（scopeEnabled 关时一个字段都不标）。
3. A2 是 OR + 写死系数，A3 是 fail-closed 且两维同构。 本会话命中行与未标注行同为 ×1.25，只有确立 foreign 才 ×0.5 → 实际落差 2.5 倍；且 agent 维能单独把 workspace 完全命中的记忆罚到 0.5。A3 下当前会话某维解析不到，该维度带标注的记忆一律不可见。

内容	位置
memory_save / memory_update 参数	src/tools.js:85-94 / :282-289
scope 仅出现在输出 schema	src/tools.js:30-33
面板开关组 / 详情只读行	lib/client.js:1737 / :125-126、:3282-3285
自动标注来源（preset 快照）	src/scope.js:33-34、:55-57
A2 系数与 scope 乘数	src/service.js:56-57、:64-72
A3 谓词 / SQL 同口径	src/service.js:95-101、src/store.js:722-733、:1044-1060

对 #17 规格的差异（维护者在 #17 收尾也列过）：memory_save 的 scope 枚举参数、defaultMemoryScope 配置、存量记忆的收窄 / 提升工具三项未随批次 A 落地。现在的形态是"每条写入都按载体自动归属 + 没有任何出口"。

二、问题 1：自动归属的范围过宽

四象限里 agent 维唯一不可替代的只有一格——agent 专属 × workspace 全局（跨项目能力库）；其余三格 workspace 维都能表达（"完全专属"也只是再加一道锁）。而自动标注对每一条写入都打 agent 标签，于是：一条通用偏好只要是在某个 preset 的会话里写下的，就永久带上了那个 preset 的身份。

用户无法表达"这条对所有 agent 都有效"：唯一的办法是把 scopeEnabled 整个关掉，那会连 workspace 标注一起失去（两维共用一个开关）。我实际需要的形态正相反——只有极少数记忆需要被显式收窄到某个 agent，绝大多数应该是全局或项目级。

我仔细考虑了 agent scope 的作用，其实它更接近于 dsh 中 agent preset 的概念，本应是直接封在 preset 中的，我们这里其实相当于一个灵活的注入。那么如果这样考虑下去的话，它的作用面就很窄，只有极少数场景下才会真的需要将部分记忆与某个特定的 agent preset 绑定。

三、问题 2：strictScope 打开后，错标缺少纠偏路径

• 标签来源只有载体，A3 不区分"自动打的"与"显式声明的"，自动标签直接吃硬效力；
• 没有任何工具能改 scope（save / update 都没有该参数，面板只读）；
• NULL 兼任"未判定"与"全局"，且没有 scope_source / scope_decided_at → 事后筛不出该复核的候选集；
• 维护面（dream / sleep）用 store.all() 绕过过滤（src/store.js:1092-1093，调用点 dream.js:673/736/1093、dream/sleep.js:106/418）——它们看得见跨 scope 的重复与通用内容，但这个信号不会交回给用户。

结果是：目录改名、中途换 preset、或某次身份解析取空（#163 就是这类），都会让一批记忆在检索与注入里消失，而界面上没有任何"它被 scope 挡住了"的提示——只有关掉开关才发现它们还在。

四、期望的行为变化（不指定实现）

1. 作用域可以显式声明：写 / 改记忆时能指定或覆盖归属，至少能声明"这条对所有 agent 可见"；面板能看到并修正单条记忆的 scope。自动标注保留为默认候选值即可，但不该是唯一来源。
2. 一条提升 / 纠偏回路：能把已标错的记忆提升回全局（放宽可见性 = 需显式确认 + 审计），并且能被半自动地提示候选——例如 dream / sleep 阶段遇到跨 scope 高度相似、或明显通用的内容时列出来交用户裁决。维护面本来就有全量视图（store.all()）和全库向量配对（sleep.js:97 phaseConflicts，阈值 gentle 0.92 / normal 0.85 / aggressive 0.75），"同一个教训在两个 scope 各写了一遍"正好是它的输入。
3. 区分"自动"与"显式"的效力——这是我最想跟维护者对齐的一点：载体自动打的标签，是否应该在 strictScope 下直接等于硬墙？我的观点是自动标注只该提供软加权，硬过滤只认显式声明。

这几项原本就在 #17 的设计规格里（memory_save 的 scope 参数、defaultMemoryScope、存量记忆的收窄 / 提升工具），批次 A 未落地——本 issue 想请维护者把它们排进 v0.8.x。

五、开放问题

1. agent 维表达的是"身份"还是"受众（这条共享给谁）"？如果只有显式声明才作数，它的值不必等于 agentPreset（可以是 coding / shared / 某个项目名），agentPreset 只是默认候选值。看路线图里"跨 workspace 共享层"，这似乎是同一件事，是否合并设计？
2. 是否考虑把 agent 维做成两档（标注只软降权、不进硬过滤），或给两维各自独立开关（现在是共用一个 scopeEnabled）？
3. 是否需要 scope_source（auto / explicit）+ scope_decided_at，作为"候选集筛选 + 提升审计"的底座？

---

说明：第一、三节引用的行号是 v0.8.0（b852323）源码核对结果；0.8.0 已在本机安装运行，但本轮没有开 strictScope 做长时间实测。"会消失多少条""体感如何"属于个人经验推断，具体情况可能取决于各人记忆库的标注分布，我这里没有量化数据。

[modusensus]

感谢这份回访——行号我们对照 b852323 逐条核过，全部属实（包括 A2 未标注行与命中行同 ×1.25 的 OR 语义、实际落差 2.5 倍、A3 fail-closed、dream/sleep 经 store.all() 绕过过滤、全库不存在任何改 scope 的代码路径）。两个问题都成立，先把立场对齐，再给落地切分。

先坦率对齐一处规格出处

查了 #17 原文：原规格里只有第 8 条的 defaultAgentScope / defaultWorkspaceScope（已在 #17 收尾列为有意偏差跟踪）；memory_save 的 scope 参数与存量记忆的收窄/提升工具并不在 #17 文本里。不过正如你在开头自陈的——这是「#17 没说清楚、被实现放大」的问题，出处不影响这两条诉求本身成立，我们照单收下。

对三个开放问题的立场

1. agent 维按「受众」语义设计：agent_scope 表达「这条共享给谁」，agentPreset 只是默认候选值，取值不必等于 preset。它与路线图里的跨 workspace 共享层确实是同一件事，但合并设计推迟——schema 保持自由 TEXT 不锁死取值空间，等共享层设计时再收敛。
2. 两维独立开关暂不拆：若下述效力规则成立（自动标签降为软加权），agent 维的主要风险随之消失，拆 scopeEnabled 属于提前优化。等效力规则落地、有真实使用反馈后再议。
3. scope_source + scope_decided_at：要，且最先落地。两个可空列、ADD COLUMN 零重写（与 feat(scope): 写入端 scope 标注存储层（A1，issue #17） #153 同款迁移），是候选筛选与提升审计的地基，不被任何后续设计决定阻塞。

核心对齐：4.3 的效力区分

你的立场我们同意：载体自动打的标签只做软加权（现有 ×0.5 已保留可见），strictScope 硬过滤只认显式声明。 这样切的好处：存量自动标注无需迁移（降级为软信号即可）；strictScope 的静默消失风险被消除；「标注语义」的争论与「效力规则」解耦，可以分开推进。

这一条会收窄 #156 的四象限公式语义（硬过滤只对 explicit 行生效），想先听你确认再动。

落地切分（v0.8.x，按依赖排序）

1. 底座：scope_source（auto / explicit）+ scope_decided_at 两列；memory_save / memory_update 增加可选 scope 参数（显式写入记 explicit）；面板详情行从只读升级为可编辑——放宽可见性 = 显式确认 + 写审计。
2. 纠偏回路：dream/sleep 本就持有全库视图（store.all()）与全库向量配对（phaseConflicts，你引用的阈值组），跨 scope 高度相似对、明显通用的内容作为候选，走 feat(conflicts): 冲突待确认的集中处理——队列 API + 状态页人工确认视图 #166 刚落地的冲突待确认队列交人工裁决——不新造界面。你说的「同一个教训在两个 scope 各写了一遍」正是它的现成输入。
3. 效力规则：strictScope 硬过滤只认 scope_source='explicit'（含上节确认后的语义收窄）。

第 1 步的工具参数 + 面板编辑体量适中，保留 good first issue 标签供认领；底座迁移与第 3 步语义收窄我们自己动手。落地 PR 会回链本 issue，谢谢你把 v0.8.0 逐行对回来的功课——这正是批次 A 需要的使用端反馈。

[modusensus]

@heptaspirit 进度同步：第 1 步（底座）已落地，PR #171 开放中——

• scope_source 按你开放问题 3 的方向落地，但拆成了 agent_scope_source / workspace_scope_source 两列（+ 单列 scope_decided_at）：混合来源（agent 维显式 + workspace 维自动）必须可表达，否则「提升回全局」后遗留的自动 workspace 标签会在第 3 步效力收窄时被一并当成显式。存量自动标注行三列 NULL、读侧按 auto 软效力口径解释，无需回填。
• memory_save / memory_update 已有可选 agent_scope / workspace_scope 参数（显式声明逐维覆盖载体自动标注；global/* = 显式全局）；面板详情抽屉 scope 可编辑，放宽可见性需二次确认，每次归属决策写 scope_changes 审计（actor：tool/panel）。
• 你开放问题 2（拆独立开关）：如回帖所说暂缓——现在自动标注与显式声明在数据上可区分了，等第 3 步落地后按真实反馈再议。

第 2 步（dream/sleep 跨 scope 相似对 → 冲突待确认队列候选）在 stacked 分支上跟进；第 3 步（strictScope 硬过滤只认 explicit）等你在 4.3 上的确认。

[modusensus]

@C:/Users/石晴/AppData/Local/Temp/c170s2-trimmed.md

[heptaspirit]

确认 4.3：硬过滤只认显式声明，载体自动标注只做软加权。

per-dim 拆成两列比我原来说的单列 scope_source 更对——混合来源不表达出来，第 3 步会把「提升 agent 维」之后遗留的自动 workspace 标签也当成显式，正好是这条 issue 要修的洞。（两个 PR 我扫了一遍，check-sync.js 和两个新用例文件在本地跑过，19/19。）

两点顺带想到的，都不挡第 3 步：

• 这条规则落地后，strictScope 就不再是「隐私墙」，而是「只对显式声明生效的隔离」。面板上现在还叫「严格隔离」，容易被读成能挡住自动标注的记忆——真正的物理隔离仍然是 sensitivity。
• 一个想问的：第 2 步的立论是「归属是用户的决定，LLM 无从代断」，所以跨 scope 对绝不进 LLM；但 memory_update 里模型传 agent_scope: "global" 就能直接放宽归属，只记一条 actor=tool 审计。放宽是把内容暴露给更多会话，模型侧是不是也该走确认，或者只允许收窄？这条不用现在定，先记着。

第 3 步按上面落地我没有异议。

[modusensus]

@heptaspirit 第 3 步已落地：PR #173（stacked on #172/#171）——strictScope 硬过滤只认 *_scope_source='explicit'，与你确认的 4.3 一致。几个对应点：

• 存量零迁移：v0.8.0 自动标注行来源三列皆 NULL，读侧按 auto 软效力解释（feat(scope): 归属显式声明与人工纠偏底座——per-dim 来源列 + save/update scope 参数 + 面板可编辑（#170 第 1 步） #171 三列设计预留的口径正好接上）。开启 strictScope 后的行为变化是放宽——原被硬挡的存量行恢复可见，正好修掉「目录改名/换 preset 后记忆静默消失」。
• fail-closed 收窄：匿名会话只挡 explicit 行，不因身份解析失败误杀自动标注。
• 你顺带第 1 点（面板文案）：已采纳——strictScope 的设置页 hint 双语改为「只对显式声明的归属生效……真正的物理隔离请用 sensitivity」，把「隐私墙」的误读摘掉。
• 你顺带第 2 点（模型侧放宽归属）：按你说的先记着不定。现状是模型 memory_update 传 agent_scope 可直接放宽、只有 actor=tool 审计行可回放；后续选项（要求确认 / 只允许收窄 / 放宽走队列）等攒到真实使用反馈再定，已进维护侧 backlog。

三个 PR 合并后 #170 的三项期望就全部闭环了（显式声明、提升/纠偏回路、效力区分）。