[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF1784RASG41CSB057HMGY":3,"skill-same:01M6CF1784RASG41CSB057HMGY":119},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":6,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M6CF1784RASG41CSB057HMGY","release",null,"Ship a version as a measured coherence delta with matching code, changelog, tag, release notes, deployment, and validation.","usurobor\u002Fcnos","usurobor","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F182342826?v=4","01M6CEXJCRMYD8HB2315FGB1Q8","Peter Lisovin","01M6CEXJH2RW04GQ2SNXY40F5S",9,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Frelease\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"ship","delta","cdd","embedded","version","approval","context","branch","decision","how","deploy","SET","beta","changelog","validation","code","deployment","release notes","notes","2026-11-10 10:12:30",false,"---\nname: release\ndescription: Ship a version as a measured coherence delta with matching code, changelog, tag, release notes, deployment, and validation.\nartifact_class: skill\nkata_surface: embedded\ngoverning_question: How does β turn a converged branch into a released version with a complete and auditable coherence delta?\nvisibility: internal\nparent: cdd\ntriggers:\n  - release\n  - ship\n  - tag\n  - version\n  - deploy\n  - changelog\nscope: task-local\ninputs:\n  - approved branch\n  - version decision\n  - release context\noutputs:\n  - release artifact set\n  - beta close-out\nrequires:\n  - approval and release readiness\ncalls: []\n---\n\n# Release\n\n## Core Principle\n\n**Coherent release: every version bump is a measured coherence delta with a complete audit trail.**\n\nβ owns: review approval outcome, `git merge` into main, and β close-out. **δ owns tag\u002Frelease\u002Fdeploy** (the release boundary — `scripts\u002Frelease.sh`, binary publication, deployment). γ owns `RELEASE.md` authoring, cycle-directory movement, and the post-release assessment. β does not tag, push tags, bump versions for release, or cut the disconnect release. See `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Development lifecycle\" → §\"Step table\" (Step 8 β review\u002Fmerge; Steps 9–13 γ-and-δ release sequence), `operator\u002FSKILL.md` §3.4 (doctrinal frame), and `release-effector\u002FSKILL.md` (mechanics).\n\nCanonical artifact locations (β close-out path, RELEASE.md, snapshot dirs, tag policy) are defined in `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Artifact contract\" → §\"Location matrix\". All tags are bare `X.Y.Z`; `v`-prefixed tags are legacy and warn-only.\n\nA release has parts: readiness check, version decision, changelog, release notes, tag, binaries, deployment, validation. Coherence = each part completed and each artifact matches the others (version in code = tag = changelog = binary = deployed agent). The released system is validated, not merely published.\n\nFailure mode: version drift — tag says X, binary says Y, agent reports Z. Or: releasing without validation, so breakage ships silently. Or: incomplete deploy where artifacts ship but assessment never lands.\n\n## 1. Define\n\n1.1. **Identify the parts**\n  - Readiness: CI green, branches merged or returned, main clean\n  - Version: semver bump decided from commit content\n  - Artifacts: cn.json, VERSION, package manifests, CHANGELOG, RELEASE.md, tag, GitHub release, binaries\n  - Deployment: binary on target hosts, `cn deps restore`, validation\n  - ❌ Push tag, hope it works\n  - ✅ Every artifact checked, deployed, validated end-to-end\n\n1.2. **Articulate how they fit**\n  - Version flows: VERSION → `stamp-versions.sh` → cn.json + package manifests → CHANGELOG → commit → tag → CI → binaries → deploy → validate\n  - Each step depends on the prior; skip one and the chain breaks\n  - ❌ Tag pushed before version bumped in code (binary reports old version)\n  - ✅ Version string updated everywhere before commit, tag matches code\n\n1.3. **Name the failure mode**\n  - Version drift: any two artifacts disagree on the version\n  - Silent breakage: release ships but CI failed or validation skipped\n  - Incomplete deploy: binary updated but packages stale (`cn deps restore` not run)\n  - ❌ \"cn update worked\" (but agent still reports old version)\n  - ✅ `cn --version` matches tag, `cn deps restore` run, agent can execute ops\n\n## 2. Unfold\n\n2.1. **Readiness check**\n  - CI passing on main (unit tests + integration tests + kata suite)\n  - No unmerged branches that should be in this release\n  - `git branch -r --no-merged origin\u002Fmain` — review each, merge or defer\n  - **Non-destructive merge-test on the merge tree before merge.** Build the merge tree in a throwaway worktree (`git worktree add \u002Ftmp\u002Fcnos-merge-test\u002Fwt origin\u002Fmain && cd \u002Ftmp\u002Fcnos-merge-test\u002Fwt && git merge --no-ff --no-commit origin\u002Fcycle\u002F{N}`); run any contract validators the cycle ships (e.g. `.\u002Ftools\u002Fvalidate-skill-frontmatter.sh` if the cycle adds or modifies SKILL.md frontmatter; `cn-cdd-verify` for `.cdd\u002F` artifacts; `scripts\u002Fcheck-version-consistency.sh` for version stamping); confirm zero unmerged paths and zero new validator findings. Tear down the worktree. **Set any worktree-local git config with the explicit `--worktree` flag** (`git config --worktree user.name X`) to avoid leaking identity to the shared repo `.git\u002Fconfig` (cycle #301 O8). This pattern is also referenced from `beta\u002FSKILL.md` § pre-merge gate row 3 — it is the same step, named here so the release-flow doc is authoritative.\n  - ❌ Release with failing CI (\"it's just a flaky test\")\n  - ❌ Merge without running the cycle's own validators on the merge tree (\"the cycle branch passes; the merge tree will too\")\n  - ✅ CI green, or known failure documented and accepted (e.g. Coherence workflow on #22)\n  - ✅ Merge-tree validation green (especially when the cycle ships a new contract surface like #301's I5 frontmatter validator)\n\n2.2. **Version decision**\n  - Review commits since last tag: `git log --oneline $(git describe --tags --abbrev=0)..HEAD`\n  - Major: breaking changes, paradigm shift\n  - Minor: new features, backwards compatible (new ops, new skills, new specs)\n  - Patch: bug fixes only\n  - ❌ Patch for a new runtime feature (undersells the change)\n  - ✅ Minor for new `Cn_shell.execute` entry point; patch for CI fix\n\n2.3. **Version bump — VERSION-first flow**\n  - `VERSION` file at repo root is the single source of truth\n  - Edit `VERSION` to the new version string (bare, no `v` prefix)\n  - Run `scripts\u002Fstamp-versions.sh` — derives all manifests (`cn.json`, package `cn.package.json` files) from VERSION\n  - Run `scripts\u002Fcheck-version-consistency.sh` — validates all version-stamped files agree\n  - Binary embeds version from VERSION at build time — no manual edit needed\n  - Tests and katas read version dynamically — no manual edit needed\n  - ❌ Edit cn.json or package manifests by hand (bypasses single source of truth)\n  - ❌ Skip stamp-versions.sh (\"I'll update the manifests manually\")\n  - ✅ `echo \"X.Y.Z\" > VERSION && scripts\u002Fstamp-versions.sh && scripts\u002Fcheck-version-consistency.sh`\n\n2.4. **CHANGELOG**\n  - Add a ledger row matching the format defined in `CHANGELOG.md` § Release Coherence Ledger. That format is canonical — do not reinvent the row shape here.\n  - The ledger row includes: Version, C_Σ, α, β, γ, Level, Rounds, and a coherence note. The **Rounds** column records the review-round count for the release's cycle (e.g. `1`, `2`, `3`); for releases bundling multiple cycles, sum or list (`1+2`). This is a learning-curve indicator — a rising trend signals process drift, a falling trend signals accumulated context.\n  - **Provisional vs. final scoring rule:** β writes the CHANGELOG TSC row at release commit with `provisional, pending γ PRA` in the level cell (or in a parenthetical next to the level). γ updates the cell to the final value in the same commit as the PRA. This ensures one writer per fact while preserving the release-time ledger entry.\n  - Add a detailed section below the ledger: Added \u002F Changed \u002F Fixed, with each commit's impact named and linked to issues.\n  - ❌ \"Various improvements\" (no detail)\n  - ❌ Ledger row without engineering level (Level column is required)\n  - ✅ Each commit's impact named, linked to issues\n  - ✅ Honest TSC grades — not everything is A+\n  - `RELEASE.md` must restate the ledger row as the Outcome section in prose. The ledger row remains canonical; the release body explains it.\n  - If release notes or CHANGELOG wording are being authored, load the write skill and record it in the CDD Trace.\n\n2.5. **Release notes — RELEASE.md**\n  - Write `RELEASE.md` at repo root before tagging. This is the GitHub release body.\n  - A release is a measured coherence delta. The release body must foreground what got more coherent and why, then detail the changes.\n  - The release CI workflow uses `RELEASE.md` as the release body if present; otherwise it auto-generates from commit titles (sparse and unstructured — not acceptable).\n  - `RELEASE.md` is committed in the release commit and consumed by CI. It stays in the repo until the next release overwrites it.\n  - ❌ Let CI auto-generate release notes (just commit titles, no detail)\n  - ❌ Jump straight into Fixed\u002FAdded\u002FChanged (change-loggy, not coherence-framed)\n  - ❌ Manually create the GitHub release after CI (race condition with workflow)\n  - ✅ Outcome first, then changes, then proof\n  - ✅ Write `RELEASE.md` → commit in release commit → CI uses it as release body\n\n  ```markdown\n  # RELEASE.md format\n\n  ## Outcome\n\n  Coherence delta: C_Σ {grade} (`α {grade}`, `β {grade}`, `γ {grade}`) · **Level:** `L{level}`\n\n  One short paragraph:\n  - what became more coherent\n  - what surface is now more truthful \u002F portable \u002F durable \u002F explicit\n\n  ## Why it matters\n\n  One short paragraph:\n  - what incoherence this cycle targeted\n  - why it mattered operationally or structurally\n  - what changed in the system's behavior or authority model\n\n  ## Fixed\n\n  - **Short description** (#issue): what changed and why it matters.\n\n  ## Added\n\n  - **Short description** (#issue): what was added and what new capability or clarity it provides.\n\n  ## Changed\n\n  - **Short description** (#issue): what changed in behavior, authority, or shape.\n\n  ## Removed\n\n  - **Short description** (#issue): what was removed and what incoherence it eliminated.\n\n  ## Validation\n\n  - Deployed to [target], validated [specific check].\n  - State what was proven coherent by the validation, not only that deployment succeeded.\n\n  ## Known Issues\n\n  - #N — description (if any found during validation)\n  ```\n\n2.5a. **Move cycle directories to release directory** (tagged release)\n  - Move every per-cycle directory from `.cdd\u002Funreleased\u002F{N}\u002F` to `.cdd\u002Freleases\u002F{X.Y.Z}\u002F{N}\u002F`:\n    ```bash\n    mkdir -p .cdd\u002Freleases\u002FX.Y.Z\n    for dir in .cdd\u002Funreleased\u002F*\u002F; do\n      [ -d \"$dir\" ] || continue\n      mv \"$dir\" .cdd\u002Freleases\u002FX.Y.Z\u002F\n    done\n    ```\n  - Each `.cdd\u002Freleases\u002F{X.Y.Z}\u002F{N}\u002F` directory carries the same role-prefixed files that lived in `.cdd\u002Funreleased\u002F{N}\u002F` during the cycle (`self-coherence.md`, `beta-review.md`, `alpha-closeout.md`, `beta-closeout.md`, `gamma-closeout.md`, plus any cycle-specific extras) per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Coordination surfaces\" + §\"Artifact contract\" → §\"Location matrix\".\n  - Include the moves in the release commit\n  - `.cdd\u002Funreleased\u002F` should be empty after the release commit\n  - ❌ Leave cycle directories in `unreleased\u002F` after tagging (lose the version association)\n  - ❌ Move after the release commit (they should be part of the release snapshot)\n  - ✅ Move before commit, include in the release commit\n\n2.5b. **Docs-only disconnect (no tag)**\n\n  A cycle that ships only documentation, protocol artifacts, or assessments — with no code change and no version bump — still requires a disconnect, but the disconnect is the merge commit on main, not a tag.\n\n  Cases this covers:\n\n  - Retroactive close-out for a previously-released version (no new code, only frozen artifacts and CHANGELOG row backfill — the cycle for `usurobor\u002Ftsc#27` is the canonical example)\n  - Self-coherence reports and post-release assessments produced as their own cycle, not bundled with a code release\n  - Skill patches that ship only as protocol changes\n  - Doc-cleanup cycles (e.g. retiring stale references after a paradigm shift)\n\n  For docs-only cycles:\n\n  - `.cdd\u002Funreleased\u002F{N}\u002F` moves to `.cdd\u002Freleases\u002Fdocs\u002F{ISO-date}\u002F{N}\u002F` where `{ISO-date}` is the merge commit's date in `YYYY-MM-DD` form (e.g. `.cdd\u002Freleases\u002Fdocs\u002F2026-05-08\u002F27\u002F`).\n  - **No CHANGELOG ledger row.** The Release Coherence Ledger tracks tagged releases. γ records the cycle in `docs\u002Fgamma\u002Fcdd\u002Fdocs\u002F{ISO-date}\u002FPOST-RELEASE-ASSESSMENT.md` instead — same PRA structure as a tagged release, just keyed by date.\n  - The merge commit hash IS the disconnect signal. No `scripts\u002Frelease.sh` invocation. No version bump. VERSION is unchanged.\n  - `scripts\u002Fcheck-version-consistency.sh` is not required to run (nothing version-stamped changed).\n\n  ```bash\n  # Docs-only disconnect at merge time (run as part of γ closure):\n  ISO_DATE=\"$(date -u +%Y-%m-%d)\"\n  mkdir -p \".cdd\u002Freleases\u002Fdocs\u002F${ISO_DATE}\"\n  for dir in .cdd\u002Funreleased\u002F*\u002F; do\n    [ -d \"$dir\" ] || continue\n    mv \"$dir\" \".cdd\u002Freleases\u002Fdocs\u002F${ISO_DATE}\u002F\"\n  done\n  ```\n\n  - ❌ Leave docs-only cycle directories in `.cdd\u002Funreleased\u002F{N}\u002F` after merge (\"there's no release to move them to\")\n  - ❌ Force a synthetic version bump on a docs-only cycle just to fit the tagged-release flow\n  - ❌ Skip the PRA because no tag was pushed\n  - ✅ Move to `.cdd\u002Freleases\u002Fdocs\u002F{ISO-date}\u002F{N}\u002F` in the merge commit\n  - ✅ γ writes `docs\u002Fgamma\u002Fcdd\u002Fdocs\u002F{ISO-date}\u002FPOST-RELEASE-ASSESSMENT.md`\n\n  γ declares `docs-only` in the issue mode header (per `issue\u002FSKILL.md` §Mode declaration); the disconnect path is selected at issue-creation time, not retrofitted at merge.\n\n2.6. **Commit and signal readiness for δ tag**\n  - **Tag naming convention:** use bare version numbers without `v` prefix: `3.15.1`, not `v3.15.1`. This matches VERSION file content, branch naming (`claude\u002F3.15.0-22-...`), and snapshot directory names (`docs\u002Fgamma\u002Fcdd\u002F3.15.0\u002F`). Consistency across all version surfaces.\n  - **Tag message generation:** δ creates annotated tags (not lightweight tags) with structured messages that include issue metadata, wave context when present, and CDD review artifacts when available. The tag message is automatically generated by `scripts\u002Fgenerate-release-tag-message.sh` and includes issue titles, labels, review rounds, and deterministic fallback when metadata is unavailable.\n  - Commit: `git commit -m \"release: X.Y.Z — summary\"` (includes VERSION, manifests, CHANGELOG, RELEASE.md)\n  - **Before any push that follows a rebase, run the eng\u002Fship rebase-integrity gate** (see `eng\u002Fship` § Rebase-Collision Integrity)\n  - Push: `git push origin main`\n  - **β signals \"release ready for δ tag\"** in `beta-closeout.md` — β does not execute `git tag` or push tags; δ creates the single annotated tag `X.Y.Z` with generated message as part of the disconnect release flow (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Development lifecycle\" → §\"Step table\" Step 10 — δ release). RELEASE.md remains the GitHub release body authority; generated tag messages are additive.\n  - ❌ β pushes tag directly (conflicts with δ tag authority)\n  - ❌ Mix `v` prefix and bare versions across tags (`v3.14.6` then `3.14.7`)\n  - ❌ Commit without RELEASE.md (CI auto-generates sparse notes)\n  - ✅ Commit (with RELEASE.md), push, signal readiness in close-out; δ handles tagging\n\n2.6a. **Delete merged branches**\n  - After push, delete remote branches that were merged into this release\n  - `git branch -r --merged origin\u002Fmain | grep -v main | grep -v HEAD | sed 's\u002Forigin\\\u002F\u002F\u002F' | xargs -I{} git push origin --delete {}`\n  - This is mechanical cleanup, not judgment — if it's merged, it's dead\n  - ❌ Leave merged branches accumulating (\"someone might need them\")\n  - ✅ Clean up immediately after release push; history is in main\n\n2.7. **Wait for release CI**\n  - Release workflow builds binaries (linux-x64, macos-x64, macos-arm64)\n  - Wait for completion before deploying\n  - **δ owns release CI polling** per `release-effector\u002FSKILL.md` §3 — after tag push, δ monitors release workflow completion via `gh run list --branch \u003Ctag>`. β waits for δ confirmation.\n  - ❌ Deploy while CI still running (stale binary from previous release)\n  - ✅ `gh run watch {id} --exit-status` then verify assets attached\n\n2.8. **Deploy to target hosts**\n  - Stop daemon, download binary, replace, start daemon\n  - `cn deps restore` to sync cognitive substrate\n  - Validate: `cn --version`, test an op that exercises the fix\n  - ❌ Replace binary while daemon running (`Text file busy`)\n  - ✅ `systemctl stop → cp → chmod → systemctl start → cn --version`\n\n2.9. **Validate**\n  - Version matches everywhere: binary, cn.json, tag\n  - The specific fix or feature works end-to-end\n  - Check telemetry for errors on first cycle\n  - Validation must confirm the targeted coherence delta, not only binary\u002Fversion correctness.\n  - ❌ \"It deployed\" (no functional validation)\n  - ✅ Trace telemetry, confirm receipts\u002Fartifacts exist, agent responds correctly\n\n2.10. **CDD Trace update**\n  - Update the primary branch artifact's CDD Trace with the release row:\n    - artifact: tag \u002F CHANGELOG \u002F release artifact\n    - skills loaded: release, plus write if used\n    - decision: released version X.Y.Z\n  - If the triadic protocol is active, β also writes:\n    - release evidence in `.cdd\u002Funreleased\u002F{N}\u002Fbeta-closeout.md`\n    - β close-out narrative in `.cdd\u002Funreleased\u002F{N}\u002Fbeta-closeout.md` for γ to read (separate from `beta-review.md`, which carries the round-by-round verdicts; see `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Coordination surfaces\" → §\"Cycle-state evidence\")\n  - γ writes the post-release assessment after β's release and close-out are complete\n  - For triadic cycles, the primary branch artifact is `.cdd\u002Funreleased\u002F{N}\u002Fself-coherence.md` — it carries the trace through step 7a; β records the review verdict in `.cdd\u002Funreleased\u002F{N}\u002Fbeta-review.md` (steps 8–9) and the close-out + release evidence in `.cdd\u002Funreleased\u002F{N}\u002Fbeta-closeout.md` (step 10).\n\n## 3. Rules\n\n3.1. **All version strings must agree**\n  - VERSION, cn.json, package manifests, tag, binary output, CHANGELOG\n  - `scripts\u002Fcheck-version-consistency.sh` validates this mechanically\n  - ❌ Tag is 3.15.1 but VERSION says 3.15.2 (forgot to commit before tagging)\n  - ✅ `scripts\u002Fcheck-version-consistency.sh` passes before commit\n\n3.2. **CI must pass before tag**\n  - If CI fails after tag, fix and force-push tag (amend release commit)\n  - ❌ Ship with known test failure (\"we'll fix it next patch\")\n  - ✅ Fix the test, amend, force-push tag, wait for green\n\n3.3. **Never deploy stale binaries**\n  - Release CI builds from the tag; wait for it to complete\n  - Clear cached downloads (`--clobber` or `rm` old artifacts)\n  - ❌ `cn update` downloads cached v3.5.1 binary from \u002Ftmp\n  - ✅ Fresh download after CI completes, verify binary version after install\n\n3.4. **Deploy includes deps restore**\n  - Binary update alone leaves cognitive substrate stale\n  - `cn deps restore` syncs doctrine, mindsets, skills from packages\n  - ❌ Binary is v3.9.1 but skills are from v3.8.0 (package drift)\n  - ✅ `cn deps restore` immediately after binary update\n\n3.5. **Validate with the specific fix**\n  - Don't just check version — exercise the feature or fix\n  - ❌ \"Version looks right, ship it\"\n  - ✅ For #46: send a message, check telemetry for receipts, confirm artifacts exist\n\n3.6. **If CI fails post-tag, amend don't re-tag**\n  - `git commit --amend --no-edit && git tag -d X.Y.Z && git tag X.Y.Z && git push --force origin main X.Y.Z`\n  - Tags are **bare** (`X.Y.Z`, never `vX.Y.Z`) — see §2.6 and `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Artifact contract\" → §\"Location matrix\"\n  - Keeps a clean single tag, single release commit\n  - ❌ `git tag -d vX.Y.Z && git tag -a vX.Y.Z && git push --force --tags` (mixes legacy v-prefix; force-pushes all tags)\n  - ❌ `3.9.1`, `3.9.1-fix`, `3.9.1-fix2` (proliferating tags)\n  - ✅ One bare tag, amended until CI green\n\n3.7. **RELEASE.md must exist before tag**\n  - The release commit must include `RELEASE.md` at repo root\n  - If `RELEASE.md` is missing, the tag must not be pushed (CI will auto-generate sparse notes)\n  - ❌ Tag without RELEASE.md (\"I'll update the release body manually later\")\n  - ✅ Write RELEASE.md → include in release commit → tag → push\n\n3.8. **TSC scoring in CHANGELOG — honest-grading rubric**\n\n  Rate α (pattern), β (relation), γ (process) for each release. Honest grades — not everything is A+. The rubric below makes the grading reproducible across releases and reviewers.\n\n  **Per-axis rubric:**\n\n  | Grade | Numeric | Meaning |\n  |---|---|---|\n  | **A**   | 4.0 | met all ACs, no protocol skips, zero binding findings of the wiring or honest-claim class |\n  | **A-**  | 3.7 | met all ACs, ≤1 binding finding, all findings non-blocking |\n  | **B+**  | 3.3 | met all ACs, ≥2 binding findings or one round of RC |\n  | **B**   | 3.0 | met core ACs; partial-protocol release (e.g. missing RELEASE.md at tag time) **or** 2+ rounds of RC |\n  | **C+**  | 2.3 | shipped but missing one of: ledger row, PRA, provenance attachment |\n  | **C**   | 2.0 | partial-protocol release with multiple drift items |\n  | **\u003C C** | \u003C 2 | re-open and remediate; do not close |\n\n  **Closure-gate override (fires before geometric-mean computation).** If any artifact required by `gamma\u002FSKILL.md` §2.10 closure gate (per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Artifact contract\" → §\"Ownership matrix\") is absent from the cycle's `.cdd\u002Funreleased\u002F{N}\u002F` directory at merge time — specifically any of `alpha-closeout.md`, `beta-closeout.md`, or `gamma-closeout.md` for a triadic cycle — then `C_Σ` is forced to `\u003CC` regardless of per-axis math. Cycle disposition is \"open and remediate\"; the geometric mean is not computed. This override is verified mechanically by `scripts\u002Fvalidate-release-gate.sh --mode pre-merge` (see AC1, issue #339). The math below applies only after the closure gate passes.\n\n  **Letter normalization (`\u003CC` and `C−`).** The rubric table uses `\u003CC` as the grade label. Prior CHANGELOG, PRA, and alpha-closeout artifacts for cycles #331, #333, and #334 used `C−` for the same disposition. These are the same grade: `C−` is the operator-visible projection of `\u003CC`. Both mean \"open and remediate; do not close.\" Authors may use either form; the CHANGELOG column uses `\u003CC` for rubric fidelity and `C−` is accepted as equivalent in prose artifacts.\n\n  **C_Σ** is the geometric mean of the three numeric grades; report the closest letter grade (e.g. (3.7 · 3.3 · 4.0)^(1\u002F3) ≈ 3.66 ⟹ A-).\n\n  **Score the release, not the intent.** A retroactive partial-protocol close-out earns C+ honestly (e.g. `usurobor\u002Ftsc` cycle 27: v0.4.0 retroactive close-out scored α B \u002F β C+ \u002F γ C \u002F C_Σ C+ — the grade reflects what shipped, not the goodwill of fixing it later).\n\n  **Configuration-floor clause.** Cycles run under `operator\u002FSKILL.md §5.2` (single-session δ-as-γ via Agent tool) cap the γ axis at **A−** regardless of execution quality, because γ\u002Fδ separation is structurally absent. The A− γ floor applies from the cycle's merge forward; it is not retroactive. The configuration must be recorded explicitly in `gamma-closeout.md` (see AC6 of any cycle introducing or running under §5.2). Applying the A− cap is operator-honest discipline: if `gamma-closeout.md` does not declare §5.2, the rubric treats the cycle as §5.1 and the cap does not apply.\n\n  **CI-red cap clause.** Cycles with red CI on the merge commit cap the γ axis at **C** (one band below current floor). Cycles that proceed to close-out without verifying CI cap the γ axis at **B−**. CI is a mechanical gate; failing or skipping it reflects structural γ-axis failure in cycle coordination, not judgment calls.\n\n  **False-gap peer-enumeration clause.** Cycles that ship on a false-gap premise (where the §Gap assertion is contradicted by existing surfaces that basic peer-enumeration would have discovered) cap the γ axis at **B** regardless of whether β caught and corrected the false claim. A cycle requiring fix-rounds to reconcile γ's unverified gap framing reflects failure of the peer-enumeration discipline per `gamma\u002FSKILL.md` §2.2a, not implementation or review failure.\n\n  - ❌ Every release is A+ (grade inflation, no signal)\n  - ❌ Score the intent rather than what shipped\n  - ❌ Round up because \"the team worked hard\"\n  - ❌ Rate a §5.2 cycle's γ axis above A− (grade inflation, structural absence of γ\u002Fδ separation unaccounted)\n  - ✅ \"β: A- — DUR skills synced but README.md still references old framing\"\n  - ✅ \"γ: C — partial-protocol release; retroactive close-out planned\"\n  - ✅ \"γ: A− — §5.2 cycle; γ\u002Fδ separation absent; A− γ floor applied per §3.8 configuration-floor clause\"\n\n---\n\n## 4. Kata\n\n**Scenario:** A bugfix is ready on main. Execute the release.\n\n1. Readiness check — CI green, no unmerged branches\n2. Version decision — patch, minor, or major\n3. VERSION bump + stamp-versions.sh + check-version-consistency.sh\n4. CHANGELOG ledger row with honest TSC grades\n5. RELEASE.md with Outcome mirroring the ledger row\n6. Commit, tag (bare version), push\n7. Wait for release CI, deploy, validate with the specific fix\n8. β close-out (γ writes PRA separately)\n\n**Verify:** Does `scripts\u002Fcheck-version-consistency.sh` pass? Does RELEASE.md start with the coherence delta? Does validation confirm the targeted incoherence is closed?\n","# Release\n\n## Core Principle\n\n**Coherent release: every version bump is a measured coherence delta with a complete audit trail.**\n\nβ owns: review approval outcome, `git merge` into main, and β close-out. **δ owns tag\u002Frelease\u002Fdeploy** (the release boundary — `scripts\u002Frelease.sh`, binary publication, deployment). γ owns `RELEASE.md` authoring, cycle-directory movement, and the post-release assessment. β does not tag, push tags, bump versions for release, or cut the disconnect release. See `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Development lifecycle\" → §\"Step table\" (Step 8 β review\u002Fmerge; Steps 9–13 γ-and-δ release sequence), `operator\u002FSKILL.md` §3.4 (doctrinal frame), and `release-effector\u002FSKILL.md` (mechanics).\n\nCanonical artifact locations (β close-out path, RELEASE.md, snapshot dirs, tag policy) are defined in `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Artifact contract\" → §\"Location matrix\". All tags are bare `X.Y.Z`; `v`-prefixed tags are legacy and warn-only.\n\nA release has parts: readiness check, version decision, changelog, release notes, tag, binaries, deployment, validation. Coherence = each part completed and each artifact matches the others (version in code = tag = changelog = binary = deployed agent). The released system is validated, not merely published.\n\nFailure mode: version drift — tag says X, binary says Y, agent reports Z. Or: releasing without validation, so breakage ships silently. Or: incomplete deploy where artifacts ship but assessment never lands.\n\n## 1. Define\n\n1.1. **Identify the parts**\n  - Readiness: CI green, branches merged or returned, main clean\n  - Version: semver bump decided from commit content\n  - Artifacts: cn.json, VERSION, package manifests, CHANGELOG, RELEASE.md, tag, GitHub release, binaries\n  - Deployment: binary on target hosts, `cn deps restore`, validation\n  - ❌ Push tag, hope it works\n  - ✅ Every artifact checked, deployed, validated end-to-end\n\n1.2. **Articulate how they fit**\n  - Version flows: VERSION → `stamp-versions.sh` → cn.json + package manifests → CHANGELOG → commit → tag → CI → binaries → deploy → validate\n  - Each step depends on the prior; skip one and the chain breaks\n  - ❌ Tag pushed before version bumped in code (binary reports old version)\n  - ✅ Version string updated everywhere before commit, tag matches code\n\n1.3. **Name the failure mode**\n  - Version drift: any two artifacts disagree on the version\n  - Silent breakage: release ships but CI failed or validation skipped\n  - Incomplete deploy: binary updated but packages stale (`cn deps restore` not run)\n  - ❌ \"cn update worked\" (but agent still reports old version)\n  - ✅ `cn --version` matches tag, `cn deps restore` run, agent can execute ops\n\n## 2. Unfold\n\n2.1. **Readiness check**\n  - CI passing on main (unit tests + integration tests + kata suite)\n  - No unmerged branches that should be in this release\n  - `git branch -r --no-merged origin\u002Fmain` — review each, merge or defer\n  - **Non-destructive merge-test on the merge tree before merge.** Build the merge tree in a throwaway worktree (`git worktree add \u002Ftmp\u002Fcnos-merge-test\u002Fwt origin\u002Fmain && cd \u002Ftmp\u002Fcnos-merge-test\u002Fwt && git merge --no-ff --no-commit origin\u002Fcycle\u002F{N}`); run any contract validators the cycle ships (e.g. `.\u002Ftools\u002Fvalidate-skill-frontmatter.sh` if the cycle adds or modifies SKILL.md frontmatter; `cn-cdd-verify` for `.cdd\u002F` artifacts; `scripts\u002Fcheck-version-consistency.sh` for version stamping); confirm zero unmerged paths and zero new validator findings. Tear down the worktree. **Set any worktree-local git config with the explicit `--worktree` flag** (`git config --worktree user.name X`) to avoid leaking identity to the shared repo `.git\u002Fconfig` (cycle #301 O8). This pattern is also referenced from `beta\u002FSKILL.md` § pre-merge gate row 3 — it is the same step, named here so the release-flow doc is authoritative.\n  - ❌ Release with failing CI (\"it's just a flaky test\")\n  - ❌ Merge without running the cycle's own validators on the merge tree (\"the cycle branch passes; the merge tree will too\")\n  - ✅ CI green, or known failure documented and accepted (e.g. Coherence workflow on #22)\n  - ✅ Merge-tree validation green (especially when the cycle ships a new contract surface like #301's I5 frontmatter validator)\n\n2.2. **Version decision**\n  - Review commits since last tag: `git log --oneline $(git describe --tags --abbrev=0)..HEAD`\n  - Major: breaking changes, paradigm shift\n  - Minor: new features, backwards compatible (new ops, new skills, new specs)\n  - Patch: bug fixes only\n  - ❌ Patch for a new runtime feature (undersells the change)\n  - ✅ Minor for new `Cn_shell.execute` entry point; patch for CI fix\n\n2.3. **Version bump — VERSION-first flow**\n  - `VERSION` file at repo root is the single source of truth\n  - Edit `VERSION` to the new version string (bare, no `v` prefix)\n  - Run `scripts\u002Fstamp-versions.sh` — derives all manifests (`cn.json`, package `cn.package.json` files) from VERSION\n  - Run `scripts\u002Fcheck-version-consistency.sh` — validates all version-stamped files agree\n  - Binary embeds version from VERSION at build time — no manual edit needed\n  - Tests and katas read version dynamically — no manual edit needed\n  - ❌ Edit cn.json or package manifests by hand (bypasses single source of truth)\n  - ❌ Skip stamp-versions.sh (\"I'll update the manifests manually\")\n  - ✅ `echo \"X.Y.Z\" > VERSION && scripts\u002Fstamp-versions.sh && scripts\u002Fcheck-version-consistency.sh`\n\n2.4. **CHANGELOG**\n  - Add a ledger row matching the format defined in `CHANGELOG.md` § Release Coherence Ledger. That format is canonical — do not reinvent the row shape here.\n  - The ledger row includes: Version, C_Σ, α, β, γ, Level, Rounds, and a coherence note. The **Rounds** column records the review-round count for the release's cycle (e.g. `1`, `2`, `3`); for releases bundling multiple cycles, sum or list (`1+2`). This is a learning-curve indicator — a rising trend signals process drift, a falling trend signals accumulated context.\n  - **Provisional vs. final scoring rule:** β writes the CHANGELOG TSC row at release commit with `provisional, pending γ PRA` in the level cell (or in a parenthetical next to the level). γ updates the cell to the final value in the same commit as the PRA. This ensures one writer per fact while preserving the release-time ledger entry.\n  - Add a detailed section below the ledger: Added \u002F Changed \u002F Fixed, with each commit's impact named and linked to issues.\n  - ❌ \"Various improvements\" (no detail)\n  - ❌ Ledger row without engineering level (Level column is required)\n  - ✅ Each commit's impact named, linked to issues\n  - ✅ Honest TSC grades — not everything is A+\n  - `RELEASE.md` must restate the ledger row as the Outcome section in prose. The ledger row remains canonical; the release body explains it.\n  - If release notes or CHANGELOG wording are being authored, load the write skill and record it in the CDD Trace.\n\n2.5. **Release notes — RELEASE.md**\n  - Write `RELEASE.md` at repo root before tagging. This is the GitHub release body.\n  - A release is a measured coherence delta. The release body must foreground what got more coherent and why, then detail the changes.\n  - The release CI workflow uses `RELEASE.md` as the release body if present; otherwise it auto-generates from commit titles (sparse and unstructured — not acceptable).\n  - `RELEASE.md` is committed in the release commit and consumed by CI. It stays in the repo until the next release overwrites it.\n  - ❌ Let CI auto-generate release notes (just commit titles, no detail)\n  - ❌ Jump straight into Fixed\u002FAdded\u002FChanged (change-loggy, not coherence-framed)\n  - ❌ Manually create the GitHub release after CI (race condition with workflow)\n  - ✅ Outcome first, then changes, then proof\n  - ✅ Write `RELEASE.md` → commit in release commit → CI uses it as release body\n\n  ```markdown\n  # RELEASE.md format\n\n  ## Outcome\n\n  Coherence delta: C_Σ {grade} (`α {grade}`, `β {grade}`, `γ {grade}`) · **Level:** `L{level}`\n\n  One short paragraph:\n  - what became more coherent\n  - what surface is now more truthful \u002F portable \u002F durable \u002F explicit\n\n  ## Why it matters\n\n  One short paragraph:\n  - what incoherence this cycle targeted\n  - why it mattered operationally or structurally\n  - what changed in the system's behavior or authority model\n\n  ## Fixed\n\n  - **Short description** (#issue): what changed and why it matters.\n\n  ## Added\n\n  - **Short description** (#issue): what was added and what new capability or clarity it provides.\n\n  ## Changed\n\n  - **Short description** (#issue): what changed in behavior, authority, or shape.\n\n  ## Removed\n\n  - **Short description** (#issue): what was removed and what incoherence it eliminated.\n\n  ## Validation\n\n  - Deployed to [target], validated [specific check].\n  - State what was proven coherent by the validation, not only that deployment succeeded.\n\n  ## Known Issues\n\n  - #N — description (if any found during validation)\n  ```\n\n2.5a. **Move cycle directories to release directory** (tagged release)\n  - Move every per-cycle directory from `.cdd\u002Funreleased\u002F{N}\u002F` to `.cdd\u002Freleases\u002F{X.Y.Z}\u002F{N}\u002F`:\n    ```bash\n    mkdir -p .cdd\u002Freleases\u002FX.Y.Z\n    for dir in .cdd\u002Funreleased\u002F*\u002F; do\n      [ -d \"$dir\" ] || continue\n      mv \"$dir\" .cdd\u002Freleases\u002FX.Y.Z\u002F\n    done\n    ```\n  - Each `.cdd\u002Freleases\u002F{X.Y.Z}\u002F{N}\u002F` directory carries the same role-prefixed files that lived in `.cdd\u002Funreleased\u002F{N}\u002F` during the cycle (`self-coherence.md`, `beta-review.md`, `alpha-closeout.md`, `beta-closeout.md`, `gamma-closeout.md`, plus any cycle-specific extras) per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Coordination surfaces\" + §\"Artifact contract\" → §\"Location matrix\".\n  - Include the moves in the release commit\n  - `.cdd\u002Funreleased\u002F` should be empty after the release commit\n  - ❌ Leave cycle directories in `unreleased\u002F` after tagging (lose the version association)\n  - ❌ Move after the release commit (they should be part of the release snapshot)\n  - ✅ Move before commit, include in the release commit\n\n2.5b. **Docs-only disconnect (no tag)**\n\n  A cycle that ships only documentation, protocol artifacts, or assessments — with no code change and no version bump — still requires a disconnect, but the disconnect is the merge commit on main, not a tag.\n\n  Cases this covers:\n\n  - Retroactive close-out for a previously-released version (no new code, only frozen artifacts and CHANGELOG row backfill — the cycle for `usurobor\u002Ftsc#27` is the canonical example)\n  - Self-coherence reports and post-release assessments produced as their own cycle, not bundled with a code release\n  - Skill patches that ship only as protocol changes\n  - Doc-cleanup cycles (e.g. retiring stale references after a paradigm shift)\n\n  For docs-only cycles:\n\n  - `.cdd\u002Funreleased\u002F{N}\u002F` moves to `.cdd\u002Freleases\u002Fdocs\u002F{ISO-date}\u002F{N}\u002F` where `{ISO-date}` is the merge commit's date in `YYYY-MM-DD` form (e.g. `.cdd\u002Freleases\u002Fdocs\u002F2026-05-08\u002F27\u002F`).\n  - **No CHANGELOG ledger row.** The Release Coherence Ledger tracks tagged releases. γ records the cycle in `docs\u002Fgamma\u002Fcdd\u002Fdocs\u002F{ISO-date}\u002FPOST-RELEASE-ASSESSMENT.md` instead — same PRA structure as a tagged release, just keyed by date.\n  - The merge commit hash IS the disconnect signal. No `scripts\u002Frelease.sh` invocation. No version bump. VERSION is unchanged.\n  - `scripts\u002Fcheck-version-consistency.sh` is not required to run (nothing version-stamped changed).\n\n  ```bash\n  # Docs-only disconnect at merge time (run as part of γ closure):\n  ISO_DATE=\"$(date -u +%Y-%m-%d)\"\n  mkdir -p \".cdd\u002Freleases\u002Fdocs\u002F${ISO_DATE}\"\n  for dir in .cdd\u002Funreleased\u002F*\u002F; do\n    [ -d \"$dir\" ] || continue\n    mv \"$dir\" \".cdd\u002Freleases\u002Fdocs\u002F${ISO_DATE}\u002F\"\n  done\n  ```\n\n  - ❌ Leave docs-only cycle directories in `.cdd\u002Funreleased\u002F{N}\u002F` after merge (\"there's no release to move them to\")\n  - ❌ Force a synthetic version bump on a docs-only cycle just to fit the tagged-release flow\n  - ❌ Skip the PRA because no tag was pushed\n  - ✅ Move to `.cdd\u002Freleases\u002Fdocs\u002F{ISO-date}\u002F{N}\u002F` in the merge commit\n  - ✅ γ writes `docs\u002Fgamma\u002Fcdd\u002Fdocs\u002F{ISO-date}\u002FPOST-RELEASE-ASSESSMENT.md`\n\n  γ declares `docs-only` in the issue mode header (per `issue\u002FSKILL.md` §Mode declaration); the disconnect path is selected at issue-creation time, not retrofitted at merge.\n\n2.6. **Commit and signal readiness for δ tag**\n  - **Tag naming convention:** use bare version numbers without `v` prefix: `3.15.1`, not `v3.15.1`. This matches VERSION file content, branch naming (`claude\u002F3.15.0-22-...`), and snapshot directory names (`docs\u002Fgamma\u002Fcdd\u002F3.15.0\u002F`). Consistency across all version surfaces.\n  - **Tag message generation:** δ creates annotated tags (not lightweight tags) with structured messages that include issue metadata, wave context when present, and CDD review artifacts when available. The tag message is automatically generated by `scripts\u002Fgenerate-release-tag-message.sh` and includes issue titles, labels, review rounds, and deterministic fallback when metadata is unavailable.\n  - Commit: `git commit -m \"release: X.Y.Z — summary\"` (includes VERSION, manifests, CHANGELOG, RELEASE.md)\n  - **Before any push that follows a rebase, run the eng\u002Fship rebase-integrity gate** (see `eng\u002Fship` § Rebase-Collision Integrity)\n  - Push: `git push origin main`\n  - **β signals \"release ready for δ tag\"** in `beta-closeout.md` — β does not execute `git tag` or push tags; δ creates the single annotated tag `X.Y.Z` with generated message as part of the disconnect release flow (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Development lifecycle\" → §\"Step table\" Step 10 — δ release). RELEASE.md remains the GitHub release body authority; generated tag messages are additive.\n  - ❌ β pushes tag directly (conflicts with δ tag authority)\n  - ❌ Mix `v` prefix and bare versions across tags (`v3.14.6` then `3.14.7`)\n  - ❌ Commit without RELEASE.md (CI auto-generates sparse notes)\n  - ✅ Commit (with RELEASE.md), push, signal readiness in close-out; δ handles tagging\n\n2.6a. **Delete merged branches**\n  - After push, delete remote branches that were merged into this release\n  - `git branch -r --merged origin\u002Fmain | grep -v main | grep -v HEAD | sed 's\u002Forigin\\\u002F\u002F\u002F' | xargs -I{} git push origin --delete {}`\n  - This is mechanical cleanup, not judgment — if it's merged, it's dead\n  - ❌ Leave merged branches accumulating (\"someone might need them\")\n  - ✅ Clean up immediately after release push; history is in main\n\n2.7. **Wait for release CI**\n  - Release workflow builds binaries (linux-x64, macos-x64, macos-arm64)\n  - Wait for completion before deploying\n  - **δ owns release CI polling** per `release-effector\u002FSKILL.md` §3 — after tag push, δ monitors release workflow completion via `gh run list --branch \u003Ctag>`. β waits for δ confirmation.\n  - ❌ Deploy while CI still running (stale binary from previous release)\n  - ✅ `gh run watch {id} --exit-status` then verify assets attached\n\n2.8. **Deploy to target hosts**\n  - Stop daemon, download binary, replace, start daemon\n  - `cn deps restore` to sync cognitive substrate\n  - Validate: `cn --version`, test an op that exercises the fix\n  - ❌ Replace binary while daemon running (`Text file busy`)\n  - ✅ `systemctl stop → cp → chmod → systemctl start → cn --version`\n\n2.9. **Validate**\n  - Version matches everywhere: binary, cn.json, tag\n  - The specific fix or feature works end-to-end\n  - Check telemetry for errors on first cycle\n  - Validation must confirm the targeted coherence delta, not only binary\u002Fversion correctness.\n  - ❌ \"It deployed\" (no functional validation)\n  - ✅ Trace telemetry, confirm receipts\u002Fartifacts exist, agent responds correctly\n\n2.10. **CDD Trace update**\n  - Update the primary branch artifact's CDD Trace with the release row:\n    - artifact: tag \u002F CHANGELOG \u002F release artifact\n    - skills loaded: release, plus write if used\n    - decision: released version X.Y.Z\n  - If the triadic protocol is active, β also writes:\n    - release evidence in `.cdd\u002Funreleased\u002F{N}\u002Fbeta-closeout.md`\n    - β close-out narrative in `.cdd\u002Funreleased\u002F{N}\u002Fbeta-closeout.md` for γ to read (separate from `beta-review.md`, which carries the round-by-round verdicts; see `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Coordination surfaces\" → §\"Cycle-state evidence\")\n  - γ writes the post-release assessment after β's release and close-out are complete\n  - For triadic cycles, the primary branch artifact is `.cdd\u002Funreleased\u002F{N}\u002Fself-coherence.md` — it carries the trace through step 7a; β records the review verdict in `.cdd\u002Funreleased\u002F{N}\u002Fbeta-review.md` (steps 8–9) and the close-out + release evidence in `.cdd\u002Funreleased\u002F{N}\u002Fbeta-closeout.md` (step 10).\n\n## 3. Rules\n\n3.1. **All version strings must agree**\n  - VERSION, cn.json, package manifests, tag, binary output, CHANGELOG\n  - `scripts\u002Fcheck-version-consistency.sh` validates this mechanically\n  - ❌ Tag is 3.15.1 but VERSION says 3.15.2 (forgot to commit before tagging)\n  - ✅ `scripts\u002Fcheck-version-consistency.sh` passes before commit\n\n3.2. **CI must pass before tag**\n  - If CI fails after tag, fix and force-push tag (amend release commit)\n  - ❌ Ship with known test failure (\"we'll fix it next patch\")\n  - ✅ Fix the test, amend, force-push tag, wait for green\n\n3.3. **Never deploy stale binaries**\n  - Release CI builds from the tag; wait for it to complete\n  - Clear cached downloads (`--clobber` or `rm` old artifacts)\n  - ❌ `cn update` downloads cached v3.5.1 binary from \u002Ftmp\n  - ✅ Fresh download after CI completes, verify binary version after install\n\n3.4. **Deploy includes deps restore**\n  - Binary update alone leaves cognitive substrate stale\n  - `cn deps restore` syncs doctrine, mindsets, skills from packages\n  - ❌ Binary is v3.9.1 but skills are from v3.8.0 (package drift)\n  - ✅ `cn deps restore` immediately after binary update\n\n3.5. **Validate with the specific fix**\n  - Don't just check version — exercise the feature or fix\n  - ❌ \"Version looks right, ship it\"\n  - ✅ For #46: send a message, check telemetry for receipts, confirm artifacts exist\n\n3.6. **If CI fails post-tag, amend don't re-tag**\n  - `git commit --amend --no-edit && git tag -d X.Y.Z && git tag X.Y.Z && git push --force origin main X.Y.Z`\n  - Tags are **bare** (`X.Y.Z`, never `vX.Y.Z`) — see §2.6 and `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Artifact contract\" → §\"Location matrix\"\n  - Keeps a clean single tag, single release commit\n  - ❌ `git tag -d vX.Y.Z && git tag -a vX.Y.Z && git push --force --tags` (mixes legacy v-prefix; force-pushes all tags)\n  - ❌ `3.9.1`, `3.9.1-fix`, `3.9.1-fix2` (proliferating tags)\n  - ✅ One bare tag, amended until CI green\n\n3.7. **RELEASE.md must exist before tag**\n  - The release commit must include `RELEASE.md` at repo root\n  - If `RELEASE.md` is missing, the tag must not be pushed (CI will auto-generate sparse notes)\n  - ❌ Tag without RELEASE.md (\"I'll update the release body manually later\")\n  - ✅ Write RELEASE.md → include in release commit → tag → push\n\n3.8. **TSC scoring in CHANGELOG — honest-grading rubric**\n\n  Rate α (pattern), β (relation), γ (process) for each release. Honest grades — not everything is A+. The rubric below makes the grading reproducible across releases and reviewers.\n\n  **Per-axis rubric:**\n\n  | Grade | Numeric | Meaning |\n  |---|---|---|\n  | **A**   | 4.0 | met all ACs, no protocol skips, zero binding findings of the wiring or honest-claim class |\n  | **A-**  | 3.7 | met all ACs, ≤1 binding finding, all findings non-blocking |\n  | **B+**  | 3.3 | met all ACs, ≥2 binding findings or one round of RC |\n  | **B**   | 3.0 | met core ACs; partial-protocol release (e.g. missing RELEASE.md at tag time) **or** 2+ rounds of RC |\n  | **C+**  | 2.3 | shipped but missing one of: ledger row, PRA, provenance attachment |\n  | **C**   | 2.0 | partial-protocol release with multiple drift items |\n  | **\u003C C** | \u003C 2 | re-open and remediate; do not close |\n\n  **Closure-gate override (fires before geometric-mean computation).** If any artifact required by `gamma\u002FSKILL.md` §2.10 closure gate (per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Artifact contract\" → §\"Ownership matrix\") is absent from the cycle's `.cdd\u002Funreleased\u002F{N}\u002F` directory at merge time — specifically any of `alpha-closeout.md`, `beta-closeout.md`, or `gamma-closeout.md` for a triadic cycle — then `C_Σ` is forced to `\u003CC` regardless of per-axis math. Cycle disposition is \"open and remediate\"; the geometric mean is not computed. This override is verified mechanically by `scripts\u002Fvalidate-release-gate.sh --mode pre-merge` (see AC1, issue #339). The math below applies only after the closure gate passes.\n\n  **Letter normalization (`\u003CC` and `C−`).** The rubric table uses `\u003CC` as the grade label. Prior CHANGELOG, PRA, and alpha-closeout artifacts for cycles #331, #333, and #334 used `C−` for the same disposition. These are the same grade: `C−` is the operator-visible projection of `\u003CC`. Both mean \"open and remediate; do not close.\" Authors may use either form; the CHANGELOG column uses `\u003CC` for rubric fidelity and `C−` is accepted as equivalent in prose artifacts.\n\n  **C_Σ** is the geometric mean of the three numeric grades; report the closest letter grade (e.g. (3.7 · 3.3 · 4.0)^(1\u002F3) ≈ 3.66 ⟹ A-).\n\n  **Score the release, not the intent.** A retroactive partial-protocol close-out earns C+ honestly (e.g. `usurobor\u002Ftsc` cycle 27: v0.4.0 retroactive close-out scored α B \u002F β C+ \u002F γ C \u002F C_Σ C+ — the grade reflects what shipped, not the goodwill of fixing it later).\n\n  **Configuration-floor clause.** Cycles run under `operator\u002FSKILL.md §5.2` (single-session δ-as-γ via Agent tool) cap the γ axis at **A−** regardless of execution quality, because γ\u002Fδ separation is structurally absent. The A− γ floor applies from the cycle's merge forward; it is not retroactive. The configuration must be recorded explicitly in `gamma-closeout.md` (see AC6 of any cycle introducing or running under §5.2). Applying the A− cap is operator-honest discipline: if `gamma-closeout.md` does not declare §5.2, the rubric treats the cycle as §5.1 and the cap does not apply.\n\n  **CI-red cap clause.** Cycles with red CI on the merge commit cap the γ axis at **C** (one band below current floor). Cycles that proceed to close-out without verifying CI cap the γ axis at **B−**. CI is a mechanical gate; failing or skipping it reflects structural γ-axis failure in cycle coordination, not judgment calls.\n\n  **False-gap peer-enumeration clause.** Cycles that ship on a false-gap premise (where the §Gap assertion is contradicted by existing surfaces that basic peer-enumeration would have discovered) cap the γ axis at **B** regardless of whether β caught and corrected the false claim. A cycle requiring fix-rounds to reconcile γ's unverified gap framing reflects failure of the peer-enumeration discipline per `gamma\u002FSKILL.md` §2.2a, not implementation or review failure.\n\n  - ❌ Every release is A+ (grade inflation, no signal)\n  - ❌ Score the intent rather than what shipped\n  - ❌ Round up because \"the team worked hard\"\n  - ❌ Rate a §5.2 cycle's γ axis above A− (grade inflation, structural absence of γ\u002Fδ separation unaccounted)\n  - ✅ \"β: A- — DUR skills synced but README.md still references old framing\"\n  - ✅ \"γ: C — partial-protocol release; retroactive close-out planned\"\n  - ✅ \"γ: A− — §5.2 cycle; γ\u002Fδ separation absent; A− γ floor applied per §3.8 configuration-floor clause\"\n\n---\n\n## 4. Kata\n\n**Scenario:** A bugfix is ready on main. Execute the release.\n\n1. Readiness check — CI green, no unmerged branches\n2. Version decision — patch, minor, or major\n3. VERSION bump + stamp-versions.sh + check-version-consistency.sh\n4. CHANGELOG ledger row with honest TSC grades\n5. RELEASE.md with Outcome mirroring the ledger row\n6. Commit, tag (bare version), push\n7. Wait for release CI, deploy, validate with the specific fix\n8. β close-out (γ writes PRA separately)\n\n**Verify:** Does `scripts\u002Fcheck-version-consistency.sh` pass? Does RELEASE.md start with the coherence delta? Does validation confirm the targeted incoherence is closed?\n",{"name":5,"calls":43,"scope":44,"inputs":45,"parent":21,"outputs":49,"requires":52,"triggers":54,"visibility":56,"description":7,"kata_surface":22,"artifact_class":57,"governing_question":58},[],"task-local",[46,47,48],"approved branch","version decision","release context",[50,51],"release artifact set","beta close-out",[53],"approval and release readiness",[5,19,55,23,29,32],"tag","internal","skill","How does β turn a converged branch into a released version with a complete and auditable coherence delta?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Frelease",0,"https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos","https:\u002F\u002Fgithub.com\u002Fusurobor","Coherence engineer. Building git-CN.","2026-11-07 14:25:44",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add usurobor\u002Fcnos --skill release",{"tool":73,"command":74},"bunx","bunx skills add usurobor\u002Fcnos --skill release",{"tool":76,"command":77},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill release","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Frelease\u002FSKILL.md",true,[81,87,91,95,99,103,107,111,115],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"agents\u002Fbundle-validator.md","REFERENCE","参考文档",7146,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fset-display-case\u002Fagents\u002Fbundle-validator.md",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"agents\u002Fcompliance-pre-check.md",11191,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fset-display-case\u002Fagents\u002Fcompliance-pre-check.md",{"path":92,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":93,"sourceHtmlUrl":94},"agents\u002Flibrary-route-scaffolder.md",37925,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fset-display-case\u002Fagents\u002Flibrary-route-scaffolder.md",{"path":96,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":97,"sourceHtmlUrl":98},"agents\u002Ftoken-expander.md",10312,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fset-display-case\u002Fagents\u002Ftoken-expander.md",{"path":100,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fclaude-md-rules-block.md",8710,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fset-display-case\u002Freferences\u002Fclaude-md-rules-block.md",{"path":104,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fdesign-system-md-template.md",13758,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fset-display-case\u002Freferences\u002Fdesign-system-md-template.md",{"path":108,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Fglobals-css-template.md",7617,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fset-display-case\u002Freferences\u002Fglobals-css-template.md",{"path":112,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":113,"sourceHtmlUrl":114},"references\u002Ftailwind-config-template.md",8889,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fset-display-case\u002Freferences\u002Ftailwind-config-template.md",{"path":116,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":117,"sourceHtmlUrl":118},"references\u002Ftoken-checklist.md",8957,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fset-display-case\u002Freferences\u002Ftoken-checklist.md",[120,136,152,180,196,215],{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":38},"01M6CF8RWQPM0VXZG06XMR0FFX","issues\u002Ftriage","Issue triage doctrine pointer. Use when classifying a new issue, deciding dispatch eligibility, or deciding whether to close\u002Fsupersede\u002Fdefer.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Ftriage\u002FSKILL.md",[],[127,128,129,130,30,28,27,131,132,133,134,135],"triage","issues","issues triage","issue triage","public","use","dispatch","issue","doctrine",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"publishedAt":38},"01M6CF8PJ812DD4APZ3WE8X67B","issues\u002Ftaxonomy","Issue label taxonomy pointer. Use when classifying an issue's kind\u002Farea\u002Fpriority\u002Feffort\u002Fstatus\u002Fprotocol\u002Fdispatch labels, or when the board needs to interpret them.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Ftaxonomy\u002FSKILL.md",[],[128,143,144,145,146,147,30,148,131,149,132,133,150,134,151],"taxonomy","issues taxonomy","github","status","protocol","open","board","github issue","issue labels",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":168,"publishedAt":38},"01M6CF8KBMZ4D0CDJQ3PF1YVTP","issues\u002Fmap","Issue-board (Issue Pivot) generation domain. Use when reasoning about `cn issues map`'s fetch, taxonomy-parse, effort-computation, and render pipeline, or about the board's JSON\u002FHTML output contract.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Fmap\u002FSKILL.md",[158,163],{"categoryNo":159,"categoryName":160,"taxonomyType":161,"taxonomyTypeDesc":162},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":164,"categoryName":165,"taxonomyType":166,"taxonomyTypeDesc":167},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[128,169,145,170,171,172,30,173,143,148,28,174,175,149,176,177,178,179,132,134],"issues map","reasoning","data","pipeline","api","json","README","edit","interactive","fetch","generated",{"skillNo":181,"name":128,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":38},"01M6CF8CZQH7G7B7RZPANQWR4G","cnos.issues package entrypoint. Use when reasoning about issue taxonomy, the Issue Pivot \u002F issue-board (`cn issues map`), the read-only CDS issue-state evaluator (`cn issues fsm evaluate`), or the current command-dispatch disposition of issue tooling.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002FSKILL.md",[],[128,145,186,187,188,189,190,191,192,143,148,28,27,26,175,193,132,194,133,195],"pr","current state","run","artifacts","state","package","boundary","command","only","cds",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":202,"publishedAt":38},"01M6CF896XKSRQVB1CSHY8GSXB","receipt-stream","Cross-cycle receipt-stream doctrine for protocol-iteration. Use when γ closes a cycle and writes the per-cycle iteration artifact (`cdd-iteration.md`), when γ updates the cross-cycle aggregator at `.cdd\u002Fiterations\u002FINDEX.md`, when ε reads the receipt stream across cycles to surface protocol-gap patterns, when a finding's disposition lands a cross-repo patch and the cross-repo trace bundle attaches, or when a courtesy empty-findings stub is written for a `protocol_gap_count == 0` cycle.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Freceipt-stream\u002FSKILL.md",[],[203,204,189,147,205,28,206,207,208,131,209,210,211,212,132,22,213,214,21,135],"receipt stream","handoff","index","learning","format","trace","repo","closeout","read","channel","patch","shape",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":221,"publishedAt":38},"01M6CF84VCBME6RK8V6HAVDM8Z","mid-flight","Mid-flight γ→in-flight-α rescue channel. Use when γ needs to change a load-bearing fact (pinned axis, scope, AC, blocker) after α has begun coding, when γ edits the cycle's GitHub issue body mid-cycle, or when a spec change lands on origin\u002Fmain while α\u002Fβ polling sessions are in-flight.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Fmid-flight\u002FSKILL.md",[],[222,145,223,224,225,226,28,227,228,26,209,211,132,194,133,229,150,230,231,232],"mid flight","change","sessions","file","cache","pin","coordination","up","Legacy","gamma","artifact channel"]