docs: reference shared channel workspace standard

SKILL.md

@@ -1,20 +1,24 @@
 ---
-name: corp-v1-channel-releases
+name: channel-releases-skic
 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.5.0
+version: 1.7.1
 author: Hermes Agent
 license: MIT
 metadata:
   hermes:
     tags: [corp-v1, discord, channel, releases, gondor-v1, gitops, pull-request]
-    related_skills: [corp-v1--main, home-v1-discord, gondor-v1-nodes, documentation-docusaurus, corp-v1--glossary]
+    related_skills: [channel-board-skic, home-v1-discord, gondor-v1-nodes, documentation-docusaurus, corp-v1-glossary]
 ---
 
-# Corp v1 Releases Channel
+# SKIC Releases Channel Reference
 
 ## Overview
 
-This skill owns release readiness and the controlled release-change workflow for a Corp v1 project. It monitors the project's `general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, and `releases` channels for release implications, but it starts release execution only after an explicit team request.
+## Hermes Kanban direct-link contract
+
+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.
+
+This skill owns release readiness and the controlled release-change workflow for a Corp v1 project. It monitors the project's `general`, `scope`, `architecture`, `ui-ux`, `kanban`, `delivery`, `uat`, and `releases` channels for release implications, but it starts release execution only after an explicit team request.
 
 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.
 
@@ -32,13 +36,24 @@ 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.
 
-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.
+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.
+
+## Shared Corp v1 System Login
+
+When an authorized task requires login to a Corp v1 system being built or operated, follow the shared policy in `channel-board-skic` and use only the Bitwarden-injected runtime secrets named:
+
+```text
+HL_V1_SSO_EMAIL
+HL_V1_SSO_PASSWORD
+```
+
+Secret availability is capability, not authorization. Verify the destination origin and task purpose before login. Never print, inspect, log, hash, serialize, paste, screenshot, or persist either value; never place a value in a command line, URL, file, repository, prompt, Discord message, browser console, test fixture, CI output, or generated artifact. Never ask a human to paste a value into chat. If a variable is unavailable, report only its missing name and request Bitwarden/gateway injection. Login does not authorize account recovery, MFA or credential changes, permission changes, billing, spending, destructive operations, or access outside the approved project task.
 
 ## When to Use
 
 Use this skill when:
 
-- operating in `corp-v1-<code>-releases`;
+- operating in `<code>-releases`;
 - running its recurring synchronization job;
 - assessing release readiness;
 - preparing version/changelog/deployment evidence;
@@ -57,16 +72,17 @@ Every releases iteration must add or materially improve at least one useful, saf
 Inspect only:
 
 ```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 mapped-channel history to avoid duplicate work and new relevant activity from the other six channels. Never inspect another project's channels.
+Use mapped-channel history to avoid duplicate work and new relevant activity from the other seven channels. Never inspect another project's channels.
 
 ## Release Readiness
 
@@ -90,7 +106,7 @@ Readiness reporting does not itself authorize deployment.
 
 ### 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.
+Require an unambiguous request from the project team identifying the project and intended release, and satisfy the UAT promotion gate below. If version, environment, artifact, scope, or required UAT evidence is missing, prepare a readiness summary and route the missing decision or evidence rather than guessing.
 
 ### Gate 2 — discover repositories and instructions
 
@@ -149,18 +165,25 @@ Read back the PR URL, number, head/base SHAs, state, checks, and review status.
 
 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.
 
+## UAT promotion gate
+
+For runtime releases, independently verify `UAT_PASSED` against the exact application commit, immutable image/chart identities, rendered non-production GitOps revision, controller revisions/sync/health, environment/base URL, E2E commit, and complete required journey set. Reject failed, blocked, stale, partial, or mismatched evidence and return it to UAT/Delivery. A release request does not waive UAT; a UAT pass does not authorize release. Non-runtime work may use only an explicitly justified, verified non-applicability record under the project release policy.
+
+Promotion preserves the tested application/artifact identity but creates a distinct production desired-state revision. Record the mapping and verify production separately; the UAT environment's GitOps commit or healthy state is not production deployment evidence.
+
 ## 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;
+- verify the owning controller's deployed revision, runtime source/chart identity, pod image digests, and endpoint against the approved production desired state; for app-of-apps, reconcile through the owning root rather than directly patching a managed child;
+- verify release-specific acceptance through ordinary user-visible controls and meaningful runtime outcomes; forced interactions or hidden state/API bypasses are diagnostic only, and healthy infrastructure cannot excuse an unusable journey;
+- record technical deployment health, automated acceptance, and human post-release acceptance separately; the latter remains `PENDING` until explicit confirmation, and a human-reported blocking defect makes it `FAILED`;
 - post version, commit, PR, deployment, and rollback evidence;
 - record post-release outcomes and unresolved follow-up.
 
-Never claim deployment from a merged PR alone.
+Never claim deployment from a merged PR alone, or human acceptance from release authorization. If a deployed release fails a core journey, record it as rejected but still deployed until containment is verified. Preserve its immutable version, artifacts, and failure evidence; agree authorized rollback or maintenance with the release owner and route a new immutable corrective release through Delivery, UAT, and Releases. Do not silently retag or overwrite the rejected version. Unapproved containment remains an explicit risk, not an action this skill authorizes.
 
 ## UI/UX Coordination
 
@@ -168,12 +191,12 @@ For frontend-affecting releases, Releases verifies the approved UI/UX acceptance
 
 ## Synchronization Workflow
 
-1. Read new same-project activity and enough release history to avoid duplicates.
+1. Read new activity from all eight mapped same-project channels 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, proactively improve readiness documentation, version/changelog evidence, rollback planning, or a concrete blocker/approval request 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 with documentation and verification evidence, or the concrete gate that prevented useful work.
+6. Return a concise release update with evidence or the blocking gate. If the execution context auto-delivers the final response, do not post a duplicate message. Claim message delivery only with a verified receipt; repository readback is not message delivery evidence.
 
 ## Authority and Escalation
 
@@ -195,6 +218,21 @@ Requires separate approval for:
 - changing secrets, permissions, costs, or unrelated infrastructure;
 - destructive or irreversible operations.
 
+
+## Mined Project-Adoption Improvements
+
+Review provenance and exclusions: [AeroSim lessons review](references/aerosim-lessons-review.md).
+
+## 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.
+
+## Project-Adoption Release Lessons
+
+Releases—not Delivery—owns the final `TO_BE_RELEASED → DONE` transition. Apply it only from canonical `TO_BE_RELEASED`, after the approved release/deployment is promoted and verified and the UAT promotion gate passes. Record the actual version, immutable artifact/digest where applicable, deployment revision, runtime health, acceptance evidence, actor/time, and append-only history linkage. The exit gate is remote documentation showing `DONE` after the release-specific checks pass; merged code, green integration CI, or a published image alone is insufficient.
+
+Recurring readiness work must refresh mutable owner PR heads and the latest exact-head CI tasks, prevent self-stale references to the readiness PR's own head, guard against concurrent writers, replace stale open/pending wording after merges, and verify exact remote artifact bytes before reporting. Follow [references/recurring-readiness-pr-refresh.md](references/recurring-readiness-pr-refresh.md).
+
 ## Common Pitfalls
 
 1. Treating green CI as a release request.
@@ -221,3 +259,16 @@ Requires separate approval for:
 - [ ] The PR clearly requires team approval before deployment.
 - [ ] No merge or deployment occurred without separate authorization.
 - [ ] At least one useful release artifact was improved, or a concrete human-request/approval blocker was documented.
+
+## Canonical naming and compatibility
+
+- Canonical installed and repository name: `channel-releases-skic`.
+- Source: `https://gitea.lego-cloud.eu/home-v1-skills-code-agent/channel-releases-skic`.
+- Previous name: `corp-v1-channel-releases`; 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-releases-skic-<code>` and remain separately owned.
+- Current project channel: `<code>-releases` 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.

references/aerosim-lessons-review.md

@@ -0,0 +1,29 @@
+# AeroSim lessons review — Releases
+
+## Immutable sources
+
+AeroSim Releases source SHA: `3c4b4788915bae3d89303959c46a8854c9a141bc`. Central baseline: `2844c4a5f7231ab597519a59f5f11cfe1c858b9f`.
+- [SKILL.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-releases-skic-aerosim/src/commit/3c4b4788915bae3d89303959c46a8854c9a141bc/SKILL.md)
+- [references/recurring-readiness-pr-refresh.md](https://gitea.lego-cloud.eu/corp-v1-aerosim-skills-code-agent/channel-releases-skic-aerosim/src/commit/3c4b4788915bae3d89303959c46a8854c9a141bc/references/recurring-readiness-pr-refresh.md)
+
+Read the full source skill and readiness reference against their central counterparts. Relevant sections: **Release Readiness**, **Gate 1 — explicit request**, **UAT promotion gate**, **Release Completion Gate**, and **Synchronization Workflow**.
+
+## Promoted lessons
+
+- Consume a complete, exact-tuple UAT pass independently of release authorization. Record a separate production desired-state revision and verify it live rather than relabeling development evidence.
+- Preserve immutable rejected-release evidence and require a new corrective release; containment remains separately authorized.
+- Separate technical health, automated acceptance, and explicit human acceptance. Use ordinary visible interactions, not diagnostic bypasses.
+- Include UAT and UI/UX in readiness collection; remove stale six-channel coverage. Respect auto-delivered reports and require receipts for message-delivery claims.
+- Keep existing readiness race guards, PR reuse, latest exact-head CI, and self-reference avoidance in their reference rather than duplicating the long AeroSim synchronization procedure.
+
+## Runtime drift reviewed
+
+Installed Releases `SKILL.md` SHA-256: `feac09e2515486abc35a5b127525ec3a13ca97d47f12b32cf68e434c50df9ece`. Its **Post-Approval and Deployment Evidence**, **Production Rejection and Replacement**, and **Release Completion Gate** add the acceptance and rejected-release lessons above. These are supplementary local snapshot evidence, not text attributed to the pinned source SHA. Runtime is not uniformly newer: its deployment repository wording and Gate 1 omit safeguards present in the Git source; those regressions are excluded. Hard-coded app-of-apps identities, flight-specific dwell instructions, standing merge authority, and Copier environment repair are not transplanted.
+
+## 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.

references/recurring-readiness-pr-refresh.md

@@ -0,0 +1,63 @@
+# Recurring release-readiness PR refresh
+
+Use this procedure when an existing release-readiness PR consolidates mutable evidence from Scope, Architecture, UI/UX, Kanban, Delivery, UAT, or another readiness source. It prevents a successful update from publishing evidence that was already stale when committed.
+
+## 1. Discover rather than hard-code
+
+1. Read new activity from all eight allowed project channels and enough Releases history to identify the last reported evidence window. Use a stored or artifact-derived high-watermark and paginate until that boundary is reached; a fixed latest-N sample can be filled by recurring bot reports and cannot prove that no human release request or approval occurred. Record author type and distinguish human authorization from bot summaries.
+   - If no separate synchronization-state file exists, derive each channel's boundary from the last verified releases report or from the readiness artifact's channel evidence links. Do not use one global timestamp when exact per-channel message IDs are available.
+   - Keep authorization coverage separate from display truncation. A collector may emit only the newest few messages for review, but its human-message count, newest-message ID, and high-watermark-reached assertion must be computed over **every fetched page**, not only the shortened digest. Record per channel: fetched oldest/newest IDs, boundary ID, whether the boundary was reached, and every human-authored message since that boundary. Refuse to claim that no human request or approval exists when any channel has not reached its verified boundary.
+   - Treat a helper that only prints the newest messages as a display digest, not an authorization collector. Before relying on an existing helper, inspect its channel map and output contract: it must include General, Scope, Architecture, UI/UX, Kanban, Delivery, UAT, and Releases and must emit the boundary/coverage fields above. Replace or parameterize helpers that hard-code one run's PR numbers, SHAs, task IDs, or message IDs.
+2. Discover the readiness PR by purpose, changed artifact, and source branch—not by title alone.
+   - If it is open and owns the same readiness page and purpose, fetch its exact remote source ref, fast-forward the clean worktree to that head, and refresh it in place.
+   - If it is closed or merged, preserve it as historical evidence and create a successor branch from the freshly fetched default branch. Never revive or append commits to the old review branch merely because that ref still exists remotely.
+   - Open Scope, Architecture, Kanban, or Delivery PRs remain independent evidence sources. Do not stack the readiness artifact onto one of those branches unless that PR already owns the readiness page and purpose.
+3. Resolve every cited PR from the Gitea API. Record its state, merged flag, head/base refs, full head/base SHAs, merge commit when applicable, and URL. Treat a closed PR's source-head CI as historical source validation; use the final default-branch SHA and exact-SHA task as the current merged baseline.
+4. Query Actions tasks and select the latest task for each exact head SHA by numeric task ID or creation time. Require terminal `success` before citing it.
+5. Read the current authoritative artifacts from the exact cited SHAs—for example Scope approval records and Kanban Board/Focus—not only from channel summaries.
+
+Do not bake current PR numbers, SHAs, or task IDs into a reusable collector or verifier. Pass them through a run-specific evidence map or generated snapshot so the helper remains reusable.
+
+## 2. Build a replacement map
+
+Before editing, construct two explicit sets:
+
+- **Required current markers:** every new full head SHA, task ID/run, and substantive decision or blocker that the refreshed page must contain.
+- **Superseded markers:** every prior SHA/task pair that must be absent after the update.
+
+Replace every occurrence of an obsolete pair, including summary tables, narrative sections, dependency maps, and approval packets. Search separately for stale boundary language and old channel counts.
+
+For the readiness PR itself, do not place its mutable current head SHA or exact-head task inside the artifact it owns. Report that pair externally after publication.
+
+## 3. Validate and apply the pre-commit race guard
+
+1. Run the repository-native full validation and `git diff --check`.
+2. Immediately before committing, re-read every cited PR and its latest exact-head task.
+3. Compare the fresh snapshot with the replacement map used in the artifact.
+4. If any head or latest task changed, update every occurrence, rerun affected validation, and repeat the guard.
+5. Confirm the local readiness branch still equals the exact remote branch head before committing; never overwrite a concurrent writer.
+
+A passing build does not satisfy this guard. The guard is about evidence freshness, not syntax.
+
+## 4. Publish and verify
+
+1. Commit only the intended readiness artifact and push the existing review branch without force.
+2. Verify local/remote ref equality.
+3. Poll Actions for the new full readiness head and require the latest matching task to succeed.
+4. Read the artifact back through the authenticated raw API at the exact pushed SHA.
+5. Assert programmatically that every required current marker is present and every superseded marker is absent.
+6. Re-read the PR and task list once more immediately before reporting; retries can create a newer task for the same SHA.
+7. Re-scan all eight allowed channels before the final report so a newly posted human release request or approval is not missed while CI was running.
+
+## 5. Report the gate accurately
+
+Report:
+
+- no release was initiated unless an explicit human request was found;
+- current Scope lifecycle and exact Kanban `ToBeReleased`/Focus state;
+- readiness PR URL, branch, full head/base SHAs, state, merge status, and latest exact-head task;
+- validation and authenticated readback results;
+- remaining human review sequence;
+- explicit confirmation that no merge, Gondor change, release, migration, or deployment occurred.
+
+Green documentation CI is planning evidence only. It is never a release request, candidate artifact, `ToBeReleased` admission, deployment approval, or proof of deployment.

tests/test_aerosim_lessons_contract.py

@@ -0,0 +1,58 @@
+"""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 / 'SKILL.md').read_text()
+        self.assertIn('## UAT promotion gate', text)
+        self.assertIn('A release request does not waive UAT', text)
+        self.assertIn('distinct production desired-state revision', text)
+        self.assertIn('human post-release acceptance', text)
+        self.assertIn('new immutable corrective release', text)
+        self.assertIn('<code>-uat', text)
+        self.assertIn('version: 1.7.1', text)
+
+    def test_contract_1(self):
+        text = (ROOT / 'references/recurring-readiness-pr-refresh.md').read_text()
+        self.assertIn('General, Scope, Architecture, UI/UX, Kanban, Delivery, UAT, and Releases', text)
+
+    def test_separate_authority_and_no_stale_channel_count(self):
+        text = (ROOT / "SKILL.md").read_text()
+        refresh = (ROOT / "references/recurring-readiness-pr-refresh.md").read_text()
+        self.assertIn("Do not merge, synchronize GitOps, or deploy unless", text)
+        self.assertIn("the team separately approves that action", text)
+        self.assertIn("a UAT pass does not authorize release", text)
+        self.assertIn("Do not silently retag or overwrite", text)
+        self.assertIn("do not post a duplicate message", text)
+        self.assertNotIn("all six allowed", refresh)
+        self.assertIn("latest exact-head CI", text)
+
+
+if __name__ == "__main__":
+    unittest.main()