corp-v1-channel-delivery/references/task-delivery-gates.md

# the adopted project Task Delivery Gates

This file contains the complete ordered procedure for delivering one the adopted project Task. Load it before selecting or continuing a Task.

## End-to-End Task Delivery Gates

These gates are mandatory and ordered. Each `GATE_###_NAME` code is the stable identifier used in communication and evidence. Hermes must not skip ahead, combine evidence from different revisions, or start the next Task before `GATE_005_TASK_POST_MERGE` passes. The three repositories used by this process are:

- application: `corp-v1-<code>/corp-v1-<code>`;
- Task files and project documentation: `corp-v1-<code>/corp-v1-<code>-documentation`; and
- this Delivery skill: `corp-v1-<code>-skills-code-agent/corp-v1-channel-delivery-<code>`.

All local work and evidence for a Task is isolated under `corp-v1-<code>-delivery/workspace/<TASK_ID>/`. Start with the required repository clones. Create Task-local `review/`, `cache/`, `tmp/`, `logs/`, or `artifacts/` only when a concrete activity for that Task needs them. Reusable installed toolchains and technical dependencies belong in `corp-v1-<code>-delivery/cache/` so later Tasks can reuse verified versions. Channel-provided input files belong in `corp-v1-<code>-delivery/uploads/`.

Hermes main session owns the Task, performs implementation and exact-head review, and communicates with the active project authority. Local repository tools execute deterministic commands. Gitea Actions runs remote CI. Gondor/GitOps is used only by an approved deployment or Release process. Cron never owns or continues a Task. No implementation or review subagent may work on the selected Task.

Verification is part of each stage, not a separate end checklist. Before leaving a stage, pass its **Exit gate** and retain the evidence named there. Every Delivery progress, blocker, CI, merge, handoff, and completion update must name the active gate code and title. When a gate passes, report the passed gate code and the next gate code. At every stage, use only the adopted project's seven project channels, load the references and engineering skills required for that action, route contradictions instead of guessing, and report failures with the exact command, file, test, or CI job.

### Mandatory gate-failure recovery

If any check, command, test, review, CI job, merge precondition, integration check, publication check, or Exit gate fails, the Task remains in that same gate. Hermes must diagnose the root cause, implement the smallest safe forward fix within the approved Task scope, rerun every affected check, and repeat this repair-and-verification loop until the complete gate passes. A repairable failure is work to fix; it is not a stopping point, a reason to abandon the Task, or permission to start another Task.

Hermes may pause the repair loop only when progress requires an unavailable external dependency or credential, a human decision or permission, a change outside the approved requirements or Architecture, or an unsafe, destructive, or otherwise unauthorized action. In that case, keep the Task's lifecycle status unchanged, record `BLOCKED` separately with the exact evidence, responsible owner, and next action, and resume the same gate as soon as the blocker is removed. Never bypass, weaken, suppress, or relabel a failed gate to make it pass.

### Stage 1 — `GATE_001_PREP` — Pick, Start, and Open the Task PR

**Repository and branch:** First read `corp-v1-<code>/corp-v1-<code>-documentation` remote `test` without creating a branch. After one eligible Task is identified, create `corp-v1-<code>-delivery/workspace/<TASK_ID>/`. Create only its initial fresh repository clones: clone the application repository into `application/` and documentation repository into `documentation/`. Do not create optional support folders during preparation. In `application/`, create branch `<release>/<TASK_ID>-<short-explanation>-<attempt>` from application `test`, with a PR whose title exactly equals the branch name and whose base is `test`. In `documentation/`, create branch `<release>/<TASK_ID>-start-delivery-<attempt>` into documentation `test`, with the same title/base rules.

**Runtime:** Hermes main session verifies eligibility, creates and reads back the application branch and PR without editing repository content, then creates the documentation branch and PR, updates the Task file, runs documentation checks, and merges the documentation PR only after its checks pass. Gitea Actions runs remote checks. Do not use HermesSubAgent or cron.

**Required work:** Verify that the Task file says `READY_FOR_DELIVERY`, the Board places the Task in the current wave, dependencies have reached the states required by the Task, the parent Feature has implementation approval, and required Architecture, requirements, target release, and UI/UX inputs exist. Inspect only the adopted project's seven project channels and select exactly one Task. Create the Task workspace and fresh application/documentation clones before repository mutation. Fetch application `test`; create the exact local application branch; use an empty kickoff commit if Gitea requires a difference; push; open the application PR; and verify that local branch, remote branch, PR head branch, local head, remote head, PR title, and `test` base match. Then use the Task's documentation clone to add the hash-linked `READY_FOR_DELIVERY` to `IN_PROGRESS` event with actor, time, Task, wave, application branch/PR evidence, previous hash, and new hash, and merge that documentation change.

**Exit gate:** The Task directory exists under `corp-v1-<code>-delivery/workspace/<TASK_ID>/`; its required `application/` and `documentation/` clones exist and have the expected remotes; no optional support folder was created without a concrete Task need; no Task checkout was created elsewhere; the application branch and PR are visible and all identities match; the documentation PR is merged; and the Task file on remote documentation `test` says `IN_PROGRESS`. Only then may source, test, configuration, or application documentation files be edited. Report the selected Task, wave, satisfied dependencies, application PR, Task workspace, and merged status change. If eligibility evidence is missing or contradictory, do not select or mutate the Task and do not create the application branch; stop and name the responsible owner.

### Stage 2 — `GATE_002_TASK_PLAN` — Plan the Task

**Repository and branch:** Read Task, requirement, Architecture, and UI/UX files from the Task's `documentation/` clone at `test`; keep implementation notes and changes in the Task's `application/` clone on the existing application Task branch.

**Runtime:** Hermes main session inspects documentation and application code. Do not use HermesSubAgent.

**Required work:** Load the project engineering skills needed by the Task. Map each acceptance criterion to affected production code, a named test, edge and failure cases, security boundaries, build or artifact evidence, and its requirement or Architecture reference.

**Exit gate:** Every criterion has a checkable proof. A contradiction stops implementation and goes to the responsible Scope, Architecture, UI/UX, Kanban, or Release owner.

### Stage 3 — `GATE_003_TASK_IMPLEMENTATION` — Implement and Review the Task

**Repository and branch:** Use `corp-v1-<code>-delivery/workspace/<TASK_ID>/application/` on the existing application Task branch and PR. Application source, unit tests, configuration, application-documentation changes, builds, and image/container/Helm artifact validation stay in that clone and branch. Every functional non-unit suite stays in the UAT-owned E2E repository. If a separate review checkout or output is needed, create and use `review/` under the same Task directory.

**Runtime:** Hermes main session runs the implementation and review loops with local repository tools inside the selected Task directory. Create and use optional `review/`, `cache/`, `tmp/`, `logs/`, or `artifacts/` folders only when the current activity needs them. Repeat environment and real-working-directory preflight in every foreground shell, review checkout, background process, main-session review command, and CI job. Do not use an implementation or review subagent, human-review dependency, or cron to satisfy this gate.

**Required work:**

1. Resolve the real working directory and verify it is inside `corp-v1-<code>-delivery/workspace/<TASK_ID>/`; then verify branch and PR identity, repository state, required tools and committed versions, and required environment-variable names without printing values. For Node/pnpm work, check the resolved `node` and `pnpm` commands and versions. Delivery unit tests use process-local fakes and must not start runtime services; UAT owns resource-dependent testing.
2. For a defect, write or identify an exact named unit test and show that it fails for the expected product reason before repair. For new behavior, add a failing unit test first when practical and request the required non-unit coverage from UAT. Syntax, tooling, environment, or credentials errors do not count as product evidence.
3. Implement only the approved Task, one behavior slice at a time. Keep the diff small, cover normal, edge, and failure behavior, avoid unrelated refactors, and repair forward without reverting valid work.
4. Run all applicable focused and full unit tests, lint, format checks, typecheck or compile, production build, production dependency audit, static checks, generated-artifact checks, and Delivery-owned Dockerfile/image/container/publication/Helm artifact validations, plus `git diff --check` and repository-state checks. Do not run functional integration, browser, security-boundary, performance, or acceptance suites in Delivery; request and consume those results from UAT.
5. After local checks pass, commit and push the Task changes without rewriting history. Read back the remote branch and PR and verify that the local checked revision, remote branch head, and PR head are identical.
6. Hermes main session reviews that exact PR head for logic, security, acceptance coverage, production-path use, and test gaps. Tests alone are not the review. The main session must inspect the complete diff and relevant production paths, record a pass/fail verdict for the exact revision, and remain accountable for that verdict. If review finds a problem, remain in `GATE_003_TASK_IMPLEMENTATION`: repair it on the same Task branch, rerun affected local checks, push the new PR head, and review that exact head again.

**Exit gate:** Every local command and review used the selected Task workspace, and every optional support folder had a concrete Task need; every acceptance criterion has implementation and test evidence; every required local check passes; the local checked revision, remote branch head, and PR head are identical; and that exact PR head has a passing review with no unresolved logic, security, acceptance, or material test finding. Any later file change keeps or returns the Task to `GATE_003_TASK_IMPLEMENTATION` until affected checks, push/readback, and review pass again. Any failure report names the exact command, file, test, or review finding; observed and expected behavior; failure class; mutation state; and repair or owner.

### Stage 4 — `GATE_004_TASK_PR_CI` — Verify and Merge the Task PR

**Repository and branch:** Use the application PR and `application/` clone inside the selected Task workspace, targeting `corp-v1-<code>/corp-v1-<code>` `test`; then fetch and read the resulting application `test` revision in that same clone after merge.

**Runtime:** Gitea Actions runs PR CI. Hermes main session verifies CI and PR state, confirms its own exact-head review still covers the PR head, performs the authorized Gitea merge, and reads back the merge result. No subagent reviews or merges.

**Required work:**

1. Verify that every required Delivery CI job—unit tests, lint, typecheck, build, static security checks, and artifact publication validation—passes on the exact PR head reviewed in `GATE_003_TASK_IMPLEMENTATION` and within one complete successful attempt. Never combine passing jobs from different revisions or attempts.
2. Immediately before merge, re-read the PR and current application `test`. Confirm that the PR remains open, its head is unchanged, its base is `test`, its branch equals the reviewed PR head, required CI is green, review still matches, the PR is mergeable, and base drift is harmless.
3. If conflict resolution, rebase, or any file/tree change is required, return to `GATE_003_TASK_IMPLEMENTATION`; repeat affected local checks, push/readback, and review for the new PR head; then restart `GATE_004_TASK_PR_CI` for that exact head.
4. Merge without rewriting the reviewed PR head. Read back the merged PR and resulting application `test` revision.

**Exit gate:** All required PR CI succeeds on the exact reviewed PR head; the final pre-merge check refers to that same head; the PR is merged; and the exact application `test` integration revision is known. The Task remains `IN_PROGRESS`; merge alone does not mean `TO_BE_RELEASED` or `DONE`.

### Stage 5 — `GATE_005_TASK_POST_MERGE` — Verify Integration and Hand Off the Task

**Repository and branch:** Use the selected Task's `application/` clone to validate `corp-v1-<code>/corp-v1-<code>` `test` at the exact integration revision produced by `GATE_004_TASK_PR_CI`. Then use the same Task's `documentation/` clone to create branch `<release>/<TASK_ID>-release-handoff-<attempt>` into documentation `test`, with a PR title exactly equal to the branch name and base `test`.

**Runtime:** Gitea Actions runs application integration, build, publication, and documentation checks. Hermes main session verifies those results, creates and validates the documentation handoff, applies the review rules from `GATE_003_TASK_IMPLEMENTATION` to the exact documentation PR head, and performs the authorized documentation merge. Gondor/GitOps is used only if the Task explicitly includes an approved deployment.

**Required work:**

1. Verify every required application unit-test/build job, container build, immutable image publication, registry digest readback, and artifact check on the exact application `test` integration revision. PR-head CI cannot replace post-merge integration evidence.
2. Add the hash-linked `IN_PROGRESS` to `TO_BE_RELEASED` event with the merged application PR, integration revision, successful integration CI, publication evidence when required, and acceptance evidence.
3. Update Ways of Working or Engineering documentation only when this Task changed how the project actually works.
4. Validate, review, merge, and read back the documentation handoff PR.

**Exit gate:** Every required post-merge unit-test, build, and publication job succeeds on the exact application `test` revision; the documentation PR is merged; and the Task file on remote documentation `test` says `TO_BE_RELEASED`. Only then may Delivery call the Task delivered. Release execution and the later `DONE` transition belong to `corp-v1-channel-releases-<code>`, not this Delivery process.

### Stage 6 — `GATE_006_NEXT_TASK` — Pick the Next Task

**Repository and branch:** Read refreshed documentation `test` and the Board from the completed Task's `documentation/` clone. Do not reuse that Task directory for another Task and create no new branch until the next Task passes `GATE_001_PREP`, which creates its own workspace and fresh clones.

**Runtime:** Hermes main session selects the next Task. Do not use cron or a subagent for selection.

**Required work:** Confirm the previous Task says `TO_BE_RELEASED`, no delivery blocker remains, capacity is free, and the next Task says `READY_FOR_DELIVERY` with satisfied dependencies.

**Exit gate:** Report the next selected Task and return to `GATE_001_PREP`. Do not wait for `DONE`; release execution and `DONE` are owned by `corp-v1-channel-releases-<code>`.