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

package/skills/rsp-manage/SKILL.md

@@ -1,55 +1,67 @@
 ---
 name: rsp-manage
-description: Continue one explicitly requested focused RSP Change through genuinely independent bounded slices or interruption recovery while keeping ordinary work on existing Core and Discipline paths.
+description: Coordinate one eligible long-running, recovery, or multi-slice RSP goal across ready Changes or a shallow Group without expanding its authority.
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.25.2"
+  version: "2026.07.28.4"
 ---
 
 # RSP Manage
 
-Manage one focused Change only after the user explicitly requests managed continuation. Keep RSP artifacts as durable truth and process data transient.
+Manage one ready Change or shallow Group selected by Core from an explicit request or effective `manage.activation: auto`. Keep artifacts durable and process data transient. The goal defines authority; automatic activation grants selection, not mutation.
 
 ## Qualify before mutation
 
-Require one focused, ready Change and sufficient mutation authority. Snapshot the user authority, nearest instructions and context, Group Brief when present, Change, relevant Specs and Decisions, current RSP status, and worktree once.
+Before dispatch, read all of the following:
 
-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.
+- every qualified WorkRef, including clear in-scope successors;
+- the complete owning Change, or the Group Brief and its children;
+- relevant Specs and Decisions;
+- the authority envelope, `rsp status --json`, and the current worktree.
 
-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.
+Missing configuration preserves `explicit` activation with `local` closeout compatibility. Invalid configuration fails closed as `explicit` plus `manual`.
 
-## Dispatch only real work
+A Change is eligible when at least one of these independent conditions holds:
 
-Send an internal compact envelope only to a worker that will execute an eligible slice:
+- its work contains genuinely independent slices;
+- the authorized continuation is prospectively long; or
+- the continuation is interruption recovery.
 
-```md
-- WorkRef: <focused Change>
-- Objective: <one observable slice>
-- Authority: <exact inputs and allowed mutations>
-- Return: <changed artifacts, decisive verification, omissions, and stop boundary>
-```
+Lack of parallel work does not disqualify a long continuation or recovery. Derive "long" before dispatch from the authorized objective and expected phases, never from elapsed time. A Group is eligible when it has at least two ready children, or when the continuation qualifies as long or recovery. A small coupled one-step Change and worker-only work are ineligible. Decline Manage without any mutation and without creating a controller artifact, then return the exact Core or Discipline action.
 
-Parallelize only non-overlapping mutation scopes with independent verification. Keep overlapping mutations and dependent verification sequential. Workers receive no implied focus, lifecycle, durable-write, Git, publication, deployment, approval, or cleanup authority.
+Preserve unrelated work and require an explicit release identity. Allow four worker dispatches and one worker corrective retry across the whole managed run. Owner transitions do not reset either limit.
 
-For each slice choose the cheapest decisive focused check. Run at most one broader integration gate, and only when combined mutations create integration risk or project authority requires it. Do not multiply checks per worker or retain disposable process tests.
+## Dispatch owned work
 
-## Continue from current evidence
+Send a compact envelope that identifies the WorkRef, objective, authority, decisive evidence, and stop boundary. For a Group, dispatch child WorkRefs only in the current derived `plan.waves` wave. Assume shared paths, lockfiles, generated artifacts, and integration outputs overlap unless an authorized isolated workspace exists. Keep blockers, later waves, overlaps, and dependent verification sequential. Workers receive no implied focus, lifecycle, Git, publication, deployment, or approval authority. Choose the cheapest decisive check and at most one integration gate.
 
-After each return inspect the diff and fresh verification. Accept only owned output with passing decisive checks and named omissions. Continue only after progress.
+## Continue from evidence
 
-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.
+Inspect diff and verification before accepting results; rerun `rsp status --json`. For a Group restrict it to declared children.
 
-Treat handoffs as transient pointers, never project truth. During recovery, reread current authority and referenced evidence, return changed or unverifiable completion to pending, and enforce the remaining finite limits. Never create durable controller status, retry graphs, receipts, or parallel lifecycle state.
+At owner boundaries, Core re-derives from goal. Continue a clear in-scope ready successor. Stop only when neither a ready successor nor clearly missing ownership remains. Otherwise suspend dispatch and return evidence to Core; Core routes Shape and requalifies without another authorization round. Manage neither classifies discovery nor changes topology.
 
-## Preserve artifact and authority boundaries
+Stop when discovery changes behavior, acceptance, interfaces, scope, mutation, or external authority. Retry only evidenced corrections. During recovery, reread authority and evidence. Never create controller status or parallel lifecycle state.
 
-Keep dispatch details, retry history, limits, and process chronology out of Changes, Specs, Decision Records, and the user-facing final result. Update the selected Change only with converged requirements, completed outcomes, decisive evidence, omissions, and real blockers. Durable facts and rationale still use Core's normal artifact-routing decision.
+## Converge managed review
 
-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.
+After fixed-scope re-review, Core correlates the report with the selected Change, original authority, fresh verification, and transient pass count. An `accepted` Finding starts another Resolve Findings pass without asking the user to continue only when it remains inside the original behavior, acceptance, paths, mutation authority, and verification budget. Resolve Findings never self-loops.
 
-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.
+Allow at most three Resolve Findings passes per Change, separate from the worker retry limit. Stop when the same Finding remains after two completed corrections. Also stop for `needs-clarification`; a material product, interface, or scope change; new mutation or external authority; an additional real-host, provider, or network run outside existing verification authority; or failed or unavailable decisive verification. Return one owner input. Treat an eligible in-scope Finding as `correction-needed`, not an external blocker. Keep counts and correction chronology transient.
 
-Stop at unresolved owner decisions, unavailable dependencies or acceptance, missing external-action authority, uncorrectable verification, drift, or exhausted limits. Do not bypass the boundary.
+## Preserve boundaries
 
-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.
+Keep dispatch chronology out of Changes, Group Briefs, Specs, Decision Records. Changes retain converged requirements, outcomes, evidence, omissions, and blockers; Briefs retain shared completion without copied child state. Never persist the goal envelope, WorkSet, waves, or discovery classification.
+
+Closeout requires Core-selected, currently-qualified Manage. For declined, unavailable, or unselected Manage, every `manage.closeout` preset is dormant; Core may report readiness/next action, but configuration executes neither archive nor commit. Earlier qualification does not carry forward.
+
+Qualified only: effective `manage.closeout` is an automatic grant ceiling narrowed by nearer restrictions and host enforcement. `manual` grants neither automatic archive nor commit. `lifecycle` grants lifecycle closeout after Core durable review but no Git action. `local` grants lifecycle closeout, separately justified recovery checkpoints, and the deterministic terminal route below. Explicit current-turn authority may allow a local action not automated by the preset; denial wins.
+
+When granted, close lifecycle before any commit. Change: after Core durable review run `rsp archive <change-work-ref>` and inspect the complete lifecycle diff. For shallow Group: durable-review/archive each child independently, rederive completion, then when all children plus Group gate pass run `rsp group close <group>`; inspect the complete lifecycle diff after each mutation. This includes terminal owners. Require proven review/clean-boundaries.
+
+Decide commit separately. Under `local` or explicit commit authority, downstream work may justify one recovery checkpoint: give `rsp-commit` owner, paths, evidence, lifecycle, and authority, then derive status. Terminal small owners default to no commit. After lifecycle closeout, a qualified `local` terminal non-small Change or Group with known owner and paths, fresh decisive verification, clean exact boundary, and no nearer denial routes exactly once to `rsp-commit`; do not require the user to repeat `commit`. An ambiguous, mixed, stale, or denied boundary stops without staging. Apply the same owner envelope to explicitly authorized Group/release commits; use Core fallback if Commit is unavailable. Archive grants no Git or publication authority.
+
+Push is opt-in only when user explicitly mentions push and remote, branch, and Group or goal milestone are unambiguous or accepted. Push there, or earlier only for required remote CI, recovery, or collaboration. Never force-push, infer push from commit authority, or push a protected or ambiguous branch. Failure preserves local commits and stops at remote boundary. Return to Core before a separate release operation and dedicated release commit.
+
+Stop on unavailable dependencies, missing authority, failed verification, drift, or limits. Return WorkRefs, verification, omissions, boundary owner, and next action. Do not expose retry chronology or claim unobserved completion.

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

@@ -1,167 +1,75 @@
 ---
 name: rsp-release-docs
-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.
+description: Draft, audit, finalize, or reconcile evidence-based changelogs, release notes, and migration notes for an explicit release operation.
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.25.2"
+  version: "2026.07.26.1"
 ---
 
 # RSP Release Docs
 
-Build one release evidence ledger, then project it into the repository's release surfaces. Treat Git history as navigation, not product truth.
+Build one net-release evidence ledger and project it into repository-owned release surfaces. Git history locates evidence; it is not product truth.
 
 ## Establish authority
 
-Resolve requirements in this order:
+Resolve user scope, audience, language, format, references, and mutation authority first; then nearest project instructions, release-tool configuration, target-artifact conventions, and prior published releases. Higher-precedence evidence wins. Ask one focused question only when an unresolved owner choice materially changes the public result.
 
-1. Follow the user's explicit scope, audience, language, format, reference, and mutation requirements.
-2. Follow the applicable instruction hierarchy; nearer project instructions override broader host or personal defaults.
-3. Follow existing release-tool configuration.
-4. Preserve the target artifact's current structure, terminology, and language.
-5. Match prior published releases and tag, link, and tracker conventions.
-6. Apply the defaults in this Skill only where the repository is silent.
+Read [convention discovery](references/convention-discovery.md) when repository, personal, tool, or historical conventions must be located or reconciled. Do not invent configuration or persist preferences without authority.
 
-Use the higher-precedence source when two sources conflict. Ask one focused question only when the unresolved choice would materially change the public result. Read [convention discovery](references/convention-discovery.md) when locating or reconciling repository and personal conventions. Persist a preference only when the user explicitly authorizes its project or personal instruction owner.
+A release identity is confirmed only by explicit user instruction or authoritative repository release configuration. Never infer it from semantic-version ordering, prior prereleases, commits, planned prose, or package-manager convention. Until confirmed, keep work version-neutral and do not mutate manifests, target changelog headings, exact-version commands, versioned note paths, or tag comparisons.
 
-Completion criterion: name the release range, target version or draft state, audience, output surfaces, language, link style, and allowed mutations from observed authority.
+Before continuing, name the range, confirmed version or draft state, audience, surfaces, language, link style, and allowed mutations.
 
-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 one branch
 
-## Select the branch
+- **Audit:** inspect fixed release prose and return findings without editing.
+- **Draft:** collect and project evidence. While identity can change, keep the ledger transient or use an existing release-fragment owner. Once identity is confirmed, update only authorized surfaces. Formal releases include release notes; update a changelog only when the repository owns one or the user asks; include migration guidance whenever users must act.
+- **Finalize for publication:** require confirmed identity and range, completed implementation Change closeout, and an exact clean candidate. An explicit tag, hosted release, registry publication, or equivalent public request must pass this branch even after prose review. Bind `ready` to the exact release commit.
+- **Reconcile published release:** observe the published identity and external surfaces, repair only authorized mutable surfaces, and assign immutable discrepancies to a corrective version or owner. Never rewrite a published package or move a tag to manufacture consistency.
 
-- **Audit:** inspect existing release prose and return findings without editing.
-- **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.
+Exactly one branch is active. Give every requested surface one disposition: draft, finalize, reconcile, audit only, not applicable, or blocked by a named decision.
 
-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.
+## Keep release coordination proportional
 
-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.
+A confirmed mechanical release does not require an RSP Change. Keep the ledger, command progress, authentication state, and publication handoff transient; manifests, changelog, release commit, tag, hosted release, and registry record own durable release history.
 
-## Collect evidence
+Use an optional Release Change only when material version/range, migration, rollback, security, compatibility, cross-repository/team, multi-stage handoff, recovery, blocker, or acceptance decisions need a persistent owner. Do not create one for a checklist, verification transcript, or prose already owned by release surfaces.
 
-Inspect the smallest sufficient set:
+## Build evidence before prose
 
-- previous release tag or user-supplied base and the target ref;
-- commits and net diff in the release range;
-- PRs, issues, tracked Changes, changesets, news fragments, and release PRs when available;
-- public API, CLI, configuration, packaging, migration, security, and operator-facing changes;
-- existing changelog, prior release notes, migration guides, version files, and release configuration;
-- fresh verification and known acceptance gaps when the release claims compatibility or readiness; label archived evidence with its observed revision or date instead of presenting it as current.
+Inspect the smallest sufficient set: base and target refs; commits and net diff; relevant PRs, issues, Changes, fragments, and release PRs; public API, CLI, configuration, packaging, migration, security, and operator behavior; release surfaces and configuration; fresh verification and known acceptance gaps.
 
-Use diffs and direct consumers to verify behavior. Use commit messages and labels to locate intent. Prefer accepted work artifacts and public documentation for business meaning. Reconcile disagreements explicitly instead of choosing the most convenient source.
+Use direct consumers and diffs for behavior, work artifacts and public docs for meaning, and commit metadata for navigation. Reconcile disagreements explicitly. Historical verification must name its observed revision or date.
 
-Completion criterion: every commit and every relevant tracked item in the range is represented by evidence or has an explicit exclusion reason.
+Read [evidence and surfaces](references/evidence-and-surfaces.md) before drafting the ledger, classifying statement lifetime, or deciding exclusions. Read [output contracts](references/output-contracts.md) before introducing a format, preparing a major/breaking release, or producing multiple surfaces.
 
-## Build the release ledger
+Every relevant commit and work item must map to a net outcome or explicit exclusion. Collapse implementation chronology, omit additions reverted within the range, fold prerelease fixes into final behavior, and exclude internal work unless it changes public behavior, packaging, compatibility, security, operations, or release integrity.
 
-Create a working ledger before writing prose. Keep it in the response or temporary work unless the repository already owns release fragments or the user authorizes a path.
+## Project distinct surfaces
 
-For each net change record:
+- **Changelog:** concise cumulative notable outcomes using the existing categories, or Keep a Changelog categories as fallback. Put breaking changes and required action first.
+- **Release notes:** audience-specific narrative led by the most important outcomes, required action, evidenced compatibility and limitations, plus the full range link. Do not merely duplicate the changelog.
+- **Migration notes:** identify affected users, ordered actions, changed defaults or removed surfaces, compatibility window, validation, and known rollback/support. Use a separate guide when this would overwhelm the notes.
 
-- evidence identifiers and links;
-- user-visible or operator-visible outcome;
-- affected audience;
-- breaking, deprecation, security, compatibility, or migration impact;
-- changelog disposition;
-- release-note disposition;
-- reference choice;
-- exclusion or uncertainty, if any.
+Every claim must map to the ledger. Keep terminology aligned while respecting each surface's audience and lifetime.
 
-Collapse multiple commits into one outcome. Omit changes added and reverted within the same range. Fold fixes to never-released behavior into the final feature description. Keep internal work out unless it changes public behavior, packaging, compatibility, security, operations, or release integrity.
+## Finalize the exact candidate
 
-Completion criterion: the ledger describes the net released state rather than commit chronology, and every exclusion is intentional.
+Read [publication lifecycle](references/publication-lifecycle.md) before a publication handoff or post-publication reconciliation.
 
-## Assign surface lifetime
+Finalization inspects public release surfaces and package inventory at the exact candidate—not every internal workflow artifact present in the tag. Require version, date, changelog, notes, migration guidance, comparisons, manifests, package inventory, release checks, and lifecycle closeout to agree. Shipped prose must remain true before, during, and after publication; transient publication or authentication state belongs only in the handoff.
 
-Classify every release statement by the lifetime and owner of its destination:
+When Git delivery is authorized, implementation Changes remain independently reviewable and versioned shipped surfaces are finalized in a separate release commit. Return the version, immutable candidate ref, required external actions, fresh checks, omissions, and `ready` or `not ready`. `ready` means internally eligible for a separately authorized operation; it is neither publication authority nor evidence of publication.
 
-- **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.
+## Protect authority and credentials
 
-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.
+This Skill never executes or grants authority for commit, tag, push, hosted release creation, registry publication, deployment, deletion, approval, or rewriting immutable history. Publication is a separate external operation.
 
-Completion criterion: every ledger statement has one named surface class and owner, and no transient release state is assigned to a shipped surface.
+Treat one-time passwords, browser-auth URLs, device codes, tokens, and token-bearing query strings as credentials. Never retain their values in release prose, Changes, ledgers, logs, summaries, or responses. If a command would expose them to retained output, stop and let the authorized human authenticate in a trusted terminal; resume only with credential-free status.
 
-## Project the artifacts
+## Return an evidence-complete result
 
-Read [output contracts](references/output-contracts.md) before creating a new format, preparing a major or breaking release, or producing more than one surface.
+Before returning, confirm consistent range and identity; ledger coverage or explicit exclusions; claims bounded by evidence; prominent breaking, migration, security, deprecation, and known-limit information; convention-compatible links, dates, headings, language, and terminology; publication-invariant shipped prose; transient state with its owner; credential-free retained output; and edits limited to authorized paths.
 
-### Changelog
-
-Write a concise cumulative record of notable outcomes. Preserve existing categories; otherwise use Keep a Changelog categories and omit empty sections. Put breaking changes and required action first. Describe behavior, not implementation mechanics.
-
-### Release notes
-
-Write a release-specific narrative for the observed audience. Lead with the most important outcomes, make required action prominent, include compatibility or known limitations when evidenced, and link to the full changelog or comparison range. Do not merely duplicate the changelog.
-
-### Migration notes
-
-State who is affected, required actions in order, changed defaults or removed surfaces, compatibility window, validation steps, and rollback or support path when known. Use a separate guide when the instructions would overwhelm the release notes.
-
-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:
-
-1. Add a version-level compare or tag link.
-2. Prefer PR links for implementation context.
-3. Prefer issue or tracked-work links for rationale and migration context.
-4. Use commit links when no better semantic anchor exists, exact provenance matters, or the user requires them.
-
-Do not force a reference onto every bullet. Use stable public links only; keep private tracker identifiers out of public prose unless the repository already exposes them.
-
-Completion criterion: references add useful context without turning the artifact into a Git log or exposing private information.
-
-## Audit before returning
-
-Check all of the following:
-
-- range and version identity are consistent across artifacts;
-- every ledger item is included or intentionally excluded;
-- no claim exceeds implementation or verification evidence;
-- verification counts, package identities, and compatibility claims name their observed revision or date when they were not refreshed in the current run;
-- breaking, migration, deprecation, security, and known-limit information is prominent where applicable;
-- 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, lifetime-correct, credential-safe, and truthful about omissions and publication state.
+Return the range, branch, changed or audited artifacts, coverage and exclusions, unresolved owner decisions, validation, handoff readiness when applicable, and whether any external action occurred.

package/skills/rsp-release-docs/references/evidence-and-surfaces.md

@@ -0,0 +1,21 @@
+# Evidence and surfaces
+
+Load this reference before drafting the release ledger, assigning statement lifetime, or deciding exclusions.
+
+## Evidence ledger
+
+Keep a transient table or equivalent notes with: evidence identifiers/links, net user or operator outcome, audience, breaking/deprecation/security/compatibility/migration impact, changelog and release-note dispositions, reference choice, and exclusion or uncertainty owner.
+
+The ledger is an analysis device, not a new project state store. Persist it only in an existing release-fragment system or explicitly authorized destination. It describes the released net state rather than commit chronology.
+
+## Surface lifetime
+
+- **Shipped surfaces:** package metadata and release communication captured by the tag or package, including README, changelog, repository notes, manifests, and migration guides. Internal workflow records keep their own artifact lifetime. Shipped statements must be publication-invariant: exclude “not yet published,” “available after publication,” pending authentication, unverified registry state, and comparisons ending at `HEAD`.
+- **Mutable public surfaces:** hosted release descriptions, safely mutable registry metadata, and other external records. Keep stable narrative aligned with shipped surfaces; add live verification only after observing it.
+- **Transient release state:** credentials, authentication, command progress, pending publication, and unverified availability. Keep it in an authorized tracker, temporary ledger, or response handoff—never shipped prose.
+
+When immutable published content is wrong, preserve it, explain the discrepancy on an authorized mutable surface, and name a corrective version or owner.
+
+## References
+
+Follow repository policy first. Otherwise add a version-level tag or comparison link, prefer PRs for implementation context, issues or tracked work for rationale and migration, and commits when no better semantic anchor exists or exact provenance is required. Links are optional per bullet and must be stable and public; do not expose private tracker identifiers.

package/skills/rsp-release-docs/references/output-contracts.md

@@ -4,16 +4,6 @@ Use these as fallbacks. Preserve an established repository format whenever it ex
 
 The generic baseline is Keep a Changelog 1.1.0 for cumulative structure and Semantic Versioning 2.0.0 for version meaning. Treat Conventional Commits, forge-generated notes, and label-based categorization as evidence inventories rather than finished prose.
 
-## Release evidence ledger
-
-Maintain a temporary table or equivalent structured notes:
-
-| Evidence | Net outcome | Audience | Risk/action | Changelog | Release notes | Reference | Exclusion/uncertainty |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| PR, issue, Change, commits, diff, docs, verification | What users receive | Users, developers, operators, maintainers | Breaking, migration, security, compatibility, none | Section or omit | Section or omit | PR, issue, work item, commit, compare | Reason or owner decision |
-
-The ledger is an analysis device, not a new project state store. Persist it only when the repository already owns release fragments or the user authorizes a destination.
-
 ## Default changelog shape
 
 ```markdown
@@ -85,14 +75,6 @@ For each required action, answer:
 
 Keep a short summary in release notes and link a dedicated guide when the procedure is long, conditional, or operationally risky.
 
-## Reference rules
-
-- Add one compare or tag link for the release range when the forge supports it.
-- Prefer PR links for reviewable implementation context.
-- Prefer issue or tracked-work links for rationale and migration context.
-- Prefer commit links for exact fixes, backports, audit provenance, projects without PRs, or explicit user policy.
-- Keep references optional per bullet; a link must earn its visual cost.
-
 ## Net-release examples
 
 - Five commits build one new capability: write one outcome.

package/skills/rsp-release-docs/references/publication-lifecycle.md

@@ -0,0 +1,24 @@
+# Publication lifecycle
+
+Load this reference before finalizing an exact publication candidate or reconciling an observed publication.
+
+## Finalization gate
+
+Require all of the following at the exact candidate:
+
+- target version agrees across manifests, changelog heading/date, release notes, migration guidance, and exact-version assertions;
+- the target changelog entry is not labeled `Unreleased`;
+- stable comparisons end at the target tag or immutable ref, not `HEAD`;
+- shipped surfaces contain no pending-publication, authentication, or unverified-live-state prose;
+- package inventory and release checks are fresh, with omissions named;
+- required implementation lifecycle closeout is in the candidate revision and its worktree relationship is explicit.
+
+Any missing evidence yields `not ready` with the failed gate and owner. A `ready` result identifies the version, immutable candidate ref, required external actions, checks, and omissions without executing them.
+
+## Reconciliation
+
+After publication, observe the tag target, hosted release, registry version/dist-tags, and exact-version consumer command where applicable. Compare them with the finalization handoff and shipped inventory. Update authorized mutable surfaces only from observed state. Mark unknown facts unverified and record immutable drift with a corrective version or owner; never move tags or rewrite packages.
+
+## Credential boundary
+
+Keep authentication values and URLs out of retained output. A human performs any credential-emitting interactive step in a trusted terminal; the handoff records only credential-free required/completed status.

package/skills/{rsp-address-review → rsp-resolve-findings}/SKILL.md

@@ -1,13 +1,13 @@
 ---
-name: rsp-address-review
-description: Resolve one fixed rsp-review report for an RSP-tracked change. Use when the user authorizes disposition of review findings, bounded fixes for accepted findings, fresh verification, re-review, or a recoverable artifact-scoped handoff; keep the reviewer report-only and never infer Git or publication authority.
+name: rsp-resolve-findings
+description: Resolve one fixed rsp-review report for an RSP-tracked change. Use when the user or a qualified managed goal authorizes disposition, bounded fixes, fresh verification, re-review, or recovery; keep the reviewer report-only and never infer Git or publication authority.
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.22.1"
+  version: "2026.07.28.1"
 ---
 
-# RSP Address Review
+# RSP Resolve Findings
 
 Resolve one fixed review report without changing what the reviewer observed. Treat resolution as a bounded correction pass, not a retry loop or a second project lifecycle.
 
@@ -15,7 +15,7 @@ Render headings, field labels, explanations, and conclusion prose in the languag
 
 ## Fix scope and authority
 
-Require the review report, its fixed comparison or file set, the selected Change and sibling Group Brief when applicable, relevant project authority, and explicit permission for any proposed mutation. Read the current worktree and the smallest behavior chain needed to verify each Finding. Preserve unrelated modified, staged, and untracked work.
+Require the review report, its fixed comparison or file set, the selected Change and sibling Group Brief when applicable, relevant project authority, and either explicit user permission or Core-confirmed original managed authority for proposed mutation. Read the current worktree and the smallest behavior chain needed to verify each Finding. Preserve unrelated modified, staged, and untracked work.
 
 Identify a Finding by its report order plus severity, title, and location. Stop if the report, comparison, Change, or Finding identity is missing or conflicting. A report grants investigation only: correction, verification, re-review, Git delivery, publication, deployment, approval, and external actions retain their own authority. Never infer Git or publication authority.
 
@@ -35,7 +35,7 @@ In one resolution pass, implement the smallest complete correction for accepted
 
 After the last relevant edit, run fresh verification for the affected behavior and the selected Change. A failed, unavailable, stale, or omitted check cannot close an accepted Finding. If a check exposes another defect, return it as evidence; do not begin an automatic retry loop.
 
-Require a fresh fixed-scope re-review before claiming resolution. Return a re-review request containing the original comparison, selected authority, post-fix file set or immutable comparison, implementation summary, dispositions, and verification evidence. The re-review remains report-only. On resume with its report, correlate original Findings as resolved or remaining and treat any new Finding as unresolved input for a later authorized pass.
+Require a fresh fixed-scope re-review before claiming resolution. Return a re-review request containing the original comparison, selected authority, post-fix file set or immutable comparison, implementation summary, dispositions, and verification evidence. The re-review remains report-only. On resume with its report, correlate original Findings as resolved or remaining and return any new Finding as unresolved input to Core. Resolve Findings never self-loops. Only qualified Manage may classify an in-scope `accepted` Finding as `correction-needed` and re-enter another bounded pass under the original managed authority and its separate convergence limit; standalone work requires new authority.
 
 ## Handoff and recovery
 
@@ -58,4 +58,4 @@ To recover, reopen every authority pointer, confirm the WorkRef and comparison s
 
 ## Return ownership
 
-Report the disposition table, changed artifacts, preserved unrelated work, fresh verification, re-review status, and the handoff when anything remains. Resolution is complete only when every Finding has a supported disposition, every accepted Finding has a verified correction, the fresh fixed-scope re-review is clean, and no `needs-clarification` input remains. Never claim archive, commit, push, publication, deployment, or approval.
+Report the disposition table, changed artifacts, preserved unrelated work, fresh verification, re-review status, and the handoff when anything remains. Name `correction-needed` only when Core supplied a qualified managed continuation; it is not an external blocker or durable Change state. Resolution is complete only when every Finding has a supported disposition, every accepted Finding has a verified correction, the fresh fixed-scope re-review is clean, and no `needs-clarification` input remains. Never claim archive, commit, push, publication, deployment, or approval.

package/skills/rsp-shape/SKILL.md

@@ -4,7 +4,7 @@ description: Shape or rigorously challenge unclear non-trivial work into one exe
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.24.1"
+  version: "2026.07.28.1"
 ---
 
 # RSP Shape
@@ -17,38 +17,40 @@ Follow Core's response-versus-artifact language boundary.
 
 Read the request, authority, Core or fallback, Change and Brief, then only decisive evidence.
 
-A request to shape, create, or refine a Change grants artifact authority unless no-edit; advice does not. If creation focuses it, preserve the exact prior focus and restore it immediately unless selection was requested. Shaping grants no other authority to focus, implement, archive, edit durable truth, or mutate Git; preserve unrelated work.
+A request to shape, create, or refine a Change grants artifact authority unless no-edit; advice does not. If creation focuses it, preserve the exact prior focus and restore it immediately unless selection was requested. Shaping grants no other authority; preserve unrelated work.
 
 Return the request directly to implementation when it is tiny and concrete or the selected Change is already ready. Do not rewrite settled work for style or completeness.
 
+During an explicit managed goal, its original planning-artifact authority remains valid for clear in-scope discovery. Keep a cohesive correction in the current Change; create one Change for an independently closable result, or one shallow Group for at least two such results sharing the goal. Return the ready WorkRef to Core for fresh qualification without another authorization round. Stop on changed behavior, acceptance, public interfaces, goal scope, mutation authority, or external action.
+
 ## Resolve material ambiguity
 
-Inspect the repository before asking. Ask only for an owner decision whose answer can change behavior, data, interfaces, compatibility, safety, ownership, migration, or acceptance. Ask the smallest useful question set and write only authorized answers into the Change.
+Inspect the repository before asking. Ask only for an owner decision changing behavior, data, interfaces, compatibility, safety, ownership, migration, or acceptance. Write only authorized answers.
 
-Read [deep clarification](references/deep-clarification.md) when the user explicitly asks for rigorous challenge, a high-risk dependent decision remains, or one bounded design question returns to Shape. Prefer the installed `rsp-design` capability; otherwise use its compact fallback against the same WorkRef.
+Read [deep clarification](references/deep-clarification.md) when the user explicitly asks for rigorous challenge, a high-risk decision remains, or one design question returns. Prefer the installed `rsp-design` capability; otherwise use its fallback.
 
 Never invent a product decision. When a material choice or mutation authority remains unresolved, leave the work open and report the single highest-impact blocker.
 
 ## Choose the owner
 
-Read [complex shaping](references/complex-shaping.md) before choosing the owner when material clarification needs more than one round, several direct slices share one completion contract, or independently closable owners converge on terminal delivery.
+Read [complex shaping](references/complex-shaping.md) when clarification needs multiple rounds, slices share one completion contract, or independently closable owners converge on terminal delivery.
 
-Prefer one ordinary Change. Use a shallow Group only when at least two direct children are independently implementable, verifiable, focusable, and archivable while sharing one goal or completion contract. A shared completion contract gates Group closure, not each child's archive unless that child declares the dependency. Keep membership in Brief `Slices`, exact prerequisites in child `Blockers`, and derived readiness in CLI output. Do not create another hierarchy or tracker.
+Prefer one ordinary Change only for one observable outcome sharing a consistency, focused-verification, review, archive, and rollback boundary. Change granularity does not prescribe Git commit count; never split or merge Changes merely to enforce a Change-to-commit mapping. Use a shallow Group for independent outcomes under one goal; an integration gate never merges them. A shared completion contract gates Group closure, not child archive unless declared there. Keep Brief `Slices`, child `Blockers`, and derived readiness. Add no hierarchy.
 
-Follow the core RSP protocol for exact Change and Group structure. Keep one observable outcome per Change:
+Keep one observable outcome per Change:
 
-- `Proposal`: outcome, scope, and non-goals;
-- `Spec`: observable requirements and acceptance scenarios;
-- `Design`: affected boundaries, constraints, and settled choices;
-- `Tasks`: executable implementation steps;
-- `Verify`: final decisive evidence proving the outcome;
-- `Blockers`: exact dependencies and unresolved external decisions, or `none`.
+- `Proposal`: outcome, scope, non-goals;
+- `Spec`: requirements and acceptance;
+- `Design`: boundaries and choices;
+- `Tasks`: executable steps;
+- `Verify`: decisive evidence;
+- `Blockers`: dependencies and decisions, or `none`.
 
-Plan a new test only when it protects observable behavior or a real boundary, adds distinct future confidence, avoids duplicate or implementation-detail coverage, and costs proportionately. Otherwise prefer smallest sufficient evidence and keep probes temporary.
+Plan a test only when it protects observable behavior or a real boundary, adds distinct future confidence, avoids duplicate or implementation-detail coverage, and costs proportionately. Otherwise prefer smallest sufficient evidence and keep probes temporary.
 
-A Change is a convergent current-plan/final-evidence snapshot, not an append-only execution log. Replace superseded evidence; keep process evidence in the response. Before archive, compress it to outcome, design, tasks, decisive verification, gaps, and risks.
+A Change is a convergent current-plan/final-evidence snapshot, not an append-only execution log. Replace superseded evidence; keep process in the response. Before archive, retain final decisive verification, gaps, and risks.
 
-Use domain language. Mention AI or agents only as real product actors, consumers, interfaces, or constraints—not authors or execution narrators.
+Use domain language. Mention agents only as real product actors or constraints, not authors or execution narrators.
 
 ## Apply the Shape Ready gate
 
@@ -62,4 +64,4 @@ A Change is ready only when:
 - Verify proves the result without process chronology; Blockers are truthful;
 - one Change or a justified shallow Group is the smallest sufficient owner.
 
-After authorized mutation, run the project focused RSP check when available. Return WorkRef, changed artifacts, validation, and the next implementation action or blocker.
+After mutation, run the focused RSP check. Return WorkRef, artifacts, validation, and next action or blocker.

package/skills/rsp-shape/references/complex-shaping.md

@@ -10,9 +10,9 @@ Use an installed interview or grilling capability only when the work boundary is
 
 ## Choose a complex owner
 
-Keep cohesive work in one Change when it has one consistency and verification boundary.
+Keep cohesive work in one Change only when it delivers one observable outcome and its tasks must converge across the same consistency, focused-verification, review, archive, and rollback boundary. A shared file, module, deadline, or integration check does not establish that cohesion by itself.
 
-Use a shallow Group when at least two direct children are independently implementable, verifiable, focusable, and archivable. The Brief explains the shared goal, constraints, slices, aggregate completion, and durable outcomes. Child Changes own implementation tasks, verification, and exact `requires` edges. Group completion gates closing the Brief; it does not prevent a child from archiving unless that child declares the dependency.
+Use a shallow Group when at least two observable outcomes can be independently implemented, focused, verified, reviewed, archived, and rolled back. Preserve those outcomes as direct child Changes even when they share one broad integration, release, or acceptance gate. The Brief owns that aggregate gate plus the shared goal, constraints, slices, completion, and durable outcomes. Child Changes own their outcome, implementation tasks, focused verification, lifecycle, and exact `requires` edges. Group completion gates closing the Brief; it does not prevent a child from archiving unless that child declares the dependency.
 
 Use an Overall Delivery Change when independently closable semantic owners converge on terminal versioning, packaging, migration, authorization, or publication. It remains an ordinary six-section Change: