@oevery/rsp 4.0.0 → 4.1.0

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.
 

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.