recruit-edge-backend

# 招募边缘后端 [](https://github.com/HukijG/recruit-edge-backend/actions/workflows/ci.yml) 一个无服务器的**分布式集成中心**，用于保持招聘团队的 disconnected SaaS 工具同步 — 由五个协作的 Cloudflare Workers、一个自然语言 AI 控制界面和一个端到端的观测管道构建。 > **三仓库系统的一部分 — 该中心是其他两个依赖的仓库：** > [recruit-extension](https://github.com/HukijG/recruit-extension) 将每个 API 调用、其 OAuth 身份和音乐条形图路由到此处； > [recruit-tv-dashboard](https://github.com/HukijG/recruit-tv-dashboard) 由该仓库的音乐工作器远程控制，并由其统计平面提供数据。连接方式：[如何连接到其他系统](#how-this-repo-connects-to-the-rest-of-the-system) · [`docs/ECOSYSTEM.md`](./docs/ECOSYSTEM.md). ## 它是什么 招聘者的日常工作分散在彼此不交互的系统中： [RecruiterFlow](https://recruiterflow.com) （候选人来源的真实来源 / ATS）、 [Dialpad](https://dialpad.com) （电话系统）、Google Calendar（预订的通话）、 [Krisp](https://krisp.ai) （AI 会议笔记记录器）、 [Apollo](https://apollo.io) （联系人丰富）和一个自定义的 Chrome 扩展程序，覆盖 LinkedIn Recruiter。每个工具只了解自己的世界。 该服务将它们整合为一个： 在一个地方添加候选人，他们将出现在需要的所有地方；通话、预订和会议上下文自动流回候选人记录； AI 助手可以使用普通英语搜索和驱动 ATS — 无需复制粘贴姓名、电话号码和笔记到其他系统，并且 **无需登录 UI**。 它完全作为边缘工作器运行，对 webhook 做出反应，加上一个小型身份验证 API，Chrome 扩展程序 / 移动 PWA 和 AI 助手调用。 ## 技术栈 - **运行时：** [Cloudflare Workers](https://workers.cloudflare.com) （无服务器，边缘）— 无需管理的服务器，直接从 `master` 通过 GitHub 监视路径部署。 - **存储：** Cloudflare **KV** （缓存，防抖标志，速率限制状态）、 **D1** （SQLite — 团队注册，薄读取缓存，附加事件日志）和 **Durable Objects** （强一致性每调用和每用户协调状态）。 - **AI：** [Cloudflare Workers AI](https://developers.cloudflare.com/workers-ai/) — Llama 3.3 70B 用于冷呼叫转录分类，Llama 3.1 8B 用于结果摘要提取。 - **身份验证：** [Cloudflare Access](https://www.cloudflare.com/zero-trust/products/access/) （Zero Trust OAuth + 电子邮件 OTP）用于每个用户界面端点；每个来源的签名令牌用于传入 webhook；工作器之间的信任服务绑定流量。 - **AI 助手集成：** 一个 [Model Context Protocol](https://modelcontextprotocol.io) 服务器，以便 LLM 客户端（claude.ai）可以使用自然语言搜索和更新 ATS。 - **可观测性：** OpenTelemetry 跟踪 + 日志到 [LaunchDarkly Observability](https://launchdarkly.com)，并使用 Cloudflare 原生可观测性作为始终在线的免费备用。 - **语言 / 测试：** JavaScript + TypeScript — **1,553 个自动化测试，涵盖 ~88 个 Vitest 规范文件**，在真正的 Workers 运行时（`@cloudflare/vitest-pool-workers` / Miniflare，不是模拟）和 CI 中的每次推送。 ## 架构概览 该系统由 **五个独立部署的 Cloudflare Workers 和一个 Google Apps Script 桥接器** 组成。三个工作器形成核心；两个工作器与其并行（一个可观测性边车和音乐控制平面）。每个外部系统都通过 **主工作器** 访问平台，主工作器将写入分发回 RecruiterFlow 和 Dialpad，并拥有集成逻辑。该仓库是 **客户端应用程序套件的后端** — 团队的 Chrome 扩展程序 + 移动 PWA、AI 助手和办公电视展位 — 而不仅仅是一个独立的 webhook 消费者。 ```mermaid flowchart LR subgraph clients["客户端"] EXT["Chrome 扩展程序 +<br/>移动 PWA"] AI["AI 助手"] end subgraph providers["外部系统 — webhook 输入"] RF[RecruiterFlow] DP[Dialpad] GC[Google Calendar] KR[Krisp] AP[Apollo] end subgraph core["核心工作器"] MAIN["主工作器<br/>rf-dialpad-sync-dev"] MCP["MCP 工作器<br/>rf-mcp-remote (无状态)"] CACHE["缓存工作器<br/>rf-mcp-cache-sync"] end subgraph storage["状态"] KV[("KV 同步状态")] USERS[("D1 用户数据库")] EVENTS[("D1 阶段事件")] RFCACHE[("D1 RF_MCP_CACHE")] DO1[["DO ExtCallState"]] DO2[["DO ColdCallArbiter"]] end RF <-->|写回| MAIN DP <--> MAIN KR --> MAIN AP --> MAIN GC -->|应用脚本桥接器| MAIN EXT -->|访问 OAuth| MAIN AI -->|OAuth| MCP MCP -->|服务绑定| MAIN MAIN --> KV & USERS & EVENTS & DO1 & DO2 MAIN -.->|只读| RFCACHE MAIN -->|实时调用插入<br/>服务绑定| CACHE CACHE ==>|唯一写入者| RFCACHE classDef provider fill:#444441,stroke:#8a8a82,color:#ffffff classDef client fill:#3c3489,stroke:#afa9ec,color:#ffffff classDef worker fill:#1f5f6b,stroke:#5fb8d4,color:#ffffff classDef db fill:#1f3a78,stroke:#6a92dc,color:#ffffff classDef durable fill:#085041,stroke:#5dcaa5,color:#ffffff class RF,DP,GC,KR,AP provider class EXT,AI client class MAIN,MCP,CACHE worker class KV,USERS,EVENTS,RFCACHE db class DO1,DO2 durable style clients fill:none,stroke:#8a8a82 style providers fill:none,stroke:#8a8a82 style core fill:none,stroke:#5fb8d4 style storage fill:none,stroke:#6a92dc linkStyle default stroke:#7d8590,stroke-width:1.5px ``` | 工作器 | 部署为 | 角色 | |--------|-----------|------| | **主工作器** （仓库根目录） | `rf-dialpad-sync-dev` | 集成中心。接收每个 webhook（RecruiterFlow、Dialpad、Calendar、Krisp、Apollo），为扩展程序 / PWA 提供 API，公开内部 `/mcp/*` 接口，并拥有团队注册 + 阶段移动事件日志。路由位于 [`src/index.js`](./src/index.js)；处理程序按域分组在 [`src/handlers/`](./src/handlers)。 | | **缓存工作器** (`cache-worker/`) | `rf-mcp-cache-sync` | **唯一写入者** D1 读取缓存。15 分钟附加写入仅一次 cron 同步（`INSERT-OR-IGNORE`，永不 `UPDATE`）+ 按需重建工作流 + 服务绑定端点用于实时调用写入。其公共 `workers.dev` 子域已禁用。 | | **MCP 工作器** (`mcp-remote/`) | `rf-mcp-remote` | 公共 Streamable-HTTP 模型上下文协议服务器，由 AI 助手使用。无状态 TypeScript 工作器：验证访问 JWT，然后服务绑定到主工作器的 `/mcp/*` 接口。无存储，无 API 密钥；为每个请求构建一个全新的 `McpServer`（MCP SDK ≥ 1.26.0 会话隔离强制执行）。 | | **指标轮询器** (`metrics-poller/`) | `rf-cf-metrics-poller` | 每小时 cron，从 GraphQL 分析 API 拉取 Cloudflare 使用指标，并将它们作为 OTel 指标记录推送到 LaunchDarkly。完全解耦于请求路径。 | | **音乐工作器** (`music-worker/`) | `rf-music-remote` | **实时协调平面，连接三个仓库生态系统**：整个团队直接从 Chrome 边栏（[recruit-extension](https://github.com/HukijG/recruit-extension)）远程控制办公电视（[recruit-tv-dashboard](https://github.com/HukijG/recruit-tv-dashboard)）。通过搭载集成的 Cloudflare Access OAuth 周界和 CF 部署，它不需要单独的身份验证或基础设施堆栈；内部，WebSocket 休眠持久对象具有双重职责警报，序列化和速率限制团队的命令（4 种模式，调整到电视的缓冲区刷新瓶颈），并将正在播放的流扇到每个扩展程序。通过设计，它与同步核心硬隔离（无服务绑定，无团队数据库，无 OTel；仅 JWT）— 控制平面永远无法触及关键业务中心。参见 [`docs/music-worker.md`](./docs/music-worker.md)。 | | **日历桥接器** (`scripts/calendar-sync.gs`) | Google Apps Script | Google Calendar 没有可用的 webhook，因此 Apps Script 在日历更改时触发，应用三信号预订过滤器，并将候选人数据 POST 到 `/webhook/calendar`。 | > **`-dev` 后缀在主工作器上是历史性的** — `rf-dialpad-sync-dev` 是每个 webhook 指向的实时生产 URL。没有单独的生产工作器；这是一个单租户部署。 架构决策的基础： **RecruiterFlow 是候选人的单一真实来源。** 每个其他系统都同步 **到** 它，候选人始终在 RF 中创建，问题“谁拥有此写入？”对于系统中的每个状态都有一个答案。 ## 难点和设计决策 — *为什么* 这是工程深度的体现。代表性样本（完整的推理在 [`docs/architecture.md`](./docs/architecture.md) 和 [`docs/PROJECT_HISTORY.md`](./docs/PROJECT_HISTORY.md) 中）： - **缓存写入风暴 → 薄不可变重新设计。** 原始缓存 cron 每 15 分钟重写每个候选人和工作岗位行（`INSERT-OR-REPLACE`），每天驱动大约一百多万次 D1 写入，*零* 活跃消费者。解决方案不是优化重写 — 而是 **停止存储难以保持新鲜的数据**：一个薄不可变的缓存，仅存储 ids + 名称 + 不变快照，仅附加写入（`INSERT-OR-IGNORE`，永不 `UPDATE`），并使用两阶段解析器实时从 RF 读取所有可变字段（对抗缓存快照，然后针对 RF 重新排名前 K 个）。迁移为分阶段的双写入切换。 - **Durable Objects 仅在最终一致性出现时使用。** KV 自由用于缓存和防抖标志。但活动状态和取消仲裁器是 Durable Objects，因为两者都需要严格的写入后读取协调，而 KV 的跨 PoP 最终一致性无法提供。权衡是刻意的：DO 更昂贵并序列化访问，因此仅在正确性要求的地方保留它们。 - **取消仲裁器。** 一通电话响起但从未连接，产生没有转录，因此 AI 流永远看不到它 — 但如果转录 **稍后到达** （乱序），它必须获胜，因为这意味着通话实际上是一个语音邮件，而不是取消。RF 没有活动删除，因此写入然后撤销是不可能的。解决方案是每个调用的 `ColdCallArbiter` DO：两个 webhook 分支都击中同一个单线程实例，调谐到超过观察到的挂起 → 转录滞后计时器仅在没有显示转录的情况下确定机械（无 AI）取消调用记录，并且 finalize 路由通过工作器的自己的仪器化 fetch 处理器，以便机械写入被完全跟踪。 - **上游 API 怪癖，一次编码。** RF 的 `/candidate/update` *替换* 数组字段（电子邮件，电话，标签）而不是追加 — 因此每个写入路径都遵循相同的 GET → 合并 → 发送完整数组的纪律，并且 RF 的唯一性 409 驱动了一个非破坏性的查找其他记录并剥离的重复数据构建到更新客户端。Dialpad 的 PATCH 覆盖其电话数组的方式相同。每个怪癖都是通过艰难的方式发现的，然后编码为一个共享模式而不是每个调用者修补。 - **衡量，然后删除。** 构建了一个循环以推动 Apollo 的丰富水流朝向更好的 EU 电话源 — 然后一次生产探针证明 Apollo 始终运行自己的 DB 步骤并在每次调用时短路其余部分，而没有供应商控制参数。整个循环机制（及其 KV 状态）被删除；仅保留真正免费的首次通过落水口。调查作为设计记录保存。遗留缓存 cron 遭到同样的命运，原因相同。 - **AI 之前去重。** 冷呼叫去重标志在转录获取和分类 **之前** 设置，因此 Dialpad 重试风暴永远不会重复计费 Workers AI。整个冷呼叫写入链是同步的，快速失败，无重试 — 在每天约 100 次调用的情况下，团队宁愿丢失事件也不愿冒着静默部分写入的风险（重复活动，擦除标签）。 - **零信任身份验证，身份验证永远来自正文。** 每个用户界面都由 Cloudflare Access OAuth 保护；身份验证是来自 JWT 的验证电子邮件声明，在服务器端解析为注册表 — 永远不会信任来自请求正文的内容。工作器之间的服务绑定流量在帐户边界内受信任，因此上游工作器验证一次 JWT 并将验证的身份转发到内部（无共享秘密标头）。原始电话号码在不透明的 HMAC 签名调用者 ID 别名后面保留，以防止篡改，因此扩展程序无法伪造别名并从任意号码拨出。 - **单一真实来源，单一写入者。** RF 拥有候选人数据；缓存工作器是 **唯一** 读取缓存的写入者；团队注册表拥有身份；一个 D1 拥有统计事件日志。每个状态所有权问题都有一个答案 — 这使得一个五工作器系统是可审计的。 - **工作器之间无共享内容 — 按设计。** 五个工作器不共享代码包，并且不导入其他模块的任何模块；它们通过服务绑定和小型冻结的线合约（内部调用插入，统计推送，`/mcp/*` 信封）进行组合。通过显式记录每个合约并针对它测试双方合约漂移得以防止 — 而不是共享类型包，这将耦合独立部署的工作器。唯一的共享依赖项是供应商和修补的 OTel 库。 ## 存储模型 系统使用三个 Cloudflare 存储原语，每个都经过刻意选择。 - **KV（`SYNC_STATE`）** — 高容量，延迟容忍状态：跨集成候选人/索引缓存（LinkedIn-slug → RF id，email → id，name → id），短 TTL 扩展程序快照缓存，每个招聘人员预热游标，滚动窗口速率限制状态和防止循环的 debounce 标志。最终一致性是可以的，因为所有这些都是。 - **D1（SQLite）** — 三个数据库，具有不同的所有者： - `RF_MCP_CACHE` — **薄不可变** 读取缓存（`candidates_v2`，`jobs_v2`，`calls`）。仅由缓存工作器写入。 - `USERS_DB` — 团队注册表（`users`）和每个用户 SMS 模板。由主工作器通过 SQL 迁移写入；添加团队成员是迁移 + 部署，而不是代码编辑。 - `STAGE_EVENTS` — 仅附加的阶段移动事件日志，支持统计平面。 - **Durable Objects** — 精确地在 KV 的跨 PoP 最终一致性引起正确性错误时使用： - `ExtCallState` — Dialpad 用户的一个实例，持有活动 `call_id`。需要强读取后写入，因为扩展程序以每 2 秒的速度轮询调用状态，而 KV 产生了可见的 1-5 秒的“无活动调用”窗口后调用已经开始。 - `ColdCallArbiter` — 每个调用的实例，一个计时器允许转录胜过“取消”标记，即使 webhook 以乱序到达（见下文）。存储规则 — **“缓存仅不可变数据”** — 使读取缓存便宜 * 且永远不会过时：可变字段（阶段，标题，当前电话，所有权）永远不会被缓存；它们在请求时实时从 RF 读取。缓存仅存储 ids，名称，LinkedIn 斜杠，并且添加时间快照。 ## 数据流平面 每个集成都是自己的流程，具有自己的怪癖。 RecruiterFlow（RF）始终是整个流程的权威。 ### RF ↔ Dialpad — 双向联系人同步（种子） - **RF → Dialpad:** 新/更新的候选人（带有名称 + 组织 + 标题）通过 UID-idempotent `PUT /contacts` 成为 Dialpad 联系人，因此招聘者看到谁正在打电话。 - **Dialpad → RF:** 在 Dialpad 编辑联系人的电话/电子邮件/LinkedIn 流回 RF — **仅这些字段**；RF 始终是其他一切的权威。创建的事件被忽略（它们只是 RF → Dialpad 同步的回声） **创建** 事件被忽略（它们只是RF → Dialpad 同步的回声）。 - **防止循环:** 每个方向在同步后都写入 60 秒 KV debounce 标志 (`sync:RF{id}`)；对方方向首先检查它，否则同步就不能 ping-pong。 ### 日历 → RF + Dialpad 预订团队的排程页面（由 Apps Script 的三信号过滤器检测）会将与会者的电子邮件/电话附加到正确的候选人，通过三级查找（LinkedIn 缓存 → RF 搜索 → 电子邮件/名称缓存），将管道阶段移动到“已预订通话”，并直接插入 Dialpad 联系人，而不必等待 RF 的 webhook。 ### Krisp → RF 完成会议的 AI 笔记会被渲染（markdown → RF 支持的 HTML 子集）并附加到候选人记录中，**归因于参加通话的顾问** — 通过团队成员资格从会议参与者中解析，具有将顾问的 Krisp 账户电子邮件映射到其团队身份的别名列。KV 去重防止重试时重复发布。 ### Dialpad calls → RF — cold-call detection with Workers AI 当招聘人员向 *已搜索* 的候选人拨打外呼电话时，转录 webhook 运行一个廉价的快速失败过滤链（监控用户？外呼？RF 链接？仍在“Sourced”？），然后 Workers AI（Llama 3.3 70B）将转录分类为语音邮件 / 连接-正 / 连接-负。连接结果通过第二个廉价模型（Llama 3.1 8B）提取下一步 / 笔记要点，记录 RF 活动，标记候选人，并推进他们的阶段。**已取消的呼叫** — 响铃但从未连接，因此永远不会到达转录 — 由每次呼叫的 `ColdCallArbiter` Durable Object 协调（参见设计决策）。 ### LinkedIn extension + mobile PWA 招聘人员从 LinkedIn Recruiter 批量添加候选人（一次 50-200 个），然后在侧面板中逐一浏览队列，并在 RF 上下文中通过 Dialpad 一键呼叫或发送短信。呼叫按钮实时切换到“挂断”按钮，基于 `ExtCallState` Durable Object 流。两层缓存策略（20 分钟快照缓存 + 定向邻近预热，基于每个工作岗位添加顺序批次索引）保持第一个配置文件约 600 毫秒，每个后续配置文件约 30-50 毫秒。原始电话号码从不离开工作节点 — caller-ID 选择作为不透明的、HMAC 签名的别名进行交换。 ### Apollo enrichment 如果候选人没有电话号码，则在 Apollo 上查找；显示的号码通过 webhook 异步到达，并通过纯粹的、无 I/O 的排名引擎（排除工作 / 扩展 / 无效；按移动 > 家庭 > 其他排序；保留预先存在的手动号码在顶部）合并 — 到 RF 和 Dialpad 中，在 Apollo 重试时幂等。 ### MCP layer — natural-language access to the ATS AI 助手可以搜索候选人 / 工作岗位，移动阶段，记录面试，并用自然语言起草通话笔记。管理原则：**助手有名无 ID**。所有模糊 / 别名 / 首字母缩写解析都在服务器端进行；客户端从不规范化，从不看到内部 ID。响应信封故意精简 — 每个字节都必须在模型的上下文窗口中获得其位置。交付时分为两个工作节点：无状态的公共 MCP 工作节点验证 JWT，主要工作节点的中间件执行所有解析和实时的 RF 读取。 ### Stage-movement stats plane RF 阶段移动的 webhook 馈送到专用 D1 中的仅追加事件日志，减少为最新的事件赢得每周 CV-Sent / 1st-Interview 总和，并通过冻结的 wire 合同推送到办公室 TV 仪表盘（[recruit-tv-dashboard](https://github.com/HukijG/recruit-tv-dashboard)）。阶段根据 **每个工作岗位自己的管道** 进行位置分类（RF 没有全局阶段列表），每小时水线重对齐扫描捕捉任何 webhook 错过的事件。 ### Observability 每个工作节点都发出 OpenTelemetry 跟踪 + 日志到 LaunchDarkly Observability，在服务绑定和异步 webhook 启动时保留跨跟踪连续性（在回调 URL 中携带跟踪链接），路径条件头部采样在根跨度时丢弃高容量轮询路由，以及两个秘密驱动的运行时杀死开关（剥离正文 / 停止发射），无需重新部署即可翻转。`@microlabs/otel-cf-workers` 依赖项被 vendored 和修补，因此 LaunchDarkly 资源属性实际上到达收集器。 ## 工程占用 - **5 Cloudflare Workers** + 1 Google Apps Script，每个工作节点都是独立部署的单元，具有自己的监视路径。 - **1,553 个自动化测试，跨越约 88 个 Vitest 规范文件**，在真正的 Workers 运行时（`@cloudflare/vitest-pool-workers` / Miniflare）和每次推送 CI 时运行 — 涵盖 webhook 流程端到端，MCP 中间件，Durable Objects，缓存工作节点 cron 和身份验证助手。 - **3 D1 数据库**，具有迁移历史，**2 个 Durable Object 类** 在核心（加上一个在隔离的音乐工作节点中），**9 个 MCP 工具**，以及一个 vendored 和修补的 OTel 依赖项。 ## 构建和运行 ### 前提条件 - Node.js - 具有已启用 Workers 的 Cloudflare 帐户 - RecruiterFlow、Dialpad 和 Apollo 的 API 密钥（完整密钥列表在 [`docs/architecture.md`](./docs/architecture.md) § 环境） ### 本地 存储库是一个 npm 工作区 monorepo — 一个根目录安装涵盖了主要工作节点和所有四个兄弟工作节点。 ```bash npm install npm run dev # 本地开发服务器，用于主要工作节点（wrangler dev） npm test # 主要工作节点的 vitest 套件，针对 Workers 运行时 npm test --workspace=cache-worker # 每个工作节点的套件都以相同方式运行 ``` ### 部署 推送到 `master` — Cloudflare 的 GitHub 集成通过每个工作节点的监视路径自动独立部署每个工作节点。可以通过 `npm run deploy` 手动部署。机密在 Cloudflare 仪表盘中管理，绝不提交。 > 已部署工作节点的 webhook URL 是真实且在线的。在迭代时，请使用 `npm test` 或本地 `wrangler dev` 实例 — 不要向已部署的工作节点发送测试 webhook。 ## 该存储库如何与系统的其余部分连接 此后端是三存储库生产系统的中心 — 其他两个存储库是此处定义的表面的客户端（[`docs/ECOSYSTEM.md`](./docs/ECOSYSTEM.md) 是完整映射）： - **[recruit-extension](https://github.com/HukijG/recruit-extension)** — 招聘人员的 Chrome 扩展程序 + 移动 PWA 是一个薄客户端，完全依赖此存储库：候选人同步（`POST /candidates`），冷呼叫表面（`/dialpad-*`，`/extension-call-status`，`/call-stats`），云 SMS 模板（`/sms-templates`），以及 Cloudflare Access OAuth 应用程序它登录到都是此处拥有。其当前播放音乐条形图与音乐工作节点的 `/music/*` API 和 WebSocket 通信。 - **[recruit-tv-dashboard](https://github.com/HukijG/recruit-tv-dashboard)** — 办公电视信息亭在两个平面上位于下游。*控制：* 音乐工作节点将团队（限速，DO 序列化）的命令转发到电视的远程 API，并将其当前播放状态反馈到每个扩展程序 — 该存储库的 [演示视频](https://github.com/HukijG/recruit-tv-dashboard/blob/dev/docs/media/extension-remote-demo.mp4) 显示整个循环。*数据：* 统计平面将每周 CV-Sent / 1st-Interview 聚合数据通过冻结的 wire 合同推送到仪表盘的 KPI 部分。 - **一个身份边界** — 一个单一的 Cloudflare Access OAuth 应用程序位于扩展程序、PWA 和音乐工作节点之前；MCP 表面验证相同的 JWT。 ## 文档 这些更深入的文档是详尽的参考资料。 **[`docs/architecture.md`](./docs/architecture.md) 是规范的、逐一吹风的系统参考资料** — 每个端点、webhook、KV 密钥、D1 表、Durable Object 和数据流图。 从 [`docs/PROJECT_HISTORY.md`](./docs/PROJECT_HISTORY.md) 开始，如果你想要以叙述形式了解 *why*。 - [`docs/architecture.md`](./docs/architecture.md) — 完整的系统概述：所有数据流、端点表、源文件映射、KV + D1 模式、Durable Object 迁移历史、部署。权威参考。 - [`docs/PROJECT_HISTORY.md`](./docs/PROJECT_HISTORY.md) — 架构的演变（2025 年 9 月 → 2026 年 6 月）：阶段、难题和当前设计背后的权衡。 - [`docs/security.md`](./docs/security.md) — Cloudflare Access 认证模型、JWT 验证和每个用户界面端点遵循的约定。 - [`docs/mcp-middleware.md`](./docs/mcp-middleware.md) — 深入了解 MCP 层：实体解析器、工具描述符、响应形状契约、筛选源真值映射、实时获取 vs. 缓存读取。 - [`docs/stage-stats.md`](./docs/stage-stats.md) — 阶段移动统计平面（每周 CV-Sent / 1st-Interview 聚合）。 - [`docs/observability.md`](./docs/observability.md) 和 [`docs/observability-runbooks.md`](./docs/observability-runbooks.md) — OpenTelemetry → LaunchDarkly 管道、仪表盘和警报手册。 - [`docs/music-worker.md`](./docs/music-worker.md) — 音乐控制平面（扩展程序 ⇄ 办公电视）：路由、共享 Durable Object、速率限制模式、WS 票证认证。 - [`docs/ECOSYSTEM.md`](./docs/ECOSYSTEM.md) — 三个存储库如何组成一个系统。