@oevery/rsp 3.1.1 → 3.3.0

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

@@ -4,13 +4,15 @@ description: Draft, audit, finalize, or reconcile evidence-based changelogs, rel
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.26.1"
+  version: "2026.08.23.1"
 ---
 
 # RSP Release Docs
 
 Build one net-release evidence ledger and project it into repository-owned release surfaces. Git history locates evidence; it is not product truth.
 
+Follow Core's response-versus-artifact language boundary for all user-visible control narration; when the response language differs, keep exact canonical values only as secondary parenthesized or code-formatted tokens.
+
 ## Establish authority
 
 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.
@@ -23,10 +25,10 @@ Before continuing, name the range, confirmed version or draft state, audience, s
 
 ## Select one 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:** fixed release prose → inspect and return findings; no edits.
+- **Draft:** when evidence projection is authorized. Mutable identity → transient ledger or existing release-fragment owner; confirmed identity → authorized surfaces only. Formal release → notes; owned or requested changelog → changelog; required user action → migration guidance.
+- **Finalize for publication:** requires confirmed identity and range, completed implementation Change closeout, and an exact clean candidate. A tag, hosted release, registry publication, or equivalent public request selects this branch even after prose review. Bind `ready` to the exact release commit.
+- **Reconcile published release:** requires an observed published identity and external surfaces. Repair authorized mutable surfaces; route an immutable discrepancy to a corrective version or owner. Never rewrite a published package or move a tag to manufacture consistency.
 
 Exactly one branch is active. Give every requested surface one disposition: draft, finalize, reconcile, audit only, not applicable, or blocked by a named decision.
 
@@ -34,7 +36,7 @@ Exactly one branch is active. Give every requested surface one disposition: draf
 
 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.
 
-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.
+Use an optional Release Change only when material version or range, migration, rollback, security, compatibility, cross-repository or cross-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.
 
 ## Build evidence before prose
 
@@ -46,21 +48,19 @@ Read [evidence and surfaces](references/evidence-and-surfaces.md) before draftin
 
 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.
 
+Project each release surface from its audience, accepted range, and observed final state. Omit rejected session-only proposals, corrections, and temporary attempts that never entered the release baseline. A session-only proposal is not a release exclusion or omission: do not name or paraphrase it as a `without X`, `did not add X`, or `did not use X` compliance claim. Preserve actual removals, deprecations, compatibility boundaries, migrations, safety or security facts, failed external actions, requested comparisons, and unresolved risks when users or operators need them.
+
 ## Project distinct surfaces
 
 - **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.
+- **Migration notes:** identify affected users, ordered actions, changed defaults or removed surfaces, compatibility window, validation, and known rollback and support paths. Use a separate guide when this would overwhelm the notes.
 
 Every claim must map to the ledger. Keep terminology aligned while respecting each surface's audience and lifetime.
 
-## Finalize the exact candidate
-
-Read [publication lifecycle](references/publication-lifecycle.md) before a publication handoff or post-publication reconciliation.
+## Load publication lifecycle
 
-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.
-
-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.
+Read [publication lifecycle](references/publication-lifecycle.md) before finalizing an exact publication candidate, preparing a publication handoff, or reconciling an observed publication. It owns exact-candidate consistency, package inventory, release-commit boundaries, readiness, and reconciliation.
 
 ## Protect authority and credentials
 
@@ -72,4 +72,6 @@ Treat one-time passwords, browser-auth URLs, device codes, tokens, and token-bea
 
 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.
 
+The final handoff must directly state every material user or operator action needed to use, migrate, validate, rollback, or remain safe. A file link or generic summary may accompany the result but cannot replace the action. Preserve exact commands, API forms, versions, and other canonical action tokens while keeping the surrounding explanation concise and localized.
+
 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/publication-lifecycle.md

@@ -4,6 +4,8 @@ Load this reference before finalizing an exact publication candidate or reconcil
 
 ## Finalization gate
 
+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.
+
 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;
@@ -15,6 +17,8 @@ Require all of the following at the exact candidate:
 
 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.
 
+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.
+
 ## 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.

package/skills/rsp-resolve-findings/SKILL.md

@@ -4,14 +4,14 @@ description: Resolve one fixed rsp-review report for an RSP-tracked change. Use
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.28.1"
+  version: "2026.08.21.1"
 ---
 
 # 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.
 
-Render headings, field labels, explanations, and conclusion prose in the language explicitly requested by the user; otherwise follow nearest project instructions, then the conversation language. Treat report and handoff shapes as semantic field order rather than fixed English wording: translate their human-facing labels when the output language differs. Preserve paths, commands, identifiers, WorkRefs, FindingRefs, severity labels, and the dispositions `accepted`, `rejected`, and `needs-clarification` unchanged.
+Render headings, field labels, explanations, and conclusion prose in the language explicitly requested by the user; otherwise follow nearest project instructions, then the conversation language. Treat report and handoff shapes as semantic field order rather than fixed English wording: translate their human-facing labels when the output language differs. Preserve paths, commands, identifiers, WorkRefs, FindingRefs, severity labels, and the dispositions `accepted`, `rejected`, and `needs-clarification` unchanged; when their language differs from the response, retain those dispositions only as secondary exact tokens beside localized narration.
 
 ## Fix scope and authority
 
@@ -52,7 +52,7 @@ When work stops before a clean re-review, return Core's compact artifact-scoped
 - <localized Next action label>: <smallest bounded action and owner>
 ```
 
-The handoff contains authoritative pointers, not project truth. Return it in the response unless the user explicitly authorizes a path; never create a hidden receipt or persistent run state. It is not durable truth or a second state store. Exclude secrets, full logs, and duplicated Change text.
+The handoff contains authoritative pointers, not project truth. Return it in the response unless the user explicitly authorizes an artifact path. Exclude secrets, full logs, and duplicated Change text.
 
 To recover, reopen every authority pointer, confirm the WorkRef and comparison still identify the intended scope, inspect current worktree drift, and revalidate claimed verification. Mark stale evidence pending instead of trusting the handoff. Continue only the named pass; host threads, agents, hooks, or proprietary resume features are optional and never required.
 

package/skills/rsp-review/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: rsp-review
-description: Review an RSP-tracked code, document, or mixed change against a fixed comparison scope and project authorities. Use for read-only findings before fixes, durable review, archive, or delivery; keep Code and Document states separate and never implement, commit, publish, or approve.
+description: Review an RSP-tracked code, document, or mixed change against a fixed comparison scope and project authorities without modifying files. Use for read-only findings before fixes, durable review, archive, or delivery; keep Code and Document states separate and never implement, commit, publish, or approve.
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.22.3"
+  version: "2026.08.19.1"
 ---
 
 # RSP Review
@@ -25,45 +25,19 @@ Do not switch branches or mutate the worktree to discover scope. If the comparis
 
 The user request fixes the requested outcome and allowed operations subject to nearest project instructions. The selected Change defines the intended delta, Specs define stable current facts, and Decision Records define lasting rationale. Implementation and tests are evidence, not authority for missing requirements. Report missing authority instead of inventing a rule, acceptance criterion, or preference.
 
-## Classify the scope
+## Classify before loading
 
-- **Code:** executable code, tests, configuration, scripts, schemas, executable prompts, Skills, commands, hooks, and workflows.
-- **Document:** requirements, plans, Changes, Specs, Decision Records, ADRs, explanatory documentation, and user-facing documentation.
+Do not read a pipeline reference until scope and authority are fixed. Then:
 
-Determine applicability only from artifacts inside the fixed comparison scope. A Change, Spec, instruction, implementation file, or test read only as authority or evidence is not thereby a reviewed artifact. Run each applicable pipeline; return `skipped` for a pipeline with no reviewed artifacts even when authority of that kind was inspected, and never return `clean` for authority-only documents. When such authority is missing, ambiguous, or conflicting, record it in Review Scope, Coverage, and Verdict; do not emit a Finding owned by a skipped pipeline. An executable document may need both; merge evidence for the same underlying issue into one cross-artifact finding.
+1. Classify only fixed reviewed artifacts. **Code** includes executable code, tests, configuration, scripts, schemas, executable prompts, Skills, commands, hooks, and workflows. **Document** includes requirements, plans, Changes, Specs, Decision Records, ADRs, explanatory documentation, and user-facing documentation. An executable document may require both.
+2. Inputs read only as authority or evidence are authority-only, not reviewed artifacts. With no reviewed artifacts, a pipeline is `skipped`, never `clean`. Record missing, ambiguous, or conflicting authority in Review Scope, Coverage, and Verdict, not as a Finding from a skipped pipeline.
+3. Load [Code review](references/code-review.md) only if Code applies and [Document review](references/document-review.md) only if Document applies. A mixed review loads both; authority-only artifacts trigger neither.
 
-Inspect in a bounded order: fixed status/diff, selected authority, then only the smallest direct behavior chain and tests needed to resolve a concrete question. Stop when every applicable pipeline can be judged. Do not search unrelated files or broaden authority merely to fill Coverage or Findings.
-
-## Review Code
-
-Check in this order:
-
-1. Safety and correctness: reachable bugs, data loss, security violations, invalid state transitions, broken contracts, unsafe failures, and regressions.
-2. Change and Spec fidelity: observable behavior against explicit intent and stable facts.
-3. Project standards: only rules established by nearest instructions or authoritative local conventions.
-4. Production reachability — hard gate before completing a seam-dependent Finding: when a Finding or suggested correction depends on an adapter, wrapper, validator, normalizer, or similar seam, name the direct production caller, compare its actual callee with that seam, and verify that the changed production consumer actually reaches that seam. Put the comparison in Evidence or Coverage. If the live path bypasses the seam, report the bypass and do not present an isolated seam fix as sufficient.
-5. Regression evidence — hard gate before `clean`: for every changed Code artifact, compare public return and failure behavior at the comparison point with the reviewed diff. Changing failure delivery between throw/rejection, sentinel values, `null`, status codes, or result objects is always a failure-contract change, even when implementation matches the selected Change. Without a focused test or other explicit verification evidence, emit a Finding and return `issues_found`. Absence of a new test is not actionable by itself: apply the simple deterministic-correction exception when the public behavior shape is preserved and no risky branch, state transition, concurrency, persistence, security behavior, or failure delivery changes, even though the corrected value differs. The exception never applies to a failure-contract change.
-6. Simplicity: unnecessary abstraction, duplication, indirection, dependency, or scope expansion with a concrete smaller alternative; never trade away required behavior.
-
-Anchor each Finding to changed lines or the smallest behavior chain. State a realistic trigger and impact. Do not report formatting, naming, generated output, taste, or hypothetical cleanup without authority or demonstrated downside.
-
-## Review Documents
-
-Classify each document by its semantic role: requirement/Change, implementation plan, Spec, Decision Record/ADR, or explanatory/user documentation. Then check:
-
-1. Authority and traceability of claims and decisions.
-2. Internal and cross-artifact coherence, including current implementation facts.
-3. Completeness and ambiguity: undefined terms, unverifiable completion, and choices disguised as decisions. Report an unresolved product, operational, rollback, migration, or completion choice as an ambiguity Finding when no authority resolves it; ask for owner judgment and mark a dependent result blocked only when the choice prevents coherent review.
-4. Feasibility of named paths, interfaces, sequencing, safety, migration, and executable verification, at the detail appropriate to the document role.
-5. Scope and concision: scope leakage, duplicate authority, unrelated requirements, or verbosity hiding a contract.
-
-Before the Document verdict, enumerate every unresolved choice in each changed document. Any unresolved product, operational, rollback, migration, ownership, or completion choice must either have resolving authority or produce an ambiguity Finding; do not stop after finding other defects.
-
-Anchor Findings to the smallest heading or claim. Do not apply code-style or test-coverage rules to semantic documents, auto-fix meaning, or rewrite prose for taste.
+Run every applicable pipeline and merge the same underlying issue into one cross-artifact finding. Inspect in order: fixed status and diff, selected authority, then the smallest direct behavior chain and tests needed for a concrete question. Stop when all applicable pipelines can be judged; do not search unrelated files or broaden authority to fill Coverage or Findings.
 
 ## Report
 
-Render headings, field labels, explanations, and verdict prose in the language explicitly requested by the user; otherwise follow nearest project instructions, then the conversation language. Treat the shape below as semantic field order rather than fixed English wording: translate its human-facing labels when the output language differs. Preserve paths, commands, identifiers, WorkRefs, severity labels `P0`-`P3`, and the values `issues_found`, `clean`, `skipped`, and `blocked` unchanged.
+Render headings, field labels, explanations, and verdict prose in the language explicitly requested by the user; otherwise follow nearest project instructions, then the conversation language. Treat the shape below as semantic field order rather than fixed English wording: translate its human-facing labels when the output language differs. Preserve paths, commands, identifiers, WorkRefs, severity labels `P0`-`P3`, and the values `issues_found`, `clean`, `skipped`, and `blocked` unchanged; when their language differs from the response, retain those values only as secondary exact tokens beside localized narration.
 
 Use this shape:
 
@@ -93,6 +67,6 @@ Use this shape:
 <blocked | findings | clean, with the smallest next action>
 ```
 
-Omit Finding entries when none exist. `clean` means an applicable pipeline was reviewed with no actionable issue; `skipped` means no applicable artifacts; `blocked` means required scope or authority was unavailable. Deduplicate one underlying issue across pipelines, then order by severity and path. Use P0 for critical security/data/breakage, P1 for normal-path contract failure, P2 for a meaningful edge or maintenance risk, and P3 only for narrow actionable improvement.
+Omit Finding entries when none exist. `clean` means an applicable pipeline was reviewed with no actionable issue; `skipped` means no applicable artifacts; `blocked` means required scope or authority was unavailable. Deduplicate one underlying issue across pipelines, then order by severity and path. Use P0 for critical security, data, or breakage risk, P1 for normal-path contract failure, P2 for a meaningful edge or maintenance risk, and P3 only for narrow actionable improvement.
 
 Return a report only. Do not edit files, apply fixes, change focus, create RSP artifacts, switch branches, stage, commit, push, open a PR, publish, delete, trigger external review, or approve. Later actions require separate explicit authority.

package/skills/rsp-review/references/code-review.md

@@ -0,0 +1,15 @@
+# Code review
+
+Load this reference only when the fixed reviewed artifacts make the Code pipeline applicable.
+
+Check in this order:
+
+1. Safety and correctness: reachable bugs, data loss, security violations, invalid state transitions, broken contracts, unsafe failures, and regressions.
+2. Change and Spec fidelity: observable behavior against explicit intent and stable facts.
+3. Project standards: only rules established by nearest instructions or authoritative local conventions.
+4. Production reachability — hard gate before completing a seam-dependent Finding or returning `clean` for a changed seam: when behavior depends on an adapter, wrapper, validator, normalizer, registration, loader, generated wire-up, bin, worker, subprocess, plugin assembly, or another shipped entry path, name the smallest real production entry chain and verify that it reaches the changed seam. Direct or isolated seam tests are insufficient when they bypass that entry chain. Put the checked entry path in Evidence or Coverage. If the shipped path bypasses the seam, or the required reachability evidence is missing, report the gap and do not return `clean` or present an isolated seam fix as sufficient.
+5. Regression evidence — hard gate before `clean`: for every changed Code artifact, compare public return and failure behavior at the comparison point with the reviewed diff. Changing failure delivery between throw/rejection, sentinel values, `null`, status codes, or result objects is always a failure-contract change, even when implementation matches the selected Change. Without a focused test or other explicit verification evidence, emit a Finding and return `issues_found`. Absence of a new test is not actionable by itself: apply the simple deterministic-correction exception when the public behavior shape is preserved and no risky branch, state transition, concurrency, persistence, security behavior, or failure delivery changes, even though the corrected value differs. The exception never applies to a failure-contract change.
+6. Test and seam value — hard gate before `clean` when the diff adds or preserves a permanent test, public seam, validator, fallback, capability, compatibility path, or generic option: classify its consumers as production, non-production, or ambiguous. Tests and documentation alone do not make behavior production-load-bearing. For each questioned permanent test, identify its observable consequence, distinct plausible regression, why existing evidence misses it, and maintenance cost. Report test-only generality, wrapper or forwarding-hop assertions, shared-constant restatement, source-string coupling, or duplicate failure coverage only when a concrete real owner or smaller evidence path exists. Do not recommend deleting or merging tests that protect independent consequences, and do not infer that fewer tests are inherently better.
+7. Simplicity: unnecessary abstraction, duplication, indirection, dependency, or scope expansion with a concrete smaller alternative; never trade away required behavior.
+
+Anchor each Finding to changed lines or the smallest behavior chain. State a realistic trigger and impact. Do not report formatting, naming, generated output, taste, or hypothetical cleanup without authority or demonstrated downside.

package/skills/rsp-review/references/document-review.md

@@ -0,0 +1,15 @@
+# Document review
+
+Load this reference only when the fixed reviewed artifacts make the Document pipeline applicable.
+
+Classify each document by its semantic role: requirement/Change, implementation plan, Spec, Decision Record/ADR, or explanatory/user documentation. Then check:
+
+1. Authority and traceability of claims and decisions.
+2. Internal and cross-artifact coherence, including current implementation facts.
+3. Completeness and ambiguity: undefined terms, unverifiable completion, and choices disguised as decisions. Report an unresolved product, operational, rollback, migration, or completion choice as an ambiguity Finding when no authority resolves it; ask for owner judgment and mark a dependent result blocked only when the choice prevents coherent review.
+4. Feasibility of named paths, interfaces, sequencing, safety, migration, and executable verification, at the detail appropriate to the document role.
+5. Scope and concision: scope leakage, duplicate authority, unrelated requirements, or verbosity hiding a contract.
+
+Before the Document verdict, enumerate every unresolved choice in each changed document. Any unresolved product, operational, rollback, migration, ownership, or completion choice must either have resolving authority or produce an ambiguity Finding; do not stop after finding other defects.
+
+Anchor Findings to the smallest heading or claim. Do not apply code-style or test-coverage rules to semantic documents, auto-fix meaning, or rewrite prose for taste.

package/skills/rsp-shape/SKILL.md

@@ -4,14 +4,14 @@ description: Shape or rigorously challenge unclear non-trivial work into one exe
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.28.1"
+  version: "2026.08.05.1"
 ---
 
 # RSP Shape
 
 Do not implement the shaped work.
 
-Follow Core's response-versus-artifact language boundary.
+Follow Core's response-versus-artifact language boundary for all user-visible control narration; when the response language differs, keep exact canonical values only as secondary parenthesized or code-formatted tokens.
 
 ## Establish the boundary
 
@@ -21,12 +21,14 @@ A request to shape, create, or refine a Change grants artifact authority unless
 
 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.
+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 WorkOwner 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 changing behavior, data, interfaces, compatibility, safety, ownership, migration, or acceptance. Write only authorized answers.
 
+Shape owns two transient questioning modes. Ordinary clarification asks one to three related material questions, while explicit deep clarification asks exactly one DecisionOwner question per turn. A Core or Manage `StopDisposition: return-to-shape` may enter either mode, but Shape resumes execution only by returning a ready WorkOwner to Core for fresh route derivation; it never resumes Manage directly.
+
 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.
 
 Read [external issue input](references/external-issue-input.md) only when a Change declares an issue relationship or the request asks to shape from an issue URL.
@@ -37,6 +39,8 @@ Never invent a product decision. When a material choice or mutation authority re
 
 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.
 
+When Shape must establish a new WorkRef, preserve an explicit valid user-supplied identity through canonical normalization. Otherwise follow an explicit nearest project or domain WorkRef naming convention. If neither exists, infer ASCII lowercase kebab-case from stable domain or technical vocabulary. Artifact, commit, response, host locale, and TUI language settings never select or translate WorkRef language. Safe Unicode remains available through explicit input or project/domain convention; never rename an existing open or archived identity because language or naming guidance changes.
+
 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.
 
 Keep one observable outcome per Change:
@@ -50,7 +54,7 @@ Keep one observable outcome per Change:
 
 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 in the response. Before archive, retain final decisive verification, gaps, and risks.
+A Change is a convergent current-plan and 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 agents only as real product actors or constraints, not authors or execution narrators.
 
@@ -67,3 +71,9 @@ A Change is ready only when:
 - one Change or a justified shallow Group is the smallest sufficient owner.
 
 After mutation, run the focused RSP check. Return WorkRef, artifacts, validation, and next action or blocker.
+
+When the gate passes, return a `ControlOutcome` for phase Shape with the ready `WorkOwner` WorkRef, decisive readiness evidence, `NextOwner: Core`, and a resume rule that Core freshly derives the route.
+
+When a material decision prevents readiness, return a non-ready `ControlOutcome` for phase Shape with `StopDisposition: ask-owner`, the decisive evidence, the `DecisionOwner`, the required answer, and a resume rule that reruns Shape from fresh evidence after the answer.
+
+For any other blocker, return a non-ready Shape `ControlOutcome` with the applicable canonical `StopDisposition`, decisive evidence, `NextOwner`, required input, and resume rule. Do not relabel unresolved fog as ready work.

package/skills/rsp-shape/references/deep-clarification.md

@@ -24,6 +24,8 @@ Ask exactly one owner decision per turn. Include a recommended answer grounded i
 
 When no material dependent decision remains, summarize the resulting behavior, boundaries, and acceptance contract, then ask the owner to confirm shared understanding. Keep all artifacts unchanged until that confirmation. After confirmation, write only authorized decisions into their existing RSP owners and reapply the Shape Ready gate.
 
+This branch fulfills `StopDisposition: return-to-shape`; it does not resume the prior execution path itself. Only after shared understanding is confirmed and the Shape Ready gate passes may Shape return the ready `WorkOwner` to Core, which freshly rederives the route.
+
 ## Completion criterion
 
 Finish the deep branch when every material dependent decision is either owner-confirmed or recorded as one explicit blocker, the project design task has returned to the same WorkRef when used, and no artifact changed before shared understanding was confirmed.

package/skills/rsp-structural-audit/SKILL.md

@@ -37,7 +37,7 @@ Do not infer a finding from directory names, pattern matching, code size, framew
 
 ## Output
 
-Render headings, field labels, explanations, and conclusions in the language explicitly requested by the user; otherwise follow nearest project instructions, then the conversation language. Treat the shape below as semantic field order rather than fixed English wording, while preserving paths, severity labels, confidence values, and the result values `findings`, `clean`, and `scoped uncertainty`.
+Render headings, field labels, explanations, and conclusions in the language explicitly requested by the user; otherwise follow nearest project instructions, then the conversation language. Treat the shape below as semantic field order rather than fixed English wording, while preserving paths, severity labels, confidence values, and the result values `findings`, `clean`, and `scoped uncertainty`; when their language differs from the response, retain those values only as secondary exact tokens beside localized narration.
 
 Return findings ranked by material impact, then confidence. Emit at most five and use this shape:
 

package/skills/rsp-tdd/SKILL.md

@@ -4,19 +4,25 @@ description: Drive one clear testable behavior owned by a selected RSP Change th
 license: MIT
 metadata:
   author: oevery
-  version: "2026.07.24.1"
+  version: "2026.08.17.1"
 ---
 
 # RSP TDD
 
-Implement one clear behavior test-first, follow Core's response-versus-artifact language boundary, and return evidence to its selected Change.
+Implement one clear behavior test-first and return evidence to its selected Change. Follow Core's response-versus-artifact language boundary for all user-visible control narration; when the response language differs, keep exact canonical values only as secondary parenthesized or code-formatted tokens.
 
 ## Establish the cycle
 
-Require one selected, ready Change, clear observable behavior, test and production mutation authority, and an executable focused check. Read project authority, current worktree state, and the smallest owning production/test seam.
+Require one selected, ready Change, clear observable behavior, test and production mutation authority, and an executable focused check. Read project authority, current worktree state, and the smallest owning production and test seam.
 
 Stop when behavior or acceptance is unclear, mutation authority is missing, an existing symptom has an unexplained cause, the execution environment is unavailable, or a baseline failure cannot be separated. Return the same Change, evidence, and one needed next action.
 
+## Admit the behavior and test seam
+
+Before RED, confirm that the selected Change, Spec, or project authority owns the observable behavior and that a real production path can reach the proposed seam. Name the consequence, one distinct plausible regression, why existing evidence misses it, and the expected maintenance cost. A test cannot create product authority; an imagined edge state, test-only consumer, wrapper hop, or source-string convention is not sufficient by itself.
+
+If the proposed test would require a new public contract, fallback, compatibility path, or handling for a state the production producer cannot emit, stop for the owning decision instead of encoding the assumption as RED. Explicit user, Change, or project test requirements remain authoritative.
+
 ## RED
 
 Add the smallest focused test at the real owning seam. Run it before production mutation and observe the expected missing or incorrect behavior.
@@ -27,6 +33,8 @@ RED is not a syntax, fixture, environment, or unrelated baseline failure. A pass
 
 Make the minimum production change for GREEN, preserve scope, and rerun the same command. An unexplained failure returns to diagnosis without speculative widening.
 
+Do not widen the product contract merely to satisfy the test. If GREEN requires an unauthorized API, fallback, compatibility behavior, test-only hook, or unreachable-state branch, treat the test premise as invalid or return the missing owner decision; do not mutate production first and rationalize the contract afterward.
+
 ## REFACTOR
 
 Refactor only after GREEN for a concrete local improvement; rerun the focused check. Otherwise skip it.

package/skills/rsp-verify/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: rsp-verify
+description: Verify one selected RSP Change against its declared evidence boundary without mutating product or workflow state.
+license: MIT
+metadata:
+  author: oevery
+  version: "2026.08.21.1"
+---
+
+# RSP Verify
+
+Run one bounded, read-only verification pass for an existing RSP WorkRef. Verify owns evidence collection and the verification result; it is a Discipline, not a router, controller, lifecycle owner, reviewer, or Git delivery capability.
+
+## Require a declared boundary
+
+Require one explicit WorkRef or one unambiguous focus marker, the selected Change or Group context, its declared `Verify` boundary, the comparison baseline, and the authority to run the named checks. Stop when the owner, scope, baseline, required evidence, or environment is ambiguous. A Group Brief is context only; verify the selected executable child or the explicitly named integration boundary.
+
+Read the nearest project instructions, Core or fallback, selected Change and Brief, relevant Specs and Decisions, current diff, blockers, and the smallest production path needed to understand the declared check. Do not invent checks from generic testability or replace an unexplained failure with a guessed assertion; route that case to `rsp-diagnose`.
+
+## Preserve read-only authority
+
+Do not edit product files, Changes, Specs, Decisions, focus markers, archives, configuration, or Git state. Do not start publication, deployment, approval, or human-acceptance actions. Running a declared local test, build, typecheck, lint, browser check, or other environment check is evidence collection only and retains the authority required by that command.
+
+Reuse the invoking Core or Manage contract. Core owns the single outer `ControlOutcome`, route, and continuation; Manage owns execution mode, delegation, result validation, acceptance, lifecycle closeout, and commit eligibility. Verify's canonical result is nested phase evidence, not a peer outer status. Verify does not select worker identity or isolation, derive `review-clean`, or claim `archiveReady`; any identity or independence evidence comes from the host.
+
+## Return one bounded result
+
+Return exactly one canonical result:
+
+- `pass`: every named required check passed within the declared boundary.
+- `fail`: at least one named required check failed.
+- `unavailable`: a required tool, dependency, service, credential, or environment could not be used.
+
+Every result includes `evidence_delta: new | none` to state independently whether the pass, failure, or unavailability produced evidence that changes the next diagnosis or correction. It also includes `boundary: unchanged | changed` to state independently whether the observed owner, paths, baseline, behavior, interface, scope, or authority still matches the declared boundary. Include the WorkRef, lane objective, effective authority, named checks, comparison baseline, observed diff boundary, decisive evidence, omissions, and stop boundary. Preserve exact result and field values as machine-facing values; human-facing narration follows the invoking response-language contract.
+
+`pass` proves only the declared verification boundary. It does not prove semantic review, durable writeback, archive readiness, commit eligibility, publication, deployment, approval, or human acceptance, and it does not grant lifecycle, Git, publication, or acceptance authority. Verify never self-reports worker identity or independence; Manage uses host observations when that distinction is required. Long-running verification remains active while its declared boundary and stop conditions hold; elapsed time, heartbeat, polling, and progress messages do not change the result.
+
+## Stop and return
+
+Stop with the invoking contract's canonical stop reason when evidence is missing, the environment is unavailable, the boundary changes, or a required check cannot be observed. On cancellation, do not begin conflicting work until the command or owned process is observed stopped. Return to Core or Manage with the result, decisive evidence, omissions, and the next owner; never turn an unavailable check into success and never retry without new evidence and safe replay inside the declared boundary.