feat: define delivery channel operations

SKILL.md

@@ -1,50 +1,180 @@
 ---
 name: corp-v1-channel-delivery
-description: "Use as the central reference when defining or adopting project-scoped operating guidance for a Corp v1 delivery channel. This repository is initial setup only; detailed purpose and procedures remain pending steering walkthrough."
+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: 0.1.0
+version: 1.0.0
 author: Hermes Agent
 license: MIT
 metadata:
   hermes:
-    tags: [corp-v1, discord, channel, delivery, reference]
+    tags: [corp-v1, discord, channel, delivery, coding, testing, ci]
     related_skills: [corp-v1-steering-committee, home-v1-discord]
 ---
 
-# Corp v1 Delivery Channel Reference
+# Corp v1 Delivery Channel
 
 ## Overview
 
-This is the central source skill for the `delivery` channel created for each Corp v1 project.
+This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels and turns approved requirements and architecture into implemented, tested, integrated, documented work.
 
-**Current status: setup only.** Its detailed purpose, responsibilities, procedures, artifacts, authority boundaries, and verification rules are intentionally not defined yet. They will be agreed in a separate walkthrough before promotion beyond version `0.1.0`.
+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.
 
 ## When to Use
 
-Use this source when walking through the future `delivery` channel skill, creating a reviewed project copy after finalization, or comparing an adopted copy with its source.
+Use this skill when:
 
-Do not use this version as complete operating guidance for a live project channel.
+- 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.
 
-## Adoption Contract
+Do not use it to silently choose between contradictory requirements or architecture decisions, approve releases, or bypass review and branch protections.
 
-After finalization, `corp-v1-steering-committee` requires a project copy named `corp-v1-channel-delivery--<code>` under `corp-v1-<code>-skills-code-agent`. Adoption preserves source history and attribution, applies project context, validates the result, and records the source branch and commit.
+## Approved Information Boundary
 
-Creating existing-project copies is explicitly deferred until separately requested.
+Inspect only the project's four channels:
 
-## Purpose Definition Pending
+```text
+corp-v1-<code>-general
+corp-v1-<code>-architecture
+corp-v1-<code>-delivery
+corp-v1-<code>-releases
+```
 
-The walkthrough must define channel outcomes, responsibilities, activities, artifacts, cross-channel relationships, applicable engineering skills, synchronization behavior, approval boundaries, and verification criteria.
+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 approved/authorized scope;
+- 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.
+
+## 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.
+
+## Synchronization Workflow
+
+1. Read new same-project activity and enough delivery history to avoid duplicates.
+2. Identify executable work, CI failures, blockers, requirements/ADR implications, and documentation drift.
+3. Load all applicable project engineering skills.
+4. Perform safe authorized work when scope and expected outcome are clear.
+5. Escalate uncertainty or contradiction rather than selecting direction.
+6. Verify local and remote results.
+7. Maintain Ways of Working and Engineering pages when durable practice changed.
+8. Post a concise update with work completed, evidence, blockers, and required decisions; otherwise stay silent.
+
+## 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. Treating this setup scaffold as finalized policy.
+1. Patching symptoms before understanding root cause.
-2. Creating project copies before the requested migration.
+2. Changing requirements or architecture implicitly through code.
-3. Defining behavior indirectly instead of completing the walkthrough.
+3. Claiming CI success from a local build.
-4. Losing source history or attribution during adoption.
+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.
 
 ## Verification Checklist
 
-- [ ] Repository exists under `home-v1-skills-code-agent`.
+- [ ] Only same-project channels and repositories were used.
-- [ ] Default branch is `test`.
+- [ ] Work maps to approved requirements/architecture.
-- [ ] Skill name is `corp-v1-channel-delivery`.
+- [ ] Applicable project skills were loaded.
-- [ ] Version remains `0.1.0` until purpose is finalized.
+- [ ] Tests and builds were actually run.
-- [ ] No project-scoped copy was created during setup.
+- [ ] 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.