82 lines
5.0 KiB
Markdown
82 lines
5.0 KiB
Markdown
# 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:
|
|
|
|
```text
|
|
IN_BACKLOG → IN_DESIGN → READY_FOR_DELIVERY → IN_DELIVERY → TO_BE_RELEASED → DONE
|
|
```
|
|
|
|
Tasks:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
## 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:
|
|
|
|
```text
|
|
<TASK_ID> | <TASK_STATUS> | <GATE_CODE> — <GATE_TITLE>
|
|
```
|
|
|
|
Example:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
GATE_003_TASK_IMPLEMENTATION passed → GATE_004_TASK_PR_CI
|
|
```
|
|
|
|
When blocked, name the gate where progress stopped:
|
|
|
|
```text
|
|
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”.
|