@jun133/athlete 0.0.5 → 0.0.6

package/spec/modules/provider-adapter.md

@@ -1,45 +0,0 @@
-# provider adapter
-
-## 作用
-
-provider adapter 负责把 Athlete 的请求发送到具体模型服务，并把 provider-specific 能力差异收敛成稳定的 capability profile。
-
-## 当前策略
-
-- 优先 OpenAI-compatible
-- provider-specific fallback、reasoning 能力、request body 差异、recovery model 选择都下沉到 provider 层
-- 运行时对网络错误、超时、上下文过长仍有恢复策略，但主循环只消费 provider capability，不再写死某家模型名
-
-## 规则
-
-1. provider 能换，主循环不跟着重写。
-2. provider 问题先在 adapter 层处理，不外溢到任务语义层。
-3. 模型 fallback 属于运行时策略，不属于业务模块。
-4. kernel 可以知道“当前 request model 是什么”，但不应该知道“某个具体 provider 为什么要这样切”。
-5. reasoning request body、tool 兼容 fallback、failure streak recovery model 都属于 provider capability。
-
-## 当前实现落点
-
-- `src/agent/provider.ts`
-  - `resolveProviderCapabilities()`
-  - `buildProviderRequestBody()`
-  - `selectProviderRequestModel()`
-- `src/agent/api.ts`
-  - 只消费 provider capability，不再直接判断 `deepseek-reasoner -> deepseek-chat`
-- `src/agent/retryPolicy.ts`
-  - 通过 provider 层选择 recovery request model
-- `src/agent/session/messages.ts`
-  - reasoning content 是否参与请求，也通过 provider capability 决定
-- `src/config/store.ts`
-  - 统一解析 `provider / baseUrl / model`
-
-## 当前状态说明
-
-- 代码默认配置与模板示例仍以 DeepSeek 系列为起点
-- 项目本地 `.athlete/.env` 可以把有效 provider / base URL / model 覆盖到其他 OpenAI-compatible 服务
-- 但 DeepSeek-specific 行为已经不在 kernel 主干里硬编码
-- adapter 层允许出现具体 provider 名词；主循环和业务规则层不允许依赖这些名字
-
-## 下一阶段要求
-
-总指挥层、closeout、workflow guard、acceptance gate 都不依赖某一家 provider 特性。

package/spec/modules/runtime-metrics.md

@@ -1,162 +0,0 @@
-# runtime metrics
-
-## 作用
-
-这一层开始，Athlete 的 session 会持久化结构化 `runtimeStats`，
-作为正式运行态仪表盘的真相源。
-
-prompt layer metrics / context diagnostics 不属于这里的持久化真相源；它们只是在 request 构建阶段即时派生，用于诊断 prompt 体积、分层占比、hotspot 与压缩触发原因。
-
-它回答的是：
-
-- 这次 session 一共发了多少次 provider request
-- 模型等待总耗时是多少
-- tool 一共调用了多少次、各自累计耗时多少
-- yield / continuation / recovery / compression 各发生了多少次
-- 有多少 tool result 被 externalize，以及累计字节数是多少
-- provider usage 是 available、partial 还是 unavailable
-
-## 真相源位置
-
-- `SessionRecord.runtimeStats`
-- 仍然持久化在既有 session JSON 文件里
-- 不新建平行 JSON 真相源
-
-## 当前结构
-
-`runtimeStats` 当前包含：
-
-- `version`
-- `model.requestCount`
-- `model.waitDurationMsTotal`
-- `model.usage.requestsWithUsage`
-- `model.usage.requestsWithoutUsage`
-- `model.usage.inputTokensTotal`
-- `model.usage.outputTokensTotal`
-- `model.usage.totalTokensTotal`
-- `model.usage.reasoningTokensTotal`
-- `tools.callCount`
-- `tools.durationMsTotal`
-- `tools.byName`
-- `events.continuationCount`
-- `events.yieldCount`
-- `events.recoveryCount`
-- `events.compressionCount`
-- `externalizedToolResults.count`
-- `externalizedToolResults.byteLengthTotal`
-- `updatedAt`
-
-## 来源
-
-### model request
-
-- 来源：`src/agent/api.ts`
-- 统计粒度：真实 provider request attempt
-- 包括 streaming、non-streaming fallback、retry、retry fallback
-
-### tool execution
-
-- 来源：`src/agent/runTurn.ts`
-- 统计粒度：真实 runtime tool execution
-- `tools.byName` 记录每个 tool 的调用次数、累计耗时、成功次数、失败次数
-
-### yield / continuation / recovery
-
-- 来源：`src/agent/turn/persistence.ts`
-- continuation 包括：
-  - managed continuation 的内部续跑输入
-  - 用户显式 `continue` / `resume` 这类恢复输入
-
-### compression
-
-- 来源：`src/agent/runTurn.ts`
-- 当 `buildRequestContext(...)` 返回 `compressed = true` 时记一次
-
-### externalized tool results
-
-- 来源：`src/agent/runTurn.ts` + `src/agent/toolResults/storage.ts`
-- 只在 tool result 实际被 externalize 时累计
-
-## 用户入口
-
-当前最小仪表盘入口：
-
-- `/runtime`
-- `/stats`
-- `/仪表盘`
-
-这些命令读取既有 session 真相源，并在命令执行当下即时派生 prompt diagnostics。
-它们可以解释 runtime，但不会把这些诊断结果反写成新的 session 真相。
-
-## 当前 summary 最少包含
-
-- model request 次数
-- model wait 总耗时
-- tool call 次数
-- tool 总耗时
-- yields / continuations / recoveries / compressions
-- externalized result count / bytes
-- top tools
-- slowest step
-- usage availability
-- session health
-- durable truth 区块：
-  - `runtimeStats.updatedAt`
-  - `checkpoint.flow.phase`
-  - `checkpoint.flow.lastTransition`
-  - `verificationState.status`
-- derived diagnostics 区块：
-  - why continue / why recovery / why compression
-  - why slow
-  - flaky tool hotspot
-  - prompt layer / hotspot / slimming 诊断
-
-## durable truth vs derived diagnostics
-
-### durable truth
-
-- `SessionRecord.runtimeStats`
-- `SessionRecord.checkpoint`
-- `SessionRecord.verificationState`
-
-### derived diagnostics
-
-- runtime summary 文本
-- why slow / why continue / why recovery / why compression 的诊断结论
-- prompt layer chars / block counts / hotspots
-- request-time context diagnostics（如 initial / final estimated chars）
-
-derived diagnostics 必须来自既有真相源和当前 request 构建结果，
-不能反过来变成新的持久化 truth。
-
-## usage 规则
-
-- 只有 provider 明确返回 usage 时才记录 usage
-- 如果 provider 没返回 usage，summary 必须显示 `unavailable` 或 `partial`
-- 不根据字符数、消息数、模型名去估算 token
-
-## 健康状态
-
-当前 summary 会给出：
-
-- `healthy`
-- `warning`
-- `recovering`
-
-它来自 checkpoint phase、verification state、recovery 事件等正式状态的推导视图，
-不是另一份单独持久化的状态。
-
-## 真实验证
-
-当前真实 API 验证入口：
-
-- `npm run verify:runtime-observability-api`
-
-它至少要确认：
-
-- `runtimeStats` 已写进 session
-- reload session 后 `runtimeStats` 仍然存在
-- 真实 model request 被统计
-- 真实 tool call 被统计
-- 用户可读的 runtime summary 路径可用
-- lightweight context 与 checkpoint runtime 没被打坏

package/spec/modules/runtime-rules.md

@@ -1,65 +0,0 @@
-# runtime rules
-
-## 作用
-
-运行时规则是 Athlete 的机器约束层。
-
-## 当前包含
-
-- 计划先行
-- inbox 注入
-- verification 状态机
-- finalize / closeout gating
-- continuation / compression
-- tool error recovery
-- runtime transition 模型
-
-## 不该放进来的东西
-
-- 具体任务拆分算法
-- 具体 skill 内容
-- 某个单一工具的内部实现
-
-## 当前与收口直接相关的规则
-
-- 变更型动作默认要求先 `todo_write`
-- 文件改动和 mutating shell 会把 session 推进到 verification required
-- 轻量交付物允许用定向 `read_file` / auto-readback 完成轻量验证
-- acceptance / verification 统一消费机器 signal，而不是分散反推某个工具名
-- continuation 后仍然读取持久化的 `pendingPaths`，不会因为 slice 切换就忘记“还有哪些输出待验”
-- 当收口条件已满足时，task board closeout 工具会被隐藏，避免 `task_list` / `task_get` / `task_update` 无意义循环
-- 当 todo 已全部完成时，runtime 不再继续鼓励补写 `todo_write`
-- continue / recover / yield / pause / finalize 必须带结构化 reason code，而不是只靠零散字符串
-- 最近一次关键 runtime 决策持久化到既有 checkpoint 真相源，不新增平行 JSON
-- one-shot CLI 收尾输出必须带稳定 machine closeout contract，而不是只打印 session id
-- 交互式 `quit` 如果发现运行中的后台进程，必须先进入 kill-or-continue 二次确认
-
-## 当前 signal 规则
-
-acceptance / verification 当前统一识别的结果类型至少包括：
-
-- `http_endpoint_verified`
-- `web_page_verified`
-- `document_read_completed`
-- `structured_artifact_valid`
-
-换 browser 实现、换 document 引擎、换 provider 时，不应重写 acceptance gate 主体，只能换 adapter 或 signal 生产方式。
-
-## 当前代码落点
-
-- `src/agent/acceptance/signals.ts`
-  - acceptance signal 归一化
-- `src/agent/acceptance/evaluate.ts`
-  - 只消费 signal、file checks、command checks
-- `src/agent/verification/state.ts`
-  - verification 真相源
-- `src/agent/verification/signals.ts`
-  - lightweight verification / auto-readback
-- `src/cli/support.ts`
-  - one-shot closeout report
-- `src/cli.ts`
-  - CLI 终态输出
-
-## 下一阶段要求
-
-总指挥层可以提出“下一步做什么”，但运行时规则仍决定“现在允不允许这样做”。

package/spec/modules/session-resume-compact.md

@@ -1,55 +0,0 @@
-# session / resume / compact
-
-## 作用
-
-这一层负责保护 Athlete 的“长任务可继续”能力。
-
-## 当前能力
-
-- session 持久化
-- resume 继续最近任务现场
-- request context 压缩
-- continuation 自动续跑
-- todo / taskState / verificationState 跨 slice 持续生效
-
-## 当前边界
-
-Athlete 当前的记忆重点是：
-
-- 当前项目
-- 当前任务
-- 当前 turn 相关状态
-- 当前待验证输出 `pendingPaths`
-- 最近一次 verification 结果
-
-它不是跨项目的人格记忆。
-
-## 当前实现约束
-
-- continuation 会复用已有 session，而不是重新发明 todo / verification 状态。
-- compact 只压缩请求上下文，不抹掉任务板、todo、verification 这些真相源。
-- 收口判断可以依赖持久化的 `verificationState.pendingPaths`，不能只看当前 slice 的临时 `changedPaths`。
-- `checkpoint.flow.lastTransition` 会随 session 持久化，保留最近一次关键 runtime 决策的结构化原因。
-
-## Resume / Reset Contract
-
-- `resume` 的语义是继续现有任务现场。
-- `quit` 会先检查当前项目仍在运行的后台进程。
-- 如果没有运行中的后台进程，`quit` 只是退出当前聊天窗口，不主动清空项目运行时状态。
-- 如果有运行中的后台进程，`quit` 必须先进入二次确认：
-  - 确认退出：kill 全部后台进程，再退出
-  - 取消退出：继续留在当前会话
-- 显式 `reset` 会清空当前项目 `.athlete/` 下的运行时状态，并删除当前项目相关的持久化 session。
-- 一旦 `reset` 成功，`resume` 不应恢复已经 reset 掉的运行时。
-- 如果 objective 明确变化，checkpoint 进度必须重置，避免旧任务进度污染新任务。
-- externalized tool-result references 和 verification pending paths 仍然是优先的可恢复锚点，但 reset 会主动销毁这一层锚点。
-- runtime transition reason code 也属于 checkpoint 真相源的一部分，resume / continuation 读取它，而不是再造平行恢复提示。
-
-## 下一阶段要求
-
-未来可以增加更强的恢复能力，但必须遵守：
-
-1. 项目事实优先于抽象记忆。
-2. 记忆是辅助，不是第二真相源。
-3. 不能破坏现有 continuation / compact / resume 的稳定边界。
-4. destructive reset 必须保持显式、可理解、不可与普通 quit 混淆。

package/spec/modules/task-state.md

@@ -1,41 +0,0 @@
-# task state
-
-## 作用
-
-任务状态是 Athlete 控制面的核心。
-
-## 当前字段重点
-
-- `status`
-- `blockedBy`
-- `blocks`
-- `assignee`
-- `owner`
-- `checklist`
-- `worktree`
-
-## 当前规则
-
-1. `assignee` 表示应该谁做。
-2. `owner` 表示现在谁正在做。
-3. 被阻塞任务不能启动。
-4. 已完成任务不能随意重开。
-5. `status / blockedBy / assignee / owner / worktree` 不是孤立看的，lead orchestrator 会联合 `TeamStore`、`BackgroundJobStore`、`WorktreeStore` 派生任务 lifecycle。
-6. 同一个任务的 machine lifecycle 至少要能区分：
-   - `blocked`
-   - `ready`
-   - `active`
-   - `completed`
-7. `ready` 还要继续区分是谁能接：
-   - lead
-   - 指定 teammate
-   - nobody（缺失或冲突时 fail-closed）
-8. 如果 task 仍绑定失效 worktree、指向缺失 background job、或保留了不存在 teammate 的 handoff，系统必须阻断继续派工。
-
-## 下一阶段演进方向
-
-任务系统后续如要继续长：
-
-- 优先先扩现有 task truth
-- 不新造平行 orchestration plane
-- 继续让 lifecycle / ownership / handoff 由机器从既有真相源派生

package/spec/modules/telegram-private-chat.md

@@ -1,291 +0,0 @@
-# Telegram 私聊接入
-
-## 范围
-
-- 只支持 Telegram 私聊
-- 不支持群聊、超级群、频道
-- 不做 Webhook 平台化，不做按钮系统，不做多平台网关
-- 只做 Telegram 通道层能力增强，不重写 Athlete 核心 runtime
-
-## 宪法对齐
-
-这块实现必须遵守 `spec/principles/` 里的几条核心原则：
-
-- `P01 一个循环一个智能体`
-  Telegram 只是把私聊消息接到现有 lead turn，不重写 agent loop
-- `P02 加一个工具只加一个处理器`
-  Telegram 文件回传能力通过独立工具处理器接入，不把平台分支塞进核心循环
-- `P16 配置只能有一个入口`
-  Telegram 配置统一走 `src/config/store.ts` 和 `.athlete/.env`
-- `P17 扩展靠事件生长`
-  Telegram 通道通过边界模块、turn display、tool registry、store 扩展，不靠在主循环里硬塞平台细节
-- `P18 主循环和文件都不能长胖`
-  Telegram 服务编排、turn 执行、附件处理、日志和命令语义要按职责拆模块，避免一个大文件继续膨胀
-
-## 模块边界
-
-Telegram 相关实现集中在 `src/telegram/`：
-
-- `types.ts`
-  Telegram update/message 的规范化类型
-- `config.ts`
-  Telegram 配置默认值、归一化、运行时目录解析
-- `botApiClient.ts`
-  Telegram Bot API HTTP 客户端
-- `polling.ts`
-  long polling 和 offset 提交
-- `offsetStore.ts`
-  update offset 持久化
-- `sessionMapStore.ts`
-  Telegram peer 到 Athlete session 的绑定
-- `attachmentStore.ts`
-  Telegram 入站附件元数据持久化
-- `deliveryQueue.ts`
-  文本/文件投递队列、重试、恢复
-- `messageChunking.ts`
-  长文本分片
-- `localCommands.ts`
-  Telegram 端命令语义适配
-- `turnDisplay.ts`
-  Telegram 过程输出适配
-- `turnRunner.ts`
-  单个 Telegram turn 的运行编排
-- `service.ts`
-  Telegram 服务总控、拉取、分发、stop、恢复
-- `logger.ts`
-  终端高层日志
-- `sendFileTool.ts`
-  Telegram 文件回传工具
-- `processLock.ts`
-  Telegram 服务单实例锁
-- `proxy.ts`
-  Telegram 代理环境接线
-
-CLI 只负责注册命令和注入依赖，仍然放在：
-
-- `src/telegram/cli.ts`
-- `src/cli.ts`
-
-## 启动方式
-
-命令：
-
-```powershell
-athlete telegram serve
-```
-
-行为：
-
-1. 读取统一配置入口 `src/config/store.ts`
-2. 解析 Telegram runtime 配置
-3. 获取 Telegram 单实例锁
-4. 启动 long polling
-5. 把私聊消息接入现有 Athlete session / turn 体系
-6. 把文本和文件回复先落盘到 delivery queue，再尝试发送
-
-默认交互模式不会被劫持；只有显式执行 `athlete telegram serve` 才会启动 Telegram 服务。
-
-## 配置
-
-Telegram 配置统一并入 `AppConfig.telegram` / `RuntimeConfig.telegram`。
-
-推荐通过 `.athlete/.env` 配置：
-
-```text
-ATHLETE_TELEGRAM_TOKEN=replace-with-your-bot-token
-ATHLETE_TELEGRAM_ALLOWED_USER_IDS=123456789
-ATHLETE_TELEGRAM_API_BASE_URL=https://api.telegram.org
-ATHLETE_TELEGRAM_PROXY_URL=http://127.0.0.1:7897
-ATHLETE_TELEGRAM_POLLING_TIMEOUT_SECONDS=50
-ATHLETE_TELEGRAM_POLLING_LIMIT=100
-ATHLETE_TELEGRAM_POLLING_RETRY_BACKOFF_MS=1000
-ATHLETE_TELEGRAM_MESSAGE_CHUNK_CHARS=3500
-ATHLETE_TELEGRAM_TYPING_INTERVAL_MS=4000
-ATHLETE_TELEGRAM_DELIVERY_MAX_RETRIES=6
-ATHLETE_TELEGRAM_DELIVERY_BASE_DELAY_MS=1000
-ATHLETE_TELEGRAM_DELIVERY_MAX_DELAY_MS=30000
-```
-
-说明：
-
-- `ATHLETE_TELEGRAM_ALLOWED_USER_IDS` 必须显式配置；空白名单等于任何人都不能控制 bot
-- `ATHLETE_TELEGRAM_PROXY_URL` 是 Telegram 专用代理入口，例如 Clash Verge 的 `mixed-port`
-- Telegram 配置仍然只走同一套配置入口，不另起平行配置系统
-
-## 什么是本地代理入口
-
-当用户使用 Clash Verge、Clash Meta、mihomo 这类代理工具时，常见情况是：
-
-- Telegram 域名会被 fake-ip 机制映射成 `198.18.x.x`
-- 应用程序自己不能直接拿这个 fake-ip 去直连
-- 应用程序应该把请求交给本地代理软件去转发
-
-这里的“本地代理入口”就是：
-
-- 代理软件跑在用户自己的电脑上
-- 它会打开一个本地地址
-- 例如 `http://127.0.0.1:7897`
-
-对于 Telegram 服务来说，真正稳定要配置的是这个本地入口，而不是 Telegram 最后被解析成的 fake-ip。
-
-## 单实例语义
-
-Telegram 服务必须是单实例：
-
-- 同一个项目状态目录下，只允许一个 `telegram serve`
-- 如果已经有一个存活实例，第二个实例直接拒绝启动
-- 如果只剩下陈旧 `service.pid`，新实例会识别为 stale lock 并自动覆盖
-
-这样可以避免：
-
-- 同一条消息被两个实例重复消费
-- 同一条最终回复被重复发送
-- 用户关掉一个窗口后，误以为服务还神秘存活
-
-## 会话与恢复
-
-Telegram 状态目录位于：
-
-```text
-<project-state-root>/.athlete/telegram/
-```
-
-持久化内容包括：
-
-- `offset.json`
-  下一个待消费的 Telegram update offset
-- `session-map.json`
-  `telegram:private:<chatId>` 到 Athlete session 的映射
-- `attachments.json`
-  入站文件元数据和本地落盘路径
-- `delivery.json`
-  待发送文本/文件、重试次数和下次重试时间
-- `service.pid`
-  Telegram 单实例锁文件
-
-恢复语义：
-
-1. 重启后先读 `offset.json`，从上次提交之后继续拉取
-2. `session-map.json` 恢复同一 Telegram 私聊到同一个 Athlete session
-3. `delivery.json` 在启动和轮询前后都会扫描并补发
-4. `attachments.json` 让“刚发的文件”这类语义可继续工作
-5. `service.pid` 如果是失效旧 pid，会被新实例覆盖
-
-## 文件能力
-
-### 入站文件
-
-- 用户可以在 Telegram 私聊直接发文件
-- Bot API 会下载文件到项目状态目录下的 Telegram 文件目录
-- 附件元数据会持久化
-- 当前 turn 会拿到这份文件的本地路径和上下文说明
-- 用户可以继续说“分析我刚发的文件”
-
-### 出站文件
-
-- 用户可以要求 Athlete 查找本地文件并发回 Telegram
-- 用户可以要求 Athlete 生成文件并发回 Telegram
-- 回复形式必须是真实 Telegram document
-- 不允许只发本地路径或文本链接糊弄
-
-### 恢复与边界
-
-- 文本和文件都先进入 delivery queue，再尝试发送
-- 失败后按指数退避重试
-- 服务重启后继续恢复待发送文本和文件
-- 文件大小要做边界校验
-
-## `/stop`
-
-Telegram 端只保留一个停止命令：
-
-```text
-/stop
-```
-
-语义：
-
-- 只停止“当前这个 Telegram 用户当前正在执行的任务”
-- bot 服务继续在线
-- 不停止整个 Telegram 服务
-- 不影响其他白名单用户
-- 停止后当前用户还能继续发下一条任务
-
-## Telegram 端命令语义
-
-Telegram 端命令语义与本地 CLI 有明确边界：
-
-- `/session`、`/config`、`/runtime` 等查看类命令继续复用现有本地命令层
-- `/multi` 明确拒绝，并提示直接发送完整消息
-- `quit` / `reset` 不再作为 Telegram 主命令暴露
-- Telegram 端收到 `quit` / `reset` 时，只做提示，不执行本地终端语义
-
-## 过程输出
-
-Telegram 过程输出要更接近终端工作感知，但遵守“可见段按事件逐条镜像”的单一语义，不能刷底层噪音。
-
-### Telegram 聊天框里的可见消息
-
-过程消息按实际事件顺序发送，不做机械固定轮换，也不做最终汇总：
-
-- `onToolCall` 不直接发聊天消息，避免把工具名刷进聊天框
-- 非 `todo_write` 的 tool result 只发送一条可见 preview，并截断到 150 个字符
-- `todo_write` 对应的可见 preview 一次，就发一条 todo preview 消息
-- `onAssistantDelta` 只作为阶段内缓冲信号，不直接发聊天消息
-- `onAssistantText` 表示拿到了完整 assistant 文本时，发一条 assistant 消息
-- `onAssistantDone` 带文本且当前 assistant 阶段尚未发出时，发一条最终 assistant 消息
-- 不合并多段 assistant
-- 不把 tool / todo / assistant 混成一条
-
-不发送的内容：
-
-- 工具输出正文
-- 大段文件原文
-- 底层噪音日志
-- reasoning
-- `onStatus` 一类非可见噪音
-
-格式约束：
-
-- 不额外加抬头
-- 过程消息保持聊天式、顺序式输出，更接近终端高层过程感知
-
-### 终端日志
-
-终端持续输出高层过程日志，包括：
-
-- 收到哪个 Telegram 用户的消息
-- 当前进入哪个 session
-- 当前在哪个阶段
-- 当前调用了哪个工具
-- 当前是否停止、失败、成功
-- 当前是否发送了文本或文件
-
-显式信号与可靠性约束：
-
-- Weixin / Telegram 共享同一层可见事件判定与 durable turn display
-- durable outbound 只按事件顺序发送，不按文本去重
-- 如果要防重复，只能基于 event id / delivery state，不能基于文本内容
-- `runOnce` 必须等当前 turn 的可见输出 durable 完成后再 commit 输入
-- `serve` 主循环通过显式 pending-commit 队列继续轮询和处理 `/stop`，不靠时序猜测
-- 可见消息 durable enqueue 失败不能 silent swallow，必须继续上抛
-
-## 串行与隔离
-
-- 同一 Telegram peer 使用 `PerPeerCommandQueue` 串行执行
-- 不同 peer 之间允许并发
-- `/stop` 与 per-peer 串行队列兼容
-- 同一个 peer 的 turn 不能并发破坏同一个 session
-
-## 安全与约束
-
-- 只接受 `allowedUserIds` 白名单内的私聊用户
-- 非白名单用户不会进入 Athlete turn
-- 群聊/频道消息不会进入私聊 session
-- Telegram 端仍然遵守 Athlete 当前 runtime 的 `mode`、`allowedRoots` 和执行约束
-
-## 维护约束
-
-- Telegram 平台细节不能下沉到 `src/agent/`、`src/tools/`、`src/ui/`
-- 只允许薄接线进入核心 runtime
-- 新增能力优先继续生长在 `src/telegram/`