Compare commits

...
Author SHA1 Message Date
jarvis-at-skic 3f8e13141e docs: reference shared channel workspace standard 2026-11-05 19:11:27 +00:00
jarvis-at-skic e5d00989e7 Merge pull request 'fix/a02-a04-global-gates' (#17) from fix/a02-a04-global-gates into test 2026-10-26 04:36:20 -07:00
jarvis-at-skic 818869fae9 fix: retain global review precedence in entry guidance 2026-10-26 11:34:06 +00:00
jarvis-at-skic 35f0a7259c fix: align Central independent review and base invalidation gates 2026-10-26 11:31:49 +00:00
jarvis-at-skic 8c39ebe70e Merge pull request 'fix: Delivery source identity and bounded helper routing' (#16) from fix/delivery-source-identity-t3c6f0036 into test 2026-10-26 03:26:59 -07:00
jarvis-at-skic 0776bacd25 test: align expected version with source identity release 2026-10-26 10:24:59 +00:00
jarvis-at-skic 9d1a6dd44d fix: qualify Delivery sources and preserve compatibility 2026-10-26 10:22:35 +00:00
jarvis-at-skic 2e7f6618b6 chore: open scoped Delivery source correction 2026-10-26 10:17:40 +00:00
jarvis-at-skic db3115aa86 Merge pull request 'Implement Delivery responsibility dispositions: channel-delivery-skic' (#15) from refactor/dispositions-7c5c1457 into test 2026-10-23 01:16:08 -07:00
jarvis-at-skic 1bff2cefab refactor: implement concrete Delivery responsibility dispositions 2026-10-23 08:11:40 +00:00
jarvis-at-skic cb6b41f1a5 chore: open scoped disposition implementation 2026-10-23 07:53:07 +00:00
jarvis-at-skic a1741dc061 Merge pull request 'Implement full Delivery program: channel-delivery-skic' (#14) from refactor/delivery-full-program into test 2026-10-22 23:39:47 -07:00
jarvis-at-skic 65e546c448 refactor: implement governed Delivery program contracts 2026-10-23 06:39:27 +00:00
jarvis-at-skic c306ea4794 Merge pull request 'refactor: implement bounded Delivery existing-owner simplification' (#13) from refactor/delivery-existing-owners into test 2026-10-22 22:16:23 -07:00
jarvis-at-skic de2e201c4e refactor: simplify Delivery through existing procedure owners 2026-10-23 05:12:21 +00:00
jarvis-at-skic 225ae3b068 Merge pull request 'docs: canonical SKIC channel skill naming' (#12) from docs/canonical-skic-reference-names into test 2026-10-21 10:58:12 -07:00
jarvis-at-skic 5068145048 docs: reconcile canonical SKIC channel skill names 2026-10-21 17:56:57 +00:00
jarvis-at-skic b45dc2d833 Merge pull request 'docs: promote reusable AeroSim channel lessons' (#11) from docs/aerosim-reference-lessons-20261020 into test 2026-10-20 11:42:59 -07:00
jarvis-at-skic 5a0949658d docs: promote reusable AeroSim channel lessons 2026-10-20 18:42:39 +00:00
jarvis-at-skic 0bf71b905f Merge pull request 'policy: retain artifact validation in Delivery' (#10) from policy/artifact-validation-boundary into test 2026-09-26 05:15:23 -07:00
jarvis-at-skic 36ae5f50e4 policy: retain artifact validation in Delivery 2026-09-26 12:02:14 +00:00
jarvis-at-skic 5ead0aeabf Merge pull request 'policy: limit Delivery to unit testing' (#9) from policy/unit-tests-only into test 2026-09-26 03:35:30 -07:00
jarvis-at-skic 44e6aa5db6 policy: limit Delivery to unit testing 2026-09-26 10:10:52 +00:00
jarvis-at-skic c61c517aa0 docs: route Delivery through reusable development skills
Validated development-skill routing and reference corrections.
2026-09-23 12:49:39 -07:00
jarvis-at-skic d185f9b2d6 docs: clarify development skill precedence 2026-09-23 19:45:36 +00:00
jarvis-at-skic 6190262538 docs: route Delivery through development skills 2026-09-23 19:38:14 +00:00
jarvis-at-skic 52bee5e227 docs: require direct Hermes Kanban links 2026-09-23 19:04:57 +00:00
jarvis-at-skic c32f8c998d feat: mine reusable AeroSim channel lessons 2026-09-10 11:41:46 +00:00
jarvis-at-skic 2535089fdd Merge immediate wave-start visibility policy
Require a dedicated pushed branch and visible PR for each Task before substantive wave implementation.
2026-09-07 03:09:22 -07:00
jarvis-at-skic 573b79ae79 docs: require immediate task branches and PRs 2026-09-07 10:08:43 +00:00
jarvis-at-skic c9d4768cd2 chore: open delivery-start visibility change 2026-09-07 10:03:24 +00:00
jarvis-at-skic 6aaed69294 Merge pull request 'Clarify READY_FOR_DELIVERY handoff semantics' (#6) from fix/ready-for-delivery-handoff into test 2026-09-07 02:30:19 -07:00
jarvis-at-skic 1309b2726c docs: clarify READY_FOR_DELIVERY handoff 2026-09-07 08:53:32 +00:00
jarvis-at-skic 40afd90e08 Merge pull request #5 from fix/canonical-scope-status-vocabulary
fix: enforce canonical Scope status vocabulary
2026-09-07 01:40:02 -07:00
jarvis-at-skic ecfd588348 fix: enforce canonical scope status vocabulary 2026-09-07 08:26:24 +00:00
jarvis-at-skic d63fcb39c0 Merge pull request 'Standardize per-project reusable CI base images' (#4) from docs/base-image-ci-strategy into test 2026-09-06 08:02:10 -07:00
jarvis-at-skic 2815fdd4b3 docs: standardize project CI base images 2026-09-06 14:57:51 +00:00
jarvis-at-skic 74cbc689ea Merge pull request 'fix: make storage procedure discovery fail closed' (#3) from fix/storage-procedure-safety into test 2026-09-05 07:27:43 -07:00
jarvis-at-skic c44c140fcd fix: make storage procedure discovery fail closed 2026-09-05 14:27:42 +00:00
jarvis-at-skic 78c6218bd1 Merge pull request 'policy: place runtime resources on shared platforms' (#2) from policy/runtime-resources-on-platform into test 2026-09-05 07:22:16 -07:00
jarvis-at-skic 611809d5d7 policy: place runtime resources on shared platforms 2026-09-05 14:22:15 +00:00
jarvis-at-skic 9edfbba511 fix: update Corp v1 skill references 2026-09-04 12:55:02 +00:00
jarvis-at-skic 20cb78ce09 feat: add safe shared SSO login guidance (central delivery) 2026-08-27 20:50:36 +00:00
jarvis-at-skic b629921b6f Merge pull request 'feat: include UI/UX in Corp v1 channel coordination' (#1) from feat/ui-ux-channel-sync into test 2026-08-25 01:18:38 -07:00
24 changed files with 880 additions and 119 deletions

No files matched your search

+94 -119
View File
@@ -1,40 +1,57 @@
---
name: corp-v1-channel-delivery
name: channel-delivery-skic
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.5.1
version: 1.18.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]
related_skills: [channel-board-skic, discord, documentation-docusaurus-global, glossary-skic, development-durable-wave-execution, development-gates, development-integrity, development-method-ttd, development-branching-strategy, development-monorepo-pnpm, development-scripts, development-gitops-argo-cd-home-gondor-v1, ci-runtime-skic, delivery-docs, status-reporting-skic, development-security, development-security-skic, develop-monorepo-pnpm-app-skic, develop-monorepo-pnpm-package-skic]
---
# Corp v1 Delivery Channel
# SKIC Delivery Channel Reference
## Overview
## Hermes Kanban direct-link contract
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`.
Whenever a response mentions a Hermes Kanban board, initiative, card, or task, it must include a direct dashboard link in the form `[descriptive board label](<dashboard-public-url>/kanban?board=<board-slug>)`. Resolve the dashboard public URL and exact board slug before reporting; never provide only a board name, slug, card count, “visible cards,” or “available in the dashboard.” If no task-specific deep link exists, link the board and include the exact task ID or title in the same statement. Project-adopted skills must replace this generic form with their verified project board URL.
## Canonical Scope Status Vocabulary
Before reporting or changing lifecycle status, load [status-and-reporting.md](references/status-and-reporting.md) and read the project's current Ways of Working Scope page. That binding loads `status-reporting-skic` for canonical vocabulary and requested wave format; local Task gates retain gate codes, and `development-integrity` owns checkpoint claims. Delivery claims only an exact `READY_FOR_DELIVERY` Task into `IN_PROGRESS`, without a second Focus admission. `BLOCKED` remains a separate flag; merge/green CI is not `DONE`, and releasable application work normally ends Delivery at `TO_BE_RELEASED`.
This skill owns delivery health for a Corp v1 project. It monitors the project's `general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, `uat`, and `releases` channels and implements only tasks whose parent Feature has explicit human `Approved for Implementation` evidence and whose exact Task status is `READY_FOR_DELIVERY`. That status is the Focus-admitted pickup handoff; no separate post-status admission gate exists.
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.
Delivery owns application **unit testing only** plus static/build-time validation of the application artifacts it publishes: Dockerfiles, image/container contracts, publication records/workflows, and Helm chart linting/rendering/packaging. The project's standalone E2E repository under its UAT channel owns every functional non-unit suite and its fixtures, configuration, runner, and evidence: integration, browser, E2E, acceptance, security-boundary, performance, runtime-budget, smoke, regression, and deployed-environment testing. Delivery must not maintain or execute functional non-unit suites in the application repository. E2E must not install Helm or build/publish application images. It consumes UAT failures as defect evidence, fixes application code with unit-first TTD, and hands the corrected deployed tuple back to UAT.
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.
Before login or credential-bearing operations, load `development-security-skic` and `development-security`; stop if the authoritative Board policy cannot load. These owners govern the non-secret operation binding and exposure preflight, not new access authority.
## When to Use
Before branch or script work, load the generic `development-branching-strategy` / `development-scripts` base alongside the named project overlay; inherit only non-conflicting mechanics.
Use this skill when:
## Development Skill Routing
- 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.
Before changing an application's configuration, startup/readiness/shutdown contract or integration boundaries, load `develop-monorepo-pnpm-app-skic`. Before changing a shared package's public API/exports, dependency boundary, version compatibility or published contents, load `develop-monorepo-pnpm-package-skic`. For a change crossing both boundaries, load both and identify producer/consumer responsibilities; do not infer impact solely from a directory name.
Do not use it to silently choose between contradictory requirements or architecture decisions, approve releases, or bypass review and branch protections.
These are **draft review aids, not approved standards**. Contributor input and project adoption approval are separate from source publication or this routing. Use them to identify questions and evidence against the Task's already approved contract; do not enforce a proposed convention without the relevant human owner's approval. They complement `development-monorepo-pnpm`, which continues to own workspace/build/package-manager mechanics. Review, CI, one implementation worker per Task, deployment and test-ownership gates remain unchanged; loading a draft grants no execution authority. Authoritative drafts: https://gitea.lego-cloud.eu/skic-skills/develop-monorepo-pnpm-app-skic and https://gitea.lego-cloud.eu/skic-skills/develop-monorepo-pnpm-package-skic.
Before CI/runtime/repair work load `ci-runtime-skic`; before status/blocker reports load `status-reporting-skic`; before documentation load `delivery-docs`; before authenticated operations load `development-security-skic` and `development-security`. Supply the concrete bindings in the matching local reference. Authoritative helper repositories: https://gitea.lego-cloud.eu/skic-skills/ci-runtime-skic, https://gitea.lego-cloud.eu/global-skills/delivery-docs, https://gitea.lego-cloud.eu/skic-skills/status-reporting-skic, https://gitea.lego-cloud.eu/global-skills/development-security and https://gitea.lego-cloud.eu/skic-skills/development-security-skic.
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/global-skills/development-durable-wave-execution |
| immutable candidate review, exact-head CI, merge, and integration gates | `development-gates` | https://gitea.lego-cloud.eu/global-skills/development-gates |
| delivery, CI, blocker, and completion reporting | `development-integrity` | https://gitea.lego-cloud.eu/global-skills/development-integrity |
| behavior changes, defect fixes, and refactoring | `development-method-ttd` | https://gitea.lego-cloud.eu/global-skills/development-method-ttd |
| branch naming, worktrees, PR topology, and base synchronization | `development-branching-strategy` | https://gitea.lego-cloud.eu/global-skills/development-branching-strategy |
| pnpm/TypeScript monorepo implementation | `development-monorepo-pnpm` | https://gitea.lego-cloud.eu/global-skills/development-monorepo-pnpm |
| Taskfile, `.scripts/`, shell wrappers, environment validation, and Devbox | `development-scripts` | https://gitea.lego-cloud.eu/global-skills/development-scripts |
| Gondor Argo CD template, rendered desired state, and repository connection | `development-gitops-argo-cd-home-gondor-v1` | https://gitea.lego-cloud.eu/home-gondor-v1-skills/development-gitops-argo-cd-home-gondor-v1 |
The channel skill may narrow authority, lifecycle, workspace, visibility, handoff, and evidence requirements. Project bindings must not contradict global skills. The global `development-gates` contract governs independent review, review-before-push ordering, candidate/base identity and CI. Project overlays supply branch naming, human ownership, one implementation worker, visibility and existing merge/deployment/release authority without weakening these gates; inherit only 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
@@ -46,26 +63,31 @@ Before starting or continuing Feature implementation, verify in project document
- task breakdown and dependencies;
- target version and status;
- acceptance evidence expected from delivery.
- explicit human Kanban approval admitting the exact task to Focus `InBacklog`.
- exact Task `READY_FOR_DELIVERY` evidence, which itself records human Kanban Focus admission.
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.
Hermes cannot approve a Feature for implementation or move a Task to `READY_FOR_DELIVERY`. Once that exact state exists, Hermes must not require a second Focus-admission decision; Delivery claims the Task by moving it to `IN_PROGRESS`.
## Immediate Wave-Start Visibility Gate
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.
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
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:
Inspect only the project's eight 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
<code>-general
<code>-scope
<code>-architecture
<code>-ui-ux
<code>-kanban
<code>-delivery
<code>-uat
<code>-releases
```
Use enough delivery history to avoid duplicate work and only relevant new activity from the other channels. Never inspect another project.
@@ -74,80 +96,25 @@ 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 requires unit tests to map to approved acceptance evidence and retains their real commands/results. UAT owns every functional non-unit test required to prove that evidence outside the unit boundary; Delivery retains build-time image/container/Helm artifact validation.
### 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.
Delivery still monitors repository-specific compile/type, unit-test, lint/format, dependency, packaging, workflow, image/container contract, Helm chart, and artifact-publication failures. Functional non-unit browser, integration, performance, security-boundary, and acceptance failures arrive as UAT evidence and are routed back for application remediation. A green local build is never remote CI evidence.
A green local build is not proof that CI or delivery succeeded. Verify the actual remote branch and matching CI task/run.
Before base-image work, load `ci-runtime-skic` and [the project image binding](references/runtime-and-ci.md#per-project-reusable-ci-base-images).
## Failure-Repair Workflow
When a build or CI failure is observed:
Load [failure-and-documentation.md](references/failure-and-documentation.md#failure-repair-workflow) when a build or CI failure is observed. It binds `ci-runtime-skic` for safe repair and `status-reporting-skic` for blocker routing, with existing gate owners for exact-head verification. Keep repairable failures in the same Task/gate; pause only for the documented external, authority, decision or safety blocker. Never guess requirements or Architecture, weaken a gate or treat a blocker as passing.
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.
Before changing Ways of Working or Engineering, load `delivery-docs` and [the concrete documentation bindings](references/failure-and-documentation.md#documentation-ownership).
## UI/UX Coordination
@@ -156,7 +123,7 @@ For frontend-affecting work, Delivery requires the approved UI/UX design package
## 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.
2. Verify human `Approved for Implementation` evidence, exact Task `READY_FOR_DELIVERY` state, 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.
@@ -165,13 +132,15 @@ For frontend-affecting work, Delivery requires the approved UI/UX design package
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.
Do not silently choose between contradictory requirements or Architecture decisions, approve releases, or bypass review/branch protections.
## Authority and Escalation
May autonomously:
- run tests/builds/read-only checks;
- run unit tests, builds, Delivery artifact validations, and read-only checks; functional non-unit suites run through UAT;
- repair clear CI/build defects within authorized scope;
- add tests for an approved behavior;
- add unit tests for an approved behavior and request non-unit coverage from UAT;
- maintain accurate delivery documentation;
- prepare branches/commits/PRs where the project workflow authorizes it.
@@ -187,30 +156,36 @@ Requires approval before:
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.
## Mined Project-Adoption Improvements
## Verification Checklist
Review provenance and exclusions: [AeroSim lessons review](references/aerosim-lessons-review.md).
- [ ] 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.
## Dedicated Project Channel Workspace
Every project adoption must bind this channel to a dedicated local workspace under the active working root. Keep clones, worktrees, plans, reports, screenshots, generated artifacts, retained logs, and channel inputs inside that channel root. Use run-unique or task-specific children under `workspace/`; keep durable project truth in approved repositories. A local folder boundary organizes execution only—it neither broadens authority nor replaces remote evidence. Delivery adoptions should additionally use a channel-level `cache/` for reusable pinned toolchains and dependencies, while keeping Task evidence isolated by Task.
## Decision-point references
Before selecting/continuing/reviewing/merging/handoff load [Task gates](references/task-delivery-gates.md); before branch/PR work load [repository entry](references/repository-entry-and-visibility.md). Before commands, CI, images or resource work load [runtime bindings](references/runtime-and-ci.md); before failure repair/docs load [failure/docs bindings](references/failure-and-documentation.md). Before planning changes load [planning reconciliation](references/planning-artifact-reconciliation.md); on failed/resumed gates load [exception checks](references/common-pitfalls.md).
Project adoptions may narrow implementation execution to a main session or prohibit implementation subagents/cron. Preserve that overlay without prohibiting independent read-only review; this reference grants no account recovery, permission, merge, release or deployment authority. Keep exactly one Task active unless explicit project authority defines another safe model. Freeze Task/branch/PR identity and retain exact-head review under the ordered gates.
When selectable controls are needed, provide complete options and their trade-offs, recommended first; follow the active interface's option-rendering contract without hiding consequences.
Before final Delivery handoff, load [final verification](references/final-verification.md) and check the retained evidence against the ordered Task gates; do not repeat the checklist here.
## Canonical naming and compatibility
- Canonical installed and repository name: `channel-delivery-skic`.
- Source: `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/channel-delivery-skic`.
- Previous name: `corp-v1-channel-delivery`; retained locally only as a compatibility alias. New guidance and presentations use the canonical name.
- Naming-only migration authorized by RootAtSkic in [presentation message 1562523679223578705](https://discord.com/channels/1518726359512387766/1543922127898415154/1562523679223578705). Repository ID, history, support files, project authority and organization ownership are preserved.
- This is a reusable central reference, not a new shared Discord channel. Project adoptions use `channel-delivery-skic-<code>` and remain separately owned.
- Current project channel: `<code>-delivery` inside `skic-<code>`.
## Channel workspace standard
Load `channel-workspace-organization` for channel setup, file placement, and authorized workspace migration. Canonical standard: https://gitea.lego-cloud.eu/global-skills/channel-workspace-organization . Follow that shared policy rather than duplicating it here. Existing workspace bindings below remain current until an authorized migration is completed and verified; this reference alone does not relocate files or change bindings.
+30
View File
@@ -0,0 +1,30 @@
# AeroSim lessons review — Delivery
## Immutable sources
AeroSim Delivery source SHA: `0c0e68bde3189fd96415af6035200cf7fcb9c877`. Central baseline: `0bf71b905f0160631460807b371732b1afc5b0cb`.
- [SKILL.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-delivery-skic-aerosim/src/commit/0c0e68bde3189fd96415af6035200cf7fcb9c877/SKILL.md)
- [references/task-delivery-gates.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-delivery-skic-aerosim/src/commit/0c0e68bde3189fd96415af6035200cf7fcb9c877/references/task-delivery-gates.md)
- [references/runtime-and-ci.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-delivery-skic-aerosim/src/commit/0c0e68bde3189fd96415af6035200cf7fcb9c877/references/runtime-and-ci.md)
- [references/single-subagent-task-delivery.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-delivery-skic-aerosim/src/commit/0c0e68bde3189fd96415af6035200cf7fcb9c877/references/single-subagent-task-delivery.md)
Read the full source skill and all nine references against the central skill and its seven references. Relevant sections: **Overview**, **End-to-End Task Delivery Gates**, **Hourly Worker Reconciliation**, gate **Stage 5**, **Immutable application images and Helm charts**, and **Main-Session Verification**.
## Promoted lessons
- Bind the post-integration UAT handoff to an actual deployed tuple, not a PR-head CI result or image push. Put the contract in Stage 5, without duplicating generic exact-head algorithms already owned by `development-gates`.
- Distinguish root Git, child chart/source, pod image, and endpoint identity; operational health is not user-visible acceptance.
- Retain destination delivery proof and prevent a Releases notification from bypassing UAT or authorizing release.
- Include UAT in the information boundary; replace stale seven-channel wording rather than retaining two conflicting lists.
## Runtime drift reviewed
Installed Delivery `SKILL.md` SHA-256: `46e5304d701d180496688d9a16bb1413fb96c7a888aaf83570da62fc8a7447ff`; installed `references/task-delivery-gates.md` SHA-256: `fcb02322d5f440f3e59a24fa03c4ae74370e469aa6a35a42d94db8818448cca0`. These are supplementary local snapshots, not content attributed to the pinned Git commit. Their **End-to-End Task Delivery Gates / Stage 5** strengthen runtime readback and non-runtime `not_applicable` reasons. Generalized only the ready-for-UAT evidence requirement; the universal AeroSim development-deployment mandate and its standing authority remain project-local. Full runtime reference diffs were inspected, including stale test-ownership wording.
## Exclusions
No project rollout, runtime overwrite, owner reassignment, branch naming change, Jira mandate, standing merge/deploy delegation, account recovery, board/channel IDs, endpoint, scheduler cadence, or deployment configuration is promoted. Central authority and project overlays remain unchanged. The newer central functional-non-unit versus build-time artifact-validation split is retained; runtime references that send Helm artifact validation to UAT are stale and are not imported.
## Verification
Run `python3 -B -m unittest discover -s tests -v` from this repository, plus `git diff --check`. Tests validate the published documentation contract and links offline; they do not prove a deployment or live acceptance run.
+5
View File
@@ -0,0 +1,5 @@
# Delivery exception checks
On failed gates or resumption, load [Task gates](task-delivery-gates.md) and [planning reconciliation](planning-artifact-reconciliation.md) to verify original admission, current claim and visibility; merged planning text is not implementation approval.
Load `ci-runtime-skic` before command/repair work, `delivery-docs` before recording operational practice, and `status-reporting-skic` before blocker or completion wording. These owners carry their topic pitfalls once; do not repeat them here.
+13
View File
@@ -0,0 +1,13 @@
# Project failure and documentation bindings
## Failure-Repair Workflow
Before diagnosis or forward repair, load `ci-runtime-skic` for the same-gate repair loop and [Unit testing](runtime-and-ci.md#unit-testing) for local TTD/exception authority. Before blocker communication, load `status-reporting-skic` for the evidence packet and owner routing. Keep the selected Task/gate; never weaken requirements to pass it.
## Documentation Ownership
Before changing Delivery-owned Ways of Working or Engineering, load `delivery-docs` for coverage and evidence-to-page reconciliation. Bind the authoring owner to `documentation-docusaurus-global` at https://gitea.lego-cloud.eu/home-v1-skills-code-agent/documentation-docusaurus, plus the project-adopted overlay. Before defining reusable terms, bind/load `glossary-skic` at https://gitea.lego-cloud.eu/home-v1-skills-code-agent/glossary-skic. Stop if the source-qualified owner is unavailable; an unrelated same-name runtime skill is not that owner.
## Synchronization Workflow
Before reconciling planning/Architecture/Kanban changes load [planning-artifact-reconciliation.md](planning-artifact-reconciliation.md); follow the entry skill's single synchronization workflow for useful safe work and domain-owner loads.
+16
View File
@@ -0,0 +1,16 @@
# Final Delivery verification
- [ ] 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 carry exact Task `READY_FOR_DELIVERY` evidence.
- [ ] 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.
Apply this evidence checklist before a final Delivery handoff. It checks the existing gates; it grants no new authority and is not another implementation stage.
@@ -0,0 +1,38 @@
# Planning-artifact reconciliation
Use when planning or readiness documentation changes while implementation remains gated.
## Verification owners — load at the decision point
Before verifying a PR or CI, run `skill_view(name="development-gates")` and load its `references/review-ci-merge-contract.md`: **Evidence model**, **Attempt integrity**, and **Concurrent publication** own candidate/remote equality, complete successful job inventory including aggregates, and separate integration evidence. Do not use a successful listed-task subset as a gate.
Before reporting, load `skill_view(name="development-integrity")` and its `references/remote-checkpoint-matrix.md` for the current remote checkpoint, changed-head invalidation and candidate-versus-integration claims; then load [status-and-reporting.md](status-and-reporting.md) for Delivery formatting. Preserve project merge authority; A02/A04 follow global independent review-before-push and any-target-base-change invalidation without local exceptions.
Before validation, load `documentation-docusaurus-global` and the project-adopted overlay through [Documentation Ownership](failure-and-documentation.md#documentation-ownership); verify source identity. Run the complete repository validator and production build with frozen-lockfile installation and `git diff --check`. Generic and VSSA packages now have separate source-qualified names. Retain the bounded nested-pnpm fallback below until that procedure is present in the generic owner; identity repair alone does not establish procedural coverage.
If child scripts cannot find pnpm, use `corepack enable --install-directory <cache>/pnpm-bin`, prepend that temporary shim directory to `PATH`, and rerun the declared command. Keep shim/dependency caches outside commits and verify the worktree remains clean.
## Retained validation bindings
- Use the fresh PR API `head.ref` and full SHA, never a title or old report, for a clean detached worktree inside the Task boundary. Assert its actual HEAD and process working directory before repository-native validation. These exact-worktree checks remain local until the installed owner carries them.
- If the PR merged or closed during validation, update its reported state and validate the freshly resolved merge/default head, including semantic probes. Use the owners above for fresh evidence immediately before reporting; repeat if it changes. Keep API task `id`, `run_number`, run/attempt/job IDs and UI URLs distinct in retained evidence.
## Delivery interpretation
Read current same-project activity and distinguish human decisions from agent reports. Verify changed artifacts by authenticated readback at the validated revision and inspect their **semantics**: the exact Task row and status, evidence timestamp, new head/task pairs and absence of superseded pairs when reconciliation claims their removal. Parse lifecycle sections separately; headings, keyword counts and generated presentations are not Task-state evidence. If a probe disagrees with rendered Markdown, inspect numbered lines and correct the probe before reporting.
New pickup requires current `READY_FOR_DELIVERY`, dependencies, target version, parent Feature implementation approval and FR/NFR/ADR/UI/UX readiness under the preserved project authority. That status already records admission: no second Focus-admission decision. Continuation instead requires current `IN_PROGRESS`, its existing claim and historical verified admission; do not demand re-admission or mistake historical portfolio status for current Task authority. A merged Board page does not itself admit a Task. If the gate remains closed, do not create application changes; verify or reconcile documentation or route the evidenced blocker instead.
## Evidence interpretation
| Evidence | What it proves | What it does not prove |
|---|---|---|
| Documentation PR merged by a human | The reviewed documentation landed | Feature implementation approval |
| Architecture hierarchy/validator passes | Documentation structure meets its contract | A proposed Feature has an accepted solution |
| Kanban Board lists an item in ideation | The unfinished scope record is visible | Exact Task `READY_FOR_DELIVERY` handoff |
| Documentation CI succeeds | That documentation head passed its checks | Application CI or release readiness |
| Application baseline CI succeeds | The observed application head is healthy | A new Task PR, deployment, or release |
## Avoid duplicate status
Before posting, compare the proposed report with enough Delivery history to find the newest marker, head SHA, CI task, and blocker set. If there is no new human decision, repository head, CI result, actionable failure, or durable documentation change, return the configured silent response instead of restating the same gate.
@@ -0,0 +1,61 @@
# the adopted project Repository Entry and Visibility
Load this reference before claiming a Task, creating its application branch, opening its PR, or resuming its worktree.
All local repository entry happens inside `<code>-delivery/workspace/<TASK_ID>/`. During preparation, create only the required repository clones: `application/` and `documentation/`. Optional Task-local `review/`, `cache/`, `tmp/`, `logs/`, or `artifacts/` folders may be added later only when a concrete Task activity needs them. Reusable installed toolchains and technical dependencies are the sole exception: place them in `<code>-delivery/cache/`, never in a Task workspace. A repository branch, clone, Task evidence file, or other Task-local support folder outside the selected Task directory does not satisfy this gate.
## Implementation Entry Gate
Before claiming a Task for Feature implementation, verify in project documentation:
- Feature ID and parent Epic;
- exact `Approved for Implementation` evidence from the primary Architecture owner `the active project authority` or the active project authority as backup;
- linked FRs/NFRs and accepted solution/ADR context;
- task breakdown and dependencies;
- target version and status;
- acceptance evidence expected from delivery;
- exact Task `READY_FOR_DELIVERY` evidence, which itself records Focus admission by the active project authority; and
- an approved UI/UX package from the active UI/UX authority or the active project authority as backup when the task changes user-facing design.
Delivery must verify the Feature decision and exact Task `READY_FOR_DELIVERY` state before initial coding, then claim the Task by moving it directly to `IN_PROGRESS`. Continue claimed work in `IN_PROGRESS` while retaining the original handoff evidence. Do not require a second Focus admission after `READY_FOR_DELIVERY` or infer missing evidence from broad delegation, silence, CI, a Board wave, or a planning status. When a record is absent, route the exact owning action to Scope, Architecture, or Kanban rather than creating an out-of-scope lifecycle or flow mutation inside an implementation change.
## Immediate Wave-Start Visibility Gate
Before any implementation or repository content change begins on a newly claimed the adopted project Task, establish and verify all of these Gitea checkpoints:
Visibility-only kickoff commits contain no file/tree changes. This exception does not authorize a substantive push: freeze and independently review every implementation or documentation candidate before publication.
1. Create the dedicated local branch with the required Task branch name, create an empty kickoff commit if needed, and push that exact branch immediately.
2. Open a visible pull request from that exact branch to `test` before editing a repository file. Do not wait for implementation, tests, review, or a finished diff.
3. Put the Task ID, wave, planned scope, and current Task state in the PR so the active project authority and the team can monitor progress from the beginning.
4. Read the PR and remote ref back, then prove that the local branch name exactly equals the remote branch and PR head ref, the local kickoff commit equals the remote branch head, and the PR base is `test`.
5. Only after the remote branch and visible pull request already exist and all identities match may Delivery edit tests, source, configuration, documentation, or other repository content.
No repository file may be edited before this gate passes. A differently named local convenience branch that merely tracks the PR branch does not pass, because it hides the branch identity during status reporting and makes accidental publication to the wrong ref easier. When resuming an existing worktree, fetch the PR head explicitly, require the current local branch name to equal the PR head ref, and fast-forward before editing; if the names differ, repair the local branch identity without force-pushing or creating a competing PR.
One Task requires one dedicated branch and one visible PR unless the adopted project Architecture or the active project authority 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, unpushed branch, compare URL, or push without PR readback does not satisfy this gate.
### Branch and pull-request naming contract
For every the adopted project delivery Task, use this exact source-branch shape:
```text
<release>/<TASK_ID>-<short-explanation>-<attempt-digit>
```
Example:
```text
0.1.0/TASK-0049-persist-simulation-metadata-1
```
- `<release>` is the Task's exact target release, without a leading `v`. Do not derive it from a package manifest, invent it, or replace it with `unreleased`, `next`, or a wave label.
- `<TASK_ID>` is the exact Task ID, preserving its uppercase spelling.
- `<short-explanation>` is a concise lowercase ASCII kebab-case description (`a-z`, `0-9`, and single hyphens only).
- `<attempt-digit>` is an unpadded positive decimal attempt number. Start at `1`; increment it only when a new branch/PR attempt is required. Never reuse an attempt number for the same release, Task, and explanation.
- The complete branch must pass `git check-ref-format --branch`, contain exactly one `/`, and remain a valid Gitea branch ref. Spaces, repeated separators, `..`, `@{`, backslash, control characters, and the Git-forbidden characters `~ ^ : ? * [` are not allowed.
- Resolve collisions against freshly fetched local and remote refs before creating the branch. Never force-push or repurpose an earlier attempt.
The Gitea pull-request title must exactly equal the source branch name. Gitea's PR API treats the title as a string rather than a Git ref, but using the exact branch value provides one unambiguous release/Task/attempt identity across the branch list, PR list, API, CI, and evidence records. Do not prepend `feat:`, `fix:`, an emoji, a wave label, or other prose to the title.
Before creating the PR, verify the Gitea technical prerequisites: the source branch is pushed, the base branch is exactly `test`, head and base differ, the branch contains a commit not already in `test`, and no open PR already exists for the same head/base pair. Create the PR with explicit `title`, `head`, `base`, and `body` fields. The body must record the Task ID, release, attempt, wave, planned scope, Task state, validation plan, and requirement/ADR links. Read the PR back and require exact title, head ref/SHA, and `test` base; a compare URL or successful API response alone is not evidence that the PR contract is satisfied.
+35
View File
@@ -0,0 +1,35 @@
# Project runtime bindings
Before commands, CI changes, image publication, resource work or repair, load `ci-runtime-skic` and follow its full procedure with these bindings. Before login or credential-bearing operations, load `development-security-skic` and `development-security`; Board policy remains authoritative. Stop the affected action when an owner cannot load.
## Channel-owned workspace
Bind the project channel root under the active working root, Task `workspace/<TASK_ID>/`, reusable `cache/` and channel-provided `uploads/`. The shared owner defines cache contents, optional folders, real-CWD containment and exact-context preflight; this binding does not authorize execution outside the selected Task.
## Delivery Responsibilities
### Coding
Load `development-monorepo-pnpm` for pnpm/TypeScript implementation and `development-scripts` for Taskfile, shell, environment and Devbox work, using their [source links and project-overlay precedence](../SKILL.md#development-skill-routing). Preserve project structure/namespace; implement only approved Features and authorized Tasks with small, traceable changes, no unrelated refactors and no fabricated results.
### Unit testing
Load `development-method-ttd` before every behavior change, defect fix or refactor. Follow its mandatory failing-test-first unit workflow and retain real commands/results; request non-unit coverage from UAT. Exceptions require the authorized project owner explicitly approving a documented exception. Discard/start-over applies only to the executor's isolated, unpublished experimental delta, preserving unrelated or valid work. Never rewrite shared history, delete another worker's changes or revert integrated work. Repair shared/integrated code forward, record historical missing RED honestly and never claim retrospective tests proved test-first compliance; seek the named project-authority exception if compliant repair cannot satisfy the gate.
### Build and continuous integration
Load `ci-runtime-skic`, `development-gates` and `development-integrity`; preserve the required job inventory and local gate order in [Task gates](task-delivery-gates.md). Before Actions or publication load `devsecops-ci-cd-gitea` and the bound project overlay.
### Execution-context toolchain preflight
Before each foreground/background/worktree/worker/review/CI command, load `ci-runtime-skic` and its exact-context preflight, including `development-scripts` → `references/runtime-preflight.md` and `development-monorepo-pnpm` → `references/workspace-and-tooling.md`. Supply the selected Task/repository, branch/PR/revision, allowed scope and `CORP_V1_<CODE>_*` non-secret environment names. Load `development-scripts` for the repository overlay.
### Per-project reusable CI base images
Bind `corp-v1-<code>/corp-v1-<code>-base-images`, trusted publication branch `test`. Before image work load `ci-runtime-skic` for digest consumption and forward-repair safeguards and its required `devsecops-ci-cd-gitea` reference loads.
### Gondor runtime-resource placement
Before resource/storage work load `ci-runtime-skic` for isolation, secret-store, retained-storage and selected GitOps owner/fallback procedures. Bind the approved template and separate desired-state repository for each environment. Only the project-approved non-production environment is within Delivery authority; missing storage/platform authorization blocks mutation.
+5
View File
@@ -0,0 +1,5 @@
# Project reporting bindings
Before Task/wave/CI/blocker/completion reports or lifecycle changes, load `status-reporting-skic` and `development-integrity` (including `references/remote-checkpoint-matrix.md`). The shared reporter owns vocabulary and templates; the current project Scope record remains authoritative.
Bind the active project status-request authority, actual Release Task Board selector, Scope record and release owner before reporting. Missing records mean status unverified. No report changes admission, release authority or scheduler policy.
+112
View File
@@ -0,0 +1,112 @@
# the adopted project Task Delivery Gates
This file contains the ordered Delivery overlay for delivering one the adopted project Task. Load it before selecting or continuing a Task.
Before candidate review, CI, merge or integration verification, run `skill_view(name="development-gates")` and load `references/review-ci-merge-contract.md`. Its Evidence model and Attempt integrity own immutable identities, complete required job/aggregate inventory, one successful attempt and separate integration evidence. Use those mechanics at each stage; retain the local exit outcomes and reviewer/authority bindings below. Missing owner guidance blocks the affected gate.
**Global gate alignment (A02/A04):** apply `development-gates` without project exceptions to review independence, substantive push ordering or base-change invalidation. Visibility-only kickoff publication does not publish implementation. The sequence below also applies to documentation claims/handoffs and GitOps candidates, not only application changes.
## End-to-End Task Delivery Gates
These gates are mandatory and ordered. Each `GATE_###_NAME` code is the stable identifier used in communication and evidence. Hermes must not skip ahead, combine evidence from different revisions, or start the next Task before `GATE_005_TASK_POST_MERGE` passes. The three repositories used by this process are:
- application: `corp-v1-<code>/corp-v1-<code>`;
- Task files and project documentation: `corp-v1-<code>/corp-v1-<code>-documentation`; and
- this Delivery skill: `corp-v1-<code>-skills-code-agent/channel-delivery-skic-<code>`.
Before repository entry, load [repository-entry-and-visibility.md](repository-entry-and-visibility.md) for the complete entry/branch/visibility contract and [runtime-and-ci.md](runtime-and-ci.md#channel-owned-workspace) for required clones, optional directories, reusable cache and Task isolation. These remain mandatory gate inputs, not optional background reading.
Hermes main session owns the Task, performs implementation and obtains independent exact-head review, and communicates with the active project authority. Local repository tools execute deterministic commands. Gitea Actions runs remote CI. Gondor/GitOps is used only by an approved deployment or Release process. Cron never owns or continues a Task. No second implementation worker may work on the selected Task. A separate read-only reviewer is required; review is not implementation ownership.
Verification is part of each stage, not a separate end checklist. Before leaving a stage, pass its **Exit gate** and retain the evidence named there. Every Delivery progress, blocker, CI, merge, handoff, and completion update must name the active gate code and title. When a gate passes, report the passed gate code and the next gate code. At every stage, use only the adopted project's eight project channels, load the references and engineering skills required for that action, route contradictions instead of guessing, and report failures with the exact command, file, test, or CI job.
### Mandatory gate-failure recovery
Before repairing any failed check/review/CI/publication/exit condition, load [Failure-Repair Workflow](failure-and-documentation.md#failure-repair-workflow). It owns diagnosis, scope-safe forward repair, affected revalidation, blocker evidence and routing. Remain in the same gate until its complete exit passes; never weaken or relabel a failed gate. Pause only for its external-dependency, credential, decision, authority or safety blocker, recording `BLOCKED` separately without changing lifecycle status. Resume the same gate when removed.
### Stage 1 — `GATE_001_PREP` — Pick, Start, and Open the Task PR
**Repository and branch:** Read documentation remote `test` before branching. Establish fresh `application/` and `documentation/` clones inside the selected Task workspace under the loaded entry contract. Application branch: `<release>/<TASK_ID>-<short-explanation>-<attempt>`; documentation claim branch: `<release>/<TASK_ID>-start-delivery-<attempt>`. Each PR title equals its branch and targets `test`.
**Runtime:** Hermes main session verifies eligibility, creates and reads back the application branch and PR without editing repository content, then creates the documentation branch and PR, updates the Task file, runs documentation checks, and merges the documentation PR only after its checks pass. Gitea Actions runs remote checks. No implementation subagent or cron; obtain independent read-only review before substantive documentation publication.
**Required work:** Apply the loaded entry contract to exactly one current-wave `READY_FOR_DELIVERY` Task: Feature approval, dependencies, Architecture/requirements, target release and UI/UX readiness. Inspect only the adopted project’s eight channels. Establish and read back the application branch/PR before any edit. In the Task’s documentation clone add the hash-linked `READY_FOR_DELIVERY` to `IN_PROGRESS` event with actor, time, Task, wave, branch/PR evidence, previous hash and new hash; validate/review/merge it.
**Exit gate:** Loaded workspace and entry checks pass: required Task-local clones have expected remotes, optional folders have a concrete need, and application branch/PR identity is verified. Documentation claim is merged and remote Task state is `IN_PROGRESS`. Only then edit repository content. Report Task, wave, dependencies, PR, workspace and merged claim. Missing or contradictory eligibility blocks selection, mutation and branch creation; name the owner.
### Stage 2 — `GATE_002_TASK_PLAN` — Plan the Task
**Repository and branch:** Read Task, requirement, Architecture, and UI/UX files from the Task's `documentation/` clone at `test`; keep implementation notes and changes in the Task's `application/` clone on the existing application Task branch.
**Runtime:** Hermes main session inspects documentation and application code. Do not use HermesSubAgent.
**Required work:** Load the project engineering skills needed by the Task. Map each acceptance criterion to affected production code, a named test, edge and failure cases, security boundaries, build or artifact evidence, and its requirement or Architecture reference.
**Exit gate:** Every criterion has a checkable proof. A contradiction stops implementation and goes to the responsible Scope, Architecture, UI/UX, Kanban, or Release owner.
### Stage 3 — `GATE_003_TASK_IMPLEMENTATION` — Implement and Review the Task
**Repository and branch:** Use `<code>-delivery/workspace/<TASK_ID>/application/` on the existing application Task branch and PR. Application source, unit tests, configuration, application-documentation changes, builds, and image/container/Helm artifact validation stay in that clone and branch. Every functional non-unit suite stays in the UAT-owned E2E repository. If a separate review checkout or output is needed, create and use `review/` under the same Task directory.
**Runtime:** Main session is the sole implementer inside the selected Task workspace. The reviewer must not be the candidate implementer: obtain a separate read-only reviewer who must not edit, push, merge or become a second implementer. Load runtime preflight before every execution context and create optional folders only for concrete needs. No new human-review dependency or cron ownership.
**Required work:**
1. Load [runtime-and-ci.md](runtime-and-ci.md#execution-context-toolchain-preflight) and pass its exact-context preflight inside the selected Task workspace before commands. Unit tests use process-local fakes, not runtime services; UAT owns resource-dependent testing.
2. Load `development-method-ttd` and follow mandatory failing-unit-test-first TTD for defects, new behavior and refactors; only an explicitly approved documented exception from the authorized project owner permits departure. Request non-unit coverage from UAT. Tooling, environment and credential failures are not product-test evidence.
3. Implement only the approved Task, one behavior slice at a time. Keep the diff small, cover normal, edge, and failure behavior, avoid unrelated refactors, and repair forward without reverting valid work.
4. Run all applicable focused and full unit tests, lint, format checks, typecheck or compile, production build, production dependency audit, static checks, generated-artifact checks, and Delivery-owned Dockerfile/image/container/publication/Helm artifact validations, plus `git diff --check` and repository-state checks. Do not run functional integration, browser, security-boundary, performance, or acceptance suites in Delivery; request and consume those results from UAT.
5. Freeze and commit the complete locally validated candidate without rewriting shared history. Record candidate head/tree, target-base SHA and merge-base; require a clean candidate worktree. Do not push substantive changes yet.
6. Obtain independent logic/security review of that exact local candidate, including acceptance coverage, production-path use and test gaps. Tests alone are not the review. Record reviewer identity, base/head/tree and PASS/FAIL. Remote CI is not required to issue code-review PASS; publication readiness remains false until its later gates pass. If review finds a problem, stay in `GATE_003_TASK_IMPLEMENTATION`: the sole implementer repairs locally, reruns affected checks, freezes the new commit, and has the reviewer review that exact head again before its next substantive push. Any candidate change invalidates PASS.
7. Push only the exact reviewed head after PASS and verify remote branch/PR head equality with the checked and reviewed local commit. If any identity differs, stop and reconcile; never transfer a verdict to a different head. Required exact-head remote CI is verified in Stage 4.
**Exit gate:** Task-workspace/preflight rules and all local checks pass; every acceptance criterion has implementation/test evidence; `development-gates` candidate identity matches remote branch/PR and exact-head review has no unresolved finding. Later edits keep/return the Task to `GATE_003_TASK_IMPLEMENTATION` until affected checks, independent local review and then push/readback pass. Failure reports use [status-and-reporting.md](status-and-reporting.md): exact command/file/test/finding, observed versus expected behavior, failure class, mutation state and repair/owner.
### Stage 4 — `GATE_004_TASK_PR_CI` — Verify and Merge the Task PR
**Repository and branch:** Use the application PR and `application/` clone inside the selected Task workspace, targeting `corp-v1-<code>/corp-v1-<code>` `test`; then fetch and read the resulting application `test` revision in that same clone after merge.
**Runtime:** Gitea Actions runs PR CI. Hermes main session verifies CI and PR state, confirms independent exact-head review still covers the PR head, performs the authorized Gitea merge, and reads back the merge result. The read-only reviewer never merges; the authorized main session remains the sole writer.
**Required work:**
1. Apply the loaded `development-gates` attempt-integrity contract to all required Delivery jobs: unit tests, lint, typecheck, build, static security and artifact validation, including the required aggregate.
2. Immediately before merge, re-read the PR and current application `test`. Confirm that the PR remains open, its head is unchanged, its base is `test`, its branch equals the reviewed PR head, required CI is green, review still matches, the PR is mergeable, and the target-base SHA still equals the reviewed base. Any target-base SHA change invalidates merge readiness, even when candidate head/tree is unchanged; refresh/synchronize and repeat validation and independent review under `development-gates`. There is no local harmless-drift exception.
3. If conflict resolution, rebase, or any file/tree change is required, return to `GATE_003_TASK_IMPLEMENTATION`; repeat affected local checks, independent review of the frozen local candidate, and then push/readback for the new PR head; then restart `GATE_004_TASK_PR_CI` for that exact head.
4. Apply the loaded owner’s reviewed-head merge and separate integration readback contract within existing merge authority.
**Exit gate:** All required PR CI succeeds on the exact reviewed PR head; the final pre-merge check refers to that same head; the PR is merged; and the exact application `test` integration revision is known. The Task remains `IN_PROGRESS`; merge alone does not mean `TO_BE_RELEASED` or `DONE`.
### Stage 5 — `GATE_005_TASK_POST_MERGE` — Verify Integration and Hand Off the Task
**Repository and branch:** Use the selected Task's `application/` clone to validate `corp-v1-<code>/corp-v1-<code>` `test` at the exact integration revision produced by `GATE_004_TASK_PR_CI`. Then use the same Task's `documentation/` clone to create branch `<release>/<TASK_ID>-release-handoff-<attempt>` into documentation `test`, with a PR title exactly equal to the branch name and base `test`.
**Runtime:** Gitea Actions runs application integration, build, publication, and documentation checks. Hermes main session verifies those results, creates and validates the documentation handoff, applies the review rules from `GATE_003_TASK_IMPLEMENTATION` to the exact documentation PR head, and performs the authorized documentation merge. Gondor/GitOps is used only within approved deployment authority. Apply the deployment and handoff evidence contract below before declaring the handoff complete.
**Required work:**
1. Apply the loaded owner’s separate integration gate to all required application unit/build, container, immutable publication and artifact checks. Retain registry digest readback; PR-head CI cannot replace integration evidence.
2. Complete the deployment and handoff evidence contract below, then add the hash-linked `IN_PROGRESS` to `TO_BE_RELEASED` event with the merged application PR, integration revision, successful integration CI, publication and deployment evidence when required, and the UAT handoff or verified non-runtime exception.
3. Update Ways of Working or Engineering documentation only when this Task changed how the project actually works.
4. Validate, review, merge, and read back the documentation handoff PR.
**Exit gate:** Every required post-merge unit-test, build, and publication job succeeds on the exact application `test` revision; the documentation PR is merged; and the Task file on remote documentation `test` says `TO_BE_RELEASED`. The deployment and handoff evidence contract below must also pass. Only then may Delivery call the Task delivered. Release execution and the later `DONE` transition belong to `channel-releases-skic-<code>`, not this Delivery process.
#### Deployment and handoff evidence
For runtime-affecting work using Delivery → UAT, require a verified non-production deployment before a ready-for-UAT handoff. Resolve the approved deployment owner, target environment, and desired-state repository from the project contract; this requirement grants no deployment authority. Missing authority or deployment evidence is `BLOCKED`, not a successful handoff. If the project requires deployment before `TO_BE_RELEASED`, enforce that gate even when the Task omits it. Only work with no deployable runtime effect may record `not_applicable`, with a verified reason; lack of permission is not such a reason.
Retain the exact integrated application commit, immutable image digests and chart identity where applicable, template provenance, rendered GitOps commit, controller revisions/sync/health, pod image IDs, environment/base URL, verification time, Task identity, and limitations. Follow the owning GitOps workflow, not direct workload mutation. For app-of-apps, distinguish root Git revision from child chart/source revision and verify each against its own desired state. Deployment readback proves identity and operational health, not user-visible acceptance; UAT owns that verdict.
Send the frozen packet to the mapped UAT channel and any release-readiness notification required by the adopted workflow. Retain the destination channel/message ID and readback, or the verified dispatcher delivery receipt; a source-channel mention is not delivery proof. Respect auto-delivery contracts rather than sending duplicate messages, and report delivery as unverified until a receipt exists. A Releases notification routes readiness only; it neither skips UAT nor authorizes release or `DONE`.
### Stage 6 — `GATE_006_NEXT_TASK` — Pick the Next Task
**Repository and branch:** Read refreshed documentation `test` and the Board from the completed Task's `documentation/` clone. Do not reuse that Task directory for another Task and create no new branch until the next Task passes `GATE_001_PREP`, which creates its own workspace and fresh clones.
**Runtime:** Hermes main session selects the next Task. Do not use cron or a subagent for selection.
**Required work:** Confirm the previous Task says `TO_BE_RELEASED`, no delivery blocker remains, capacity is free, and the next Task says `READY_FOR_DELIVERY` with satisfied dependencies.
**Exit gate:** Report the next selected Task and return to `GATE_001_PREP`. Do not wait for `DONE`; release execution and `DONE` are owned by `channel-releases-skic-<code>`.
+26
View File
@@ -0,0 +1,26 @@
"""Exact, reversible skill-identity migration; never rewrite provenance URLs."""
import re
IDENTITIES = {
'development-branching-strategy-aerosim': 'development-branching-strategy-skic-aerosim',
'development-scripts-aerosim': 'development-scripts-skic-aerosim',
'devsecops-ci-cd-gitea-aerosim': 'devsecops-ci-cd-gitea-skic-aerosim',
'documentation-docusaurus-aerosim': 'documentation-docusaurus-skic-aerosim',
'development-gitops-argo-cd-gondor-v1': 'development-gitops-argo-cd-home-gondor-v1',
'home-v1-discord': 'discord',
'home-v1--truenas': 'truenas',
}
def translate(text, mapping):
# Bare discord/truenas are common words: only migrate explicit skill identity
# delimiters (inline code, quoted names, and related_skills list entries).
pattern = r'(?P<left>`|[\"\'])(?P<name>' + '|'.join(map(re.escape, mapping)) + r')(?=[`\"\'\],])'
text = re.sub(pattern, lambda m: m['left'] + mapping[m['name']], text)
return re.sub(r'(?m)^( related_skills: \[)(.*)(\])$',
lambda m: m[1] + ', '.join(mapping.get(v, v) for v in m[2].split(', ')) + m[3], text)
def canonicalize(text):
return translate(text, IDENTITIES)
def original_identity(text):
return translate(text, {new: old for old, new in IDENTITIES.items()})
+25
View File
@@ -0,0 +1,25 @@
{
"retained": [
"channel-board-skic",
"discord",
"documentation-docusaurus-global",
"glossary-skic",
"development-durable-wave-execution",
"development-gates",
"development-integrity",
"development-method-ttd",
"development-branching-strategy",
"development-monorepo-pnpm",
"development-scripts",
"development-gitops-argo-cd-home-gondor-v1"
],
"additional": [
"ci-runtime-skic",
"delivery-docs",
"status-reporting-skic",
"development-security",
"development-security-skic",
"develop-monorepo-pnpm-app-skic",
"develop-monorepo-pnpm-package-skic"
]
}
+28
View File
@@ -0,0 +1,28 @@
[
{
"path": "references/task-delivery-gates.md",
"sha256": "6ecc350c0aaa66551a4bcd9a5da278c55980cce783eaf563a1a7546c1d5ac588"
},
{
"path": "references/repository-entry-and-visibility.md",
"sha256": "ee89ad297ea28e5a393b8a7e53de487883e64c720276f4055e368086d1c0ba65"
},
{
"path": "references/planning-artifact-reconciliation.md",
"sha256": "8676cb832199c4e11acc0f9f3abc649364a9ed6eec83d561ffd9c21bc556c3af"
},
{
"path": "references/aerosim-lessons-review.md",
"sha256": "e66dbafba963f95831ed230b15cee67b23677024bdbf464dae8cb2deb906a96e"
},
{
"path": "SKILL.md",
"heading": "Authority and Escalation",
"sha256": "85635a7e636529593e5ed98ff8884b7078e429123442c59ae4f7db94cc1e0e40"
},
{
"path": "SKILL.md",
"heading": "UI/UX Coordination",
"sha256": "c7331b08010fc4f931543a5ced352cc05d16df122aea2abafc3b3221da05b18d"
}
]
+15
View File
@@ -0,0 +1,15 @@
{
"home-v1-skills-code-agent/development-gates": "global-skills/development-gates",
"home-v1-skills-code-agent/development-integrity": "global-skills/development-integrity",
"home-v1-skills-code-agent/development-method-ttd": "global-skills/development-method-ttd",
"home-v1-skills-code-agent/development-durable-wave-execution": "global-skills/development-durable-wave-execution",
"home-v1-skills-code-agent/development-monorepo-pnpm": "global-skills/development-monorepo-pnpm",
"home-v1-skills-code-agent/development-branching-strategy": "global-skills/development-branching-strategy",
"home-v1-skills-code-agent/development-scripts": "global-skills/development-scripts",
"home-v1-skills-code-agent/devsecops-ci-cd-gitea": "global-skills/devsecops-ci-cd-gitea",
"corp-v1-aerosim-skills-code-agent/documentation-docusaurus-aerosim": "skic-aerosim-skills/documentation-docusaurus-skic-aerosim",
"corp-v1-aerosim-skills-code-agent/development-scripts-aerosim": "skic-aerosim-skills/development-scripts-skic-aerosim",
"corp-v1-aerosim-skills-code-agent/development-branching-strategy-aerosim": "skic-aerosim-skills/development-branching-strategy-skic-aerosim",
"corp-v1-aerosim-skills-code-agent/devsecops-ci-cd-gitea-aerosim": "skic-aerosim-skills/devsecops-ci-cd-gitea-skic-aerosim",
"home-v1-skills-code-agent/development-gitops-argo-cd-gondor-v1": "home-gondor-v1-skills/development-gitops-argo-cd-home-gondor-v1"
}
+13
View File
@@ -0,0 +1,13 @@
from pathlib import Path
import os
ROOT=Path(__file__).resolve().parents[1]
def owner(name):
base=Path(os.environ.get('DELIVERY_OWNER_ROOT',str(ROOT.parent)))
direct=base/name/'SKILL.md'
found=[direct] if direct.is_file() else list(base.glob('*/'+name+'/SKILL.md'))
if len(found)!=1: raise RuntimeError('Owner missing or ambiguous: '+name+' under '+str(base))
return found[0].read_text()
def effective(path):
text=(ROOT/path).read_text()
routes={'references/runtime-and-ci.md':['ci-runtime-skic'], 'references/status-and-reporting.md':['status-reporting-skic'], 'references/failure-and-documentation.md':['ci-runtime-skic','status-reporting-skic','delivery-docs']}
return text+'\n'+'\n'.join(owner(n) for n in routes.get(path,[]))
+49
View File
@@ -0,0 +1,49 @@
[
{
"path": "references/task-delivery-gates.md",
"pattern": "^\\*\\*Exit gate:\\*\\* All required PR CI.*$",
"hashes": [
"ff18fe3b523dae671eb14f513e1f90700eeea9c8a93bf85686f67b8f9635e7f3"
]
},
{
"path": "references/task-delivery-gates.md",
"pattern": "^\\*\\*Exit gate:\\*\\* Every required post-merge.*$",
"hashes": [
"9338b15f03aa46139240842a0c72c92fd3af2d91e1af4ee82c55fe859361d196"
]
},
{
"path": "references/task-delivery-gates.md",
"pattern": "^### Stage [1-6].*$",
"hashes": [
"50a5e09da6aca1488d9d375c22740b39c0168837bde39bb390352186f7982d6d",
"fc758ac75b342cceb555b927710c0aba38ca31fd6bdbca4eb7ed054f814c2f38",
"f68e0313b622ef7666bccd0c6bd9551153e01e2b8f6cc68978a4dda72924c45a",
"156eb690576a1a812c3fb7d32ee32fb98c174c81143830a336ca4ec54dd27745",
"4a76eda13fa68c5f28b458d5d1ad400211c4daad5418b3f3319c36b84ade03b2",
"960be6948de8a23e4591cfa099c9cf30e47f2b1b72f8702f05c6d7dd1713bfd7"
]
},
{
"path": "references/status-and-reporting.md",
"pattern": "(?s)## Scope Status Vocabulary.*",
"hashes": [
"0aa256d5852c664c0d18b3888990d6c31e73a4e50e894324e1d11cb72a970b93"
]
},
{
"path": "references/failure-and-documentation.md",
"pattern": "(?s)When a build or CI failure is observed:.*?(?=5\\. )",
"hashes": [
"d7850a4ca34226dd9b45badc1623012e87a2557f3cced4b63807939be00a72f5"
]
},
{
"path": "references/failure-and-documentation.md",
"pattern": "(?s)7\\. run local validation;.*?(?=## Documentation Ownership)",
"hashes": [
"13e74d3dd90a757a7a7d0ef7f0a4448cb6a7764b7c63ce8699b40f197fbac6fa"
]
}
]
+97
View File
@@ -0,0 +1,97 @@
{
"owners": {
"preflight": {
"owner": "development-scripts",
"reference": "references/runtime-preflight.md",
"source_url": "https://gitea.lego-cloud.eu/global-skills/development-scripts",
"inspected_head": "0e36552938da94c0539e39b35256b8effe34c25d",
"sha256": "07306382b8afe5c2d2e83e2955a04a1523d008e7e39cead7c7a1797bb6640462",
"state": "merged source and installed reference byte-identical; authenticated immutable full-package readback verified",
"evidence_text": "# Exact-context toolchain preflight\n\nUse before repository commands in a Node/pnpm repository, or any command that may invoke Node or pnpm. This is a reusable execution procedure, not a project directory convention or permission to run tests. The caller supplies the authorized repository, revision, worker context, required environment names and permitted operation. Task-directory containment and stop-on-failed-preflight remain caller responsibilities.\n\n## Required inputs\n\nLoad `development-monorepo-pnpm` and its `references/workspace-and-tooling.md` tooling reference for version selection and committed toolchain/workspace conventions. Resolve required Node and pnpm versions from the repository's **committed toolchain contract**, not ambient executables. Inspect the selected revision's package-manager pin, Node declaration and applicable locked environment/image metadata. Do not invent a universal version or workspace layout. If declarations conflict, are absent, or leave the required exact version unresolved, stop and reconcile the contract with its owner before running the requested command. A version range alone is not an exact observed-version pin.\n\n## Procedure\n\nTreat every foreground shell, detached worktree, background process, main-session review command and CI job as a separate execution context. A successful check elsewhere is not transferable evidence. Perform inspection/preflight in the intended context before the requested repository operation; inspection commands themselves are necessary to establish the context.\n\n1. Resolve the required versions from the committed toolchain contract at the expected source revision. Record the paths/revision used, not secret content.\n2. Inside that exact shell/process/container run `command -v node`, `node --version`, `command -v pnpm`, and `pnpm --version`, using `terminal` or the equivalent job step. Require every command to succeed; compare observed versions to the resolved required versions (normalize only Node's leading `v`). An executable found in a different shell is not sufficient. Record executable paths and observed/required versions.\n3. Verify required non-secret environment variable names are present, including disposable-test database markers when applicable, **without reading or printing their values**. For Bash, a presence-only `[[ -v VARIABLE_NAME ]]` check is suitable after validating a supplied name against `[A-Za-z_][A-Za-z0-9_]*`. Do not dump `env`, expand indirect values, enable tracing, or read credentials. Presence alone does not prove resource isolation or authorize database use; that remains the caller's separate gate.\n4. Verify the actual working directory and repository root; compare source HEAD and linked branch/PR identity with caller-supplied expected identity. Inspect repository state and confirm it is clean or intentionally staged, with every intentional change accounted for. Detached HEAD is allowed only when it matches the authorized revision/worktree. Never reset/stash unrelated changes to make a check green. Do not assume a project-specific application layout.\n5. Start the original command only after every applicable check passes. Keep activation, verification and execution in the same context. Recheck if PATH, activation, working directory, revision, image or required environment changes. A background worker must do its own preflight within its launch command, not consume a foreground success flag.\n\n## Failure and repair\n\nNever assume a background process inherits `PATH`, shell activation, Devbox state, Corepack activation, database variables or other exports from a foreground terminal. Missing `pnpm` is an execution-context/toolchain failure, **never an application-code or test failure**. Missing Node, wrong versions, wrong working directory/revision and absent required names also block execution; they do not constitute product RED.\n\nRepair the exact context by providing the required toolchain path or approved activation. Do not silently install a latest toolchain, rewrite pins, or execute Devbox unless the parent workflow permits it. Then **repeat the complete preflight** there and rerun the original command before making a claim about repository code. Preserve failure and rerun evidence separately.\n\n## Verification and scope\n\nRecord expected/observed versions, executable paths, repository root/revision, branch/PR link, approved state, presence-only results, context identity and command outcome. Do not include secrets or environment values. Local narrow validation never replaces all-app CI or exact-head remote job evidence. Toolchain success is not a claim of CI, publication, deployment or runtime acceptance.\n\nRun the owner contract regression with `terminal(command=\"python3 scripts/test_preflight_contract.py\", workdir=\"<skill-repository>\")`. This checks maintained guidance, not a live consumer toolchain; the five steps above must still be exercised for each real conLine truncated
},
"base_images": {
"owner": "devsecops-ci-cd-gitea",
"reference": "references/base-images.md",
"source_url": "https://gitea.lego-cloud.eu/global-skills/devsecops-ci-cd-gitea",
"inspected_head": "669e28eadfe79ac7cb3c10ccdea318dd5296d481",
"sha256": "1fb0e24ec5789b195be9ae35fbb9529fa1cab56112dae5baf9455284ca490e53",
"state": "merged source and installed reference byte-identical; authenticated immutable full-package readback verified",
"evidence_text": "# Reusable CI base-image contract\n\nUse when stable runtimes or OS tools would otherwise be downloaded repeatedly in application jobs. This owner defines reusable construction, validation, publication and consumption mechanics; it does not choose a project's image repository, branch, application layout or runtime-smoke authority. Supply those bindings from the project Delivery/CI overlay. Runtime verification is a separate acceptance layer delegated to the project's authorized runtime-test owner, not permission granted by this reference.\n\nRead [pipeline-workflow.md](pipeline-workflow.md) for trust boundaries, exact checkout and immutable retries, and [harbor-auth.md](harbor-auth.md) for credential handling. These safeguards apply in addition to this contract; base-image work is not an exemption.\n\n## Construction and static contract\n\n1. Keep one folder per image containing a Dockerfile, machine-readable version/platform metadata, usage documentation, a build helper and a static publication contract. Record required upstream reference, platforms, runtime/tool pins, numeric user/group and supported workspace path. Do not prescribe a product's application directories.\n2. Pin the upstream base by digest (`repository@sha256:<64 lowercase hexadecimal characters>`). Check the actual resolved platform against metadata; for a multi-platform index, record index and platform-manifest relationships rather than silently comparing unlike digests.\n3. Assert exact runtime/tool versions, architecture, numeric non-root identity, writable workspace, CA trust, Git, shell and every other required tool. Static/unit checks inspect Dockerfile and metadata; they cannot alone prove live writability, effective UID, trust or executable behavior. The authorized runtime verifier must exercise those assertions on the **published digest** and record results separately. Never describe a static declaration as runtime proof.\n4. Prefer the verified job image over repeated `actions/setup-node` or package-manager bootstrap steps. Keep `pnpm install --frozen-lockfile --ignore-scripts` in the application repository for lockfile parity; do not bake project dependencies or credentials into a generic base image. This does not waive the consumer's committed toolchain contract or exact-context preflight in `development-scripts/references/runtime-preflight.md`.\n\n## Candidate isolation and trusted publication\n\n- Build and perform static/unit validation on pull requests **without registry credentials**. Credential absence must be structural: no publication secret in workflow-global scope, candidate job environment, persistent runner home, Docker config, build args, cache or artifact. Skipping login does not remove an already available credential. Use an approved credential-free base acquisition path; if unavailable, stop rather than leak publication credentials to candidates.\n- Choose exactly one configured default integration branch, as in the pipeline owner (`test` or `main`), and publish only its exact trusted integration commit. PR, fork, branch-readiness and broad tag triggers cannot publish. Separately authorized release workflows must retain equivalent isolation, never broaden the ordinary candidate path.\n- Complete candidate execution before introducing a narrowly scoped Harbor robot secret in the isolated trusted publication job. Pass secrets via standard input only. Keep temporary Docker/Helm credential stores scoped to the job, clean on success and failure, and treat logout failure on persistent runners as failure after cleanup. Never pre-seed push credentials into the reusable job image or execute untrusted candidate hooks after authentication.\n\n## Immutable publication and direct readback\n\n1. Verify checkout identity before building. Tag the image with the full 40-character source revision; never publish `latest`, mutable version aliases or shortened SHAs for governed consumption. Enforce registry immutable-tag rules as well as workflow checks.\n2. Preserve the validated local image ID. Existing tags are reusable only when the remote OCI config digest equals that validated local image ID; different content is a hard failure, not an overwrite. For multiple platforms, verify each required platform's config identity and expected manifest/index membership. Missing or ambiguous remote evidence fails closed.\n3. After publication, read back the Harbor artifact directly: verify reference, source identity, platform and manifest digest. Record source URL/revision, workflow run/attempt/job, immutable tag, manifest digest, config digest/local image ID and canonical millisecond ISO-8601 UTC timestamp. Config digest is for retry content comparison; manifest digest is for consumption. Do not interchange either with source SHA or chart archive checksum.\n4. Require the final aggregate under `always()` to explicitly require every necessary build/publication/readback job's success. A green push step or skipped aggrLine truncated
}
},
"moved_clauses": [
{
"clause": "version resolution, executable/version comparisons",
"owner_key": "preflight",
"section": "Required inputs; Procedure 1\u20132"
},
{
"clause": "presence-only environment and repository identity/state checks",
"owner_key": "preflight",
"section": "Procedure 3\u20134"
},
{
"clause": "same-context activation, inheritance failure classification and complete retry",
"owner_key": "preflight",
"section": "Procedure 5; Failure and repair"
},
{
"clause": "image folder/metadata, digest/tool/platform/user/workspace/trust assertions and lockfile parity",
"owner_key": "base_images",
"section": "Construction and static contract"
},
{
"clause": "credential-free candidates and isolated trusted publication",
"owner_key": "base_images",
"section": "Candidate isolation and trusted publication"
},
{
"clause": "full-source tags, direct Harbor readback, immutable retry and aggregates",
"owner_key": "base_images",
"section": "Immutable publication and direct readback"
},
{
"clause": "digest consumer verification and forward repair mechanics",
"owner_key": "base_images",
"section": "Consumer verification and forward repair"
},
{
"clause": "negative trigger/tag/secret/interpolation/digest/setup regression cases",
"owner_key": "base_images",
"section": "Fail-closed regression matrix"
}
],
"retained_local": [
"every foreground shell",
"detached worktree",
"background process",
"worker",
"Hermes main-session review command",
"CI job",
"Stop on failed preflight",
"selected Task directory",
"selected repository",
"allowed command scope",
"complete repository CI",
"last known-good digest",
"trusted `test` branch",
"UAT",
"exact PR-head SHA"
],
"superseded_golden_rules": [
{
"path": "references/runtime-and-ci.md",
"pattern": "(?s)### Per-project reusable CI base images\\n.*?(?=### Gondor)",
"hashes": [
"0c92e0521c57c357a62c8313c70527547427d98b7647ec8cd1a97c148b5ba4f1"
]
},
{
"path": "references/runtime-and-ci.md",
"pattern": "(?s)Treat every foreground shell.*?(?=### Immutable|### Per-project)",
"hashes": [
"8df9d2e952a6a8c48fd3d0a18357aea21d5ffbb1e06e53c7273c6e50e2545be5"
]
}
]
}
+1
View File
@@ -0,0 +1 @@
0d7de8761e3c27908cef45c05a16e36cc36dce0dd428027002c632c34c8448bf
+57
View File
@@ -0,0 +1,57 @@
"""Offline regression tests for the channel's published prose contract."""
from pathlib import Path
import re
import unittest
ROOT = Path(__file__).resolve().parents[1]
class LessonsContract(unittest.TestCase):
def test_review_provenance_and_link(self):
review = ROOT / "references/aerosim-lessons-review.md"
self.assertTrue(review.is_file())
text = review.read_text()
self.assertRegex(text, r"/src/commit/[0-9a-f]{40}/")
self.assertIn("## Exclusions", text)
self.assertIn("aerosim-lessons-review.md", (ROOT / "SKILL.md").read_text())
def test_local_markdown_links_resolve(self):
for path in [ROOT / "SKILL.md", *ROOT.glob("references/*.md")]:
for target in re.findall(r"\]\(([^)]+)\)", path.read_text()):
if "://" not in target and not target.startswith(("#", "<")):
self.assertTrue((path.parent / target.split("#")[0]).is_file(), (path, target))
def test_no_project_authority_transplant(self):
for path in [ROOT / "SKILL.md", *ROOT.glob("references/*.md")]:
if path.name == "aerosim-lessons-review.md":
continue
text = path.read_text()
for forbidden in ("jarvis-at-skic", "aerosim-dev.apps", "AEROSIM_STANDING", "1537388451501056081"):
self.assertNotIn(forbidden, text)
def test_contract_0(self):
text = (ROOT / 'references/task-delivery-gates.md').read_text()
self.assertIn('#### Deployment and handoff evidence', text)
self.assertIn('pod image IDs', text)
self.assertIn('destination channel/message ID', text)
self.assertIn('not_applicable', text)
self.assertIn('not user-visible acceptance', text)
def test_contract_1(self):
text = (ROOT / 'SKILL.md').read_text()
self.assertIn('<code>-uat', text)
self.assertIn('version: 1.18.0', text)
def test_stage_five_scope_and_authority(self):
text = (ROOT / "references/task-delivery-gates.md").read_text()
stage = text.split("### Stage 5", 1)[1].split("### Stage 6", 1)[0]
self.assertIn("#### Deployment and handoff evidence", stage)
self.assertNotRegex(stage, r"(?m)^## ")
self.assertIn("this requirement grants no deployment authority", stage)
self.assertIn("If the project requires deployment before", stage)
self.assertNotIn("only if the Task explicitly includes", stage)
self.assertIn("image/container/Helm artifact validation", text)
self.assertIn("No second implementation worker", text)
if __name__ == "__main__":
unittest.main()
+36
View File
@@ -0,0 +1,36 @@
from pathlib import Path
from disposition_support import effective
ROOT = Path(__file__).resolve().parents[1]
SKILL = (ROOT / "SKILL.md").read_text(encoding="utf-8")
RUNTIME = effective("references/runtime-and-ci.md")
REFERENCES = {
"development-durable-wave-execution": "https://gitea.lego-cloud.eu/global-skills/development-durable-wave-execution",
"development-gates": "https://gitea.lego-cloud.eu/global-skills/development-gates",
"development-integrity": "https://gitea.lego-cloud.eu/global-skills/development-integrity",
"development-method-ttd": "https://gitea.lego-cloud.eu/global-skills/development-method-ttd",
"development-branching-strategy": "https://gitea.lego-cloud.eu/global-skills/development-branching-strategy",
"development-monorepo-pnpm": "https://gitea.lego-cloud.eu/global-skills/development-monorepo-pnpm",
"development-scripts": "https://gitea.lego-cloud.eu/global-skills/development-scripts",
"development-gitops-argo-cd-home-gondor-v1": "https://gitea.lego-cloud.eu/home-gondor-v1-skills/development-gitops-argo-cd-home-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 "Project bindings must not contradict global skills" in SKILL
assert "the explicit project/channel overlay wins" not in SKILL
def test_gitops_reference_requires_one_environment_per_repository() -> None:
assert "development-gitops-argo-cd-home-gondor-v1" in RUNTIME
assert "one repository per environment" in RUNTIME
+75
View File
@@ -0,0 +1,75 @@
"""Disposition regression: immutable authority, concrete loads and moved policy."""
from pathlib import Path
import hashlib,json,re,unittest
from disposition_support import ROOT,owner,effective
TESTS=Path(__file__).parent
class Disposition(unittest.TestCase):
def test_authority_and_unresolved_gates_unchanged(self):
mapping=json.loads((TESTS/'disposition-url-map.json').read_text())
for f in json.loads((TESTS/'disposition-protected.json').read_text()):
t=(ROOT/f['path']).read_text()
for old,new in mapping.items(): t=t.replace('https://gitea.lego-cloud.eu/'+new,'https://gitea.lego-cloud.eu/'+old)
t=t.replace('glossary-skic','corp-v1-glossary')
if 'heading' in f: t=re.search(r'^## '+re.escape(f['heading'])+r'\n.*?(?=^## |\Z)',t,re.M|re.S).group()
if 'block' in f: t=re.search(r'<!-- '+f['block']+r':BEGIN -->.*?<!-- '+f['block']+r':END -->',t,re.S).group()
self.assertEqual(hashlib.sha256(t.rstrip().encode()).hexdigest(),f['sha256'],f)
def test_all_retained_and_real_additional_dependencies(self):
t=(ROOT/'SKILL.md').read_text(); d=json.loads((TESTS/'disposition-dependencies.json').read_text())
actual=re.search(r'related_skills: \[(.*?)\]',t).group(1).split(', ')
self.assertEqual(actual,d['retained']+d['additional']); self.assertEqual(len(actual),len(set(actual)))
self.assertIn('develop-monorepo-pnpm-app-skic',actual); self.assertIn('develop-monorepo-pnpm-package-skic',actual)
self.assertIn('draft review aids, not approved standards',t)
for n in d['additional']:
self.assertIn('`'+n+'`',t)
for n in ['gitops-manifest-engineering','gondor-v1-nodes']:
self.assertIn(n,t if ROOT.name.endswith('aerosim') else owner('ci-runtime-skic'))
def test_no_removed_reports_or_empty_sections(self):
t=(ROOT/'SKILL.md').read_text()
for n in ['ADOPTION.md','FULL-PROGRAM.md','naming-delivery-review.md','SIMPLIFICATION.md']:self.assertFalse((ROOT/n).exists())
for h in ['Overview','When to Use','Common Pitfalls','Project-Adoption Delivery Lessons','Proactive Iteration Requirement','Verification Checklist','Shared Corp v1 System Login','Documentation Ownership']:
self.assertNotIn('## '+h+'\n',t)
self.assertIn('## Synchronization Workflow',t)
if not ROOT.name.endswith('aerosim'):
self.assertIn('references/final-verification.md',t)
self.assertTrue((ROOT/'references/final-verification.md').is_file())
def test_complete_vocabulary_and_templates_moved_once(self):
t=owner('status-reporting-skic').split('## Scope Status Vocabulary',1)[1].split('## Blocker routing',1)[0]
self.assertEqual(hashlib.sha256(('## Scope Status Vocabulary'+t).rstrip().encode()).hexdigest(),(TESTS/'report-format.sha256').read_text().strip())
local=(ROOT/'references/status-and-reporting.md').read_text()
self.assertNotIn('wave-previous:',local)
self.assertIn('status-reporting-skic',local);self.assertIn('development-integrity',local)
def test_scoped_owner_mechanics_and_fail_closed_loads(self):
ci=owner('ci-runtime-skic')
for s in ['every foreground shell','last known-good digest','credential-free','per-run database/schema/role','deletion-reclaim','Bitwarden','exact-context','stop','self-hosted-service-account-recovery','truenas','references/base-images.md','references/runtime-preflight.md','repeat diagnosis, repair','same Task/gate','Before Delivery publication/install or operational adoption','complete published and installed owner packages','immutable owner revision and reference hash','Stop adoption if this evidence is unresolved']:
self.assertIn(s,ci)
for s in ['devsecops-ci-cd-gitea-skic-aerosim','development-scripts-skic-aerosim','gitops-manifest-engineering','gondor-v1-nodes']:
self.assertIn(s,ci)
local=(ROOT/'references/runtime-and-ci.md').read_text()
self.assertIn('ci-runtime-skic',local);self.assertIn('development-security-skic',local)
self.assertNotIn('├── cache/',local)
self.assertIn('isolated, unpublished experimental delta',local)
self.assertIn('historical missing RED',local)
def test_documentation_outcomes_and_binding(self):
docs=owner('delivery-docs'); local=(ROOT/'references/failure-and-documentation.md').read_text()
for s in ['five sections','Delivery workflow','Collaboration and decisions','Packaging and deployment preparation','Operations and troubleshooting','planned process as already operational','source identity','read back']:
self.assertIn(s,docs)
self.assertNotIn('### Ways of Working',local);self.assertIn('delivery-docs',local)
self.assertIn('glossary-skic',local)
self.assertIn('documentation-docusaurus-skic-aerosim' if ROOT.name.endswith('aerosim') else 'documentation-docusaurus-global',local)
def test_security_preserves_single_policy_owner(self):
security=owner('development-security-skic'); generic=owner('development-security')
for s in ['channel-board-skic','Corp v1 System SSO Credential Use','Stop before login','development-security','Central Delivery gains no self-recovery authority']:
self.assertIn(s,security)
self.assertNotIn('HL_V1_SSO_PASSWORD',security+generic)
for s in ['presence only','never inspect, hash or measure','generic 401/403','separately verified delegation','not authority']:
self.assertIn(s,generic)
def test_local_markdown_targets_and_anchors_exist(self):
for p in [ROOT/'SKILL.md',*ROOT.glob('references/*.md')]:
for link in re.findall(r'\]\(([^)]+)\)',p.read_text()):
if '://' in link or link.startswith('<'):continue
path,_,anchor=link.partition('#');dest=p.parent/path if path else p
self.assertTrue(dest.is_file(),(p,link))
if anchor:
anchors={re.sub(r'[^\w -]','',h.lower()).replace(' ','-') for h in re.findall(r'^#+ (.*)',dest.read_text(),re.M)}
self.assertIn(anchor,anchors,(p,link))
if __name__=='__main__':unittest.main()
+8
View File
@@ -0,0 +1,8 @@
from pathlib import Path
import unittest
class DraftRouting(unittest.TestCase):
def test_scoped_draft_decision_points(self):
text=(Path(__file__).resolve().parents[1]/'SKILL.md').read_text()
for marker in ['startup/readiness/shutdown','public API/exports','develop-monorepo-pnpm-app-skic','develop-monorepo-pnpm-package-skic','draft review aids, not approved standards','do not enforce a proposed convention','one implementation worker per Task','loading a draft grants no execution authority','workspace/build/package-manager mechanics']:
self.assertIn(marker,text)
if __name__=='__main__':unittest.main()
+34
View File
@@ -0,0 +1,34 @@
"""Central executable policy follows the global exact-candidate gates."""
from pathlib import Path
import unittest
ROOT = Path(__file__).resolve().parents[1]
class GlobalGateAlignment(unittest.TestCase):
def test_review_before_substantive_push(self):
gates = (ROOT/'references/task-delivery-gates.md').read_text()
stage = gates.split('### Stage 3')[1].split('### Stage 4')[0]
self.assertLess(stage.index('5. Freeze'), stage.index('6. Obtain independent'))
self.assertLess(stage.index('6. Obtain independent'), stage.index('7. Push only'))
self.assertIn('before its next substantive push', stage)
self.assertIn('reviewer must not be the candidate implementer', stage)
self.assertIn('read-only reviewer', stage)
self.assertNotIn('push the new PR head, and review', gates)
self.assertNotIn('No implementation or review subagent', gates)
def test_any_base_change_invalidates_readiness(self):
gates = (ROOT/'references/task-delivery-gates.md').read_text()
self.assertIn('Any target-base SHA change invalidates merge readiness', gates)
self.assertIn('even when candidate head/tree is unchanged', gates)
self.assertNotIn('base drift is harmless', gates)
self.assertNotIn('push/readback, and review', gates)
def test_kickoff_and_cross_repository_scope(self):
entry = (ROOT/'references/repository-entry-and-visibility.md').read_text()
self.assertIn('no file/tree changes', entry)
self.assertIn('does not authorize a substantive push', entry)
gates = (ROOT/'references/task-delivery-gates.md').read_text()
self.assertIn('documentation claims/handoffs and GitOps candidates', gates)
def test_no_unresolved_policy_marker(self):
for path in [ROOT/'SKILL.md', *ROOT.glob('references/*.md')]:
text = path.read_text()
self.assertNotIn('Bounded unresolved A02/A04', text)
self.assertNotIn('A02/A04 review-order/base-drift remain bounded unresolved', text)
if __name__ == '__main__':
unittest.main()
+7
View File
@@ -0,0 +1,7 @@
"""Validate the current bounded source contract, not full-program completion."""
from pathlib import Path
import subprocess,sys
ROOT=Path(__file__).resolve().parents[1]
if __name__=='__main__':
print('Source-contract checks only; A17 and deferred helpers are not completion claims.',flush=True)
subprocess.run([sys.executable,'-m','pytest','-q',str(Path(__file__).parent)],cwd=ROOT,check=True)