Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(review): file triage stage — classify changed files to drive packing order and prompt selection [v0.8]

Open
  • Is something wrong?
#666 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
28/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
java
Domain
ai, backend

Research direction

Start with the size-based ordering and First-Fit-Decreasing packing in DiffBudgetPlanner.java (around lines 609-736), then read FindingPipeline.java and ThrillhouseConfig.java to see how the plan is consumed and where config gates live. The new review/FileTriage collaborator would classify files by path signals before packing. Done means unit tests cover the deterministic classifier, and a plan inspection test shows high-risk files reviewed before low-risk ones under a forced spend ceiling. The issue is design-heavy and has no discussion yet, so confirm scope with the maintainer first.

Written by the indexing model from the issue text.

Description

enhancement java
Problem Statement

Batch packing is size-based only: DiffBudgetPlanner orders files by additions+deletions descending and packs First-Fit-Decreasing (DiffBudgetPlanner.java:609-736). Importance never enters the picture, so when the spend ceiling (REVIEW_MAX_TOKENS_PER_REVIEW), the call cap, or a batch failure forces degradation, what gets skipped is whatever happened to pack last — possibly the auth change, while a giant generated file got a full-budget batch.

Proposed Solution

Add a triage stage between diff load and budget planning that classifies every changed file:

  • Deterministic first (free): category from path/content signals — source / test / config / IaC / docs / generated / lockfile — plus coarse risk signals (security-sensitive paths, public API surface, migration files). Most files classify without any model call.
  • Optional cheap LLM call (concise binding, ledger-gated, counted in maxAiCalls accounting): rank only the ambiguous remainder by review priority. One small call with file paths + hunk headers, not diffs — predictable, tiny prompt. Config-gated, default off.

Consumers of the classification:

  1. Packing order: importance-first (risk tier, then size) instead of size-only, so degradation always sheds the lowest-value files. The existing disclosure machinery (omittedFiles, spendCeilingSkippedFiles, withheld-material notice) keeps reporting honestly.
  2. Dimension routing input: batch composition by category makes per-batch dimension selection (the v0.7 routing issue) sharper — e.g. pack config/IaC files together so only those batches carry IaC rules.
  3. Lightweight lane: docs/generated/lockfile tiers can share a minimal sanity-check prompt or be summarized-only, rather than consuming full-prompt budget.
  4. Model routing: the risk tier is exactly the signal #43 (risk-based model routing) needs — this issue provides the classifier, #43 consumes it.
Touchpoints

New review/FileTriage collaborator; review/DiffBudgetPlanner.java (ordering + lane assignment), review/FindingPipeline.java, config/ThrillhouseConfig.java (gate + tier globs, extensible via .github/thrillhousebot.yml like review.ignored-files).

Acceptance criteria
  • Deterministic classifier covered by unit tests over representative path sets; LLM ranking optional and fail-open (falls back to deterministic order).
  • Under a forced spend ceiling, high-risk files are demonstrably reviewed before low-risk ones (test via DiffBudgetPlanner plan inspection).
  • No change in behavior when the feature gate is off.
Alternatives Considered
  • Pure LLM classification — unpredictable cost and an extra call on every review; deterministic-first keeps the common case free.
Dominant language
Java
Stars
35
Forks
7
Avg merge
9h 10m
Merged PRs (30d)
166

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from devops-thiago/ThrillhouseBot

All issues in devops-thiago/ThrillhouseBot

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.