docs: route Delivery through reusable development skills
Validated development-skill routing and reference corrections.
This commit was merged in pull request #8.
This commit is contained in:
@@ -1,13 +1,13 @@
|
||||
---
|
||||
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.11.0
|
||||
version: 1.11.1
|
||||
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
|
||||
@@ -75,6 +75,23 @@ Use this skill when:
|
||||
|
||||
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:
|
||||
@@ -91,14 +108,9 @@ 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
|
||||
|
||||
@@ -124,34 +136,17 @@ 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 only requires that the resulting tests map to approved acceptance evidence and that real commands/results are retained.
|
||||
|
||||
### 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/integration, lint/format, dependency, packaging, container, chart, workflow, and artifact failures. A green local build is never remote CI evidence.
|
||||
|
||||
### Per-project reusable CI base images
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ Update these pages from verified project practice. Do not document a planned pro
|
||||
|
||||
## Synchronization Workflow
|
||||
|
||||
When planning documentation, Architecture structure, or Kanban state changes while implementation remains gated, follow [`references/planning-artifact-reconciliation.md`](references/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.
|
||||
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.
|
||||
|
||||
@@ -104,7 +104,7 @@ the adopted project owns `corp-v1-<code>/corp-v1-<code>-base-images` as the reus
|
||||
|
||||
### 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. Provision every required development, integration-test, test, staging, preview, or production resource under the the adopted project application on Gondor through the `corp-v1-<code>/gondor-v1-tmpl-<code>` → `corp-v1-<code>/gondor-v1-<code>` GitOps chain.
|
||||
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.
|
||||
- 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. Run resource-dependent tests through a restricted trigger as private in-cluster Jobs/Workflows; do not expose PostgreSQL or another internal resource through Ingress, NodePort, LoadBalancer, or a runner-accessible public endpoint.
|
||||
|
||||
@@ -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
|
||||
Reference in New Issue
Block a user