corp-v1-channel-delivery/SKILL.md

name, description, version, author, license, metadata

name	description	version	author	license	metadata
corp-v1-channel-delivery	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.	1.12.3	Hermes Agent	MIT	hermes tags related_skills corp-v1 discord channel delivery coding testing ci 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.

Ideas, Epics, and Features:

IN_BACKLOG → IN_DESIGN → READY_FOR_DELIVERY → IN_DELIVERY → TO_BE_RELEASED → DONE

Tasks:

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.

Its scope includes coding, unit testing, builds, continuous integration, review readiness, delivery blockers, and maintenance of the project documentation's Ways of Working and Engineering areas.

Delivery owns unit testing only. The project's standalone E2E repository under its UAT channel owns every non-unit suite and its fixtures, configuration, runner, and evidence: integration, browser, E2E, acceptance, security-boundary, performance, runtime-budget, container/image, Helm/rendering, smoke, regression, and deployed-environment testing. Delivery must not maintain or execute those suites in the application repository. It consumes UAT failures as defect evidence, fixes application code with unit-first TTD, and hands the corrected deployed tuple back to UAT.

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.

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:

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 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:

• Feature ID and parent Epic;
• explicit human Approved for Implementation evidence;
• 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 human Kanban Focus admission.

Hermes cannot approve a Feature for implementation or move a Task to READY_FOR_DELIVERY. Once that exact state exists, Hermes must not require a second Focus-admission decision; Delivery claims the Task by moving it to IN_PROGRESS.

Immediate Wave-Start Visibility Gate

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.

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

Inspect only the project's seven channels:

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

Use enough delivery history to avoid duplicate work and only relevant new activity from the other channels. Never inspect another project.

Delivery Responsibilities

Coding

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

Load development-method-ttd for every behavior change, defect fix, or refactor. It owns RED–GREEN–REFACTOR mechanics, focused-test progression, and test-design anti-patterns. Delivery requires unit tests to map to approved acceptance evidence and retains their real commands/results. UAT owns every non-unit test required to prove that evidence outside the unit boundary.

Build and continuous integration

Load development-gates before candidate review, remote CI, merge, or integration validation, and load development-integrity before reporting their status. These skills own exact-head identity, attempt integrity, base-drift handling, candidate-versus-integration separation, and honest checkpoint wording.

Delivery still monitors repository-specific compile/type, unit-test, lint/format, dependency, packaging, workflow, and artifact-publication failures. Non-unit, container-runtime, chart-rendering, browser, integration, and acceptance failures arrive as UAT evidence and are routed back for application remediation. A green local build is never remote CI evidence.

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 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 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, 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

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.

Failure-Repair Workflow

When a build or CI failure is observed:

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 unit testing — commands, unit-test fixtures, debugging, and the handoff to UAT for every 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.

UI/UX Coordination

For frontend-affecting work, Delivery requires the approved UI/UX design package, exact Penpot links, responsive/state behavior, accessibility criteria, and mapped tasks. Delivery reports implementation deviations to UI/UX with concrete evidence rather than silently changing the approved experience.

Synchronization Workflow

1. Read new same-project activity and enough delivery history to avoid duplicates.
2. Verify human Approved for Implementation evidence, exact Task READY_FOR_DELIVERY state, task dependencies, and target version before task work.
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.

Authority and Escalation

May autonomously:

• run unit tests, builds, and read-only checks; non-unit suites run through UAT;
• repair clear CI/build defects within authorized scope;
• add unit tests for an approved behavior and request non-unit coverage from UAT;
• maintain accurate delivery documentation;
• prepare branches/commits/PRs where the project workflow authorizes it.

Requires approval before:

• changing requirements or architecture to make tests pass;
• merging protected changes;
• deploying or releasing;
• changing secrets, permissions, costs, external services, or destructive resources;
• suppressing required quality/security gates.

Evidence Requirements

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
• Status, wave, blocker, CI, and completion wording: references/status-and-reporting.md
• Workspace, branch, PR, and visibility entry: references/repository-entry-and-visibility.md
• Toolchain contexts, CI, images, and runtime placement: references/runtime-and-ci.md
• Failure repair and Delivery-owned documentation: references/failure-and-documentation.md
• Planning-artifact reconciliation: references/planning-artifact-reconciliation.md
• Gate failures, resumptions, blockers, merge, and completion: 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.
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.