週五下午 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 仍然熟悉產品，另一名工程師仍回答領域問題。但她在半天內作出有效貢獻，而不是用兩三天重建上下文。更重要的是，她沒有把零售規則帶進醫療項目，也沒有把醫療知識帶回零售工具。