@oevery/rsp 4.0.0 → 4.2.0

package/skills/rsp-review/SKILL.md

@@ -4,7 +4,7 @@ description: Judge a fixed change or file set, or discover evidenced structural
 license: MIT
 metadata:
   author: oevery
-  version: "2026.10.16.5"
+  version: "2026.11.04.1"
 ---
 
 # RSP Review
@@ -29,11 +29,9 @@ The user request fixes the requested outcome and allowed operations subject to n
 
 ## 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. Two perspectives require neither two reports nor two reviewers. Supporting references inform the judgment without becoming additional review targets. Respect narrower requested scope and reuse applicable instructions already in context.
 
-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.
+- **[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.
 
@@ -41,9 +39,11 @@ When fixed reviewed artifacts include changelogs, release notes, migration guide
 
 ## Inspect the fixed scope
 
-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.
+Inspect checkout state and the selected diff or structural boundary, then authority, then the smallest behavior chain and evidence needed for the question. 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.
+
+Reuse traceable check evidence while its tested scope and relevant code, dependencies, configuration, tools, inputs and environment still apply. Before running an authorized check, identify the evidence gap, invalidated result, changed risk or explicit execution requirement it addresses. Apply this selection to tests and non-test checks alike; low cost alone does not justify extra execution. Distinguish reused evidence from new observations.
 
-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.
+When the reviewed scope affects modeled structure, responsibilities, dependencies or bindings, apply [architecture knowledge](../rsp/references/architecture.md) within that scope.
 
 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.
 
@@ -53,21 +53,21 @@ Missing comparison or authority blocks dependent pipelines; other gaps follow th
 
 ## Report
 
-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.
+Responses follow explicit language instruction, personal instructions, then conversation language, never project artifact-language settings. Preserve paths, commands, identifiers, WorkOwner/WorkRefs and `P0`-`P3`; use localized narration with differing machine values as secondary exact tokens. Use `blocked | findings | clean` for the overall verdict. For per-file or per-perspective results, preserve the caller's required schema, including `issues_found` or `skipped` where specified.
 
 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.
+- 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 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.
+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.
 
-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.
+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` (`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.
+> [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

@@ -21,10 +21,16 @@ Check in this order:
    - 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.
+   - 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.
 
-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.
+## 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:
+
+- **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

@@ -4,7 +4,7 @@ Load for explanation or usage guidance within the fixed reviewed content, includ
 
 - 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.
+- 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.
 
 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:
@@ -12,21 +12,19 @@ Classify each document by its semantic role: requirement/Change, implementation
 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.
+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.
 
 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.
+Within fixed work-record scope, load the [current work record rules](../../rsp/references/work-model.md#current-work-records) when absent from context. Check Tasks, Verify and Focus against their respective rules, including current limits and stale conclusions. Existing text has no exemption. 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.
+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 follows the current work record rules and removes stale operation permissions and response-only handoff/readiness blocks. Return substantive inconsistencies to their owner; prose cleanup cannot resolve them. Do not conceal unmet checks or limits, 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.
+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 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, 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.
+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-shape/SKILL.md

@@ -4,7 +4,7 @@ description: Resolve bounded design questions read-only or clarify material choi
 license: MIT
 metadata:
   author: oevery
-  version: "2026.10.15.2"
+  version: "2026.11.04.1"
 ---
 
 # RSP Shape
@@ -23,6 +23,8 @@ Resolve needed RSP settings, including defaults and inheritance, through the sel
 
 Read the request, authority, nearest project context, Change and Brief when selected, then only decisive evidence. A direct design question without a Change does not require one. A design question inside a tracked Change retains that WorkRef, but defaults to report-only; only explicit artifact authority permits updating its Design.
 
+For structural or responsibility decisions, use [architecture knowledge](../rsp/references/architecture.md) to inspect any existing model and distinguish current facts from proposed design.
+
 A request to shape, create, or refine a Change grants artifact authority unless no-edit; advice does not. If creation focuses it, preserve the exact prior focus and restore it immediately unless selection was requested. Shaping grants no other authority; preserve unrelated work.
 
 Route concrete or ready work to implementation only when authorized and no design/planning question remains. An explicit read-only design request still ends with its report. Do not rewrite settled work for style or completeness.

package/skills/rsp-shape/references/planning.md

@@ -15,15 +15,15 @@ Keep one observable outcome per Change:
 - `Proposal`: outcome, scope, non-goals;
 - `Spec`: settled contract delta and acceptance, referencing affected existing Specs rather than copying the baseline or inventing public promises;
 - `Design`: approach, responsibility boundaries, and necessary tradeoffs, not repeated requirements or tasks;
-- `Tasks`: checkable work, with prescribed order only where correctness, safety, or migration requires it;
-- `Verify`: methods proving settled acceptance, not adding new public requirements; then actual decisive results, gaps, and limits, not repeated requirements or transcripts;
+- `Tasks`: current checkable work, with prescribed order only where correctness, safety, or migration requires it;
+- `Verify`: settled acceptance evidence under the current work record rules below; do not introduce new public requirements;
 - `Blockers`: dependencies and decisions, or `none`.
 
 Keep the six sections; small changes need only proportionate content. Plain-prose HTML scaffold hints may remain or be removed; they guide writing, never supply requirements, evidence, or completed content. Resolve body placeholders and keep all material decisions visible outside comments.
 
 Plan a test only when it protects observable behavior or a real boundary, adds distinct future confidence, avoids duplicate or implementation-detail coverage, and costs proportionately. Otherwise prefer smallest sufficient evidence and keep probes temporary.
 
-A Change is a convergent plan and final-result snapshot. Ongoing recovery notes belong in Focus; detailed evidence stays with its owner. Before closeout, establish verified outcomes, selectively update stable knowledge at its owner, then reconcile the final Change with those facts and references. These may be one operation and already-accurate text needs no edit. Do not append execution history.
+Apply the [current work record rules](../../rsp/references/work-model.md#current-work-records) when shaping or revising tasks and verification; load them when absent from context. Replace obsolete plans within settled authority, keeping unmet obligations visible. A Change records current intent and progress during work, then the delivered result at closeout. Necessary stable knowledge stays with its owner; Focus only supplements missing recovery context.
 
 Use domain language. Mention agents only as real product actors or constraints, not authors or execution narrators.
 
@@ -35,7 +35,7 @@ A Change is ready only when:
 - product and mutation authority are settled;
 - affected boundaries and material constraints are known;
 - no hidden assumption can change implementation or acceptance;
-- Tasks are executable without performing them;
+- Tasks are concrete enough for implementation to begin. Shaping does not execute them;
 - Verify proves the result without process chronology; Blockers are truthful;
 - one Change or a justified shallow Group is the smallest sufficient owner.
 

package/skills/rsp-verify/SKILL.md

@@ -4,7 +4,7 @@ description: Collect and report one selected RSP WorkOwner's declared check evid
 license: MIT
 metadata:
   author: oevery
-  version: "2026.10.12.1"
+  version: "2026.10.27.1"
 ---
 
 # RSP Verify
@@ -15,14 +15,14 @@ Collect declared-check evidence for one existing RSP WorkOwner when requested or
 
 ## Require a declared boundary
 
-Require one selected WorkOwner, declared boundary, comparison baseline and authority for the named checks. An explicit reference wins; otherwise resolve one FocusSet candidate from user intent and status. Multiple markers are valid.
+Require one selected WorkOwner, current target, declared check contract and execution authority. A comparison needs its comparison baseline; a current-target check does not need an old revision. An explicit reference wins; otherwise resolve one FocusSet candidate from user intent and status. Multiple markers are valid.
 
 - **Change:** use its WorkRef and its `Verify` section for the declared boundary.
 - **Group:** use its Group reference and named `Integration:` condition in the Brief's `Completion Conditions`; child evidence stays with each child WorkRef. An explicit request may supply an in-progress temporary boundary, which must be written back before Group closeout.
 
-Stop for ambiguous owner, scope, baseline, required evidence or environment, or a Group without a named boundary for the requested verification.
+Stop for ambiguous owner, target, required evidence or environment, a missing required comparison baseline, or a Group without a named boundary for the requested verification.
 
-Read nearest project instructions and the available project protocol, selected Change and Brief, relevant Specs and Decisions, current diff, blockers, and the smallest production path needed to understand the declared check. This package needs no installed Core Skill. Do not invent checks from generic testability or replace an unexplained failure with a guessed assertion; return that symptom for read-only diagnosis.
+Read nearest instructions, selected Change/Brief, relevant contracts, blockers and the smallest production path needed to understand the check. Inspect the diff when the check concerns a change. This package needs no installed Core Skill. Do not invent checks from generic testability or replace an unexplained failure with a guessed assertion; return that symptom for read-only diagnosis.
 
 ## Preserve read-only authority
 
@@ -32,7 +32,9 @@ Use the caller's result contract when supplied, otherwise the direct result belo
 
 ## Collect the declared evidence
 
-Compare existing evidence with the declared baseline. Reuse traceable passes while their tested scope and relevant content, dependencies, configuration, tools, inputs and environment still apply. Run missing, failed or invalidated named checks and any explicitly required execution, current-environment observations or independent execution. Corrections and integration need fresh evidence for affected inputs or an enlarged boundary; a phase change alone requires no rerun.
+Bind evidence to the declared target. For comparison or reuse, establish the earlier target and relevant inputs. Reuse traceable passes while their tested scope and relevant content, dependencies, configuration, tools, inputs and environment still apply. Run missing, failed or invalidated named checks and any explicitly required execution, current-environment observations or independent execution. Corrections and integration need fresh evidence for affected inputs or an enlarged boundary; a phase change alone requires no rerun.
+
+Create no backup, snapshot or digest merely to identify a routine check. Use them only for an actual recovery requirement or independent identity/integrity consumer. Exact Git delivery, trusted external digests and required recovery safeguards retain their own contracts.
 
 Compare each check's actual targets, inputs, coverage and completion with its declaration. Retain commands, scope, sources and results; distinguish reused evidence from new execution. Invocation errors or incomplete observations alone prove no product defect; exit status alone establishes no acceptance.
 
@@ -52,14 +54,7 @@ Return exactly one canonical result from the collected evidence, with observed f
 
 Report each check's outcome, including missing or unexecuted checks. Aggregation changes neither coverage nor stop conditions. Failure does not imply complete coverage; unavailable evidence does not erase observed failures.
 
-Include these independent fields and their evidence:
-
-- `evidence_delta: new | none`: whether the result changes the next diagnosis or correction.
-- `boundary: unchanged | changed`: whether observed owner, paths, baseline, behavior, interface, scope and authority still match the declared boundary.
-- WorkOwner and applicable Change WorkRef or Group `Integration:` condition; lane objective and effective authority.
-- Named checks, comparison baseline, observed diff, decisive evidence with reused versus newly executed results, omissions and stop boundary.
-
-Preserve exact machine values and all required result information. Present them concisely without repeated logs or evidence; a requested machine schema remains exact. Human-facing narration follows a supplied response-language contract; otherwise use explicit user instruction, then personal instructions, then conversation language.
+Report the WorkOwner and applicable WorkRef or Group `Integration:` condition, target, named checks and outcomes, decisive evidence, omissions and any changed boundary. Distinguish reused from new execution; include a comparison baseline only for a comparative claim or reused evidence. Add machine fields only for an actual consumer or explicitly required schema, preserving its exact values. Do not repeat logs. Human-facing narration follows explicit user instruction, then personal instructions, then conversation language.
 
 `pass` proves only declared checks, not semantic review, writeback, archive/commit eligibility, publication, deployment, approval or human acceptance. It grants no lifecycle, Git, external or acceptance authority.
 
@@ -67,6 +62,6 @@ Long-running verification remains active while its boundary and stop conditions
 
 ## Stop and return
 
-Stop when evidence is missing, the environment is unavailable, the boundary changes or a required check cannot be observed. Use the caller's canonical stop reason only when supplied. For direct invocation, identify the missing input or changed boundary and the required next action; do not invent a completed verification result before the declared boundary is established.
+Stop the affected verification if required evidence cannot be collected or observed, the required environment is unavailable, or the declared boundary changes. Use the caller's canonical stop reason only when supplied. For direct invocation, identify the missing input or changed boundary and the required next action; do not invent a completed verification result before the declared boundary is established.
 
 On cancellation, wait until the command or owned process is observed stopped before beginning conflicting work. Return the result, decisive evidence, omissions and next action to the caller or user. Retry only with new evidence and safe replay inside the declared boundary.

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

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

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

@@ -1,41 +0,0 @@
-# Structural review
-
-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
-
-When the user supplies a broad repository boundary without a narrower lead, use repeated changes, recurring defects, or cross-owner correction history only to select the smallest candidate behavior chain. Churn is navigation evidence, not a Finding. Inspect the current owners and reachable path before applying any lens, and return `clean` when the selected chain has no concrete structural downside.
-
-## Ownership and sources of truth
-
-Trace where important state or data is created, validated, mutated, persisted, recovered, and consumed. Look for competing writers, duplicated authority, or a lifecycle whose transitions are split across owners that cannot enforce the same invariants. A cache, projection, generated artifact, or test fixture is not automatically a competing source of truth. Report only when a reachable path can diverge and the divergence has a concrete consequence.
-
-## Module and dependency direction
-
-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.
-
-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
-
-Trace the smallest complete path from a real entry point to the behavior under examination. For an adapter, validator, normalizer, wrapper, or policy seam, name the direct production caller and its actual callee. Report a bypass only when the live consumer reaches a different path, and distinguish an unused seam from a seam used by another valid entry point. Do not treat API existence, registration, generated code, or an isolated passing test as proof of lifecycle integration.
-
-## Change amplification and repeated knowledge
-
-Use repository history only when it is available and necessary; otherwise trace one representative behavior across schemas, types, adapters, callers, configuration, tests, and documentation. Report amplification when one behavioral change requires independently maintained edits because ownership is fragmented. Similar text, generated output, deliberate boundary translation, and test fixtures are not duplication by themselves. Code reduction is never the objective.
-
-## Verification mismatch
-
-Map focused tests, assertions, or checks to the same production path and public behavior claimed by the implementation. Look for tests that exercise only an isolated seam while the live consumer bypasses it, or verification that cannot observe the relevant state transition or failure contract. Missing tests alone are not a structural finding; establish that existing evidence creates false confidence or leaves a material invariant unverified.
-
-## Finding gate and ranking
-
-Before retaining a finding, answer all of these from repository evidence:
-
-1. What exact entry point, owner, caller, or artifact anchors it?
-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 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 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.