policy: limit Delivery to unit testing
This commit is contained in:
@@ -44,16 +44,16 @@ 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. All source, test, configuration, application-documentation changes, builds, and tests stay in that clone and branch. If a separate review checkout or output is needed, create and use `review/` under the same Task directory.
|
||||
**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, and builds stay in that clone and branch. Every 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. Tests may use only disposable test services, never persistent Gondor data.
|
||||
2. For a defect, write or identify an exact named test and show that it fails for the expected product reason before repair. For new behavior, add a failing behavioral test first when practical. Syntax, tooling, environment, or credentials errors do not count as product evidence.
|
||||
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 tests, full tests, integration and security-boundary tests, lint, format checks, typecheck or compile, production build, production dependency audit, static checks, generated-artifact checks, `git diff --check`, and repository-state checks.
|
||||
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, `git diff --check`, and repository-state checks. Do not run integration, browser, security-boundary, performance, container-runtime, Helm-rendering, 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.
|
||||
|
||||
@@ -67,7 +67,7 @@ Hermes may pause the repair loop only when progress requires an unavailable exte
|
||||
|
||||
**Required work:**
|
||||
|
||||
1. Verify that every required CI job—such as tests, lint, typecheck, build, security checks, and image 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.
|
||||
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.
|
||||
@@ -82,12 +82,12 @@ Hermes may pause the repair loop only when progress requires an unavailable exte
|
||||
|
||||
**Required work:**
|
||||
|
||||
1. Verify every required integration job, application test, 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.
|
||||
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 integration 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.
|
||||
**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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user