Why every task gets an iteration budget

Every task in Berry carries a designation: n/5. This represents the iteration budget — the maximum number of build-review-test cycles permitted before a task either splits or escalates to Needs you.

The pathological case

Without iteration limits, Developer and Reviewer agents risk endless cycles. A diff gets submitted, feedback arrives, corrections introduce new issues, catches occur, and the cycle repeats. While the task never technically fails, it also never completes. Berry observed a task consume 38 iterations, with the final diff being worse than earlier versions.

Why five iterations

The number five allows for a complete round-trip: build, review, fix, re-review, ship. It's also short enough to prevent both human and agent attachment to sunk costs. Beyond five iterations, rationalization becomes tempting.

At the ceiling

Tasks don't fail — they split. The Architect reviews the original brief, failing reviews, and current diff, then decides to either:

1. Split the task into smaller ones with independent budgets, or
2. Escalate to Needs you with a summary of where obstacles emerged

The loop progresses forward, preventing products from getting stuck on resistant cards.

The core principle

A budget functions as a forcing function, not a punishment. Regular ceiling-hitting suggests tasks are oversized — improve planning rather than adjusting limits.