feat: mine reusable AeroSim channel lessons

2026-09-10 11:41:47 +00:00
parent 1297bfd89f
commit 1093084a1f
2 changed files with 77 additions and 1 deletions
@@ -1,7 +1,7 @@
 ---
 name: corp-v1-channel-releases
 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.1
+version: 1.6.0
 author: Hermes Agent
 license: MIT
 metadata:
@@ -206,6 +206,19 @@ Requires separate approval for:
 - changing secrets, permissions, costs, or unrelated infrastructure;
 - destructive or irreversible operations.

+
+## Mined Project-Adoption Improvements
+
+## 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 after the approved release/deployment is promoted and verified. 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.