improve(backend): スキル推論のキャップを実データでチューニング（ADR-0016 #478）#483
Conversation
連携本人の実データに収集コードを当てて打ち切り発生状況とキャップ反実仮想を 計測し、閾値を見直す。 - verify（D6）: ソースキャップをグローバル 30 件 → エコシステム別 50 件へ変更。 monorepo で辞書順先頭のエコシステムが枠を使い切り、direct 依存 26 件中 17 件が昇格漏れしていた（順序戦略の変更は浅い順に勝てないことを確認済み） - IaC（D10）: 件数キャップを 30 → 60 へ引き上げ。30 では infra/modules/ 配下の resource 20 種中 11 種を取りこぼしていた（50 で全量一致、余裕込みで 60） - manifest（D9）と各深さ上限は実データで打ち切りゼロ・寄与ゼロを確認し据え置き - ADR-0016 に計測結果ベースの判断根拠と改訂履歴を追記 - エコシステム別キャップの回帰テスト 2 件を追加 スキーマ・API 契約は不変（migration / codegen 不要）。 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
github-actions
Bot
added
backend
|
Warning Review limit reached
Next review available in: 44 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughChanges replace a single global source-extraction cap with an ecosystem-specific cap (50) and raise the IaC scan cap (30→60) in the GitHub collector. Source selection now buckets paths by scanner ecosystem before applying per-ecosystem sampling and OR-aggregating truncation flags. Tests and ADR documentation are updated accordingly. ChangesEcosystem-based source cap change
Estimated code review effort: 2 (Simple) | ~15 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
backend/app/services/intelligence/github_collector.py (1)
176-188: 🧹 Nitpick | 🔵 TrivialPer-ecosystem bucketing and OR-aggregation logic is correct.
Each ecosystem gets an independent 50-file cap,
source_droppedis properly OR-aggregated, andpath_scanners[path]lookup is safe sinceselected_sourcesonly contains paths frompath_scanners.Operational note: The total source-file fetch budget per repo changed from a fixed 30 to up to 50×N_ecosystems (e.g., ~100 for a typical 2-ecosystem monorepo, up to ~200 for 4 ecosystems). Each fetch is a sequential GitHub API call. Consider monitoring API rate-limit consumption and collection latency after deployment, especially for users with many monorepo-style repos.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@backend/app/services/intelligence/github_collector.py` around lines 176 - 188, The per-ecosystem selection in github_collector.py is fine, but the new budget can increase total GitHub API calls substantially across ecosystems. Add lightweight observability around the source-fetch loop in github_collector.py (near the _select_shallow / selected_sources flow) to record total source files fetched, dropped counts, and any rate-limit/backoff behavior, so deployment impact on latency and API quota can be monitored. If there is an existing metrics or logging path in GitHubCollector, reuse it instead of adding a new mechanism.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@backend/app/services/intelligence/github_collector.py`:
- Around line 176-188: The per-ecosystem selection in github_collector.py is
fine, but the new budget can increase total GitHub API calls substantially
across ecosystems. Add lightweight observability around the source-fetch loop in
github_collector.py (near the _select_shallow / selected_sources flow) to record
total source files fetched, dropped counts, and any rate-limit/backoff behavior,
so deployment impact on latency and API quota can be monitored. If there is an
existing metrics or logging path in GitHubCollector, reuse it instead of adding
a new mechanism.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 6d892ed2-976b-49c0-b0ea-920acec30095
📒 Files selected for processing (3)
backend/app/services/intelligence/github_collector.pybackend/tests/test_github_collector_extended.pydocs/adr/0016-github-skill-inference.md
エコシステム別キャップで 1 リポあたりの source fetch 件数が増えうるため、 GitHub API 消費量を監視できるよう fetch 件数（tree_blobs / manifest / source / infra）を DEBUG ログに残す。既存の module logger を再利用し、レート制限・ バックオフは api_client 側の warning ログをそのまま流用する（重複させない）。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1 participant
Summary
連携本人（yusuke0610）の実データに対して本番の収集コード（github_collector）を当て、キャップ値ごとの打ち切り発生状況と「値を変えた場合の検出数推移」を計測し、閾値を見直しました。
計測詳細
Test Plan
make cipass（lint/test/build）Notes
fetch_repo_treeの 403 握り込み（リトライ不経由）を確認しましたが、今回範囲外として未対応🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Documentation