@oevery/rsp 3.3.0 → 4.1.0

package/skills/rsp-implement/SKILL.md

@@ -1,64 +1,99 @@
 ---
 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.11.04.3"
 ---
 
 # 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.
+- A ready Change selected by explicit WorkRef or resolved 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.
+
+For optional context discovery, distinguish no matches from execution errors: no matches should not block independent subsequent reads, while missing required inputs and actual execution errors still need handling.
+
+Within the confirmed checkout/worktree, prefer paths relative to the command or tool's explicit working directory for repository reads, searches and edits. Reuse the known execution root; do not switch worktrees to make a path resolve. Use absolute paths when the tool requires them, accessing files outside that root, or explicitly locating another authorized root; a path alone does not establish checkout identity or revision.
 
-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.
+When work affects modeled structure, responsibilities, dependencies or bindings, use [architecture knowledge](../rsp/references/architecture.md) for reading, synchronization and own checks.
+
+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. Prefer, in order, no addition when the outcome is already met, repository reuse, platform or standard-library facilities, existing dependencies, then the smallest complete implementation. Keep rules with their invariants; do not force unrelated responsibilities through 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 defensive logic or a new boundary only for an explicit requirement or an evidenced producer, production consumer, trust/lifecycle transition and material consequence. Typed same-process values and imagined or test-only consumers do not establish that need. Backups, snapshots and digests likewise need a real recovery or independent identity/integrity consumer; do not create them as routine preflight. Preserve required recovery safeguards and independently trusted integrity checks.
 
-## Classify implementation evidence
+Test stable public behavior with real internal collaborators by default. Substitute external or nondeterministic boundaries as needed. Focused unit tests remain useful for meaningful algorithms, parsers and critical boundaries; choose evidence by risk, not a per-function/file/branch allocation or unit/integration ratio.
 
-Apply these routes in order before mutation and after failure:
+Reuse sufficient existing evidence before adding a permanent test. A new test needs a distinct plausible regression, observable consequence and evidence gap worth its maintenance. Exercise the consumer outcome through the relevant production path; an already-covered forwarding hop adds no confidence.
 
-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.
+Derive expectations from the contract or independent examples. Assert outcomes and effects, including rejection; pin details, counts or order only when contract-relevant. Private structure, source wording and constants compared with themselves are not contracts; public defaults can be. When setup leaves the target condition uncertain, inspect it or use a targeted probe rather than adding ritual preconditions. Keep scenario-defining inputs and assertions visible and share incidental setup when clearer.
 
-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.
+## 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. For authorized Change updates, load the [current work record rules](../rsp/references/work-model.md#current-work-records) when absent from context. Update affected work and evidence as facts change; reopen invalidated results rather than append fix/retry tasks or check history. Plan or contract changes retain their decision authority. 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.

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,72 +1,73 @@
 ---
 name: rsp-review
-description: Review an RSP-tracked code, document, or mixed change against a fixed comparison scope and project authorities without modifying files. Use for read-only findings before fixes, durable review, archive, or delivery; keep Code and Document states separate and never implement, commit, publish, or approve.
+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.19.1"
+  version: "2026.11.04.1"
 ---
 
 # 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
+
+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 executable content; also ownership, dependency and verification lenses for explicitly bounded structural discovery. Within change review, structural inspection stays with a concrete risk in the fixed boundary. 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.
+
+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.
+
+## Inspect the fixed scope
 
-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.
+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.
 
-## Classify before loading
+When the reviewed scope affects modeled structure, responsibilities, dependencies or bindings, apply [architecture knowledge](../rsp/references/architecture.md) within that scope.
 
-Do not read a pipeline reference until scope and authority are fixed. Then:
+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.
 
-1. Classify only fixed reviewed artifacts. **Code** includes executable code, tests, configuration, scripts, schemas, executable prompts, Skills, commands, hooks, and workflows. **Document** includes requirements, plans, Changes, Specs, Decision Records, ADRs, explanatory documentation, and user-facing documentation. An executable document may require both.
-2. Inputs read only as authority or evidence are authority-only, not reviewed artifacts. With no reviewed artifacts, a pipeline is `skipped`, never `clean`. Record missing, ambiguous, or conflicting authority in Review Scope, Coverage, and Verdict, not as a Finding from a skipped pipeline.
-3. Load [Code review](references/code-review.md) only if Code applies and [Document review](references/document-review.md) only if Document applies. A mixed review loads both; authority-only artifacts trigger neither.
+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.
 
-Run every applicable pipeline and merge the same underlying issue into one cross-artifact finding. Inspect in order: fixed status and diff, selected authority, then the smallest direct behavior chain and tests needed for a concrete question. Stop when all applicable pipelines can be judged; do not search unrelated files or broaden authority to fill Coverage or Findings.
+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.
+
+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, or breakage risk, 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, changed lines or the smallest inspected chain, evidence and consequence, and the smallest correction or unresolved owner decision. For a defect, show its reachable trigger; for a simplification, show the current responsibility, demonstrated burden and smaller complete alternative preserving failure, authority and Required gates. Cite authority when a contract is violated and state material uncertainty. 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 may establish a defect, an explicit-requirement violation, or an evidenced simplification; fewer lines alone, speculative impact and taste-only cleanup do not qualify. Do not invent a wrong-result bug for a supported simplification. 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. Assess findings by consequence and confidence, not lines removed or ease of correction.
+
+Illustrative compact finding, not an observed defect:
+
+> [P1] Failure is reported as success — `src/save.ts:42`. 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,15 +1,36 @@
 # 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 or returning `clean` for a changed seam: when behavior depends on an adapter, wrapper, validator, normalizer, registration, loader, generated wire-up, bin, worker, subprocess, plugin assembly, or another shipped entry path, name the smallest real production entry chain and verify that it reaches the changed seam. Direct or isolated seam tests are insufficient when they bypass that entry chain. Put the checked entry path in Evidence or Coverage. If the shipped path bypasses the seam, or the required reachability evidence is missing, report the gap and do not return `clean` or present an isolated seam fix as sufficient.
-5. Regression evidence — hard gate before `clean`: for every changed Code artifact, compare public return and failure behavior at the comparison point with the reviewed diff. Changing failure delivery between throw/rejection, sentinel values, `null`, status codes, or result objects is always a failure-contract change, even when implementation matches the selected Change. Without a focused test or other explicit verification evidence, emit a Finding and return `issues_found`. Absence of a new test is not actionable by itself: apply the simple deterministic-correction exception when the public behavior shape is preserved and no risky branch, state transition, concurrency, persistence, security behavior, or failure delivery changes, even though the corrected value differs. The exception never applies to a failure-contract change.
-6. Test and seam value — hard gate before `clean` when the diff adds or preserves a permanent test, public seam, validator, fallback, capability, compatibility path, or generic option: classify its consumers as production, non-production, or ambiguous. Tests and documentation alone do not make behavior production-load-bearing. For each questioned permanent test, identify its observable consequence, distinct plausible regression, why existing evidence misses it, and maintenance cost. Report test-only generality, wrapper or forwarding-hop assertions, shared-constant restatement, source-string coupling, or duplicate failure coverage only when a concrete real owner or smaller evidence path exists. Do not recommend deleting or merging tests that protect independent consequences, and do not infer that fewer tests are inherently better.
-7. Simplicity: unnecessary abstraction, duplication, indirection, dependency, or scope expansion with a concrete smaller alternative; never trade away required behavior.
+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 a questioned test or added boundary, identify its real consumer, distinct observable consequence and evidence gap. Tests/docs alone establish no production load. Prefer stable public behavior and real internal collaboration; substitute external or nondeterministic boundaries as needed. Meaningful algorithms, parsers and critical boundaries can warrant focused unit tests.
+   - Derive expectations from the contract or independent examples, not the tested computation or source spelling. Check uncertain fixture conditions with targeted evidence. Pin details, counts or ordering only when contract-relevant. Private structure and constants compared with themselves are not behavioral contracts; a public default can be.
+   - Report duplicate confidence, forwarding-only assertions or test-only generality with a concrete smaller evidence path. Keep important scenario inputs and assertions visible. Independent consequences retain value; neither per-function/file/branch allocation nor a unit/integration ratio determines coverage.
+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.
+
+## Bounded structural discovery
+
+Use only for a requested repository/subtree audit or a concrete structural risk within fixed-change scope. Without a narrower lead, use recurring changes or defects to select a candidate chain; history is navigation evidence, not a finding. Inspect current owners and the live path. Do not turn these lenses into a whole-repository checklist:
 
-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.
+- **Ownership:** trace creation, validation, mutation, persistence, recovery and consumption. Report competing authority only when reachable paths can diverge with a concrete consequence; projections and fixtures are not automatically competing owners.
+- **Dependencies:** start from a consumer's required knowledge of provider policy, representation, ordering, failures and lifecycle. Show actual change amplification or invalid-state exposure, not merely an import or large file. Trace a proposed layer removal: eliminating pass-through work may help, but scattering policy or failure knowledge into callers does not.
+- **Repeated knowledge:** trace one representative change across its independently maintained owners. Generated copies, deliberate boundary translation and similar text alone establish no duplication problem.
+- **Verification:** map claimed evidence to the same entry path and public result. A bypassed isolated seam can give false confidence; missing tests alone establish neither a structural finding nor a functional defect.

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

@@ -1,15 +1,30 @@
 # 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.
+- 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.
+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.
 
-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.
+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, load the [current work record rules](../../rsp/references/work-model.md#current-work-records) when absent from context. Check that Tasks reflects current work, each Verify detail serves acceptance, applicability or necessary evidence lookup without repeating check results, and Focus contains only additional recovery context without a second state list or execution timeline. A record can still contain unnecessary execution detail without chronological headings. Preserve useful before/after comparisons, material failure dispositions and distinct review/acceptance boundaries. When judging blockers/readiness, compare actual impediments and the declaration with parsed state under the same work model. 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.
+
+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 document findings, identify the reader/task. 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. 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. 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. Do not apply code-style or test-coverage rules to semantic documents.

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.