人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载本篇文章基于 oh-my-openagent 仓库.omo/evidence/omo-senpi-adapter/memory-v2/F2/quality.md评审证据完整还原一次针对feat/memory-v2-active-learning分支的F2 代码质量评审包括评审范围与方法、八个检查维度的判定标准、全部违规清单与严重级别以及后续整改A1/A3 重做、文件拆分、测试重构直至 F2-rerun 复评通过PASS的完整闭环。读完本文你将掌握该项目在文件规模上限、空 catch、Unicode 字符、测试纪律、确定性测试等维度上可落地的质量红线并能将其复用到自己的大型 TypeScript 仓库评审中。评审背景F1F4 门禁体系中的 F2 环节在 oh-my-openagent 的 evidence 体系见 .omo/evidence中功能分支合入前要经过多道门禁。memory-v2 分支的评审证据存放在 .omo/evidence/omo-senpi-adapter/memory-v2 目录下F1计划合规审计F1-final2/compliance.md 显示最终PASS逐行核对musthave.md检查清单并使用git show HEAD:path对提交 blob 做逐字验证F2代码质量评审本文主体初始FAILF3功能 QA含 qa-driver.mjs、transcript、session 文件等运行证据F4范围核验F4/scope.md。F2 评审针对的分支为feat/memory-v2-active-learning对比基线为origin/dev..HEAD结论是F2: FAIL。评审还明确了边界排除.omo/、docs/、packages/omo-senpi/plugin/extensions/*.js与install-dist等生成物只对真正的人写代码负责。评审范围与方法论223 个触碰文件如何被量化审计F2 报告在Scope and method一节给出了可复现的审计口径排除上述目录后共审阅223 个触碰文件深度源码审阅覆盖148 个触碰的.ts、.tsx、.mjs与非生成.js文件重点在packages/memory-core与packages/omo-senpi下的145 个 TypeScript 文件memory-v2 正是 memory-core 与 omo-senpi 两包联动的主动学习记忆功能审阅53 个触碰的测试文件检查点包括given/when/then 结构、被禁止的散文 pinprose pins、快照、长度上限、非确定性等待Pure LOC 定义非空、非注释行。注释剥离时保留字符串与模板字面量内容因此可执行的多行模板内容计入源码行数——这是一个值得注意的计量口径防止用把逻辑塞进模板字符串绕过规模红线分支新增行单独检查抑制指令suppressions、Unicode 破折号、emoji、Arrange/Act/Assert 措辞、定时器调用。在origin/dev上已存在的历史 Unicode 行按约定豁免。这一方法论的要点在于分支增量归因只用git merge-base界定新增行避免把基线旧代码的存量问题算到新功能头上这一点在后续 F2-rerun 中被再次强调。检查维度一抑制与空 catch——两个功能上为空的分支违规第一类违规针对异常吞噬。评审表指出文件行号问题严重级别packages/omo-senpi/src/components/memory/worker/spawn.ts138-140仅含注释的catch {}静默吞掉所有chmod失败而非只吞预期的文件不存在场景功能上等价于空 catchVIOLATION同文件232-234第二个仅含注释的catch {}同样吞掉所有chmod失败VIOLATION空 catch 的典型危害chmod因权限EPERM/EACCES或磁盘问题失败时错误被静默吞掉后续逻辑可能在错误假设上继续执行导致难以排查的静默损坏。评审同时确认范围内没有as any、ts-ignore、ts-expect-error也没有触碰名为utils.ts、helpers.ts、service.ts的catch-all文件。有趣的是在当前仓库 HEADdev分支中worker/spawn.ts已经被整改为仅 3 行的 export-only 兼容桶见 spawn.ts原chmod准备逻辑拆入 spawn-payload.ts。在 spawn-payload.ts 第 48 行与第 213 行可以看到修复后的精确写法if (errorCode(error) ! ENOENT) throw error——只吞文件不存在这一预期场景其余错误一律重新抛出这正是 F2-rerun 中Category 1: PASS的依据。检查维度二文件纪律——250 行硬上限与 200 行软上限评审对文件规模执行两档红线硬上限hard ceiling纯 LOC 超过250 行即违规VIOLATION软上限soft limit201250 行记 NOTE不阻断但要求知晓。硬上限违规清单21 个文件文件Pure LOC备注packages/memory-core/src/facts/extraction.test.ts319新增文件packages/memory-core/src/facts/queue.test.ts268新增文件packages/memory-core/src/git/repo.ts288自 230 增长packages/memory-core/src/people/format.test.ts373新增文件packages/memory-core/src/tools/memory-apply-patch.test.ts266自 253 增长packages/memory-core/src/tools/memory.test.ts260自 240 增长packages/omo-config-core/src/schema/memory.test.ts278自 102 增长packages/omo-senpi/plugin/scripts/install.mjs436自 435 增长生成脚本packages/omo-senpi/src/components/memory/dream-selector.ts277新增文件packages/omo-senpi/src/components/memory/dream-trigger.test.ts491新增文件packages/omo-senpi/src/components/memory/dream-trigger.ts282新增文件packages/omo-senpi/src/components/memory/facts-runner.test.ts262新增文件packages/omo-senpi/src/components/memory/facts-runner.ts402新增文件packages/omo-senpi/src/components/memory/palace/template.ts473自 391 增长packages/omo-senpi/src/components/memory/skills-usage.test.ts265新增文件packages/omo-senpi/src/components/memory/tools.test.ts292自 233 增长packages/omo-senpi/src/components/memory/trigger-wiring.test.ts362自 306 增长packages/omo-senpi/src/components/memory/wiring.ts434自 248 增长packages/omo-senpi/src/components/memory/worker/runner.ts284自 243 增长packages/omo-senpi/src/components/memory/worker/spawn.ts521自 219 增长packages/omo-senpi/src/install/install-senpi.ts262自 261 增长注意 21 个违规中有 11 个是新增测试文件——说明在 memory-v2 的开发过程中测试规模尤其 dream-trigger 的 491 行、people/format 的 373 行是文件规模超限的重灾区。软上限记录201250 行软上限清单涵盖 20 个文件包括packages/memory-core/src/facts/extraction.ts221、packages/memory-core/src/facts/person-routing.ts238、packages/memory-core/src/facts/queue.ts212、packages/memory-core/src/journal/store.ts245、packages/memory-core/src/people/format.ts241、packages/memory-core/src/reflection/machine.ts229、packages/memory-core/src/reflection/reservation.ts228、packages/memory-core/src/tools/memory-apply-patch.ts226、packages/memory-core/src/tools/memory.ts240以及packages/omo-senpi下的plugin/scripts/build-extension.mjs243、components/memory/skills-usage.ts245、components/memory/mcp/memory-server.ts218、components/memory/worker/memory-run-supervisor.integration.test.ts241等。软上限不阻断但意味着这些文件已接近红线后续任何增长都可能升级为违规。从源码结构看packages/memory-core/src/facts/queue.ts当前仍是一个承载持久化事实队列listPendingUnlocked、readClaimsUnlocked、readConsumedUnlocked等锁内私有方法见 queue.ts的单文件实现这类重活正是 250 行上限设计要逼着开发者拆分的原因。检查维度三Barrel 文件纪律评审检查index.ts是否只是纯导出桶export-only barrel。唯一记录项为文件行号问题严重级别packages/omo-senpi/src/components/memory/index.ts1-224该入口承载逻辑实现非纯导出且本分支还在其中追加实现NOTE因该模式在分支之前就已存在pre-existing评审将其记为架构性注记而非硬性 F2 失败项。其余触碰的index.ts均确认为纯导出桶。这给了读者一个可复用的判断标准入口文件名index.ts不必然豁免于逻辑承载组件入口若承载逻辑应在评审中单独点名。检查维度四测试风格——given/when/then 与禁用 AAA 措辞评审结论为未发现测试风格违规每个范围内触碰的测试文件都使用嵌套或行内 given/when/then 标记没有引入Arrange-Act-Assert 措辞。这呼应了仓库内 .omo/rules/test-discipline.md 的纪律要求——测试必须围绕行为而非文本措辞组织。given/when/then 与 AAA 只是风格差异但该项目将其固化为门禁说明一致性本身也是质量的一部分。检查维度五源码中的 Emoji 与 Unicode 破折号评审对分支新增的源码行执行了字符级检查禁止字面 emoji 与 Unicode 破折号en dashU2013、em dashU2014文件行号问题严重级别packages/omo-config-core/src/schema/memory.ts44分支新增源码注释含一个 em dashVIOLATIONpackages/omo-senpi/src/components/memory/commands/doctor.test.ts63-65分支新增 TS fixture 含三个 em dash字节可能是历史沿用但规则无源码 fixture 例外VIOLATIONpackages/omo-senpi/src/components/memory/dream-selector.test.ts158、192分支新增测试数据含 emoji是有用的 UTF-8 测试数据但违反字面 no-emoji 源码规则emoji 不在硬失败清单内因此此处不阻断NOTE未发现引入 en dash。这条红线背后的工程理由源码文本的字节级一致性终端渲染、跨平台 diff、LLM 生成回归远比看起来美观重要尤其是当测试数据中混入肉眼难以分辨的 Unicode 破折号时会污染 diff 可读性。检查维度六Zod 边界与文件名规范该项目大量使用 Zod 做运行时 schema 校验。评审发现 6 处进程边界/持久化边界未走 Zod的记录均为 NOTE非阻断文件行号问题packages/memory-core/src/facts/schema.ts107-218持久化队列、游标、consumed JSON 边界用手写 record guard 而非 Zod schemapackages/memory-core/src/facts/extraction.ts65-223子进程产出的 JSONL 在进程边界用手工解析校验而非 Zodpackages/omo-senpi/src/components/memory/dream-selector.ts214-232持久化 dream 状态用JSON.parse 手工 narrowing 而非 Zodpackages/omo-senpi/src/components/memory/skills-usage.ts124-151持久化 skill-usage JSON 手工 narrowing 而非 Zodpackages/omo-senpi/src/components/memory/worker/run-artifacts.ts31-33readRunJsonT直接从JSON.parse做未检查的泛型强转该边界无运行时校验packages/omo-senpi/src/mcp/memory-server.ts130-139MCP 参数被断言为MemoryToolParams旁注注释明确把校验委托出去而非应用边界 schema从当前源码看packages/omo-config-core/src/schema/memory.ts确实大量使用z.object(...).strict()定义 recall/nudge 等配置 schema见 memory.ts 第 38-53 行说明Zod 优先是项目约定只是 memory-v2 的部分持久化边界尚未迁移。评审将其定为 NOTE 而非 VIOLATION符合边界 schema 缺失是架构风险而非硬错误的定位。文件名维度全部通过所有触碰代码文件均为 kebab-case。检查维度七测试纪律合规——散文 pin 与长度上限的七处违规这是四类最终失败项中覆盖面最广的一类全部为 VIOLATION文件行号问题packages/memory-core/src/compile/compile.test.ts66、89、127、145完整编译提示词输出与 golden 文本文件比对仅归一化一行 reminder 并不能阻止测试 pin 住其余散文与全文渲染同文件170、196正则断言 pin 散文措辞尽管已有稳定的机器 token 可断言packages/memory-core/src/tools/memory-apply-patch.test.ts302触碰的测试保留显式输出长度上限error.message.length 7000为测试纪律门禁所禁packages/omo-senpi/src/components/memory/commands/sleeptime.test.ts27-104新增断言 pin 大量面向用户的输出短语如Nudge: on、Dream: on与 override 措辞而非断言解析后的机器消费值packages/omo-senpi/src/components/memory/commands/doctor.test.ts201新增断言 pin 用户可见短语manual disposal而稳定诊断 key 已单独断言packages/omo-senpi/src/components/memory/commands/dream.test.ts185新增断言 pin 用户可见错误散文only senpi session JSONLpackages/omo-senpi/src/components/memory/commands/people.test.ts194-228、254、283、306新命令测试 pin 渲染散文与回答措辞而非结构化命令结果packages/omo-senpi/src/mcp/memory-server.test.ts129、192新增断言 pin 工具输出的完整成功短语提交状态与结构化回执已是现成的行为接缝评审同时明确未发现Jest/Bun 散文快照机器消费的基数检查如 active-plus-pending 预留数、配置的max_entries不视为散文长度上限是合规的。这些违规背后是 .omo/rules/test-discipline.md 中ASSERT BEHAVIOR, NOT TEXT断言行为而非文本的原则。规则明确列出被禁止的断言模式expect(prompt).toContain(You are Sisyphus) // 短语存在 pin expect(skill).not.toContain(old wording) // 短语缺失/旧措辞守卫 expect(prompt).toMatchSnapshot() // 散文快照 expect(prompt).toBe(EXPECTED_PROMPT) // 全文 pin expect(wordCount(workflow)).toBeLessThanOrEqual(3930) // 词/字符/LOC 上限 expect(md.match(/some phrase/g)?.length).toBe(1) // 短语出现次数规则给出的判定树是机器消费什么值就断言那个值解析 frontmatter 字段、运行真实消费者两个副本必须一致时用一次真实制品之间的相等断言纯散文改动且无机器消费者时不写自动化测试以评审 QA-by-read 代替——绿色文本 pin 是假覆盖率跳过测试才是诚实的结果。检查维度八测试确定性——无时序运气违规评审对新增测试做了时序审计结论是零违规facts-wiring.test.ts:95在触发前订阅确切的 launch promisesetTimeout仅作为有界失败熔断器shutdown-drain.test.ts:238在 dispatch 前安装 warning 回调同样用有界熔断器supervisor 集成测试在触发前订阅 filesystem/socket/stdout/child-exit 信号定时器仅用于超时拒绝新增测试中未发现固定 sleep、轮询延迟或等足够久式同步机制生产代码中的定时器与重试延迟不计入测试非确定性。这与 test-discipline 规则subscribe BEFORE the trigger, await the signal with an explicit timeout完全一致——监听器必须先于触发注册超时只是电路断路器而非同步原语若断言逻辑依赖超时先触发则测试本身是错的。最终失败项清单与整改闭环F2 评审将全部问题收敛为四类最终失败项两个功能上为空的 catch 块packages/omo-senpi/src/components/memory/worker/spawn.ts21 个文件超过 250 行纯 LOC 硬上限见硬上限表引入的 em dashpackages/omo-config-core/src/schema/memory.ts与packages/omo-senpi/src/components/memory/commands/doctor.test.ts被禁的测试形态compile golden 测试、散文短语 pin 测试、保留的输出长度上限。结论F2: FAIL。该分支随后的整改在 evidence 目录中留下完整轨迹A1修复、A3rework、task-13/task-16/task-19 等任务的 RED/GREEN 证据以及最终的F2-rerun 复评PASS。复评报告 F2-rerun/quality.md 显示四类失败全部关闭空 catchworker/spawn.ts拆分为 3 行纯导出兼容桶chmod逻辑移入spawn-payload.ts仅ENOENT被吞、其余 rethrow当前仓库 spawn-payload.ts 第 48/213 行可验证全树扫描零空 catchLOC 上限21 个文件全部降至 250 以下如dream-trigger.test.ts从 491 降至 75、spawn.ts从 521 降至 3仅 4 个任务批准的例外保留Unicodememory.ts改回 ASCII 连字符doctor.test.ts用\u2014转义保留历史字节渲染结果与历史 commit02a7d562e的 fixture 逐字节一致937 字节SHA-2562e96a09c...测试纪律compile 测试改为断言段落边界/投影路径/元数据apply-patch 测试删除长度上限改用类型化错误与截断标记sleeptime/doctor/dream/people/MCP 测试全部迁移到结构化行为接缝。复评的聚焦验证命令结果为69 pass / 0 fail / 177 expect() calls15 个文件27.01s且复评过程中未修改任何源码。从这份评审中可以提炼的工程实践量化红线要可复现pure LOC 定义剔除注释与空行但保留模板字面量、分支新增行用git merge-base归因保证任何审计者能复算出同一张表。空 catch 必须精确到异常类型catch (e) { if (code ! ENOENT) throw e }优于注释型catch {}这是 memory-v2 整改中最具可迁移价值的模式。散文与行为分离测试只允许断言机器消费的值解析字段、结构化回执、提交状态、诊断 key禁止 pin 用户可见措辞——这直接降低提示词迭代时的测试维护成本。确定性测试 先订阅、后触发、显式超时把setTimeout的角色严格限定为熔断器而非同步原语。评审证据本身即资产.omo/evidence 下的 F2 初评与复评对照F2/quality.md 与 F2-rerun/quality.md展示了失败清单 → 逐条整改 → 复评证明的完整审计闭环任何大型仓库的质量门禁都可以参考此范式沉淀为可追溯的文档证据。赞分享人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址https://gitcode.com/gh_mirrors/oh/oh-my-openagent点击查看免费下载相关推荐oh-my-openagent omo-native 遥测管线 F2 代码质量评审隐私白名单、失败关闭配置与生成产物一致性的完整解读oh my openagent omo native 遥测管线 F2 代码质量评审隐私白名单、失败关闭配置与生成产物一致性的完整解读 OmO Native 是人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排oh-my-openagent comment-checker 误报修复验证策略从 CI 到多 Agent 评审的完整质量门禁指南oh my openagent comment checker 误报修复验证策略从 CI 到多 Agent 评审的完整质量门禁指南 本文基于 oh my op人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排oh-my-openagent ulw-loop 代码质量门禁实战纯 LOC 预算、禁止构造审计与 Given/When/Then 测试纪律oh my openagent ulw loop 代码质量门禁实战纯 LOC 预算、禁止构造审计与 Given/When/Then 测试纪律 导读 本文基于人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考