policy: retain artifact validation in Delivery

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.12.3
+version: 1.13.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -46,7 +46,7 @@ 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.
+Delivery owns application **unit testing only** plus static/build-time validation of the application artifacts it publishes: Dockerfiles, image/container contracts, publication records/workflows, and Helm chart linting/rendering/packaging. The project's standalone E2E repository under its UAT channel owns every functional non-unit suite and its fixtures, configuration, runner, and evidence: integration, browser, E2E, acceptance, security-boundary, performance, runtime-budget, smoke, regression, and deployed-environment testing. Delivery must not maintain or execute functional non-unit suites in the application repository. E2E must not install Helm or build/publish application images. 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.
 
@@ -142,13 +142,13 @@ 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 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.
+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 functional non-unit test required to prove that evidence outside the unit boundary; Delivery retains build-time image/container/Helm artifact validation.
 
 ### 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-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.
+Delivery still monitors repository-specific compile/type, unit-test, lint/format, dependency, packaging, workflow, image/container contract, Helm chart, and artifact-publication failures. Functional non-unit browser, integration, performance, security-boundary, 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
 
@@ -212,7 +212,7 @@ Maintain two documentation areas.
 ### Engineering — five sections
 
 1. **Repository and workspace** — monorepo/application/package structure and local prerequisites.
-2. **Development and unit testing** — commands, unit-test fixtures, debugging, and the handoff to UAT for every non-unit suite.
+2. **Development and unit testing** — commands, unit-test fixtures, debugging, Delivery artifact validation, and the handoff to UAT for every functional 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.
@@ -239,7 +239,7 @@ For frontend-affecting work, Delivery requires the approved UI/UX design package
 
 May autonomously:
 
-- run unit tests, builds, and read-only checks; non-unit suites run through UAT;
+- run unit tests, builds, Delivery artifact validations, and read-only checks; functional non-unit suites run through UAT;
 - repair clear CI/build defects within authorized scope;
 - add unit tests for an approved behavior and request non-unit coverage from UAT;
 - maintain accurate delivery documentation;

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 unit testing** — commands, unit-test fixtures, debugging, and the handoff to UAT for every non-unit suite.
+2. **Development and unit testing** — commands, unit-test fixtures, debugging, Delivery artifact validation, and the handoff to UAT for every functional 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/task-delivery-gates.md

@@ -44,7 +44,7 @@ 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, 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.
+**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.
 
@@ -53,7 +53,7 @@ Hermes may pause the repair loop only when progress requires an unavailable exte
 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, `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.
+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.