feat: define delivery channel operations
This commit is contained in:
@@ -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."
|
||||
version: 0.1.0
|
||||
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.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.
|
||||
2. Creating project copies before the requested migration.
|
||||
3. Defining behavior indirectly instead of completing the walkthrough.
|
||||
4. Losing source history or attribution during adoption.
|
||||
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.
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
- [ ] Repository exists under `home-v1-skills-code-agent`.
|
||||
- [ ] Default branch is `test`.
|
||||
- [ ] Skill name is `corp-v1-channel-delivery`.
|
||||
- [ ] Version remains `0.1.0` until purpose is finalized.
|
||||
- [ ] No project-scoped copy was created during setup.
|
||||
- [ ] Only same-project channels and repositories were used.
|
||||
- [ ] Work maps to approved requirements/architecture.
|
||||
- [ ] 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.
|
||||
|
||||
Reference in New Issue
Block a user