|
|
|
@@ -8,9 +8,9 @@ These gates are mandatory and ordered. Each `GATE_###_NAME` code is the stable i
|
|
|
|
|
|
|
|
|
|
- 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>`.
|
|
|
|
|
- this Delivery skill: `corp-v1-<code>-skills-code-agent/channel-delivery-skic-<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/`.
|
|
|
|
|
All local work and evidence for a Task is isolated under `<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 `<code>-delivery/cache/` so later Tasks can reuse verified versions. Channel-provided input files belong in `<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.
|
|
|
|
|
|
|
|
|
@@ -24,13 +24,13 @@ Hermes may pause the repair loop only when progress requires an unavailable exte
|
|
|
|
|
|
|
|
|
|
### 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.
|
|
|
|
|
**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 `<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 eight 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.
|
|
|
|
|
**Exit gate:** The Task directory exists under `<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
|
|
|
|
|
|
|
|
|
@@ -44,13 +44,13 @@ Hermes may pause the repair loop only when progress requires an unavailable exte
|
|
|
|
|
|
|
|
|
|
### 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.
|
|
|
|
|
**Repository and branch:** Use `<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.
|
|
|
|
|
1. Resolve the real working directory and verify it is inside `<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.
|
|
|
|
@@ -87,7 +87,7 @@ Hermes may pause the repair loop only when progress requires an unavailable exte
|
|
|
|
|
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`. The deployment and handoff evidence contract below must also pass. 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.
|
|
|
|
|
**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`. The deployment and handoff evidence contract below must also pass. Only then may Delivery call the Task delivered. Release execution and the later `DONE` transition belong to `channel-releases-skic-<code>`, not this Delivery process.
|
|
|
|
|
|
|
|
|
|
#### Deployment and handoff evidence
|
|
|
|
|
|
|
|
|
@@ -105,4 +105,4 @@ Send the frozen packet to the mapped UAT channel and any release-readiness notif
|
|
|
|
|
|
|
|
|
|
**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>`.
|
|
|
|
|
**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 `channel-releases-skic-<code>`.
|
jarvis-at-skic