docs: reconcile canonical SKIC channel skill names

SKILL.md

@@ -1,16 +1,16 @@
 ---
-name: corp-v1-channel-delivery
+name: channel-delivery-skic
 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.13.0
+version: 1.14.1
 author: Hermes Agent
 license: MIT
 metadata:
   hermes:
     tags: [corp-v1, discord, channel, delivery, coding, testing, ci]
-    related_skills: [corp-v1-main, home-v1-discord, documentation-docusaurus, corp-v1-glossary, development-durable-wave-execution, development-gates, development-integrity, development-method-ttd, development-branching-strategy, development-monorepo-pnpm, development-scripts, development-gitops-argo-cd-gondor-v1]
+    related_skills: [channel-board-skic, home-v1-discord, documentation-docusaurus, corp-v1-glossary, development-durable-wave-execution, development-gates, development-integrity, development-method-ttd, development-branching-strategy, development-monorepo-pnpm, development-scripts, development-gitops-argo-cd-gondor-v1]
 ---
 
-# Corp v1 Delivery Channel
+# SKIC Delivery Channel Reference
 
 ## Overview
 
@@ -42,7 +42,7 @@ Never invent, abbreviate, or substitute lifecycle values such as `Ready`, `Activ
 
 A merge or successful CI does not automatically mean `DONE`. Releasable application Tasks normally move from `IN_PROGRESS` to `TO_BE_RELEASED`; `DONE` requires the applicable release or completion evidence. Status reports must show the exact canonical value even when a separate plain-language action is also included.
 
-This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, and `releases` channels and implements only tasks whose parent Feature has explicit human `Approved for Implementation` evidence and whose exact Task status is `READY_FOR_DELIVERY`. That status is the Focus-admitted pickup handoff; no separate post-status admission gate exists.
+This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, `uat`, and `releases` channels and implements only tasks whose parent Feature has explicit human `Approved for Implementation` evidence and whose exact Task status is `READY_FOR_DELIVERY`. That status is the Focus-admitted pickup handoff; no separate post-status admission gate exists.
 
 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.
 
@@ -54,7 +54,7 @@ Load the global `corp-v1-glossary` skill from `https://gitea.lego-cloud.eu/home-
 
 ## Shared Corp v1 System Login
 
-When an authorized task requires login to a Corp v1 system being built or operated, follow the shared policy in `corp-v1-main` and use only the Bitwarden-injected runtime secrets named:
+When an authorized task requires login to a Corp v1 system being built or operated, follow the shared policy in `channel-board-skic` and use only the Bitwarden-injected runtime secrets named:
 
 ```text
 HL_V1_SSO_EMAIL
@@ -67,7 +67,7 @@ Secret availability is capability, not authorization. Verify the destination ori
 
 Use this skill when:
 
-- operating in `corp-v1-<code>-delivery`;
+- operating in `<code>-delivery`;
 - running its recurring synchronization job;
 - implementing or reviewing project code;
 - adding or repairing unit tests only; non-unit coverage is routed to the project's UAT channel and standalone E2E repository;
@@ -120,16 +120,17 @@ Every delivery iteration must complete at least one useful, safe activity for an
 
 ## Approved Information Boundary
 
-Inspect only the project's seven channels:
+Inspect only the project's eight channels:
 
 ```text
-corp-v1-<code>-general
-corp-v1-<code>-scope
-corp-v1-<code>-architecture
-corp-v1-<code>-ui-ux
-corp-v1-<code>-kanban
-corp-v1-<code>-delivery
-corp-v1-<code>-releases
+<code>-general
+<code>-scope
+<code>-architecture
+<code>-ui-ux
+<code>-kanban
+<code>-delivery
+<code>-uat
+<code>-releases
 ```
 
 Use enough delivery history to avoid duplicate work and only relevant new activity from the other channels. Never inspect another project.
@@ -260,6 +261,8 @@ Include repository, branch, commit SHA, changed paths, commands, local results,
 
 ## Mined Project-Adoption Improvements
 
+Review provenance and exclusions: [AeroSim lessons review](references/aerosim-lessons-review.md).
+
 ## Dedicated Project Channel Workspace
 
 Every project adoption must bind this channel to a dedicated local workspace under the active working root. Keep clones, worktrees, plans, reports, screenshots, generated artifacts, retained logs, and channel inputs inside that channel root. Use run-unique or task-specific children under `workspace/`; keep durable project truth in approved repositories. A local folder boundary organizes execution only—it neither broadens authority nor replaces remote evidence. Delivery adoptions should additionally use a channel-level `cache/` for reusable pinned toolchains and dependencies, while keeping Task evidence isolated by Task.
@@ -311,3 +314,12 @@ When selectable controls are needed, explain every complete option and its trade
 - [ ] Contradictions were escalated, not guessed through.
 - [ ] Ways of Working and Engineering documentation remains accurate.
 - [ ] Completed work includes exact evidence.
+
+## Canonical naming and compatibility
+
+- Canonical installed and repository name: `channel-delivery-skic`.
+- Source: `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/channel-delivery-skic`.
+- Previous name: `corp-v1-channel-delivery`; retained locally only as a compatibility alias. New guidance and presentations use the canonical name.
+- Naming-only migration authorized by RootAtSkic in [presentation message 1562523679223578705](https://discord.com/channels/1518726359512387766/1543922127898415154/1562523679223578705). Repository ID, history, support files, project authority and organization ownership are preserved.
+- This is a reusable central reference, not a new shared Discord channel. Project adoptions use `channel-delivery-skic-<code>` and remain separately owned.
+- Current project channel: `<code>-delivery` inside `skic-<code>`.

references/aerosim-lessons-review.md

@@ -0,0 +1,30 @@
+# AeroSim lessons review — Delivery
+
+## Immutable sources
+
+AeroSim Delivery source SHA: `0c0e68bde3189fd96415af6035200cf7fcb9c877`. Central baseline: `0bf71b905f0160631460807b371732b1afc5b0cb`.
+- [SKILL.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-delivery-skic-aerosim/src/commit/0c0e68bde3189fd96415af6035200cf7fcb9c877/SKILL.md)
+- [references/task-delivery-gates.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-delivery-skic-aerosim/src/commit/0c0e68bde3189fd96415af6035200cf7fcb9c877/references/task-delivery-gates.md)
+- [references/runtime-and-ci.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-delivery-skic-aerosim/src/commit/0c0e68bde3189fd96415af6035200cf7fcb9c877/references/runtime-and-ci.md)
+- [references/single-subagent-task-delivery.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-delivery-skic-aerosim/src/commit/0c0e68bde3189fd96415af6035200cf7fcb9c877/references/single-subagent-task-delivery.md)
+
+Read the full source skill and all nine references against the central skill and its seven references. Relevant sections: **Overview**, **End-to-End Task Delivery Gates**, **Hourly Worker Reconciliation**, gate **Stage 5**, **Immutable application images and Helm charts**, and **Main-Session Verification**.
+
+## Promoted lessons
+
+- Bind the post-integration UAT handoff to an actual deployed tuple, not a PR-head CI result or image push. Put the contract in Stage 5, without duplicating generic exact-head algorithms already owned by `development-gates`.
+- Distinguish root Git, child chart/source, pod image, and endpoint identity; operational health is not user-visible acceptance.
+- Retain destination delivery proof and prevent a Releases notification from bypassing UAT or authorizing release.
+- Include UAT in the information boundary; replace stale seven-channel wording rather than retaining two conflicting lists.
+
+## Runtime drift reviewed
+
+Installed Delivery `SKILL.md` SHA-256: `46e5304d701d180496688d9a16bb1413fb96c7a888aaf83570da62fc8a7447ff`; installed `references/task-delivery-gates.md` SHA-256: `fcb02322d5f440f3e59a24fa03c4ae74370e469aa6a35a42d94db8818448cca0`. These are supplementary local snapshots, not content attributed to the pinned Git commit. Their **End-to-End Task Delivery Gates / Stage 5** strengthen runtime readback and non-runtime `not_applicable` reasons. Generalized only the ready-for-UAT evidence requirement; the universal AeroSim development-deployment mandate and its standing authority remain project-local. Full runtime reference diffs were inspected, including stale test-ownership wording.
+
+## Exclusions
+
+No project rollout, runtime overwrite, owner reassignment, branch naming change, Jira mandate, standing merge/deploy delegation, account recovery, board/channel IDs, endpoint, scheduler cadence, or deployment configuration is promoted. Central authority and project overlays remain unchanged. The newer central functional-non-unit versus build-time artifact-validation split is retained; runtime references that send Helm artifact validation to UAT are stale and are not imported.
+
+## Verification
+
+Run `python3 -B -m unittest discover -s tests -v` from this repository, plus `git diff --check`. Tests validate the published documentation contract and links offline; they do not prove a deployment or live acceptance run.

references/repository-entry-and-visibility.md

@@ -2,7 +2,7 @@
 
 Load this reference before claiming a Task, creating its application branch, opening its PR, or resuming its worktree.
 
-All local repository entry happens inside `corp-v1-<code>-delivery/workspace/<TASK_ID>/`. During preparation, create only the required repository clones: `application/` and `documentation/`. Optional Task-local `review/`, `cache/`, `tmp/`, `logs/`, or `artifacts/` folders may be added later only when a concrete Task activity needs them. Reusable installed toolchains and technical dependencies are the sole exception: place them in `corp-v1-<code>-delivery/cache/`, never in a Task workspace. A repository branch, clone, Task evidence file, or other Task-local support folder outside the selected Task directory does not satisfy this gate.
+All local repository entry happens inside `<code>-delivery/workspace/<TASK_ID>/`. During preparation, create only the required repository clones: `application/` and `documentation/`. Optional Task-local `review/`, `cache/`, `tmp/`, `logs/`, or `artifacts/` folders may be added later only when a concrete Task activity needs them. Reusable installed toolchains and technical dependencies are the sole exception: place them in `<code>-delivery/cache/`, never in a Task workspace. A repository branch, clone, Task evidence file, or other Task-local support folder outside the selected Task directory does not satisfy this gate.
 
 ## Implementation Entry Gate
 

references/runtime-and-ci.md

@@ -4,10 +4,10 @@ Load this reference before login, toolchain execution, CI work, image publicatio
 
 ## Channel-owned workspace
 
-Resolve the channel root as `corp-v1-<code>-delivery/` under the active user's working root:
+Resolve the channel root as `<code>-delivery/` under the active user's working root:
 
 ```text
-corp-v1-<code>-delivery/
+<code>-delivery/
 ├── cache/                 # reusable channel toolchains and technical dependencies
 ├── uploads/
 └── workspace/
@@ -34,7 +34,7 @@ corp-v1-<code>-delivery/
 
 ## Shared Corp v1 System Login
 
-When an authorized task requires login to a Corp v1 system being built or operated, follow the shared policy in `corp-v1-main` and use only the Bitwarden-injected runtime secrets named:
+When an authorized task requires login to a Corp v1 system being built or operated, follow the shared policy in `channel-board-skic` and use only the Bitwarden-injected runtime secrets named:
 
 ```text
 HL_V1_SSO_EMAIL

references/task-delivery-gates.md

@@ -8,13 +8,13 @@ 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.
 
-Verification is part of each stage, not a separate end checklist. Before leaving a stage, pass its **Exit gate** and retain the evidence named there. Every Delivery progress, blocker, CI, merge, handoff, and completion update must name the active gate code and title. When a gate passes, report the passed gate code and the next gate code. At every stage, use only the adopted project's seven project channels, load the references and engineering skills required for that action, route contradictions instead of guessing, and report failures with the exact command, file, test, or CI job.
+Verification is part of each stage, not a separate end checklist. Before leaving a stage, pass its **Exit gate** and retain the evidence named there. Every Delivery progress, blocker, CI, merge, handoff, and completion update must name the active gate code and title. When a gate passes, report the passed gate code and the next gate code. At every stage, use only the adopted project's eight project channels, load the references and engineering skills required for that action, route contradictions instead of guessing, and report failures with the exact command, file, test, or CI job.
 
 ### Mandatory gate-failure recovery
 
@@ -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 seven 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.
+**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.
@@ -78,16 +78,24 @@ Hermes may pause the repair loop only when progress requires an unavailable exte
 
 **Repository and branch:** Use the selected Task's `application/` clone to validate `corp-v1-<code>/corp-v1-<code>` `test` at the exact integration revision produced by `GATE_004_TASK_PR_CI`. Then use the same Task's `documentation/` clone to create branch `<release>/<TASK_ID>-release-handoff-<attempt>` into documentation `test`, with a PR title exactly equal to the branch name and base `test`.
 
-**Runtime:** Gitea Actions runs application integration, build, publication, and documentation checks. Hermes main session verifies those results, creates and validates the documentation handoff, applies the review rules from `GATE_003_TASK_IMPLEMENTATION` to the exact documentation PR head, and performs the authorized documentation merge. Gondor/GitOps is used only if the Task explicitly includes an approved deployment.
+**Runtime:** Gitea Actions runs application integration, build, publication, and documentation checks. Hermes main session verifies those results, creates and validates the documentation handoff, applies the review rules from `GATE_003_TASK_IMPLEMENTATION` to the exact documentation PR head, and performs the authorized documentation merge. Gondor/GitOps is used only within approved deployment authority. Apply the deployment and handoff evidence contract below before declaring the handoff complete.
 
 **Required work:**
 
 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.
+2. Complete the deployment and handoff evidence contract below, then add the hash-linked `IN_PROGRESS` to `TO_BE_RELEASED` event with the merged application PR, integration revision, successful integration CI, publication and deployment evidence when required, and the UAT handoff or verified non-runtime exception.
 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`. 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
+
+For runtime-affecting work using Delivery → UAT, require a verified non-production deployment before a ready-for-UAT handoff. Resolve the approved deployment owner, target environment, and desired-state repository from the project contract; this requirement grants no deployment authority. Missing authority or deployment evidence is `BLOCKED`, not a successful handoff. If the project requires deployment before `TO_BE_RELEASED`, enforce that gate even when the Task omits it. Only work with no deployable runtime effect may record `not_applicable`, with a verified reason; lack of permission is not such a reason.
+
+Retain the exact integrated application commit, immutable image digests and chart identity where applicable, template provenance, rendered GitOps commit, controller revisions/sync/health, pod image IDs, environment/base URL, verification time, Task identity, and limitations. Follow the owning GitOps workflow, not direct workload mutation. For app-of-apps, distinguish root Git revision from child chart/source revision and verify each against its own desired state. Deployment readback proves identity and operational health, not user-visible acceptance; UAT owns that verdict.
+
+Send the frozen packet to the mapped UAT channel and any release-readiness notification required by the adopted workflow. Retain the destination channel/message ID and readback, or the verified dispatcher delivery receipt; a source-channel mention is not delivery proof. Respect auto-delivery contracts rather than sending duplicate messages, and report delivery as unverified until a receipt exists. A Releases notification routes readiness only; it neither skips UAT nor authorizes release or `DONE`.
 
 ### Stage 6 — `GATE_006_NEXT_TASK` — Pick the Next Task
 
@@ -97,4 +105,4 @@ Hermes may pause the repair loop only when progress requires an unavailable exte
 
 **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>`.

tests/test_aerosim_lessons_contract.py

@@ -0,0 +1,57 @@
+"""Offline regression tests for the channel's published prose contract."""
+from pathlib import Path
+import re
+import unittest
+
+ROOT = Path(__file__).resolve().parents[1]
+
+class LessonsContract(unittest.TestCase):
+    def test_review_provenance_and_link(self):
+        review = ROOT / "references/aerosim-lessons-review.md"
+        self.assertTrue(review.is_file())
+        text = review.read_text()
+        self.assertRegex(text, r"/src/commit/[0-9a-f]{40}/")
+        self.assertIn("## Exclusions", text)
+        self.assertIn("aerosim-lessons-review.md", (ROOT / "SKILL.md").read_text())
+
+    def test_local_markdown_links_resolve(self):
+        for path in [ROOT / "SKILL.md", *ROOT.glob("references/*.md")]:
+            for target in re.findall(r"\]\(([^)]+)\)", path.read_text()):
+                if "://" not in target and not target.startswith(("#", "<")):
+                    self.assertTrue((path.parent / target.split("#")[0]).is_file(), (path, target))
+
+    def test_no_project_authority_transplant(self):
+        for path in [ROOT / "SKILL.md", *ROOT.glob("references/*.md")]:
+            if path.name == "aerosim-lessons-review.md":
+                continue
+            text = path.read_text()
+            for forbidden in ("jarvis-at-skic", "aerosim-dev.apps", "AEROSIM_STANDING", "1537388451501056081"):
+                self.assertNotIn(forbidden, text)
+
+    def test_contract_0(self):
+        text = (ROOT / 'references/task-delivery-gates.md').read_text()
+        self.assertIn('#### Deployment and handoff evidence', text)
+        self.assertIn('pod image IDs', text)
+        self.assertIn('destination channel/message ID', text)
+        self.assertIn('not_applicable', text)
+        self.assertIn('not user-visible acceptance', text)
+
+    def test_contract_1(self):
+        text = (ROOT / 'SKILL.md').read_text()
+        self.assertIn('<code>-uat', text)
+        self.assertIn('version: 1.14.1', text)
+
+    def test_stage_five_scope_and_authority(self):
+        text = (ROOT / "references/task-delivery-gates.md").read_text()
+        stage = text.split("### Stage 5", 1)[1].split("### Stage 6", 1)[0]
+        self.assertIn("#### Deployment and handoff evidence", stage)
+        self.assertNotRegex(stage, r"(?m)^## ")
+        self.assertIn("this requirement grants no deployment authority", stage)
+        self.assertIn("If the project requires deployment before", stage)
+        self.assertNotIn("only if the Task explicitly includes", stage)
+        self.assertIn("image/container/Helm artifact validation", text)
+        self.assertIn("No implementation or review subagent", text)
+
+
+if __name__ == "__main__":
+    unittest.main()