周五下午 4:30，Harbor Labs 得知一家医疗客户必须在下周审计前修复无障碍问题。熟悉系统的工程师生病了。Elena 当天下午刚完成一个零售发布，是唯一有合适前端经验的开发者。
使用 onemind 之前，交付负责人会给 Elena 发一页链接，把她加入多个系统，再安排两小时结对。Elena 会用整个周一阅读旧任务，而 AI 工具仍沿用零售项目的习惯。医疗客户使用不同组件库，要求为无障碍决策提供证据，而且禁止 Harbor 在其他地方常用的一个依赖。
交付负责人在 onemind 中打开 Elena 的成员申请，指定医疗 Project、开发角色、两个仓库、六周期限和访问原因。预览显示 Elena 将从 Harbor 继承的内容——安全底线、代码评审流程、估算方法——以及来自客户的设计系统、审计规则、浏览器政策、完成定义和失败方案。商业文档和生产病人数据被排除。客户负责人批准申请。
周一早上 8:45，Elena 的本地 onemind App 显示即将发生的变化。零售工具包会停用；医疗工具包会加入 Cursor、Codex CLI 和仓库评审 Hooks。一个可选无障碍测试 Plugin 需要单独的本地安装批准。Elena 查看 Plugin 发布者、版本、权限和卸载方式后批准。
她打开 Cursor 时，顶部 Banner 显示当前客户和 Project。会话启动包总结审计期限、当前目标、架构图、Ready Components、必要证据和设计与合规负责人。它没有把整个客户 Wiki 塞进 Prompt；当 Elena 询问某条规则的原因时，Cursor 才检索获批页面。
她的第一个方案建议用流行开源 Library 替换客户日期选择器。onemind 检索出九个月前的失败方案：Library 的键盘行为虽然可修改，但如果不维护私有 Fork，就无法生成客户需要的审计证据。条目连接旧评估并指出已批准内部组件。Elena 在生成代码前就修改计划。
午饭时，一个上下文警告出现。Elena 在另一个编辑器窗口打开了零售仓库。onemind 没有在那里注入医疗工具包，而是同时显示两个当前上下文，并拒绝在整台电脑上全局使用一个包。从 onemind 角度看，零售窗口保持只读，直到 Elena 主动重新激活该 Project。
下午 3:00，Elena 打开 Pull Request。评审 Hook 除 Harbor 标准测试外，还运行医疗项目的键盘、屏幕阅读器、对比度和证据检查。一项检查失败，因为 AI 生成的 PR 描述写着“完全符合 WCAG”，而客户政策不允许开发者作这种承诺。Hook 建议改用只描述已通过测试的事实性文字。Elena 修改后请求评审。
客户工程师发现一项设计问题，但没有发现任何已经文档化的标准违规。修复在周一晚上进入 Staging。周二，审计负责人批准证据包。
六周后，Elena 的成员资格到期。onemind 停止生成新的医疗工具包，并请求移除本地 Plugin 和缓存检索索引。受支持工具确认已删除。一个手工导出的 PDF 无法验证，因此 Elena 必须确认已经删除；结束记录明确展示两种状态的差别。
Harbor 没有把调动工作降到零。客户负责人仍然评审访问，Elena 仍然熟悉产品，另一名工程师仍回答领域问题。但她在半天内作出有效贡献，而不是用两三天重建上下文。更重要的是，她没有把零售规则带进医疗项目，也没有把医疗知识带回零售工具。