fix: retain global review precedence in entry guidance

fix: align Central independent review and base invalidation gates
Merge pull request 'fix: Delivery source identity and bounded helper routing' (#16 ) from fix/delivery-source-identity-t3c6f0036 into test
2026-10-26 11:34:06 +00:00 · 2026-10-26 11:31:49 +00:00 · 2026-10-26 03:26:59 -07:00 · 2026-10-26 10:24:59 +00:00 · 2026-10-26 10:22:35 +00:00 · 2026-10-26 10:17:40 +00:00
24 changed files with 637 additions and 490 deletions
@@ -1,18 +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.11.1
+version: 1.18.0
 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, discord, documentation-docusaurus-global, glossary-skic, development-durable-wave-execution, development-gates, development-integrity, development-method-ttd, development-branching-strategy, development-monorepo-pnpm, development-scripts, development-gitops-argo-cd-home-gondor-v1, ci-runtime-skic, delivery-docs, status-reporting-skic, development-security, development-security-skic, develop-monorepo-pnpm-app-skic, develop-monorepo-pnpm-package-skic]
 ---

-# Corp v1 Delivery Channel
-
-## Overview
+# SKIC Delivery Channel Reference

 ## Hermes Kanban direct-link contract

@@ -20,77 +18,40 @@ Whenever a response mentions a Hermes Kanban board, initiative, card, or task, i

 ## Canonical Scope Status Vocabulary

-Before reporting or changing any lifecycle status, read the project's current Ways of Working Scope page. Use only the canonical values defined there.
+Before reporting or changing lifecycle status, load [status-and-reporting.md](references/status-and-reporting.md) and read the project's current Ways of Working Scope page. That binding loads `status-reporting-skic` for canonical vocabulary and requested wave format; local Task gates retain gate codes, and `development-integrity` owns checkpoint claims. Delivery claims only an exact `READY_FOR_DELIVERY` Task into `IN_PROGRESS`, without a second Focus admission. `BLOCKED` remains a separate flag; merge/green CI is not `DONE`, and releasable application work normally ends Delivery at `TO_BE_RELEASED`.

-Ideas, Epics, and Features:
-
-```text
-IN_BACKLOG → IN_DESIGN → READY_FOR_DELIVERY → IN_DELIVERY → TO_BE_RELEASED → DONE
-```
-
-Tasks:
-
-```text
-IN_BACKLOG → READY_FOR_DELIVERY → IN_PROGRESS → TO_BE_RELEASED → DONE
-```
-
-`READY_FOR_DELIVERY` is the exact Task's Focus-admitted, pickup-ready state. It means Architecture, dependencies, implementation boundaries, verification steps, and Kanban selection are complete; implementation has not started. Delivery claims that Task by moving it directly to `IN_PROGRESS`. Never require or invent a second Focus-admission decision after `READY_FOR_DELIVERY`.
-
-`CANCELLED` is an exceptional terminal status. `BLOCKED` is a separate flag with a reason and evidence; it never replaces the lifecycle status.
-
-Never invent, abbreviate, or substitute lifecycle values such as `Ready`, `Active`, `Delivered`, `Complete`, `Awaiting CI`, or `Overrun`. Those phrases may describe activity only when clearly separated from the canonical status field. If the canonical status cannot be verified, report `status unverified` and inspect the source record rather than guessing.
-
-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.

-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.
+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 `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.
+Before login or credential-bearing operations, load `development-security-skic` and `development-security`; stop if the authoritative Board policy cannot load. These owners govern the non-secret operation binding and exposure preflight, not new access authority.

-## 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:
-
-```text
-HL_V1_SSO_EMAIL
-HL_V1_SSO_PASSWORD
-```
-
-Secret availability is capability, not authorization. Verify the destination origin and task purpose before login. Never print, inspect, log, hash, serialize, paste, screenshot, or persist either value; never place a value in a command line, URL, file, repository, prompt, Discord message, browser console, test fixture, CI output, or generated artifact. Never ask a human to paste a value into chat. If a variable is unavailable, report only its missing name and request Bitwarden/gateway injection. Login does not authorize account recovery, MFA or credential changes, permission changes, billing, spending, destructive operations, or access outside the approved project task.
-
-## When to Use
-
-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;
- diagnosing build or CI failures;
- checking implementation against requirements and ADRs;
- maintaining delivery-oriented documentation.
-
-Do not use it to silently choose between contradictory requirements or architecture decisions, approve releases, or bypass review and branch protections.
+Before branch or script work, load the generic `development-branching-strategy` / `development-scripts` base alongside the named project overlay; inherit only non-conflicting mechanics.

 ## Development Skill Routing

+Before changing an application's configuration, startup/readiness/shutdown contract or integration boundaries, load `develop-monorepo-pnpm-app-skic`. Before changing a shared package's public API/exports, dependency boundary, version compatibility or published contents, load `develop-monorepo-pnpm-package-skic`. For a change crossing both boundaries, load both and identify producer/consumer responsibilities; do not infer impact solely from a directory name.
+
+These are **draft review aids, not approved standards**. Contributor input and project adoption approval are separate from source publication or this routing. Use them to identify questions and evidence against the Task's already approved contract; do not enforce a proposed convention without the relevant human owner's approval. They complement `development-monorepo-pnpm`, which continues to own workspace/build/package-manager mechanics. Review, CI, one implementation worker per Task, deployment and test-ownership gates remain unchanged; loading a draft grants no execution authority. Authoritative drafts: https://gitea.lego-cloud.eu/skic-skills/develop-monorepo-pnpm-app-skic and https://gitea.lego-cloud.eu/skic-skills/develop-monorepo-pnpm-package-skic.
+
+Before CI/runtime/repair work load `ci-runtime-skic`; before status/blocker reports load `status-reporting-skic`; before documentation load `delivery-docs`; before authenticated operations load `development-security-skic` and `development-security`. Supply the concrete bindings in the matching local reference. Authoritative helper repositories: https://gitea.lego-cloud.eu/skic-skills/ci-runtime-skic, https://gitea.lego-cloud.eu/global-skills/delivery-docs, https://gitea.lego-cloud.eu/skic-skills/status-reporting-skic, https://gitea.lego-cloud.eu/global-skills/development-security and https://gitea.lego-cloud.eu/skic-skills/development-security-skic.
+
 This channel skill owns **delivery governance and project-channel coordination**. Reusable engineering procedures belong to the global `development-*` skills below; load the matching skill before the action and treat a project-adopted variant as the project-specific overlay when one exists.

 | Work | Required reusable skill | Authoritative Gitea source |
 |---|---|---|
-| dependency-wave claim, continuation, recovery, and closure | `development-durable-wave-execution` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-durable-wave-execution |
-| immutable candidate review, exact-head CI, merge, and integration gates | `development-gates` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-gates |
-| delivery, CI, blocker, and completion reporting | `development-integrity` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-integrity |
-| behavior changes, defect fixes, and refactoring | `development-method-ttd` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-method-ttd |
-| branch naming, worktrees, PR topology, and base synchronization | `development-branching-strategy` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-branching-strategy |
-| pnpm/TypeScript monorepo implementation | `development-monorepo-pnpm` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-monorepo-pnpm |
-| Taskfile, `.scripts/`, shell wrappers, environment validation, and Devbox | `development-scripts` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-scripts |
-| Gondor Argo CD template, rendered desired state, and repository connection | `development-gitops-argo-cd-gondor-v1` | https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-gitops-argo-cd-gondor-v1 |
+| dependency-wave claim, continuation, recovery, and closure | `development-durable-wave-execution` | https://gitea.lego-cloud.eu/global-skills/development-durable-wave-execution |
+| immutable candidate review, exact-head CI, merge, and integration gates | `development-gates` | https://gitea.lego-cloud.eu/global-skills/development-gates |
+| delivery, CI, blocker, and completion reporting | `development-integrity` | https://gitea.lego-cloud.eu/global-skills/development-integrity |
+| behavior changes, defect fixes, and refactoring | `development-method-ttd` | https://gitea.lego-cloud.eu/global-skills/development-method-ttd |
+| branch naming, worktrees, PR topology, and base synchronization | `development-branching-strategy` | https://gitea.lego-cloud.eu/global-skills/development-branching-strategy |
+| pnpm/TypeScript monorepo implementation | `development-monorepo-pnpm` | https://gitea.lego-cloud.eu/global-skills/development-monorepo-pnpm |
+| Taskfile, `.scripts/`, shell wrappers, environment validation, and Devbox | `development-scripts` | https://gitea.lego-cloud.eu/global-skills/development-scripts |
+| Gondor Argo CD template, rendered desired state, and repository connection | `development-gitops-argo-cd-home-gondor-v1` | https://gitea.lego-cloud.eu/home-gondor-v1-skills/development-gitops-argo-cd-home-gondor-v1 |

-The channel skill may narrow authority, lifecycle, workspace, visibility, handoff, and evidence requirements. When a project/channel overlay conflicts with a reusable skill on branch naming, human confirmation, worker count, review identity, merge authority, deployment authority, or release authority, the explicit project/channel overlay wins; inherit only the non-conflicting mechanics. It must not restate generic RED–GREEN–REFACTOR mechanics, shell-module layouts, pnpm workspace conventions, ordinary Git branching mechanics, exact-head gate algorithms, or Argo CD authoring procedures. Improve those reusable skills at their linked sources and keep only the project/channel overlay here.
+The channel skill may narrow authority, lifecycle, workspace, visibility, handoff, and evidence requirements. Project bindings must not contradict global skills. The global `development-gates` contract governs independent review, review-before-push ordering, candidate/base identity and CI. Project overlays supply branch naming, human ownership, one implementation worker, visibility and existing merge/deployment/release authority without weakening these gates; inherit only non-conflicting mechanics. It must not restate generic RED–GREEN–REFACTOR mechanics, shell-module layouts, pnpm workspace conventions, ordinary Git branching mechanics, exact-head gate algorithms, or Argo CD authoring procedures. Improve those reusable skills at their linked sources and keep only the project/channel overlay here.

 ## Implementation Entry Gate

@@ -112,22 +73,21 @@ Load `development-durable-wave-execution`, `development-branching-strategy`, and

 The Corp v1 overlay is narrower: every Task requires a dedicated visible branch and PR before substantive coding, and that PR must carry the Task ID, wave, planned scope, current state, exact head, and governed `test` base. If Gitea requires a delta, use an empty kickoff commit rather than a filler file. Read the branch and PR back before editing. One Task maps to one branch and PR unless Architecture or the human owner explicitly approves another topology.

-## 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.

 ## 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.
@@ -140,82 +100,21 @@ 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 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/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, 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
-
-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.
- 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.
- 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.
- 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
-
-CI jobs and developer workstations must not provision databases, queues, object stores, caches, brokers, or other application runtime services. When implementation or validation needs such a resource, provision it under the owning application on the approved shared runtime platform through that project's GitOps repository, then consume it through a governed application or test interface.
-
- Keep every non-production 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. Prefer a narrowly governed in-platform Job/Workflow trigger so a private resource does not need public, NodePort, or runner-network exposure.
- Persistent storage must follow the project's named platform storage operations skill; load that skill before designing or mutating storage. If the project instead names an approved storage procedure, read that exact procedure and verify its current provenance before acting. If neither an approved skill nor an approved procedure is identified, stop and route the missing decision to Architecture/platform operations; do not infer a provider or provisioning method. Never accept a dynamically provisioned volume whose reclaim policy can delete durable data when the PVC is removed.
- Secrets come from the approved external secret store; never commit connection strings or credentials.
- Provision and verify required runtime resources before treating dependent application work as deployable. Missing infrastructure blocks deployment, not safe code-only work whose tests do not require that resource.
+Before base-image work, load `ci-runtime-skic` and [the project image binding](references/runtime-and-ci.md#per-project-reusable-ci-base-images).

 ## Failure-Repair Workflow

-When a build or CI failure is observed:
+Load [failure-and-documentation.md](references/failure-and-documentation.md#failure-repair-workflow) when a build or CI failure is observed. It binds `ci-runtime-skic` for safe repair and `status-reporting-skic` for blocker routing, with existing gate owners for exact-head verification. Keep repairable failures in the same Task/gate; pause only for the documented external, authority, decision or safety blocker. Never guess requirements or Architecture, weaken a gate or treat a blocker as passing.

-1. verify repository, branch, head SHA, failed job, and exact logs;
-2. reproduce locally when feasible;
-3. determine root cause before editing;
-4. compare the intended fix against approved FR/NFRs, ADRs, architecture documentation, and project conventions;
-5. implement the smallest safe fix;
-6. add/update tests where behavior changed;
-7. run local validation;
-8. commit and push through the approved branch workflow;
-9. inspect CI for the exact new head SHA;
-10. report evidence and remaining risk.
-
-The skill may attempt a safe fix when the failure and expected behavior are clear. If evidence is insufficient or requirements/architecture conflict, stop and raise the issue in the relevant channel:
-
- requirement/product ambiguity → `general` and/or `architecture` as appropriate;
- architecture contradiction → `architecture`;
- release policy/readiness ambiguity → `releases`;
- implementation-only blocker → `delivery`.
-
-Never guess the team's intended direction.
-
-## Documentation Ownership
-
-Maintain two documentation areas.
-
-### Ways of Working — five sections
-
-1. **Delivery workflow** — intake, prioritization, implementation states, and definition of done.
-2. **Branching and reviews** — branch conventions, pull requests, approvals, and merge expectations.
-3. **Planning and ownership** — backlog, sequencing, owners, dependencies, blockers, and escalation.
-4. **Quality practices** — review standards, test strategy, defect handling, and evidence expectations.
-5. **Collaboration and decisions** — channel routing, handoffs, decision references, and communication norms.
-
-### 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.
-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.
-
-Update these pages from verified project practice. Do not document a planned process as already operational.
+Before changing Ways of Working or Engineering, load `delivery-docs` and [the concrete documentation bindings](references/failure-and-documentation.md#documentation-ownership).

 ## UI/UX Coordination

@@ -233,13 +132,15 @@ For frontend-affecting work, Delivery requires the approved UI/UX design package
 8. Maintain Ways of Working and Engineering pages when durable practice changed.
 9. Post a concise update with work completed, evidence, blockers, and required decisions.

+Do not silently choose between contradictory requirements or Architecture decisions, approve releases, or bypass review/branch protections.
+
 ## Authority and Escalation

 May autonomously:

- run tests/builds/read-only checks;
+- 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 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.

@@ -258,54 +159,29 @@ 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.

-## Project-Adoption Delivery Lessons
+## Decision-point references

-Use the exact Task-file state. The canonical progression is `IN_BACKLOG → READY_FOR_DELIVERY → IN_PROGRESS → TO_BE_RELEASED → DONE`; `BLOCKED` is a separate reasoned flag, and neither merge nor green CI means `DONE`. A Task already in `READY_FOR_DELIVERY` is Focus-admitted and pickup-ready; Delivery claims it by moving directly to `IN_PROGRESS` without inventing a second admission gate.
+Before selecting/continuing/reviewing/merging/handoff load [Task gates](references/task-delivery-gates.md); before branch/PR work load [repository entry](references/repository-entry-and-visibility.md). Before commands, CI, images or resource work load [runtime bindings](references/runtime-and-ci.md); before failure repair/docs load [failure/docs bindings](references/failure-and-documentation.md). Before planning changes load [planning reconciliation](references/planning-artifact-reconciliation.md); on failed/resumed gates load [exception checks](references/common-pitfalls.md).

-Keep exactly one Task active unless the adopted project authority explicitly defines another safe model. Establish a visible branch and PR before implementation, freeze Task/branch/PR identity, verify every review against the exact candidate head, and end Delivery ownership at `TO_BE_RELEASED`. Failed gates remain active and are repaired forward until they pass or a genuine external, authority, decision, or safety blocker is evidenced.
+Project adoptions may narrow implementation execution to a main session or prohibit implementation subagents/cron. Preserve that overlay without prohibiting independent read-only review; this reference grants no account recovery, permission, merge, release or deployment authority. Keep exactly one Task active unless explicit project authority defines another safe model. Freeze Task/branch/PR identity and retain exact-head review under the ordered gates.

-Load the matching detailed reference at the decision point—not from memory:
+When selectable controls are needed, provide complete options and their trade-offs, recommended first; follow the active interface's option-rendering contract without hiding consequences.

- Task selection, execution, review, merge, and handoff: [references/task-delivery-gates.md](references/task-delivery-gates.md)
- Status, wave, blocker, CI, and completion wording: [references/status-and-reporting.md](references/status-and-reporting.md)
- Workspace, branch, PR, and visibility entry: [references/repository-entry-and-visibility.md](references/repository-entry-and-visibility.md)
- Toolchain contexts, CI, images, and runtime placement: [references/runtime-and-ci.md](references/runtime-and-ci.md)
- Failure repair and Delivery-owned documentation: [references/failure-and-documentation.md](references/failure-and-documentation.md)
- Planning-artifact reconciliation: [references/planning-artifact-reconciliation.md](references/planning-artifact-reconciliation.md)
- Gate failures, resumptions, blockers, merge, and completion: [references/common-pitfalls.md](references/common-pitfalls.md)

-Project adoptions may narrow execution to a named main session or prohibit subagents/cron. Preserve that project-local authority overlay; the central reference does not grant account recovery, permission changes, merge, release, or deployment authority.

-When selectable controls are needed, explain every complete option and its trade-offs in prose first, then use short `Option A`, `Option B`, and so on labels in the control. Put the recommended option first and keep button labels free of hidden consequences.
+Before final Delivery handoff, load [final verification](references/final-verification.md) and check the retained evidence against the ordered Task gates; do not repeat the checklist here.

-## Common Pitfalls
+## Canonical naming and compatibility

-1. Patching symptoms before understanding root cause.
-2. Changing requirements or architecture implicitly through code.
-3. Claiming CI success from a local build.
-4. Editing without loading applicable project engineering skills.
-5. Skipping tests for behavioral fixes.
-6. Updating documentation with aspirational rather than actual practice.
-7. Repeatedly posting unchanged failure summaries.
-8. Inspecting another project.
-9. Starting implementation because requirements exist but human implementation approval is absent.
-10. Ignoring architecture task dependencies, Kanban Focus admission, or target-version allocation.
-11. Posting passive status when safe implementation, testing, diagnosis, or documentation work is available.
-
-## Verification Checklist
-
- [ ] Only same-project channels and repositories were used.
- [ ] Work maps to approved requirements/architecture.
- [ ] Feature has explicit human `Approved for Implementation` evidence and a documented target version.
- [ ] Selected tasks respect documented dependencies and carry exact Task `READY_FOR_DELIVERY` evidence.
- [ ] At least one useful delivery activity was completed, or a concrete blocker was documented and routed.
- [ ] Applicable project skills were loaded.
- [ ] Tests and builds were actually run.
- [ ] Remote branch and matching CI head SHA were verified.
- [ ] Contradictions were escalated, not guessed through.
- [ ] Ways of Working and Engineering documentation remains accurate.
- [ ] Completed work includes exact evidence.
+- 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>`.
@@ -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.
@@ -1,26 +1,5 @@
-# the adopted project Delivery Pitfalls
+# Delivery exception checks

-Load this reference when a gate fails, when work resumes after interruption, or before reporting a blocker, CI result, merge, or completion.
+On failed gates or resumption, load [Task gates](task-delivery-gates.md) and [planning reconciliation](planning-artifact-reconciliation.md) to verify original admission, current claim and visibility; merged planning text is not implementation approval.

-## Common Pitfalls
-
-1. Patching symptoms before understanding root cause.
-2. Changing requirements or architecture implicitly through code.
-3. Claiming CI success from a local build.
-4. Editing without loading applicable project engineering skills.
-5. Skipping tests for behavioral fixes.
-6. Updating documentation with aspirational rather than actual practice.
-7. Repeatedly posting unchanged failure summaries.
-8. Inspecting another project.
-9. Starting implementation because requirements exist but human implementation approval is absent.
-10. Ignoring architecture task dependencies, the Task's `READY_FOR_DELIVERY` handoff, or target-version allocation.
-11. Posting passive status when safe implementation, testing, diagnosis, or documentation work is available.
-12. Treating a human-merged planning or Architecture documentation PR as implementation approval.
-13. Treating an ideation-board entry, generated presentation, or broad approval as equivalent to an exact Task `READY_FOR_DELIVERY` transition—or requiring a second admission after that verified transition.
-14. Validating a stale channel-reported SHA instead of freshly resolving and checking the current remote merge head.
-15. Continuing to report or validate an open PR head after the PR merged during the run; re-resolve the merge/default-branch SHA and require local validation plus CI for that exact merge commit.
-16. Reposting an unchanged gate summary when no new decision, head, CI result, failure, or durable artifact exists.
-17. Editing in a local-only worktree or on a differently named local branch before the exact remote branch and PR head are visible and verified.
-18. Starting `pnpm`, tests, or a background worker before checking the toolchain and required environment inside that exact execution context.
-19. Reporting only “failed” or leading with hashes instead of the linked branch/PR and the exact failed command, file, test, or CI job.
-20. Stopping at a repairable gate failure, abandoning the active Task, or starting another Task instead of fixing forward and rerunning the gate until it passes.
+Load `ci-runtime-skic` before command/repair work, `delivery-docs` before recording operational practice, and `status-reporting-skic` before blocker or completion wording. These owners carry their topic pitfalls once; do not repeat them here.
@@ -1,64 +1,13 @@
-# the adopted project Failure and Documentation Operations
-
-Load this reference when repairing a failure or changing Delivery-owned project documentation.
+# Project failure and documentation bindings

 ## Failure-Repair Workflow

-When a build or CI failure is observed:
-
-1. verify repository, linked branch and PR, exact failed command/file/test/job, failure class, and exact logs;
-2. reproduce locally when feasible;
-3. determine root cause before editing;
-4. compare the intended fix against approved FR/NFRs, ADRs, architecture documentation, and project conventions;
-5. implement the smallest safe fix;
-6. add/update tests where behavior changed;
-7. run local validation;
-8. commit and push through the approved branch workflow;
-9. inspect CI for the exact new head SHA;
-10. report evidence and remaining risk;
-11. repeat diagnosis, repair, and affected validation until the active gate passes.
-
-The skill must continue with a safe forward fix when the failure and expected behavior are clear. A repairable failure does not end the Task or authorize moving to another gate or Task. If evidence is insufficient, requirements/architecture conflict, an external dependency is unavailable, or the required action exceeds authority, keep the Task in the same gate, record the separate blocker with evidence and owner, and raise the issue in the relevant channel:
-
- requirement/product ambiguity → `general` and/or `architecture` as appropriate;
- architecture contradiction → `architecture`;
- release policy/readiness ambiguity → `releases`;
- implementation-only blocker → `delivery`.
-
-Never guess the team's intended direction, weaken a gate, or treat a blocker as a passed gate. Resume the same gate and continue the repair loop when the blocker is removed.
+Before diagnosis or forward repair, load `ci-runtime-skic` for the same-gate repair loop and [Unit testing](runtime-and-ci.md#unit-testing) for local TTD/exception authority. Before blocker communication, load `status-reporting-skic` for the evidence packet and owner routing. Keep the selected Task/gate; never weaken requirements to pass it.

 ## Documentation Ownership

-Maintain two documentation areas.
-
-### Ways of Working — five sections
-
-1. **Delivery workflow** — intake, prioritization, implementation states, and definition of done.
-2. **Branching and reviews** — branch conventions, pull requests, approvals, and merge expectations.
-3. **Planning and ownership** — backlog, sequencing, owners, dependencies, blockers, and escalation.
-4. **Quality practices** — review standards, test strategy, defect handling, and evidence expectations.
-5. **Collaboration and decisions** — channel routing, handoffs, decision references, and communication norms.
-
-### 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.
-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.
-
-Update these pages from verified project practice. Do not document a planned process as already operational.
+Before changing Delivery-owned Ways of Working or Engineering, load `delivery-docs` for coverage and evidence-to-page reconciliation. Bind the authoring owner to `documentation-docusaurus-global` at https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus, plus the project-adopted overlay. Before defining reusable terms, bind/load `glossary-skic` at https://gitea.lego-cloud.eu/home-v1-skills-code-agent/glossary-skic. Stop if the source-qualified owner is unavailable; an unrelated same-name runtime skill is not that owner.

 ## Synchronization Workflow

-When planning documentation, Architecture structure, or Kanban state changes while implementation remains gated, follow [`planning-artifact-reconciliation.md`](planning-artifact-reconciliation.md). It defines fresh remote-head discovery, exact-merge-SHA validation, `READY_FOR_DELIVERY` handoff interpretation, evidence boundaries, and duplicate-status suppression.
-
-1. Read new same-project activity and enough delivery history to avoid duplicates.
-2. Before claiming new task work, verify exact-item `Approved for Implementation` evidence, exact Task `READY_FOR_DELIVERY` state, task dependencies, approved UI/UX handoff when applicable, and target version.
-3. Identify executable tasks, CI failures, blockers, requirements/ADR implications, and documentation drift.
-4. Load all applicable project engineering skills.
-5. Complete at least one useful safe activity when an authorized path exists; otherwise document and route the exact blocker.
-6. Escalate uncertainty or contradiction rather than selecting direction.
-7. Verify local and remote results and update task/Feature progress in project documentation.
-8. Maintain Ways of Working and Engineering pages when durable practice changed.
-9. Post a concise update with work completed, evidence, blockers, and required decisions.
+Before reconciling planning/Architecture/Kanban changes load [planning-artifact-reconciliation.md](planning-artifact-reconciliation.md); follow the entry skill's single synchronization workflow for useful safe work and domain-owner loads.
@@ -0,0 +1,16 @@
+# Final Delivery verification
+
+- [ ] Only same-project channels and repositories were used.
+- [ ] Work maps to approved requirements/architecture.
+- [ ] Feature has explicit human `Approved for Implementation` evidence and a documented target version.
+- [ ] Selected tasks respect documented dependencies and carry exact Task `READY_FOR_DELIVERY` evidence.
+- [ ] At least one useful delivery activity was completed, or a concrete blocker was documented and routed.
+- [ ] Applicable project skills were loaded.
+- [ ] Tests and builds were actually run.
+- [ ] Remote branch and matching CI head SHA were verified.
+- [ ] Contradictions were escalated, not guessed through.
+- [ ] Ways of Working and Engineering documentation remains accurate.
+- [ ] Completed work includes exact evidence.
+
+
+Apply this evidence checklist before a final Delivery handoff. It checks the existing gates; it grants no new authority and is not another implementation stage.
@@ -1,27 +1,27 @@
 # Planning-artifact reconciliation

-Use this procedure when Scope, Architecture, Kanban, Ways of Working, Engineering, or release-readiness documentation changes while Feature implementation remains gated.
+Use when planning or readiness documentation changes while implementation remains gated.

-## Procedure
+## Verification owners — load at the decision point

-1. Read the latest same-project channel activity and identify human actions separately from Hermes-authored status reports.
-2. Re-fetch the documentation repository and resolve the current remote default/test head. Do not reuse a SHA from an earlier channel report.
-3. Read back relevant pull requests and distinguish `open`, `closed`, and `merged`; a human merge is evidence that documentation landed, not evidence that a Feature changed lifecycle state.
-4. Resolve the current source ref and full head SHA from the fresh PR API response before fetching. Do not infer the branch name from a PR title, an older checkout, a prior report, or a similarly named local branch. Fetch that exact `head.ref` into an unambiguous temporary remote-tracking ref, create a clean detached worktree from it, and assert `git rev-parse HEAD` equals the API-reported full SHA before validation.
-5. Validate the exact head in that clean or detached worktree using the repository's own validation command. Explicitly execute package-manager commands with the worktree as the process working directory (or begin the shell block with `cd "$worktree"`); setting up the worktree in an earlier command does not make it the current directory for a later process. Install dependencies with the repository's declared frozen-lockfile command when the clean worktree has no installed dependencies. If the package manager shim is unavailable, use the repository-declared package-manager launcher rather than changing project files. Before running a composite package script, verify that child scripts can resolve the package-manager executable too: `corepack pnpm validate` can start successfully yet fail when `validate` invokes nested `pnpm ...` commands. In that case, create a writable temporary shim directory with `corepack enable --install-directory <cache>/pnpm-bin`, prepend it to `PATH`, and run the declared command (for example, `PATH=<cache>/pnpm-bin:$PATH pnpm validate`). Keep the shim and dependency cache outside committed content, run `git diff --check`, and confirm the worktree remains clean afterward.
-6. Query Gitea Actions tasks and match the full exact head SHA. Require each matching task to report `success`; do not transfer a PR-head result to the eventual merge head. Keep Gitea identifiers distinct: the Actions task API `id`, its `run_number`, and any UI run URL/ID are separate fields and may not have the same value. Report the exact field actually returned by the verified endpoint (for example, `task id 684, run_number 66`) rather than relabeling a channel-reported UI run ID as a task ID.
-7. Read back the changed planning artifacts through the authenticated raw-file API at the exact PR source ref and verify their **semantics**, not merely keyword presence. Headings and lifecycle guidance naturally contain terms such as `READY_FOR_DELIVERY`, so keyword presence alone does not prove a Task is pickup-ready. For Kanban, assert the exact Task row and status, the evidence timestamp, and any newly cited head/task pairs; also assert superseded pairs are absent when the change claims reconciliation. Parse each lifecycle section independently and verify the Task's actual row rather than using loose whole-file heuristics such as a state-name count. If an automated semantic probe disagrees with the rendered Markdown, read the relevant numbered lines and correct the probe before reporting.
-8. Immediately before reporting, re-fetch the PR, its remote source ref, the default branch, and exact-SHA tasks. Scheduled writers or human reviewers can change repository state during local validation.
-   - If the open PR source head advanced, treat the completed source-head check as stale and validate the new source head.
-   - If the PR merged or closed during validation, stop describing it as open. Fetch the freshly resolved merge/default-branch SHA, create or switch to a clean detached worktree at that exact commit, rerun the repository's declared validation and semantic probes there, and require a successful Actions task whose full `head_sha` equals the merge commit. PR-head CI must not be transferred to the merge head.
-   - Re-fetch once more after merge-head validation and assert the PR state, default-branch SHA, local validated SHA, and latest exact-SHA terminal task still agree. If another Delivery report already covers that identical evidence, remain silent.
-9. Reconcile Kanban separately:
-   - Proposed Epics/Features may appear in an ideation view.
-   - An exact Task is Focus-admitted and pickup-ready when its status is `READY_FOR_DELIVERY`; there is no second Focus-admission gate.
-   - A newly added Kanban page or merged board does not itself move an exact Task to `READY_FOR_DELIVERY`.
-10. Re-evaluate every implementation gate from the source files and approvals: Approved for Implementation, FR/NFR and ADR context, task/dependency plan, target version, acceptance evidence, and exact Task `READY_FOR_DELIVERY` state.
-11. If the gate remains closed, do not create application changes. A useful delivery activity can be exact-head build/CI verification, durable documentation reconciliation, or a newly evidenced blocker report.
-12. Report only deltas not already covered by the latest delivery message. Include repository, branch, full SHA, local commands/results, exact-SHA task IDs, and the specific missing gate.
+Before verifying a PR or CI, run `skill_view(name="development-gates")` and load its `references/review-ci-merge-contract.md`: **Evidence model**, **Attempt integrity**, and **Concurrent publication** own candidate/remote equality, complete successful job inventory including aggregates, and separate integration evidence. Do not use a successful listed-task subset as a gate.
+
+Before reporting, load `skill_view(name="development-integrity")` and its `references/remote-checkpoint-matrix.md` for the current remote checkpoint, changed-head invalidation and candidate-versus-integration claims; then load [status-and-reporting.md](status-and-reporting.md) for Delivery formatting. Preserve project merge authority; A02/A04 follow global independent review-before-push and any-target-base-change invalidation without local exceptions.
+
+Before validation, load `documentation-docusaurus-global` and the project-adopted overlay through [Documentation Ownership](failure-and-documentation.md#documentation-ownership); verify source identity. Run the complete repository validator and production build with frozen-lockfile installation and `git diff --check`. Generic and VSSA packages now have separate source-qualified names. Retain the bounded nested-pnpm fallback below until that procedure is present in the generic owner; identity repair alone does not establish procedural coverage.
+
+If child scripts cannot find pnpm, use `corepack enable --install-directory <cache>/pnpm-bin`, prepend that temporary shim directory to `PATH`, and rerun the declared command. Keep shim/dependency caches outside commits and verify the worktree remains clean.
+
+## Retained validation bindings
+
+- Use the fresh PR API `head.ref` and full SHA, never a title or old report, for a clean detached worktree inside the Task boundary. Assert its actual HEAD and process working directory before repository-native validation. These exact-worktree checks remain local until the installed owner carries them.
+- If the PR merged or closed during validation, update its reported state and validate the freshly resolved merge/default head, including semantic probes. Use the owners above for fresh evidence immediately before reporting; repeat if it changes. Keep API task `id`, `run_number`, run/attempt/job IDs and UI URLs distinct in retained evidence.
+
+## Delivery interpretation
+
+Read current same-project activity and distinguish human decisions from agent reports. Verify changed artifacts by authenticated readback at the validated revision and inspect their **semantics**: the exact Task row and status, evidence timestamp, new head/task pairs and absence of superseded pairs when reconciliation claims their removal. Parse lifecycle sections separately; headings, keyword counts and generated presentations are not Task-state evidence. If a probe disagrees with rendered Markdown, inspect numbered lines and correct the probe before reporting.
+
+New pickup requires current `READY_FOR_DELIVERY`, dependencies, target version, parent Feature implementation approval and FR/NFR/ADR/UI/UX readiness under the preserved project authority. That status already records admission: no second Focus-admission decision. Continuation instead requires current `IN_PROGRESS`, its existing claim and historical verified admission; do not demand re-admission or mistake historical portfolio status for current Task authority. A merged Board page does not itself admit a Task. If the gate remains closed, do not create application changes; verify or reconcile documentation or route the evidenced blocker instead.

 ## Evidence interpretation

@@ -35,4 +35,4 @@ Use this procedure when Scope, Architecture, Kanban, Ways of Working, Engineerin

 ## Avoid duplicate status

-Before posting, compare the proposed report with enough Delivery history to find the newest marker, head SHA, CI task, and blocker set. If there is no new human decision, repository head, CI result, actionable failure, or durable documentation change, return the configured silent response instead of restating the same gate.
+Before posting, compare the proposed report with enough Delivery history to find the newest marker, head SHA, CI task, and blocker set. If there is no new human decision, repository head, CI result, actionable failure, or durable documentation change, return the configured silent response instead of restating the same gate.
@@ -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

@@ -23,6 +23,8 @@ Delivery must verify the Feature decision and exact Task `READY_FOR_DELIVERY` st

 Before any implementation or repository content change begins on a newly claimed the adopted project Task, establish and verify all of these Gitea checkpoints:

+Visibility-only kickoff commits contain no file/tree changes. This exception does not authorize a substantive push: freeze and independently review every implementation or documentation candidate before publication.
+
 1. Create the dedicated local branch with the required Task branch name, create an empty kickoff commit if needed, and push that exact branch immediately.
 2. Open a visible pull request from that exact branch to `test` before editing a repository file. Do not wait for implementation, tests, review, or a finished diff.
 3. Put the Task ID, wave, planned scope, and current Task state in the PR so the active project authority and the team can monitor progress from the beginning.
@@ -1,113 +1,35 @@
-# the adopted project Runtime and CI
+# Project runtime bindings

-Load this reference before login, toolchain execution, CI work, image publication, or Gondor resource work.
+Before commands, CI changes, image publication, resource work or repair, load `ci-runtime-skic` and follow its full procedure with these bindings. Before login or credential-bearing operations, load `development-security-skic` and `development-security`; Board policy remains authoritative. Stop the affected action when an owner cannot load.

 ## Channel-owned workspace

-Resolve the channel root as `corp-v1-<code>-delivery/` under the active user's working root:
-
-```text
-corp-v1-<code>-delivery/
-├── cache/                 # reusable channel toolchains and technical dependencies
-├── uploads/
-└── workspace/
-    └── <TASK_ID>/
-        ├── application/       # always: repository clone
-        ├── documentation/     # always: repository clone
-        ├── review/            # optional: only when separate review files are needed
-        ├── cache/             # optional: only when a Task-specific cache is needed
-        ├── tmp/               # optional: only when temporary Task files are needed
-        ├── logs/              # optional: only when logs must be retained
-        └── 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.
- `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.
- Do not create Task-local `review/`, `cache/`, `tmp/`, `logs/`, or `artifacts/` speculatively. Create each folder only when a concrete activity for that Task needs it.
- Use Task-local `review/` only for a separate review checkout or review output. Use Task-local `cache/` only for non-reusable data bound to that Task; reusable installed technical dependencies belong in the channel-level `cache/`. Use `tmp/`, `logs/`, and `artifacts/` only for their named Task-local purpose.
- Run dependency installation, generation, tests, and builds inside the applicable repository clone using that repository's normal paths. Copy or export outputs to `artifacts/` only when they must be retained separately.
- Keep every optional folder inside the selected Task directory. Never share it between Tasks or place it at the channel root.
- Before every local repository command, resolve the real working directory and require it to be inside the selected Task directory. A command running elsewhere is invalid evidence and must stop before mutation.
- Do not reuse another Task's clone or support folder as a shortcut. Resume only from the selected Task's own workspace after fetching and matching its visible PR head.
-
-## 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:
-
-```text
-HL_V1_SSO_EMAIL
-HL_V1_SSO_PASSWORD
-```
-
-Secret availability is capability, not authorization. Verify the destination origin and task purpose before login. Never print, inspect, log, hash, serialize, paste, screenshot, or persist either value; never place a value in a command line, URL, file, repository, prompt, Discord message, browser console, test fixture, CI output, or generated artifact. Never ask a human to paste a value into chat. If a variable is unavailable, report only its missing name and request Bitwarden/gateway injection. Login does not authorize account recovery, MFA or credential changes, permission changes, billing, spending, destructive operations, or access outside the approved project task.
-
+Bind the project channel root under the active working root, Task `workspace/<TASK_ID>/`, reusable `cache/` and channel-provided `uploads/`. The shared owner defines cache contents, optional folders, real-CWD containment and exact-context preflight; this binding does not authorize execution outside the selected Task.

 ## Delivery Responsibilities

 ### Coding

- implement only human-approved Features and their authorized tasks;
- load applicable project engineering skills before changing code;
- preserve project structure, conventions, and environment namespace;
- keep changes small, reviewable, and traceable to requirements/issues;
- avoid unrelated refactors during failure repair;
- never fabricate command, test, CI, or deployment results.
+Load `development-monorepo-pnpm` for pnpm/TypeScript implementation and `development-scripts` for Taskfile, shell, environment and Devbox work, using their [source links and project-overlay precedence](../SKILL.md#development-skill-routing). Preserve project structure/namespace; implement only approved Features and authorized Tasks with small, traceable changes, no unrelated refactors and no fabricated results.
+

 ### Unit testing

- add or update tests with behavioral changes;
- reproduce defects before fixing when practical;
- cover normal, edge, and failure cases proportional to risk;
- run the narrowest relevant tests first, then required broader validation;
- record exact commands and real results.
+Load `development-method-ttd` before every behavior change, defect fix or refactor. Follow its mandatory failing-test-first unit workflow and retain real commands/results; request non-unit coverage from UAT. Exceptions require the authorized project owner explicitly approving a documented exception. Discard/start-over applies only to the executor's isolated, unpublished experimental delta, preserving unrelated or valid work. Never rewrite shared history, delete another worker's changes or revert integrated work. Repair shared/integrated code forward, record historical missing RED honestly and never claim retrospective tests proved test-first compliance; seek the named project-authority exception if compliant repair cannot satisfy the gate.
+

 ### Build and continuous integration

-Monitor local builds and Gitea Actions for:
-
- compile/type failures;
- unit/integration test failures;
- lint/format failures;
- dependency, packaging, container, or chart failures;
- workflow/configuration defects;
- missing or stale artifacts;
- branch/head-SHA mismatch.
-
-A green local build is not proof that CI or delivery succeeded. Verify the actual remote branch and matching CI task/run.
+Load `ci-runtime-skic`, `development-gates` and `development-integrity`; preserve the required job inventory and local gate order in [Task gates](task-delivery-gates.md). Before Actions or publication load `devsecops-ci-cd-gitea` and the bound project overlay.

 ### Execution-context toolchain preflight

-Treat every foreground shell, detached worktree, background process, Hermes main-session review command, and CI job as a separate execution context. Before any repository command or operation runs in an execution context, complete the applicable preflight for that exact context. For a Node/pnpm repository—or any command that may invoke Node or pnpm—the following checks are mandatory:
-
-1. resolve the repository-required Node and pnpm versions from its committed toolchain contract;
-2. run `command -v node`, `node --version`, `command -v pnpm`, and `pnpm --version` inside the exact context, then compare the observed versions with the committed required versions;
-3. verify required non-secret environment variable names are present, including disposable-test database markers when applicable, without reading or printing their values;
-4. verify the actual working directory, linked branch/PR identity, and clean or intentionally staged repository state; and
-5. start the repository command only after every applicable preflight check passes.
-
-Never assume a background process inherits `PATH`, shell activation, Devbox state, Corepack activation, database variables, or other exports from a foreground terminal. A missing `pnpm` executable is always an execution-context/toolchain failure, never an application-code or test failure. Repair the exact context by providing the required toolchain path or activation, repeat the complete preflight there, and rerun the original command before making any claim about repository code.
+Before each foreground/background/worktree/worker/review/CI command, load `ci-runtime-skic` and its exact-context preflight, including `development-scripts` → `references/runtime-preflight.md` and `development-monorepo-pnpm` → `references/workspace-and-tooling.md`. Supply the selected Task/repository, branch/PR/revision, allowed scope and `CORP_V1_<CODE>_*` non-secret environment names. Load `development-scripts` for the repository overlay.

 ### Per-project reusable CI base images

-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.
- 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.
- 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.
- 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.
+Bind `corp-v1-<code>/corp-v1-<code>-base-images`, trusted publication branch `test`. Before image work load `ci-runtime-skic` for digest consumption and forward-repair safeguards and its required `devsecops-ci-cd-gitea` reference loads.

 ### Gondor runtime-resource placement

-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.
- 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.
+Before resource/storage work load `ci-runtime-skic` for isolation, secret-store, retained-storage and selected GitOps owner/fallback procedures. Bind the approved template and separate desired-state repository for each environment. Only the project-approved non-production environment is within Delivery authority; missing storage/platform authorization blocks mutation.
@@ -1,81 +1,5 @@
-# the adopted project Status and Reporting
+# Project reporting bindings

-Load this reference when reading Task states or reporting Task, wave, CI, blocker, or completion status.
+Before Task/wave/CI/blocker/completion reports or lifecycle changes, load `status-reporting-skic` and `development-integrity` (including `references/remote-checkpoint-matrix.md`). The shared reporter owns vocabulary and templates; the current project Scope record remains authoritative.

-## Scope Status Vocabulary
-
-Before reporting or changing any lifecycle status, read the project's current `ways-of-working/scope.md`. Use only the values defined there.
-
-Ideas, Epics, and Features:
-
-```text
-IN_BACKLOG → IN_DESIGN → READY_FOR_DELIVERY → IN_DELIVERY → TO_BE_RELEASED → DONE
-```
-
-Tasks:
-
-```text
-IN_BACKLOG → READY_FOR_DELIVERY → IN_PROGRESS → TO_BE_RELEASED → DONE
-```
-
-`READY_FOR_DELIVERY` is the exact Task's Focus-admitted, pickup-ready state. It means Architecture, dependencies, implementation boundaries, verification steps, and Kanban selection are complete; implementation has not started. Delivery claims that Task by moving it directly to `IN_PROGRESS`. Never require or invent a second Focus-admission decision after `READY_FOR_DELIVERY`.
-
-`CANCELLED` is an exceptional terminal status. `BLOCKED` is a separate flag with a reason and evidence; it never replaces the lifecycle status.
-
-Never invent, abbreviate, or substitute lifecycle values such as `Ready`, `Active`, `Delivered`, `Complete`, `Awaiting CI`, or `Overrun`. Those phrases may describe activity only when clearly separated from the status field. If the status cannot be verified, report `status unverified` and inspect the source record rather than guessing.
-
-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 value even when a separate plain-language action is also included.
-
-## Wave Status Report
-
-When the active project authority explicitly asks for project, delivery, blocker, progress, or wave status, begin the status report with this exact first-line structure, with no text before it:
-
-```text
-wave-previous: <previous wave> | wave-current: <current wave> | wave-next: <next wave>
-```
-
-Each value must be an actual dependency-wave label calculated by the the adopted project Release Task Board, such as `Wave 11`, `Wave 12`, or `Wave 13`. Never substitute activities, work descriptions, statuses, invented phases, or ad hoc labels. Resolve the current wave and its adjacent existing waves from the Board selector and task assignments; do not infer them from conversation wording. Use `none` only when the Board has no previous or next wave.
-
-Do not repeat the wave header or task chapter in ordinary acknowledgements, implementation narration, questions, or non-status replies. Use them only when the active project authority explicitly asks for status.
-
-### Current-wave task chapter
-
-Immediately after the header in a requested status report, include:
-
-```text
-## Wave XX (Current)
-
- TASK-XXXX — <status> — Responsible: <Hermes main session or concrete owning process>
-```
-
-Replace `XX` with the current Board wave number. List every Task assigned to that wave—never a sample or only changed Tasks—and use each Task's verified flow status. For responsibility, name Hermes main session when it actively owns the Task; otherwise name the concrete owning process, such as Delivery pickup, implementation/review, integration, or Release handoff. When no active executor or owning process exists, say `Unassigned`; never invent an agent, process, or ownership. Refresh the Board/task records and live process state before reporting when they may have changed.
-
-### Human-facing delivery updates
-
-In every implementation, review, CI, blocker, merge, handoff, or completion update, lead with the linked branch and pull request where the work is visible. The next line must identify the Task, exact Task status, active gate code, and gate title:
-
-```text
-<TASK_ID> | <TASK_STATUS> | <GATE_CODE> — <GATE_TITLE>
-```
-
-Example:
-
-```text
-TASK-0084 | IN_PROGRESS | GATE_003_TASK_IMPLEMENTATION — Implement and Review the Task
-```
-
-While work remains inside a gate, continue reporting that same code. When its exit gate passes, report the transition explicitly:
-
-```text
-GATE_003_TASK_IMPLEMENTATION passed → GATE_004_TASK_PR_CI
-```
-
-When blocked, name the gate where progress stopped:
-
-```text
-BLOCKED at GATE_004_TASK_PR_CI — Verify and Merge the Task PR
-```
-
-Do not invent a separate phase or shorthand. Do not lead with or routinely include commit SHAs, tree hashes, digests, internal worktree paths, or temporary review-commit identities; retain those for automated verification and provide them only when the active project authority asks for audit detail or when an identity mismatch itself is the blocker.
-
-When anything fails, identify the exact failed command, file, test, or CI job. State its failure classification—application code, test assertion, workflow, infrastructure, credentials, or local execution environment—then provide the expected behavior and observed behavior, whether repository or remote state changed, and the concrete repair or owner. Never summarize a failure as only “validation failed”, “review failed”, or “CI failed”.
+Bind the active project status-request authority, actual Release Task Board selector, Scope record and release owner before reporting. Missing records mean status unverified. No report changes admission, release authority or scheduler policy.
@@ -1,6 +1,11 @@
 # the adopted project Task Delivery Gates

-This file contains the complete ordered procedure for delivering one the adopted project Task. Load it before selecting or continuing a Task.
+This file contains the ordered Delivery overlay for delivering one the adopted project Task. Load it before selecting or continuing a Task.
+
+
+Before candidate review, CI, merge or integration verification, run `skill_view(name="development-gates")` and load `references/review-ci-merge-contract.md`. Its Evidence model and Attempt integrity own immutable identities, complete required job/aggregate inventory, one successful attempt and separate integration evidence. Use those mechanics at each stage; retain the local exit outcomes and reviewer/authority bindings below. Missing owner guidance blocks the affected gate.
+
+**Global gate alignment (A02/A04):** apply `development-gates` without project exceptions to review independence, substantive push ordering or base-change invalidation. Visibility-only kickoff publication does not publish implementation. The sequence below also applies to documentation claims/handoffs and GitOps candidates, not only application changes.

 ## End-to-End Task Delivery Gates

@@ -8,29 +13,27 @@ 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/`.
+Before repository entry, load [repository-entry-and-visibility.md](repository-entry-and-visibility.md) for the complete entry/branch/visibility contract and [runtime-and-ci.md](runtime-and-ci.md#channel-owned-workspace) for required clones, optional directories, reusable cache and Task isolation. These remain mandatory gate inputs, not optional background reading.

-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.
+Hermes main session owns the Task, performs implementation and obtains independent 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 second implementation worker may work on the selected Task. A separate read-only reviewer is required; review is not implementation ownership.

-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

-If any check, command, test, review, CI job, merge precondition, integration check, publication check, or Exit gate fails, the Task remains in that same gate. Hermes must diagnose the root cause, implement the smallest safe forward fix within the approved Task scope, rerun every affected check, and repeat this repair-and-verification loop until the complete gate passes. A repairable failure is work to fix; it is not a stopping point, a reason to abandon the Task, or permission to start another Task.
-
-Hermes may pause the repair loop only when progress requires an unavailable external dependency or credential, a human decision or permission, a change outside the approved requirements or Architecture, or an unsafe, destructive, or otherwise unauthorized action. In that case, keep the Task's lifecycle status unchanged, record `BLOCKED` separately with the exact evidence, responsible owner, and next action, and resume the same gate as soon as the blocker is removed. Never bypass, weaken, suppress, or relabel a failed gate to make it pass.
+Before repairing any failed check/review/CI/publication/exit condition, load [Failure-Repair Workflow](failure-and-documentation.md#failure-repair-workflow). It owns diagnosis, scope-safe forward repair, affected revalidation, blocker evidence and routing. Remain in the same gate until its complete exit passes; never weaken or relabel a failed gate. Pause only for its external-dependency, credential, decision, authority or safety blocker, recording `BLOCKED` separately without changing lifecycle status. Resume the same gate when removed.

 ### 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:** Read documentation remote `test` before branching. Establish fresh `application/` and `documentation/` clones inside the selected Task workspace under the loaded entry contract. Application branch: `<release>/<TASK_ID>-<short-explanation>-<attempt>`; documentation claim branch: `<release>/<TASK_ID>-start-delivery-<attempt>`. Each PR title equals its branch and targets `test`.

-**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.
+**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. No implementation subagent or cron; obtain independent read-only review before substantive documentation publication.

-**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:** Apply the loaded entry contract to exactly one current-wave `READY_FOR_DELIVERY` Task: Feature approval, dependencies, Architecture/requirements, target release and UI/UX readiness. Inspect only the adopted project’s eight channels. Establish and read back the application branch/PR before any edit. In the Task’s documentation clone add the hash-linked `READY_FOR_DELIVERY` to `IN_PROGRESS` event with actor, time, Task, wave, branch/PR evidence, previous hash and new hash; validate/review/merge it.

-**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:** Loaded workspace and entry checks pass: required Task-local clones have expected remotes, optional folders have a concrete need, and application branch/PR identity is verified. Documentation claim is merged and remote Task state is `IN_PROGRESS`. Only then edit repository content. Report Task, wave, dependencies, PR, workspace and merged claim. Missing or contradictory eligibility blocks selection, mutation and branch creation; name the owner.

 ### Stage 2 — `GATE_002_TASK_PLAN` — Plan the Task

@@ -44,33 +47,34 @@ 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 `<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.
+**Runtime:** Main session is the sole implementer inside the selected Task workspace. The reviewer must not be the candidate implementer: obtain a separate read-only reviewer who must not edit, push, merge or become a second implementer. Load runtime preflight before every execution context and create optional folders only for concrete needs. No new human-review dependency or cron ownership.

 **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. Load [runtime-and-ci.md](runtime-and-ci.md#execution-context-toolchain-preflight) and pass its exact-context preflight inside the selected Task workspace before commands. Unit tests use process-local fakes, not runtime services; UAT owns resource-dependent testing.
+2. Load `development-method-ttd` and follow mandatory failing-unit-test-first TTD for defects, new behavior and refactors; only an explicitly approved documented exception from the authorized project owner permits departure. Request non-unit coverage from UAT. Tooling, environment and credential failures are not product-test 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.
-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.
+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. Freeze and commit the complete locally validated candidate without rewriting shared history. Record candidate head/tree, target-base SHA and merge-base; require a clean candidate worktree. Do not push substantive changes yet.
+6. Obtain independent logic/security review of that exact local candidate, including acceptance coverage, production-path use and test gaps. Tests alone are not the review. Record reviewer identity, base/head/tree and PASS/FAIL. Remote CI is not required to issue code-review PASS; publication readiness remains false until its later gates pass. If review finds a problem, stay in `GATE_003_TASK_IMPLEMENTATION`: the sole implementer repairs locally, reruns affected checks, freezes the new commit, and has the reviewer review that exact head again before its next substantive push. Any candidate change invalidates PASS.
+7. Push only the exact reviewed head after PASS and verify remote branch/PR head equality with the checked and reviewed local commit. If any identity differs, stop and reconcile; never transfer a verdict to a different head. Required exact-head remote CI is verified in Stage 4.

-**Exit gate:** Every local command and review used the selected Task workspace, and every optional support folder had a concrete Task need; every acceptance criterion has implementation and test evidence; every required local check passes; the local checked revision, remote branch head, and PR head are identical; and that exact PR head has a passing review with no unresolved logic, security, acceptance, or material test finding. Any later file change keeps or returns the Task to `GATE_003_TASK_IMPLEMENTATION` until affected checks, push/readback, and review pass again. Any failure report names the exact command, file, test, or review finding; observed and expected behavior; failure class; mutation state; and repair or owner.
+**Exit gate:** Task-workspace/preflight rules and all local checks pass; every acceptance criterion has implementation/test evidence; `development-gates` candidate identity matches remote branch/PR and exact-head review has no unresolved finding. Later edits keep/return the Task to `GATE_003_TASK_IMPLEMENTATION` until affected checks, independent local review and then push/readback pass. Failure reports use [status-and-reporting.md](status-and-reporting.md): exact command/file/test/finding, observed versus expected behavior, failure class, mutation state and repair/owner.

 ### Stage 4 — `GATE_004_TASK_PR_CI` — Verify and Merge the Task PR

 **Repository and branch:** Use the application PR and `application/` clone inside the selected Task workspace, targeting `corp-v1-<code>/corp-v1-<code>` `test`; then fetch and read the resulting application `test` revision in that same clone after merge.

-**Runtime:** Gitea Actions runs PR CI. Hermes main session verifies CI and PR state, confirms its own exact-head review still covers the PR head, performs the authorized Gitea merge, and reads back the merge result. No subagent reviews or merges.
+**Runtime:** Gitea Actions runs PR CI. Hermes main session verifies CI and PR state, confirms independent exact-head review still covers the PR head, performs the authorized Gitea merge, and reads back the merge result. The read-only reviewer never merges; the authorized main session remains the sole writer.

 **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.
-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.
+1. Apply the loaded `development-gates` attempt-integrity contract to all required Delivery jobs: unit tests, lint, typecheck, build, static security and artifact validation, including the required aggregate.
+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 the target-base SHA still equals the reviewed base. Any target-base SHA change invalidates merge readiness, even when candidate head/tree is unchanged; refresh/synchronize and repeat validation and independent review under `development-gates`. There is no local harmless-drift exception.
+3. If conflict resolution, rebase, or any file/tree change is required, return to `GATE_003_TASK_IMPLEMENTATION`; repeat affected local checks, independent review of the frozen local candidate, and then push/readback for the new PR head; then restart `GATE_004_TASK_PR_CI` for that exact head.
+4. Apply the loaded owner’s reviewed-head merge and separate integration readback contract within existing merge authority.

 **Exit gate:** All required PR CI succeeds on the exact reviewed PR head; the final pre-merge check refers to that same head; the PR is merged; and the exact application `test` integration revision is known. The Task remains `IN_PROGRESS`; merge alone does not mean `TO_BE_RELEASED` or `DONE`.

@@ -78,16 +82,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 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.
-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.
+1. Apply the loaded owner’s separate integration gate to all required application unit/build, container, immutable publication and artifact checks. Retain registry digest readback; PR-head CI cannot replace integration 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 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`. 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 +109,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>`.
@@ -0,0 +1,26 @@
+"""Exact, reversible skill-identity migration; never rewrite provenance URLs."""
+import re
+
+IDENTITIES = {
+    'development-branching-strategy-aerosim': 'development-branching-strategy-skic-aerosim',
+    'development-scripts-aerosim': 'development-scripts-skic-aerosim',
+    'devsecops-ci-cd-gitea-aerosim': 'devsecops-ci-cd-gitea-skic-aerosim',
+    'documentation-docusaurus-aerosim': 'documentation-docusaurus-skic-aerosim',
+    'development-gitops-argo-cd-gondor-v1': 'development-gitops-argo-cd-home-gondor-v1',
+    'home-v1-discord': 'discord',
+    'home-v1--truenas': 'truenas',
+}
+
+def translate(text, mapping):
+    # Bare discord/truenas are common words: only migrate explicit skill identity
+    # delimiters (inline code, quoted names, and related_skills list entries).
+    pattern = r'(?P<left>`|[\"\'])(?P<name>' + '|'.join(map(re.escape, mapping)) + r')(?=[`\"\'\],])'
+    text = re.sub(pattern, lambda m: m['left'] + mapping[m['name']], text)
+    return re.sub(r'(?m)^(    related_skills: \[)(.*)(\])$',
+                  lambda m: m[1] + ', '.join(mapping.get(v, v) for v in m[2].split(', ')) + m[3], text)
+
+def canonicalize(text):
+    return translate(text, IDENTITIES)
+
+def original_identity(text):
+    return translate(text, {new: old for old, new in IDENTITIES.items()})
@@ -0,0 +1,25 @@
+{
+  "retained": [
+    "channel-board-skic",
+    "discord",
+    "documentation-docusaurus-global",
+    "glossary-skic",
+    "development-durable-wave-execution",
+    "development-gates",
+    "development-integrity",
+    "development-method-ttd",
+    "development-branching-strategy",
+    "development-monorepo-pnpm",
+    "development-scripts",
+    "development-gitops-argo-cd-home-gondor-v1"
+  ],
+  "additional": [
+    "ci-runtime-skic",
+    "delivery-docs",
+    "status-reporting-skic",
+    "development-security",
+    "development-security-skic",
+    "develop-monorepo-pnpm-app-skic",
+    "develop-monorepo-pnpm-package-skic"
+  ]
+}
@@ -0,0 +1,28 @@
+[
+  {
+    "path": "references/task-delivery-gates.md",
+    "sha256": "6ecc350c0aaa66551a4bcd9a5da278c55980cce783eaf563a1a7546c1d5ac588"
+  },
+  {
+    "path": "references/repository-entry-and-visibility.md",
+    "sha256": "ee89ad297ea28e5a393b8a7e53de487883e64c720276f4055e368086d1c0ba65"
+  },
+  {
+    "path": "references/planning-artifact-reconciliation.md",
+    "sha256": "8676cb832199c4e11acc0f9f3abc649364a9ed6eec83d561ffd9c21bc556c3af"
+  },
+  {
+    "path": "references/aerosim-lessons-review.md",
+    "sha256": "e66dbafba963f95831ed230b15cee67b23677024bdbf464dae8cb2deb906a96e"
+  },
+  {
+    "path": "SKILL.md",
+    "heading": "Authority and Escalation",
+    "sha256": "85635a7e636529593e5ed98ff8884b7078e429123442c59ae4f7db94cc1e0e40"
+  },
+  {
+    "path": "SKILL.md",
+    "heading": "UI/UX Coordination",
+    "sha256": "c7331b08010fc4f931543a5ced352cc05d16df122aea2abafc3b3221da05b18d"
+  }
+]
@@ -0,0 +1,15 @@
+{
+  "home-v1-skills-code-agent/development-gates": "global-skills/development-gates",
+  "home-v1-skills-code-agent/development-integrity": "global-skills/development-integrity",
+  "home-v1-skills-code-agent/development-method-ttd": "global-skills/development-method-ttd",
+  "home-v1-skills-code-agent/development-durable-wave-execution": "global-skills/development-durable-wave-execution",
+  "home-v1-skills-code-agent/development-monorepo-pnpm": "global-skills/development-monorepo-pnpm",
+  "home-v1-skills-code-agent/development-branching-strategy": "global-skills/development-branching-strategy",
+  "home-v1-skills-code-agent/development-scripts": "global-skills/development-scripts",
+  "home-v1-skills-code-agent/devsecops-ci-cd-gitea": "global-skills/devsecops-ci-cd-gitea",
+  "corp-v1-aerosim-skills-code-agent/documentation-docusaurus-aerosim": "skic-aerosim-skills/documentation-docusaurus-skic-aerosim",
+  "corp-v1-aerosim-skills-code-agent/development-scripts-aerosim": "skic-aerosim-skills/development-scripts-skic-aerosim",
+  "corp-v1-aerosim-skills-code-agent/development-branching-strategy-aerosim": "skic-aerosim-skills/development-branching-strategy-skic-aerosim",
+  "corp-v1-aerosim-skills-code-agent/devsecops-ci-cd-gitea-aerosim": "skic-aerosim-skills/devsecops-ci-cd-gitea-skic-aerosim",
+  "home-v1-skills-code-agent/development-gitops-argo-cd-gondor-v1": "home-gondor-v1-skills/development-gitops-argo-cd-home-gondor-v1"
+}
@@ -0,0 +1,13 @@
+from pathlib import Path
+import os
+ROOT=Path(__file__).resolve().parents[1]
+def owner(name):
+    base=Path(os.environ.get('DELIVERY_OWNER_ROOT',str(ROOT.parent)))
+    direct=base/name/'SKILL.md'
+    found=[direct] if direct.is_file() else list(base.glob('*/'+name+'/SKILL.md'))
+    if len(found)!=1: raise RuntimeError('Owner missing or ambiguous: '+name+' under '+str(base))
+    return found[0].read_text()
+def effective(path):
+    text=(ROOT/path).read_text()
+    routes={'references/runtime-and-ci.md':['ci-runtime-skic'], 'references/status-and-reporting.md':['status-reporting-skic'], 'references/failure-and-documentation.md':['ci-runtime-skic','status-reporting-skic','delivery-docs']}
+    return text+'\n'+'\n'.join(owner(n) for n in routes.get(path,[]))
@@ -0,0 +1,49 @@
+[
+  {
+    "path": "references/task-delivery-gates.md",
+    "pattern": "^\\*\\*Exit gate:\\*\\* All required PR CI.*$",
+    "hashes": [
+      "ff18fe3b523dae671eb14f513e1f90700eeea9c8a93bf85686f67b8f9635e7f3"
+    ]
+  },
+  {
+    "path": "references/task-delivery-gates.md",
+    "pattern": "^\\*\\*Exit gate:\\*\\* Every required post-merge.*$",
+    "hashes": [
+      "9338b15f03aa46139240842a0c72c92fd3af2d91e1af4ee82c55fe859361d196"
+    ]
+  },
+  {
+    "path": "references/task-delivery-gates.md",
+    "pattern": "^### Stage [1-6].*$",
+    "hashes": [
+      "50a5e09da6aca1488d9d375c22740b39c0168837bde39bb390352186f7982d6d",
+      "fc758ac75b342cceb555b927710c0aba38ca31fd6bdbca4eb7ed054f814c2f38",
+      "f68e0313b622ef7666bccd0c6bd9551153e01e2b8f6cc68978a4dda72924c45a",
+      "156eb690576a1a812c3fb7d32ee32fb98c174c81143830a336ca4ec54dd27745",
+      "4a76eda13fa68c5f28b458d5d1ad400211c4daad5418b3f3319c36b84ade03b2",
+      "960be6948de8a23e4591cfa099c9cf30e47f2b1b72f8702f05c6d7dd1713bfd7"
+    ]
+  },
+  {
+    "path": "references/status-and-reporting.md",
+    "pattern": "(?s)## Scope Status Vocabulary.*",
+    "hashes": [
+      "0aa256d5852c664c0d18b3888990d6c31e73a4e50e894324e1d11cb72a970b93"
+    ]
+  },
+  {
+    "path": "references/failure-and-documentation.md",
+    "pattern": "(?s)When a build or CI failure is observed:.*?(?=5\\. )",
+    "hashes": [
+      "d7850a4ca34226dd9b45badc1623012e87a2557f3cced4b63807939be00a72f5"
+    ]
+  },
+  {
+    "path": "references/failure-and-documentation.md",
+    "pattern": "(?s)7\\. run local validation;.*?(?=## Documentation Ownership)",
+    "hashes": [
+      "13e74d3dd90a757a7a7d0ef7f0a4448cb6a7764b7c63ce8699b40f197fbac6fa"
+    ]
+  }
+]
@@ -0,0 +1,97 @@
+{
+  "owners": {
+    "preflight": {
+      "owner": "development-scripts",
+      "reference": "references/runtime-preflight.md",
+      "source_url": "https://gitea.lego-cloud.eu/global-skills/development-scripts",
+      "inspected_head": "0e36552938da94c0539e39b35256b8effe34c25d",
+      "sha256": "07306382b8afe5c2d2e83e2955a04a1523d008e7e39cead7c7a1797bb6640462",
+      "state": "merged source and installed reference byte-identical; authenticated immutable full-package readback verified",
+      "evidence_text": "# Exact-context toolchain preflight\n\nUse before repository commands in a Node/pnpm repository, or any command that may invoke Node or pnpm. This is a reusable execution procedure, not a project directory convention or permission to run tests. The caller supplies the authorized repository, revision, worker context, required environment names and permitted operation. Task-directory containment and stop-on-failed-preflight remain caller responsibilities.\n\n## Required inputs\n\nLoad `development-monorepo-pnpm` and its `references/workspace-and-tooling.md` tooling reference for version selection and committed toolchain/workspace conventions. Resolve required Node and pnpm versions from the repository's **committed toolchain contract**, not ambient executables. Inspect the selected revision's package-manager pin, Node declaration and applicable locked environment/image metadata. Do not invent a universal version or workspace layout. If declarations conflict, are absent, or leave the required exact version unresolved, stop and reconcile the contract with its owner before running the requested command. A version range alone is not an exact observed-version pin.\n\n## Procedure\n\nTreat every foreground shell, detached worktree, background process, main-session review command and CI job as a separate execution context. A successful check elsewhere is not transferable evidence. Perform inspection/preflight in the intended context before the requested repository operation; inspection commands themselves are necessary to establish the context.\n\n1. Resolve the required versions from the committed toolchain contract at the expected source revision. Record the paths/revision used, not secret content.\n2. Inside that exact shell/process/container run `command -v node`, `node --version`, `command -v pnpm`, and `pnpm --version`, using `terminal` or the equivalent job step. Require every command to succeed; compare observed versions to the resolved required versions (normalize only Node's leading `v`). An executable found in a different shell is not sufficient. Record executable paths and observed/required versions.\n3. Verify required non-secret environment variable names are present, including disposable-test database markers when applicable, **without reading or printing their values**. For Bash, a presence-only `[[ -v VARIABLE_NAME ]]` check is suitable after validating a supplied name against `[A-Za-z_][A-Za-z0-9_]*`. Do not dump `env`, expand indirect values, enable tracing, or read credentials. Presence alone does not prove resource isolation or authorize database use; that remains the caller's separate gate.\n4. Verify the actual working directory and repository root; compare source HEAD and linked branch/PR identity with caller-supplied expected identity. Inspect repository state and confirm it is clean or intentionally staged, with every intentional change accounted for. Detached HEAD is allowed only when it matches the authorized revision/worktree. Never reset/stash unrelated changes to make a check green. Do not assume a project-specific application layout.\n5. Start the original command only after every applicable check passes. Keep activation, verification and execution in the same context. Recheck if PATH, activation, working directory, revision, image or required environment changes. A background worker must do its own preflight within its launch command, not consume a foreground success flag.\n\n## Failure and repair\n\nNever assume a background process inherits `PATH`, shell activation, Devbox state, Corepack activation, database variables or other exports from a foreground terminal. Missing `pnpm` is an execution-context/toolchain failure, **never an application-code or test failure**. Missing Node, wrong versions, wrong working directory/revision and absent required names also block execution; they do not constitute product RED.\n\nRepair the exact context by providing the required toolchain path or approved activation. Do not silently install a latest toolchain, rewrite pins, or execute Devbox unless the parent workflow permits it. Then **repeat the complete preflight** there and rerun the original command before making a claim about repository code. Preserve failure and rerun evidence separately.\n\n## Verification and scope\n\nRecord expected/observed versions, executable paths, repository root/revision, branch/PR link, approved state, presence-only results, context identity and command outcome. Do not include secrets or environment values. Local narrow validation never replaces all-app CI or exact-head remote job evidence. Toolchain success is not a claim of CI, publication, deployment or runtime acceptance.\n\nRun the owner contract regression with `terminal(command=\"python3 scripts/test_preflight_contract.py\", workdir=\"<skill-repository>\")`. This checks maintained guidance, not a live consumer toolchain; the five steps above must still be exercised for each real conLine truncated
+    },
+    "base_images": {
+      "owner": "devsecops-ci-cd-gitea",
+      "reference": "references/base-images.md",
+      "source_url": "https://gitea.lego-cloud.eu/global-skills/devsecops-ci-cd-gitea",
+      "inspected_head": "669e28eadfe79ac7cb3c10ccdea318dd5296d481",
+      "sha256": "1fb0e24ec5789b195be9ae35fbb9529fa1cab56112dae5baf9455284ca490e53",
+      "state": "merged source and installed reference byte-identical; authenticated immutable full-package readback verified",
+      "evidence_text": "# Reusable CI base-image contract\n\nUse when stable runtimes or OS tools would otherwise be downloaded repeatedly in application jobs. This owner defines reusable construction, validation, publication and consumption mechanics; it does not choose a project's image repository, branch, application layout or runtime-smoke authority. Supply those bindings from the project Delivery/CI overlay. Runtime verification is a separate acceptance layer delegated to the project's authorized runtime-test owner, not permission granted by this reference.\n\nRead [pipeline-workflow.md](pipeline-workflow.md) for trust boundaries, exact checkout and immutable retries, and [harbor-auth.md](harbor-auth.md) for credential handling. These safeguards apply in addition to this contract; base-image work is not an exemption.\n\n## Construction and static contract\n\n1. Keep one folder per image containing a Dockerfile, machine-readable version/platform metadata, usage documentation, a build helper and a static publication contract. Record required upstream reference, platforms, runtime/tool pins, numeric user/group and supported workspace path. Do not prescribe a product's application directories.\n2. Pin the upstream base by digest (`repository@sha256:<64 lowercase hexadecimal characters>`). Check the actual resolved platform against metadata; for a multi-platform index, record index and platform-manifest relationships rather than silently comparing unlike digests.\n3. Assert exact runtime/tool versions, architecture, numeric non-root identity, writable workspace, CA trust, Git, shell and every other required tool. Static/unit checks inspect Dockerfile and metadata; they cannot alone prove live writability, effective UID, trust or executable behavior. The authorized runtime verifier must exercise those assertions on the **published digest** and record results separately. Never describe a static declaration as runtime proof.\n4. 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 or credentials into a generic base image. This does not waive the consumer's committed toolchain contract or exact-context preflight in `development-scripts/references/runtime-preflight.md`.\n\n## Candidate isolation and trusted publication\n\n- Build and perform static/unit validation on pull requests **without registry credentials**. Credential absence must be structural: no publication secret in workflow-global scope, candidate job environment, persistent runner home, Docker config, build args, cache or artifact. Skipping login does not remove an already available credential. Use an approved credential-free base acquisition path; if unavailable, stop rather than leak publication credentials to candidates.\n- Choose exactly one configured default integration branch, as in the pipeline owner (`test` or `main`), and publish only its exact trusted integration commit. PR, fork, branch-readiness and broad tag triggers cannot publish. Separately authorized release workflows must retain equivalent isolation, never broaden the ordinary candidate path.\n- Complete candidate execution before introducing a narrowly scoped Harbor robot secret in the isolated trusted publication job. Pass secrets via standard input only. Keep temporary Docker/Helm credential stores scoped to the job, clean on success and failure, and treat logout failure on persistent runners as failure after cleanup. Never pre-seed push credentials into the reusable job image or execute untrusted candidate hooks after authentication.\n\n## Immutable publication and direct readback\n\n1. Verify checkout identity before building. Tag the image with the full 40-character source revision; never publish `latest`, mutable version aliases or shortened SHAs for governed consumption. Enforce registry immutable-tag rules as well as workflow checks.\n2. Preserve the validated local image ID. Existing tags are reusable only when the remote OCI config digest equals that validated local image ID; different content is a hard failure, not an overwrite. For multiple platforms, verify each required platform's config identity and expected manifest/index membership. Missing or ambiguous remote evidence fails closed.\n3. After publication, read back the Harbor artifact directly: verify reference, source identity, platform and manifest digest. Record source URL/revision, workflow run/attempt/job, immutable tag, manifest digest, config digest/local image ID and canonical millisecond ISO-8601 UTC timestamp. Config digest is for retry content comparison; manifest digest is for consumption. Do not interchange either with source SHA or chart archive checksum.\n4. Require the final aggregate under `always()` to explicitly require every necessary build/publication/readback job's success. A green push step or skipped aggrLine truncated
+    }
+  },
+  "moved_clauses": [
+    {
+      "clause": "version resolution, executable/version comparisons",
+      "owner_key": "preflight",
+      "section": "Required inputs; Procedure 1\u20132"
+    },
+    {
+      "clause": "presence-only environment and repository identity/state checks",
+      "owner_key": "preflight",
+      "section": "Procedure 3\u20134"
+    },
+    {
+      "clause": "same-context activation, inheritance failure classification and complete retry",
+      "owner_key": "preflight",
+      "section": "Procedure 5; Failure and repair"
+    },
+    {
+      "clause": "image folder/metadata, digest/tool/platform/user/workspace/trust assertions and lockfile parity",
+      "owner_key": "base_images",
+      "section": "Construction and static contract"
+    },
+    {
+      "clause": "credential-free candidates and isolated trusted publication",
+      "owner_key": "base_images",
+      "section": "Candidate isolation and trusted publication"
+    },
+    {
+      "clause": "full-source tags, direct Harbor readback, immutable retry and aggregates",
+      "owner_key": "base_images",
+      "section": "Immutable publication and direct readback"
+    },
+    {
+      "clause": "digest consumer verification and forward repair mechanics",
+      "owner_key": "base_images",
+      "section": "Consumer verification and forward repair"
+    },
+    {
+      "clause": "negative trigger/tag/secret/interpolation/digest/setup regression cases",
+      "owner_key": "base_images",
+      "section": "Fail-closed regression matrix"
+    }
+  ],
+  "retained_local": [
+    "every foreground shell",
+    "detached worktree",
+    "background process",
+    "worker",
+    "Hermes main-session review command",
+    "CI job",
+    "Stop on failed preflight",
+    "selected Task directory",
+    "selected repository",
+    "allowed command scope",
+    "complete repository CI",
+    "last known-good digest",
+    "trusted `test` branch",
+    "UAT",
+    "exact PR-head SHA"
+  ],
+  "superseded_golden_rules": [
+    {
+      "path": "references/runtime-and-ci.md",
+      "pattern": "(?s)### Per-project reusable CI base images\\n.*?(?=### Gondor)",
+      "hashes": [
+        "0c92e0521c57c357a62c8313c70527547427d98b7647ec8cd1a97c148b5ba4f1"
+      ]
+    },
+    {
+      "path": "references/runtime-and-ci.md",
+      "pattern": "(?s)Treat every foreground shell.*?(?=### Immutable|### Per-project)",
+      "hashes": [
+        "8df9d2e952a6a8c48fd3d0a18357aea21d5ffbb1e06e53c7273c6e50e2545be5"
+      ]
+    }
+  ]
+}
@@ -0,0 +1 @@
+0d7de8761e3c27908cef45c05a16e36cc36dce0dd428027002c632c34c8448bf
@@ -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.18.0', 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 second implementation worker", text)
+
+
+if __name__ == "__main__":
+    unittest.main()
@@ -1,18 +1,19 @@
 from pathlib import Path
+from disposition_support import effective

 ROOT = Path(__file__).resolve().parents[1]
 SKILL = (ROOT / "SKILL.md").read_text(encoding="utf-8")
-RUNTIME = (ROOT / "references/runtime-and-ci.md").read_text(encoding="utf-8")
+RUNTIME = effective("references/runtime-and-ci.md")

 REFERENCES = {
-    "development-durable-wave-execution": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-durable-wave-execution",
-    "development-gates": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-gates",
-    "development-integrity": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-integrity",
-    "development-method-ttd": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-method-ttd",
-    "development-branching-strategy": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-branching-strategy",
-    "development-monorepo-pnpm": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-monorepo-pnpm",
-    "development-scripts": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-scripts",
-    "development-gitops-argo-cd-gondor-v1": "https://gitea.lego-cloud.eu/home-v1-skills-code-agent/development-gitops-argo-cd-gondor-v1",
+    "development-durable-wave-execution": "https://gitea.lego-cloud.eu/global-skills/development-durable-wave-execution",
+    "development-gates": "https://gitea.lego-cloud.eu/global-skills/development-gates",
+    "development-integrity": "https://gitea.lego-cloud.eu/global-skills/development-integrity",
+    "development-method-ttd": "https://gitea.lego-cloud.eu/global-skills/development-method-ttd",
+    "development-branching-strategy": "https://gitea.lego-cloud.eu/global-skills/development-branching-strategy",
+    "development-monorepo-pnpm": "https://gitea.lego-cloud.eu/global-skills/development-monorepo-pnpm",
+    "development-scripts": "https://gitea.lego-cloud.eu/global-skills/development-scripts",
+    "development-gitops-argo-cd-home-gondor-v1": "https://gitea.lego-cloud.eu/home-gondor-v1-skills/development-gitops-argo-cd-home-gondor-v1",
 }


@@ -26,9 +27,10 @@ def test_delivery_reference_routes_reusable_development_procedures() -> None:
 def test_generic_automation_is_owned_by_development_scripts() -> None:
    assert "`development-scripts` owns Taskfile, `.scripts/`" in SKILL
    assert "must not restate generic RED–GREEN–REFACTOR mechanics" in SKILL
-    assert "the explicit project/channel overlay wins" in SKILL
+    assert "Project bindings must not contradict global skills" in SKILL
+    assert "the explicit project/channel overlay wins" not in SKILL


 def test_gitops_reference_requires_one_environment_per_repository() -> None:
-    assert "development-gitops-argo-cd-gondor-v1" in RUNTIME
+    assert "development-gitops-argo-cd-home-gondor-v1" in RUNTIME
    assert "one repository per environment" in RUNTIME
@@ -0,0 +1,75 @@
+"""Disposition regression: immutable authority, concrete loads and moved policy."""
+from pathlib import Path
+import hashlib,json,re,unittest
+from disposition_support import ROOT,owner,effective
+TESTS=Path(__file__).parent
+class Disposition(unittest.TestCase):
+    def test_authority_and_unresolved_gates_unchanged(self):
+        mapping=json.loads((TESTS/'disposition-url-map.json').read_text())
+        for f in json.loads((TESTS/'disposition-protected.json').read_text()):
+            t=(ROOT/f['path']).read_text()
+            for old,new in mapping.items(): t=t.replace('https://gitea.lego-cloud.eu/'+new,'https://gitea.lego-cloud.eu/'+old)
+            t=t.replace('glossary-skic','corp-v1-glossary')
+            if 'heading' in f: t=re.search(r'^## '+re.escape(f['heading'])+r'\n.*?(?=^## |\Z)',t,re.M|re.S).group()
+            if 'block' in f: t=re.search(r'<!-- '+f['block']+r':BEGIN -->.*?<!-- '+f['block']+r':END -->',t,re.S).group()
+            self.assertEqual(hashlib.sha256(t.rstrip().encode()).hexdigest(),f['sha256'],f)
+    def test_all_retained_and_real_additional_dependencies(self):
+        t=(ROOT/'SKILL.md').read_text(); d=json.loads((TESTS/'disposition-dependencies.json').read_text())
+        actual=re.search(r'related_skills: \[(.*?)\]',t).group(1).split(', ')
+        self.assertEqual(actual,d['retained']+d['additional']); self.assertEqual(len(actual),len(set(actual)))
+        self.assertIn('develop-monorepo-pnpm-app-skic',actual); self.assertIn('develop-monorepo-pnpm-package-skic',actual)
+        self.assertIn('draft review aids, not approved standards',t)
+        for n in d['additional']:
+            self.assertIn('`'+n+'`',t)
+        for n in ['gitops-manifest-engineering','gondor-v1-nodes']:
+            self.assertIn(n,t if ROOT.name.endswith('aerosim') else owner('ci-runtime-skic'))
+    def test_no_removed_reports_or_empty_sections(self):
+        t=(ROOT/'SKILL.md').read_text()
+        for n in ['ADOPTION.md','FULL-PROGRAM.md','naming-delivery-review.md','SIMPLIFICATION.md']:self.assertFalse((ROOT/n).exists())
+        for h in ['Overview','When to Use','Common Pitfalls','Project-Adoption Delivery Lessons','Proactive Iteration Requirement','Verification Checklist','Shared Corp v1 System Login','Documentation Ownership']:
+            self.assertNotIn('## '+h+'\n',t)
+        self.assertIn('## Synchronization Workflow',t)
+        if not ROOT.name.endswith('aerosim'):
+            self.assertIn('references/final-verification.md',t)
+            self.assertTrue((ROOT/'references/final-verification.md').is_file())
+    def test_complete_vocabulary_and_templates_moved_once(self):
+        t=owner('status-reporting-skic').split('## Scope Status Vocabulary',1)[1].split('## Blocker routing',1)[0]
+        self.assertEqual(hashlib.sha256(('## Scope Status Vocabulary'+t).rstrip().encode()).hexdigest(),(TESTS/'report-format.sha256').read_text().strip())
+        local=(ROOT/'references/status-and-reporting.md').read_text()
+        self.assertNotIn('wave-previous:',local)
+        self.assertIn('status-reporting-skic',local);self.assertIn('development-integrity',local)
+    def test_scoped_owner_mechanics_and_fail_closed_loads(self):
+        ci=owner('ci-runtime-skic')
+        for s in ['every foreground shell','last known-good digest','credential-free','per-run database/schema/role','deletion-reclaim','Bitwarden','exact-context','stop','self-hosted-service-account-recovery','truenas','references/base-images.md','references/runtime-preflight.md','repeat diagnosis, repair','same Task/gate','Before Delivery publication/install or operational adoption','complete published and installed owner packages','immutable owner revision and reference hash','Stop adoption if this evidence is unresolved']:
+            self.assertIn(s,ci)
+        for s in ['devsecops-ci-cd-gitea-skic-aerosim','development-scripts-skic-aerosim','gitops-manifest-engineering','gondor-v1-nodes']:
+            self.assertIn(s,ci)
+        local=(ROOT/'references/runtime-and-ci.md').read_text()
+        self.assertIn('ci-runtime-skic',local);self.assertIn('development-security-skic',local)
+        self.assertNotIn('├── cache/',local)
+        self.assertIn('isolated, unpublished experimental delta',local)
+        self.assertIn('historical missing RED',local)
+    def test_documentation_outcomes_and_binding(self):
+        docs=owner('delivery-docs'); local=(ROOT/'references/failure-and-documentation.md').read_text()
+        for s in ['five sections','Delivery workflow','Collaboration and decisions','Packaging and deployment preparation','Operations and troubleshooting','planned process as already operational','source identity','read back']:
+            self.assertIn(s,docs)
+        self.assertNotIn('### Ways of Working',local);self.assertIn('delivery-docs',local)
+        self.assertIn('glossary-skic',local)
+        self.assertIn('documentation-docusaurus-skic-aerosim' if ROOT.name.endswith('aerosim') else 'documentation-docusaurus-global',local)
+    def test_security_preserves_single_policy_owner(self):
+        security=owner('development-security-skic'); generic=owner('development-security')
+        for s in ['channel-board-skic','Corp v1 System SSO Credential Use','Stop before login','development-security','Central Delivery gains no self-recovery authority']:
+            self.assertIn(s,security)
+        self.assertNotIn('HL_V1_SSO_PASSWORD',security+generic)
+        for s in ['presence only','never inspect, hash or measure','generic 401/403','separately verified delegation','not authority']:
+            self.assertIn(s,generic)
+    def test_local_markdown_targets_and_anchors_exist(self):
+        for p in [ROOT/'SKILL.md',*ROOT.glob('references/*.md')]:
+            for link in re.findall(r'\]\(([^)]+)\)',p.read_text()):
+                if '://' in link or link.startswith('<'):continue
+                path,_,anchor=link.partition('#');dest=p.parent/path if path else p
+                self.assertTrue(dest.is_file(),(p,link))
+                if anchor:
+                    anchors={re.sub(r'[^\w -]','',h.lower()).replace(' ','-') for h in re.findall(r'^#+ (.*)',dest.read_text(),re.M)}
+                    self.assertIn(anchor,anchors,(p,link))
+if __name__=='__main__':unittest.main()
@@ -0,0 +1,8 @@
+from pathlib import Path
+import unittest
+class DraftRouting(unittest.TestCase):
+ def test_scoped_draft_decision_points(self):
+  text=(Path(__file__).resolve().parents[1]/'SKILL.md').read_text()
+  for marker in ['startup/readiness/shutdown','public API/exports','develop-monorepo-pnpm-app-skic','develop-monorepo-pnpm-package-skic','draft review aids, not approved standards','do not enforce a proposed convention','one implementation worker per Task','loading a draft grants no execution authority','workspace/build/package-manager mechanics']:
+   self.assertIn(marker,text)
+if __name__=='__main__':unittest.main()
@@ -0,0 +1,34 @@
+"""Central executable policy follows the global exact-candidate gates."""
+from pathlib import Path
+import unittest
+ROOT = Path(__file__).resolve().parents[1]
+class GlobalGateAlignment(unittest.TestCase):
+    def test_review_before_substantive_push(self):
+        gates = (ROOT/'references/task-delivery-gates.md').read_text()
+        stage = gates.split('### Stage 3')[1].split('### Stage 4')[0]
+        self.assertLess(stage.index('5. Freeze'), stage.index('6. Obtain independent'))
+        self.assertLess(stage.index('6. Obtain independent'), stage.index('7. Push only'))
+        self.assertIn('before its next substantive push', stage)
+        self.assertIn('reviewer must not be the candidate implementer', stage)
+        self.assertIn('read-only reviewer', stage)
+        self.assertNotIn('push the new PR head, and review', gates)
+        self.assertNotIn('No implementation or review subagent', gates)
+    def test_any_base_change_invalidates_readiness(self):
+        gates = (ROOT/'references/task-delivery-gates.md').read_text()
+        self.assertIn('Any target-base SHA change invalidates merge readiness', gates)
+        self.assertIn('even when candidate head/tree is unchanged', gates)
+        self.assertNotIn('base drift is harmless', gates)
+        self.assertNotIn('push/readback, and review', gates)
+    def test_kickoff_and_cross_repository_scope(self):
+        entry = (ROOT/'references/repository-entry-and-visibility.md').read_text()
+        self.assertIn('no file/tree changes', entry)
+        self.assertIn('does not authorize a substantive push', entry)
+        gates = (ROOT/'references/task-delivery-gates.md').read_text()
+        self.assertIn('documentation claims/handoffs and GitOps candidates', gates)
+    def test_no_unresolved_policy_marker(self):
+        for path in [ROOT/'SKILL.md', *ROOT.glob('references/*.md')]:
+            text = path.read_text()
+            self.assertNotIn('Bounded unresolved A02/A04', text)
+            self.assertNotIn('A02/A04 review-order/base-drift remain bounded unresolved', text)
+if __name__ == '__main__':
+    unittest.main()
@@ -0,0 +1,7 @@
+"""Validate the current bounded source contract, not full-program completion."""
+from pathlib import Path
+import subprocess,sys
+ROOT=Path(__file__).resolve().parents[1]
+if __name__=='__main__':
+    print('Source-contract checks only; A17 and deferred helpers are not completion claims.',flush=True)
+    subprocess.run([sys.executable,'-m','pytest','-q',str(Path(__file__).parent)],cwd=ROOT,check=True)
Author	SHA1	Message	Date
jarvis-at-skic	818869fae9	fix: retain global review precedence in entry guidance	2026-10-26 11:34:06 +00:00
jarvis-at-skic	35f0a7259c	fix: align Central independent review and base invalidation gates	2026-10-26 11:31:49 +00:00
jarvis-at-skic	8c39ebe70e	Merge pull request 'fix: Delivery source identity and bounded helper routing' (#16 ) from fix/delivery-source-identity-t3c6f0036 into test	2026-10-26 03:26:59 -07:00
jarvis-at-skic	0776bacd25	test: align expected version with source identity release	2026-10-26 10:24:59 +00:00
jarvis-at-skic	9d1a6dd44d	fix: qualify Delivery sources and preserve compatibility	2026-10-26 10:22:35 +00:00
jarvis-at-skic	2e7f6618b6	chore: open scoped Delivery source correction	2026-10-26 10:17:40 +00:00
jarvis-at-skic	db3115aa86	Merge pull request 'Implement Delivery responsibility dispositions: channel-delivery-skic' (#15 ) from refactor/dispositions-7c5c1457 into test	2026-10-23 01:16:08 -07:00
jarvis-at-skic	1bff2cefab	refactor: implement concrete Delivery responsibility dispositions	2026-10-23 08:11:40 +00:00
jarvis-at-skic	cb6b41f1a5	chore: open scoped disposition implementation	2026-10-23 07:53:07 +00:00
jarvis-at-skic	a1741dc061	Merge pull request 'Implement full Delivery program: channel-delivery-skic' (#14 ) from refactor/delivery-full-program into test	2026-10-22 23:39:47 -07:00
jarvis-at-skic	65e546c448	refactor: implement governed Delivery program contracts	2026-10-23 06:39:27 +00:00
jarvis-at-skic	c306ea4794	Merge pull request 'refactor: implement bounded Delivery existing-owner simplification' (#13 ) from refactor/delivery-existing-owners into test	2026-10-22 22:16:23 -07:00
jarvis-at-skic	de2e201c4e	refactor: simplify Delivery through existing procedure owners	2026-10-23 05:12:21 +00:00
jarvis-at-skic	225ae3b068	Merge pull request 'docs: canonical SKIC channel skill naming' (#12 ) from docs/canonical-skic-reference-names into test	2026-10-21 10:58:12 -07:00
jarvis-at-skic	5068145048	docs: reconcile canonical SKIC channel skill names	2026-10-21 17:56:57 +00:00
jarvis-at-skic	b45dc2d833	Merge pull request 'docs: promote reusable AeroSim channel lessons' (#11 ) from docs/aerosim-reference-lessons-20261020 into test	2026-10-20 11:42:59 -07:00
jarvis-at-skic	5a0949658d	docs: promote reusable AeroSim channel lessons	2026-10-20 18:42:39 +00:00
jarvis-at-skic	0bf71b905f	Merge pull request 'policy: retain artifact validation in Delivery' (#10 ) from policy/artifact-validation-boundary into test	2026-09-26 05:15:23 -07:00
jarvis-at-skic	36ae5f50e4	policy: retain artifact validation in Delivery	2026-09-26 12:02:14 +00:00
jarvis-at-skic	5ead0aeabf	Merge pull request 'policy: limit Delivery to unit testing' (#9 ) from policy/unit-tests-only into test	2026-09-26 03:35:30 -07:00
jarvis-at-skic	44e6aa5db6	policy: limit Delivery to unit testing	2026-09-26 10:10:52 +00:00
jarvis-at-skic	c61c517aa0	docs: route Delivery through reusable development skills Validated development-skill routing and reference corrections.	2026-09-23 12:49:39 -07:00
				`@@ -0,0 +1 @@`
				`0d7de8761e3c27908cef45c05a16e36cc36dce0dd428027002c632c34c8448bf`