Files
holiday-property-booking/09-operating-cadence-and-batch-plan.md
Chris Dumas 7b9ae307a5
Some checks failed
Deploy Holiday Property Booking / deploy (push) Failing after 30s
Playwright Holiday Property Booking / playwright (push) Failing after 6m57s
Test & Build Holiday Property Booking / test-build (push) Successful in 10m43s
docs: add operating cadence and clean styling
2026-05-25 13:16:57 +00:00

3.4 KiB

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.