[Backlog Discovery] feat(backlog): github-api-conditional-request-cache

[bestony]

[Backlog Discovery]

• Requirement title: 为定时拉取加入条件请求与增量缓存
• Priority: P1
• Requirement file: backlog/20260221063826-github-api-conditional-request-cache.md
• Dedupe key: github-api-conditional-request-cache
• Source run: https://github.com/bestony/self/actions/runs/22252052274

[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]

[Reviewer Workflow]
Reviewer: Product Manager

需求价值评估

• 是否有价值: 有价值
• 优先级: P1
• Reviewer 视角结论: 该需求能显著降低定时任务的 API 调用与 LLM 处理成本，且对规模增长与限流风险具有直接价值。

价值点

• 对高频 schedule 任务，通过条件请求避免无变更时的全量拉取与分析，提升效率
• 降低 GitHub API 限流与工作流失败风险，提升系统稳定性
• 成本侧减少不必要的 LLM 调用与执行时间波动

风险与建议

• 需明确缓存的生命周期与失效策略，否则可能出现数据滞后
• 建议补充量化基线（当前 API 调用量、LLM 成本）以便评估收益

[github-actions]

[Backlog Discovery]
Reviewer: Product Manager

• Scope ambiguity: requirement mentions backlog-discovery and product schedules, but acceptance criteria doesn’t specify which workflows/endpoints are in scope for the first iteration, making delivery and validation unclear. Suggest: explicitly list the workflows and GitHub API endpoints covered in v1.
• Force-refresh control is underspecified: acceptance criteria requires a force-refresh switch but doesn’t define where it is configured (workflow input/env) or its default behavior, which makes it untestable. Suggest: define the exact config surface and defaults.
• Cache persistence criteria are vague: “跨 schedule 运行保留” doesn’t define cache key/retention/eviction or fallback when cache is missing, risking stale or missing data without a clear expected behavior. Suggest: document cache key design, retention expectations, and the full-fetch fallback path.