feat(autofix): back off scan inspection of idle candidates - #8049
Conversation
The scheduled scan inspects every candidate every tick. The takeover pool doubled in two days (28 open takeover PRs, 8 of them idle in 'nothing new' state for 10+ hours), and idle candidates crowd the two SHARED budgets: MAX_CANDIDATE_INSPECTIONS (60) and the 10-target cap. Observed on #8002: freshly engaged, admitted by the 09:03 scan, then deferred by the target budget while long-idle PRs re-confirmed their idleness yet again. Candidates whose list-provided updatedAt (no extra API call) is older than 24h are now inspected on roughly every 4th scan, on a deterministic slot keyed by PR number and UTC hour so no PR waits forever. The skip is free — it sits with the busy skip before the inspection-budget increment. Safe by construction: every real wake-up bumps updatedAt (reviews, comments, labels, pushes) or routes in real time anyway, so the only thing deferred is the scheduled re-confirmation of idleness plus worst-case a few hours of base-conflict-detection latency for a PR nobody touched in a day. The forced-dispatch path never builds the list files, so a forced PR is always inspected.
|
Thanks for the PR! Template: the headings differ from the template ( Problem: observed and well-evidenced. The PR cites a concrete incident on #8002 (engaged 08:00, not reached until 09:09 — six minutes of serial Direction: aligned — internal autofix infrastructure, reducing wasted scan cycles on idle candidates directly improves pipeline responsiveness to fresh work. No auth/sandbox/model/telemetry/public-contract surface touched. Size: not applicable (no core paths — Approach: tight scope, every edit serves the stated goal. Adding Risk: no elevated risk signals. Moving on to code review. 🔍 中文说明感谢贡献！ 模板：标题与模板不同（ 问题：已观测且有充分证据。PR 引用了 #8002 的具体事件（08:00 接管、09:09 才到达——6 分钟串行 方向：对齐——内部 autofix 基础设施，减少空闲候选的无效扫描直接提升流水线对新工作的响应速度。未触及认证/沙箱/模型/遥测/公共契约。 规模：不适用（无核心路径——仅 方案：范围紧凑，每处改动都服务于目标。在现有列表查询中加入 风险：无升级风险信号。 进入代码审查 🔍 — Qwen Code · qwen3.8-max-preview Reviewed at |
Code ReviewIndependent proposal: I would add Comparison: the PR matches this exactly. The implementation is 48 lines of workflow bash that slots cleanly into the existing scan loop — after the busy skip, before the budget increment, with the same fleet-row visibility pattern. No new abstractions, no new API calls, no new state beyond the precomputed set. Findings: no critical blockers, no convention violations. The follow-up commits (5 since the initial review) are all refinements: pinning the null- The behavioral replay tests are the standout: they extract the real TestingCI on
The ubuntu suite (which runs the workflow pin tests including the idle-backoff behavioral replay) passed. macOS/Windows/integration are skipped for this PR (workflow + test-only change, no platform-specific code). Not verified: real scan behavior under production load (would require observing multiple scan cycles with idle candidates present). The probabilistic gap claims (median ~2h, p90 ~6h) are from the author's measurement of 100 real scans — plausible given the ~40-70 min scan cadence, but not independently re-run here. 中文说明代码审查独立方案： 在现有 对比： PR 完全匹配此方案。实现为 48 行工作流 bash，干净嵌入现有扫描循环——在 busy 跳过之后、预算自增之前，使用相同的面板行可见性模式。无新抽象、无新 API 调用、除预计算集合外无新状态。 发现：无关键阻塞项，无规范违反。 5 个后续提交均为改进：pin null- 行为回放测试是亮点：从工作流源码中提取真实 测试CI 在 未验证：生产负载下的真实扫描行为（需观察多个含空闲候选的扫描周期）。概率性间隔声明（中位数 ~2h，p90 ~6h）来自作者对 100 次真实扫描的测量——给定 ~40-70 分钟扫描周期属合理，但未在此独立重跑。 — Qwen Code · qwen3.8-max-preview Reviewed at |
|
Confidence: 5/5 — clean across every stage; the problem is real, the fix is minimal, and the follow-up commits made it better. Stepping back: this does one thing well. The idle-backoff logic is 48 lines of production bash that slots into the existing scan loop with the same idiom as the busy skip — precomputed set, substring test, fleet-row visibility, fail-open defaults. The deterministic slot arithmetic is about as simple as fair periodic re-checking can be. My independent proposal matched the PR's approach exactly — I couldn't find a simpler path. The The five follow-up commits since the initial review are all quality improvements: the gap is now stated honestly as probabilistic (median ~2h, p90 ~6h) rather than claiming a bounded ≤30m that only holds under the idealized cron cadence; the quantum is unpinned so CI won't block future tuning; and the behavioral replay now covers the null- CI is green on the reviewed commit. Approval already stands from the finalize workflow. 中文说明置信度：5/5——每个阶段都干净；问题真实，修复最小化，后续提交使其更好。 退一步看：这是一个只做一件事且做得好的改动。idle-backoff 逻辑为 48 行生产 bash，以与 busy 跳过相同的写法嵌入现有扫描循环——预计算集合、子串测试、面板行可见性、fail-open 默认值。确定性排片算术是公平周期性重检的最简方案。 我的独立方案与 PR 完全一致——找不到更简路径。 初次审查以来的 5 个后续提交均为质量改进：间隔现在诚实地表述为概率性（中位数 ~2h，p90 ~6h）而非声称仅在理想化 cron 周期下成立的有界 ≤30m；量子解除 pin 以免 CI 阻止未来调参；行为回放现在覆盖 null- CI 在审查提交上全绿。审批已由 finalize 工作流生效。 — Qwen Code · qwen3.8-max-preview Reviewed at |
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
No issues found. LGTM! ✅
— qwen3.8-max-preview via Qwen Code /review
Review: back off scan inspection of idle candidatesVerdict: the mechanism is sound and low-risk — merge after fixing the two claims baked into the workflow comment, which the code contradicts. Reviewed at What's right
1. The 10-target-cap justification is wrong — idle candidates never reach that budgetThe comment states:
A candidate that re-confirms "nothing new" hits
Also worth re-reading the quoted evidence: The real cost idle candidates impose — and the real (worthwhile) win here — is the other two: the shared 60-inspection budget, and the serial wall-clock/API walk of the candidate list. That walk is exactly the 09:03 → 09:09 gap in your own evidence: six minutes of serial This matters beyond wording: the comment is permanent documentation, and the next person chasing target-cap starvation will read it and tune the wrong knob. Please restate it as inspection-budget + scan-walk latency. 2. Hourly slot ×
|
|
@qwen-code /takeover |
qwen-code-dev-bot
added
the
autofix/takeover
|
🤝 Takeover engaged: the autofix loop now manages this PR — it will address new review feedback and resolve base conflicts until the label is removed or the round cap is reached. Remove the 中文说明🤝 已接管：autofix 循环现在管理此 PR —— 将持续处理新的评审反馈与 base 冲突，直到移除标签或达到轮次上限。移除 |
- Corrected the comment's cost model: idle candidates hit 'continue' before the TARGETS append, so they never contend for the 10-target cap — the real win is the shared inspection budget plus the serial scan-walk latency (the walk is what delayed #8002's pickup by ~6 minutes), and the comment now says exactly that. - Slot quantum changed from the hour to the scan tick (600s, the same quantum as ROT_OFF): an hourly slot against the */10 cron meant 6 back-to-back inspections then a ~3h blind window per PR — same 25% average, terrible shape. The gap is now bounded at ~30 minutes, which is what the operator-facing strings promise ('gap ≤30m'). - The two scan-only signals updatedAt cannot see (a base conflict appearing when main moves; still-red checks awaiting the redcheck marker) are named in the comment instead of papered over. - The per-candidate jq fork became a single precomputed set + a bash substring test, matching the busy skip's idiom and the 'free' claim. - Tests: the skip predicate and set builder got a behavioral replay (idle+out-of-slot defers, idle+in-slot inspects, fresh inspects, missing-from-lookup inspects); the two byte-distance assertions became a loop-head slice (comment growth cannot red-light CI, and budget-consuming code between the skips and the increment fails); the --json field pin is order-independent; the 3600 quantum is pinned OUT.
|
All six addressed in 29a96e3:
— Claude Code (claude-fable-5) |
|
🤖 Reviewed the latest feedback — no changes needed. Why, point by point: · 已审阅最新反馈——无需改动。逐点说明原因如下： No action needed this roundAll six findings from @wenshao's review were addressed in the previous round (commit
No new maintainer feedback has been posted since that commit. The cancelled CI checks (label, review-config, authorize, ack-review-request, delay-automatic-review, resolve-pr, review-pr) are all 中文说明本轮无需操作@wenshao 评审中的全部六项发现已在上一轮（提交
该提交之后没有新的维护者反馈。已取消的 CI 检查（label、review-config、authorize、ack-review-request、delay-automatic-review、resolve-pr、review-pr）状态均为 Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed. Suggestions are inline. Not linted (tool limitation, not a blocker): the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
已审查。 建议见行内评论。 未检查（工具限制，非阻断）：the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— qwen3.8-max-preview via Qwen Code /review
|
🤖 Addressed the latest review feedback (round 1/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 1/100 轮）。改动内容与我反驳保留之处如下： Review feedback — round summary[rc:3675379804] Null/empty
|
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed — no blockers. Suggestions are inline. Not linted (tool limitation, not a blocker): the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
已审查——无阻断问题。 建议见行内评论。 未检查（工具限制，非阻断）：the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— qwen3.8-max-preview via Qwen Code /review
|
🤖 Addressed the latest review feedback (round 2/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 2/100 轮）。改动内容与我反驳保留之处如下： Review feedback — round summaryrc:3676308509 — [Suggestion] Extract the skip predicate from the workflow instead of hand-writing it in the replayDecision: Implemented. The Changes: rc:3676308519 — [Suggestion] Fix "gap ≤30m" → "gap ≤40m" (4 ticks × 10 min = 40 min)Decision: Implemented. With the Changes: Conflict notesNo conflicts ( Verification
中文说明审查反馈——本轮摘要rc:3676308509 — [建议] 从 workflow 中提取跳过谓词，而非在回放中手写决定： 已实现。
变更： rc:3676308519 — [建议] 修正 "gap ≤30m" → "gap ≤40m"（4 个 tick × 10 分钟 = 40 分钟）决定： 已实现。 在 变更： 冲突说明无冲突（ 验证
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
doudouOUC
left a comment
doudouOUC
left a comment
There was a problem hiding this comment.
.github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
.github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— qwen3.7-max via Qwen Code /review
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed — no blockers. Suggestions are inline. Not linted (tool limitation, not a blocker): the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
已审查——无阻断问题。 建议见行内评论。 未检查（工具限制，非阻断）：the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— qwen3.8-max-preview via Qwen Code /review
|
🤖 Addressed the latest review feedback (round 3/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 3/100 轮）。改动内容与我反驳保留之处如下： Round summaryOne suggestion addressed; no conflicts. Feedback points
Changes
No workflow changes; test-only commit. 中文说明轮次总结处理了一条建议；无冲突。 反馈要点
变更内容
无工作流变更；仅测试提交。 Verification
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
No issues found. LGTM! ✅
Not linted (tool limitation, not a blocker): the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted.
中文说明
未发现问题。LGTM！✅
未检查（工具限制，非阻断）：the executable-script lint — .github/workflows/qwen-autofix.yml: actionlint embedded-shell source mapping is not yet supported — not linted。
— qwen3.8-max-preview via Qwen Code /review
Verification round 2 — local build + production measurementVerdict: the runtime behaviour is safe and the tests are excellent (103/103, 10/10 mutants killed). But every quantitative claim in this PR rests on a 10-minute scan tick that production does not have — including the Verified at What holds up
1 · The 600 s scan tick does not exist — the bound is off by 3–19×I pulled the real start time of the
0 of 99 inter-scan gaps were ≤ 10.5 min. Median 37.5, min 21.3, max 83.6. This is not news to the repo — the same workflow already says so at line 332: Because scans arrive 21–84 min apart,
Real gaps: median 120 m, p90 367 m, max 754 m (12.6 h); 21 % exceed 4 h. This is where round 1 went wrong, and I want to be direct about it. Round 1's finding 2 replayed "144 consecutive ticks (24h)" — a synthetic, evenly-spaced
Across the whole sweep the tightest median is 91 min (2.3× the promised bound) and the tightest maximum is 346 min (5.8 h, 8.7×). A time-quantised slot cannot bound the gap against an irregular cadence — the aggregate 25 % is robust, the bound is not achievable at any constant. One concrete consequence: the two scan-only signals the comment correctly names — base conflict when main moves, and still-red checks awaiting the redcheck marker — go from a median 37 min blind window to median 2 h, p90 6 h. 2 · Neither claimed saving is a binding constraint
The run was created at 09:03:19; the The genuine win is real but small: ~2–3 fewer 3 · Three different numbers are shipping, and the tests lock the wrong one in
All four are wrong against the measured distribution, and they disagree with each other for the same event. The test suite is genuinely rigorous — I applied 10 mutants (asserting each anchor landed first, so a no-op edit can't masquerade as a survivor) and re-ran the full 103-test file each time:
10/10 killed — including the flipped comparison, the inverted predicate, the broken fail-open, and the RecommendationShip the mechanism; fix the claims. Minimal, no code change:
Reproduction: 中文说明第 2 轮验证 —— 本地构建 + 生产数据实测结论：运行时行为安全，测试质量很高（103/103 通过，10/10 变异体被杀）。但本 PR 所有量化结论都建立在一个「10 分钟扫描节拍」之上，而生产环境并不存在这个节拍 —— 包括第 1 轮建议采用的 在隔离 worktree 中于 站得住的部分
1 · 600 s 扫描节拍不存在 —— 上界偏差 3–19 倍我取了最近 100 次定时运行中 由于扫描间隔为 21–84 分钟，
真实间隔：中位数 120 分钟，p90 367 分钟，最大 754 分钟（12.6 小时）；21% 超过 4 小时。 这正是第 1 轮出错之处，我想直说。 第 1 轮发现 2 回放的是「144 个连续 tick（24h）」—— 一个人工构造的等间距 从 10 到 80 分钟的任何量子都达不到 40 分钟量级。在不规则节拍下，时间量化槽位无法给出上界 —— 25% 的总量是稳健的，上界在任何常数下都不可达。 一个具体后果：注释中正确点明的两个「仅扫描可见」信号（main 前进导致的 base 冲突、等待 redcheck 标记的持续红检查）的盲窗从中位 37 分钟变为中位 2 小时、p90 6 小时。 2 · 两项声称的收益都不是紧约束
真实收益存在但很小：每次扫描少约 2–3 次 3 · 三个不同数字同时发布，而测试把错的那个锁死了
测试确实严谨 —— 我施加 10 个变异体（先断言每个锚点确实命中，避免空改动伪装成存活者），每次重跑完整 103 条测试：10/10 全部被杀，含翻转比较、反转谓词、破坏 fail-open、 建议机制可以合并，把声明改对即可，无需改代码：
复现方式： |
…#8049) Round-2 verification showed the scheduled scan lands every ~40-70 min on this repo, not every 10 min, so the (epoch/600)%4 slot is an independent ~25% draw per scan, not a deterministic 1-in-4 rotation. The gap is geometric (measured median ~2h, p90 ~6h), not bounded at ~40m. Reword the operator-facing strings (skip echo, fleet row) and the workflow comment to state the behaviour probabilistically and drop the false "bounded" / "no PR is unlucky forever" claims; correct the misattributed #8002 latency (queue/startup, not the serial walk). Relax the tests so a truthful number is not a CI failure: pin the mod-4 time-quantum shape instead of the exact 600s constant, and drop the /3600 exclusion that forbade the better-tailed quantum. Mechanism logic is unchanged.
|
🤖 Addressed the latest review feedback (round 4/100). What changed, and what I pushed back on: · 已处理最新评审反馈（第 4/100 轮）。改动内容与我反驳保留之处如下： Autofix review round — PR #8049Addressed @wenshao's round-2 verification feedback ("ship the mechanism; fix the claims"). The mechanism logic is byte-identical; only the quantitative claims — and the tests that locked them in — were corrected. Committed as Feedback points1 · State the behaviour probabilistically in all four surfaces; drop "bounded"/"no PR is unlucky forever" — DONE for the 3 code surfaces; PR body not editable from this mode.
2 · Update the PR body — NOT DONE (no credentials in this mode); see point 1. 3 · Relax the
Finding 2 (misattributed #8002 latency) — corrected in comments. The workflow comment and test comment no longer claim the serial walk delayed #8002 by ~6 min; they now state the win is a few fewer Point 4 (state-based real bound) — not implemented (correctly scoped out). A real bound needs persisted per-PR last-inspected state; agreed this is future work, not this round. Conflict
Scope / simplicity noteNo mechanism change: the Verification
中文说明Autofix 评审轮次 — PR #8049已处理 @wenshao 第 2 轮验证反馈（「机制可合并，把声明改对」）。机制逻辑逐字节未变；仅修正了量化声明，以及把这些声明锁死的测试。提交为 反馈逐条1 · 四处表述统一改为概率性描述，去掉「bounded」/「no PR is unlucky forever」—— 3 处代码表述已完成；PR 描述在本模式下无法编辑。
2 · 更新 PR 描述 —— 未完成（本模式无凭据）；见第 1 条。 3 · 放宽
发现 2（#8002 延迟归因错误）—— 已在注释中修正。 workflow 注释与测试注释不再声称「串行遍历使 #8002 延迟约 6 分钟」；现表述为：收益是每次扫描少几次 第 4 点（基于状态的真实上界）—— 未实现（正确地排除在本轮之外）。 真实上界需要持久化每个 PR 的上次检查时间；一致认同这是后续工作，不属于本轮。 冲突
范围 / 简洁性说明无机制改动： 验证
Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。 Re-review when you have a moment. After round 100 this bot stops and leaves the PR for a human. · 有空请复审；第 100 轮后本 bot 停止并将 PR 交给人工。 🧠 Handled by Qwen Code · model/模型 |
|
@qwen-code /triage |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
No issues found. LGTM! ✅
— qwen3.8-max-preview via Qwen Code /review
doudouOUC
left a comment
doudouOUC
left a comment
There was a problem hiding this comment.
Reviewed at 7c4eaf0. The backoff is derived state, not persisted state, which removes the whole producer/consumer-drift failure class: idleness is updatedAt < date -u -d '24 hours ago' (same-format UTC ISO strings, so lexical compare is time order) and the rotation is PR % 4 against a 600s time-quantum slot — no marker to parse, nothing to expire. Reset-on-activity is structural: comments, reviews, labels, and pushes all bump updatedAt, so any work-producing event lifts the backoff on the next tick; the two scan-only signals that don't bump it (base conflict from main moving, still-red checks) are called out in the workflow comment and self-correct once the eventual address run comments/pushes. Fail-open everywhere it matters: forced dispatch never builds the list files, missing/null updatedAt is excluded from the idle set, and a jq failure collapses to an empty set — all three degrade to "inspect", never to "starve". Verified in the step body that both free skips sit before INSPECTED=$(( INSPECTED + 1 )), so a deferred idle candidate consumes no inspection budget, matching the PR's claim that the win is budget + walk latency (and its explicit non-claim about the 10-target cap). Tests behaviorally replay the extracted jq set-builder and bash predicate against fixtures (idle/out-of-slot, idle/in-slot, fresh, forced-dispatch, null updatedAt, takeover cohort) rather than only string-pinning, and pin the skip-before-budget ordering via the loop-head slice. Ran the changed test file locally at this HEAD: 103/103 passed. CI green. No findings.
|
Released in v0.21.2. |
Problem
The scheduled scan inspects every candidate on every tick. The takeover pool doubled in two days — 28 open takeover PRs at last count, 8 of them sitting in "nothing new" state for 10+ hours — and every idle inspection costs twice: a unit of the shared
MAX_CANDIDATE_INSPECTIONSbudget (60), and a slice of the serial API walk over the candidate list. That walk is what delays fresh engagements: on the 09:03 scan (2026-07-29), #8002 — freshly engaged at 08:00 — was not reached until 09:09, six minutes of serialghreads in.(Idle candidates never contend for the 10-target cap — the "nothing new" branch
continues before theTARGETSappend — so this change does not claim to relieve it. The win is inspection budget plus scan-walk latency.)Change
Candidates whose
updatedAt— taken from the candidate list itself, no extra API call, no per-candidate process fork (onejqbuilds an idle set; the loop does a bash substring test, same idiom as the busy skip) — is older than 24h are inspected on roughly every 4th scan instead of every one.Slotting is deterministic on the scan tick (600s, the same quantum as
ROT_OFF): each PR is eligible one 10-minute tick in every four, so the skip gap is bounded at ~30 minutes and no PR is unlucky forever. The skip sits with the busy skip before the inspection-budget increment.Why this is safe:
updatedAtor route in real time — a review event on a takeover PR never waits for a scan.updatedAtcannot see — a base conflict appearing when main moves, and still-red checks awaiting the redcheck marker — wait at most the ~30-minute gap on a PR nobody has touched in a day, and self-correct (the eventual address run comments/pushes).updatedAt.Backed-off candidates are visible in the fleet dashboard as
idle-backoffrows (idle >24h; inspected roughly every 4th scan (gap ≤30m)).Tests
Behavioral replay of the set builder + skip predicate (idle+out-of-slot defers; idle+in-slot inspects; fresh inspects; missing-from-lookup inspects), loop-head slice assertions (both free skips before the budget increment, no budget spend in between — immune to comment growth), an order-independent
--jsonfield pin, the 600s quantum pinned in and the 3600s quantum pinned out, and the corrected cost-model statements pinned in the workflow comment. 103/103; YAML parses.中文说明
问题
定时扫描每一轮检查所有候选。接管池两天翻倍（28 个 open 接管 PR，8 个已空闲 10+ 小时），每次空闲检查有双重代价：占一个共享检查预算（
MAX_CANDIDATE_INSPECTIONS=60），以及串行 API 遍历的一段时长——正是这个遍历拖慢新接管的首次拾取：09:03 扫描直到 09:09（6 分钟串行读之后）才走到 08:00 刚接管的 #8002。（空闲候选不会争抢 10 目标上限——"无新反馈"分支在
TARGETS追加之前就continue了——本改动不声称缓解该上限；收益在检查预算与遍历延迟。）改动
updatedAt（取自候选列表本身，零额外 API 调用、零每候选进程 fork：一次jq构建空闲集合，循环内做 bash 子串判断，与 busy 跳过同款写法）超过 24h 的候选，约每 4 次扫描检查一次。按扫描 tick（600s，与ROT_OFF同量子）确定性排片：每 PR 每 4 个 10 分钟 tick 有 1 个可检，跳过间隔上界 ~30 分钟。跳过与 busy 跳过一起位于检查预算自增之前。安全性：评论/评审/标签/推送都会刷新
updatedAt或本就实时路由；updatedAt看不到的两个仅扫描信号（main 前进导致的 base 冲突、等待 redcheck 标记的持续红检查）最多等 ~30 分钟且自我修正；强制 dispatch 不生成列表文件，集合为空，强制 PR 永远被检查（缺失同样 fail-open）；新接管免疫（打标签即刷新updatedAt）。fleet 面板以idle-backoff行可见（idle >24h; inspected roughly every 4th scan (gap ≤30m)）。测试
集合构建器+跳过谓词的行为回放（空闲出槽推迟/空闲在槽检查/新活动检查/未列出检查）；loop-head 切片断言（两个免费跳过均在预算自增前、其间无预算消耗，注释增长免疫）；字段顺序无关的
--jsonpin；600s 量子 pin 入、3600s pin 出；注释中修正后的成本模型表述 pin 入。103/103；YAML 解析正常。