Lead Pulse Guard watches Facebook comments, Lead Ads forms and mailboxes, drafts the answer with an LLM, and waits for someone to approve it. Nothing reaches a customer automatically. Lead Pulse Guard 监控 Facebook 评论、广告线索表单和邮箱，用大模型起草回复，然后等人工确认。没有任何内容会自动发给客户。
All three are handled structurally here — by code that refuses to act, not by asking the model nicely. 下面三种情况在这里都是靠结构解决的 —— 由代码直接拒绝执行，而不是在提示词里请求模型「请勿」。
Your bot replies to a comment. That reply arrives as a new webhook event. The bot answers itself. Forever. 机器人回复了一条评论，这条回复又以新事件的形式回到 webhook，机器人于是回复自己，如此循环。
A customer says "thanks". The bot answers. They say "ok". It answers again. Nobody is being helped, and the thread never ends. 客户说声「谢谢」，机器人回一句；客户再说「好的」，机器人再回一句。谁的问题都没被解决，话头也停不下来。
Asked about a spec it does not know, the model produces a plausible number. That number is now public, and attributed to your company. 被问到一个它并不知道的参数时，模型会给出一个看起来很合理的数字。这个数字现在就挂在公开评论区，署着你公司的名字。
Every channel converges on the same card: the original message, the model's draft, and a person who can send, edit or ignore it. 所有渠道最终汇到同一张卡片：原始消息、模型草稿，以及一个可以「发送 / 改后发送 / 忽略」的人。
| Entrance入口 | Delivery投递方式 | Silent failure mode静默失效方式 |
|---|---|---|
| Page comments主页评论 | webhook · feed | Our own replies return as new events自家回复被当成新事件送回来 |
| Lead Ads forms广告线索表单 | webhook · leadgen | The event never arrives at all事件根本不投递 |
| Mailbox邮箱 | IMAP poll · read-only | None, as long as the poll runs只要轮询在跑，就不会漏 |
We measured a day when five Lead Ads submissions arrived and only two produced a webhook event. No error, no log line, no retry — a broken feed and a quiet day look identical from the receiving end. 我们实测过一天：进来 5 条广告线索，只有 2 条产生了 webhook 事件。没有报错，没有日志，也没有重试 —— 从接收端看，链路断了和今天没人来是一样的。 — why there is a second, independent read path— 这就是为什么还要有一条独立的读取路径
So the lead poller and the comment poller run alongside the webhooks. The pollers do not re-implement the decision logic: the comment poller re-signs each comment as a webhook and feeds it back to the gateway, so "should we reply to this" exists in exactly one place. Worst case moves from never to ten minutes. 所以除了 webhook，还有线索轮询和评论轮询在跑。轮询器不复制判断逻辑：评论轮询会把评论重新签名、当成一条 webhook 送回网关，于是「这条该不该回」在全系统只有一份实现。最坏情况从「永远收不到」变成「最多晚十分钟」。
Everything below is in the repository and covered by the reasoning in the docs. 以下每一项都在仓库里，设计理由写在 docs 中。
X-Hub-Signature-256 checked against the bytes as received, with a timing-safe compare. Invalid requests get 403 and are not logged. 对收到的原始字节计算 X-Hub-Signature-256，并用定时安全比较。签名不对的请求返回 403，且不记录内容。
It holds no downstream credential. Compromising it gets an attacker a write to a spool file, nothing more. 它不持有任何下游凭据。即使被攻破，攻击者最多也只能往一个 spool 文件里写一行字。
The handoff is an append-only JSONL spool. No broker to operate, and every event is replayable. 交接是一个只追加的 JSONL 文件。没有中间件要运维，每一条事件都能重放。
Each Page loads its own confirmed facts and a do-not-state list. Empty KB means the model may state nothing specific. 每个主页加载各自的「已确认事实」和「禁止表述」清单。知识库为空时，模型不得作出任何具体陈述。
Output is strict JSON with answers_question and invented_specifics flags, so a bad draft is visible before a human reads it. 输出是严格 JSON，带 answers_question 和 invented_specifics 两个自检字段，草稿有问题在人工读到之前就能看出来。
Chat callbacks return immediately and publish in a background thread — the timeout that makes people click twice and post twice. 卡片回调立刻应答，发帖放到后台线程 —— 超时会让人再点一次，然后就发了两遍。
Webhook and poller race on the same activity ID; whichever arrives first claims it, the other becomes a no-op. webhook 和轮询会争抢同一个活动 ID，先到的占位，后到的自动变成空操作。
Every fetch uses BODY.PEEK. Nothing is marked read, moved or deleted, and the first run establishes a baseline instead of backfilling history. 全部用 BODY.PEEK 取信，不标已读、不移动、不删除；首次运行只建基线，不倒灌历史邮件。
The code is free and stays free. What you can buy is the part that takes weeks: wiring it to a real Meta app, keeping it alive, and knowing what to do when Meta changes something without telling you. 代码是免费的，也会一直是。你能买的是最花时间的那部分：接上真实的 Meta 应用、让它一直活着，以及 Meta 哪天悄悄改了东西时知道怎么修。
One-time. We configure everything up to the first real conversation. 一次性交付。一直配到第一条真实对话跑通为止。
Monthly. You do not touch the server, and you do not hear about an expired token from a customer. 按月。你不用碰服务器，也不会等客户告诉你，才发现令牌过期了。
Scoped project. For setups that are not one Page and one language. 按项目。适用于不是一个主页、一种语言就够的场景。
Fixed scope, quoted before anything starts. Hosting is a flat monthly fee. No per-message charges — your cost should not grow just because a post went viral. 固定范围，开工前给报价。托管是固定月费。不按消息条数收费 —— 一条内容火了不该让你多付钱。
Three cases where automation makes things worse, and we say so before taking money: 有三种情况，自动化只会让事情更糟。这三种我们会在收钱之前说清楚：
With AIW_POST_ENABLED=false the Send button reports a simulated send and nothing reaches Facebook. Flip it only after a few drafts have come through. AIW_POST_ENABLED=false 时，点「发送」只会提示「模拟发送」，不会有任何内容发到 Facebook。先看几条草稿，再考虑打开。
# 1. clone and configure git clone https://github.com/<you>/lead-pulse-guard.git cd lead-pulse-guard cp .env.example .env # 2. gateway (verify → tag → dedupe → spool) docker compose up -d gateway # 3. worker (spool → KB → LLM → approval card) python3 -m venv venv && ./venv/bin/pip install -r requirements.txt AIW_POST_ENABLED=false ./venv/bin/python -m worker.main
Sponsorship buys no licence change, no priority support and no say in the roadmap. It pays for the work nobody enjoys and everybody depends on: signature edge cases, poller idempotency, and keeping the docs true when the code moves. 赞助买不到许可变更、优先支持，也买不到路线图话语权。它支付的是那些没人爱做、但所有人都依赖的工作：签名边界情况、轮询幂等性，以及代码改了之后让文档保持真实。
Sponsorship and paid services are separate things. Services are over here; sponsoring keeps the open-source side moving for everyone. 赞助和付费服务是两件事。服务在上面那一节；赞助是用来让开源这半边继续走下去的。
Channels open with the first public release. Can't sponsor? A failure report with a timestamp and a page ID is worth more than the money. 赞助通道随首次公开发布开放。不能赞助也没关系 —— 一份带时间戳和主页 ID 的失败报告，比钱更有价值。
Two sentences is enough: what you sell, roughly how many inquiries a day, and where they arrive. We will tell you whether this is worth automating — including when the answer is no. 两句话就够：你卖什么、一天大概几条询盘、从哪几个入口进来。我们会告诉你值不值得上自动化 —— 包括答案是「不值得」的时候。
yangke821118@gmail.com · replies usually within one business day yangke821118@gmail.com · 通常一个工作日内回复