@oevery/rsp 3.1.0-beta.0 → 3.1.0-beta.1

package/README.md

@@ -34,17 +34,17 @@ RSP derives the next action from the selected Change, repository evidence, verif
 ## Quick start
 
 ```bash
-npx -y @oevery/rsp@3.1.0-beta.0 init
-npx -y @oevery/rsp@3.1.0-beta.0 doctor
+npx -y @oevery/rsp@3.1.0-beta.1 init
+npx -y @oevery/rsp@3.1.0-beta.1 doctor
 ```
 
 Recommended bootstrap flow:
 
 ```bash
-npx -y @oevery/rsp@3.1.0-beta.0 init --with-project-setup
+npx -y @oevery/rsp@3.1.0-beta.1 init --with-project-setup
 # fill .rsp/changes/project-setup.md
 # fill .rsp/specs/design.md
-npx -y @oevery/rsp@3.1.0-beta.0 doctor
+npx -y @oevery/rsp@3.1.0-beta.1 doctor
 ```
 
 ## Artifact foundation
@@ -205,7 +205,7 @@ Surface matrix:
 
 Humans should usually start with `README.md`; agents should follow nearest `AGENTS.md`, load the `rsp` skill when available, and use `.rsp/rsp-rules.md` only as fallback.
 
-When this README shows `rsp <command>`, it assumes the command is already available in your environment. For this opt-in beta, otherwise use the exact `npx -y @oevery/rsp@3.1.0-beta.0 <command>` identity after publication; stable users can keep using the unversioned package entrypoint for npm `latest`.
+When this README shows `rsp <command>`, it assumes the command is already available in your environment. For opt-in beta evaluation, pin the exact prerelease identity, such as `npx -y @oevery/rsp@3.1.0-beta.1 <command>`; stable users can keep using the unversioned package entrypoint for npm `latest`.
 
 Install the exact package-bundled suite into the current project:
 
@@ -214,14 +214,14 @@ rsp skills install --dry-run
 rsp skills install
 ```
 
-The command preflights all ten package-owned targets, leaves unrelated `.agents/skills` entries untouched, and requires explicit `--force` before replacing a divergent package-owned directory. It installs from the package that invoked `rsp`, so prerelease dogfooding can use one exact npm identity after publication:
+The command preflights all ten package-owned targets, leaves unrelated `.agents/skills` entries untouched, and requires explicit `--force` before replacing a divergent package-owned directory. It installs from the package that invoked `rsp`, so prerelease dogfooding can pin one exact npm identity:
 
 ```bash
-npx -y @oevery/rsp@3.1.0-beta.0 skills install --dry-run
-npx -y @oevery/rsp@3.1.0-beta.0 skills install
+npx -y @oevery/rsp@3.1.0-beta.1 skills install --dry-run
+npx -y @oevery/rsp@3.1.0-beta.1 skills install
 ```
 
-These registry commands remain unavailable until `3.1.0-beta.0` is published. `rsp update` refreshes RSP-managed project files only; run `rsp skills install` separately to refresh the package-owned Skill suite.
+Exact prerelease identities avoid depending on a moving dist-tag. `rsp update` refreshes RSP-managed project files only; run `rsp skills install` separately to refresh the package-owned Skill suite.
 
 ## Migrating from 2.x
 
@@ -272,8 +272,8 @@ Durable review makes two independent semantic choices: whether current facts or
 
 New project:
 
-1. `npx -y @oevery/rsp@3.1.0-beta.0 init`
-2. Prefer `npx -y @oevery/rsp@3.1.0-beta.0 init --with-project-setup`, or run `rsp create project-setup` manually
+1. `npx -y @oevery/rsp@3.1.0-beta.1 init`
+2. Prefer `npx -y @oevery/rsp@3.1.0-beta.1 init --with-project-setup`, or run `rsp create project-setup` manually
 3. Fill `.rsp/specs/design.md`
 4. Use `rsp add spec <name>` only when a new durable project doc is needed
 5. Keep lasting rationale in the configured Decision Record directory and stable scoped operating instructions in the nearest project-owned `AGENTS.md`
@@ -286,14 +286,14 @@ New project:
 
 Existing project with a rich `AGENTS.md`:
 
-1. `npx -y @oevery/rsp@3.1.0-beta.0 init`
+1. `npx -y @oevery/rsp@3.1.0-beta.1 init`
 2. Keep the managed block thin
 3. Move durable design into `.rsp/specs/design.md`
 4. Use `rsp add spec <name>` only when another durable current-fact document is needed
 
 AI-assisted setup:
 
-1. `npx -y @oevery/rsp@3.1.0-beta.0 init --agents-mode print --with-project-setup`
+1. `npx -y @oevery/rsp@3.1.0-beta.1 init --agents-mode print --with-project-setup`
 2. Keep the managed block as generated and adapt only the surrounding human-owned content if needed
 3. Have the AI review and fill `.rsp/changes/project-setup.md`
 4. Have the AI fill `.rsp/specs/design.md`

package/README.zh-CN.md

@@ -34,17 +34,17 @@ RSP 根据 selected Change、仓库证据、验证结果和 blockers 推导下
 ## 快速开始
 
 ```bash
-npx -y @oevery/rsp@3.1.0-beta.0 init
-npx -y @oevery/rsp@3.1.0-beta.0 doctor
+npx -y @oevery/rsp@3.1.0-beta.1 init
+npx -y @oevery/rsp@3.1.0-beta.1 doctor
 ```
 
 推荐启动流程：
 
 ```bash
-npx -y @oevery/rsp@3.1.0-beta.0 init --with-project-setup
+npx -y @oevery/rsp@3.1.0-beta.1 init --with-project-setup
 # 填写 .rsp/changes/project-setup.md
 # 填写 .rsp/specs/design.md
-npx -y @oevery/rsp@3.1.0-beta.0 doctor
+npx -y @oevery/rsp@3.1.0-beta.1 doctor
 ```
 
 ## Artifact foundation
@@ -190,7 +190,7 @@ RSP 发布十个宿主无关、按需加载的 Skills：
 
 通常应由人先读 `README.md`；agent 应遵循 nearest `AGENTS.md`，可用时加载 `rsp` skill，仅在 skill 不可用时读取 `.rsp/rsp-rules.md`。
 
-如果文档中写的是 `rsp <command>`，默认前提是你的环境里已经能直接运行 `rsp`。对本次 opt-in beta，发布后应使用精确身份 `npx -y @oevery/rsp@3.1.0-beta.0 <command>`；stable 用户仍可使用不带版本的入口获取 npm `latest`。
+如果文档中写的是 `rsp <command>`，默认前提是你的环境里已经能直接运行 `rsp`。进行 opt-in beta 评估时，应固定精确 prerelease 身份，例如 `npx -y @oevery/rsp@3.1.0-beta.1 <command>`；stable 用户仍可使用不带版本的入口获取 npm `latest`。
 
 将当前精确包内置的完整 Skill 套件安装到当前项目：
 
@@ -199,14 +199,14 @@ rsp skills install --dry-run
 rsp skills install
 ```
 
-该命令会预检全部十个 package-owned targets，保留无关的 `.agents/skills` 条目，并且只有显式传入 `--force` 才会替换内容不同的 package-owned 目录。它从调用 `rsp` 的同一个包安装，因此 beta 发布后可以固定精确 npm 身份：
+该命令会预检全部十个 package-owned targets，保留无关的 `.agents/skills` 条目，并且只有显式传入 `--force` 才会替换内容不同的 package-owned 目录。它从调用 `rsp` 的同一个包安装，因此 beta 评估可以固定精确 npm 身份：
 
 ```bash
-npx -y @oevery/rsp@3.1.0-beta.0 skills install --dry-run
-npx -y @oevery/rsp@3.1.0-beta.0 skills install
+npx -y @oevery/rsp@3.1.0-beta.1 skills install --dry-run
+npx -y @oevery/rsp@3.1.0-beta.1 skills install
 ```
 
-在 `3.1.0-beta.0` 实际发布前，上述 registry 命令不可用。`rsp update` 只刷新由 RSP 管理的项目文件；刷新 package-owned Skill 套件需要单独运行 `rsp skills install`。
+精确 prerelease 身份可以避免依赖持续移动的 dist-tag。`rsp update` 只刷新由 RSP 管理的项目文件；刷新 package-owned Skill 套件需要单独运行 `rsp skills install`。
 
 ## 从 2.x 迁移
 
@@ -257,8 +257,8 @@ durable review 包含两个独立语义判断：是否更新当前事实或作
 
 新项目：
 
-1. `npx -y @oevery/rsp@3.1.0-beta.0 init`
-2. 优先使用 `npx -y @oevery/rsp@3.1.0-beta.0 init --with-project-setup`，或手动执行 `rsp create project-setup`
+1. `npx -y @oevery/rsp@3.1.0-beta.1 init`
+2. 优先使用 `npx -y @oevery/rsp@3.1.0-beta.1 init --with-project-setup`，或手动执行 `rsp create project-setup`
 3. 填写 `.rsp/specs/design.md`
 4. 仅在需要新的长期项目文档时使用 `rsp add spec <name>`
 5. 将长期理由写入配置的 Decision Record 目录，将稳定的作用域操作指令写入 nearest project-owned `AGENTS.md`
@@ -271,14 +271,14 @@ durable review 包含两个独立语义判断：是否更新当前事实或作
 
 已有复杂 `AGENTS.md` 的项目：
 
-1. `npx -y @oevery/rsp@3.1.0-beta.0 init`
+1. `npx -y @oevery/rsp@3.1.0-beta.1 init`
 2. 保持受管块尽量薄
 3. 将长期设计收敛到 `.rsp/specs/design.md`
 4. 只有需要额外的 durable current-fact 文档时才使用 `rsp add spec <name>`
 
 AI 协助接入：
 
-1. `npx -y @oevery/rsp@3.1.0-beta.0 init --agents-mode print --with-project-setup`
+1. `npx -y @oevery/rsp@3.1.0-beta.1 init --agents-mode print --with-project-setup`
 2. 保持受管块原样，只在需要时调整周围由人维护的内容
 3. 让 AI 审阅并填写 `.rsp/changes/project-setup.md`
 4. 让 AI 填写 `.rsp/specs/design.md`

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@oevery/rsp",
   "type": "module",
-  "version": "3.1.0-beta.0",
+  "version": "3.1.0-beta.1",
   "description": "RSP (Reliable Software Practice), a repository-native engineering workflow for humans and AI agents",
   "author": "oevery",
   "license": "MIT",
@@ -37,7 +37,8 @@
   },
   "scripts": {
     "prepare": "pnpm run build",
-    "release:check": "pnpm run build && pnpm run typecheck && pnpm run lint && pnpm run test && pnpm run release:package-check",
+    "release:check": "pnpm run release:metadata-check && pnpm run build && pnpm run typecheck && pnpm run lint && pnpm run test && pnpm run release:package-check",
+    "release:metadata-check": "node scripts/release-metadata-check.mjs",
     "release:package-check": "node scripts/clean-install-check.mjs",
     "prepublishOnly": "pnpm run release:check",
     "build": "tsup",

package/rules/rsp-rules.md

@@ -39,7 +39,7 @@ This file is the minimal fallback protocol for agents that cannot load the `rsp`
 - Persist only `open` and `archived`; readiness, blockers, verification, and next actions are derived.
 - Ordinary implementation is the default after unexplained failures have been ruled out. Use test-first work only when user, Change, or project authority requires it or a concrete changed risk makes a focused pre-mutation failure materially safer. Retain a new test only when it protects observable behavior or a real boundary, adds distinct future confidence, avoids duplicate or implementation-detail coverage, and has proportionate maintenance cost; otherwise remove the temporary probe and use the smallest decisive final verification.
 - Route one isolated domain, module/seam, or evidence-seeking design question to `rsp-design` when available, or use a compact manual design pass. Return evidence, alternatives, owner decisions, and any authorized planned-design update to the same selected Change; do not implement or write durable current truth from that pass.
-- Route release documentation only when the selected Change explicitly owns a confirmed release identity or range and still has unfinished changelog, release-note, or migration work. Select `rsp-release-docs` when available, or use the same evidence-led manual fallback; lifecycle stage, completed implementation, and archive readiness alone are insufficient. This route never grants commit, tag, push, release creation, publication, deployment, or approval authority.
+- Route release documentation only when a dedicated Release Change explicitly owns a confirmed release identity or range and still has unfinished changelog, release-note, or migration work. Identity is confirmed only by explicit user instruction or authoritative release configuration; never infer it from version order, prior prereleases, commits, or planned prose. Until confirmation, keep release planning version-neutral and leave manifests, target changelog headings, exact-version documentation, versioned release notes, and tag comparisons unchanged. Select `rsp-release-docs` when available, or use the same evidence-led manual fallback; lifecycle stage, completed implementation, and archive readiness alone are insufficient. This route never grants commit, tag, push, release creation, publication, deployment, or approval authority.
 - Do not infer current work from open Changes or filenames.
 - Prefer RSP commands for deterministic setup, status, validation, repair, focus, index, and archive operations.
 
@@ -49,7 +49,7 @@ This file is the minimal fallback protocol for agents that cannot load the `rsp`
 - Project-owned `CONTEXT.md` owns stable navigation or scoped current context, while project-owned `AGENTS.md` owns stable operating instructions. Preserve their conventions and never treat RSP as their owner.
 - Before archive, decide independently whether current facts need a Spec or scoped-instruction update and whether lasting rationale needs a Decision Record.
 - Before archive, compress the Change to its final outcome, current design, completed delivery tasks, final decisive verification, and unresolved risks. Keep RED/GREEN/REFACTOR cycles, temporary probes, command transcripts, and step-by-step review corrections in the response instead of the Change or Archive.
-- After required durable updates, Core recommends explicit archive before final Git delivery. Core does not execute archive or grant authority to stage, commit, push, or publish.
+- After required durable updates, Core recommends explicit archive before final Git delivery. Keep each completed Change independently reviewable; with explicit Git authority deliver it as one logical commit before a separate Release Change and dedicated release commit finalize versioned shipped surfaces. Core does not execute archive or grant authority to stage, commit, push, or publish.
 - Decision Records are for hard-to-reverse choices with real tradeoffs; they do not duplicate current facts.
 - Change Spec deltas are planning aids and are never promoted automatically into Specs or Decision Records.
 - Keep task history, debugging notes, and transient execution state out of Specs and Decision Records.

package/skills/rsp/SKILL.md

@@ -4,7 +4,7 @@ description: Use this skill when initializing RSP, operating an existing .rsp pr
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.24.1"
+  version: "2026.07.25.2"
 ---
 
 # RSP Skill
@@ -49,19 +49,26 @@ Diagnosis takes precedence over TDD: do not encode an unexplained symptom as a g
 
 Use the release-documentation branch only when the selected Change explicitly owns a confirmed release identity or range and still has unfinished changelog, release-note, or migration work. Lifecycle stage, completed implementation, or archive readiness alone is insufficient; ordinary Changes continue to the Core durable decision.
 
+Treat release identity as an owner decision. It is confirmed only by an explicit user instruction or authoritative repository release configuration; never infer it from version ordering, a previous prerelease, commit contents, or planned prose. Until confirmation, keep any release ledger version-neutral and leave version manifests, target changelog headings, exact-version README commands, versioned release notes, and tag comparisons unchanged.
+
 When both conditions hold, select `rsp-release-docs` when available. Otherwise use the manual release-documentation fallback against the same Change: confirm the release range and audience, build one net-release evidence ledger, and project it into the repository-owned changelog, release notes, and applicable migration guidance. This route prepares or audits documentation only; it does not grant commit, tag, push, release creation, publication, deployment, or approval authority.
 
+An explicit request to create a release tag, hosted release, registry publication, or equivalent public release has an additional mandatory finalization gate. Before any external action, require either one selected Change or one explicitly named archived release Change to own the confirmed release identity and range, then select the `rsp-release-docs` **Finalize for publication** branch even if the prose was already reviewed. When project authority requires archive before final Git delivery, finish the durable decision and lifecycle closeout first, commit that closeout, and rerun the exact finalization checks against the post-archive candidate ref; only that immutable candidate may receive `ready`. The gate inspects the public tag/package release surfaces, rejects transient publication-state prose in shipped artifacts, and returns a credential-free `ready` or `not ready` handoff. If the Skill is unavailable, perform the same checks with the manual fallback. Neither result executes or grants authority for the external action.
+
+After an observed publication, use the `rsp-release-docs` **Reconcile published release** branch only when the selected or explicitly named archived release owner has unfinished external verification or mutable public-surface corrections. Keep immutable discrepancies historical and assign a corrective version or owner instead of moving tags or rewriting packages.
+
 Apply these gates in order:
 
 1. If authority, selection, or a material owner decision is ambiguous, return the one decision or evidence needed to proceed. If a declared blocker prevents the next operation, return its owning artifact or person; do not route around it.
 2. If the user explicitly requests managed continuation, select `rsp-manage` only when it is available. Its eligibility gate activates only for one focused ready Change with genuinely independent slices, long authorized continuation, or interruption recovery; an ineligible request returns the exact ordinary Core or Discipline next action without mutation or controller artifacts. Managed routing is never implicit and grants no lifecycle, Git, publication, deployment, approval, or human-acceptance authority.
 3. If the user requests a report-only review against a fixed scope, select `rsp-review` only when it is available; otherwise name the manual read-only review and return its findings to the selected Change's Tasks, Verify, or Blockers.
-4. If no Change is selected, use the status plan to name one ready WorkRef and the direct focus action. For tiny settled work, return the direct engineering action without creating RSP state. For unclear non-trivial work, select `rsp-shape` only when it is available and the user authorized its Change mutation; otherwise give the manual fallback of creating or refining one Change.
-5. If the user or Shape has isolated one material domain, module/seam, or evidence-seeking design question for the selected Change, select `rsp-design` when available; otherwise return the compact manual design fallback: inspect project authority and the live path, compare credible alternatives, separate evidence from owner choice, and return the result to the same WorkRef without implementation or durable-truth mutation.
-6. If the selected Change is not shape-ready and no bounded design question has been isolated, select `rsp-shape` under the same authority rule or give the manual fallback of completing its Proposal, Spec, Design, Tasks, Verify, and Blockers.
-7. If a shape-ready Change has incomplete implementation tasks, or its required verification is missing, stale, or failed, apply the implementation-evidence routing above. Select only its resulting available capability when authorized; otherwise name its manual fallback owned by that Change.
-8. If implementation Tasks and required verification pass with no blocker, and the selected Change meets both release-documentation conditions above, select `rsp-release-docs` under the same availability rule or use its manual fallback. Return its evidence and artifact dispositions to the same Change.
-9. Otherwise, when required Tasks and verification pass with no blocker, perform the Core durable decision. Archive only after required current facts and rationale are written or explicitly judged unnecessary. Recommend explicit archive as the next action before final Git delivery; Core does not execute archive or grant authority to stage, commit, push, or publish.
+4. If the user explicitly requests a tag, hosted release, registry publication, or published-release reconciliation, resolve exactly one selected or explicitly named archived release owner with the confirmed identity and range, then run the `rsp-release-docs` finalization or reconciliation branch and return its credential-free result. This gate precedes ordinary no-focus and implementation routing so a post-archive release owner is not replaced by an unrelated ready Change. Missing owner evidence returns the exact required release owner; the gate never executes or grants the external action.
+5. If no Change is selected, use the status plan to name one ready WorkRef and the direct focus action. For tiny settled work, return the direct engineering action without creating RSP state. For unclear non-trivial work, select `rsp-shape` only when it is available and the user authorized its Change mutation; otherwise give the manual fallback of creating or refining one Change.
+6. If the user or Shape has isolated one material domain, module/seam, or evidence-seeking design question for the selected Change, select `rsp-design` when available; otherwise return the compact manual design fallback: inspect project authority and the live path, compare credible alternatives, separate evidence from owner choice, and return the result to the same WorkRef without implementation or durable-truth mutation.
+7. If the selected Change is not shape-ready and no bounded design question has been isolated, select `rsp-shape` under the same authority rule or give the manual fallback of completing its Proposal, Spec, Design, Tasks, Verify, and Blockers.
+8. If a shape-ready Change has incomplete implementation tasks, or its required verification is missing, stale, or failed, apply the implementation-evidence routing above. Select only its resulting available capability when authorized; otherwise name its manual fallback owned by that Change.
+9. If implementation Tasks and required verification pass with no blocker, and the selected Change meets both ordinary release-documentation conditions above, select `rsp-release-docs` under the same availability rule or use its manual fallback. Return its evidence and surface dispositions to the same Change.
+10. Otherwise, when required Tasks and verification pass with no blocker, perform the Core durable decision. Archive only after required current facts and rationale are written or explicitly judged unnecessary. Recommend explicit archive as the next action before final Git delivery; Core does not execute archive or grant authority to stage, commit, push, or publish. Keep each completed Change independently reviewable. If later Git authority is granted, deliver that Change as its own logical commit before a separately owned Release Change finalizes versioned shipped surfaces in a dedicated release commit.
 
 State the derived stage, one next action, required input, returned owner, and decisive evidence. Name at most one available optional capability. Only name an optional capability when it is the one next action, and treat it as available only when it appears in the host's loaded skill inventory. Missing optional capabilities never invalidate RSP; always provide the manual fallback against the same owner.
 

package/skills/rsp-manage/SKILL.md

@@ -4,7 +4,7 @@ description: Continue one explicitly requested focused RSP Change through genuin
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.24.1"
+  version: "2026.07.25.2"
 ---
 
 # RSP Manage
@@ -17,7 +17,7 @@ Require one focused, ready Change and sufficient mutation authority. Snapshot th
 
 Activate only for at least two non-overlapping mutation scopes with independent verification, genuinely long authorized continuation, or interruption recovery whose stale-evidence cost justifies orchestration. A small single slice, tightly coupled scopes, or host worker availability alone is ineligible. On decline, make no mutation, create no dispatch envelope, receipt, budget, or controller state, and return the exact Core or Discipline next action without executing it.
 
-Identify allowed mutations, required verification, unavailable acceptance, and lifecycle, Git, publication, deployment, approval, or other external-action boundaries. Preserve unrelated work. Unless the user sets a tighter limit, allow at most four worker dispatches and one corrective retry for the whole run.
+Identify allowed mutations, required verification, unavailable acceptance, and lifecycle, Git, publication, deployment, approval, or other external-action boundaries. Release identity is unconfirmed unless explicit user or repository authority supplies it; never infer it from versions or plans. Preserve unrelated work. Unless the user sets a tighter limit, allow at most four worker dispatches and one corrective retry.
 
 ## Dispatch only real work
 
@@ -36,7 +36,7 @@ For each slice choose the cheapest decisive focused check. Run at most one broad
 
 ## Continue from current evidence
 
-After each return inspect the actual diff and freshly observed verification. Accept a slice only when the owned output exists, decisive checks pass, omissions are named, and the Change still owns the result. Continue only after positive progress.
+After each return inspect the diff and fresh verification. Accept only owned output with passing decisive checks and named omissions. Continue only after progress.
 
 Use the one corrective retry only when new evidence identifies an in-scope correction. Otherwise stop at the failure. Inspect current worktree and evidence after returns, but reread stable authority only during interruption recovery or when evidenced authority or worktree drift could invalidate the snapshot.
 
@@ -48,6 +48,8 @@ Keep dispatch details, retry history, limits, and process chronology out of Chan
 
 Treat archive guidance as advisory unless the run has explicit lifecycle-closeout authority and Core has completed its durable decision. Archive never grants Git or publication authority.
 
-Stop at an unresolved owner decision, unavailable service, credential, device, environment, or human acceptance; missing external-action authority; verification without an evidenced in-scope correction; drift; or exhausted limits. Do not route around the boundary.
+With explicit Git authority, commit only the completed focused Change after closeout. Keep later versioned surfaces in a separate Release Change and dedicated release commit. Otherwise return the exact commit boundary and owner.
+
+Stop at unresolved owner decisions, unavailable dependencies or acceptance, missing external-action authority, uncorrectable verification, drift, or exhausted limits. Do not bypass the boundary.
 
 Return only completed and pending slices, fresh verification, omissions, the real boundary owner, and one next action. Do not expose dispatch, retry, or budget chronology and do not claim archive, Git, publication, deployment, approval, or human acceptance that was not completed under explicit authority.

package/skills/rsp-release-docs/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: rsp-release-docs
-description: Prepare and audit evidence-based changelogs, release notes, and migration notes. Use when drafting or updating release documentation, reviewing an Unreleased section, summarizing a version range, deciding references or omissions, or checking that release prose matches shipped behavior and repository conventions.
+description: Prepare, finalize, reconcile, and audit evidence-based changelogs, release notes, and migration notes. Use when drafting or updating release documentation, reviewing an Unreleased section, summarizing a version range, deciding references or omissions, checking that release prose matches shipped behavior, finalizing artifacts before an explicit tag or publication request, or reconciling public release surfaces afterward.
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.22.1"
+  version: "2026.07.25.2"
 ---
 
 # RSP Release Docs
@@ -26,15 +26,18 @@ Use the higher-precedence source when two sources conflict. Ask one focused ques
 
 Completion criterion: name the release range, target version or draft state, audience, output surfaces, language, link style, and allowed mutations from observed authority.
 
+A release identity is confirmed only when the user states it or an authoritative repository release configuration already selects it. Never infer the next version from semantic-version ordering, a previous prerelease, commit contents, a planned changelog, or package-manager convention. When identity or range remains undecided, return that exact owner decision instead of choosing it.
+
 ## Select the branch
 
 - **Audit:** inspect existing release prose and return findings without editing.
-- **Prepare:** draft requested artifacts; for a formal release, always include release notes. Update a changelog only when the repository owns one or the user requests one. Include migration guidance whenever users must act.
-- **Finalize:** replace Unreleased markers, dates, comparison links, or draft labels only when the release identity is confirmed.
+- **Draft:** build a version-neutral ledger while the release identity may still change. Keep it in the response, temporary work, or an existing release-fragment system; do not mutate version manifests, target changelog headings, exact-version README commands, versioned release-note paths, or tag comparisons before identity is confirmed. Once confirmed, draft the requested release surfaces; for a formal release, always include release notes. Update a changelog only when the repository owns one or the user requests one. Include migration guidance whenever users must act.
+- **Finalize for publication:** with a confirmed release identity and range, make every shipped surface true both immediately before and after publication, then produce a checkable publication handoff. An explicit request to create a tag, GitHub release, registry version, or equivalent public release must pass this branch even when earlier drafts were reviewed. Use the selected release Change before lifecycle closeout or one explicitly named archived release Change afterward; when project authority requires archive before final Git delivery, only the post-archive candidate may receive the final `ready` handoff.
+- **Reconcile published release:** verify the external release against the confirmed identity, repair only authorized mutable public surfaces, and record immutable discrepancies and their remediation owner. Never rewrite a published package or move an existing tag to make evidence appear consistent.
 
-Publication is a separate branch. Preparing prose never grants commit, tag, push, release creation, registry publication, deployment, deletion, or approval authority.
+Publication remains an external action. This Skill never executes commit, tag, push, release creation, registry publication, deployment, deletion, or approval; finalization returns a handoff to the separately authorized operator.
 
-Completion criterion: every requested surface has one disposition: draft, update, audit only, not applicable, or blocked by a named decision.
+Completion criterion: exactly one branch is selected, and every requested surface has one disposition: draft, finalize, reconcile, audit only, not applicable, or blocked by a named decision.
 
 ## Collect evidence
 
@@ -70,6 +73,18 @@ Collapse multiple commits into one outcome. Omit changes added and reverted with
 
 Completion criterion: the ledger describes the net released state rather than commit chronology, and every exclusion is intentional.
 
+## Assign surface lifetime
+
+Classify every release statement by the lifetime and owner of its destination:
+
+- **Shipped surfaces:** public release communication and package metadata captured by the release tag or package, including README content, changelog entries, repository release notes, manifests, and migration guides. Internal workflow records merely present in the source tag, such as archived Changes, remain governed by their own artifact lifetime rather than becoming release prose. Finalized shipped prose must be **publication-invariant**: it remains true before publication, at publication, and afterward. Use the target version and stable comparison target; exclude transient claims such as “not yet published,” “available after publication,” pending authentication, live registry state, or comparisons ending at `HEAD`.
+- **Mutable public surfaces:** hosted release descriptions, registry metadata that can be safely changed, and other public records outside the immutable artifact. Keep their stable narrative aligned with shipped surfaces; add post-publication verification only after observing it.
+- **Transient release state:** pending publication, credentials, command progress, authentication status, and unverified registry availability. Keep it in the selected Change, an authorized release tracker, temporary working ledger, or response handoff—never in shipped prose.
+
+When a published immutable surface is wrong, preserve the historical artifact, state the discrepancy on an authorized mutable surface, and name a corrective follow-up version or owner. Do not manufacture consistency by changing historical evidence.
+
+Completion criterion: every ledger statement has one named surface class and owner, and no transient release state is assigned to a shipped surface.
+
 ## Project the artifacts
 
 Read [output contracts](references/output-contracts.md) before creating a new format, preparing a major or breaking release, or producing more than one surface.
@@ -88,6 +103,35 @@ State who is affected, required actions in order, changed defaults or removed su
 
 Completion criterion: every statement maps to the ledger, each surface serves its distinct audience and lifetime, and terminology remains consistent across surfaces.
 
+## Finalize for publication
+
+Enter this gate only with a confirmed target version and release range owned by a dedicated Release Change. Inspect the exact public release surfaces and package inventory, not every internal workflow record present in the source tag. Ordinary implementation Changes must complete their own review and lifecycle closeout first. When Git delivery is authorized, keep their commits independently reviewable and finalize version manifests and versioned shipped surfaces in a separate release commit. When project authority requires archive before final Git delivery, an open Release Change may prepare these surfaces but the final handoff must rerun against the post-archive candidate ref using the explicitly named archived Release Change as authority.
+
+Require all of the following before returning a publication handoff:
+
+- version manifests, changelog heading and date, release-note identity, migration guidance, and exact-version assertions agree on the target version;
+- the target changelog entry is no longer labeled `Unreleased`;
+- stable comparison links terminate at the target tag or immutable release ref rather than `HEAD`;
+- shipped surfaces contain no pending-publication, pending-authentication, or unverified-live-state prose;
+- the package inventory and release checks have been run at the exact candidate revision, with results and omissions named;
+- required lifecycle closeout is already captured by the candidate revision, and the working tree/candidate relationship is explicit, so the operator can tell exactly what the tag and package will contain.
+
+Return a publication handoff containing the target version and immutable candidate ref, required external actions, fresh checks, known omissions, and a clear `ready` or `not ready` result. `ready` means the documentation and candidate are internally eligible for a separately authorized publication operation; it is not publication authority or evidence that publication occurred.
+
+Completion criterion: every gate above has observed evidence or the result is `not ready` with the exact failed gate and owner.
+
+## Reconcile a published release
+
+After publication, observe the tag target, hosted release state, registry version and dist-tags, and exact-version consumer command when applicable. Compare them to the finalization handoff and shipped artifact inventory. Update authorized mutable public surfaces only when their current state is known; keep unknown external facts explicitly unverified. Record immutable drift as a release discrepancy with its corrective version or owner.
+
+Completion criterion: every intended external surface is verified, explicitly unverified, or assigned a discrepancy owner without rewriting immutable release history.
+
+## Protect transient credentials
+
+Treat one-time passwords, browser-auth URLs, device codes, and token-bearing query strings as transient credentials even when they expire or are single-use. Keep them out of release prose, Changes, evidence ledgers, command summaries, retained logs, and final responses. Prefer a CLI-owned interactive browser flow only when it does not copy authentication material into retained agent output. If the command would emit that material into a retained transcript, stop and let the authorized human complete authentication in a trusted local terminal, then resume credential-free verification. The release handoff may state that authentication is required or completed, but never include the credential value or URL.
+
+Completion criterion: retained artifacts contain only credential-free authentication status, and the publication operator owns any interactive authentication outside this Skill.
+
 ## Apply reference policy
 
 Follow repository policy first. Otherwise:
@@ -113,8 +157,11 @@ Check all of the following:
 - user-visible net outcomes are not fragmented by commit;
 - links, dates, headings, language, and terminology match observed conventions;
 - changelog and release notes agree without becoming copies;
+- every shipped statement is publication-invariant and every transient fact stays with its release-state owner;
+- finalization gates are complete before any explicit tag or publication handoff is marked `ready`;
+- retained artifacts and responses contain no transient credential values or token-bearing URLs;
 - working-tree edits stay within authorized files.
 
 Return the release range, artifacts drafted or changed, coverage and exclusions, unresolved decisions, validation performed, and whether any external release action occurred.
 
-Completion criterion: the result is evidence-complete, convention-compatible, and truthful about omissions and publication state.
+Completion criterion: the result is evidence-complete, convention-compatible, lifetime-correct, credential-safe, and truthful about omissions and publication state.