diff --git a/SKILL.md b/SKILL.md index 59a76da..ff5cc7c 100644 --- a/SKILL.md +++ b/SKILL.md @@ -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 diff --git a/references/failure-and-documentation.md b/references/failure-and-documentation.md index 2876f79..2fd6005 100644 --- a/references/failure-and-documentation.md +++ b/references/failure-and-documentation.md @@ -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. diff --git a/references/runtime-and-ci.md b/references/runtime-and-ci.md index d6bde81..0cab565 100644 --- a/references/runtime-and-ci.md +++ b/references/runtime-and-ci.md @@ -104,7 +104,7 @@ the adopted project owns `corp-v1-/corp-v1--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-/gondor-v1-tmpl-` → `corp-v1-/gondor-v1-` 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. diff --git a/tests/test_development_skill_routing.py b/tests/test_development_skill_routing.py new file mode 100644 index 0000000..c712581 --- /dev/null +++ b/tests/test_development_skill_routing.py @@ -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