[Backlog Discovery] feat(backlog): scheduled-workflow-jitter-throttling

[bestony]

[Backlog Discovery]

• Requirement title: 为定时工作流增加错峰调度与节流策略
• Priority: P2
• Requirement file: backlog/20260221075326-scheduled-workflow-jitter-throttling.md
• Dedupe key: scheduled-workflow-jitter-throttling
• Source run: https://github.com/bestony/self/actions/runs/22253073588

---

[Backlog Discovery]

Update Record 2026-02-21 16:11:09 +08:00

Update summary:

• Polished core scenarios with consistent sentence punctuation.

• Added user problems calling out missing 30-day delay/queue/runtime evidence and unclear throttling conditions.

• Added an external research placeholder for internal Actions usage/queue metrics to quantify impact.

• Expanded proposed solution to include scoped config, explicit throttling conditions with fallback rules, and a manual dispatch bypass.

• Reworked acceptance criteria to define scope/opt-out rules, manual dispatch exceptions, and required 30-day baseline metrics before launch.

• Status: committed

• Commit: f1258c7d093bdf66cb0f7947d2f754bfe27020e6

• Trigger: issue_comment.edited

• Comment: [Backlog Discovery] feat(backlog): scheduled-workflow-jitter-throttling #110 (comment)

• Actor: @github-actions[bot]

• Updated At (Asia/Shanghai): 2026-02-21 16:11:09 +08:00

---

[Backlog Discovery]

Update Record 2026-02-21 16:14:11 +08:00

Update summary:

• Lowered backlog priority from P2 to P3, aligning both frontmatter and priority section.

• Clarified that internal repository metrics are planned, assigning the maintainer a deadline to add 30-day schedule delay, queue time, runtime, and cost share baselines.

• Defined the initial in-scope scheduled workflows for jitter/throttling with an explicit opt-in requirement for others.

• Tightened acceptance criteria wording for the scope definition without changing requirements.

• Status: committed

• Commit: e0e8d427e8bb23184fa459bf5a183c6b05e6c006

• Trigger: workflow_run.completed

• Comment: https://github.com/bestony/self/actions/runs/22253370595

• Actor: @github-actions[bot]

• Updated At (Asia/Shanghai): 2026-02-21 16:14:11 +08:00

---

[Backlog Discovery]

Update Record 2026-02-21 16:16:33 +08:00

Update summary:

• Reviewed trusted feedback and current PR content; no document update was needed.

• Status: no_change

• Commit: N/A

• Trigger: workflow_run.completed

• Comment: https://github.com/bestony/self/actions/runs/22253411285

• Actor: @github-actions[bot]

• Updated At (Asia/Shanghai): 2026-02-21 16:16:33 +08:00

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[github-actions]

[Backlog Discovery]
Reviewer: Product Manager

• Acceptance criteria says apply jitter/throttling to “all schedule workflows” but doesn’t define scope or opt-out, which risks impacting critical workflows; specify which workflows are in-scope and add an explicit opt-out/override rule.
• Core scenario mentions keeping manual triggers, but acceptance criteria doesn’t guarantee manual runs bypass throttling; add a criterion that workflow_dispatch executions are never delayed/skipped (or define when they are).

[github-actions]

[Reviewer Workflow]
Reviewer: Product Manager

需求价值评估

• 是否有价值: 价值不足
• 优先级: P3
• Reviewer 视角结论: 方向合理但缺少近 30 天队列/延迟/成本基线，当前不足以进入高优先级排期。

价值点

• 通过错峰与节流减少定时任务在高峰时段排队或跳过的风险，提升自驱迭代节奏稳定性。
• 以集中配置降低频繁运行带来的 Actions 成本与额度压力，提升运维效率。
• 明确手动触发直通与兜底规则，降低关键任务被误跳过的业务风险。

风险与建议

• 证据不足：需补齐近 30 天延迟率/排队时长/运行时长/成本占比数据，形成收益基线后再评估优先级。
• 规则复杂度风险：节流判定与 opt-out/override 需清晰落地并覆盖关键任务，否则可能引入误跳过或漏跑。

[github-actions]

[Product Designer]

@bestony 当前需求分析中存在待确认问题，请在本 Issue 回复：

1. 近 30 天定时工作流的排队延迟、运行时长与成本基线数据是多少？

来源文档：plans/110-scheduled-workflow-jitter-throttling.md

[github-actions]

[Backlog Discovery]
Reviewer: Product Manager

• Scope definition is missing: the requirement does not list which schedule workflows are in-scope, making it hard to assess impact and opt-out rules. Suggest adding a concrete workflow list (names/paths) and any known exclusions.
• Baseline evidence is marked “待补充”, but acceptance requires 30‑day delay/queue/runtime/cost metrics to validate value. Suggest filling in the metrics now or explicitly stating a data collection plan with owner and timeline before moving forward.

[github-actions]

[Backlog Discovery]
Reviewer: Product Manager

• Requirement priority is inconsistent: PR context states P2 while the requirement file sets P3, which affects planning and execution urgency. Suggest align the priority in the requirement file with the PR context (or update the PR context if P3 is correct) and note the rationale.