Repository navigation
[Feature Request] scope 标注缺人工入口与提升回路：自动载体标签不该直接吃硬过滤效力 #170
Description
背景与使用场景
我是 #17 的提案作者。日常形态就是 #17 的场景 1 + 场景 2：多个 preset（编码 / 写作 / …）× 多个互不相关的 workspace，mneme 0.8.0。
当前版本落地后我把实现逐条对了一遍（对照 #17 的规格），有两个风险想提出来对齐——都是我自己在 #17 里没说清楚、被实现放大之后才看出来的：
- agent 维的自动标注范围过宽：它把"这条共享给谁"当成了"写入会话的身份快照"，于是绝大多数本应全局的记忆被自动归属；
strictScope打开之后，错标的记忆缺少纠偏路径——既没有人工改 scope 的入口，也没有能发现"这条其实该全局"的机制。
已查现状
CHANGELOG 0.8.0、README、面板设置页、#153 / #155 / #156 / #157 / #163，以及已关闭的 #17。确认 scopeEnabled / strictScope 默认关；也确认当前不存在任何手动改 scope 的入口（不是没找到开关，是逐条 grep 过）。
环境：@modusensus/[email protected]（desktop profile 实际安装版本）、Windows、DSH Desktop。
一、现状核对（v0.8.0 / b852323）
- 两维都只有"写入载体"一个来源，没有人工入口。
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 的代码路径。 - 自动标注的键 = 写入会话的 preset 快照（
scopeEnabled关时一个字段都不标）。 - 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 挡住了"的提示——只有关掉开关才发现它们还在。
四、期望的行为变化（不指定实现）
- 作用域可以显式声明：写 / 改记忆时能指定或覆盖归属，至少能声明"这条对所有 agent 可见"；面板能看到并修正单条记忆的 scope。自动标注保留为默认候选值即可，但不该是唯一来源。
- 一条提升 / 纠偏回路：能把已标错的记忆提升回全局（放宽可见性 = 需显式确认 + 审计），并且能被半自动地提示候选——例如 dream / sleep 阶段遇到跨 scope 高度相似、或明显通用的内容时列出来交用户裁决。维护面本来就有全量视图（
store.all()）和全库向量配对（sleep.js:97phaseConflicts，阈值gentle 0.92 / normal 0.85 / aggressive 0.75），"同一个教训在两个 scope 各写了一遍"正好是它的输入。 - 区分"自动"与"显式"的效力——这是我最想跟维护者对齐的一点：载体自动打的标签，是否应该在
strictScope下直接等于硬墙？我的观点是自动标注只该提供软加权，硬过滤只认显式声明。
这几项原本就在 #17 的设计规格里（memory_save 的 scope 参数、defaultMemoryScope、存量记忆的收窄 / 提升工具），批次 A 未落地——本 issue 想请维护者把它们排进 v0.8.x。
五、开放问题
- agent 维表达的是"身份"还是"受众（这条共享给谁）"？如果只有显式声明才作数，它的值不必等于
agentPreset（可以是coding/shared/ 某个项目名），agentPreset只是默认候选值。看路线图里"跨 workspace 共享层"，这似乎是同一件事，是否合并设计？ - 是否考虑把 agent 维做成两档（标注只软降权、不进硬过滤），或给两维各自独立开关（现在是共用一个
scopeEnabled）？ - 是否需要
scope_source（auto / explicit）+scope_decided_at，作为"候选集筛选 + 提升审计"的底座？
说明：第一、三节引用的行号是 v0.8.0（b852323）源码核对结果；0.8.0 已在本机安装运行，但本轮没有开 strictScope 做长时间实测。"会消失多少条""体感如何"属于个人经验推断，具体情况可能取决于各人记忆库的标注分布，我这里没有量化数据。
Activity
modusensus commentedon Sep 13, 2026
感谢这份回访——行号我们对照
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 没说清楚、被实现放大」的问题，出处不影响这两条诉求本身成立，我们照单收下。对三个开放问题的立场
agent_scope表达「这条共享给谁」，agentPreset只是默认候选值，取值不必等于 preset。它与路线图里的跨 workspace 共享层确实是同一件事，但合并设计推迟——schema 保持自由 TEXT 不锁死取值空间，等共享层设计时再收敛。scopeEnabled属于提前优化。等效力规则落地、有真实使用反馈后再议。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，按依赖排序）
scope_source（auto / explicit）+scope_decided_at两列；memory_save/memory_update增加可选 scope 参数（显式写入记 explicit）；面板详情行从只读升级为可编辑——放宽可见性 = 显式确认 + 写审计。store.all()）与全库向量配对（phaseConflicts，你引用的阈值组），跨 scope 高度相似对、明显通用的内容作为候选，走 feat(conflicts): 冲突待确认的集中处理——队列 API + 状态页人工确认视图 #166 刚落地的冲突待确认队列交人工裁决——不新造界面。你说的「同一个教训在两个 scope 各写了一遍」正是它的现成输入。scope_source='explicit'（含上节确认后的语义收窄）。第 1 步的工具参数 + 面板编辑体量适中，保留 good first issue 标签供认领；底座迁移与第 3 步语义收窄我们自己动手。落地 PR 会回链本 issue，谢谢你把 v0.8.0 逐行对回来的功课——这正是批次 A 需要的使用端反馈。
modusensus commentedon Sep 13, 2026
@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 步（dream/sleep 跨 scope 相似对 → 冲突待确认队列候选）在 stacked 分支上跟进；第 3 步（strictScope 硬过滤只认 explicit）等你在 4.3 上的确认。
modusensus commentedon Sep 13, 2026
@C:/Users/石晴/AppData/Local/Temp/c170s2-trimmed.md
feat(scope): sleep 冲突阶段跨 scope 分流——同内容跨归属对停车人工裁决（issue #170 第 2 步）
heptaspirit commentedon Sep 14, 2026
确认 4.3：硬过滤只认显式声明，载体自动标注只做软加权。
per-dim 拆成两列比我原来说的单列
scope_source更对——混合来源不表达出来，第 3 步会把「提升 agent 维」之后遗留的自动 workspace 标签也当成显式，正好是这条 issue 要修的洞。（两个 PR 我扫了一遍，check-sync.js和两个新用例文件在本地跑过，19/19。）两点顺带想到的，都不挡第 3 步：
memory_update里模型传agent_scope: "global"就能直接放宽归属，只记一条actor=tool审计。放宽是把内容暴露给更多会话，模型侧是不是也该走确认，或者只允许收窄？这条不用现在定，先记着。第 3 步按上面落地我没有异议。
modusensus commentedon Sep 14, 2026
@heptaspirit 第 3 步已落地：PR #173（stacked on #172/#171）——strictScope 硬过滤只认
*_scope_source='explicit'，与你确认的 4.3 一致。几个对应点：memory_update传agent_scope可直接放宽、只有 actor=tool 审计行可回放；后续选项（要求确认 / 只允许收窄 / 放宽走队列）等攒到真实使用反馈再定，已进维护侧 backlog。三个 PR 合并后 #170 的三项期望就全部闭环了（显式声明、提升/纠偏回路、效力区分）。
fix(scope): 复核跟进——dedupe 来源升级补 scope_changes 审计 + 钉死工具脏入参 schema 拒绝（i…
feat(scope): sleep 冲突阶段跨 scope 分流——同内容跨归属对停车人工裁决（issue #170 第 2 步）
fix(scope): 人工已裁决的冲突对不再反复入队——内容变了才重新评审（issue #170 复核项 4）
13 remaining items
fix(scope): 人工已裁决的冲突对不再反复入队——内容变了才重新评审（issue #170 复核项 4）
test(conflict-freeze): 重写「已解决对再次 pending」用例到新语义（issue #170 复核项 4）
fix(scope): 普通 dream 的跨 scope conflict 决策停车人工裁决（issue #170 复核项 3）
feat(scope): strictScope 硬过滤只认显式声明——自动标注降为纯软加权（issue #170 第 3 步，4.3 已确认）
docs(readme): strictScope 口径对齐 explicit-only 语义（issue #170 复核项 1）
fix(scope): memory_update/memory_delete 补 strictScope 可见性校验——与 memory…
feat(scope): sleep 跨 scope 相似对停车人工裁决——纠偏回路接冲突队列（#170 第 2 步） (#172)
feat(scope): strictScope 硬过滤只认显式声明——自动标注降为纯软加权（#170 第 3 步，4.3 已确认） (#173
release: v0.8.1 准备——版本号 0.8.1、CHANGELOG、README 对齐 0.8.1
modusensus commentedon Sep 23, 2026
收尾对账：本 issue 三项期望已全部落地，按定论楼逐条核过 main 现状——
agent_scope_source/workspace_scope_source/conversation_scope_source三列，存量零迁移）+ feat(scope): strictScope 硬过滤只认显式声明——自动标注降为纯软加权（#170 第 3 步，4.3 已确认） #173（strictScope 硬过滤只认*_scope_source='explicit'，fail-closed 收窄）。已随 0.8.1 发布。lib/client.js落地，「隐私墙」误读摘掉。顺带第 2 点（模型经
memory_update传agent_scope直接放宽归属、仅 actor=tool 审计可回放）按当时商定留在维护侧 backlog，攒到真实使用反馈再定选项（要求确认 / 只允许收窄 / 放宽走队列），不在本 issue 范围内拖延关单。感谢 @heptaspirit 全程的逐条对拍（4.3 确认、三列设计优于单列、两处顺带）。关闭，有后续在 #170 侧重开或新开均可。
fix(organize): filter dryRun match targets by caller visibility (#231 …
feat(organize): expose the organizer to agents as memory_organize (sl…
docs(sleep): record the three boundaries of the conflict auto-resolve…