5.0 KiB
the adopted project Status and Reporting
Load this reference when reading Task states or reporting Task, wave, CI, blocker, or completion status.
Scope Status Vocabulary
Before reporting or changing any lifecycle status, read the project's current ways-of-working/scope.md. Use only the values defined there.
Ideas, Epics, and Features:
IN_BACKLOG → IN_DESIGN → READY_FOR_DELIVERY → IN_DELIVERY → TO_BE_RELEASED → DONE
Tasks:
IN_BACKLOG → READY_FOR_DELIVERY → IN_PROGRESS → TO_BE_RELEASED → DONE
READY_FOR_DELIVERY is the exact Task's Focus-admitted, pickup-ready state. It means Architecture, dependencies, implementation boundaries, verification steps, and Kanban selection are complete; implementation has not started. Delivery claims that Task by moving it directly to IN_PROGRESS. Never require or invent a second Focus-admission decision after READY_FOR_DELIVERY.
CANCELLED is an exceptional terminal status. BLOCKED is a separate flag with a reason and evidence; it never replaces the lifecycle status.
Never invent, abbreviate, or substitute lifecycle values such as Ready, Active, Delivered, Complete, Awaiting CI, or Overrun. Those phrases may describe activity only when clearly separated from the status field. If the status cannot be verified, report status unverified and inspect the source record rather than guessing.
A merge or successful CI does not automatically mean DONE. Releasable application Tasks normally move from IN_PROGRESS to TO_BE_RELEASED; DONE requires the applicable release or completion evidence. Status reports must show the exact value even when a separate plain-language action is also included.
Wave Status Report
When the active project authority explicitly asks for project, delivery, blocker, progress, or wave status, begin the status report with this exact first-line structure, with no text before it:
wave-previous: <previous wave> | wave-current: <current wave> | wave-next: <next wave>
Each value must be an actual dependency-wave label calculated by the the adopted project Release Task Board, such as Wave 11, Wave 12, or Wave 13. Never substitute activities, work descriptions, statuses, invented phases, or ad hoc labels. Resolve the current wave and its adjacent existing waves from the Board selector and task assignments; do not infer them from conversation wording. Use none only when the Board has no previous or next wave.
Do not repeat the wave header or task chapter in ordinary acknowledgements, implementation narration, questions, or non-status replies. Use them only when the active project authority explicitly asks for status.
Current-wave task chapter
Immediately after the header in a requested status report, include:
## Wave XX (Current)
- TASK-XXXX — <status> — Responsible: <Hermes main session or concrete owning process>
Replace XX with the current Board wave number. List every Task assigned to that wave—never a sample or only changed Tasks—and use each Task's verified flow status. For responsibility, name Hermes main session when it actively owns the Task; otherwise name the concrete owning process, such as Delivery pickup, implementation/review, integration, or Release handoff. When no active executor or owning process exists, say Unassigned; never invent an agent, process, or ownership. Refresh the Board/task records and live process state before reporting when they may have changed.
Human-facing delivery updates
In every implementation, review, CI, blocker, merge, handoff, or completion update, lead with the linked branch and pull request where the work is visible. The next line must identify the Task, exact Task status, active gate code, and gate title:
<TASK_ID> | <TASK_STATUS> | <GATE_CODE> — <GATE_TITLE>
Example:
TASK-0084 | IN_PROGRESS | GATE_003_TASK_IMPLEMENTATION — Implement and Review the Task
While work remains inside a gate, continue reporting that same code. When its exit gate passes, report the transition explicitly:
GATE_003_TASK_IMPLEMENTATION passed → GATE_004_TASK_PR_CI
When blocked, name the gate where progress stopped:
BLOCKED at GATE_004_TASK_PR_CI — Verify and Merge the Task PR
Do not invent a separate phase or shorthand. Do not lead with or routinely include commit SHAs, tree hashes, digests, internal worktree paths, or temporary review-commit identities; retain those for automated verification and provide them only when the active project authority asks for audit detail or when an identity mismatch itself is the blocker.
When anything fails, identify the exact failed command, file, test, or CI job. State its failure classification—application code, test assertion, workflow, infrastructure, credentials, or local execution environment—then provide the expected behavior and observed behavior, whether repository or remote state changed, and the concrete repair or owner. Never summarize a failure as only “validation failed”, “review failed”, or “CI failed”.