policy: limit Delivery to unit testing

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.