Friend Windows 桌面端 Track 3 代码清单解析记忆、目标、任务与共享 Schema 的真实基线【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend导读本文基于 gt-windows-inventory.mdTrack 3 Ground-Truth Inventory整理而成该文档以「存量盘点」的形式逐文件记录了 Friend 项目 Windows 桌面端desktop/windows中与 memories记忆、goals目标、tasks任务、insights洞察、integrations集成相关的全部既有代码路径并标注了三份共享 schema 文件main/ipc/db.ts、shared/types.ts、preload/index.ts的「追加点」。阅读本文后你将掌握Windows 端当前记忆/目标/任务功能究竟由哪些渲染层模块与主进程模块承载、本地 SQLite 与远端 REST 两种数据通路如何并存、以及为新增本地表或远端字段做 additive-only只增不改Schema 变更时应遵循的确切代码结构与约定。说明文档与源码中大量使用「Track 3」这一代号指代 macOS/Windows 桌面端对齐计划中的第三轨工作memories、goals、tasks、insights、integrations 相关功能面。文档生成于 2026-07-14本文同时引用了仓库当前源码做印证个别结论如某文件当前行数以文档记录为准实现方式以源码为准。一、盘点范围与方法论给编排者一份「今天到底有什么」的基线这份清单的用途非常明确在规划一个 additive-only 的 schema PR 之前先拿到 Track 3 自有功能面memories、goals、tasks、insights、integrations加上三份共享 schema 文件的精确存量基线避免「边写边猜」。路径约定除特别说明外所有路径均相对于 desktop/windows/src 目录。工作方式对每个路径逐一确认「是否存在 → 行数 → 完整度 → 当前职责」并用 glob 确认缺失项如lib/embeddings*.ts的「MISSING」是通过通配搜索确认的。三大任务TASK 1 为自有路径清单lib / hooks / main / pages / componentsTASK 2 为共享 schema 文件db.tsdbMigrations.ts、shared/types.ts、preload/index.ts、生成式 API 客户端TASK 3 为渲染层 → 主进程的两种 DB/IPC 访问模式。文章结构即按这三个任务展开。二、TASK 1自有路径逐文件盘点2.1 渲染层renderer/src/lib/*目标、记忆导入与洞察引擎清单中这一目录下的文件大体可分为三类目标Goals辅助层 —— lib/goals.ts55 行这是 onboarding「选一个目标」步骤的纯辅助模块职责单一且完整函数职责buildGoalPrompt(apps)构造单次 LLM prompt若 onboarding 脑图已知用户常用应用则拼入「I work with these apps and tools: ...」上下文否则请求通用生产力目标parseTargetValue(text)从目标句子中提取第一个数字作为target_value无数字时默认返回 1因为POST /v1/goals缺target_value会 422generateGoal(apps)调用 agent LLM 生成目标并清洗引号与多余空白createGoal(title)通过POST /v1/goals持久化target_value由parseTargetValue推导调用方应将失败视为非致命从源码可见其设计约束POST /v1/goals必须携带target_value否则后端 422因此parseTargetValue的兜底逻辑默认 1即布尔式目标是必需的。而目标的建议/进度逻辑并不在此文件而是内联在Goals.tsx与QuickGoalsWidget.tsx中见 2.4。记忆导入与批量操作 ——lib/memoryExtract.ts、lib/memoriesBulk.ts、lib/memoryCleanup.ts、lib/memoryRank.tsmemoryExtract.ts139 行基于 LLM 的记忆日志导入ChatGPT/Claude 粘贴文本是 macOS 端OnboardingMemoryLogImportService的忠实移植。它将粘贴的导出内容 既有记忆一并发送到desktopApi.post(/v2/chat/completions, ...)使用claude-haiku-4-5-20251001合成模型解析 JSON 后对既有记忆做「规范化后的精确匹配」去重同时为向后兼容重新导出extractJSONObject。memoriesBulk.ts120 行三个批量操作。fetchAllMemories()分页拉取GET /v3/memories并按 id 去重源码中体现为fetchAllMemoriesPaged页大小MEMORIES_PAGE_LIMIT 500并在注释中记录了后端「offset 0 处强制 5000 上限」的怪癖实际代码以每页 500 循环推进postMemoriesBatched()按MEMORIES_IMPORT_BATCH_SIZE100分块 POST/v3/memories/batchdeleteMemoriesPaced()是渲染端按 429/Retry-After 限速的单删循环。注意还存在一个主进程批量删除路径main/ipc/memoryCleanup.ts那才是真正接到设置页「批量删除」按钮的实现渲染端版本可能已不被 UI 使用文档明确标注「worth flagging but out of scope」。memoryCleanup.ts94 行纯只读的「app-index 记忆」检测器用正则识别已被移除的本地文件索引管线合成的记忆APP_INDEX_TAG、USES_TEMPLATE、LOCAL_INDEX_STEM、INDEX_SENTENCES并提供summarizeMemories()供维护界面按标签分组、标记待删除候选。无网络、无变更——它是「分析」半边删除动作在memoriesBulk.ts/memoryCleanupIPC。memoryRank.ts69 行纯 token 重叠度排序rankMemories用于把文件夹/项目名或问题与已存记忆做关联停用词表针对 folder-slug token 调优无 I/O。洞察Insights引擎 ——lib/insight*.ts4 个文件 3 个测试Proactive InsightsRewind OCR → Gemini → 毛玻璃 toast与 macOS 的记忆管线相互独立文件职责insightActivity.ts39 行将 Rewind 帧分组为 OCR 文本摘要insightPrompt.ts69 行构造 Gemini prompt/schema 并把响应解析为InsightPayloadinsightGate.ts16 行置信度阈值 头条去重insightEngine.ts95 行编排器自调度定时器调用window.omi.rewindFrames、insightGetSettings/insightAdd/insightRecent、Geminigenerate()需要特别说明的是当前仓库源码中 lib/insightEngine.ts 头部注释显示该引擎已退役RETIREDTrack 3 P4——提取循环已迁移到主进程main/assistants/insight/*作为 macOS 两阶段工具调用管线的忠实移植由 proactive-assistant 协调器托管渲染端残存的引导函数maybeStartInsightEngine()仅用于启动 AI-profile host、Rewind embedding indexer 与 pi-mono 托管云聊天会话中继三者都依赖渲染端的 Firebase token。这与清单记录「insight 与 Track 3 的 memory/goals/tasks 无涉、不触碰记忆」的结论一致且印证了「此管线独立演进」的判断。确认缺失项lib/embeddings*.tsMISSINGglob 确认renderer/src/lib下无任何 embeddings 相关文件。lib/clientDevice.tsMISSING与 brief 中「macOS 提交 a4c50bcb4 的 client-device 上报尚未 cherry-pick 到 Windows」的注记一致。lib/userProfile.ts27 行不是AI/记忆 profileget_ai_profile/update_ai_profile而是 onboarding 向导的身份同步syncLanguage()PATCH /v1/users/language、syncRecordingConsent()POST /v1/users/store-recording-permission裸布尔 body、setDisplayName()FirebaseupdateProfile因为后端没有「设置我的名字」端点。AI-profile 的读写逻辑在此文件乃至整个renderer/src/lib中都不存在——生成客户端里虽有get_ai_profile/update_ai_profile函数见 TASK 2却无任何调用者。2.2 渲染层renderer/src/hooks/*只有记忆有 Hookhooks/useMemories.ts169 行完整全应用唯一的记忆 Hook。模块级缓存 发布订阅subscribers: Set使所有挂载实例Memories 页、设置导入器等跨页面保持同步。其fetchMemories()调用GET /v3/memories?limit500offset0并在客户端按created_at desc排序服务端不排序。createMemoryPOST/v3/memorieseditMemory与setMemoryVisibility都走patchMemoryOptimistic()——PATCH/v3/memories/{id}或/v3/memories/{id}/visibility时把新值作为查询参数{ params: { value } }发送这与后端value: str函数参数契约FastAPI 对非模型类型绑定为 query param一致同时做乐观更新、失败回滚。源码还展示了额外细节跨账号切换防护getCacheUid()比对、X-Omi-Memory-Canonical-Lifecycle-Exposed能力头读取用于门控 tier/device 过滤、冷启动先渲染磁盘缓存再后台 revalidate。hooks/useTasks*.ts不存在。Tasks 没有专门 Hookpages/Tasks.tsx613 行全部内联模块级缓存、fetchAllActionItems()按has_more分页GET /v1/action-itemsTASKS_PAGE_SIZE100外加尽力而为的GET /v1/conversations拉取以标注每个任务的来源会话。components/home/QuickTaskWidget.tsx则重复实现了一套更简单的独立拉取自带 auth-gateduseEffect、无缓存 state页面与组件之间没有共享 Hook。hooks/useGoals*.ts不存在。与 Tasks 同样模式。pages/Goals.tsx662 行内联一切模块缓存、fetchAll()走GET /v1/goals/all单端点同时返回 activecompleted客户端按is_active拆分、完成度逻辑isCompleted/progressPct/progressLabel在components/home/QuickGoalsWidget.tsx中被逐字复制后者还独立调用GET /v1/goals/suggestPOST /v1/goals实现一键「生成目标」。文档明确指出这是真实重复记入 Leave-It-Better 范围本次未修。2.3 主进程main/*集成、导出、导入、清理与用量main/assistants/**MISSING目录列表确认不存在。注意这与前文insightEngine.ts注释中「已迁移到src/main/assistants/insight/*」的说法存在版本差异——清单生成时该目录尚不存在属于后续演进阅读时请以当前源码为准。main/integrations/**完整google.ts、googleMap.ts(test)、oauth.ts、oauthPkce.ts(test)、stickyNotes.ts、stickyNotesPath.ts(test)、stickyNotesText.ts(test)、syncState.ts、syncStateLogic.ts(test)、tokenStore.ts。覆盖完整 Google OAuthGmail/Calendar与 Windows 便笺Sticky Notes读取全部带单测。main/memoryExport/**完整format.ts(test)、io.test.ts、notion.ts、obsidian.ts、plainFile.ts——三个导出目标Notion 页面、Obsidian vault 文件夹、纯 Markdown 文件。main/memoryImport/**完整但单薄只有parse.ts(test)即纯文本转储解析器parseMemoryDump。真正的 LLM 提取路径在渲染端lib/memoryExtract.ts此目录只是兜底/启发式切分器。main/memoryCleanup/**完整但单薄bulkDelete.ts(test)提供纯函数classifyStatus、backoffMs供main/ipc/memoryCleanup.ts的工作池消费。main/usage/**完整前台应用用量跟踪子系统category.ts(test)、foregroundMonitor.ts、nativeForeground.ts、usageAccumulator.ts(test)、usageDay.ts(test)、usageRetention.ts(test)、usageSettings.ts、userAssist.ts(test)、userAssistRegistry.ts、userAssistSeed.ts。虽不在 Track 3 范围内但与本地知识图谱合成管线共享app_usage表。main/insight/{notification,state}.ts均存在完整notification.ts17 行的fireNativeInsight()把InsightPayload显示为原生 Windows 通知尽力而为不支持则 no-opstate.ts46 行的getInsightSettings()/updateInsightSettings()是基于 JSON 文件userData 下insights.json的存储带内存缓存与DEFAULTSenabled: true, intervalMin: 15, notificationStyle: omi, denylist: [], lastRunAt: null。同目录还有第三个文件toastWindow.ts不在 brief 列表中负责共享毛玻璃 toast 窗口。IPC 处理器文件内容main/ipc/memoryExport.ts47 行注册 3 个ipcMainhandlermemoryExport:obsidian/file/notionobsidian/file 打开原生对话框后委托给main/memoryExport/*main/ipc/memoryImport.ts8 行刻意单薄唯一 handlermemoryImport:parse委托parseMemoryDump注释说明渲染端因持有 Firebase token 而自行执行真正的POST /v3/memoriesmain/ipc/memoryCleanup.ts102 行注册memories:bulkDelete——使用 Electronnet.fetch而非渲染端 axios的 4 路并发工作池按 id 重试/退避MAX_ATTEMPTS6经memories:deleteProgress流式上报进度。这才是接到批量删除 UI 的路径文档未在本轮验证调用组件标注待确认2.4 页面与组件完整但存在重复逻辑页面均完整非桩代码页面行数备注renderer/src/pages/Memories.tsx479全功能页面自有模块级缓存renderer/src/pages/Tasks.tsx613全功能页面内联缓存与乐观更新renderer/src/pages/Goals.tsx662全功能页面内联缓存文档说明仅对 Tasks/Goals 前 ~80 行做了逐行阅读头/导入/缓存初始化部分足以确认完整度并与 TASK 2 记录的 API 面吻合。组件组件状态components/insight/InsightToast.tsx(insight-toast.css)154 行在共享毛玻璃 toast 窗口渲染三种 toast主动洞察、会议检测通知、更新后「whats new」——属 Rewind/Insight 功能 UI与 memory/goals/tasks 无关components/home/QuickTaskWidget.tsx150 行主页待办预览卡按截止日期取前 2独立拉取/v1/action-itemsauth-gated聚焦/路由变化时 refetch与Tasks.tsx无共享 Hookcomponents/home/QuickGoalsWidget.tsx179 行主页进行中目标预览卡带进度条独立拉取/v1/goals/all加一键/v1/goals/suggest→POST /v1/goals生成流isCompleted/progressPct逻辑与Goals.tsx重复无共享辅助components/settings/tabs/IntegrationsTab.tsx两个集成Windows 便笺window.omi.readStickyNotes()读取 →lib/stickyNotesExtractLLM 提取 → 作为带标签记忆导入与 GoogleGmail/Calendar 经lib/googleSync同步由VITE_ENABLE_GOOGLE_INTEGRATION或 dev localStorage flag 门控。两者都通过useMemories()写入记忆三、TASK 2共享 Schema 文件——三处「追加点」与生成客户端3.1main/ipc/db.ts903 行main/ipc/dbMigrations.ts99 行当前所有CREATE TABLE全部位于get()中单个db.exec(...)模板字符串内IF NOT EXISTS守护caption_event——会话字幕/OCR 覆盖文本含conversation_id, ts索引local_conversation——本地录音/聊天列以下方追加方式增加indexed_files——文件索引扫描结果含file_type索引local_kg_nodes/local_kg_edges——聊天 agent 本地知识图谱含 label/type 索引onboarding_kg_nodes/onboarding_kg_edges——独立的 onboarding 脑图图谱app_usage——前台时长跟踪以exe_path为键rewind_frames——屏幕历史时间线含ts、indexed索引insights——Proactive Insights 记录含ts索引当前源码中该清单又追加了conversation_folders、conversation_speaker_names、rescue_segments、file_index_meta、app_meta、voice_turn_outbox以及ai_user_profiles、focus_sessions、memories等新表部分带「Net-new tables — CREATE TABLE IF NOT EXISTS only, no numbered migration」注释说明 Track 3 之后桌面端本地持久化已持续扩展。文档结论依然成立memories/goals/tasks 这些资源今天全部在服务端/v3/memories等本地没有对应缓存表新增本地持久化是干净的全新加法碰撞风险低。两套迁移机制在get()内按序执行加法基线引导bootstrap——ensureColumn(db, table, col, decl)调用dbMigrations.ts中addColumnIfMissing的别名在每次启动时无条件执行各自幂等ensureColumn(db, local_conversation, kind, TEXT NOT NULL DEFAULT recording) ensureColumn(db, local_conversation, messages, TEXT) ensureColumn(db, local_conversation, title, TEXT) ensureColumn(db, local_kg_nodes, aliases_json, TEXT) ensureColumn(db, local_kg_nodes, source_refs, TEXT) ensureColumn(db, indexed_files, target_path, TEXT)这是第一个追加点若要在已有表上新增一列例如给未来某表加profile/embedding列就在runMigrations(db)之前补一行ensureColumn(...)。版本化迁移dbMigrations.ts——PRAGMA user_version跟踪、有序、只追加每个迁移包在自己的事务里BEGIN/m.up(d)/PRAGMA user_version N/COMMIT抛错即回滚。清单记录当时恰好有一条迁移export const MIGRATIONS: Migration[] [ { version: 1, name: local_conversation cloud-sync outbox columns, up: (d) { addColumnIfMissing(d, local_conversation, sync_state, TEXT NOT NULL DEFAULT local_only) addColumnIfMissing(d, local_conversation, segments_json, TEXT) addColumnIfMissing(d, local_conversation, cloud_id, TEXT) addColumnIfMissing(d, local_conversation, sync_attempts, INTEGER NOT NULL DEFAULT 0) addColumnIfMissing(d, local_conversation, sync_error, TEXT) } } ]当前源码已新增version: 2rewind_fts_backfill对rewind_frames_fts外置内容 FTS 索引做一次性重建并以sqlite_master存在性守卫保证纯迁移测试环境可跳过完全验证了文档描述的追加模式。这是第二个追加点任何超过「加一列」的变更新表、回填、多语句 DDL都应追加{ version: N, name: ..., up: (d) {...} }条目。文件头注释与runMigrations运行时校验共同强调的规则是只追加、绝不重编号或修改已发布的迁移、每个up尽量幂等、version必须从 1 连续递增runMigrations会对不连续直接抛错。db.ts中 schema 初始化以下的内容是按功能分组的普通导出函数以// --- Section ---横幅注释分隔如// --- App usage ---、// --- Local knowledge graph (M2) ---、// --- Rewind: screen-history timeline ---、// --- Proactive Insights ---。Track 3 自己的代码块应遵循同样约定在文件末尾recentInsights()即第 903 行之后追加// --- Feature Name ---横幅与对应函数。3.2shared/types.ts1276 行单文件、无命名空间/子模块。组织方式顶部少量共享常量PCM_PENDING_MAX_BYTES、GPU_CONTEXT_LOST_CHANNEL随后按功能添加的大致顺序排列类型组每组前有// ─── Section ───或// --- Section ---横幅。唯一的巨型聚合接口OmiBridgeApi自第 470 行起是 preload 暴露面——每个新的 main→renderer IPC 方法的 TypeScript 签名都加在这里归入自己的// --- Feature ---注释组如第 1157 行的// --- Proactive Insights (Rewind OCR → Gemini → acrylic toast) ---、第 774 行的// --- Coding agents ---。某功能的 payload/记录类型如InsightPayload、InsightSettings、InsightRecord声明在文件末尾、靠近其最后被引用的位置而不是与OmiBridgeApi同置。Track 3 在此文件的追加点两处独立编辑新 payload/数据类型例如若要加本地缓存则加GoalRecord/TaskRecord/AIProfileRecord——按InsightPayload/InsightRecord/InsightSettings约 1157–1217 行的模式追加到文件末尾附近。新 IPC 方法签名——追加进OmiBridgeApi接口体其右花括号当前在第 772 行内放在新的// --- Feature ---横幅下镜像// --- Local knowledge graph (M2) ---586 行或// --- Meeting detection (Phase 5) ---644 行的分组方式。3.3preload/index.ts394 行底部三次contextBridge.exposeInMainWorld调用omi、omiOverlay、omiBar各自以普通对象字面量实现shared/types.ts中对应接口。当前源码在此基础上又增加了omiGlow。omi对象实现OmiBridgeApi对 Track 3 而言是最相关的每个方法都是一行ipcRenderer.invoke(...)请求/响应或ipcRenderer.send(...)ipcRenderer.on(...)/removeListener对发后即忘/事件订阅分组顺序与shared/types.ts中OmiBridgeApi的横幅注释一致如 insight 块自第 173 行起insightGetSettings、insightSetSettings、insightAdd、insightRecent、insightShow、insightDismiss、insightHoverStart/End、insightTest、onInsightShow。追加点在omi对象字面量右花括号当前约在第 283 行闭合前添加新方法位置与其OmiBridgeApi声明保持相对一致遵循既有ipcRenderer.invoke(feature:action, ...)命名约定冒号命名空间通道如insight:getSettings、memoryExport:notion。当前源码中该模式清晰可证例如const omi: OmiBridgeApi { getCaptureSources: () ipcRenderer.invoke(capture:getSources), // ... contextBridge.exposeInMainWorld(omi, omi) }3.4 生成式 API 客户端renderer/src/lib/omiApi.generated.ts12,369 行由后端 OpenAPI schema 自动生成一个interface Paths块path → method →operationId/responses随后是每个端点一个导出的async function operationId(...)包装器外加全部请求/响应interface。清单对相关后端功能做了「生成客户端中是否存在」的逐项核对后端功能生成客户端中函数名签名要点获取 AI profile是get_ai_profile_v1_users_ai_profile_get(init?)→PromiseAIUserProfileResponse \| null10702 行无路径/查询参数AIUserProfileResponse { data_sources_used?, generated_at?, profile_text? }更新 AI profile是update_ai_profile_v1_users_ai_profile_patch(body: UpdateAIUserProfileRequest, init?)→PromiseAIUserProfileResponse10717 行走 JSONbody区别于下面的记忆编辑/可见性记忆编辑内容是两种变体edit_memory_v3_memories__memory_id__patch(path: {memory_id}, query: {value: string}, init?)12219 行另有 MCP 变体edit_memory_v1_mcp_memories__memory_id__patch9968 行查询参数而非 JSON body全文件 grep 确认不存在MemoryValueRequest类型记忆可见性是update_memory_visibility_v3_memories__memory_id__visibility_patch(path: {memory_id}, query: {value: string}, init?)12270 行同为查询参数模式目标建议当前是get_current_goal_advice_v1_goals_advice_get(init?)→PromiseAdviceResponse9278 行AdviceResponse { advice: string }目标建议指定是get_goal_advice_v1_goals__goal_id__advice_get(path: {goal_id}, init?)9372 行目标生成建议是suggest_goal_v1_goals_suggest_get(init?)→PromiseGoalSuggestionResponse9325 行GoalSuggestionResponse { reasoning, suggested_max?, suggested_min?, suggested_target, suggested_title, suggested_type }暂存任务staged tasks全系列否完全缺失无后端路由 backend/routers/staged_tasks.py 完整存在POST/GET /v1/staged-tasks、DELETE /v1/staged-tasks/{id}、/v1/staged-tasks/clear、/v1/staged-tasks/promote、批量打分端点但生成客户端从未在 staged-tasks 加入后端后重新生成——这是「客户端已过期」的最直接证据且 Windows 端目前没有任何 staged-tasks UI/管道对 additive schema PR 的实操含义若 Track 3 范围包含 staged-tasks 支持生成客户端需要一次重新生成从当前后端 OpenAPI schema它不是手改目标而是 codegen 产物本轮未定位确切重生成命令可查 desktop/windows/package.json 的 scripts 或scripts/generate-api*文件。另外值得记录的细节Goals.tsx/QuickGoalsWidget.tsx目前是经裸omiApi.get(/v1/goals/suggest)调用该端点并手动把响应标注为{ suggested_title?, suggested_target? }而不是导入生成函数/类型——不一致但本轮不修。四、TASK 3渲染层 → 主进程 DB 的两种 IPC 模式文档强调「两种截然不同的数据访问模式并存新功能该跟哪种走很关键」模式 A——本地 SQLite 经 IPC主进程持有如 Insights三段链路加调用方共四跳全部 fire-and-forget 或 invoke/response渲染端不直接碰 DBbetter-sqlite3 是原生模块只在主进程可加载shared/types.ts 声明方法签名进OmiBridgeApi如insightGetSettings: () PromiseInsightSettings、insightAdd: (p: InsightPayload) Promisevoid。preload/index.ts 以薄封装实现ipcRenderer.invoke(insight:getSettings)/ipcRenderer.invoke(insight:add, p)经contextBridge.exposeInMainWorld(omi, omi)暴露到window.omi。main/ipc/*.ts的 handler对 insights 而言是注册insight:getSettings/insight:add的地方类比memoryCleanup.ts的ipcMain.handle(memories:bulkDelete, ...)调用main/insight/state.ts的getInsightSettings()/updateInsightSettings()——该功能读写 JSON 文件而非 SQLite对于insights/local_kg_nodes这类表则直接调用main/ipc/db.ts的导出函数如文件末尾的insertInsight()、recentInsights()。渲染端调用方lib/insightEngine.ts直接使用桥await window.omi.insightGetSettings()、await window.omi.insightAdd(insight)、window.omi.insightShow(insight)——没有 React Hook 包裹定时器上的普通异步函数直接调用。端到端的表支撑读示例window.omi.rewindFrames(from, to)→ preloadipcRenderer.invoke(rewind:frames, from, to)→ rewind 的 IPC handler →db.ts导出的listRewindFrames(from, to)它对该表执行prepare(...).all(from, to)并返回类型化行。结论任何新增的 Track 3 本地表都应遵循此模式——在OmiBridgeApi声明方法 → preload 薄 invoke → 在main/ipc/feature.ts注册ipcMain.handle→ 在db.ts或主进程侧小辅助模块实现实际 SQL → 渲染端经window.omi.method()调用。模式 B——渲染端 axios 直连后端 RESTmemories/goals/tasks 当前实际用法memories、goals、tasks完全不经过主进程 SQLite——它们是 Omi 后端的服务端资源由渲染端经omiApilib/apiClient.ts 中的 axios 实例自动附加 Firebase auth token直接拉取。实例hooks/useMemories.ts的fetchMemories()直接omiApi.get(/v3/memories, { params: { limit: 500, offset: 0 } })——无 IPC 往返、无本地表Goals.tsx的omiApi.get(/v1/goals/all)与Tasks.tsx的omiApi.get(/v1/action-items, ...)同理。今天记忆相关唯一需要主进程 IPC 的场景是需要主进程独占能力的地方文件对话框memoryExport.ts或「跨导航存活 Electronnet.fetch」memoryCleanup.ts的批量删除——它仍然打同一个/v3/memories/{id}REST 端点只是从主进程发起并把渲染端 token 作为 IPC 参数传入。规划含义如果 Track 3 的 additive schema PR 针对的是后端API 面新的 memory/goal/task 字段、staged-tasks、AI profile那么相关的「schema」是生成客户端 shared/types.ts的 payload 形状大概率完全不涉及本地 SQLite 表——走模式 B 而非模式 A。只有当计划要求为这些资源做本地缓存/离线存储时才需要动用db.ts/dbMigrations.ts而今天并不存在这样的存储。五、缺口与过期点汇总对后续工作的直接指引文档在末尾给出了便于编排者快速决策的摘要lib/embeddings*.ts与lib/clientDevice.ts——确认缺失与 brief 预期一致。main/assistants/**——确认缺失同样注意当前源码已出现main/assistants/insight/*的演进需以现状为准。不存在useTasks/useGoalsHook两个页面及其主页组件对应物各自内联重复 fetch/缓存/完成度逻辑Goals.tsx与QuickGoalsWidget.tsx尤其逐字重复isCompleted/progressPct。omiApi.generated.ts完全不含 staged-tasks 支持尽管后端路由存在——若 staged-tasks 在范围内需重新生成。记忆编辑/可见性在生成客户端与当前后端backend/routers/memories.py 的edit_memory()/update_memory_visibility()均为普通value: str函数参数两侧都用查询参数——两者今天一致。若计划迁移为MemoryValueRequest {value}JSON body 契约那是新的后端变更需要客户端重新生成而非当前客户端落后。存在两套竞争的记忆批量删除实现lib/memoriesBulk.ts的deleteMemoriesPaced()渲染端驱动、单飞行与main/ipc/memoryCleanup.ts的memories:bulkDelete主进程驱动、4 路并发、net.fetch、可跨导航存活。设置页按钮到底接的是哪个本轮未验证——在下结论前值得快速 grep 确认别把任一方当死代码。db.ts对 memories/goals/tasks/AI-profile/embeddings 零表——任何 Track 3 需要的新本地持久化都是干净的全新加法碰撞风险低追加方式为dbMigrations.ts新Migration条目 db.ts末尾新// --- Feature ---横幅函数区。这份清单的价值正在于「不猜」它以文件为单位给出存在性、行数、完整度与职责把 schema 变更的碰撞面收敛到三个明确的追加点ensureColumn引导、MIGRATIONS数组、OmiBridgeApi/preload 的对应位置并为新增本地表还是新增远端字段提供了模式选择的判断依据——这正是任何后续增量开发前最需要的地基。【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考