Repository navigation
Conversation
Signed-off-by: ficowang <fico@xd.com>
Signed-off-by: ficowang <fico@xd.com>
Signed-off-by: ficowang <fico@xd.com>
Signed-off-by: ficowang <fico@xd.com>
Signed-off-by: ficowang <fico@xd.com>
Signed-off-by: ficowang <fico@xd.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 858623e9b4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
| Filename | Overview |
|---|---|
| apps/desktop/src/main/hook-control/telegramDelivery.ts | 新增官方 Telegram 投递 bridge 与持久幂等日志，但无锁回执更新可被并发旧状态覆盖。 |
| apps/desktop/src/main/hook-control/manager.ts | 增加能力、epoch、目标门控和在途回执匹配，连接断开时按未知结果收口。 |
| packages/lizi-mcps/src/scheduler/telegramDelivery.ts | 新增 status/send/receipt 工具，但发送入口缺少任务来源、session 所有权或明确授权门控。 |
| packages/slack-hook-protocol/src/parse.ts | 新增 Telegram 实际回执校验，但没有验证新加入的 send delivery 元数据。 |
| packages/slack-hook-protocol/src/types.ts | 扩展发送 capability、epoch、delivery 和实际消息回执类型，运行时校验尚未完整同步。 |
Sequence Diagram
sequenceDiagram
participant A as cc/codex Session
participant MCP as Scheduler MCP
participant B as Telegram Delivery Bridge
participant J as Owner-scoped Journal
participant H as Hook Manager
participant S as Telegram Server
A->>MCP: schedule_telegram_status
MCP->>B: status()
B-->>A: capability + owner DM target
A->>MCP: schedule_telegram_send(text, target, key)
MCP->>B: send(input)
B->>J: 原子创建 started claim
B->>H: msg.op(send + binding + epoch + deadline)
H->>S: WebSocket frame
S-->>H: msg.op.result
H->>B: onResult(receipt)
B->>J: 更新 sent / unknown / not_sent
B-->>A: 持久回执
Prompt To Fix All With AI
### Issue 1
packages/lizi-mcps/src/scheduler/telegramDelivery.ts:39
**发送入口缺少授权门控**
`cindy_scheduler` provider 明确允许任意 cc/codex session 使用 `schedule_*` 工具，而这里直接将调用方提供的 `text` 交给 bridge，没有像其他 scheduler 写工具一样绑定 session，也没有校验调用来自定时任务或经过用户明确授权。调用方可以先通过 status 获取当前 target，再以官方 Bot 身份向 owner 私聊发送任意内容，超出了“定时结果或明确授权测试”的权限范围。请在工具层加入可验证的任务来源、session 所有权或明确授权门控。
**How this was verified:** The scheduler provider explicitly allows every cc/codex session, while this handler forwards caller-controlled text to the authenticated owner-DM bridge without any task-origin or authorization check.
### Issue 2
apps/desktop/src/main/hook-control/telegramDelivery.ts:179-181
**并发更新会降级成功回执**
这里先读取持久记录以确认它尚非 `sent`，随后再用内存中的旧 `row` 覆盖文件，两个操作之间没有锁或版本校验。如果迟到回执恰好在这期间将记录更新为 `sent`，最终写入会把它重新降级为 `unknown` 或 `not_sent`。`onResult` 也对同一文件执行独立的读取和覆盖写，而且同一 owner profile 明确支持多进程共享，因此该竞态也可能跨进程发生，导致真实成功回执丢失。请使用跨进程锁、版本化 CAS，或在同一临界区内重新读取并按单调状态合并。
### Issue 3
packages/slack-hook-protocol/src/types.ts:1372-1373
**投递元数据缺少运行时校验**
新增的 `MessageOpAction.delivery` 只有 TypeScript 类型，没有进入 `validateMessageOp` 的运行时校验。解析器会接受缺失字段、错误类型或非有限 `expiresAt` 等畸形对象，并原样交给消费者，使共享协议无法可靠保证新增的 binding、epoch 和 deadline 契约，也让问题只能在下游才暴露。请在 `msg.op` 的 `send` 分支校验对象形状和 deadline 的数值约束，并补充相应的负向协议测试；是否已经过期仍可由执行端按当前时间判断。
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "chore(telegram): 清理主动投递文件末尾空行" | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
本 PR 命中维护者确认门（规则文档 + 核心出站路径），暂不进入自动代码审查或合并。 改动包括官方 Telegram 定时主动投递（Host 桥、scheduler MCP、持久回执、协议能力协商），以及 请维护者直接在本 PR 上 Approve；需要作者修改则 Request Changes。讨论 issue：#4315 |
MagicLizi
added
awaiting-discussion
Signed-off-by: ficowang <fico@xd.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d7ec17bc49
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: ficowang <fico@xd.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b32415502b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| try { | ||
| try { fs.writeFileSync(fd, JSON.stringify(row)); fs.fsyncSync(fd); } | ||
| finally { fs.closeSync(fd); } |
There was a problem hiding this comment.
On filesystems where syncing a newly created file does not also persist its parent-directory entry, fsyncSync(fd) can leave the claim absent after a power loss. If Telegram accepted the network send before that loss, the next process sees no journal for the same idempotency key and sends the message again, defeating the durable-before-network guarantee and producing duplicate user-visible messages. The claim's directory entry must be made durable before deps.send is reached.
AGENTS.md reference: AGENTS.md:L76-L79
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
bef4572 已实际推入本 PR：POSIX 在写入并 fsync 认领文件后同步认领目录及祖先目录，失败时不进入 send；相关回归、类型检查和根 related 门禁已有通过记录。Windows 的 Node/libuv 不支持目录 fsync，本提交沿用既有平台处理，未做 Windows 断电持久化实测，因此这条跨平台耐久性反馈暂保留未解决，等待明确其剩余保证；不将其归为仅等 reviewer。
There was a problem hiding this comment.
补充本轮平台查证，保持此 thread 未解决：微软的文件缓存说明确实要求通过 FlushFileBuffers 或 FILE_FLAG_WRITE_THROUGH 落下元数据（https://learn.microsoft.com/en-us/windows/win32/fileio/file-caching）；但本实现创建多级目录后的 Windows 断电恢复保证仍没有原生证据。Node 22 官方文档列出的 Windows file-open 常量不含 O_SYNC/O_DSYNC（https://nodejs.org/docs/latest-v22.x/api/fs.html#file-open-constants），因此不能直接套 POSIX 数值标记或空置目录 fsync 就称修复。POSIX 回归已覆盖目录/祖先同步失败时零发送；Windows 还需对新目录+claim的实际持久边界验证，必要的存储实现调整另按兼容/回滚约束评审。本轮先处理独立的 plain 长度 P1，不将此项列为仅等 reviewer 或声称掉电安全。
Signed-off-by: ficowang <fico@xd.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bef457293b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: ficowang <fico@xd.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 01a9a16286
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: ficowang <fico@xd.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1fc7a99192
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: ficowang <fico@xd.com>
Signed-off-by: ficowang <fico@xd.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9f83581eaf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Signed-off-by: ficowang <fico@xd.com>
Signed-off-by: ficowang <fico@xd.com>
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
Signed-off-by: ficowang <fico@xd.com>
|
mergeable 变 CONFLICTING 后已同步主干（f14663d60）：冲突仅在 |
|
合 main 后 CI：Windows (2/2) 失败为 |
…aAccess Signed-off-by: ficowang <fico@xd.com>
|
已同步主干（8478f4670）：#5134 合入后 |
冲突处理（两侧均保留）： - hook-control/manager.ts：Telegram helloFeatures 同时声明 telegram-dm-send-v1 与主干新增的 progress/final/card ops 及 commands 能力。 - slack-hook-protocol/parse.ts：msg.op.result 同时校验本分支的 deliveryState / sentMessage 与主干的 errorCode / channelErrorCode（均为可选字段）。 - telegram-bot-parity.md 缺口 2：以主干现状为基础，并入定时主动正文 send 的说明。 Signed-off-by: ficowang <fico@xd.com>
Signed-off-by: ficowang <fico@xd.com>
Signed-off-by: ficowang <fico@xd.com>
…-scheduled-delivery-sync Signed-off-by: ficowang <fico@xd.com> # Conflicts: # apps/desktop/src/main/mcp-integrations/mcp-providers.ts
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e9f288f5ed
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
账号删除边界（clearPersisted: true）只注销了投递桥，owner 作用域下的 telegram-delivery-receipts（.sent 中含实际发送的 Telegram 正文与 entities） 会残留。现记录桥的目录，在删除账号时于注销桥之后清除；普通登出与退出仍保留 日志以便幂等重放。 Signed-off-by: ficowang <fico@xd.com>
2 participants
这次改了什么
摘要
本次补齐 POSIX 回执发布的目录同步：
.sent/.result发布并清理临时名后同步父目录及祖先；同步失败保留 claim、不会重发。新增四个反证用例旧实现全部失败，修复后投递套件 30/30、Desktop typecheck 和 Node 22 根 related（Desktop 242.2s、MCP 6.8s、协议 2.0s）通过。最新 head 的 CI 需独立核验；Windows 掉电耐久性 P1 仍开放。为定时结果及用户明确授权的测试增加官方 Telegram 本人私聊出站入口，保留原文和实际回执。发送前核对当前绑定、连接 epoch、能力协商及授权，先持久认领再发出；结果未知不重发，迟到成功回执不能被旧写入降级。
最新修复在 MCP 和 Host 两层限制 plain 与 HTML 单段源码最多 4096 个 UTF-16 单位。超长内容在写 claim/网络前拒绝，修正正文后同一 key 仍可使用。HTML 采用保守源码预算，标签与实体也计入长度；调用者负责保持完整标签预先分段与展示验证，Host 不截断或改写原文。
变更类型
fix缺陷修复feat官方本人 DM 独立出站入口范围
UI 变化
不涉及新 UI、样式或界面文案，使用现有 Host 授权流程。
怎么验证的
本轮验证
pnpm test:unit:related，Desktop 全量 224.8 秒、MCP 5.9 秒、协议 1.7 秒及测试 runner 均通过。--if-present自动跳过。既有验证与边界
既有反证涵盖并发 claim、SIGKILL/重启、旧 unknown 写入与迟到 sent 竞争、发送前目录同步失败零发送、连接/epoch/binding 在发帧前变化时明确 not_sent。两仓协议的 delivery 字段及回执 entities 校验保留。既有本地跨仓 fixture 回环不是官方 Telegram 实发验收。
风险
风险分类
影响与回滚
提交前检查
主干冲突修复（2026-09-16 20:00）
同步 main 143e12c，解决 hook-control/manager.ts 的 Telegram 发送入口与主干 Slack 通讯控制入口冲突，两侧行为与测试均保留。最新主干已包含上轮三处源码字符串断言修正，本地使用已验证 SQLite ABI127 的 Node 22.22.3，避免 Node25 ABI 不匹配。
Windows 认领目录掉电耐久性 P1、#4315 产品批准与真实 Telegram 实发验收仍保留；本次没有实发消息，也没有将合并冲突修复等同于上述问题已解决。
验证：Desktop typecheck 通过；@cindy/mcps、@cindy/slack-hook-protocol 无 typecheck script，按仓库 if-present 规则跳过；根 related 自动选择完整适用工作区并全部通过（Desktop 321.7s，maker-core 157.9s）。新 head 9f83581 CI 单独等待核验。
2026-09-16 发送前断线 P1 修复