@oevery/rsp 3.2.0 → 4.0.0

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,54 +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/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.07.29.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.
 
-Read nearest instructions, Core or fallback, Change and Brief, relevant Specs and decisions, worktree, then the smallest owning code/test chain. Use normal repository discovery; do not guess owners.
+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.
+
+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 affected 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 checks, and stop before staging, continuing, aborting, or committing. Verify named findings first.
+## Admit boundaries and permanent tests
 
-## Classify implementation evidence
+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.
 
-Apply these routes in order before mutation and after failure:
+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.
 
-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.
+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.
 
-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.
+Before creating or extending a permanent test:
+
+- **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.
+
+## Continue within the evidence boundary
+
+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 test only when it protects observable behavior or a real boundary, adds distinct future confidence, avoids duplicate or implementation-detail coverage, and has proportionate maintenance cost. Otherwise remove the 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:
 
-Record concise fresh evidence when Change Verify owns it. Do not create a receipt store or mandate one shell wrapper.
+- 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.
+
+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.
+
+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.

package/skills/rsp-implement/references/diagnosis.md

@@ -0,0 +1,10 @@
+# Read-only diagnosis
+
+Load only for an unexplained, conflicting, intermittent, or multi-layer symptom, including a diagnosis-only request. A diagnosis request permits inspection and safe diagnostic commands, not edits to tests, instrumentation, fixtures, Change, or production. Those need separate exact mutation authority. A bounded symptom may be investigated without a ready Change or WorkRef. Do not silently turn diagnosis into a fix.
+
+1. Reproduce the smallest safe symptom or label supplied evidence and its limits; state expected and actual behavior.
+2. Trace the production path to the first divergence and confirm that the suspected seam is reached by a real consumer.
+3. Compare live hypotheses by distinct predictions and run the smallest safe discriminating check.
+4. Confirm only a cause explaining the symptom and excluding credible alternatives. Otherwise return unresolved with one next check or environmental blocker.
+
+Return confirmed or unresolved, evidence limits, cause and owning layer or remaining hypotheses, scope impact and next action. Diagnosis-only ends here read-only. Continue ordinary or risk-selected test-first implementation when existing fix authority covers the confirmed cause and owner. Stop for changed owner, scope, behavior, acceptance or authority. Diagnose subsequent check failures from new evidence and correct in scope. Stop when repeated attempts add no discriminating evidence or fail to converge. Write decisive facts to a tracked Change only with separate artifact authority.

package/skills/rsp-implement/references/finding-resolution.md

@@ -0,0 +1,21 @@
+# Bounded fixed-report finding resolution
+
+Load only for one fixed read-only Review report and its original comparison or file set. Inspect report identity (order, severity, title, location), current checkout, investigation authority and the smallest affected behavior chain. Read the selected Change when tracked; an authorized direct investigation needs no Change. A report alone grants no investigation, correction, fresh external checks or Git authority. Preserve unrelated staged, modified and untracked work.
+
+Give every Finding one evidence-backed disposition:
+
+- `accepted`: the issue is confirmed against the governing contract and bounded investigation evidence.
+- `rejected`: direct evidence disproves it or authority does not require the suggestion.
+- `needs-clarification`: intended behavior, reproducible trigger, owner or safe investigation scope is missing.
+
+Acceptance of a finding grants no correction authority. If only investigation is authorized, return dispositions and the smallest next action without edits.
+
+## Correct only with separate authority
+
+Confirm the intended correction and exact mutation boundary before fixing accepted Findings in one bounded pass. One correction may address several findings while preserving their separate dispositions.
+
+After the last edit, rerun affected or missing declared checks and reuse traceable passes for unaffected inputs. Preserve the original report and return dispositions, actual changed paths, comparison, checks and limits to the caller. Failure, unavailability or stale evidence cannot close a Finding; the implementer cannot certify review-clean.
+
+Use this method for one correction. For requested or required correction/review, [Core review convergence](../../rsp/references/coordination-review.md) owns fresh Review, continuation and pass limits. Direct invocation needs no earlier Core execution; its caller applies that loop only to the remaining authorized review obligation. For repair-only requests, return the correction and unperformed review status. Claim no acceptance or new review assignment.
+
+Stop this pass for changed scope or authority, an unresolved material requirement, `needs-clarification`, unsafe effects or missing decisive evidence. Do not start a second local retry counter or reset the caller's count. Return any unresolved Findings and the exact next decision or evidence needed.

package/skills/rsp-implement/references/test-first.md

@@ -0,0 +1,7 @@
+# Risk-selected test-first implementation
+
+Load only after a clear authorized behavior and owning production/test seam are known, when test-first is explicitly required or a concrete changed risk makes pre-mutation RED materially safer. An unexplained symptom goes to diagnosis first. Require test and product mutation authority and an executable focused check. A test cannot create product authority, a public compatibility path, or an unreachable state.
+
+Identify the observable consequence, one distinct plausible regression, gap in current checks and maintenance cost. Add the smallest test at the real consumer seam. Run it before production mutation and observe the expected behavioral RED. Syntax, fixture, environment or unrelated baseline failures are not RED. If it passes, improve the discriminating check or stop. Make the smallest GREEN change and rerun the same check. Refactor only for a concrete improvement while green; do not widen interfaces or add test-only hooks to force GREEN.
+
+Retain a permanent test only when it protects observable behavior or a real boundary with distinct future value and proportionate cost, unless user/Change/project authority requires retention. Otherwise remove the disposable probe and helpers safely, then rerun affected decisive checks and reuse applicable unaffected evidence for the final state. Record final verification and omissions, not test chronology. Stop for changed owner/authority, unexplained failure, unavailable decisive environment, or non-convergence; within the same authorized scope use new failure evidence to diagnose and correct without an artificial Core handoff. No Git, review, archive, or external action follows from this method.

package/skills/rsp-review/SKILL.md

@@ -1,75 +1,73 @@
 ---
 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: Judge a fixed change or file set, or discover evidenced structural risks in an explicitly bounded repository or subtree. Authorized supporting checks are part of this read-only review; declared-check reporting alone belongs to Verify. No repair or approval.
 license: MIT
 metadata:
   author: oevery
-  version: "2026.08.05.1"
+  version: "2026.10.16.5"
 ---
 
 # RSP Review
 
-Review one fixed change scope without modifying it. Be concise, separate Code and Document judgment, and emit one deduplicated report.
+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.
+
+Review one fixed change/file set or bounded structural scope read-only. Apply relevant perspectives and report each issue once. Run supporting checks within this review; named checks alone require no separate Verify pass. Honor combined requests and independent-evidence obligations. Judging implementation completeness grants no lifecycle completion or closeout authority.
 
 ## Fix scope and authority
 
 Resolve before judging:
 
-- one immutable comparison point or explicit fixed file set;
-- reviewed files, including relevant untracked files named by the user;
-- the selected Change and, for grouped work, its Group Brief;
+- one immutable comparison point or explicit fixed file set for change review; for structural discovery, one explicit repository/subtree boundary and its observed checkout state, without requiring a diff;
+- content being judged, including relevant untracked files named by the user, distinguished from reference-only authority and evidence;
+- the selected WorkOwner when tracked: a Change WorkRef, or a Group reference with its Group Brief and direct child Changes; an untracked review may use the explicit request and fixed file set without creating a Change;
 - nearest project instructions and only relevant Specs and Decision Records;
 - any caller-supplied implementation summary.
 
-Do not switch branches or mutate the worktree to discover scope. If the comparison point is unavailable, report the review as blocked. If multiple focus markers or authorities select different intent, name the conflict, mark dependent pipelines blocked, and do not guess. Continue only pipelines whose inputs remain authoritative.
+Do not switch branches or mutate the worktree to discover scope. If a required change-review comparison point is unavailable, report the review as blocked. If the selected WorkOwner, included WorkRefs, or authorities select different intent, name the conflict, mark dependent pipelines blocked, and do not guess; multiple focus markers alone are only candidate context. Continue only pipelines whose inputs remain authoritative.
+
+The user request fixes the requested outcome and allowed operations subject to nearest project instructions. The selected WorkOwner defines the intended delta: a Change uses its WorkRef, while a Group uses its Brief and direct child Changes. Specs define current contracts, boundaries, and necessary constraints; 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.
+
+## Select perspectives before loading
+
+After fixing an explicit structural-discovery scope, load [structural review](references/structural-review.md) for ownership, dependency, production-path and verification lenses; no diff is required. Within fixed-change review, use those lenses only for a concrete structural risk in the same boundary; do not expand into a repository audit. Return evidenced findings and the smallest correction or unresolved design question, not a replacement design or implementation. Keep the report and verdict semantics below.
+
+Select methods from the judged content and its risks. Supporting references inform the judgment without becoming additional review targets. Respect narrower requested scope and reuse applicable instructions already in context.
+
+- **[Code](references/code-review.md):** behavior, contracts, safety and failures of reviewed executable instructions/code, runnable recipes, algorithmic logic or tool-interpreted content. A prose behavior claim alone can remain Document grounding.
+- **[Document](references/document-review.md):** factual explanation, usability, navigation and maintenance of reviewed content, including API/TSDoc comments, requirements and human- or agent-facing guidance.
+- Mixed targets receive both applicable perspectives; complete Skill instruction reviews normally need both. Ordinary implementation comments need local accuracy/clarity checks, not an automatic full Document pass; bounded wording changes need only affected perspectives. Illustrative pseudocode needs logical consistency, not an invented runtime or production test gate.
 
-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.
+When fixed reviewed artifacts include changelogs, release notes, migration guides or public release descriptions, also use [release communication checks](references/release-communication.md) within the Document pipeline. Ordinary documents and release evidence read only as authority do not select this method.
 
-## Classify the scope
+## Inspect the fixed scope
 
-- **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.
+Inspect checkout state and the selected diff or structural boundary, then authority, then the smallest behavior chain and evidence needed for the question. Match checks to each perspective, actual content and changed risk. Report a comment/implementation or example/contract discrepancy once, with evidence from both sides; presume neither correct. Stop when applicable judgments are supported. Do not broaden scope or execute snippets without authority.
 
-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.
+Reuse traceable test evidence while its tested scope and relevant code, dependencies, configuration, tools, inputs and environment still apply. Run authorized checks only for gaps, invalidated results, changed risk or explicitly required execution. Distinguish reused evidence from new observations.
 
-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.
+For re-review, inspect the actual correction and affected behavior against the original scope, expanding within it for evidenced consequences. Earlier clean verdicts do not establish a changed target; unchanged tests need no rerun solely for a new judgment. Perform the requested semantic review: neither passing tests nor an implementer summary supplies that judgment or required independence.
 
-Read [Code review](references/code-review.md) only when the fixed reviewed artifacts make the Code pipeline applicable.
+Recover a tool-only fault within the fixed scope using another permitted read-only method after inspecting its scope and effects. Preserve the comparison, authority, named checks, required evidence and independence; project mutation and unsafe probes remain prohibited.
 
-Read [Document review](references/document-review.md) only when the fixed reviewed artifacts make the Document pipeline applicable. A mixed review reads both references; authority-only artifacts never trigger either reference by themselves.
+Missing comparison or authority blocks dependent pipelines; other gaps follow the applicable gate. Keep supported findings and identify affected judgments without inventing a product defect or whole-review blocker. An unestablished required judgment is not clean.
 
 ## 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; when their language differs from the response, retain those values only as secondary exact tokens beside localized narration.
-
-Use this shape:
-
-```md
-## <localized Review Scope heading>
-- <localized Comparison label>: <fixed ref, range, or file set>
-- <localized Intent label>: <authorities, missing, or ambiguous>
-- <localized Code label>: <issues_found | clean | skipped | blocked>
-- <localized Document label>: <issues_found | clean | skipped | blocked>
-- <localized Excluded label>: <paths and reasons, or none>
-
-## <localized Findings heading>
-### [P0-P3] <title>
-- <localized Artifact kind label>: <code | document | cross-artifact>
-- <localized Axis label>: <pipeline axis>
-- <localized Location label>: <path:line or precise section>
-- <localized Authority label>: <authority or observed invariant>
-- <localized Evidence label>: <conflicting behavior or text>
-- <localized Impact label>: <real consequence>
-- <localized Suggested action label>: <smallest correction; no edit>
-- <localized Confidence label>: <high | medium | low>
-
-## <localized Coverage heading>
-- <checked and unverified scope, including non-actionable missing coverage>
-
-## <localized Verdict heading>
-<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.
+Responses follow explicit language instruction, personal instructions, then conversation language, never project artifact-language settings. Preserve paths, commands, identifiers, WorkOwner/WorkRefs, `P0`-`P3` and `issues_found | clean | skipped | blocked`; use localized narration with differing machine values as secondary exact tokens.
+
+Preserve the information below without mandatory headings or one line per field. Use a compact report for a clean bounded review, omit empty Findings and unrelated no-op fields, and honor explicitly required formats:
+
+- Scope: WorkOwner or direct request, fixed comparison, authoritative intent, applicable perspectives and material exclusions.
+- Findings when present: severity/title, kind (`code | document | cross-artifact`), review axis, location, authority, evidence, impact, smallest correction and confidence (`high | medium | low`). Combine related information in sentences; report one root issue once even when both perspectives are affected.
+- Coverage: each perspective's checked content, material omissions and unverified scope, including non-actionable gaps; distinguish reused evidence from new observations.
+- Verdict: `blocked | findings | clean`; give the next action only when an issue, blocker or requested follow-up remains. Do not repeat the findings or evidence.
+
+Use `clean` only for an applicable judgment with no actionable issue, `skipped` for an inapplicable perspective when the requested format requires it, and `blocked` when required scope, authority or decisive evidence is missing. Findings require a demonstrated defect or explicit-requirement violation; missing evidence alone is a coverage limit. Retain supported findings while blocking only affected judgments. Two perspectives require neither two reports nor two reviewers.
+
+Order findings by severity and path: P0 critical security/data/breakage risk; P1 normal-path contract failure; P2 meaningful edge/maintenance risk; P3 narrow actionable improvement.
+
+Illustrative compact finding, not an observed defect:
+
+> [P1] Failure is reported as success — `src/save.ts:42` (`code`, failure contract, high confidence). The selected Spec requires rejection, but this catch returns success after a failed write, so callers acknowledge unsaved data. Preserve rejection and verify the failure path.
 
 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

@@ -1,14 +1,30 @@
 # Code review
 
-Load this reference only when the fixed reviewed artifacts make the Code pipeline applicable.
+Load for behavior or tool semantics within the fixed reviewed content. Document examples, API comments and executable instructions can need Code checks without making their entire containing file or evidence source an implementation-review target.
+
+Match checks and evidence to the actual role and changed risk:
+
+- Copyable examples: syntax, prerequisites, API/command compatibility, outcomes and dangerous side effects; execute only with authority.
+- API comments: declared inputs, returns and failures against authority and implementation. Type, compiler, lint or generation annotations can affect tooling despite comment syntax.
+- Illustrative pseudocode: logic/contract consistency, not mandatory compilation, runtime dependencies or production tests.
+- Real changed seams and public behavior: retain the applicable reachability and regression gates below; do not impose them on prose or unchanged code read as evidence.
 
 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.
+1. **Safety and correctness:** reachable bugs, data loss, security violations, invalid transitions, broken contracts, unsafe failures and regressions.
+2. **Change and Spec fidelity:** observable behavior against explicit intent and stable facts.
+3. **Project standards:** user rules, nearest instructions and relevant Specs. Check ordinary comments for local accuracy and useful information that nearby code does not make clear, such as constraints, rationale or usage; restatement without added information is unnecessary. Document owns fuller expression/usability checks when applicable; cite agreed requirements, not taste. For reviewed Skills, compare trigger, inputs, authority, failures, output, completion, verification and conditional loading with the baseline. Trace relevant branches and required local safety guidance; report concrete misroutes or missing contracts. Static pruning or a newer model label proves neither behavioral equivalence nor quality or cost gain.
+4. **Production reachability — hard gate for a changed seam:**
+   - For adapter, wrapper, validator, normalizer, registration, loader, generated wire-up, bin, worker, subprocess, plugin assembly or other shipped-entry behavior, name the smallest production chain and verify it reaches the seam. Isolated tests bypassing it are insufficient.
+   - Record that entry path in Evidence or Coverage before completing a seam-dependent Finding or returning `clean`. Missing evidence or a bypassed seam requires a reported gap, no `clean`, and no isolated-fix sufficiency claim.
+5. **Regression evidence — hard gate before `clean`:**
+   - Compare each changed Code artifact's public return and failure behavior with the fixed baseline. Changes between throw/rejection, sentinel, `null`, status code or result object are failure-contract changes even when intended. Require focused tests or other explicit verification for the affected judgment. If decisive evidence is unavailable, report the gap and block that judgment under the shared report contract. Emit a Finding for a demonstrated defect or an evidenced violation of an explicit project/task verification requirement, not absence of a new test alone.
+   - Simple deterministic correction is excepted when public behavior shape is preserved and no risky branch, state transition, concurrency, persistence, security or failure delivery changes, despite a corrected value. Failure-contract changes are never excepted.
+6. **Test and seam value — hard gate before `clean`:**
+   - For an added or preserved permanent test, public seam, validator, fallback, capability, compatibility path or generic option, classify consumers as production, non-production or ambiguous. Tests/docs alone establish no production load.
+   - A questioned test needs an observable consequence, distinct plausible regression, existing evidence gap and maintenance cost. Derive expectations 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, seek targeted evidence; a precondition assertion or mutation run is not mandatory for every test.
+   - Prefer real collaboration when fast, deterministic and practical for the scenario. A substitute may control a necessary boundary while preserving the verified behavior. Judge error details and interaction counts/order by contract relevance; otherwise assess outcomes and effects, including rejection.
+   - Report test-only generality, wrapper/forwarding assertions, self-confirming expectations, source-string coupling or duplicate failure coverage only with a concrete real owner or smaller evidence path. Keep helpers clear about important inputs and assertions; useful shared setup and limited repetition are both acceptable. Tests protecting independent consequences retain value; fewer tests are not inherently better.
+7. **Simplicity:** for unnecessary abstraction, duplication, indirection, dependency or scope expansion, identify a smaller alternative preserving required behavior. Check who owns each rule, whether ordinary changes stay local and what internals callers must know. Similar code with different responsibilities may stay separate; unrelated flags can increase coupling through forced reuse. Judge extraction or removal by caller and maintainer burden, not file size, layer count or reuse count.
 
 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

@@ -1,15 +1,32 @@
 # Document review
 
-Load this reference only when the fixed reviewed artifacts make the Document pipeline applicable.
+Load for explanation or usage guidance within the fixed reviewed content, including Skill instructions and API/TSDoc comments. Apply the dimensions relevant to the reader's task; a short inline comment needs no synthetic introduction, document scaffold or standalone writing pass.
 
-Classify each document by its semantic role: requirement/Change, implementation plan, Spec, Decision Record/ADR, or explanatory/user documentation. Then check:
+- Compare API comments and copyable examples with the smallest authoritative contract and implementation: inputs, outputs, failures, prerequisites and consequences.
+- Label illustrative pseudocode and incomplete snippets; neither is a verified runnable recipe. A code fence or evidence-source read does not select Code by itself, and review grants no execution authority.
+- Code handles applicable behavior/tool checks, not a duplicate writing pass. Report one text/behavior mismatch once without automatically treating implementation as correct.
+- Skill guidance: descriptions discriminate neighboring intents; actions have prerequisites/results and conditional links have a reading purpose. Keep common safety and minimum actionable context local. Tables serve short stable mappings, not branching procedures; concise wording preserves substantive qualifiers.
 
-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.
+Classify each document by its semantic role: requirement/Change, implementation plan, Spec, Decision Record/ADR, context/navigation, operating instruction, or explanatory/user documentation. Then check:
 
-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.
+1. **Purpose:** identify the intended reader, available prior knowledge, and reading task. Missing framing matters when it causes a wrong decision or prevents that task, not merely when a preferred introduction is absent.
+2. **Grounding:** verify authority and traceability of claims and decisions, including commands, defaults, conditions, limits, and failure outcomes. For shortened text, check lost negation, exceptions, permissions, quantities, units, certainty or necessary reasoning. Technical literals must not change under wording-only authority. Compare internal and cross-artifact meaning; polished prose can still make a false promise.
+3. **Usability:** judge task usability separately from factual accuracy. Procedures need usable actions and success signals, contracts assessable conditions, and decisions reasons and tradeoffs. Against the intended reader's prior knowledge, check findability, prerequisites, definitions, causal and conditional links and visible unknowns without the author conversation. Retain mechanisms needed to reason, troubleshoot or judge guarantees; otherwise true internals may still leave the required action unclear. Preserve necessary teaching and local safety without demanding tutorials in references. Fixed order needs a correctness, safety or contract reason.
+4. **Ownership:** check scope, duplicate authority, and choices disguised as settled decisions. An unresolved choice warrants an ambiguity Finding when it prevents the reviewed content from serving its declared task or safe use. Respect draft state and narrower review scope; intentionally deferred or out-of-scope choices are limits, not automatic defects. Missing authority or decisive evidence follows the shared report contract and blocks only the affected judgment.
+5. **Maintenance:** check affected paths, links, anchors, terms and examples. For structural edits, follow reading paths and inspect moved content for omissions or broken ownership. Flag repeated examples or failure explanations only when they add no decision distinction. Preserve useful summaries, local safety and required evidence, including rare permission, serious-consequence and safe-recovery boundaries. An incident alone establishes no need for another constraint. Reuse applicable author evidence for mechanical checks; make required independent semantic judgments separately.
+
+Check ownership by meaning, not file shape. CONTEXT owns canonical terms, domain relationships, and navigation; AGENTS owns operating rules; README owns introduction and usage. Specs own current contracts and necessary constraints, including design-reference tables when they define normative evidence. Change Spec owns only the delta and acceptance; Design owns the approach, Tasks the work, and Verify the evidence. Decision Records own rationale. Short summaries and references are valid; parallel full definitions are not.
+
+Within fixed work-record scope, check placement as well as truth: Focus holds recovery notes; Change/Brief holds converged results and limits; knowledge documents hold justified stable facts. When judging blockers/readiness, compare actual impediments and the declaration with parsed state under the [shared work model](../../rsp/references/work-model.md). A claim of no blockers that parses as blocked is an inconsistency.
+
+For closeout, inspect the final whole Change or archived artifact after needs-based writeback, not only added Verify lines or an earlier candidate. Check that any writeback uses verified results, necessary knowledge corrections are complete and the final Change reflects them without duplicating current specifications. Already-accurate knowledge needs no edit; required corrections cannot be waived. Whole-Change convergence removes stale operation permissions, attempt/session chronology and response-only handoff/readiness blocks while retaining the contract delta, material failures, version-bound results and evidence references. Return substantive inconsistencies to their owner; prose cleanup cannot resolve them. Do not hide failures, relabel reports or grant cleanup authority. CLI readiness cannot establish this semantic result.
+
+Prefer behavior that survives replaceable internals. Report a Spec/code discrepancy without assuming the implementation is correct. Specialized Spec headings and omitted unnecessary scenarios are not defects; scaffold hints are optional writing aids, not requirements or evidence. Material promises, decisions, and limits must remain visible outside comments. Do not request extra sections, tests, or bulk historical rewrites merely for template conformity.
+
+For each finding, name the reader/task, exact evidence and violated authority or demonstrated consequence. For usability, identify what readers must infer and its effect on the task. An obscured action, scattered conditions, independent decisions crowded together or repetition can cause avoidable reconstruction or lookup. Cite the specific passage and effect; "too long" or "sounds generated" alone establishes no defect. Agreed expression rules are contracts; unagreed taste is not. Accept alternatives meeting the task and applicable contracts. Assess severity by consequence, not the amount of suggested rewriting. Preserve helpful causal prose, navigation summaries and author voice. Keep contrasts resolving likely ambiguity; do not require one per rule or delete needed operations to shorten text. Length, list counts and format checks cannot replace judgment.
+
+For example, an unexplained "the plan" can misdirect execution or force an avoidable search before the reader finds the right plan. A definition or prerequisite link that identifies it resolves that issue. Necessary prerequisite reading or a dense paragraph alone is no defect.
+
+Reading difficulty is evidence to investigate, not permission to invent facts or rewrite the document. Do not invoke Doc to apply findings during review. The five dimensions also guide writing, but Review uses this local reference and does not depend on Doc being installed. State whether reader comprehension was assessed locally or with actual independent evidence; never infer independence from a self-check or require a fixed number of rounds.
 
 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-review/references/release-communication.md

@@ -0,0 +1,21 @@
+# Release communication checks
+
+Load only when the fixed Document review scope includes release communication. Apply these checks alongside Document review; this method needs no installed Doc Skill and adds no writing, publication or approval authority.
+
+## Fix evidence and intended state
+
+Establish the released unit, range, requested surfaces and draft, final or published state from the request and authoritative project release conventions. A claimed version needs explicit user or repository release authority; do not infer it from commit ordering or a plausible next version.
+
+Read only the direct behavior, net diff, accepted fragments and verification needed to judge the fixed claims. Generated inventories and commit summaries are leads, not delivered behavior. Missing decisive range or behavior evidence blocks dependent judgments; unknown product or operational choices follow Document review's ambiguity rule. Do not broaden the reviewed set into a repository-wide release audit.
+
+## Check the communication
+
+- **Net outcome:** claims describe delivered final behavior, not reverted additions, implementation chronology or rejected session-only proposals. Material public, compatibility, packaging, security and operator effects are neither invented nor omitted.
+- **User action:** affected users can identify breaking changes, deprecations, old/new behavior, ordered migration steps, applicable compatibility windows, success checks and known recovery paths. Required safe commands, API forms and versions remain exact; a file link cannot replace a required action or consequence.
+- **Consistency:** selected surfaces agree with authoritative versions, dates, supported environments and references. Changelogs, notes and migration guides serve their distinct audiences rather than duplicating one transcript. Public links are stable and do not expose private identifiers.
+- **Evidence limits:** historical checks identify their revision or date; unavailable platform or live-release verification is not described as completed. Document correctness proves neither package verification nor release readiness.
+- **Lifetime and authority:** drafts disclose unresolved identity without inventing versioned claims. Final shipped prose remains publication-invariant and uses target tags or immutable comparisons, not moving HEAD. Credentials and transient authentication/publication progress stay out of retained artifacts. A document task never grants commit, tag, push, publish or immutable-history repair.
+
+For an explicitly scoped post-publication comparison, inspect observed public state against the selected immutable candidate. Report mutable-document corrections or an immutable discrepancy's corrective owner; never edit, move a tag or rewrite a package. An unknown external state remains unverified.
+
+Apply project-required release checks and closeout conditions only when they govern this judgment. Do not impose a universal Release Change, separate release commit, archive requirement or publication checklist. Return findings, coverage and limitations in Review's existing report; a clean Document result is not release approval.

package/skills/{rsp-structural-audit/references/structural-lenses.md → rsp-review/references/structural-review.md}

@@ -1,6 +1,6 @@
-# Structural audit lenses
+# Structural review
 
-Load this reference only after the audit boundary and authority are fixed. Select the smallest relevant set of lenses; do not turn them into a completion checklist.
+Load for requested structural discovery or a concrete structural risk within an already fixed review boundary. Select the smallest relevant set of lenses; do not turn them into a completion checklist.
 
 ## Candidate selection in a broad boundary
 
@@ -14,7 +14,7 @@ Trace where important state or data is created, validated, mutated, persisted, r
 
 Start from a direct consumer and list what it must know about the provider: policy, representation, ordering, failure behavior, configuration, and lifecycle. Look for dependency direction that forces an owner to understand another module's internals, or a boundary that leaks enough decisions to amplify ordinary changes. An import, large module, circular-looking name, or missing interface is not sufficient; establish actual caller burden or invalid-state exposure.
 
-For suspected shallow indirection, reason through removal before calling it redundant. If removal eliminates the apparent complexity, the layer may be pass-through. If required policy, invariants, or failure knowledge instead disperses into callers, the layer may be earning locality. Thinness alone proves neither result; retain a Finding only when the live chain also establishes a reachable trigger and concrete impact.
+Before calling a layer redundant, trace what its removal would do. Eliminated complexity suggests pass-through; policy, invariants or failure knowledge dispersed into callers suggests useful locality. Thinness proves neither. Retain a Finding only with a reachable trigger and concrete impact in the live chain.
 
 ## Production-path reachability
 
@@ -36,6 +36,6 @@ Before retaining a finding, answer all of these from repository evidence:
 2. What reachable condition triggers the problem?
 3. What realistic user, operator, data, or change-cost impact follows?
 4. Which evidence confirms the full chain, and what remains unobserved?
-5. What is the smallest next owner: a user decision, shaping question, or one bounded design question?
+5. What is the smallest correction or unresolved owner/design question?
 
-Discard the finding when any of the first three answers is speculative. Rank retained findings by impact and confidence, not ease of cleanup. Use P1 for a normal-path structural failure with significant correctness or data consequences, P2 for a meaningful edge or recurring change risk, and P3 only for a narrow actionable maintenance risk. Do not emit P0 from this general structural audit; route suspected critical security, safety, or data-loss work to the appropriate specialist or incident owner.
+Discard the finding when any of the first three answers is speculative. Rank retained findings by impact and confidence, not ease of cleanup. Use Review's severity and verdict semantics. Select only material supported findings; missing coverage stays explicit and does not justify an unqualified clean claim. Do not turn the report into an implementation, replacement design or automatic handoff.