corp-v1-channel-delivery/SKILL.md

---
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.6.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]
---

# Corp v1 Delivery Channel

## Overview

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 which a human team member separately admitted to Kanban Focus `InBacklog`.

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

Load the global `documentation-docusaurus` skill from `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus` before changing documentation structure, navigation, Markdown/MDX, Docusaurus configuration, or builds.

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:

```text
HL_V1_SSO_EMAIL
HL_V1_SSO_PASSWORD
```

Secret availability is capability, not authorization. Verify the destination origin and task purpose before login. Never print, inspect, log, hash, serialize, paste, screenshot, or persist either value; never place a value in a command line, URL, file, repository, prompt, Discord message, browser console, test fixture, CI output, or generated artifact. Never ask a human to paste a value into chat. If a variable is unavailable, report only its missing name and request Bitwarden/gateway injection. Login does not authorize account recovery, MFA or credential changes, permission changes, billing, spending, destructive operations, or access outside the approved project task.

## When to Use

Use this skill when:

- operating in `corp-v1-<code>-delivery`;
- running its recurring synchronization job;
- implementing or reviewing project code;
- adding or repairing unit tests;
- diagnosing build or CI failures;
- checking implementation against requirements and ADRs;
- maintaining delivery-oriented documentation.

Do not use it to silently choose between contradictory requirements or architecture decisions, approve releases, or bypass review and branch protections.

## 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.
- explicit human Kanban approval admitting the exact task to Focus `InBacklog`.

Hermes cannot approve a Feature for implementation or admit a task to Focus `InBacklog`. If the gate is incomplete, improve safe delivery-readiness documentation or raise the exact missing decision in `architecture`; do not start code.

## 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 Kanban Focus `InBacklog`, backed by architecture's approved task/dependency plan, and update progress in project documentation.

## Approved Information Boundary

Inspect only the project's seven channels:

```text
corp-v1-<code>-general
corp-v1-<code>-scope
corp-v1-<code>-architecture
corp-v1-<code>-ui-ux
corp-v1-<code>-kanban
corp-v1-<code>-delivery
corp-v1-<code>-releases
```

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

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

### 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 platform's storage operations skill. 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 testing** — commands, unit/integration testing, fixtures, and debugging.
3. **Build and continuous integration** — pipelines, checks, artifacts, runners, and failure diagnosis.
4. **Packaging and deployment preparation** — containers, Helm/GitOps interfaces, configuration, and release inputs.
5. **Operations and troubleshooting** — observability, known failure modes, recovery checks, and evidence collection.

Update these pages from verified project practice. Do not document a planned process as already operational.

## 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, explicit human Kanban Focus `InBacklog` admission, 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 tests/builds/read-only checks;
- repair clear CI/build defects within authorized scope;
- add tests for an approved behavior;
- 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.

## 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 have explicit human Focus `InBacklog` admission.
- [ ] 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.