Merge pull request 'policy: retain artifact validation in Delivery' (#10) from policy/artifact-validation-boundary into test

Validated development-skill routing and reference corrections.

SKILL.md

@@ -1,19 +1,23 @@
 ---
 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.10.0
+version: 1.13.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]
+    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
 
 ## Overview
 
+## Hermes Kanban direct-link contract
+
+Whenever a response mentions a Hermes Kanban board, initiative, card, or task, it must include a direct dashboard link in the form `[descriptive board label](<dashboard-public-url>/kanban?board=<board-slug>)`. Resolve the dashboard public URL and exact board slug before reporting; never provide only a board name, slug, card count, “visible cards,” or “available in the dashboard.” If no task-specific deep link exists, link the board and include the exact task ID or title in the same statement. Project-adopted skills must replace this generic form with their verified project board URL.
+
 ## 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.
@@ -42,6 +46,8 @@ This skill owns delivery health for a Corp v1 project. It monitors the project's
 
 Its scope includes coding, unit testing, builds, continuous integration, review readiness, delivery blockers, and maintenance of the project documentation's `Ways of Working` and `Engineering` areas.
 
+Delivery owns application **unit testing only** plus static/build-time validation of the application artifacts it publishes: Dockerfiles, image/container contracts, publication records/workflows, and Helm chart linting/rendering/packaging. The project's standalone E2E repository under its UAT channel owns every functional non-unit suite and its fixtures, configuration, runner, and evidence: integration, browser, E2E, acceptance, security-boundary, performance, runtime-budget, smoke, regression, and deployed-environment testing. Delivery must not maintain or execute functional non-unit suites in the application repository. E2E must not install Helm or build/publish application images. It consumes UAT failures as defect evidence, fixes application code with unit-first TTD, and hands the corrected deployed tuple back to UAT.
+
 Load the global `documentation-docusaurus` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus` before changing documentation structure, navigation, Markdown/MDX, Docusaurus configuration, or builds.
 
 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.
@@ -64,13 +70,30 @@ Use this skill when:
 - operating in `corp-v1-<code>-delivery`;
 - running its recurring synchronization job;
 - implementing or reviewing project code;
-- adding or repairing unit tests;
+- adding or repairing unit tests only; non-unit coverage is routed to the project's UAT channel and standalone E2E repository;
 - diagnosing build or CI failures;
 - checking implementation against requirements and ADRs;
 - maintaining delivery-oriented documentation.
 
 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. 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.
+
 ## Implementation Entry Gate
 
 Before starting or continuing Feature implementation, verify in project documentation:
@@ -87,18 +110,13 @@ 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.
-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.
+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.
+Every delivery iteration must complete at least one useful, safe activity for an implementation-approved Feature or delivery-health need: implement an unblocked task, add unit tests, diagnose/fix CI, improve build tooling, update real Ways of Working/Engineering guidance, verify dependency readiness, or document a concrete blocker with evidence. Never create filler changes. Select work only from exact Tasks in `READY_FOR_DELIVERY`; claiming one moves it to `IN_PROGRESS`. Keep architecture's approved task/dependency plan and project documentation current.
 
 ## Approved Information Boundary
 
@@ -120,46 +138,29 @@ Use enough delivery history to avoid duplicate work and only relevant new activi
 
 ### 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 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.
 
 ### 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` 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
 
-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;
-- 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.
+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.
+- Keep one folder per image, with its Dockerfile, machine-readable version/platform metadata, usage documentation, build helper, and static publication contract. Runtime smoke belongs to UAT.
 - Pin the upstream base by digest and assert exact runtime/tool versions, architecture, numeric non-root identity, writable workspace, CA trust, Git, shell, and other required tools.
-- Build and smoke-test without registry credentials on pull requests. Publish only from the trusted integration branch using a narrowly scoped Harbor robot secret.
+- Build and perform static/unit validation without registry credentials on pull requests. Publish only from the trusted integration branch using a narrowly scoped Harbor robot secret; UAT validates the published digest at runtime.
 - Publish immutable full-source-SHA tags, read back the Harbor artifact digest, and consume the image from project workflows by digest—not `latest`, a mutable version tag, or an unverified local name.
 - Extend fail-closed tests to reject broad publication triggers, mutable tags, secret access from candidate/PR paths, shell interpolation, wrong digests, and reintroduced runtime setup actions.
 - Prefer the verified job image over repeated runtime or package-manager setup actions. Keep lockfile-frozen application dependency installation in the application repository; do not bake project dependencies into a generic base image.
-- Treat the first real Gitea build, runtime smoke test, Harbor publication, digest readback, and a consumer workflow at the exact candidate SHA as separate acceptance layers.
+- Treat the first real Gitea build, Harbor publication, digest readback, and consumer workflow at the exact candidate SHA as separate Delivery layers. Runtime smoke is a separate UAT layer.
 - Repair image or publication failures forward only. Preserve the last known-good digest for consumers until the replacement image and consuming workflow pass exact-head CI.
 
 ### Runtime-resource placement
@@ -211,7 +212,7 @@ Maintain two documentation areas.
 ### Engineering — five sections
 
 1. **Repository and workspace** — monorepo/application/package structure and local prerequisites.
-2. **Development and testing** — commands, unit/integration testing, fixtures, and debugging.
+2. **Development and unit testing** — commands, unit-test fixtures, debugging, Delivery artifact validation, and the handoff to UAT for every functional non-unit suite.
 3. **Build and continuous integration** — pipelines, checks, artifacts, runners, and failure diagnosis.
 4. **Packaging and deployment preparation** — containers, Helm/GitOps interfaces, configuration, and release inputs.
 5. **Operations and troubleshooting** — observability, known failure modes, recovery checks, and evidence collection.
@@ -238,9 +239,9 @@ For frontend-affecting work, Delivery requires the approved UI/UX design package
 
 May autonomously:
 
-- run tests/builds/read-only checks;
+- run unit tests, builds, 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.
 
@@ -256,6 +257,33 @@ Requires approval before:
 
 Include repository, branch, commit SHA, changed paths, commands, local results, CI run/task IDs and status, and relevant requirement/ADR references. Report blockers honestly.
 
+
+## Mined Project-Adoption Improvements
+
+## 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
+
+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.
+
+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.
+
+Load the matching detailed reference at the decision point—not from memory:
+
+- 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.
+
 ## Common Pitfalls
 
 1. Patching symptoms before understanding root cause.

references/common-pitfalls.md

@@ -0,0 +1,26 @@
+# the adopted project Delivery Pitfalls
+
+Load this reference when a gate fails, when work resumes after interruption, or before reporting a blocker, CI result, merge, or completion.
+
+## 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.

references/failure-and-documentation.md

@@ -0,0 +1,64 @@
+# the adopted project Failure and Documentation Operations
+
+Load this reference when repairing a failure or changing Delivery-owned project documentation.
+
+## 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.
+
+## 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 unit testing** — commands, unit-test fixtures, debugging, Delivery artifact validation, and the handoff to UAT for every functional non-unit suite.
+3. **Build and continuous integration** — pipelines, checks, artifacts, runners, and failure diagnosis.
+4. **Packaging and deployment preparation** — containers, Helm/GitOps interfaces, configuration, and release inputs.
+5. **Operations and troubleshooting** — observability, known failure modes, recovery checks, and evidence collection.
+
+Update these pages from verified project practice. Do not document a planned process as already operational.
+
+## 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.

references/planning-artifact-reconciliation.md

@@ -0,0 +1,38 @@
+# Planning-artifact reconciliation
+
+Use this procedure when Scope, Architecture, Kanban, Ways of Working, Engineering, or release-readiness documentation changes while Feature implementation remains gated.
+
+## Procedure
+
+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.
+
+## Evidence interpretation
+
+| Evidence | What it proves | What it does not prove |
+|---|---|---|
+| Documentation PR merged by a human | The reviewed documentation landed | Feature implementation approval |
+| Architecture hierarchy/validator passes | Documentation structure meets its contract | A proposed Feature has an accepted solution |
+| Kanban Board lists an item in ideation | The unfinished scope record is visible | Exact Task `READY_FOR_DELIVERY` handoff |
+| Documentation CI succeeds | That documentation head passed its checks | Application CI or release readiness |
+| Application baseline CI succeeds | The observed application head is healthy | A new Task PR, deployment, or release |
+
+## 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.

references/repository-entry-and-visibility.md

@@ -0,0 +1,59 @@
+# the adopted project Repository Entry and Visibility
+
+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.
+
+## Implementation Entry Gate
+
+Before claiming a Task for Feature implementation, verify in project documentation:
+
+- Feature ID and parent Epic;
+- exact `Approved for Implementation` evidence from the primary Architecture owner `the active project authority` or the active project authority as backup;
+- linked FRs/NFRs and accepted solution/ADR context;
+- task breakdown and dependencies;
+- target version and status;
+- acceptance evidence expected from delivery;
+- exact Task `READY_FOR_DELIVERY` evidence, which itself records Focus admission by the active project authority; and
+- an approved UI/UX package from the active UI/UX authority or the active project authority as backup when the task changes user-facing design.
+
+Delivery must verify the Feature decision and exact Task `READY_FOR_DELIVERY` state before initial coding, then claim the Task by moving it directly to `IN_PROGRESS`. Continue claimed work in `IN_PROGRESS` while retaining the original handoff evidence. Do not require a second Focus admission after `READY_FOR_DELIVERY` or infer missing evidence from broad delegation, silence, CI, a Board wave, or a planning status. When a record is absent, route the exact owning action to Scope, Architecture, or Kanban rather than creating an out-of-scope lifecycle or flow mutation inside an implementation change.
+
+## Immediate Wave-Start Visibility Gate
+
+Before any implementation or repository content change begins on a newly claimed the adopted project Task, establish and verify all of these Gitea checkpoints:
+
+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.
+4. Read the PR and remote ref back, then prove that the local branch name exactly equals the remote branch and PR head ref, the local kickoff commit equals the remote branch head, and the PR base is `test`.
+5. Only after the remote branch and visible pull request already exist and all identities match may Delivery edit tests, source, configuration, documentation, or other repository content.
+
+No repository file may be edited before this gate passes. A differently named local convenience branch that merely tracks the PR branch does not pass, because it hides the branch identity during status reporting and makes accidental publication to the wrong ref easier. When resuming an existing worktree, fetch the PR head explicitly, require the current local branch name to equal the PR head ref, and fast-forward before editing; if the names differ, repair the local branch identity without force-pushing or creating a competing PR.
+
+One Task requires one dedicated branch and one visible PR unless the adopted project Architecture or the active project authority 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, unpushed branch, compare URL, or push without PR readback does not satisfy this gate.
+
+### Branch and pull-request naming contract
+
+For every the adopted project delivery Task, use this exact source-branch shape:
+
+```text
+<release>/<TASK_ID>-<short-explanation>-<attempt-digit>
+```
+
+Example:
+
+```text
+0.1.0/TASK-0049-persist-simulation-metadata-1
+```
+
+- `<release>` is the Task's exact target release, without a leading `v`. Do not derive it from a package manifest, invent it, or replace it with `unreleased`, `next`, or a wave label.
+- `<TASK_ID>` is the exact Task ID, preserving its uppercase spelling.
+- `<short-explanation>` is a concise lowercase ASCII kebab-case description (`a-z`, `0-9`, and single hyphens only).
+- `<attempt-digit>` is an unpadded positive decimal attempt number. Start at `1`; increment it only when a new branch/PR attempt is required. Never reuse an attempt number for the same release, Task, and explanation.
+- The complete branch must pass `git check-ref-format --branch`, contain exactly one `/`, and remain a valid Gitea branch ref. Spaces, repeated separators, `..`, `@{`, backslash, control characters, and the Git-forbidden characters `~ ^ : ? * [` are not allowed.
+- Resolve collisions against freshly fetched local and remote refs before creating the branch. Never force-push or repurpose an earlier attempt.
+
+The Gitea pull-request title must exactly equal the source branch name. Gitea's PR API treats the title as a string rather than a Git ref, but using the exact branch value provides one unambiguous release/Task/attempt identity across the branch list, PR list, API, CI, and evidence records. Do not prepend `feat:`, `fix:`, an emoji, a wave label, or other prose to the title.
+
+Before creating the PR, verify the Gitea technical prerequisites: the source branch is pushed, the base branch is exactly `test`, head and base differ, the branch contains a commit not already in `test`, and no open PR already exists for the same head/base pair. Create the PR with explicit `title`, `head`, `base`, and `body` fields. The body must record the Task ID, release, attempt, wave, planned scope, Task state, validation plan, and requirement/ADR links. Read the PR back and require exact title, head ref/SHA, and `test` base; a compare URL or successful API response alone is not evidence that the PR contract is satisfied.

references/runtime-and-ci.md

@@ -0,0 +1,113 @@
+# the adopted project Runtime and CI
+
+Load this reference before login, toolchain execution, CI work, image publication, or Gondor resource work.
+
+## 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, Nginx binaries, and package-manager download caches. Browser/Playwright dependencies for non-unit suites belong to the UAT workspace and E2E repository. 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.
+
+
+## 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.
+
+### 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.
+
+### Build and continuous integration
+
+Monitor local builds and Gitea Actions for:
+
+- compile/type failures;
+- unit-test failures and UAT-reported non-unit 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.
+
+### 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.
+
+### 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 static publication contract. Runtime smoke belongs to UAT.
+- Pin the upstream base by digest and assert exact runtime/tool versions, architecture, numeric non-root identity, writable workspace, CA trust, Git, shell, and other required tools.
+- Build and perform static/unit validation without registry credentials on pull requests. Publish only from the trusted `test` branch using a narrowly scoped Harbor robot secret; UAT validates the published digest at runtime.
+- Publish immutable full-source-SHA tags, read back the Harbor artifact digest, and consume the image from 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, Harbor publication, digest readback, and consumer workflow at the exact PR-head SHA as separate Delivery layers. Runtime smoke is a separate UAT layer.
+- Repair image or publication failures forward only. Preserve the last known-good digest for consumers until the replacement image and consuming workflow pass exact-head CI.
+
+### 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.
+- Delivery CI may orchestrate exact-head unit/build validation, but it must not start application runtime-resource service containers or receive application-resource credentials. Harmless process-local unit-test doubles and build tools are not runtime resources. UAT owns resource-dependent tests and their restricted execution; Delivery only provisions an approved development dependency and hands its exact identity to UAT. 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.

references/status-and-reporting.md

@@ -0,0 +1,81 @@
+# the adopted project Status and Reporting
+
+Load this reference when reading Task states or reporting Task, wave, CI, blocker, or completion status.
+
+## 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”.

references/task-delivery-gates.md

@@ -0,0 +1,100 @@
+# 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.
+
+## End-to-End Task Delivery Gates
+
+These gates are mandatory and ordered. Each `GATE_###_NAME` code is the stable identifier used in communication and evidence. Hermes must not skip ahead, combine evidence from different revisions, or start the next Task before `GATE_005_TASK_POST_MERGE` passes. The three repositories used by this process are:
+
+- 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>`.
+
+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/`.
+
+Hermes main session owns the Task, performs implementation and exact-head review, and communicates with the active project authority. Local repository tools execute deterministic commands. Gitea Actions runs remote CI. Gondor/GitOps is used only by an approved deployment or Release process. Cron never owns or continues a Task. No implementation or review subagent may work on the selected Task.
+
+Verification is part of each stage, not a separate end checklist. Before leaving a stage, pass its **Exit gate** and retain the evidence named there. Every Delivery progress, blocker, CI, merge, handoff, and completion update must name the active gate code and title. When a gate passes, report the passed gate code and the next gate code. At every stage, use only the adopted project's seven project channels, load the references and engineering skills required for that action, route contradictions instead of guessing, and report failures with the exact command, file, test, or CI job.
+
+### 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.
+
+### 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.
+
+**Runtime:** Hermes main session verifies eligibility, creates and reads back the application branch and PR without editing repository content, then creates the documentation branch and PR, updates the Task file, runs documentation checks, and merges the documentation PR only after its checks pass. Gitea Actions runs remote checks. Do not use HermesSubAgent or cron.
+
+**Required work:** Verify that the Task file says `READY_FOR_DELIVERY`, the Board places the Task in the current wave, dependencies have reached the states required by the Task, the parent Feature has implementation approval, and required Architecture, requirements, target release, and UI/UX inputs exist. Inspect only the adopted project's seven project channels and select exactly one Task. Create the Task workspace and fresh application/documentation clones before repository mutation. Fetch application `test`; create the exact local application branch; use an empty kickoff commit if Gitea requires a difference; push; open the application PR; and verify that local branch, remote branch, PR head branch, local head, remote head, PR title, and `test` base match. Then use the Task's documentation clone to add the hash-linked `READY_FOR_DELIVERY` to `IN_PROGRESS` event with actor, time, Task, wave, application branch/PR evidence, previous hash, and new hash, and merge that documentation change.
+
+**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.
+
+### Stage 2 — `GATE_002_TASK_PLAN` — Plan the Task
+
+**Repository and branch:** Read Task, requirement, Architecture, and UI/UX files from the Task's `documentation/` clone at `test`; keep implementation notes and changes in the Task's `application/` clone on the existing application Task branch.
+
+**Runtime:** Hermes main session inspects documentation and application code. Do not use HermesSubAgent.
+
+**Required work:** Load the project engineering skills needed by the Task. Map each acceptance criterion to affected production code, a named test, edge and failure cases, security boundaries, build or artifact evidence, and its requirement or Architecture reference.
+
+**Exit gate:** Every criterion has a checkable proof. A contradiction stops implementation and goes to the responsible Scope, Architecture, UI/UX, Kanban, or Release owner.
+
+### Stage 3 — `GATE_003_TASK_IMPLEMENTATION` — Implement and Review the Task
+
+**Repository and branch:** Use `corp-v1-<code>-delivery/workspace/<TASK_ID>/application/` on the existing application Task branch and PR. Application source, unit tests, configuration, application-documentation changes, builds, and image/container/Helm artifact validation stay in that clone and branch. Every functional non-unit suite stays in the UAT-owned E2E repository. If a separate review checkout or output is needed, create and use `review/` under the same Task directory.
+
+**Runtime:** Hermes main session runs the implementation and review loops with local repository tools inside the selected Task directory. Create and use optional `review/`, `cache/`, `tmp/`, `logs/`, or `artifacts/` folders only when the current activity needs them. Repeat environment and real-working-directory preflight in every foreground shell, review checkout, background process, main-session review command, and CI job. Do not use an implementation or review subagent, human-review dependency, or cron to satisfy this gate.
+
+**Required work:**
+
+1. Resolve the real working directory and verify it is inside `corp-v1-<code>-delivery/workspace/<TASK_ID>/`; then verify branch and PR identity, repository state, required tools and committed versions, and required environment-variable names without printing values. For Node/pnpm work, check the resolved `node` and `pnpm` commands and versions. Delivery unit tests use process-local fakes and must not start runtime services; UAT owns resource-dependent testing.
+2. For a defect, write or identify an exact named unit test and show that it fails for the expected product reason before repair. For new behavior, add a failing unit test first when practical and request the required non-unit coverage from UAT. Syntax, tooling, environment, or credentials errors do not count as product evidence.
+3. Implement only the approved Task, one behavior slice at a time. Keep the diff small, cover normal, edge, and failure behavior, avoid unrelated refactors, and repair forward without reverting valid work.
+4. Run all applicable focused and full unit tests, lint, format checks, typecheck or compile, production build, production dependency audit, static checks, generated-artifact checks, and Delivery-owned Dockerfile/image/container/publication/Helm artifact validations, plus `git diff --check` and repository-state checks. Do not run functional integration, browser, security-boundary, performance, or acceptance suites in Delivery; request and consume those results from UAT.
+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.
+
+**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.
+
+### 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.
+
+**Required work:**
+
+1. Verify that every required Delivery CI job—unit tests, lint, typecheck, build, static security checks, and artifact publication 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.
+
+**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`.
+
+### Stage 5 — `GATE_005_TASK_POST_MERGE` — Verify Integration and Hand Off the Task
+
+**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.
+
+**Required work:**
+
+1. Verify every required application unit-test/build job, container build, immutable image publication, registry digest readback, and artifact check on the exact application `test` integration revision. PR-head CI cannot replace post-merge integration evidence.
+2. Add the hash-linked `IN_PROGRESS` to `TO_BE_RELEASED` event with the merged application PR, integration revision, successful integration CI, publication evidence when required, and acceptance evidence.
+3. Update Ways of Working or Engineering documentation only when this Task changed how the project actually works.
+4. Validate, review, merge, and read back the documentation handoff PR.
+
+**Exit gate:** Every required post-merge unit-test, build, and publication job succeeds on the exact application `test` revision; the documentation PR is merged; and the Task file on remote documentation `test` says `TO_BE_RELEASED`. Only then may Delivery call the Task delivered. Release execution and the later `DONE` transition belong to `corp-v1-channel-releases-<code>`, not this Delivery process.
+
+### Stage 6 — `GATE_006_NEXT_TASK` — Pick the Next Task
+
+**Repository and branch:** Read refreshed documentation `test` and the Board from the completed Task's `documentation/` clone. Do not reuse that Task directory for another Task and create no new branch until the next Task passes `GATE_001_PREP`, which creates its own workspace and fresh clones.
+
+**Runtime:** Hermes main session selects the next Task. Do not use cron or a subagent for selection.
+
+**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>`.

tests/test_development_skill_routing.py

@@ -0,0 +1,34 @@
+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
+    assert "the explicit project/channel overlay wins" 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