66 lines
3.4 KiB
Markdown
66 lines
3.4 KiB
Markdown
# 09. Operating Cadence and Batch Plan
|
|
|
|
## Purpose
|
|
|
|
Keep the holiday-property-booking board moving in a predictable rhythm so Neo always has clear implementation work and the project does not stall between batches.
|
|
|
|
## Cadence
|
|
|
|
### Every hour: Neo takes the top Ready ticket
|
|
|
|
- Neo takes the top ticket in `Ready for Dev`.
|
|
- Neo follows the normal dev procedure for that ticket:
|
|
- move it to `In Dev`
|
|
- branch from `develop`
|
|
- implement the work
|
|
- push the branch
|
|
- report blockers or validation-ready evidence
|
|
- merge the feature branch back to `develop` when the implementation slice is done
|
|
- leave the merge-complete comment and hand the ticket forward for validation or promotion according to the playbook
|
|
- When the ticket is finished, post a Discord-ready completion summary with the ticket ID, what changed, branch/merge state, and the next step or blocker.
|
|
- Neo works one ticket at a time unless Morpheus explicitly batches related work.
|
|
|
|
### Every hour: Morpheus reviews the lanes
|
|
|
|
- Review the full board for:
|
|
- stalled `In Dev` work
|
|
- validation work waiting on `Ready for Test`, `Deploying to Dev`, or `In QA`
|
|
- release work waiting on `Ready for QA Promotion`, `Deploying to QA`, `QA Deployed`, `Ready for Production`, or `Included in Next Release`
|
|
- blockers that need triage
|
|
- queue depth in `Ready for Dev`
|
|
- If a ticket is clearly stalled, route it to the correct owner and keep the handoff explicit.
|
|
- Morpheus keeps the promotion side of the flow: wait for Neo's merge to `develop`, check the develop build, then promote `develop -> qa` when ready.
|
|
|
|
## Batch Rule
|
|
|
|
- Count the tickets that have not yet been worked on, meaning the tickets still waiting in `Backlog` or `Ready for Dev`.
|
|
- If that count is less than 5, continue the project by creating the next batch of work.
|
|
- The next batch should come from the next unresolved phase in the project plan, in dependency order.
|
|
- Keep the batch grouped so the work stays coherent and reviewable.
|
|
- Keep refilling the ready queue until there are at least 5 unworked tickets, or until the next phase is exhausted.
|
|
|
|
## Routing Rule
|
|
|
|
- For each new ready ticket, add a paste-ready comment that states:
|
|
- the current lane
|
|
- the target lane
|
|
- the next responsible agent
|
|
- the next concrete action
|
|
- Send Neo the actual handoff directly; the ticket comment is the audit trail, not the delivery channel.
|
|
- Keep the ticket comment short and actionable so it makes sense even if someone reads it later without the surrounding chat.
|
|
- Keep lane moves and comments aligned with the playbook lane model; do not skip the comment even when the move is automated or obvious.
|
|
- Do not leave the queue in a state where no ticket is clearly assigned.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- Neo always has a top ready ticket to pick up on the 30-minute cadence.
|
|
- Neo always has a top ready ticket to pick up on the hourly cadence.
|
|
- Neo posts a completion summary to Discord when a ticket finishes.
|
|
- Neo still owns merge-back-to-`develop` for feature work.
|
|
- Morpheus still owns `develop -> qa` promotion after develop is green.
|
|
- Ticket moves and comments stay consistent with the playbook lane model.
|
|
- Morpheus can see the full lane state on the hourly review.
|
|
- The ready queue is replenished before it drops below 5 unworked tickets.
|
|
- New batches are created in dependency order instead of ad hoc.
|
|
- The board never stalls because the next group of tickets was not prepared.
|