LobeHub Acceptance 验收机制双层失误目录、supersedes 替换规则与 Electron 登录注入策略【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehubLobeHub 的验收Acceptance体系由三层文档协作支撑可移植的通用技能、项目级“活日志”目录以及保留历史事故细节的田野笔记field notes。读完本篇你将理解 LobeHub 如何用“通用层 项目层”双层失误目录沉淀验证经验如何用supersedes声明管理检查项的替换关系以及为什么自动化验证在 LobeHub 桌面端被明令禁止触发 OAuth 登录流程、必须改用登录态注入。1. 定位field notes 是双层失误目录中的“历史残留层”本文的主体文件是 common-mistakes-field-notes.md。它开头就声明了自己的身份历史项目层素材historical project-layer source material。当前真正被维护的目录是同级的 common-mistakes.md新条目必须使用稳定的L-前缀标识符追加到后者而本文件保留的旧案例维持原始编号这样更老的交叉引用依然可以解析——某个案例若在本文件中找不到说明它已经被泛化genericize后晋升到了通用层。两层目录的分工在 PROCESS.md 的 Step 0 中有明确规定执行任何验收运行前必须同时读全两层——通用层随技能分发本仓库中只读.agents/skills/acceptance/references/common-mistakes.md与probe-mock-patterns.md。该技能路径在仓库内是符号链接指向技能源码packages/builtin-skills/src/acceptance/见 PROJECT.md 开头说明。通用层的更新方式是向lobehub/cli提 PR项目层可写、属于本仓库common-mistakes.md 与 probe-mock-patterns.md。晋升promote到通用层的判定标准是 PROCESS.md Step 0 的五条准入门禁任何一条负面反馈要入日志都必须通过Durable可复现性——换一个人、换一个功能轮次是否还会遇到Project-specific项目相关性——是否依赖 LobeHub 的产品语义、环境或基础设施若否就应去掉 LobeHub 名词泛化后 PR 到技能源Invariant-level不变式层级——陈述行为或证据契约而不是冻结某个具体解法像素值、图标选择、标注坐标属于规格/组件/回归测试的领地Non-duplicative不重复——先搜索两层底层失败相同则修订既有案例Actionable可行动——未来的验证者能否据此选择不同的动作、或拒绝无效证据。这个设计解释了为什么 common-mistakes.md 自称是“curated log策展过的日志而非评审反馈的流水记录”它只保留 LobeHub 产品和环境的持久不变式而把逐条事故的叙事细节下沉到 field notes 与references/probe-field-notes.md使“每次验收运行必读”的成本可控。2. 目录本体L-标识符与三类不变式维护目录 common-mistakes.md 用L-前缀避免与通用层的M目录混淆并强制把每条失误归入三类标识符前缀即类别名前缀类别典型条目L-E*Evidence and publication证据与发布L-E1 把替换项发布成第二行验收项L-E11b 在被评审者已接受的检查上发新轮次L-D*Product and interaction contracts产品与交互契约L-D1 按视觉印象重建规范表面L-D2 双 scope 只应用到一个批量动作L-S*Environment safety环境安全L-S5 不验证 CDP 9222 的属主L-S7 通过早于安装的 dev server 验证依赖级修复追加规则同样严格新条目必须加到其所属类别内、取该前缀下一个空闲编号永远不追加到文件最后一条之后——类别边界本身就是结构约束。3. field notes 中保留的五条 LobeHub 平台级残案例按文件头部说明历史上积累的大部分案例已晋升通用层本文件剩下的是verify / Acceptance 页面机制与权限面permission-surface框架相关的 LobeHub 专属细节。以下逐条完整继承其“错误做法 / 为何错误 / 会破坏什么 / 正确做法”四段结构。3.1 Case 26第一例把状态徽章当成信息层级错误做法远程设备行在右侧详情位置渲染一个大而泛化的 “Online” 徽章主机名、平台、作用域被压到设备名下的一行低强调副文本对应工具 Inspector 里还漏掉了设备图标。为何错误在线状态是设备标识的一个紧凑属性而主机名、平台、scope 才是用户区分相似机器的关键细节。把整条右边缘让给状态等于把信息层级倒置图标缺失还会让折叠态的工具调用更难扫读混合文本组件的行高甚至会让 Inspector 计数在视觉上错位。会破坏什么设备行把最强的元数据区域浪费在重复状态上相似设备难以对比折叠工具链看起来视觉未完结。正确做法列表 Inspector 放平台中性的设备图标计数文本用显式共享行盒对齐设备名旁放语义化状态点 本地化状态文案右栏留给主机名、平台、scope。并用真实聊天截图验证展开行与零计数 Inspector 两种形态。这一案例在维护目录中被压缩为不变式级别的条目其对应的产品契约思想与 L-D4“不要把列表行硬拉成详情表面”列表控件与详情读/决策任务互相竞争一脉相承。3.2 Case 25为某个表面建“孪生”却不逐功能走查兄弟实现错误做法要求表面 B“与”既有表面 A列表面板、证据渲染器、链接 chip“保持一致”时只扫一眼 A 的视觉语言颜色、间距、组件选型就凭印象重建 B。某次运行里因此丢掉了A 的搜索框、A 的 before/after 对比渲染、A 的报告字段约定title / verdict / 对比标签还有一个 hover 态与预期的文本强调语义自相矛盾。为何错误所谓“一致性”是对兄弟功能的清单核对不是风格匹配。兄弟有而孪生缺的每个能力都是用户晚一张截图就会发现的 bug。ux 技能里那句“compose the canonical surface component, dont re-derive it组装规范表面组件不要重新推导”正好覆盖此问题但前提是动手前真正枚举过兄弟实现。会破坏什么用户得到一个“看起来对 90%”但缺承重功能的表面以及一轮本可用 10 分钟兄弟走查避免的“为什么这里缺 X / 丢了 Y”反馈“对齐”一词的可信度被透支。正确做法建孪生表面前逐功能枚举兄弟实现——对其组件 grep 每个已渲染的交互点搜索、空态、对比视图、hover 行为、抽屉接线与数据约定作者必须供给哪些字段把清单变成构建 checklist构建后在截图里把两个表面并排 diff 再发布。对于手工制品result.json重读报告参考里的字段规范而不是凭记忆写title与summary.verdict是身份字段对比对需要每一侧各自的label。对应维护目录中的 L-D1“Rebuilding a canonical surface from visual impression”。3.3 Case 20(a)把替换项发布成第二行验收项并用纯文本证据放行 UI错误做法给一个精化后的检查项分配新 id 却不声明supersedes然后仅凭单测输出或计算样式文本就标记视觉 UI 检查通过没有为每个声称的表面捕获并打开截图。某次布局探针还因为“侧栏右对齐”就放行了一个绝对定位、实际盖住报告正文的侧边栏。为何错误Acceptance 的 union故意不做模糊标题匹配没有显式替换边两个 id 就是两条独立且都有效的需求。程序输出证明的是逻辑不是渲染出的 Markdown 实体也不是“无视觉重叠”。单一 CSS 属性不构成布局契约。会破坏什么被取代的旧文案以重复行形式留存UI 变更没有可检查的证据绿色报告里可能真的盖住了自己的内容。正确做法新检查语义上替代旧需求时把旧稳定 id 写进新 plan 项的supersedes数组每个用户可见的 UI 用例必须要求自己的截图打开该图后再判过并断言完整空间结果右侧贴附 零重叠而不是孤立的 computed-style 值绝不把一张截图复用为不相干 UI 用例的证据。supersedes机制在服务端有真实实现可查acceptanceService.ts 中计划项的supersedes会把它替换的行折叠进当前行如const supersedes (row.planItem?.supersedes ?? []).map(...)与注释 “a plan itemssupersedesfolds the ids of checks it REPLACES into this row”合并逻辑在 acceptanceMerge.ts并有 acceptanceUnion.test.ts 等测试钉住行为。这也解释了为什么维护目录的 L-E1 要求“先声明替换边再给每个可见用例打开的视觉证据”。3.4 Case 20(b)把服务端权限变更当作“无 UI 表面”只交 API 转录报告文件头部注明通用层已覆盖宽泛规则触碰 UI 的变更需要视觉证据本条保留的是 LobeHub 特有的把授权/权限变更视为 UI 表面的框架若将来不再 LobeHub 专属则候选泛化上游。错误做法一个只改 TRPC 路由收紧谁能变更共享资源的改动被归类为纯后端发布的 verify 报告证据全是 curl / API 探针转录。用户打开报告后只问了一句“完全没有截图吗”为何错误权限收紧本身就是 UI 可见状态——被阻止的用户仍然看得到编辑/删除入口点击后得到一个拒绝错误 toast / 失败动作。“diff 不碰任何 .tsx 文件”不等于“没有 UI 表面”UI 表面是这个改动所改变的产品行为不是它编辑的文件。会破坏什么报告无法展示真实被阻用户的体验拒绝是被清晰呈现、被静默吞掉、还是原始报错也漏掉了截图本可暴露的 UX 后续项例如对必然被拒的用户应隐藏/禁用的入口。正确做法任何授权/权限变更除了 API 探针还要以被阻角色驱动真实 UI并截图拒绝态以及允许角色的成功态如果拒绝呈现为原始或缺失的错误文案把它作为发现项finding报告出来而不是让它保持未被发现。3.5 Case 26第二例双 scope 只应用于一个批量维护动作错误做法为某个批量动作引入了 own-scope 与 workspace-scope 两个变体却把相邻的维护动作留在仅 owner-own。为何错误权限是按“菜单条目”逐条评估的而不是按完整的角色 × 动作 × scope 矩阵评估。正确做法枚举矩阵每个单元格member 只拿到 own-only 动作owner 对每个适用动作拿到 own 与 workspace 两个变体破坏性的 workspace 级操作附加强化确认。即维护目录的 L-D2。注意 field notes 中两个案例共用编号 26——这正是文件头部所说的“案例保留原始编号以便旧引用可解析”的直接体现编号是历史锚点不是排序号。4. 横切禁令永远不要用 OAuth 流程获取 Electron 登录态文件末尾有一条无编号但反复被引用的硬规则Never acquire Electron auth through the OAuth flow — inject state instead绝不通过 OAuth 流程获取 Electron 登录改为注入状态。错误做法在一个登出状态的桌面实例上照旧版 auth.md 的配方去调用remoteServerService.requestAuthorization(...)或点击应用里的 “Sign in”来“自己驱动登录”。为何错误桌面主进程控制器 AuthCtr.ts 通过shell.openExternal实现该流程源码中await shell.openExternal(authUrl.toString())可在 AuthCtr.ts 附近看到因此每次尝试都会在用户默认浏览器里弹出一个登录/授权页——可见地、在用户的机器上、重试时反复弹出。开发实例还跑在按实例分配的端口上localhost:3024……授权 URL 指向的 localhost 来源其 session/callback 通常无法完成用户只会积累一堆坏掉的登录 tab。会破坏什么劫持用户个人浏览器会话、把测试活动泄进其真实浏览上下文、侵蚀对自动化运行的信任。正确做法登录态只能注入不能交互获取——① 恢复electron-login快照login-status/save-login② 通过 CLI/API seeding 铸造 sessionweb-seed的思路③ 都不行就报告 auth 为 ❌ Blocked并请求一次手动登录。修正后的策略落在 auth.md 的 “When the instance comes up signed out” 一节以及 PROJECT.md §4 Electron。auth.md 对这条禁令做了完整展开值得随附三条它点名的令牌陷阱刷新令牌每次启动都轮换——只有最后启动的实例持有可用 refresh token所以必须用electron-dev.sh stop会先快照登录到~/.lobehub/agent-testing/electron-login再清目录而不是 kill 实例被 kill 的实例其轮换后的令牌随之死亡。encryptedTokens.expiresAt是访问令牌的过期时间而非刷新令牌的——它是 RemoteServerConfigCtr.saveTokens 里Date.now() data.expires_in * 1000的结果一个完全可刷新的登录也会“过期”绝不能拿它决定是否保留配置真正表示登出的信号是refreshToken缺失刷新不可重试失败时应用调用clearTokens()删除整个encryptedTokens键。令牌缺失也未必等于登出——better-auth cookie 可能比它活得更久。stop/save-login会探测运行中的渲染进程取用户 id因此纯 cookie 会话也能被快照捕获只看磁盘令牌会漏掉这种情况。配套的注入工具链同样以脚本固化setup-auth.sh提供status全表面、status --surface electron、web-seed、cli-seed等命令登录态检查标准化为app-probe.sh auth返回{ isSignedIn, userId }禁止手写window.__LOBE_STORESeval见 PROJECT.md §3。5. 把 field notes 放回工作流读、晋升、引用三层文档在运行中的协作顺序可以从 PROCESS.md 与 PROJECT.md 的引用关系读出读Plan 阶段 Step 0 要求先确定测试目标再读全两层活日志通用 项目。field notes 属于“详细事故叙事可选读”——它让历史细节保持可查询而不构成每次运行的强制阅读晋升任何负面反馈先过五条准入门禁“太依赖实现”的候选被分流到规格、组件、回归测试或references/probe-field-notes.md而不是直接丢弃。当一条 field notes 条目被发现其实与产品无关时文件头部的指示是把 LobeHub 名词去掉、泛化后 PR 到lobehub/cli的通用层引用维护目录条目内部用[[L-E1]]、[[L-S7]]这类 wikilink 交叉引用field notes 保留原始案例编号保证跨层引用不断链。例如 common-mistakes.md 的 L-E11b 在解释“已接受检查需要新 id”时直接回链 L-E1而 L-E1 的完整事故叙事Case 20(a)就留在 field notes 里供需要时追溯。从源码结构看这套文档约束背后有服务端强制力supersedes折叠、已接受检查的粘性sticky accept等行为由 acceptanceService.ts 计算并由 acceptanceMerge.test.ts、acceptanceUnion.test.ts、acceptanceSettledCheck.test.ts 以测试钉住Electron 侧的shell.openExternal授权行为则可在 AuthCtr.test.ts 中验证。文档中的每条“正确做法”并非纯约定多数都对应着可测试的实现事实。6. 小结common-mistakes-field-notes.md 的价值不在于五条案例本身而在于它示范了一套可持续演化的验证知识管理方式分层通用层技能随附、只读、按 PR 演进承载产品无关规则项目层 common-mistakes.md可写、L-编号、三分类承载 LobeHub 不变式field notes 保留晋升后的历史叙事编号不动准入五条门禁保证日志只收“可复用、项目相关、不变式级、不重复、可行动”的条目细节分流到规格/组件/测试强一致supersedes折叠、检查 id 复用规则、截图必须打开后判过、权限变更必须驱动真实 UI——这些“正确做法”在 acceptanceService.ts 与技能 SKILL.md 的硬规则HARD RULE程序化门禁永远不是验收检查轮次不可变修复意味着新一轮中互为镜像环境安全Electron 登录只注入不交互获取配套electron-dev.sh快照/播种与三条令牌陷阱杜绝自动化运行劫持用户浏览器。如果你的仓库也要搭建自验收self-acceptance体系这套“技能通用层 项目适配器PROJECT.md/PROCESS.md/ 活日志 / field notes”的分层以及与 PROJECT.md §5 探针脚本app-probe.sh、setup-auth.sh、test-env.sh配套的标准化检查手段是一个可以直接参照的模板。【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LobeHub Acceptance 验收机制：双层失误目录、supersedes 替换规则与 Electron 登录注入策略
LobeHub Acceptance 验收机制双层失误目录、supersedes 替换规则与 Electron 登录注入策略【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehubLobeHub 的验收Acceptance体系由三层文档协作支撑可移植的通用技能、项目级“活日志”目录以及保留历史事故细节的田野笔记field notes。读完本篇你将理解 LobeHub 如何用“通用层 项目层”双层失误目录沉淀验证经验如何用supersedes声明管理检查项的替换关系以及为什么自动化验证在 LobeHub 桌面端被明令禁止触发 OAuth 登录流程、必须改用登录态注入。1. 定位field notes 是双层失误目录中的“历史残留层”本文的主体文件是 common-mistakes-field-notes.md。它开头就声明了自己的身份历史项目层素材historical project-layer source material。当前真正被维护的目录是同级的 common-mistakes.md新条目必须使用稳定的L-前缀标识符追加到后者而本文件保留的旧案例维持原始编号这样更老的交叉引用依然可以解析——某个案例若在本文件中找不到说明它已经被泛化genericize后晋升到了通用层。两层目录的分工在 PROCESS.md 的 Step 0 中有明确规定执行任何验收运行前必须同时读全两层——通用层随技能分发本仓库中只读.agents/skills/acceptance/references/common-mistakes.md与probe-mock-patterns.md。该技能路径在仓库内是符号链接指向技能源码packages/builtin-skills/src/acceptance/见 PROJECT.md 开头说明。通用层的更新方式是向lobehub/cli提 PR项目层可写、属于本仓库common-mistakes.md 与 probe-mock-patterns.md。晋升promote到通用层的判定标准是 PROCESS.md Step 0 的五条准入门禁任何一条负面反馈要入日志都必须通过Durable可复现性——换一个人、换一个功能轮次是否还会遇到Project-specific项目相关性——是否依赖 LobeHub 的产品语义、环境或基础设施若否就应去掉 LobeHub 名词泛化后 PR 到技能源Invariant-level不变式层级——陈述行为或证据契约而不是冻结某个具体解法像素值、图标选择、标注坐标属于规格/组件/回归测试的领地Non-duplicative不重复——先搜索两层底层失败相同则修订既有案例Actionable可行动——未来的验证者能否据此选择不同的动作、或拒绝无效证据。这个设计解释了为什么 common-mistakes.md 自称是“curated log策展过的日志而非评审反馈的流水记录”它只保留 LobeHub 产品和环境的持久不变式而把逐条事故的叙事细节下沉到 field notes 与references/probe-field-notes.md使“每次验收运行必读”的成本可控。2. 目录本体L-标识符与三类不变式维护目录 common-mistakes.md 用L-前缀避免与通用层的M目录混淆并强制把每条失误归入三类标识符前缀即类别名前缀类别典型条目L-E*Evidence and publication证据与发布L-E1 把替换项发布成第二行验收项L-E11b 在被评审者已接受的检查上发新轮次L-D*Product and interaction contracts产品与交互契约L-D1 按视觉印象重建规范表面L-D2 双 scope 只应用到一个批量动作L-S*Environment safety环境安全L-S5 不验证 CDP 9222 的属主L-S7 通过早于安装的 dev server 验证依赖级修复追加规则同样严格新条目必须加到其所属类别内、取该前缀下一个空闲编号永远不追加到文件最后一条之后——类别边界本身就是结构约束。3. field notes 中保留的五条 LobeHub 平台级残案例按文件头部说明历史上积累的大部分案例已晋升通用层本文件剩下的是verify / Acceptance 页面机制与权限面permission-surface框架相关的 LobeHub 专属细节。以下逐条完整继承其“错误做法 / 为何错误 / 会破坏什么 / 正确做法”四段结构。3.1 Case 26第一例把状态徽章当成信息层级错误做法远程设备行在右侧详情位置渲染一个大而泛化的 “Online” 徽章主机名、平台、作用域被压到设备名下的一行低强调副文本对应工具 Inspector 里还漏掉了设备图标。为何错误在线状态是设备标识的一个紧凑属性而主机名、平台、scope 才是用户区分相似机器的关键细节。把整条右边缘让给状态等于把信息层级倒置图标缺失还会让折叠态的工具调用更难扫读混合文本组件的行高甚至会让 Inspector 计数在视觉上错位。会破坏什么设备行把最强的元数据区域浪费在重复状态上相似设备难以对比折叠工具链看起来视觉未完结。正确做法列表 Inspector 放平台中性的设备图标计数文本用显式共享行盒对齐设备名旁放语义化状态点 本地化状态文案右栏留给主机名、平台、scope。并用真实聊天截图验证展开行与零计数 Inspector 两种形态。这一案例在维护目录中被压缩为不变式级别的条目其对应的产品契约思想与 L-D4“不要把列表行硬拉成详情表面”列表控件与详情读/决策任务互相竞争一脉相承。3.2 Case 25为某个表面建“孪生”却不逐功能走查兄弟实现错误做法要求表面 B“与”既有表面 A列表面板、证据渲染器、链接 chip“保持一致”时只扫一眼 A 的视觉语言颜色、间距、组件选型就凭印象重建 B。某次运行里因此丢掉了A 的搜索框、A 的 before/after 对比渲染、A 的报告字段约定title / verdict / 对比标签还有一个 hover 态与预期的文本强调语义自相矛盾。为何错误所谓“一致性”是对兄弟功能的清单核对不是风格匹配。兄弟有而孪生缺的每个能力都是用户晚一张截图就会发现的 bug。ux 技能里那句“compose the canonical surface component, dont re-derive it组装规范表面组件不要重新推导”正好覆盖此问题但前提是动手前真正枚举过兄弟实现。会破坏什么用户得到一个“看起来对 90%”但缺承重功能的表面以及一轮本可用 10 分钟兄弟走查避免的“为什么这里缺 X / 丢了 Y”反馈“对齐”一词的可信度被透支。正确做法建孪生表面前逐功能枚举兄弟实现——对其组件 grep 每个已渲染的交互点搜索、空态、对比视图、hover 行为、抽屉接线与数据约定作者必须供给哪些字段把清单变成构建 checklist构建后在截图里把两个表面并排 diff 再发布。对于手工制品result.json重读报告参考里的字段规范而不是凭记忆写title与summary.verdict是身份字段对比对需要每一侧各自的label。对应维护目录中的 L-D1“Rebuilding a canonical surface from visual impression”。3.3 Case 20(a)把替换项发布成第二行验收项并用纯文本证据放行 UI错误做法给一个精化后的检查项分配新 id 却不声明supersedes然后仅凭单测输出或计算样式文本就标记视觉 UI 检查通过没有为每个声称的表面捕获并打开截图。某次布局探针还因为“侧栏右对齐”就放行了一个绝对定位、实际盖住报告正文的侧边栏。为何错误Acceptance 的 union故意不做模糊标题匹配没有显式替换边两个 id 就是两条独立且都有效的需求。程序输出证明的是逻辑不是渲染出的 Markdown 实体也不是“无视觉重叠”。单一 CSS 属性不构成布局契约。会破坏什么被取代的旧文案以重复行形式留存UI 变更没有可检查的证据绿色报告里可能真的盖住了自己的内容。正确做法新检查语义上替代旧需求时把旧稳定 id 写进新 plan 项的supersedes数组每个用户可见的 UI 用例必须要求自己的截图打开该图后再判过并断言完整空间结果右侧贴附 零重叠而不是孤立的 computed-style 值绝不把一张截图复用为不相干 UI 用例的证据。supersedes机制在服务端有真实实现可查acceptanceService.ts 中计划项的supersedes会把它替换的行折叠进当前行如const supersedes (row.planItem?.supersedes ?? []).map(...)与注释 “a plan itemssupersedesfolds the ids of checks it REPLACES into this row”合并逻辑在 acceptanceMerge.ts并有 acceptanceUnion.test.ts 等测试钉住行为。这也解释了为什么维护目录的 L-E1 要求“先声明替换边再给每个可见用例打开的视觉证据”。3.4 Case 20(b)把服务端权限变更当作“无 UI 表面”只交 API 转录报告文件头部注明通用层已覆盖宽泛规则触碰 UI 的变更需要视觉证据本条保留的是 LobeHub 特有的把授权/权限变更视为 UI 表面的框架若将来不再 LobeHub 专属则候选泛化上游。错误做法一个只改 TRPC 路由收紧谁能变更共享资源的改动被归类为纯后端发布的 verify 报告证据全是 curl / API 探针转录。用户打开报告后只问了一句“完全没有截图吗”为何错误权限收紧本身就是 UI 可见状态——被阻止的用户仍然看得到编辑/删除入口点击后得到一个拒绝错误 toast / 失败动作。“diff 不碰任何 .tsx 文件”不等于“没有 UI 表面”UI 表面是这个改动所改变的产品行为不是它编辑的文件。会破坏什么报告无法展示真实被阻用户的体验拒绝是被清晰呈现、被静默吞掉、还是原始报错也漏掉了截图本可暴露的 UX 后续项例如对必然被拒的用户应隐藏/禁用的入口。正确做法任何授权/权限变更除了 API 探针还要以被阻角色驱动真实 UI并截图拒绝态以及允许角色的成功态如果拒绝呈现为原始或缺失的错误文案把它作为发现项finding报告出来而不是让它保持未被发现。3.5 Case 26第二例双 scope 只应用于一个批量维护动作错误做法为某个批量动作引入了 own-scope 与 workspace-scope 两个变体却把相邻的维护动作留在仅 owner-own。为何错误权限是按“菜单条目”逐条评估的而不是按完整的角色 × 动作 × scope 矩阵评估。正确做法枚举矩阵每个单元格member 只拿到 own-only 动作owner 对每个适用动作拿到 own 与 workspace 两个变体破坏性的 workspace 级操作附加强化确认。即维护目录的 L-D2。注意 field notes 中两个案例共用编号 26——这正是文件头部所说的“案例保留原始编号以便旧引用可解析”的直接体现编号是历史锚点不是排序号。4. 横切禁令永远不要用 OAuth 流程获取 Electron 登录态文件末尾有一条无编号但反复被引用的硬规则Never acquire Electron auth through the OAuth flow — inject state instead绝不通过 OAuth 流程获取 Electron 登录改为注入状态。错误做法在一个登出状态的桌面实例上照旧版 auth.md 的配方去调用remoteServerService.requestAuthorization(...)或点击应用里的 “Sign in”来“自己驱动登录”。为何错误桌面主进程控制器 AuthCtr.ts 通过shell.openExternal实现该流程源码中await shell.openExternal(authUrl.toString())可在 AuthCtr.ts 附近看到因此每次尝试都会在用户默认浏览器里弹出一个登录/授权页——可见地、在用户的机器上、重试时反复弹出。开发实例还跑在按实例分配的端口上localhost:3024……授权 URL 指向的 localhost 来源其 session/callback 通常无法完成用户只会积累一堆坏掉的登录 tab。会破坏什么劫持用户个人浏览器会话、把测试活动泄进其真实浏览上下文、侵蚀对自动化运行的信任。正确做法登录态只能注入不能交互获取——① 恢复electron-login快照login-status/save-login② 通过 CLI/API seeding 铸造 sessionweb-seed的思路③ 都不行就报告 auth 为 ❌ Blocked并请求一次手动登录。修正后的策略落在 auth.md 的 “When the instance comes up signed out” 一节以及 PROJECT.md §4 Electron。auth.md 对这条禁令做了完整展开值得随附三条它点名的令牌陷阱刷新令牌每次启动都轮换——只有最后启动的实例持有可用 refresh token所以必须用electron-dev.sh stop会先快照登录到~/.lobehub/agent-testing/electron-login再清目录而不是 kill 实例被 kill 的实例其轮换后的令牌随之死亡。encryptedTokens.expiresAt是访问令牌的过期时间而非刷新令牌的——它是 RemoteServerConfigCtr.saveTokens 里Date.now() data.expires_in * 1000的结果一个完全可刷新的登录也会“过期”绝不能拿它决定是否保留配置真正表示登出的信号是refreshToken缺失刷新不可重试失败时应用调用clearTokens()删除整个encryptedTokens键。令牌缺失也未必等于登出——better-auth cookie 可能比它活得更久。stop/save-login会探测运行中的渲染进程取用户 id因此纯 cookie 会话也能被快照捕获只看磁盘令牌会漏掉这种情况。配套的注入工具链同样以脚本固化setup-auth.sh提供status全表面、status --surface electron、web-seed、cli-seed等命令登录态检查标准化为app-probe.sh auth返回{ isSignedIn, userId }禁止手写window.__LOBE_STORESeval见 PROJECT.md §3。5. 把 field notes 放回工作流读、晋升、引用三层文档在运行中的协作顺序可以从 PROCESS.md 与 PROJECT.md 的引用关系读出读Plan 阶段 Step 0 要求先确定测试目标再读全两层活日志通用 项目。field notes 属于“详细事故叙事可选读”——它让历史细节保持可查询而不构成每次运行的强制阅读晋升任何负面反馈先过五条准入门禁“太依赖实现”的候选被分流到规格、组件、回归测试或references/probe-field-notes.md而不是直接丢弃。当一条 field notes 条目被发现其实与产品无关时文件头部的指示是把 LobeHub 名词去掉、泛化后 PR 到lobehub/cli的通用层引用维护目录条目内部用[[L-E1]]、[[L-S7]]这类 wikilink 交叉引用field notes 保留原始案例编号保证跨层引用不断链。例如 common-mistakes.md 的 L-E11b 在解释“已接受检查需要新 id”时直接回链 L-E1而 L-E1 的完整事故叙事Case 20(a)就留在 field notes 里供需要时追溯。从源码结构看这套文档约束背后有服务端强制力supersedes折叠、已接受检查的粘性sticky accept等行为由 acceptanceService.ts 计算并由 acceptanceMerge.test.ts、acceptanceUnion.test.ts、acceptanceSettledCheck.test.ts 以测试钉住Electron 侧的shell.openExternal授权行为则可在 AuthCtr.test.ts 中验证。文档中的每条“正确做法”并非纯约定多数都对应着可测试的实现事实。6. 小结common-mistakes-field-notes.md 的价值不在于五条案例本身而在于它示范了一套可持续演化的验证知识管理方式分层通用层技能随附、只读、按 PR 演进承载产品无关规则项目层 common-mistakes.md可写、L-编号、三分类承载 LobeHub 不变式field notes 保留晋升后的历史叙事编号不动准入五条门禁保证日志只收“可复用、项目相关、不变式级、不重复、可行动”的条目细节分流到规格/组件/测试强一致supersedes折叠、检查 id 复用规则、截图必须打开后判过、权限变更必须驱动真实 UI——这些“正确做法”在 acceptanceService.ts 与技能 SKILL.md 的硬规则HARD RULE程序化门禁永远不是验收检查轮次不可变修复意味着新一轮中互为镜像环境安全Electron 登录只注入不交互获取配套electron-dev.sh快照/播种与三条令牌陷阱杜绝自动化运行劫持用户浏览器。如果你的仓库也要搭建自验收self-acceptance体系这套“技能通用层 项目适配器PROJECT.md/PROCESS.md/ 活日志 / field notes”的分层以及与 PROJECT.md §5 探针脚本app-probe.sh、setup-auth.sh、test-env.sh配套的标准化检查手段是一个可以直接参照的模板。【免费下载链接】lobehub LobeHub is your Chief Agent Operator, organizing your agents into 7×24 operations by hiring, scheduling, and reporting on your entire AI team.项目地址: https://gitcode.com/GitHub_Trending/lo/lobehub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考