@oevery/rsp 3.3.0 → 4.0.0

package/skills/rsp-commit/SKILL.md

@@ -1,63 +1,108 @@
 ---
 name: rsp-commit
-description: Create one authorized, exact-scope local commit for a Core- or Manage-derived direct, Change, Group, or release boundary with a repository-consistent structured message.
+description: Inspect or create one authorized exact-scope local commit for direct, Change, integration, Group or release delivery. Preserve unrelated work; do not infer lifecycle, remote delivery or history-rewrite authority.
 license: MIT
 metadata:
   author: oevery
-  version: "2026.08.17.1"
+  version: "2026.10.16.1"
 ---
 
 # RSP Commit
 
-Create one reviewable local commit after Core or qualified Manage has already derived one transient Commit envelope. Skill availability grants none of its facts. The envelope contains exactly one owner variant, exact allowed paths, fresh decisive verification, current commit authority, and lifecycle evidence only when the owner variant requires it.
+For tracked work, read the [shared work model](../rsp/references/work-model.md) when its identity and ownership definitions are missing from the current context. Use logical WorkRefs in commands and reports; cite file locations separately. Direct invocation needs no prior Core execution.
 
-Accept exactly one owner variant:
+Own exact local Git delivery, invoked directly or through Core. This default core capability grants no authority through availability. Readiness-only work stays read-only. Commit only with current local authority, one exact owned boundary and applicable passing verification.
 
-| Owner | Required identity and evidence | RSP metadata |
+Responses follow explicit instruction, personal instructions, then conversation language; existing artifacts retain theirs. Commit prose follows explicit commit-language instruction, effective configuration, nearest repository authority, then clear recent non-merge style. Response language does not select it. Preserve commands, identifiers, Conventional types/scopes and trailers.
+
+Resolve needed RSP defaults/inheritance through the selected CLI's successful `rsp config --json`, refreshing on drift or recovery. Raw YAML is diagnostic only. Projection failure leaves dependent language unresolved before staging; history cannot replace it, while independent authorized inspection may continue. Resolve material conflicts with the owner.
+
+## Establish the delivery boundary
+
+Resolve the smallest request: kind, purpose, owner or summary, real included WorkRefs when relevant, exact paths, current local authority, applicable verification pointers and lifecycle evidence only when applicable. Derive these facts from direct user intent or Core's bounded handoff; do not require a transport schema or create a second source of truth.
+
+| Kind | Identity and applicable evidence | RSP trailers |
 | --- | --- | --- |
-| `direct` | a concise owner summary for one confirmed direct Tiny/Small boundary | none |
-| `change` | one real WorkRef and its applicable checkpoint or lifecycle evidence | `RSP-WorkRef` |
-| `group` | one integration-coupled wave or Group closeout, its Group ref, included WorkRefs, and applicable lifecycle evidence | `RSP-Group` and included `RSP-WorkRef` values |
-| `release` | one confirmed release identity and release-boundary evidence | only real included WorkRefs, when supplied |
+| direct | One confirmed direct outcome permitted by project tracking rules | none |
+| change | One real WorkRef | RSP-WorkRef |
+| integration | At least two real WorkRefs and one evidenced shared delivery boundary | included RSP-WorkRef values |
+| group | Group reference, included WorkRefs and one wave or closeout boundary | RSP-Group and included RSP-WorkRef values |
+| release | Confirmed release identity and release-boundary evidence | only real included WorkRefs |
 
-A direct owner is a transient Git delivery boundary, not a durable RSP WorkOwner. Never require it to create a Change, invent a WorkRef, or supply lifecycle evidence.
+A durable owner is a Change WorkRef or Group reference; included children never replace it. Direct, integration and release may have no durable WorkOwner. Integration creates no Group, direct creates no Change, and commit count is independent from Change count.
 
-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.
+Purpose is separate from kind:
 
-## Audit the envelope
+- A checkpoint keeps the Change open and delivers a verified current slice without claiming completed acceptance, closing an issue or requiring archive.
+- A terminal delivery claims completion only for its selected boundary. Tracked terminal inputs require complete Tasks, decisive Required Verify and no active blocker; legacy unclassified Verify is Required. Optional omissions remain explicit but do not block. Direct work uses its own acceptance, not an invented lifecycle gate.
 
-Read nearest project authority and the selected owner evidence: the supplied direct outcome summary, relevant open Change, Group Brief and children, archive, or confirmed release boundary. Then inspect `git status`, staged, unstaged, and untracked paths, the cached diff, and recent non-merge commit messages. Recheck supplied verification and any applicable lifecycle facts against current repository state. For a terminal Change or Group child, inspect its open or archived Verify section and stop before staging when a Task or Required Verify item remains incomplete or a blocker remains active. Legacy unclassified Verify items are Required. Optional coverage warnings do not block a terminal commit, but include a material omission in the commit body when it affects review. A checkpoint commit remains explicitly non-terminal and does not claim completed acceptance.
+A generic commit request is a checkpoint unless final delivery is already established. For tracked final delivery, resolve the closure decision through [Core closeout](../rsp/references/closeout.md) before staging, including direct invocation; do not repeat an already settled decision. Commit pauses for its owning capability to perform necessary writing or authorized lifecycle work. Lifecycle authority stays upstream. If terminal delivery includes authorized archive or Group closeout, require that action and its inspected diff before staging. Do not archive, update Specs or clean up a Change inside Commit. A valid explicitly authorized local commit without lifecycle authority does not gain it or require an invented archive.
 
-Stop without staging when the owner variant, its required identity, allowed paths, commit authority, verification, applicable lifecycle evidence, or logical boundary is missing, ambiguous, stale, or conflicts with unrelated work. A missing WorkRef or lifecycle state is not a defect for a valid direct owner. Refuse an active merge, cherry-pick, revert, rebase, mail-apply, or sequencer operation before commit execution. Stop when an allowed path contains mixed owned and unrelated changes that cannot be staged without guessing. Never infer archive, Group closeout, commit, cross-branch integration, push, tag, publication, approval, amend, rebase, force-push, or history-rewrite authority.
+## Audit before staging
 
-## Derive the message
+Read nearest authority and the selected current owner, plus the relevant Brief/children or archive when needed. Inspect status, the complete staged, unstaged and untracked boundary, cached diff and recent non-merge messages. Reread decisive verification and applicable lifecycle facts; copied handoff prose is insufficient.
 
-Choose subject and body prose language from explicit current commit-language instruction, then the configured effective commit language, nearest repository commit authority, and finally the clear style of recent non-merge commits. Response language and preferences remembered from another repository do not select it. Preserve Conventional Commit types/scopes and trailers as technical values. When recent history is materially mixed and no nearer rule resolves it, return the single language decision to its owner.
+Reuse traceable passing results while relevant content, dependencies, configuration, tools, inputs and environment still apply. Run only authorized missing or invalidated checks with settled scope and method, or explicitly required executions; entering Commit alone requires no rerun. Failed or unavailable required evidence stops delivery.
 
-Use the repository's established Conventional Commit form when present. Derive type and scope from the owned outcome and repository history, not from the conversation. Keep the subject concise and imperative or otherwise repository-consistent.
+Stop without changing the index on missing or ambiguous authority, stale evidence, an invalid kind/purpose, unrelated staged work, mixed ownership that cannot be separated without guessing, or active merge, cherry-pick, revert, rebase, mail-apply or sequencer state. Preserve pre-existing owned partial staging unless the exact additional content is authorized. Never broaden paths, unstage unrelated work or reset the index to make a boundary fit.
 
-Describe the accepted diff as a reader who did not see the working session. Omit rejected session-only alternatives, corrections, and temporary attempts that never entered the authoritative baseline. Such an alternative is not an omission: do not name or paraphrase it as a `without X`, `did not add X`, or `did not use X` compliance claim. Name a removal, exclusion, failed external action, compatibility boundary, migration, safety rule, audit fact, or requested comparison when it is a real owned change or material review fact.
+Before reporting eligibility, confirm verification covers the exact proposed content. Matching filenames or a working-tree pass containing excluded changes is insufficient. For a staged slice, compare evidence with the current index. Check excluded code, configuration, fixtures and generated inputs for invalidation. Obtain missing evidence within authority or report the gap; preserve unrelated work.
 
-A tiny, mechanical, or direct `Tiny` or `Small` boundary may be subject-only when that subject fully explains it. For a non-trivial Change, integration wave, Group closeout, or release commit, add two to four concise bullets covering:
+Before dependent `git add` or `git commit`, run required audits and preparation as separately observed commands by default. If batching, explicitly gate each dependent write on all its prerequisites succeeding; shell newlines and the batch's final exit code do not provide that gate. A failed or unavailable prerequisite blocks its dependent write. Inspect actual index/worktree effects before permitted recovery; later success does not erase an earlier write after failure. Commit's one-attempt rule still applies.
 
-- the observable outcome;
-- material behavior or compatibility boundaries; and
-- an important omission or risk when one affects review.
+For readiness-only work, report eligibility, gaps and the next owner here; do not stage, prepare files or commit.
 
-Do not copy file lists, command transcripts, routine verification output, execution chronology, or the full Change or archive. Project trailers from the selected owner variant: add one `RSP-WorkRef:` per real included WorkRef and `RSP-Group:` only when the Group is the owner. A direct or release owner with no included WorkRefs emits no RSP trailer. Add authoritative external references already owned by the work and `BREAKING CHANGE:` only for an actual breaking change. Never invent a WorkRef, Group, issue, co-author, sign-off, breaking change, or AI attribution.
+## Review the final index and message
 
-Project every owned issue relationship as a non-closing `Issue: <canonical-url>` reference when proportionate. Only a terminal commit whose selected Change acceptance is complete may additionally use a provider-supported closing keyword for an explicit `relation: closes`. Checkpoints, `relation: relates`, ambiguous Change or Group ownership, and unresolved provider or repository identity emit no closing keyword. When safe shorthand cannot be resolved, keep only the canonical URL; never infer an issue from changed files or mutate the external tracker.
+1. Stage only the authorized content with exact path handling. Reread status, complete cached paths and diff, including sensitive material, and prove one reviewable logical boundary. Stop if it does not match; do not repair unrelated staging.
+2. Confirm the final index matches the content covered by the audited evidence. If staging changed that boundary, reassess applicability and fill only missing or invalidated coverage before proceeding; unchanged applicable results need no rerun. Record the reviewed HEAD (or unborn state) and index tree. These bind content, file modes and deletions, not only names; keep them transient.
+3. Derive the message from that final cached diff, not conversation chronology or a copied Change. Follow applicable project message rules and checks, using the established Conventional form when present and a concise repository-consistent subject. When the project permits and the subject is sufficient, omit the body; otherwise add only the rationale, behavior differences, compatibility or risk needed by a reader without the session.
+4. Load [message and references](references/message.md) for tracked, integration, Group, release, issue-related or non-trivial messages. Keep real removals, migration constraints and important omissions; omit session-only attempts, file inventories and routine command output. A supplied prepared message must still match the reviewed boundary; do not edit it when nearer authority forbids editing.
+5. Prepare actual multiline text, preferably outside the worktree or at an explicitly allowed path. Never use literal backslash-n as a newline transport or include a temporary message file in delivery. Legitimate escape notation in prose stays literal; do not decode it or reject it merely for containing backslash-n.
 
-## Commit the exact boundary
+## Execute once and observe
 
-Stage only the explicit allowed paths. Re-read `git status --short`, inspect the complete cached path list and cached diff, and confirm they represent exactly one owner boundary with no sensitive material. If the cached boundary is wrong, stop and leave unrelated work untouched; do not repair it by broad staging, destructive reset, or history rewrite.
+Use native Git inside this capability; no RSP commit wrapper or generated delivery
+script is required. Missing Commit capability has no Core substitute. Respect a
+nearer required method or denial; an incompatible requirement needs an owner
+decision, not a trial commit or automatic fallback.
 
-Transport a structured multiline message with actual line breaks or a safely prepared message file. Do not rely on ordinary quoted `\n` escape sequences as portable newlines; a host shell may pass those characters through literally.
+1. Inspect operation state through `git rev-parse --git-path` for MERGE_HEAD,
+   CHERRY_PICK_HEAD, REVERT_HEAD, rebase-merge, rebase-apply and sequencer. Any
+   active operation or incomplete inspection stops ordinary delivery. Resolve
+   paths through Git, not a presumed .git directory, so worktrees are covered.
+2. Read HEAD with `git --no-replace-objects rev-parse --verify 'HEAD^{commit}'`.
+   A failed read is not automatically unborn: require `git symbolic-ref -q HEAD`
+   to name refs/heads/... and `git show-ref --verify --quiet <that-ref>` to confirm
+   absence (exit 1). Other errors stop. Immediately before execution, recheck this
+   HEAD/unborn state and `git write-tree` against the reviewed snapshot. A caller's
+   fixed snapshot cannot be replaced on its behalf. Drift stops without index repair.
+3. Attempt exactly once: `git commit --cleanup=verbatim -F <message-file>`, replacing
+   the placeholder with the safely prepared, quoted path. Preserve normal hooks
+   and signing policy; do not disable either to obtain success. Snapshot checks
+   are sequential observations, not a cross-process lock.
+4. Read resulting HEAD, then inspect that immutable SHA using
+   `git --no-replace-objects cat-file commit <sha>` for the raw message, tree and
+   parents, and `git --no-replace-objects diff-tree --root --no-commit-id --name-only --no-renames -r -z <sha>`
+   for actual paths. Use NUL-delimited path observations before and after delivery;
+   do not split unusual filenames on whitespace or treat display quoting as identity.
+5. Require the committed tree and paths to match the reviewed index, one parent
+   equal to reviewed HEAD (no parents for unborn), and the complete stored message
+   to match the prepared text with at most one terminal LF difference. Recheck
+   final HEAD still identifies that SHA and inspect remaining staged, unstaged
+   and untracked work against the prior boundary. Obtain committed facts from the
+   immutable object, not several movable HEAD reads.
 
-When the packaged CLI is available, use `rsp commit --message-file <path> [--json]` for the exact local execution step. The command reads the prepared message file, rejects unintended literal `\n` sequences, and invokes `git commit --cleanup=verbatim -F -` through Node's direct child-process API. It operates only on the existing staged boundary; it never stages paths itself.
+Post-commit verification inspects these Git results and hook effects, not routine repetition of product tests. If hooks changed relevant inputs, report which evidence no longer applies; delivery remains stopped on mismatch or uncertain effects.
 
-Create one local commit with the prepared subject, optional body, and trailers. Do not cherry-pick, clean another checkout, push, tag, publish, amend, rebase, or force-push. Afterward observe exact before and after `HEAD`, the raw complete committed message, committed paths, remaining worktree paths, and remote refs when required. Confirm that committed paths equal the reviewed staged boundary. Compare the observed stored message with the prepared message exactly, allowing only one terminal LF difference in either direction for Git's message-file boundary. A successful commit is still a post-commit mismatch when either paths or message differ; report the complete observed receipt and stop without inferring amend or second-commit authority. If the command is unavailable, use a safely prepared message file with a direct non-shell Git invocation and retain the same preflight and post-commit checks.
+Exit zero alone is not exact delivery. After any failure, observe HEAD and actual
+index/worktree effects before classifying the result. Distinguish refusal before
+execution, Git failure with observed unchanged HEAD, created-commit mismatch and
+incomplete observation. Even unchanged HEAD cannot rule out hook side effects.
+An attempted commit or uncertain effects stops delivery without retry, amend,
+reset, rollback or a repair commit. Preserve the observed state and report gaps;
+never claim successful delivery when required observations fail or disagree.
 
-## Return the receipt
+## Return the result
 
-Return before and after `HEAD`, the commit SHA, owner kind and identity, included WorkRefs when present, the complete stored message with parsed subject/body/trailers, committed paths, remaining worktree paths, and explicit omissions. Report a stop before staging, commit failure, receipt-observation failure, or post-commit path or message mismatch truthfully; never silently amend or create a second commit to repair the first. An available Commit Skill that rejects an invalid envelope returns that stop; manual fallback is only for capability unavailability.
+Concisely report kind and purpose, owner or refs when relevant, commit SHA when observed, delivered paths and message subject; include remaining work and material omissions when present. Retain the complete message and content/history observations as evidence; expand them when requested or needed to explain a mismatch, not as routine output. For a stop, name the missing condition, observed Git effects and safe next action. No stage grants push, tag, publication, deployment, approval, cross-branch integration or history rewrite.

package/skills/rsp-commit/references/message.md

@@ -0,0 +1,34 @@
+# Message and owned references
+
+Load for tracked, integration, Group, release, issue-related or non-trivial messages after the final cached boundary is reviewed.
+
+## Project contract and subject
+
+Read applicable project instructions, message conventions and configured checks. Recent relevant commits supplement explicit rules, never override them. RSP does not require adopting Conventional Commits; where adopted, distinguish its syntax from stricter project requirements. Report conflicts with required checks instead of bypassing them. Preserve the entrypoint's commit-language precedence.
+
+Derive type from the accepted change and scope from a stable domain or module, not session activities or path inventories. Summarize one reviewable outcome. If the message exposes unrelated outcomes, return to the delivery-boundary check; do not silently split or broaden the authorized commit.
+
+## Body by information need
+
+When project rules permit, omit the body if the subject suffices and no material rationale, compatibility, migration or risk needs explanation. File count and change type alone do not determine that need. Otherwise explain only what a reader without the session needs: the problem and motivation, important old/new behavior differences, consequential tradeoffs or limitations.
+
+For Conventional messages, separate the body from the subject with a blank line. Use prose for causes/tradeoffs, lists for independent points or both as needed. Do not require a bullet list, Why/What/Testing template or prose-plus-list sequence. Omit padding and subject repetition.
+
+Keep real removals, migration constraints and important omissions. Do not copy the Change, execution chronology, routine checks or full path lists. Omit session-only attempts; retain a consequential reason for rejecting an alternative or accepting a tradeoff only when it explains the final design. A decisive measurement or verification limitation may matter, but command success must not imply broader acceptance.
+
+Follow project length and wrapping checks without inventing universal 50/72-character limits. Otherwise wrap for readability without breaking URLs, identifiers, commands or natural Chinese text. If an exact required reference conflicts with a hard check, report the conflict rather than truncating it or bypassing the check.
+
+## Owned footers
+
+Body freedom does not remove footer syntax. Keep footers separated by a blank line from the body, or from the subject when the body is absent. Emit ownership trailers as standalone fields, not body-list items; a necessary footer does not require a filler body. For Conventional breaking changes, use `!` or a `BREAKING CHANGE` footer as permitted, requiring both only when the project does. Explain the affected contract and migration needs proportionately; use the footer's exact token and syntax when present.
+
+Project trailers from real ownership:
+
+- Add one RSP-WorkRef per included Change.
+- Add RSP-Group only when a Group is the durable owner; integration alone emits none.
+- Direct and release without real included WorkRefs emit no RSP trailer.
+- Keep authoritative external references already owned by the work. Use BREAKING CHANGE only for a real breaking contract.
+
+Never invent a WorkRef, Group, issue, co-author, sign-off, breaking change or AI attribution.
+
+Represent owned issue relationships with a proportionate non-closing Issue reference. A terminal delivery with complete selected Change acceptance may additionally use the provider-supported closing keyword only for an explicit closes relation. Checkpoints, relates, ambiguous ownership or unresolved provider/repository identity emit no closing keyword. If shorthand cannot be resolved safely, retain only the canonical URL; do not infer issues from files or mutate the tracker.

package/skills/rsp-doc/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: rsp-doc
+description: Write or revise repository documents, Skills and release communication, including final Change convergence and knowledge writeback. Own writing and author self-checks, not product planning, formal read-only review or publication.
+license: MIT
+metadata:
+  author: oevery
+  version: "2026.10.15.1"
+---
+
+# RSP Doc
+
+For tracked work, read the [shared work model](../rsp/references/work-model.md) when its identity and ownership definitions are missing from the current context. Use logical WorkRefs in commands and reports; cite file locations separately. Direct invocation needs no prior Core execution.
+
+Write a grounded artifact usable without the author conversation. Use the artifact method for whole-record reconciliation, inspect final consistency and retain already-converged text. Local wording fixes and mechanical status/evidence updates need no full writing pass unless the whole record needs reconciliation. A no-op decision needs no new artifact or routine report field.
+
+## Produce the artifact
+
+1. **Fix the outcome.** Identify the reader, task, authorized files and expected result. For a document set, distinguish authoritative owners from summaries. Keep routine narration in conversation and retained evidence with its existing owner.
+2. **Establish the facts.** Read existing content, relevant callers and the smallest authoritative contract, code or source chain. Check commands, defaults, links and behavior with available tools. Distinguish current behavior, intended requirements and unknowns. Resolve material contradictions before rewriting a promise. Interpret tool output as evidence; it grants no permission and does not prove semantic correctness.
+3. **Draft for the task.** Apply the expression rules below and load only the relevant method:
+   - [Artifact lenses](references/artifact-lenses.md): README, CONTEXT, Spec, Change, guides and scoped operating documents.
+   - [Skill authoring](references/skill-authoring.md): Skill creation or revision, including descriptions, package resources and invocation policy.
+   - [Release communication](references/release-communication.md): changelogs, release notes, migration guidance or authorized release-document reconciliation; not ordinary document writing.
+4. **Verify the result.** Check the edited meaning in context. For structural edits, also follow the affected reading path and references. Use the checks below; reuse traceable unchanged mechanical results. Writing completion does not automatically trigger Review, but separately requested or required judgment remains binding.
+
+## Check facts and reading paths
+
+Use the checks relevant to the change:
+
+- Check whether readers can find information, understand conditions, act or judge compliance, and recognize unknowns.
+- Check affected links, anchors, examples and metadata with existing tools. Execute examples only within safe authorized scope.
+- For linked artifacts, compare shared claims, terminology, defaults and handoffs against their authoritative owner. Correct authorized summaries and links without copying full definitions or changing unassigned owners. Report out-of-scope contradictions to their owner.
+- Recheck facts, quantifiers, defaults, failures, permissions and terminology after editing. Report actual checks and remaining gaps.
+- API comments and embedded guidance: compare claims with their contract and implementation without assuming either side correct. Keep ordinary inline comments locally accurate and useful: retain constraints, rationale or usage that nearby code does not make clear, and remove restatement that adds no information; no full writing workflow is needed. Compiler/tool annotations retain implementation ownership.
+- Examples: label illustrative pseudocode or incomplete snippets; check copyable commands against real prerequisites, outcomes and safe use without inferring execution or installation authority.
+
+For agent-facing instructions, trace the relevant branch and its targets. Distinguish local reading-path reasoning from actual agent execution and required independent evidence; retain background human co-readers need.
+
+For a failed command, inspect cause and actual effects before recovery. Change a permitted read/search or repeat-safe check method only within unchanged goal, scope, authority, baseline and required evidence. Named checks and protected RSP operations retain their methods/owners; unavailable Required evidence, unknown mutation or unsafe replay stops affected work.
+
+## Resolve language
+
+- Response: explicit request → personal instructions → conversation language.
+- Existing files: preserve language unless the user asks to change it.
+- New files: explicit artifact language → effective configuration → scoped instructions → conversation language. Resolve needed RSP defaults/inheritance through the selected CLI's successful `rsp config --json`; refresh on relevant drift or recovery. Raw YAML is diagnostic only. Failed projection leaves dependent choices unresolved, not replaced by lower precedence; independent authorized work may continue. Other projects retain their configuration readers.
+- Keep canonical identifiers, machine values and required headings exact.
+
+## Write precisely
+
+- Organize around the reader's task: operations need actions and success signals; contracts need guarantees and exceptions; design needs reasons and tradeoffs. Explain unfamiliar concepts through their task-relevant meaning; include mechanisms needed to reason, troubleshoot or assess guarantees. Reference entries need no forced tutorial. Do not force every artifact into an action list or closing next step.
+- State the actor, action and object directly. Prefer short, complete sentences when easier to follow. Separate independent actions; preserve causal and conditional links. Give each paragraph one useful purpose. Put prerequisites before use, conditions beside actions and exceptions beside their rules. Keep necessary local context; link branch-only detail with its reading condition and purpose.
+- Number steps when their order matters; make each step a bounded action. Use peer bullets for independent items and connected prose for reasoning. Use tables for useful fixed mappings/comparisons, not branching Skill judgments.
+- Remove empty introductions, rhetorical framing, repeated conclusions, filler and irrelevant chronology. Keep author voice, decision-relevant explanations, necessary reasoning and required audit evidence. Replace abstract aspirations with concrete actions. For prescriptive rules, use contrasts or counterexamples only to resolve likely ambiguity. Retain explanatory comparisons needed for understanding, decisions or migration; merge equivalent examples. No fixed sentence length, list size or compression ratio defines quality.
+- Preserve negation, conditions, exceptions, permissions, quantities, units and certainty. Merge failure explanations with the same decision effect. Retain permission, outcome, stop and safe-recovery conditions, including rare boundaries preventing unauthorized action, serious harm or unsafe replay. Keep incident details with their evidence owner. Do not turn a proposal or unknown into a verified fact. Shorter wording proves no behavioral equivalence.
+- Wording edits preserve meaning, information ownership, heading anchors and technical literals: code blocks, commands, paths, identifiers, links, versions and numeric values. Structural edits may merge, move or reorder content within scope while preserving completeness and references. Behavior changes and technical corrections need their own scope and checks; shortening prose grants neither.
+- Use ordinary words for conjunctions. Preserve technical syntax; reserve | for closed alternatives, / for established pairs, → for defined transitions and : for label/value boundaries.
+
+## Preserve ownership
+
+- Follow nearest project instructions and the authorized file boundary. Keep a selected WorkRef when tracked; bounded direct work needs no automatic Change.
+- Doc owns writing and self-checks; formal fixed-scope Review remains read-only and independent when required. A combined request retains both responsibilities: Review grants no repair authority, but originally authorized corrections may continue.
+- Product decisions stay with their design owner. Release writing grants no version decision, release verification, Git delivery or external publication authority. Missing optional methods do not require installation or block an available bounded method.
+- Preserve unrelated work. Ask when a missing choice materially changes the result or authority; stop when required evidence is unavailable. Writing alone grants no installation, deployment, Git delivery or publication.
+
+Return changed artifacts, decisive checks and material limits. Tracked work retains necessary conclusions in its existing record; stable knowledge belongs to its document and retained evidence to its existing owner. Focus maintenance remains Core's responsibility.

package/skills/rsp-doc/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: RSP Doc
+  short_description: 'Write clear, grounded documents and Skills'

package/skills/rsp-doc/references/artifact-lenses.md

@@ -0,0 +1,43 @@
+# Artifact lenses
+
+Choose what the reader must understand, do or judge, not a mandatory template. Preserve project formats and canonical headings; action-first wording is useful for procedures, not a requirement for every artifact.
+
+For a document set, start with the reader's entry point and follow only the links needed for the task. Check that each handoff supplies its prerequisites and that summaries agree with the linked owner. An owner outside the authorized write set remains read-only; return its conflicting claim rather than expanding the edit boundary.
+
+## README
+
+- Help a newcomer find the starting point, prerequisites and first useful result with a recognizable success signal.
+- State important exclusions before setup. Keep a useful overview and local prerequisites; link specialized detail with its reading purpose.
+- Match the audience. A maintainer README need not become an installation tutorial.
+
+## CONTEXT
+
+- Help readers understand domain terms and relationships, then find the authoritative owner; do not duplicate that owner's full contract.
+- Keep names, useful translations and navigation near each definition. Link one authoritative definition across root and local files.
+- Explain different meanings at domain boundaries; do not silently rename them.
+
+## Spec
+
+- Enable a reader to judge compliance: state what a consumer can rely on, under which conditions, with scope, handoffs, failures and exceptions.
+- Keep normative design references and protocol detail needed to establish compliance.
+- Add a scenario only when it resolves ambiguity. Domain headings are valid; no fixed section set is required.
+- Leave future promises in the Change and verification results with their work owner.
+
+For example, “retries are safe” is incomplete when deduplication applies only to the same key. State that condition without inventing retention or failure guarantees.
+
+## Guides and references
+
+- Procedures: give prerequisites, execution context, bounded actions and success signals. Explain a likely failure when it helps the task; keep conditional branches near their triggers.
+- Concepts and design explanations: preserve definitions, causal reasoning and tradeoffs needed to understand or decide; do not replace them with a terse action checklist.
+- References: provide exact contracts and navigable details, not a forced tutorial.
+- Label illustrative snippets; do not present invented output as observed execution. Preserve incoming links after heading changes.
+- API/TSDoc comments: explain the consumer's real inputs, returns, failures and use. Compare examples and claims with their authoritative contract and implementation; report unresolved discrepancies rather than silently documenting whatever code does. Writing authority does not permit implementation changes, execution or dependency installation.
+
+## Operating instructions and work records
+
+- AGENTS: state applicable rules, commands, authority and checks. Changing rules requires explicit scope.
+- Change: retain the six canonical sections and selected delta. Proposal gives the outcome; Spec gives acceptance; Design gives the approach; Tasks state checkable work and completion, with completed items describing the accomplished result; Verify records methods, candidate-bound conclusions, limits and necessary evidence references; Blockers uses the [shared work-model syntax](../../rsp/references/work-model.md) for current impediments.
+- Work records: retain necessary plan/contract changes, outcomes, blockers and scoped verification. Keep routine narration in conversation and needed recovery state in Focus. Before archive, establish facts and justified knowledge writeback; reconcile all six sections with current outcomes, superseded plans and knowledge owners. Retain facts affecting the delivered contract, evidence applicability, important failure disposition or remaining limit. Link knowledge and evidence owners; preserve their detailed records and original verdicts. Correct stale authoritative contracts. Return substantive contradictions to their owner; prose cleanup cannot settle them.
+- Decision Record: let readers understand why a choice was made, its alternatives and consequences, without redefining the contract.
+- Audit/run records: retain required observations, actions and evidence. Remove irrelevant session narration, not the record's purpose.
+- Skill packages: use Doc's Skill-authoring branch. Release communication uses Doc's conditional release method.

package/skills/rsp-doc/references/release-communication.md

@@ -0,0 +1,39 @@
+# Release communication
+
+Load only for changelog, release-note or migration writing, including authorized reconciliation of release documents. Doc owns writing and self-checks, not release execution or independent acceptance.
+
+## Establish the release boundary
+
+Resolve the released unit, audience, evidence range, target surfaces and allowed edits. Follow nearest instructions, existing release artifacts, relevant release-tool configuration and prior published conventions. Preserve Doc's artifact-language precedence; prior releases may inform style but do not override it. Inspect only relevant non-secret settings; do not create configuration or persist preferences without authority.
+
+Confirm a version only from explicit user instruction or authoritative repository release configuration. Until confirmed, keep authorized drafts or fragments version-neutral; do not invent versioned headings, paths, exact-version commands or tag comparisons. A missing range or delivered behavior prevents factual release claims, not a bounded explanation of what evidence is needed.
+
+Use established project tools for inventories or generated drafts when useful. Inspect their effects before invoking them: generation may also commit, tag, push or publish. Tool availability and release-writing authority permit none of those actions.
+
+## Explain the net result
+
+Inspect the smallest sufficient net diff, direct public consumers, accepted fragments or work records and verification evidence. Git history and generated notes locate evidence; they are not proof of delivered behavior. Reconcile material disagreements and label historical results with their revision or date.
+
+Describe final user or operator outcomes. Omit reverted additions, fold prerelease corrections into final behavior and include housekeeping only for compatibility, packaging, security or operational effects. Omit rejected session-only proposals. Retain material removals, deprecations and known limits. Ground each claim and check meaningful omissions; add no permanent ledger or per-commit transcript.
+
+Project only the requested or existing surfaces:
+
+- **Changelog:** concise cumulative notable outcomes in the project's categories; use Added, Changed, Deprecated, Removed, Fixed and Security only as a fallback, omitting empty categories.
+- **Release notes:** lead with audience-relevant outcomes, required action, compatibility and validation limits. Use a stable public range link when available; do not invent links or duplicate the whole changelog.
+- **Migration guidance:** state affected users, old and new behavior, ordered actions, applicable compatibility window, success checks, and known rollback or support paths. Unknown operational decisions remain explicit. Keep a short note inline and use a separate guide only when needed and authorized.
+
+Breaking changes and required actions come first. Follow established formats; writing alone requires no Release Change, manifest edit, separate release commit or archive.
+
+## Check surfaces and handoff
+
+Compare claims, version, date, terminology, links and required actions across the selected surfaces and their authoritative sources. A draft may be unfinished when labelled as such; final shipped prose must remain true before and after publication. Keep pending publication, authentication, command progress and unverified live availability in the transient handoff, not shipped documents. Final comparisons use the target tag or immutable ref, not moving HEAD.
+
+When preparing final documents, name the observed candidate and fresh relevant evidence or gaps. Document consistency is not a release-ready verdict; package checks, implementation closeout and independent acceptance follow the project's declared gates and actual authority.
+
+For Core-routed work, release checks without a WorkOwner stay with Core and the project's declared checks; WorkOwner-declared verification uses Verify. These are caller responsibilities, not installed dependencies or permission for Doc to create a Change or execute a release workflow.
+
+For post-publication reconciliation, use observed tag, hosted release or registry facts only as needed. Modify only authorized mutable document surfaces; immutable shipped discrepancies need a corrective version or owner. Never move tags or rewrite published packages.
+
+Never retain passwords, tokens, device codes or authentication URLs in artifacts, command output or responses. Stop before a credential-emitting interactive step; authorized human authentication occurs in a trusted terminal and returns credential-free status.
+
+Return the range, confirmed identity or draft state, changed surfaces, checks, material omissions and decisions. State required user/operator actions and their consequences directly; links alone are insufficient. Preserve explicitly required safe command, API and version tokens exactly in the handoff. Report evidence limits and external-action status without claiming publication or approval.

package/skills/rsp-doc/references/skill-authoring.md

@@ -0,0 +1,36 @@
+# Skill authoring
+
+Use for creating or revising a Skill. Apply Doc's language, expression and authority rules; this branch adds package-specific decisions.
+
+## Establish the package
+
+- For creation, resolve the goal, inputs and observable result before choosing structure.
+- Honor an explicit destination; otherwise use project instructions and host constraints. Check for existing content before creating files.
+- For revision, inspect the authored package and its callers. Name the failure or missing capability; preserve unrelated adaptations.
+- Start with SKILL.md. Use a host initializer when useful; add resources only for a real task need.
+- Preserve existing packages and global configuration. Creation is not installation or publication.
+
+## Make discovery precise
+
+- Describe the capability and triggering intents that distinguish it from neighboring Skills. Put detailed procedures in the body, not discovery metadata; avoid promises beyond the actual capability.
+- Remove exhaustive synonyms. Add an exclusion only for a likely adjacent misroute.
+- For creation or trigger changes, select useful probes by risk: direct requests, paraphrases or nearby non-triggers. Resource-only edits do not automatically need selection probes.
+- Preserve invocation policy. Optional distribution does not mean explicit-only invocation; change policy only with user intent and verified host support.
+
+## Make execution concise
+
+- Organize the ordinary task around its goal, necessary inputs, authorized action, completion evidence and real stops. Choose headings for the task, not a universal template. Continue ordinary authorized checks. Prescribe order only for correctness, safety or contract dependencies.
+- Before adding an instruction, reuse or revise the rule already owning that decision. Merge repeated entry/step/return explanations and failure conditions with the same effect. For example, combine "read the guide" and a later "only for release notes" into "for release notes, read the guide." Add an incident-derived constraint only for a reusable contract gap, not noncompliance or tool/fixture failure alone. Preserve trigger, authority, failure and output meaning.
+- Keep shared guidance and necessary local safety context visible. Link substantial branch-only knowledge with its reading condition and purpose; ordinary tasks need no unrelated recovery or delivery detail. A short Skill needs no router or extra files. Split or merge resources only when it improves the reading path, not when it merely moves mandatory text. Honor the declared distribution boundary. RSP ships as a suite: shared concepts may reference Core resources directly; independent Skills keep their own resource closure. Never depend on a maintainer repository Spec.
+- Retain generic teaching or old model-compensation instructions only for a current task-specific need. A newer model label alone proves neither redundancy nor safe removal of a constraint.
+- Reuse tools for deterministic work; the Skill owns method selection and interpretation within its authority. Preserve named mandatory commands, provenance, independence and protected operations when replacing a tool-only method. Add a script only when repetition or fragility warrants it, and run changed helpers safely. Check incoming links before moving resources.
+
+## Check the changed risk
+
+1. Validate supported metadata, names, local links and package contents using existing tools. Do not import another host's schema.
+2. Trace the ordinary task and changed branches through completion, including standalone use, unnecessary reads/handoffs, correct restraint, erroneous stops and the final answer. Check behavior and explanation together. Use realistic task outcomes and a relevant restraint case for changed behavior; judge artifacts and effects, not exact wording or reading commands. Formal Review selects applicable Code/Document perspectives within its own fixed scope.
+3. Report structural checks separately from model execution. Explicit invocation does not prove discovery; self-checks do not prove independent review.
+
+Use isolated inputs for write tests. Paid model calls, external effects and extra workers require actual authorization.
+
+For an optimization claim, compare success and corrections alongside available token, call and time costs under comparable inputs. Otherwise leave the effect unverified.

package/skills/rsp-implement/SKILL.md

@@ -1,64 +1,95 @@
 ---
 name: rsp-implement
-description: Implement exactly one selected, ready RSP Change within explicit mutation authority. Use when the user asks to implement or fix tracked work and requires code and tests plus truthful Tasks, Blockers, and fresh verification evidence; never infer Git, publication, review, TDD, or diagnosis authority.
+description: Diagnose unexplained symptoms read-only or implement authorized bounded tasks or ready RSP Changes with ordinary own checks, risk-selected test-first work and fixed-finding correction. Not fixed-scope review or whole-document writing.
 license: MIT
 metadata:
   author: oevery
-  version: "2026.08.23.1"
+  version: "2026.10.16.2"
 ---
 
 # RSP Implement
 
-Implement one selected Change and return facts.
+For tracked work, read the [shared work model](../rsp/references/work-model.md) when its identity and ownership definitions are missing from the current context. Use logical WorkRefs in commands and reports; cite file locations separately. Direct invocation needs no prior Core execution.
 
-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.
+Implement one bounded authorized task, run minimum sufficient own checks and retain necessary tracked Change evidence. Select the mode before loading its method. Changing methods within the same authority needs no handoff. No mode grants Git, review, lifecycle, external-action or approval authority.
+
+Responses follow explicit instruction, personal instructions, then conversation language. Preserve existing artifact language and canonical identifiers, commands and values. New artifacts follow explicit instruction, effective configuration, scoped project instructions, then conversation language.
+
+Query RSP settings only for a decision depending on an unresolved value. Use the selected CLI's successful `rsp config --json` summary, including defaults and inheritance, and refresh on relevant drift or recovery. Raw YAML is diagnostic only. Projection failure blocks dependent choices, not independent authorized work; resolve material conflicts with the owner.
 
 ## Select and inspect
 
-Require an explicit WorkRef or one unambiguous focus marker. A Group Brief is context, not executable work. Stop when selection, readiness, product authority, acceptance, or required decisions are unresolved.
+Mutation requires one of:
+
+- A bounded direct task with explicit scope and acceptance; no WorkRef or RSP writeback.
+- An explicit or AI-resolved ready Change from the FocusSet, with settled acceptance and exact product authority. Multiple markers are candidates; a Group Brief is context, not executable work.
+
+Diagnosis-only investigates a bounded symptom read-only without a ready mutation owner or WorkRef. A suspected cause grants no mutation. For an authorized fix, diagnose an unexplained cause first; after confirmation continue the same request only with settled owner, scope and mutation authority.
+
+Inspect applicable instructions, the selected Change/Brief when tracked, relevant Specs and decisions, and the owning code and tests. Use supplied paths and discover missing context as needed; a dispatch summary does not replace source inspection. Operate only in the execution location supplied by the host.
 
-Read nearest instructions, Core or fallback, Change and Brief, relevant Specs and decisions, current checkout, then the smallest owning code and test chain. Use normal repository discovery; do not guess owners. Operate only in the execution location actually supplied by the host; Implement never selects or migrates execution environments.
+Select the method from the request and evidence:
+
+- **Diagnosis:** for an unexplained symptom or diagnosis-only request, load [diagnosis](references/diagnosis.md) before any fix. Diagnosis-only remains read-only and ends with cause evidence or an unresolved discriminating check.
+- **Ordinary implementation:** for a clear authorized correction, implement directly; no branch reference is needed.
+- **Test-first:** after the cause and authorized behavior are clear, load [test-first](references/test-first.md) only when explicitly required or a concrete changed risk makes pre-mutation RED safer. Testability or being a fix is insufficient.
+- **Fixed findings:** for a known review report and bounded investigation authority, load [finding-resolution](references/finding-resolution.md). Supply dispositions and one authorized correction with checks; Core owns any required cross-capability re-review loop. A report or accepted finding alone grants no mutation.
+
+These are conditional methods, not separate controllers.
 
 ## Preserve authority
 
-Identify outcome, owners, verification, and pre-existing work. Modify only Change requirements, Tasks, Verify, and Blockers. Preserve unrelated modified, staged, and untracked work. Stop when overlap would discard, guess, or rewrite pre-existing intent.
+Identify outcome, owner, verification, and pre-existing work. For tracked work, update only authorized Change sections; a direct task creates no Change, WorkRef, or RSP lifecycle state. Preserve unrelated modified, staged, and untracked work. Stop when overlap would discard, guess, or rewrite pre-existing intent.
 
-Git delivery, publication, deployment, approval, and out-of-scope deletion require separate explicit authority. For conflicts, inspect base/ours/theirs, preserve unrelated work, resolve only evidenced scope, rerun checks, and stop before staging, continuing, aborting, or committing. Verify named findings first.
+Git delivery, publication, deployment, approval, and out-of-scope deletion require separate explicit authority. For conflicts, inspect base/ours/theirs, preserve unrelated work, resolve only evidenced scope, rerun affected checks, and stop before staging, continuing, aborting, or committing. Verify named findings first.
 
 ## Admit boundaries and permanent tests
 
-Before adding a validator, fallback, defensive copy, capability, state machine, compatibility path, or public option, identify its current producer, production consumer, actual trust or lifecycle transition, and material consequence. A typed same-process value, imagined future caller, or test/document-only consumer does not establish a production boundary. Keep an explicitly required seam, but otherwise do not create one when this evidence is missing.
+Inspect existing owners and callers before adding logic. Reuse behavior and business rules that satisfy the accepted outcome. Keep each rule and its invariants with one clear owner so ordinary changes stay local. Similar code with different responsibilities may stay separate; do not force reuse through unrelated flags or speculative interfaces.
+
+Hide internal representation and coordination behind the necessary caller contract, including ordering and failures. Judge decomposition by what callers and maintainers must understand, not file size or layer count.
 
-Before creating or extending a permanent test, identify the observable consequence, one distinct plausible regression in the owning production seam, why existing evidence misses it, and the maintenance cost. Prefer an existing test, type or static check, build, or acceptance check when it already owns the risk. When the requested behavior belongs to a consumer and downstream adapters or forwarding hops already have owners and coverage, exercise the consumer through those existing seams to the observable consequence. A nearest-spy, emitted-message, shared-constant, or forwarding assertion that only re-proves the downstream hop is not sufficient, even when added to an existing test file. Do not add one test per touched file, wrapper, forwarding hop, branch, or shared constant. Multiple nearby tests remain justified when each protects an independent consequence.
+Add a validator, fallback, defensive copy, capability, state machine, compatibility path or public option only for an explicit requirement or an evidenced producer, production consumer, trust/lifecycle transition and material consequence. Typed same-process values, imagined callers and test/document-only consumers establish no production boundary.
 
-## Classify implementation evidence
+Before creating or extending a permanent test:
 
-Apply these routes in order before mutation and after failure:
+- **Value:** reuse sufficient test, type/static, build or acceptance evidence first. Otherwise identify the observable consequence, distinct plausible regression at its production seam, evidence gap and proportionate maintenance cost.
+- **Expectations and setup:** derive outcomes from the agreed contract or an independent example, not the tested computation. If fixture construction, platform behavior, fault injection or scheduling leaves the target condition uncertain, inspect the arranged state or use a targeted probe. This requires no precondition assertion or mutation run for every test.
+- **Real consequence:** use real collaborators when fast, deterministic and practical; otherwise substitute the necessary boundary while preserving the relevant behavior. Exercise consumer-owned behavior through covered downstream adapters or forwarding hops. A nearest-spy, emitted-message or forwarding assertion covering only an already-covered hop adds insufficient evidence, even in an existing test file.
+- **Assertions:** one final-message assertion can suffice for the agreed consumer outcome. Pin error details or interaction counts/order only when the contract needs them; otherwise assert outcomes and effects, including rejection.
+- **Maintenance:** keep scenario-defining inputs and assertions visible; share incidental setup for clarity rather than repetition alone. Keep nearby tests protecting independent consequences, but do not allocate tests per touched file, wrapper, hop, branch or constant.
 
-1. Unexplained failure → return `rsp-diagnose`, or Core's manual diagnosis fallback when unavailable.
-2. No unexplained failure, plus test-first explicitly required by the user, selected Change, or project instructions, or a concrete changed risk that makes pre-mutation RED materially safer → return `rsp-tdd`, or Core's manual TDD fallback when unavailable. Behavior being testable, a test being possible, or the work being a fix is not sufficient.
-3. Otherwise, sufficiently evidenced behavior, cause, and owner → continue ordinary implementation.
+## Continue within the evidence boundary
 
-Diagnosis precedes TDD. Do not invoke another Skill from inside this Skill. If evidence changes the route, stop mutation and return the next action, evidence, and same selected Change. Do not reproduce either discipline inside Implement or invoke review or delivery.
+Investigate new failures and correct in scope. For a tool-only obstacle, inspect cause/effects before a permitted repair or replacement. Continue only with safe replay and unchanged goal, owner, scope, baseline, authority and required evidence. Named checks and command-owned RSP operations retain their methods.
+
+Stop for a repeated failure without new discriminating evidence, non-convergence, changed owner/scope/acceptance/authority, unknown mutation effects, unsafe or one-shot replay, or unavailable mandatory evidence or environment. An independent reviewer or verifier required by acceptance remains a separate read-only owner and cannot be replaced by the implementer's checks.
 
 ## Implement and verify
 
-Implement the smallest complete slice. Update Tasks after outcomes exist; keep unresolved issues in Blockers.
+Implement the smallest complete slice. Update authorized Change sections only for necessary plan/contract changes, outcomes, blockers and scoped verification. Update Tasks after outcomes exist. Keep routine narration in conversation and required or tool-owned evidence with its existing owner; copy no execution history into Change or a new process record. Direct work reports outcomes without RSP artifact mutation.
 
-After final mutation, run required Change checks and narrower risk checks. Fresh verification is required, but a new test is only one evidence option; prefer the cheapest decisive existing test, static check, build, or acceptance evidence. Record command, scope, result, and omissions. Prior runs are stale; failed or unavailable verification cannot support completion. Rerun after relevant edits.
+Use `rsp-doc` for document/Skill writing and whole-Change convergence within existing authority. Local wording fixes and mechanical status/evidence updates needing no whole-record reconciliation remain direct. Without Doc, write grounded guidance and check affected examples/links locally. Author self-checks never certify independent Review.
 
-Keep a new or extended test only when it still satisfies the admission evidence, protects observable behavior or a real boundary, adds distinct future confidence, avoids duplicate or implementation-detail coverage, and has proportionate maintenance cost. Otherwise remove the disposable test, fixture, and helper before completion, then use smallest sufficient final evidence. User, Change, and project retention requirements remain authoritative.
+After final mutation, establish minimum sufficient evidence for tracked Required checks or direct-task acceptance:
 
-Before returning, reread changed comments, test names, documentation, and handoff prose from the accepted result and each surface's authoritative baseline. Build the final handoff only from the accepted Change, actual changed paths, final verification, material omissions or risks, executed external actions, and pre-existing user work that must be attributed. A rejected session-only alternative, correction, or temporary attempt is not an omission or boundary: do not name it, paraphrase it, or turn it into an unrequested `did not add` or `did not use` compliance claim.
+- Reuse traceable passing results when the tested boundary and relevant code, dependencies, configuration, tools, inputs and environment still apply. Phase changes and unrelated edits do not invalidate evidence.
+- Run missing, failed or invalidated checks and risk-justified additions, including checks affected by integration. Named checks retain their method and coverage; explicit reruns and independent execution remain binding.
+- For an unfixed method, choose the cheapest decisive existing test, static check, build or acceptance evidence; a new test is not required.
+- Match the actual target, inputs, coverage and completion to the declared check. Invocation errors or incomplete observations do not by themselves prove a product defect. Record command, tested scope, result, source and omissions, distinguishing reused evidence from new execution. Failed, unavailable or untraceable evidence cannot establish completion.
 
-Preserve a negative fact when a reader without the session needs it to understand an actual baseline removal, safety or compatibility boundary, migration, audit result, failed external action, unresolved risk, or explicitly requested comparison. Preserve required facts and pre-existing user work; never change executable behavior, public contracts, tests, snapshots, or diagnostics merely to clean wording.
+Before completion, apply the same admission criteria to retained tests. Remove disposable probes, fixtures and helpers that add no distinct future confidence unless retention is required by user, Change or project authority; establish sufficient evidence for the final retained state.
 
-Record concise fresh evidence when Change Verify owns it.
+Check changed comments, test names, documents and handoff prose against the accepted result and authoritative baseline. For comments, retain accurate information that nearby code leaves unclear, including constraints, rationale or usage; remove restatement. Omit repeated Tasks/logs and discarded session attempts, while keeping negative facts needed for removals, safety, compatibility, migration, audit, failures, unresolved risks or requested comparisons. This prose check changes no behavior, public contract, test, snapshot or diagnostic.
 
 ## Return ownership
 
-Report whether the Change is completed, partial, blocked before implementation, verification-failed, verification-unavailable, or verification-blocked. Use failed for an exercised defect; use unavailable when a missing tool, dependency, service, credential, or environment prevents execution. Use blocked only when scoped checks pass but a required gate fails solely from a confirmed pre-existing or out-of-scope baseline defect; never waive affected gates.
+Report the outcome, actual paths, verification, material limits and any external effects or pre-existing user work. State whether the selected Change or direct task is completed, partial, blocked before implementation, verification-failed, verification-unavailable, or verification-blocked:
+
+- Failed means an exercised defect.
+- Unavailable means a missing tool, dependency, service, credential or environment prevented execution.
+- Blocked applies only when scoped checks pass but a required gate fails solely from a confirmed pre-existing or out-of-scope baseline defect. Affected gates are never waived.
 
-When work remains, return `WorkRef`, `Authority`, `Current state`, `Changed artifacts`, `Fresh verification`, `Blockers`, and `Next action`. They are not durable truth; persistence requires explicit path authority.
+When work remains, report owner (WorkRef for tracked work, direct request otherwise), authority, changed artifacts, reused and new checks, blockers and next action as needed for safe continuation. A non-trivial handoff may use Core's fuller continuation; ordinary same-owner corrections need no template or new request. The response is not durable truth.
 
-Claim completion only when required Tasks and checks pass and no blocker remains. Do not claim review, archive, Git delivery, or release unless separately performed with explicit authority.
+Claim completion only when tracked required Tasks (if any) and applicable checks pass and no blocker remains. Do not claim review, archive, Git delivery, or release unless separately performed with explicit authority.