边界存在于“记忆与习惯”里
- 全局索引和旧 Advisor 容易把别的项目规则带进来。
- 主模型负责计划、执行、解释和自我验收。
- 同一 macOS 用户下，凭据和运行时距离模型进程太近。
- 并行写入、重试和长会话容易互相放大问题。
- 没有清晰 baseline 时，很难证明回滚只回滚本任务。
30 秒总览：从“靠模型自觉”变成“系统有边界”
这轮最值钱的不是多了多少功能，而是把项目归属、记忆适用范围、审查、写入权和凭据处理从提示词愿望，往确定性规则迁了一大步。
以前像所有项目共用一块白板、一串钥匙，做事的人还要自己给自己打分。
所以“相关”很容易被误当成“适用”：眼镜会话可能看到 MaiBot 的发图限制；主模型说“完成了”，也可能没有另一双眼睛及时追问证据。
- 已运行：项目 binding、记忆 scope、active Advisor、安全门、租约、完整性和供应链门禁。
- 只到 canary：Guard broker 鉴权与 Swift broker。
- 仍待处理：外部 key/session 失效、生产 OS 隔离、完整 AgentLoop。
边界尽量落进“系统与测试”里
- 会话先绑定项目，Guard 再做服务端 scope 复核。
- 副模型在顶层 step/end 持续检查跑偏与无证据完成。
- 正常链路有多层敏感数据门，凭据轮换有值盲工具。
- AgentTeams 用路径租约，重试有分类与上限。
- 三个源码仓已有本地 checkpoint，精确 staged，不自动 push。
一句最诚实的话：现在比以前稳很多，但不是“全部问题彻底消失”。尤其是生产 broker、独立 OS 身份、MiniMax / Alibaba 外部失效和完整 fresh-worker AgentLoop，仍明确留在待办区。
记忆不再是一锅汤，而是“公共前台 + 项目房间”
老大的判断是对的：系统维护和项目总控确实需要跨项目视野；但普通业务项目不能因此自动继承另一个项目的规则。现在这两件事被分开建模。
项目房间示意图
箭头代表“允许查询/适用”，不是自由复制全部内容
改前规则池混在一起
眼镜
MaiBot
系统规则
发图限制
“相关”很容易被当成“当前适用”
共同上下文
改后全局骨架 + 分项目房间
owner / runtime global
系统维护 / 项目总控有跨项目目录与协调视野
Guard 按 session binding 重算 scope
Guard 门卫
只把适用规则送进对应房间
眼镜项目connector: none
MaiBot 项目connector: maibot
其他普通项目各自 project scope
能看项目目录，不等于把所有房间的规则都塞进当前会话。
把系统/总控想成大楼管理员：它需要知道有哪些房间、谁负责、哪里报警，所以有跨项目“目录和协调视野”；但它不会把 201 室的操作守则自动贴进 305 室，更不能因为能看目录就随便搬别人的东西。
owner_global鹿崽身份、老大的稳定偏好、跨入口连续性。
全局适用runtime_globalDSH / Codex / Hermes 的安全和调度规则。
全局适用portfolio_global只自动给系统维护与项目总控，用于项目登记、路由和协调。
限主控角色capability:luzai-image-output通用“怎么发图”的范式，能力确实存在时才启用。
按能力启用connector:maibot-mediaMaiBot 特有上传/媒体限制；仅 MaiBot connector 活跃时适用。
不进眼镜project:<id>某一个项目的事实、规则和证据，默认只在该项目房间里。
严格隔离看到“发图”，可能顺手联想到 MaiBot
旧全局启动链和旧 Advisor 能先看到 MaiBot / Android 媒体边界。即使当前 cwd 是眼镜，“相关词”也可能把不适用规则带进判断。
只拿通用发图能力，不拿 MaiBot 连接器限制
会话先绑定眼镜项目；真实 fresh smoke 中 connector_ids=[]，scoped prompt 没有注入 MaiBot 媒体边界，Guard 也会服务端重算权限。
“项目绑定”到底防了什么？
它把“这个 session 属于哪个项目”做成首绑不可变：根据已登记项目根目录和当前 cwd 做最长匹配，得到确定性 revision；同一个 owner / peer / session 若中途改报项目、scope 或 revision，Guard 返回冲突。普通项目跨项目 mutation 默认拒绝，未绑定 session 对写操作 fail closed。
它还没做到什么？
还没有完整实现“发现目标项目变化 → 自动收束旧 session → 新建项目 session → 生成最小 handoff”。真实 MaiBot 对照，以及“发图 / root Android / 显式跨项目比较”等用户语义回归也仍待补。
Advisor 从“偶尔提意见”变成持续副驾驶
老大要的不是主模型干完以后再找人盖章，而是副模型在执行过程中持续看它有没有偏离目标、跨错项目、无证据宣布完成，必要时能把它叫回来。
主模型与副模型的工作关系
Advisor 看有界新证据，不继承主模型的“我觉得我对”
改前自己做，自己判
主模型计划 → 执行 → 验收 → 再相信自己的历史
同一段历史会放大沉没成本，跑偏后更难主动推翻自己。
改后执行席 + 独立副驾驶
主模型执行每个 top-level step / end 形成 checkpoint
只抽取当前项目的新增有界证据
ReviewFrameV1
送到独立审查席
副模型 Advisorkimi-coding/k3 · 不继承主模型的“我觉得我对”
输出严格 verdict
OK / NIT / CONCERN / BLOCKER
驱动下一步
继续 / 纠正 / 暂停
真人目标 revision 更新后，旧 verdict 会自动 stale-drop，不把过期建议重新注入。
审查容易和主模型一起跑偏
旧 Advisor 缺少严格项目作用域，也没有清楚的“证据序号、目标 revision、binding revision”。它可能把别项目规则当建议，又很难判断建议是不是已经过时。
每个顶层节点都排审查 checkpoint
同一 session 只允许一个审查在飞；后续 checkpoint 用 latest-wins 合并，不积压旧建议。下一次只读从 lastReviewedSeq 开始的有界新证据，并绑定当前项目和目标。
OK证据覆盖目标，继续。
NIT小问题，记录但不打断。
CONCERN需要纠正；注入下一步或唤醒 follow-up。
BLOCKER高风险或证据不足，可暂停 goal / 工具。
一次真实纠偏是怎么发生的
1. 主模型收口它在没有足够证据时宣布完成。
2. Advisor 晚到判定
completion_without_evidence。3. 独立唤醒会话已 idle、没有 live goal，于是 delivery=followup。
4. 主模型撤回明确收回无证据完成声明并补充处理。
5. 再审为 OK事件账本 canceled/discarded 都是 0。
这正是老大要的“持续纠错”：不是等最终报告才点评，而是发现主模型已经停下但结论站不住时，还能主动叫它回来修正。
Advisor 会不会自己形成新的串线？
ReviewFrame 会排除 system prompt 和 workspace/plugin prompt 注入，只带当前 binding、当前目标、限定 event seq、错误摘要和预算；结构化字段和文本都做敏感数据门。未知字段、错误 scope 或证据序号会 fail closed。
Advisor 等于完整 AgentLoop 吗？
不等于。Advisor 是在线副驾驶，负责及时发现偏航；完整 AgentLoop 还需要每轮 fresh worker、独立 cycle critic、严格终态、持久任务状态、下一动作和 host restart 恢复。当前这部分仍未实现。
还有哪些 Advisor 分支只通过了测试？
fast same-turn inject、第二次 unresolved concern 升级 owner-visible blocker、blocker / goal pause / steer / tool-gate 已有确定性回归，但尚未全部做受控生产 E2E；长期误报率和延迟也需要继续观察。
凭据安全：已经止住正常链路，但保险柜还没正式接管
这里最容易被一句“已经安全了”说过头。现在确实补了很多门，但生产 Guard 仍是 legacy，Swift broker 仍是 mock-only canary，same-UID 的最终隔离还没有完成。
凭据从“同桌可见”走向“窄接口取用”
虚线部分表示设计已验证、尚未切生产
改前同一桌面的一串钥匙
DSH
Codex / Hermes
都靠近共享凭据面
bearer / 环境 / Keychainadapter 与 admin 边界不够窄
同一 macOS UID 下，shell/code 能力仍可能形成旁路。
当前已上线正常链路先经过多层门
正常工具链descriptor-only
发送前与写入前都检查
多层 secret gate
轮换过程不回显真实值
值盲轮换器
Phase 2source/mock canary｜尚未切生产
root-only broker尚未生产接线
5 秒签名断言 · role / path / JTI
内部固定路由
Guard 目标端当前仍 legacy
OpenViking 目标端记忆后端
Admin 分权设计仍未切生产
秘密可能在模型可见面经过
- GUI launchd 曾携带 Alibaba 登录 cookie。
- 共享 Guard bearer 同时靠近 adapter 和管理端能力。
- 完整诊断、tool result 或 completed turn 可能把可识别秘密送入 transcript / SQLite / 外部模型。
- 同一 macOS UID 下的 shell/code 能力不构成真正 sandbox。
正常链路多层拦截，轮换不回显值
- GUI launchd 已移除该 cookie，loader fail closed，Guard/Codex tail 使用最小环境。
- 工具结果、Advisor frame、DSH ingress、Guard pre-INSERT、Flash/Pro 输入输出和 job 都有可识别敏感数据门。
- MiniMax 轮换器只从 stdin/剪贴板取新值，原子替换、并发锁、失败回滚，输出只有固定状态。
- broker 的角色、路径、短 TTL、一次性 JTI 与 peer 校验已经进入源码测试。
两个 P0 仍开放：旧 MiniMax 值仍在 9 份私密历史归档中作为事故证据存在，必须在 provider 侧确认旧 key 失效；Alibaba 登录 cookie 也需要服务端 logout-all / session 失效确认。本机删除和脱敏不能替代服务端吊销。
为什么 broker 现在不能写成“已经上线”
- Swift broker 目前严格 mock-only，未安装、未加载、未转发真实上游。
- Guard 生产模式仍为
legacy；当前断言 replay cache 只适合严格单实例。 - 还缺独立 OS UID / process sandbox、root-only 持久签名密钥、可信 launchd 注册和 code-signing 绑定。
- 生产 broker 必须在内部消费断言并固定路由，不能把断言或原始凭据返回 caller。
- healthcheck、全部 adapter、owner/admin 必须有原子迁移和回滚，不能半切。
现有 secret gate 能挡住所有秘密吗？
不能。它覆盖正常工具/API 路径里的可识别标签与结构，并对 getter、proxy、未知结构等 fail closed；任意无标签 opaque 字符串、加密/压缩内容、媒体内容和 same-UID 直读仍不属于完整 DLP 保证。它是有效的纵深防御，不是最终 sandbox。
会话、并行、重试和插件：少靠运气，多靠合同
串项目只是表象之一。审计还发现并行写入覆盖、JSONL 缺口、重试风暴、长会话无 goal、市场插件来源漂移等问题。这轮给这些路径加了明确护栏。
多个 Agent 可能同时改同一棵路径
成员、captain 和主线程可能基于不同旧版本修改重叠文件，出现 stale edit、覆盖或“测试的版本不是最终版本”。
AgentTeams 先声明 write_roots
精确根集合原子 acquire/release；祖先/后代冲突，主线程和 captain 也要服从。跨进程锁对损坏 owner fail closed。
错误分类不清，容易重复撞墙
认证失败、内容拒绝、上下文错误和网络抖动可能混用一套重试逻辑；XAI 历史出现过大量 retry-started。
永久错误停，瞬态同指纹最多 2 次
provider + model + code + 归一化 message 组成指纹；认证、凭证、quota、invalid request、context window 等直接停并诊断。
市场入口和可变来源扩大供应链面
“装得上”不代表来源固定、权限合理、许可证清楚，也不代表插件规则会尊重当前项目。
policy 与 observed lock 分开
安装前检查 exact provenance、完整 Git SHA、权限扩张、quarantine 和 literal secret；市场 mutation 已禁用，desired/live 都是 11 个直接依赖。
这轮新增的几道硬门
| 护栏 | 现在能做什么 | 还缺什么 | 状态 |
|---|---|---|---|
| Workspace lease | 阻止 AgentTeams 重叠路径并发写；主线程不能旁路。 | 真实生产冲突 E2E、read/version token 与 tree hash。 | 已运行 / 待补 E2E |
| Session integrity | 新健康 session 对 seq、call/result 配对、step/turn pending fail hard。 | 旧 40 条坏物理行、缺 seq 4244/23555 和 writer 根因没有修复。 | 预防已上线 |
| Harness guard | 未知工具不当只读；跨项目 mutation、敏感取值命令和危险结果结构 fail closed。 | bounded search、统一结构化 tool outcome、read-before-edit CAS。 | 生产运行 |
| Plugin supply chain | 市场写入口禁用；候选插件按来源、权限、quarantine 验证。 | 7 条低风险 engine/license 元数据、全部第三方源码逐行 review。 | 生产运行 |
| Goal / AgentLoop | Ralph 从 64 收紧到 8；Advisor completion certificate 有确定性测试。 | fresh worker、independent critic、持久 continuation 与 restart 恢复。 | 仍未完整实现 |
路径租约像施工许可证：A 队正在拆 3 楼承重墙，B 队就不能同时进去改同一堵墙。可是“只有一队施工”仍不等于它手里的图纸是最新版本，所以 read/version token 还是下一道要补的门。
为什么这轮没有顺手装一堆外部插件？
因为本轮根因是作用域、审查、凭据和执行合同，不是缺 Cloudflare、Drive、Calendar 或任务管理能力。无目标安装只会扩大 credential、网络与跨项目数据面。现在的策略是“任务确实需要才按最小权限接入”，不是用安装数量证明系统变强。
旧同步撤下，Git 变成可审计路标
以前既有新的 Guard/OpenViking 权威，又残留旧 Core native sync 可执行路径；同时源码仓缺少稳定 baseline。现在“哪条路能写、出事回哪里”清楚了很多。
旧 native-sync 旁路已撤下，主在线路径更明确
历史证据保留，不等于历史工具还能运行
主在线路径写入入口更明确
DSH / Codex / Hermes
受服务端门禁约束
Luzai Guard
统一进入记忆后端
OpenViking
旧旁路保留证据，不再允许继续跑
旧 Core 历史证据目标只读；write CLI 仍待单独关闭
native sync.txt / 0444 / hash archive
被划掉的是 native-sync artifact set；不能因此把另一套 Core write CLI 写成“已经关闭”。
Git 路标出现问题时能精确回看
DSH · 1b4c398
memory · 309bdb1
OpenViking · cad9f60
第二条写路和脏工作区让回退含糊
旧 native sync 仍能被人工或模型误调用，重新建立第二套记忆写入路径。没有清晰 baseline 时，也难证明某次提交有没有带进用户旧改动。
旧 artifact 只读封存，源码有精确 checkpoint
workspace source/test 与系统 runtime 三份旧 native-sync artifact 已改为 .txt、0444 并记录路径、mode、大小与 SHA-256；三个源码仓建立本地 baseline。
没夹带用户改动：workspace 当时有大量既有/旁支脏改动；本轮使用精确 staged 路径，报告提交后暂存区为 0。DSH、memory-platform 无 remote，OpenViking 只保留原有上游 remote；本轮没有新增 remote，也没有 push。
还有旧 Core 写入口吗？
有一个单独开放问题：活动的 workspace/tools/luzai_core.py 仍注册 append-batch、claim-add、claim-revise、claim-import 等写命令。它不是被隔离的 native-sync artifact set，审计仍明确 WARN；需要先盘点仍要保留的只读维护能力，再单独迁移或加不可绕过的 read-only gate。
有 Git baseline 就等于 AgentLoop 能断点续跑吗？
不等于。Git 只是可靠“路标”和差异权威。完整续跑还需要持久 task state、当前 goal revision、下一动作、证据索引、严格 verdict 和 host restart 后的恢复合同；这些仍待实现。
完整状态表：哪些真上线了，哪些只是打好了地基
看这张表就能避免口径混乱。“有源码”“测试通过”“运行中”“真实业务 E2E”是四个不同层级，不能互相代替。
| 能力 | 改后现状 | 你可以相信到哪一步 | 状态 |
|---|---|---|---|
| 项目 binding | 首绑不可变；Guard 服务端重算 scope；普通项目跨项目 mutation fail closed。 | 系统与眼镜 fresh smoke 通过；眼镜没有 MaiBot connector 注入。 | 已生产 |
| 记忆读写边界 | 同一 Guard/OpenViking 在线权威；completed owner turn 才进入 guarded extraction。 | 正常 bound ingress/recall 已接线；历史旧内容不因此自动清洗。 | 已生产 |
| Advisor supervisor | active；step/end checkpoint；latest-wins；terminal concern follow-up。 | 真实“无证据完成 → 撤回 → 再审 OK”闭环通过；部分 blocker 分支仍只到测试。 | 主动运行 |
| Secret / descriptor gate | DSH、Guard、模型输入输出和读 egress 多层可识别敏感数据门。 | 运行态合成探针通过；不覆盖任意 opaque / 加密 / 媒体与 same-UID 直读。 | 已生产 |
| AgentTeams lease | write_roots 原子租约，主线程/captain 同锁。 | 17/17 回归；真实生产冲突 acquire→deny→release→reacquire 待补。 | 已生产 / E2E 待补 |
| Session integrity | 新健康 session 的 seq、call/result 和 pending 合同 fail hard。 | 防新增损坏；不修复旧 40 条坏物理行，也未定位 writer 根因。 | 预防已上线 |
| Plugin supply chain | policy/lock 分离、市场 mutation 禁用、candidate quarantine。 | blocking 0；仍有 7 条低风险元数据和第三方源码 review 待办。 | 已生产 |
| Native sync | 三份 runnable artifact 撤下并只读哈希封存。 | 该 artifact set 已关闭；旧 luzai_core.py 写 CLI 是另一项开放问题。 | 已隔离 |
| MiniMax 轮换器 | stdin-only、值盲输出、锁、原子替换、回滚、可同步 DSH。 | 工具 20/20；provider 旧 key 尚未确认失效。 | 工具完成 / 外部待办 |
| Guard / Swift broker | LBA1、短 TTL/JTI、角色分权、peer 与 macOS ACL 安全测试。 | Python 204/204、Swift 21/21；生产 Guard 仍 legacy，broker 未安装。 | source-only canary |
| 完整 AgentLoop | 已有 Advisor、Ralph 上限和 Git baseline 作为地基。 | fresh worker/critic、严格持久状态、restart 恢复尚未实现。 | 未完成 |
| Alibaba session | GUI launchd 已清除 cookie；loader fail closed。 | 服务端 logout-all / session 失效尚未确认。 | 外部待办 |
老大实际会感觉到什么不一样
很多安全改造平时应该“没感觉”；真正出问题时，它们才会表现为更少串线、更早停手、更明确说降级、更容易回到正确版本。
少串项目
在眼镜项目问发图，不应再莫名背出 MaiBot 的媒体限制；系统/总控仍保留跨项目协调视野。
“完成了”更难随口说
Advisor 会追当前目标和证据；真实样本里，主模型已被叫回来撤回一次无证据完成。
错误更早停
认证、quota、invalid request 等永久错误不会再当网络抖动无限重试；同指纹瞬态错误也有硬上限。
并行施工更少互踩
AgentTeams 成员必须先拿路径租约；主线程和 captain 也不能趁成员工作时绕过去改同一棵路径。
记忆坏了会明说
Recall 失败会产生固定、简短的 degraded 标记，而不是悄悄装作记得或把异常正文塞回上下文。
出事更容易回退
源码仓已有本地 checkpoint 和精确 staged 证据；回滚不会默认吞进 workspace 的旧改动，也不会自动 push。
还不会自动做到：抹掉旧会话里的事故证据、让任意秘密永不泄漏、自动吊销 provider key、把跨项目 mutation 变成合法 handoff、在 host 重启后保证任务自动续跑，或让所有 Advisor / AgentTeams 风险分支都天然拥有生产 E2E。
下一步按风险顺序走，不要一起切
接下来不是继续堆功能，而是先把两个外部 P0 真正失效，再把 source-only broker 补齐生产条件，最后完成 AgentLoop 和剩余真实回归。
本轮已经跑过的硬证据
这些数字证明受检代码通过相应测试，不自动扩大为“所有生产边界都完成”。
130 / 130DSH JavaScript 回归
204 / 204memory-platform Python
21 / 21Swift broker · warnings-as-errors
本地提交：
DSH 1b4c398
memory 309bdb1
OpenViking cad9f60
workspace 的大量既有/旁支脏改动未夹带；本轮未新增 remote，未 push。