docs: route Delivery through development skills

SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: corp-v1-channel-delivery
 description: "Use when operating or synchronizing a Corp v1 project's delivery channel. Drives coding, unit testing, build and continuous-integration health, attempts safe evidence-based fixes, escalates requirement or architecture contradictions, and maintains Ways of Working and Engineering documentation."
-version: 1.11.0
+version: 1.11.1
 author: Hermes Agent
 license: MIT
 metadata:
   hermes:
     tags: [corp-v1, discord, channel, delivery, coding, testing, ci]
-    related_skills: [corp-v1-main, home-v1-discord, documentation-docusaurus, corp-v1-glossary]
+    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]
 ---
 
 # Corp v1 Delivery Channel
@@ -75,6 +75,23 @@ Use this skill when:
 
 Do not use it to silently choose between contradictory requirements or architecture decisions, approve releases, or bypass review and branch protections.
 
+## Development Skill Routing
+
+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 |
+
+The channel skill may narrow authority, lifecycle, workspace, visibility, handoff, and evidence requirements. 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
 
 Before starting or continuing Feature implementation, verify in project documentation:
@@ -91,14 +108,9 @@ Hermes cannot approve a Feature for implementation or move a Task to `READY_FOR_
 
 ## Immediate Wave-Start Visibility Gate
 
-Before implementation begins on a newly claimed delivery wave, establish these Gitea checkpoints for **every Task** in that wave:
+Load `development-durable-wave-execution`, `development-branching-strategy`, and `development-gates` before claiming or starting a wave. Those skills own durable whole-wave claims, branch/worktree mechanics, immutable candidate identity, and exact-head review/CI behavior.
 
-1. Create a dedicated branch whose name includes the exact Task ID and concise purpose, and push it immediately.
+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.
-2. Open a pull request from that branch to the governed integration branch immediately after the branch exists. Do not wait for implementation, tests, review, or a finished diff.
-3. Put the Task ID, wave, planned scope, and current delivery state in the PR so the human owner and team can monitor progress from the beginning.
-4. Read back and record the branch ref, PR URL/number, exact head SHA, and base branch before substantive coding starts. Keep the same PR updated as commits are pushed.
-
-One Task requires one dedicated branch and one visible PR unless Architecture or the human owner explicitly approves a different grouping. Do not hide several independently deliverable Tasks behind a shared wave branch. If Gitea refuses a no-diff PR, create and push an empty kickoff commit—never a filler file change—then open the PR. A locally created worktree or unpushed branch does not satisfy this gate.
 
 ## Proactive Iteration Requirement
 
@@ -124,34 +136,17 @@ Use enough delivery history to avoid duplicate work and only relevant new activi
 
 ### Coding
 
-- implement only human-approved Features and their authorized tasks;
+Load the project-adopted engineering skill for the repository stack before editing. `development-monorepo-pnpm` owns pnpm/TypeScript workspace implementation, while `development-scripts` owns Taskfile, `.scripts/`, shell-wrapper, environment-validation, and Devbox conventions. Delivery adds only the approved requirement/Task boundary, traceability, and prohibition on unrelated refactoring or fabricated evidence.
-- 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.
 
 ### Unit testing
 
-- add or update tests with behavioral changes;
+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.
-- 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.
 
 ### Build and continuous integration
 
-Monitor local builds and Gitea Actions for:
+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.
 
-- compile/type failures;
+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.
-- 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.
 
 ### Per-project reusable CI base images
 

references/runtime-and-ci.md

@@ -104,7 +104,7 @@ the adopted project owns `corp-v1-<code>/corp-v1-<code>-base-images` as the reus
 
 ### 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. Provision every required development, integration-test, test, staging, preview, or production resource under the the adopted project application on Gondor through the `corp-v1-<code>/gondor-v1-tmpl-<code>` → `corp-v1-<code>/gondor-v1-<code>` GitOps chain.
+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.

tests/test_development_skill_routing.py

@@ -0,0 +1,33 @@
+from pathlib import Path
+
+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")
+
+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",
+}
+
+
+def test_delivery_reference_routes_reusable_development_procedures() -> None:
+    assert "## Development Skill Routing" in SKILL
+    for name, url in REFERENCES.items():
+        assert name in SKILL
+        assert url in SKILL
+
+
+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
+
+
+def test_gitops_reference_requires_one_environment_per_repository() -> None:
+    assert "development-gitops-argo-cd-gondor-v1" in RUNTIME
+    assert "one repository per environment" in RUNTIME