From da2842641194f04981639e982b25b003ad760889 Mon Sep 17 00:00:00 2001 From: Jarvis Jr Hermes Date: Thu, 13 Aug 2026 12:57:33 +0000 Subject: [PATCH] feat: define releases channel operations --- SKILL.md | 201 ++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 178 insertions(+), 23 deletions(-) diff --git a/SKILL.md b/SKILL.md index 5a78cf7..e34eec5 100644 --- a/SKILL.md +++ b/SKILL.md @@ -1,50 +1,205 @@ --- name: corp-v1-channel-releases -description: "Use as the central reference when defining or adopting project-scoped operating guidance for a Corp v1 releases channel. This repository is initial setup only; detailed purpose and procedures remain pending steering walkthrough." -version: 0.1.0 +description: "Use when operating or synchronizing a Corp v1 project's releases channel. Assesses release readiness and, only when the team requests a release, updates the Gondor v1 template source, renders it, pushes a separate branch to Gondor v1, and opens a pull request requiring team approval before deployment." +version: 1.0.0 author: Hermes Agent license: MIT metadata: hermes: - tags: [corp-v1, discord, channel, releases, reference] - related_skills: [corp-v1-steering-committee, home-v1-discord] + tags: [corp-v1, discord, channel, releases, gondor-v1, gitops, pull-request] + related_skills: [corp-v1-steering-committee, home-v1-discord, gondor-v1-nodes] --- -# Corp v1 Releases Channel Reference +# Corp v1 Releases Channel ## Overview -This is the central source skill for the `releases` channel created for each Corp v1 project. +This skill owns release readiness and the controlled release-change workflow for a Corp v1 project. It monitors the project's `general`, `architecture`, `delivery`, and `releases` channels for release implications, but it starts release execution only after an explicit team request. -**Current status: setup only.** Its detailed purpose, responsibilities, procedures, artifacts, authority boundaries, and verification rules are intentionally not defined yet. They will be agreed in a separate walkthrough before promotion beyond version `0.1.0`. +The release workflow updates the project-specific portion of: + +```text +https://gitea.lego-cloud.eu/home-v1/gondor-v1-tmpl +``` + +It then runs the repository's authoritative rendering process and pushes the rendered change to a separate branch in: + +```text +https://gitea.lego-cloud.eu/home-v1/gondor-v1 +``` + +The skill opens a pull request for team review. Deployment must not proceed until the team approves the pull request and all required gates pass. ## When to Use -Use this source when walking through the future `releases` channel skill, creating a reviewed project copy after finalization, or comparing an adopted copy with its source. +Use this skill when: -Do not use this version as complete operating guidance for a live project channel. +- operating in `corp-v1--releases`; +- running its recurring synchronization job; +- assessing release readiness; +- preparing version/changelog/deployment evidence; +- the team explicitly asks to release the project; +- updating Gondor v1 template/rendered configuration through a reviewable PR; +- tracking migration, rollback, deployment, and post-release outcomes. -## Adoption Contract +Do not start a release merely because CI is green or a synchronization run detected changes. -After finalization, `corp-v1-steering-committee` requires a project copy named `corp-v1-channel-releases--` under `corp-v1--skills-code-agent`. Adoption preserves source history and attribution, applies project context, validates the result, and records the source branch and commit. +## Approved Information Boundary -Creating existing-project copies is explicitly deferred until separately requested. +Inspect only: -## Purpose Definition Pending +```text +corp-v1--general +corp-v1--architecture +corp-v1--delivery +corp-v1--releases +``` -The walkthrough must define channel outcomes, responsibilities, activities, artifacts, cross-channel relationships, applicable engineering skills, synchronization behavior, approval boundaries, and verification criteria. +Use mapped-channel history to avoid duplicate work and new relevant activity from the other three channels. Never inspect another project's channels. + +## Release Readiness + +Before proposing or executing a release, verify: + +- explicit team release request and intended scope; +- target project, environment, version, image/artifact references, and source commit; +- approved requirements and architecture implications; +- required tests, builds, CI, security/quality gates, and artifacts; +- changelog/release notes accuracy; +- configuration and secret **names/references** without accessing secret values; +- migrations, compatibility, dependencies, capacity, and operational risk; +- rollback strategy and previous known-good state; +- deployment verification and ownership plan; +- unresolved blockers and required approvals. + +Readiness reporting does not itself authorize deployment. + +## Controlled Gondor v1 Release Workflow + +### Gate 1 — explicit request + +Require an unambiguous request from the project team identifying the project and intended release. If version, environment, artifact, or scope is missing, prepare a readiness summary and ask for the missing decision rather than guessing. + +### Gate 2 — discover repositories and instructions + +1. Load applicable Gitea and Gondor v1 skills. +2. Fetch both repositories and verify authenticated identity, remotes, default branches, clean worktrees, and divergence. +3. Inspect repository-native instructions, Taskfiles/scripts, schemas, and validation commands. +4. Identify the exact project-owned template subtree and generated destination. +5. Verify no unrelated project configuration will be modified. + +### Gate 3 — update template source + +Make the smallest project-scoped change in `home-v1/gondor-v1-tmpl`. The template repository remains the source of truth; do not patch generated Gondor output manually as a substitute. + +Validate template syntax, project values, artifact references, naming, and any repository-specific schema/checks. Keep secrets out of files, logs, commits, and chat. + +### Gate 4 — render + +Run the repository's authoritative rendering command. Do not invent a renderer command. Compare generated output and confirm: + +- only expected project files changed; +- output matches the requested release inputs; +- no unrelated generated content drifted; +- generated configuration passes repository validation. + +If rendering changes unexpected projects/resources, stop and report the discrepancy. + +### Gate 5 — separate branch in Gondor v1 + +Create a dedicated, descriptive branch in `home-v1/gondor-v1`, for example: + +```text +release/corp-v1-- +``` + +Use the project's actual branching convention when defined. Commit only intended rendered artifacts, push the branch, and verify remote SHA equality and readback. + +If the template repository itself also requires a reviewed source change, follow its repository policy and preserve traceability between source and rendered commits. Never force-push or bypass protected branches. + +### Gate 6 — pull request + +Open a PR against the configured deployment branch with: + +- project, environment, version, and requested scope; +- source application commit and artifact/image references; +- template source commit; +- rendered Gondor commit; +- changed resources; +- validation and CI evidence; +- migration and rollback notes; +- risks, blockers, and required reviewers; +- explicit statement: **team approval required before deployment**. + +Read back the PR URL, number, head/base SHAs, state, checks, and review status. + +### Gate 7 — stop before deployment + +Opening the PR completes autonomous release preparation. Do not merge, synchronize GitOps, or deploy unless the team separately approves that action and the applicable deployment workflow explicitly authorizes execution. + +## Post-Approval and Deployment Evidence + +When separately authorized after approval: + +- verify approval and required checks still apply to the exact head SHA; +- follow Gondor/GitOps deployment instructions; +- monitor actual deployment state; +- verify health and release-specific acceptance checks; +- post version, commit, PR, deployment, and rollback evidence; +- record post-release outcomes and unresolved follow-up. + +Never claim deployment from a merged PR alone. + +## Synchronization Workflow + +1. Read new same-project activity and enough release history to avoid duplicates. +2. Identify readiness changes, version/changelog drift, deployment evidence, migration/rollback risk, and release requests. +3. Without an explicit release request, maintain readiness information and proposals only. +4. With an explicit request, execute the controlled workflow through PR creation. +5. Verify every repository, branch, commit, render, check, and PR claim. +6. Post a concise release update; otherwise remain silent. + +## Authority and Escalation + +May autonomously after explicit release request: + +- assess readiness; +- update project-scoped template configuration; +- run rendering and validation; +- create commits and a separate branch; +- push the branch and open a PR; +- prepare release notes and rollback guidance. + +Requires separate approval for: + +- merging the release PR; +- deployment/GitOps synchronization; +- migrations with impact; +- rollback execution; +- changing secrets, permissions, costs, or unrelated infrastructure; +- destructive or irreversible operations. ## Common Pitfalls -1. Treating this setup scaffold as finalized policy. -2. Creating project copies before the requested migration. -3. Defining behavior indirectly instead of completing the walkthrough. -4. Losing source history or attribution during adoption. +1. Treating green CI as a release request. +2. Editing generated Gondor files without updating template source. +3. Inventing render commands instead of reading repository instructions. +4. Including unrelated project drift in the release branch. +5. Opening a PR without traceable source/template/rendered commits. +6. Merging or deploying before team approval. +7. Claiming deployment from PR or commit state alone. +8. Exposing secret values while validating configuration. +9. Inspecting another project's channels. ## Verification Checklist -- [ ] Repository exists under `home-v1-skills-code-agent`. -- [ ] Default branch is `test`. -- [ ] Skill name is `corp-v1-channel-releases`. -- [ ] Version remains `0.1.0` until purpose is finalized. -- [ ] No project-scoped copy was created during setup. +- [ ] The team explicitly requested the release. +- [ ] Scope, version, environment, artifact, and source SHA are known. +- [ ] Readiness gates and blockers are recorded. +- [ ] Only the project's template portion changed. +- [ ] Authoritative rendering and validation passed. +- [ ] Rendered output contains only expected changes. +- [ ] A separate Gondor v1 branch was pushed and read back. +- [ ] PR head/base SHAs, checks, and URL were verified. +- [ ] The PR clearly requires team approval before deployment. +- [ ] No merge or deployment occurred without separate authorization.