tibo-reset-codex

# Tibo Reset — ChatGPT/Codex 额度重置速查 ## 这是什么 「Tibo reset」= OpenAI Codex/ChatGPT Work 负责人 **Thibault Sottiaux（X: @thsottiaux）** 在 X 上宣布的广域额度重置传统。社区昵称「Lord Tibo」，有第三方追踪站 **Tibo Radar** （`codex-reset.com`）和「祈祷重置」亚文化。Tibo 官宣没有固定排期；但平台也会在限额 配置切换时**不发 reset 帖而直接重置账户**。所以「没有 Tibo 帖」只证明没有官宣，不能证明 没有重置。 **先分清用户问的是哪种重置**： | 类型 | 谁触发 | 在哪看 | 性质 | |---|---|---|---| | **官宣广域 RESET** | Tibo / OpenAI | 官方 X 原帖；追踪站只作公告索引 | 无固定排期，常用于里程碑或故障补偿 | | **静默平台重置** | OpenAI 后端或限额配置发布 | 产品 usage 状态 + 同时段多账户第一手实测 + 排除各自正常周期；官方限额变更只作上下文 | 可以没有 reset 帖；未获官方范围声明时只能称「大范围观测到」，不能称「全员」 | | **BANKED reset** | Tibo 推文，或官方现场活动 | 官宣：官方原帖——也可能没有 X 原帖（2026-09-29 DevDay 现场按按钮发放，最先由第三方站运营者记录，随后经用户名下多账号读数证实；此时没有官宣，到账按用户对自己账号的直接观测或同一 `account_ref` 的前后读数判，都没有则未核实）；到账：逐账号对照产品内备用重置库存前后读数 | 一次性「存着随你用」的额度包，**到账后不自动消耗**，由用户在 usage 页手动兑现；官宣 ≠ 人人到账（有过分批延迟）。触发形态含里程碑庆祝与故障补偿——§1 所述 rollout 延迟补偿属后者（按无访问天数累积，可一人多笔；2026-09 GPT-6 Astra 补偿即此形态） | | **账户级周重置** | 系统按该账户当前用量窗口 | ChatGPT 产品内「Next reset: …」 | 每人时间不同；使用 Full reset 也会改变周重置日期，不从订阅开通日推算 | ## 先判宿主：应用托管的只读研究任务 仅当上层应用明确给出研究问题、上轮完整报告、未决状态、有效纠正、信息截点、 逐条授权的私有来源和结构化输出合同，并明确本轮只做读取与分析、持久交接归应用时走此分支。 即使宿主为获授权的私有来源开放网络和临时工作区写入，也不改变本分支的本地台账边界。 **此分支优先于下方「入口分流」 与「监测轮」的本地台账步骤**：不用 `forecast_log.py summary` / `handoff` 读取用户 目录下可能属于另一研究范围的台账，也不执行 `finding` / `record` / `review` 写入； 不执行裸调用默认的 `query_usage`、`scan_rollouts` 或账号登录/恢复路径，除非宿主把 对应账号/usage 来源明确列入本轮授权清单。未授权或无法读取时，到账和账号状态是 `unknown`，不由公告推断成已到账。 以宿主提供的 `state.entries` 和上轮报告接替监测轮步骤 1，以最终结构化产物接替 步骤 5：把未决承诺、候选来源、类型、窗口、实际覆盖和下一次复查条件写回 `state.entries`，在报告中保留原帖、区分新证据与旧事实，不能把缺失的本地台账说成 「过去没有线索」。继续执行中间步骤的 Tibo 信源发现、上下文补证，以及 `global` / `banked` / `both` / 未明的不同用量决策；公开来源清单仍只是起点。 只有宿主明确列出的私人会话才可通过 `read-wechat-messages` 读取，并先完成该 Skill 要求的账号预检和图片/语音覆盖；未列出、预检失败或只读环境无法处理时标 `uncovered`。其它任何私有来源（含本机账号状态）同样以宿主逐条授权为前提。 宿主产物中的变化摘要只是待核研究，不冒充已送达、已读或正式账户操作。 需要登录浏览器补读公开 X 来源时，先按当前 `ego-browser` 指南核对共享资源占用。 在 macOS 受限 Codex 宿主中，优先由工具直接执行 `ego-browser nodejs -e`；长脚本按 该指南写成本轮新的完整 `.mjs`，再用 `-e` 导入绝对 file URL。实测直接调用可读， stdin/heredoc 及 Python/Node 子进程调用却可能报 `Failed to start ego lite`； 不能把顶层 `-e` 的成功移植成子进程封装已可用。连接成功后仍须实际读取目标正文； 失败保留覆盖缺口，不自动扩大权限、切号或把空壳页面算作已读。这里是执行者采用的 调用约定，不是应用已机械拦截其它调用形式的保证。 不满足本节全部触发条件的独立调用，按下方普通分流和本地台账流程执行。 ## 入口分流 - 每次调用先按[本地预测反馈](references/forecast-feedback.md)读取已有记录；查询获得相关事件 证据后回填未决预测。只读记录为空时不创建文件；提出新预测时保存窗口、依据与本轮反馈。 实际抓取外部数据的调用先落 findings 记录，record/review 用 evidence_refs 挂链（schema 与 规则见该文档「findings：原始读数层」节）。 - 用户已经知道结果，追问「为什么漏了 / 哪一环没覆盖 / 下次怎么避免」→ 切到**历史证据链 诊断**：按当时可得的索引、原帖全文、reply / quote / parent 覆盖、解析结果与 findings 逐层 定位；没有当轮原始记录时保留「获取 / 解析 / 提炼 / 记录哪一步丢失 = unknown」。不要重复查询 已知结果来代替诊断，也不要再次核对用户已明确说不用查的 banked reset。用户同时明确要求 当前账户状态，或当前读数会改变这次诊断时，才并行走账号 SOP；这一分流不阻止明确的实时查询。 - 用户追问**当前**官宣为何尚未到账、为何还没有执行信号 → 按[监测轮](#监测轮从信息到可行动信号) 追查兑现状态和原因；这不是上轮漏报归因，不能只重放旧 findings。 - 裸调用（没带具体问题，只想知道现在什么情况）→ 组合执行：台账回看 → 公告线（Radar 索引 + 独立的 Tibo 主帖时间线 + 有界 reply 发现，按 §1 各路径）+ 故障线（§1）→ 本机落地状态（§2 脚本）→ [监测轮的线索决策](#监测轮从信息到可行动信号)与台账回填。 按输出合同先给当前重置状态结论，再按预测路径给出下一步时间判断；没有可支持的日期窗口时， 给出等待是否值得的判断，不为填满格式调用 `record` 造窗。公告线、故障线与 本机扫描的每次实际抓取先落 findings 记录，回填时用 evidence_refs 挂链（见[预测反馈的 findings 节](references/forecast-feedback.md)）。**§2 之后必须再跑一次实时 banked 查询**（`scripts/query_usage.py`，读法与字段表见 [账号 SOP](references/account-usage.md)）——§2 的 rollout 快照结构上没有备用重置字段，不跑就 答不全「现在什么情况」这个最常被问的维度；只取 banked 一个数即可，并把输出里的 `account_ref` 一起记进 findings（记录规则见 forecast-feedback.md 的隐私契约，banked 计数的可比范围见账号 SOP）；本条其余部分仍只管重置状态。 ⚠️ **scan 与 banked 不要 `&&` 串联**：scan_rollouts 无快照时 exit 1，`&&` 会把 banked 查询直接 短路掉——表面上全套像跑过了，实际少一维（2026-09-19 实测）。两条分开跑，或串联时给 scan 加 `|| true`。**循环场景下 skill 里的裸命令被 `same-cmd-resend-guard` 拦**（端点抖动失败一次 后逐字节重发即拦）——命令开头加 `cd <skill 绝对路径> &&` 换结构即放行（2026-09-19 实测）。 定时循环（如 `/loop`）重复触发时，若距上次检查间隔很短（<10 分钟）且上轮无改判信号，可只跑 公告线确认无新官宣、跳过 incidents/banked/本机扫描全套；这是降成本的取舍，未查的维度 仍标 uncovered。间隔正常、台账里的线索到达复查条件，或上轮出现过新信号时仍跑全套。 **按时段降频**（与按间隔那条正交，两者叠加）：Tibo 睡眠时段（`America/Los_Angeles` 01:00–08:00；每次按当日时区换算北京时间） 只跑公告线一个请求确认无新官宣，跳过 incidents/banked/本机扫描全套——官宣型重置从不落在他 睡眠时段（历史模式，见「Tibo 的时间写法」节），补偿型不依赖他的作息。**降频不能省掉新条目 的全文判读**：Radar 成功返回比上次已裁决更新的索引项时，先按 §1 读取原帖全文，再决定是否 继续降频；`official_window=null` 不能提前结束。**升级例外**包括：`official_window` 明确给窗； 正文出现未来承诺；正文中的时间、类型或范围会改变安排；或台账里已有未决承诺到达跟进条件。 命中任一项就升级回全套，并按承诺的改判条件跟进；都未命中才保留单请求降频。代价要说清： 睡眠时段万一发生无官宣的静默重置，会延迟到活跃时段才发现——静默重置也是人触发的，历史 模式支持睡眠时段不会发生，按可接受处理。（2026-09-18 用户拍板保留正常降频分支。） **正常轮与覆盖自审**：固定检查腿是当前已知来源的起点，不是完整信源表，更不保证「不漏 新重置」。每轮按下文的线索决策处理新证据、未决问题与反馈；连续无新信号也要在下一次 正常轮检查是否出现了值得追查的来源、上下文或反证。用户问「有没有漏信号 / 别人怎么预测」 时，直接核对来源盲区与当时可得信息，不能用「全套已跑」作答。 点名额度/余额本身的问法整条走账号 SOP，本条只管重置状态。 - 本 Skill 改善的是**每次调用或宿主已安排循环时**的读取、判定和记录；它本身没有后台调度、 主动通知或 ACK 机制。没有另行部署并实测这些运行层，就不能声称已保证持续发现、送达或确认已阅。 - 用户问「我们几个账号 / 都用完了吗 / 还有两个满额 / 还有几次 Full reset」→ 先读 [逐账号额度查询与网页登录恢复](references/account-usage.md)。**通道优先级**： 若 `~/.config/agent-fleet/accounts.json` 存在且非空（minions 账号清单），优先走 minions `usage-refresh`（CodexBar RPC 通道，覆盖全部注册账号）；失败或不存在时 才走浏览器隔离 profile（只覆盖 Chrome 登录态能到的账号）。 - 用户问「Tibo 说了什么」或明确只要官宣 → 查**公告路径**。 - 用户问「下一次是什么时候 / 明天会不会重置 / 值不值得等」，包括上一轮刚重置后的追问 → 查公告后读[下一轮重置预测](references/next-reset-forecast.md)，给出主判断、依据和更新时间。 默认继承上文的重置类型；明确问个人周期时仍走账号 SOP，不用个人周重置日期代答全局预测。 - 用户说自己的 weekly/5h 回到 100%、`Next reset` 改了，或贴出 usage 截图 → 先把它记为 **该账户的直接观测**，再查是个人周期还是跨账户事件。 - 用户明确说「肯定又重置了」且聚合器无记录 → 立即走**静默重置路径**；禁止重复查询同一 聚合器后再次用空结果驳回用户。 - 用户只问当前剩余或下一次周期重置 → 同样进入账号 SOP 的实时查询；需要解释历史跳变时 再走 §2 的 rollout 快照。当前余额查询不要求先跑整段历史重建或重查公告。 - 想迁移日常 Chrome 中**现成的 ChatGPT 登录态**到隔离查询 profile → 先读 [Cookie Copy 接入](references/browser-session-migration.md)，加载独立 `cookie-copy` 执行复制与身份验证，再由本 Skill 验证账号绑定的真实额度。先安装缺失依赖并读回； 不把复制成功或仅登录成功当作额度查询完成。 - 想把日常 Chrome 的 Google Cookie 接到隔离查询 profile → 先按 [Cookie Copy 接入](references/browser-session-migration.md) 准备依赖； `scripts/launch-usage-profile.sh <a|b>` 建/开隔离 Chrome profile，关闭目标后用 `scripts/import-google-cookies.py --profile <a|b>` 搬运 `.google.com` 系 Cookie。 - 想**自动**驱动隔离 Chrome 查第二账号用量 → `node scripts/read-usage-profile.cjs`（依赖 `~/.chrome-profiles/tibo-cdp/` 的 playwright；默认 profile a）。读模式直接解析当前登录账号 usage；加 `--drive-login` 在未登录时自动点 `Continue with Google` 驱动到 Google 账号选择器 并列出全部账号。**实测边界（2026-09-16）**：隔离 profile 无 Google 会话 token，账号选择器 每个账号都标 `Signed out`；这只说明当次 Google 路线未取得活会话，不否定上面的 ChatGPT 现成会话迁移。密码/验证码遵守当前宿主的人工边界，登录后再验证读模式。 踩过的可执行细节（代理、真实输入通道对哪个按钮有效、登录态判据、OAuth 轮询）见 [account-usage.md 隔离 Chrome 自动化节](references/account-usage.md#隔离-chrome-profile-自动化真实输入通道的适用边界2026-09-16-实测)。 ## 输出合同：先给结论，再交代边界 用户原话（2026-08-26）：「**你必须给出结论而不是让我给结论。**」 - 第一段第一句必须给出当前证据支持的**唯一最强结论**，禁止用「可能是 A/B/C、请你再看」 把分类责任交还用户。 - 不确定性用于**收窄结论的属性**，不是取消结论： - 只证实一个账户的当前读数 → 「当前账户剩余 X%；Next reset 为 …；是否发生重置未核实」。 - 同一 `account_ref` 的前后读数出现用量下降与锚点变化，但没有直接事件证据 → 「两个观测点之间窗口发生变化；原因未核实」。端点身份相同不能排除中间 A→B→A，不能写成「该账户已经重置」。 - 多账户的身份已绑定读数提前跳变，且各自正常周期与账号切换都解释不了 → 「发生了未官宣的大范围静默重置」。 - 官方明确 all/every → 「官方确认全员重置」。 - 下「已重置 / 换号 / 全员重置」结论前，按[账号 SOP 的机械归因判据](references/account-usage.md#窗口变化与重置归因机械判据)运行 `scripts/reset_attribution.py`；`claim_gate` 为 `block` 的断言不得交付。归因是 `unknown` 不妨碍报告当前余量、Next reset 和 banked 现值。 - 证据、竞争解释和待核字段放在结论之后。拿不到某账户的 `Next reset` 或 banked 状态时， 仍先对已知事实下结论，再说明哪一层属性不能确认；禁止以「你检查后自行判断」收尾。 - **账户现值不替事件归因**：当前剩余、`Next reset` 和 banked 库存只证明查询时的状态。 原因未定的账户读数不能作为官宣重置已在该账户到账的旁证；自然周期与额外重置可能先后发生， 按[账号 SOP](references/account-usage.md#相邻两次重置的归因)分别核对，不用前一次解释或否定后一次。 - 用户追问未兑现的承诺、到账延迟或事件时间线时，结论之后按时间顺序列出会改变判断的节点： 故障与恢复（若相关）、官方原帖的承诺时刻与措辞、承诺后的账户读数、后续完成或解释信号。 每个节点标明时区、原始来源和它实际证明的范围；缺失的节点保留未知，不拿公告时刻充当到账时刻。 - 后续核验动作只用于证实/证伪这个结论，不得把它写成让用户代替 agent 做判断的选择题。 - **未来时间问题要给预测判断。** 有明确预告时先报换算后的官宣窗口；没有时继续分析近期同类 事件与当前信号，按[预测路径](references/next-reset-forecast.md)给出有依据的主窗口、信心和 改判条件。「未官宣 / 没有固定排期 / There is no schedule」只说明公告状态，不能独自结束 回答。资料不足以支持日期时，给出等待是否值得的判断及缺口，不编日期或精确概率。 ## 监测轮：从信息到可行动信号 适用于裸调用、预测询问和宿主重复调用本 Skill 的正常轮；明确只问账户余额、只问已知帖原文 或历史漏报归因时，按入口分流缩小范围。降频轮保留上述取舍，但不能丢掉未决线索；未决线索 到达复查条件时升级为正常轮。每轮按以下顺序执行，停止于证据已足够改变或维持当前行动、 且下一次需要什么新信息已经写清，而不是停止于固定端点返回空值。 1. **接上上轮的问题。** 读 `forecast_log.py summary`，先看 `due_for_followup`（窗口已过期或 即将关闭、尚无定论的预测——到期跟进项从这里第一眼读，不用翻 rationale；closing_soon 的 阈值定义见 forecast-feedback.md）；若有 `withdrawal_conflicts`，先核对冲突的撤回与旧版核验； 若有 `recent_withdrawn`，先排除已撤回的旧窗口；也看 `snapshot.status`——`lagging` 表示台账 的 git 快照落后（原因与处置见 forecast-feedback.md 的 findings 节），要在本轮汇报里说明； 再从同一 state-dir 运行 `forecast_log.py handoff` 读取最新一条 `invocation=monitor` 的完整原始行；`findings` 子命令的紧凑列表不显示 `notes`，不能用它代替交接正文。`handoff` 返回 `null` 表示尚无监测交接，不能推断此前 没有值得追的线索。 其中的 `notes` 记录上轮尚未解决的具体问题、候选来源、下一次复查条件和用户反馈。上轮 没有记录就从当前问题与现有预测的 `revision_trigger` 建立这些项，不把空台账说成已覆盖。 本轮即使只做降频查询，也要在新 finding 的 `notes` 里结转未决项或写明已由哪条证据关闭， 使它始终能从最新轮次读回；逐字读数仍只放 `readings`，判断不得伪装成原始数据。 同一 state-dir 再运行 `forecast_log.py followup`，执行其 `event_tasks` 与 `account_tasks`，不要把输出清单当成已经查过。`confirmed_unscored` 表示事件已经确认、 预测仍不可评分，不为它继续问「重置发生了吗」；`account_followup` 单独保留已绑定账号的 未到账项。官宣的具体时刻用 `announce` 保存，字段与状态读 [本地预测反馈](references/forecast-feedback.md#官宣单点时间与事件账号状态)。 2. **先取增量，再问它改变什么。** 以 §1 的 Radar、Tibo 主帖、reply、故障与社区监测为 基线，比较上次已读的 ID/时间和本次实际覆盖；新发现的旧帖也按**首次发现时间**进入本轮 判读，不能因为发帖时间早于本轮起点就丢弃。阅读完整正文及承重的 parent / quote / 图片 文字；同一原帖的镜像和群截图只算一份事实，但群截图作为新的发现路径应保留。先判断 「这条信息若为真，会改变哪一个关于时间、范围、类型、到账或使用策略的判断」，再决定 是否追下一跳；不能以 `reset` 等固定关键词或 tracker 标签作语义闸门。 3. **沿问题扩来源，而非无限抓取。** 已知来源空白、未来承诺尚无独立兑现证据、用户追问原因、 上下文指向别处，或候选会改变行动时，先标明公告、服务恢复、账户到账、影响范围与执行原因 哪些已有证据，再列能改变判断的竞争解释。承诺没有截止时间时，本账户暂未变化是待证状态， 不是承诺与产品相矛盾；也不能据此断言后端尚未执行或已在其他账户到账。 从帖子引用、回复对象、官方事故、独立账户观测和用户已授权的社区记录中选最有辨别力的 下一跳。用户已指出「VIP 1群｜一支烟花社区」是本案有效的补充发现源；正常轮若尚无该群 的新鲜覆盖，就用现有 `read-wechat-messages` 读取其增量，包含纯图片与语音，随后回原帖 核验。相关群会随用户反馈和实际信号增减，不把这个群写成永远完整的来源清单。群消息是 发现与交叉核对渠道，转发次数不是独立证据。每跳写明它要区分的竞争解释；查不到时 保留 unknown 与下一次可执行的复查条件。证据已足以回答用户问的状态或原因， 或追加来源不会改变有界结论时停止扩展；平台内部原因无可读证据时明确保留 unknown。 `followup.event_tasks` 标为 `overdue` 时，补查清单里的新鲜账号读数、官方主帖、候选回复链、 有界回复发现和已授权社区增量，分别核对「官方是否改期或完成」「同一账号是否变化」 「其他独立账号是否已有到账」。只看原预告和同一批回复不能完成这轮复查；通道仍不可用时 保存本轮失败与下次可执行条件，不把旧的 `unknown` 当作本轮已经尝试。具体现有获取路径 仍按 §1 与社区读取 Skill 执行，不为一次失败判通道永久不可用。`account_tasks` 则只追对应 账号到账，不重开已确认的全局事件；未获授权的社区来源保留 uncovered。 4. **分层输出并保留行动差异。** 已核实的事件、未来承诺和行动提示可构成信号；含糊回复、 里程碑或第三方解读先列候选，若会改变当前安排仍及时提示其歧义与补证条件，不升格为 明文承诺。明确区分 `global`、`banked`、`both`、个人周期和类型未明：`global` 到来前可 评估把原本值得做的工作提前；`banked` 先关注到账、到期与手动兑现，不因它将发放就建议 提前耗尽现有额度；`both` 分开跟进两类容量；类型未明时可记录账户基线、准备既有任务， 只在本账户读数与机会成本支持时作可撤销的条件性安排。未发现新信号时只说 「本轮已覆盖范围内无新增可行动信息」，连同 uncovered / unknown 与下一复查条件报告， 不说全域无信号。若本轮有新判断，用原帖、上下文和产品观测说明它比上轮多了什么， 以及是否要通知、等待或改变用量策略；不能把发送回执当用户 ACK。 **反向同样成立：官方已明文预告 global 在途时，先等落地再动备用**——global 落地即全员回满， 此刻兑现备用等于白扔库存（2026-10-11 实测：4 账号全空 + EOD 官宣在途，官宣后 5h45m 落地、 距 EOD 上限仍提前 ~3h，2 次备用保住未花）。 5. **把下一轮要接的状态落下。** 在本轮最后追加一条 `invocation=monitor` 的交接 finding； `query` 写当前监测问题，`endpoints=[]`、`readings={}`，`notes` 写本轮 UTC 检查时刻、新线索、已排除解释、 未决问题、候选来源、各来源覆盖、下次触发条件及用户纠偏。重要判断另按预测路径保存或 修订预测，并以 `evidence_refs` 链接原始读数。没有新信息也更新下一轮应检查的条件；不得以「连续数日 没信号」自行拉长宿主调用间隔。Skill 只能规定被调用时的行为，不能凭一次执行证明未来 定时唤起、消息送达或 ACK 已生效。 完成确认后追加 `review`，分开记录事件确认与账号读数。只有完成帖时仍用 `time_basis=confirmation_only`，不得为清空待查队列伪造发生时刻或命中评分；脚本会把已确认 但不可评分的记录移到 `confirmed_unscored`。官宣时刻是 `announce` 的单点记录，不加一秒 尾巴凑成预测窗口，也不凭经验添加执行宽限。 **烧额度任务的授权边界。** 接受「烧额度」类授权（让某会话持续跑、直到额度耗尽或跑到某 时刻）时，授权合同当场逐项写明下列内容，缺任一项 = 授权不可执行，当场指出、不带病开跑： 1. **绝对停止时刻**：相对时长（「再烧两小时」）与事件锚点（「烧到官宣落地」）都当场 换算成绝对时刻，并复述回写给用户确认； 2. **停止执行人**：到点由谁让它停——runner 自停、已验证的停止执行器、还是用户手动； 3. **停止方式**：自带超时自停、对话内要求停止，还是合同逐条点名授权的 kill。 默认形态是**自带停止**：runner 到点自停，监测轮只兜底复核它是否真的停了，不承担计时 职责；定期监测不能充当到点停止器。未配置可执行停止方式时不要开跑。 **可选本地执行器**：宿主已安装 `burn-stopper` 时，先读取其维护者提供的 README； 本机既有入口为 `~/scripts/burn-stopper/README.md`。这是环境可选工具，不随本公共 Skill 分发， 不把该路径存在或本机私有脚本当作其他宿主的前提。未安装、依赖缺失或宿主不支持时， 如实报告 helper 不可用；已有合法的 runner timeout 自停方式仍可用，不借此自动安装或扩大终止权限。 按 README 的实际接口执行：核对本次点名目标、实例/会话归属、停止授权及带时区的绝对 deadline， 并与当前时刻比较；已过期不新建调度，进入下述到期处置。仅授权 runner 自停时继续用其 timeout， 不把自停授权解释为 helper 发送 SIGTERM 的授权。已明确授权 helper 的停止方式时，使用 README 的 `arm` 命令， 按其示例提供 `--at`、`--targets`、`--label` 与 `--note`；授权来源记入 note，note 本身不授予权限。 武装后用同一 label 的 `status` 读回 deadline、generation、目标与 `scheduler.plist_exists`、`scheduler.launchd_loaded`，不能只凭 `arm` 回执宣称已受保护。 工具对会话与共享进程的归属检查、SIGTERM 范围和取消方法以其 README 及现有 kill-guard SOP 为准， 不在这里复制另一套进程操作流程。 到点读执行报告：`fired` 仍按逐目标退出证据核对；`fired-partial` 逐条报告跳过/幸存者， `stale-skipped` 表示迟到未执行，`armed` 只表示任务记录。CLI 退出 0 不等于全部停下； 需要保留或改作他用的会话先按 README disarm 并读回，再继续使用。 处置阶梯：发现停止时刻已过而消耗仍在继续 → 永远可以立即报告用户并要求燃烧会话 自停；**kill 仅限当次合同逐条点名的会话/PID 范围**，不写成可复用的通用权力，操作序列按 `~/.claude/references/irreversible-gates.md`「终止进程」节执行。相对时刻换算与「已过期不建 调度」的对表规则见全局 CLAUDE.md「中断恢复后先对表」，本节不复述。 ## 查证工作流 ### 1. 公告路径：Radar、Tibo 主帖与 reply 读取 tracker 和社区反馈前，加载[时间、来源与覆盖读数](references/signal-readings.md)。 用其中的 `signal_readings.py` 从已保存响应整理时刻与来源定位，再读完整候选正文； 辅助元数据不替代正文、产品观测或 claim gate。 **正常轮次必须实际尝试 Radar、Tibo 主帖时间线与下文的有界 reply 发现。** Radar 可能 完全没有索引一条新的独立主帖；主帖时间线也不含 replies，所以前两条都无新仍不能跳过 reply 发现。宿主没有可用的已登录 X 通道时，reply 腿的执行结果是 `unknown`，不是静默省略。按时段 降频的已批准例外仍按入口分流执行：降频轮只查 Radar 时，把 `main_posts` 与 `replies` 都记为 `uncovered`，不能把结果写成全量无新。 本机已登录且 `twitter-cli` 可用时，主帖入口使用下面的只读命令（v0.8.5，2026-09-23 实测； 帮助与 JSON 输出均核对过）： ```bash twitter user-posts thsottiaux -n 50 --json 2>/dev/null ``` CLI 的 WARNING（如 `Failed to init ClientTransaction`）走 stderr、不影响 JSON；用 `2>&1` 合流会让 JSON 解析在首字符失败（2026-09-30 实测），所以丢弃 stderr。 把返回项按 `createdAtISO` / `id` 与上次 finding 的主帖游标比较；新主帖逐条读完整 `text`，并保留 `quotedTweet` 关系。若两轮间发帖量超过当前窗口、最旧返回项仍晚于上次游标，扩大 `-n`（最多 200）补齐，不把截断窗口记成 covered。`user-posts` 只列主帖，不能认证 replies。没有该 CLI 的 宿主使用已有可用的 Web/X 原站通道；这些通道也不可用时写 `main_posts=unknown`，不能伪造完全覆盖。 Radar 继续作为结构化索引腿。用 Tibo Radar JSON API 找最新公开公告（2026-08-26 实测 200）： ```bash curl -s -m 15 "https://codex-reset.com/api/timeline" | python3 -c " import json,sys for e in json.load(sys.stdin)['events'][:5]: print(e['announced_at'], '|', e.get('type'), '|', str(e.get('summary'))[:100]) ow = e.get('official_window') if ow: print(' 窗口:', ow.get('label'), '=', ow.get('start_at'), '→', ow.get('end_at'), 'UTC') print(' url:', e.get('url'))" ``` 新条目在前。关键字段：`announced_at`（UTC ISO）、`summary`（可能截断）、`url`（原帖）、 `official_window`、`reset_verification_status`。`type` 是内部小写值：`reset` = 广域 重置公告、`credits` = banked/额度包、`boost`/`promo` = 消耗规则类。 **Radar 成功取得新索引项后，必须先读该项原帖全文，再判它是否包含未来承诺或会改变安排的 时间、类型、范围。** 摘要、`type`、`official_window` 与核验标签只用于定位和交叉检查；任何一个 为空都不能短路全文读取。全文判读结果与未决字段写入 finding / forecast；只有全文也无承诺、 台账也没有到期未决承诺时，才能把这一轮记为「已覆盖范围内无新决策信号」。 **摘要截断也会藏住预告**：2026-09-08 实测最新条目的 `summary` 只截到开头玩笑， `official_window=null`、`announcement_state=none`、核验标签为 pending； [原帖全文](https://x.com/thsottiaux/status/2097043464538264003) 却明确预告所有付费订阅的全局重置， 时间为发帖当日太平洋 18:00 左右。先读全文再判断，不能按索引字段宣布“无新预告”。 当次发帖北京 09-08 03:24、太平洋 09-07 12:24，故预告换算为北京 09-08 09:00； 这是当次预告的换算案例，不是固定排期，也不是已到账证据。 ⚠️ **`type` 是 Radar 编辑者打的标签，不是事件性质的机器判定——跨平台互动也会被打上 `reset`。** 2026-09-05 实测：Tibo 回复 Anthropic 的 Lydia Hallie（原帖：「We've just reset weekly limits for everyone on a Claude Max plan」，Claude 官方学重置传统），只回了句 「Wow, huge, wonder why!」的调侃，Radar 照样给它 `type=reset`。读原帖是唯一消歧手段； fxtwitter 响应里的 `replying_to`（被回复人）+ `replying_to_status`（被回复帖 id）就是为 这一步准备的字段。 `url` 已在上面命令的输出里（2026-08-31 起直接打印，免去二次查询），拿到后优先读原帖。twitter-cli 不可用（未登录/未装）时，X 帖正文的制胜通道才是 **fxtwitter 公开镜像 API**（2026-08-30 实测： 免登录、直连即可、返回完整 JSON；**完整正文在 `tweet.text` 字段——不是 `full_text`**，该键 不存在、照抄会 KeyError；note_tweet 长文全文也给，8-29 官宣长文实测 2324 字符完整拿到、以 自然结尾收束；2026-09-24 实测它可整段不可用（12 连败），而已登录 twitter-cli 的 `user-posts --json` 本身就带完整正文——通道排位按能力排，别按文档惯性先打 fxtwitter）： ```bash curl -sS --max-time 20 "https://api.fxtwitter.com/<user>/status/<status-id>" \ | python3 -c "import json,sys; t=json.load(sys.stdin)['tweet']; q=t.get('quote'); print(t['created_at']); print('reply_to:', t.get('replying_to'), t.get('replying_to_status') or ''); print('quote:', json.dumps(None if not q else {'id':q.get('id'),'url':q.get('url'),'text':q.get('text')}, ensure_ascii=False)); print(t['text'])" ``` 备胎与死路（同日实测）： - `cdn.syndication.twimg.com/tweet-result?id=<id>&lang=en&token=a`（官方端点，200）：**正文截断 276 字符**、note_tweet 只给 id 不给内容——只能核对开头与元数据，长文拿不到。 - `publish.twitter.com/oembed`：301 落到 `publish.x.com` 后（加 `-L`）返回 200+JSON，但可见 文本同样截断（~273 字符、以省略号收尾，截断点与 syndication 相同）——**与 syndication 同一档**，够核对开头与元数据，拿不到 note_tweet 全文。 - ~~Jina Reader~~ **可用但间歇，不作主通道依赖**：匿名访问 x.com 会因他人滥用被**间歇性全局 封禁**（403，2026-08-30 实测：封禁数小时后解除，解除后匿名仍能拿到帖子正文；错误信息点名 触发滥用的第三方账号）；本仓 jina key 已 402 余额尽。fxtwitter 优先，Jina 只作它的备用。 - fxtwitter 不返回回复**内容**（`replies` 字段只是数值计数）。它返回的 `replying_to` （被回复人 handle）与 `replying_to_status`（被回复帖 id）足够判断一条已知帖子是否为回复， 被回复帖本身再用同一条命令取一次；但它**不能枚举主帖下有哪些回复**。主帖零命中、主帖时间线 无新项，或某个 CLI search 返回 404，都不能写成「没有回复」。 - 已知候选帖（官宣帖、落地帖）的回复链核验有更便宜的路：`twitter tweet <id> --json` 一次返回 主帖＋replies（作者字段是 `data[].author.screenName`——不是 `userName`，2026-09-24 实测 50 items，据此确认承诺帖下 Tibo 本人零回复）。它只给「这一条帖下的回复」；「他最近回过谁」 的发现性扫描仍走下面的网页滚动法。`twitter search`（含 `from:` 查询）实测 HTTP 404，搜索路线不可用。 - **有界 reply 发现路径**（2026-09-23 已登录 X 原站实测能看到一条主帖入口遗漏的旧回复）： 1. 先固定起点：上次**可靠** reply 检查的 UTC；没有就用本任务窗口或当前未决承诺的起点。 打开 `https://x.com/thsottiaux/with_replies`，记录本轮 URL、起点与开始时间。 2. 只记录页面实际显示、作者为 Tibo 的条目：逐条保存 status ID 和 UTC，连续向旧滚动，直到 页面已越过起点，或出现明确的加载停止 / 资源上限 / 网站失败。网页滚过时间边界只表示观察 到该处，**不证明区间穷尽**；不得据此写 covered。 3. 发现会改变安排的承诺、时间、类型或范围线索后即可停止继续翻旧内容，把它形成候选并补证。 对每个重要候选，用上面的 fxtwitter 单帖命令读取正文、`replying_to_status` 及 `quote` 的 id / URL / 正文。存在 parent 时再用同一命令读取 parent；存在 quote 且其内容承重时，再按 quote URL 读取原帖。`quote: null` 是健康的无引用形态，不是未核；只有实际存在的承重节点 取不到时，相应判断才保持 unknown。 4. finding 记录 `window_start/window_end`、观察到的 status IDs、最旧可见 UTC 与停止原因： `boundary_observed` / `loading_stopped` / `resource_stop` / `site_failed` / `not_logged_in`。 没有登录态或网站失败即 `unknown`；到边界但只有网页滚动证据即 `partial`，阴性结果只能写 「本轮观察到的回复中无相关线索」。 - 每轮按对象写回复覆盖：`covered(candidate_chain:<id>)` 只用于一个已知候选的正文及其实际存在的 parent / quote 承重节点已完整核验，或某个接口提供了真实穷尽信号且记录了明确范围； `partial(<window>)` 用于有界网页 观察；`uncovered` 表示本轮只有结构上不含 replies 的主帖/镜像入口；`unknown` 表示 reply 通道 失败或不可用。后三种都不能宣布该时段没有回复或全局无新信号。主帖入口始终只算 main-post coverage，不因它返回零条或返回完整正文而升级 reply coverage。 - **落地确认帖的回复链要读；tracker 的条目数不等于事件数**（2026-09-10 实测）：09-08 「All reset for everyone」官宣帖下，Tibo 回复「You forgot the part where I reset usage twice in the middle」——正式落地之前当天已中途全局重置两次，这个口径只存在于回复里。 codexrunway 把这条回复标成了**第二条独立的** Completed Global reset（Confidence 93%）。 预告＋中途加码＋落地是一轮事件（归并规则见 next-reset-forecast），读回复用同一条 fxtwitter 命令；回复帖 id 从 tracker 页面里的 x.com 状态链接提取（2026-09-10 即从 codexrunway 静态 HTML 中 grep 得到），fxtwitter 自身没有 replies 列表。 `codexlimitwatch.com/codex-reset-history` 与 Radar 都以 Tibo 动态为核心上游，属于**同一来源 家族**，只能互查转录/解析是否一致，不能称为独立双源。**LunarWerx Codex Forecast** （`codex.lunarwerx.com`）介于两者之间：它的**核验腿**独立（站点自述且 meta description 实测 「checked against OpenAI's own status page」），但**数据上游**仍是公开重置记录（含 Tibo 动态、 社区描述其模型由 Tibo hints 驱动）——所以它适合作「第三方对 Tibo 信号的**解读**交叉验证」 （2026-08-30：对 celebration 帖它独立给出同样的「明天重置」读法，标注 95% confident）， **不能当「独立观测到重置事件」的第二源**，否则就犯了本 skill 警告的同源错误。它是 SPA， 静态抓取只能拿到 meta 与壳，正文内容经 WebSearch 引用。HTML `codex-reset.com/tibo` 是 SPA，静态内容可能滞后；只作人类视图。 **第三方预测腿**：`www.codexrunway.com/api/status.json` 于 2026-09-26 跳转到 `didcodexreset.com/api/status.json`；每次取回后核对最终 URL、`generatedAt`、 `lastSuccessfulCheckAt`、`monitor.status` 与当前字段，不假定旧域名或旧字段永久有效。 当前响应以 `events[]` 的 `kind` 区分 `reset_scheduled` 与 `reset_completed`，没有旧说明中的