feat: define releases channel operations
This commit is contained in:
@@ -1,50 +1,205 @@
|
|||||||
---
|
---
|
||||||
name: corp-v1-channel-releases
|
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."
|
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: 0.1.0
|
version: 1.0.0
|
||||||
author: Hermes Agent
|
author: Hermes Agent
|
||||||
license: MIT
|
license: MIT
|
||||||
metadata:
|
metadata:
|
||||||
hermes:
|
hermes:
|
||||||
tags: [corp-v1, discord, channel, releases, reference]
|
tags: [corp-v1, discord, channel, releases, gondor-v1, gitops, pull-request]
|
||||||
related_skills: [corp-v1-steering-committee, home-v1-discord]
|
related_skills: [corp-v1-steering-committee, home-v1-discord, gondor-v1-nodes]
|
||||||
---
|
---
|
||||||
|
|
||||||
# Corp v1 Releases Channel Reference
|
# Corp v1 Releases Channel
|
||||||
|
|
||||||
## Overview
|
## 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
|
## 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-<code>-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--<code>` under `corp-v1-<code>-skills-code-agent`. Adoption preserves source history and attribution, applies project context, validates the result, and records the source branch and commit.
|
## Approved Information Boundary
|
||||||
|
|
||||||
Creating existing-project copies is explicitly deferred until separately requested.
|
Inspect only:
|
||||||
|
|
||||||
## Purpose Definition Pending
|
```text
|
||||||
|
corp-v1-<code>-general
|
||||||
|
corp-v1-<code>-architecture
|
||||||
|
corp-v1-<code>-delivery
|
||||||
|
corp-v1-<code>-releases
|
||||||
|
```
|
||||||
|
|
||||||
The walkthrough must define channel outcomes, responsibilities, activities, artifacts, cross-channel relationships, applicable engineering skills, synchronization behavior, approval boundaries, and verification criteria.
|
Use 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-<code>-<version>
|
||||||
|
```
|
||||||
|
|
||||||
|
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
|
## Common Pitfalls
|
||||||
|
|
||||||
1. Treating this setup scaffold as finalized policy.
|
1. Treating green CI as a release request.
|
||||||
2. Creating project copies before the requested migration.
|
2. Editing generated Gondor files without updating template source.
|
||||||
3. Defining behavior indirectly instead of completing the walkthrough.
|
3. Inventing render commands instead of reading repository instructions.
|
||||||
4. Losing source history or attribution during adoption.
|
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
|
## Verification Checklist
|
||||||
|
|
||||||
- [ ] Repository exists under `home-v1-skills-code-agent`.
|
- [ ] The team explicitly requested the release.
|
||||||
- [ ] Default branch is `test`.
|
- [ ] Scope, version, environment, artifact, and source SHA are known.
|
||||||
- [ ] Skill name is `corp-v1-channel-releases`.
|
- [ ] Readiness gates and blockers are recorded.
|
||||||
- [ ] Version remains `0.1.0` until purpose is finalized.
|
- [ ] Only the project's template portion changed.
|
||||||
- [ ] No project-scoped copy was created during setup.
|
- [ ] 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.
|
||||||
|
|||||||
Reference in New Issue
Block a user