Merge pull request 'policy: limit Delivery to unit testing' (#9) from policy/unit-tests-only into test

SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: corp-v1-channel-delivery
 description: "Use when operating or synchronizing a Corp v1 project's delivery channel. Drives coding, unit testing, build and continuous-integration health, attempts safe evidence-based fixes, escalates requirement or architecture contradictions, and maintains Ways of Working and Engineering documentation."
-version: 1.11.1
+version: 1.12.3
 author: Hermes Agent
 license: MIT
 metadata:
@@ -46,6 +46,8 @@ This skill owns delivery health for a Corp v1 project. It monitors the project's
 
 Its scope includes coding, unit testing, builds, continuous integration, review readiness, delivery blockers, and maintenance of the project documentation's `Ways of Working` and `Engineering` areas.
 
+Delivery owns **unit testing only**. The project's standalone E2E repository under its UAT channel owns every non-unit suite and its fixtures, configuration, runner, and evidence: integration, browser, E2E, acceptance, security-boundary, performance, runtime-budget, container/image, Helm/rendering, smoke, regression, and deployed-environment testing. Delivery must not maintain or execute those suites in the application repository. It consumes UAT failures as defect evidence, fixes application code with unit-first TTD, and hands the corrected deployed tuple back to UAT.
+
 Load the global `documentation-docusaurus` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus` before changing documentation structure, navigation, Markdown/MDX, Docusaurus configuration, or builds.
 
 Load the global `corp-v1-glossary` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/corp-v1-glossary` whenever project documentation needs to define or explain a reusable term. Maintain one canonical definition in the project's final top-level **Glossary** area and link to it from the owning domain page; do not duplicate glossary-style explanations across channel documentation.
@@ -68,7 +70,7 @@ Use this skill when:
 - operating in `corp-v1-<code>-delivery`;
 - running its recurring synchronization job;
 - implementing or reviewing project code;
-- adding or repairing unit tests;
+- adding or repairing unit tests only; non-unit coverage is routed to the project's UAT channel and standalone E2E repository;
 - diagnosing build or CI failures;
 - checking implementation against requirements and ADRs;
 - maintaining delivery-oriented documentation.
@@ -114,7 +116,7 @@ The Corp v1 overlay is narrower: every Task requires a dedicated visible branch
 
 ## Proactive Iteration Requirement
 
-Every delivery iteration must complete at least one useful, safe activity for an implementation-approved Feature or delivery-health need: implement an unblocked task, add tests, diagnose/fix CI, improve build tooling, update real Ways of Working/Engineering guidance, verify dependency readiness, or document a concrete blocker with evidence. Never create filler changes. Select work only from exact Tasks in `READY_FOR_DELIVERY`; claiming one moves it to `IN_PROGRESS`. Keep architecture's approved task/dependency plan and project documentation current.
+Every delivery iteration must complete at least one useful, safe activity for an implementation-approved Feature or delivery-health need: implement an unblocked task, add unit tests, diagnose/fix CI, improve build tooling, update real Ways of Working/Engineering guidance, verify dependency readiness, or document a concrete blocker with evidence. Never create filler changes. Select work only from exact Tasks in `READY_FOR_DELIVERY`; claiming one moves it to `IN_PROGRESS`. Keep architecture's approved task/dependency plan and project documentation current.
 
 ## Approved Information Boundary
 
@@ -140,25 +142,25 @@ Load the project-adopted engineering skill for the repository stack before editi
 
 ### Unit testing
 
-Load `development-method-ttd` for every behavior change, defect fix, or refactor. It owns RED–GREEN–REFACTOR mechanics, focused-test progression, and test-design anti-patterns. Delivery only requires that the resulting tests map to approved acceptance evidence and that real commands/results are retained.
+Load `development-method-ttd` for every behavior change, defect fix, or refactor. It owns RED–GREEN–REFACTOR mechanics, focused-test progression, and test-design anti-patterns. Delivery requires unit tests to map to approved acceptance evidence and retains their real commands/results. UAT owns every non-unit test required to prove that evidence outside the unit boundary.
 
 ### Build and continuous integration
 
 Load `development-gates` before candidate review, remote CI, merge, or integration validation, and load `development-integrity` before reporting their status. These skills own exact-head identity, attempt integrity, base-drift handling, candidate-versus-integration separation, and honest checkpoint wording.
 
-Delivery still monitors repository-specific compile/type, unit/integration, lint/format, dependency, packaging, container, chart, workflow, and artifact failures. A green local build is never remote CI evidence.
+Delivery still monitors repository-specific compile/type, unit-test, lint/format, dependency, packaging, workflow, and artifact-publication failures. Non-unit, container-runtime, chart-rendering, browser, integration, and acceptance failures arrive as UAT evidence and are routed back for application remediation. A green local build is never remote CI evidence.
 
 ### Per-project reusable CI base images
 
 Each Corp v1 project should own `corp-v1-<code>/corp-v1-<code>-base-images` when stable runtimes or operating-system tools would otherwise be downloaded repeatedly in application CI.
 
-- Keep one folder per image, with its Dockerfile, machine-readable version/platform metadata, usage documentation, build helper, and smoke contract.
+- Keep one folder per image, with its Dockerfile, machine-readable version/platform metadata, usage documentation, build helper, and static publication contract. Runtime smoke belongs to UAT.
 - Pin the upstream base by digest and assert exact runtime/tool versions, architecture, numeric non-root identity, writable workspace, CA trust, Git, shell, and other required tools.
-- Build and smoke-test without registry credentials on pull requests. Publish only from the trusted integration branch using a narrowly scoped Harbor robot secret.
+- Build and perform static/unit validation without registry credentials on pull requests. Publish only from the trusted integration branch using a narrowly scoped Harbor robot secret; UAT validates the published digest at runtime.
 - Publish immutable full-source-SHA tags, read back the Harbor artifact digest, and consume the image from project workflows by digest—not `latest`, a mutable version tag, or an unverified local name.
 - Extend fail-closed tests to reject broad publication triggers, mutable tags, secret access from candidate/PR paths, shell interpolation, wrong digests, and reintroduced runtime setup actions.
 - Prefer the verified job image over repeated runtime or package-manager setup actions. Keep lockfile-frozen application dependency installation in the application repository; do not bake project dependencies into a generic base image.
-- Treat the first real Gitea build, runtime smoke test, Harbor publication, digest readback, and a consumer workflow at the exact candidate SHA as separate acceptance layers.
+- Treat the first real Gitea build, Harbor publication, digest readback, and consumer workflow at the exact candidate SHA as separate Delivery layers. Runtime smoke is a separate UAT layer.
 - Repair image or publication failures forward only. Preserve the last known-good digest for consumers until the replacement image and consuming workflow pass exact-head CI.
 
 ### Runtime-resource placement
@@ -210,7 +212,7 @@ Maintain two documentation areas.
 ### Engineering — five sections
 
 1. **Repository and workspace** — monorepo/application/package structure and local prerequisites.
-2. **Development and testing** — commands, unit/integration testing, fixtures, and debugging.
+2. **Development and unit testing** — commands, unit-test fixtures, debugging, and the handoff to UAT for every non-unit suite.
 3. **Build and continuous integration** — pipelines, checks, artifacts, runners, and failure diagnosis.
 4. **Packaging and deployment preparation** — containers, Helm/GitOps interfaces, configuration, and release inputs.
 5. **Operations and troubleshooting** — observability, known failure modes, recovery checks, and evidence collection.
@@ -237,9 +239,9 @@ For frontend-affecting work, Delivery requires the approved UI/UX design package
 
 May autonomously:
 
-- run tests/builds/read-only checks;
+- run unit tests, builds, and read-only checks; non-unit suites run through UAT;
 - repair clear CI/build defects within authorized scope;
-- add tests for an approved behavior;
+- add unit tests for an approved behavior and request non-unit coverage from UAT;
 - maintain accurate delivery documentation;
 - prepare branches/commits/PRs where the project workflow authorizes it.
 

references/failure-and-documentation.md

@@ -42,7 +42,7 @@ Maintain two documentation areas.
 ### Engineering — five sections
 
 1. **Repository and workspace** — monorepo/application/package structure and local prerequisites.
-2. **Development and testing** — commands, unit/integration testing, fixtures, and debugging.
+2. **Development and unit testing** — commands, unit-test fixtures, debugging, and the handoff to UAT for every non-unit suite.
 3. **Build and continuous integration** — pipelines, checks, artifacts, runners, and failure diagnosis.
 4. **Packaging and deployment preparation** — containers, Helm/GitOps interfaces, configuration, and release inputs.
 5. **Operations and troubleshooting** — observability, known failure modes, recovery checks, and evidence collection.

references/runtime-and-ci.md

@@ -21,7 +21,7 @@ corp-v1-<code>-delivery/
         └── artifacts/         # optional: only when outputs must be retained
 ```
 
-- `cache/` contains reusable technical dependencies installed by Delivery, including pinned Node/pnpm toolchains, Playwright browsers, Nginx binaries, and package-manager download caches. Reuse verified entries across Tasks instead of reinstalling them. Version or digest cache paths when compatibility matters, verify the resolved executable and version in every execution context, and never store credentials, Task evidence, repository content, or mutable application state there.
+- `cache/` contains reusable technical dependencies installed by Delivery, including pinned Node/pnpm toolchains, Nginx binaries, and package-manager download caches. Browser/Playwright dependencies for non-unit suites belong to the UAT workspace and E2E repository. Reuse verified entries across Tasks instead of reinstalling them. Version or digest cache paths when compatibility matters, verify the resolved executable and version in every execution context, and never store credentials, Task evidence, repository content, or mutable application state there.
 - `uploads/` contains files supplied through this channel. It is not a repository checkout or build directory.
 - Create one `workspace/<TASK_ID>/` directory per Task.
 - During `GATE_001_PREP`, create only the required repository clones: `application/` and `documentation/`. If a Task genuinely needs another repository, clone it as another clearly named child.
@@ -68,7 +68,7 @@ Secret availability is capability, not authorization. Verify the destination ori
 Monitor local builds and Gitea Actions for:
 
 - compile/type failures;
-- unit/integration test failures;
+- unit-test failures and UAT-reported non-unit failures;
 - lint/format failures;
 - dependency, packaging, container, or chart failures;
 - workflow/configuration defects;
@@ -93,13 +93,13 @@ Never assume a background process inherits `PATH`, shell activation, Devbox stat
 
 the adopted project owns `corp-v1-<code>/corp-v1-<code>-base-images` as the reusable CI-image repository. Use it when stable runtimes or operating-system tools would otherwise be downloaded repeatedly in application jobs.
 
-- Keep one folder per image, with its Dockerfile, machine-readable version/platform metadata, usage documentation, build helper, and smoke contract.
+- Keep one folder per image, with its Dockerfile, machine-readable version/platform metadata, usage documentation, build helper, and static publication contract. Runtime smoke belongs to UAT.
 - Pin the upstream base by digest and assert exact runtime/tool versions, architecture, numeric non-root identity, writable workspace, CA trust, Git, shell, and other required tools.
-- Build and smoke-test without registry credentials on pull requests. Publish only from the trusted `test` branch using a narrowly scoped Harbor robot secret.
+- Build and perform static/unit validation without registry credentials on pull requests. Publish only from the trusted `test` branch using a narrowly scoped Harbor robot secret; UAT validates the published digest at runtime.
 - Publish immutable full-source-SHA tags, read back the Harbor artifact digest, and consume the image from the adopted project workflows by digest—not `latest`, a mutable version tag, or an unverified local name.
 - Extend fail-closed tests to reject broad publication triggers, mutable tags, secret access from PR paths, shell interpolation, wrong digests, and reintroduced runtime setup actions.
 - Prefer the verified job image over repeated `actions/setup-node` or package-manager bootstrap steps. Keep `pnpm install --frozen-lockfile --ignore-scripts` in the application repository for lockfile parity; do not bake project dependencies into a generic base image.
-- Treat the first real Gitea build, runtime smoke test, Harbor publication, digest readback, and a consumer workflow at the exact PR-head SHA as separate acceptance layers.
+- Treat the first real Gitea build, Harbor publication, digest readback, and consumer workflow at the exact PR-head SHA as separate Delivery layers. Runtime smoke is a separate UAT layer.
 - Repair image or publication failures forward only. Preserve the last known-good digest for consumers until the replacement image and consuming workflow pass exact-head CI.
 
 ### Gondor runtime-resource placement
@@ -107,7 +107,7 @@ the adopted project owns `corp-v1-<code>/corp-v1-<code>-base-images` as the reus
 The adopted project CI jobs and developer workstations must not provision PostgreSQL, queues, object stores, caches, brokers, or other application runtime services. Load `development-gitops-argo-cd-gondor-v1` before defining or changing Gondor desired state. Render the committed project template separately into one repository per environment; Delivery may update only the repository assigned to its non-production environment, while production remains outside Delivery authority unless an explicit project overlay says otherwise.
 
 - Keep every non-production the adopted project environment—including development, integration, test, staging, and preview—and all of its resources isolated from production and from other non-production environments. Destructive or concurrent validation requires a per-run database/schema/role or explicit serialization; it must not reset shared data.
-- CI may orchestrate exact-head validation, but it must not start application runtime-resource service containers or receive application-resource credentials. Harmless process-local test doubles and build tools are not runtime resources. Run resource-dependent tests through a restricted trigger as private in-cluster Jobs/Workflows; do not expose PostgreSQL or another internal resource through Ingress, NodePort, LoadBalancer, or a runner-accessible public endpoint.
+- Delivery CI may orchestrate exact-head unit/build validation, but it must not start application runtime-resource service containers or receive application-resource credentials. Harmless process-local unit-test doubles and build tools are not runtime resources. UAT owns resource-dependent tests and their restricted execution; Delivery only provisions an approved development dependency and hands its exact identity to UAT. Do not expose PostgreSQL or another internal resource through Ingress, NodePort, LoadBalancer, or a runner-accessible public endpoint.
 - Persistent Gondor storage must follow `home-v1--truenas`. For durable the adopted project data, create a purpose-specific TrueNAS dataset and NFS share restricted to Gondor node networks, then bind a static PV/PVC with `persistentVolumeReclaimPolicy: Retain` and `storageClassName: ""`. Do not use the default dynamic `truenas-csi` StorageClass for durable data because its `Delete` reclaim policy can remove the backing dataset with the PVC.
 - Use only External Secrets backed by the existing Bitwarden `ClusterSecretStore`; never commit connection strings or credentials.
 - Provision and verify required Gondor resources before deploying dependent the adopted project code. Resource-independent implementation may proceed, but deployment remains blocked until the dependency is healthy and consumed by the application.

references/task-delivery-gates.md

@@ -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.
+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 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.
+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