4.2 Mid-Cycle Request Handling Protocol
How to handle new items that appear between cycle planning meetings
The problem this solves
Clients and architects sometimes surface new requests or priorities mid-cycle — after the cycle planner has been created but before the next planning meeting. This protocol defines how to handle these without derailing the current cycle or creating confusion.
Sparsh's framework — the RevGravy standard
Sparsh defined this protocol in March 2026 and it is the closest thing RevGravy has to an official cycle management standard for mid-cycle items:
Step 1 — Filter by urgency and impact
- If the new item directly affects something being shipped this cycle: add it to the current cycle planner
- If it doesn't affect the current cycle delivery: add to next cycle queue or parking lot
Step 2 — Check capacity and effort
|
Item size |
Action |
|
Small / quick win (< 2 hours) |
Add to current cycle — absorb it |
|
Medium (2–6 hours) |
Add to current cycle only if it's critical and there is remaining capacity |
|
Large (> 6 hours) |
Add to next cycle — protect current cycle focus |
Step 3 — If added at capacity
|
Marking standard |
If a new item is added to the current cycle but capacity is tight, mark it clearly as 'Moved to Next Cycle' directly in the cycle planner task table. This makes the trade-off visible and ensures nothing gets lost. |
The default bias
Default toward protecting the current cycle. Queue new items unless they are truly urgent or high-impact. A cluttered cycle with 20 half-done items is worse than a clean cycle with 8 fully completed ones.
For items that come in via email
Juan suggested in March 2026 automating the process of forwarding client emails directly to task@revgravy.com to auto-create HubSpot tickets. This is a BUILD NEXT automation candidate (G1 + G2 pass). Until it's built, the process is: when a client emails the architect directly with a new request, the architect foward the project to HubSpot manually and tags Manuel in Slack if sidekick help is needed.