@oevery/rsp 4.0.0 → 4.1.0

package/skills/rsp/SKILL.md

@@ -4,7 +4,7 @@ description: Coordinate authorized direct, Change or Group work; select capabili
 license: MIT
 metadata:
   author: oevery
-  version: "2026.10.22.4"
+  version: "2026.11.04.1"
 ---
 
 # RSP Core
@@ -21,7 +21,7 @@ Before mutation, read nearest instructions and relevant CONTEXT; establish inten
 
 Load the [work model](references/work-model.md) when tracked identities are missing from context; required tracking cannot be bypassed by relabelling work Direct. Use rsp status for needed owner, dependency or recovery facts, and JSON for exact dependency data. Required dependency checks and fresh archive readiness still apply.
 
-Use the CLI invocation selected by the project AGENTS entry: consumer projects pin an exact package in `.rsp/version`; an explicit `.rsp/source` selects the RSP development checkout's own built CLI. `rsp` in these Skills denotes that selection, never `@latest`, a version range, or an unverified global binary. Do not substitute a published package for source mode because version strings match. Only an authorized upgrade selects another exact package target and runs its `update` command for the complete environment; source-mode update retains the local source selection. Upgrade notices grant no migration authority. Resolve needed settings through the selected CLI's successful rsp config --json summary. Reuse it until relevant drift or recovery; raw YAML is diagnostic only. Projection failure blocks choices depending on unknown settings, while independent authorized work continues.
+Use the CLI invocation selected by the project AGENTS entry; `rsp` in these Skills denotes that selection. Resolve needed settings through the selected CLI's successful `rsp config --json` summary. Reuse it until relevant drift or recovery; raw YAML is diagnostic only. Projection failure blocks choices depending on unknown settings, while independent authorized work continues.
 
 Select capabilities from their descriptions and the task contract. Executors load applicable methods and inspect sources; Core consults method details when needed for its own work or a concrete coordination question. Select the responsibility needed now:
 
@@ -32,7 +32,7 @@ Select capabilities from their descriptions and the task contract. Executors loa
 - rsp-review: fixed-scope read-only judgment or explicitly bounded structural discovery. Supporting checks remain within that review.
 - rsp-commit: separately authorized exact local delivery; required for Git execution, with no Core substitute if unavailable.
 
-Continue authorized same-scope work without another continuation request. A phase, role or method change alone requires no tool call, worker, review or test run. Required review, independent execution and protected operations still apply. For ownerless release checks, establish the exact candidate, check contract, baseline and effects authority; invent no Change or Verify owner.
+Continue authorized same-scope work without another continuation request. A phase, role or method change alone requires no tool call, worker, review or test run. Required review, independent execution and protected operations still apply. For ownerless release checks, establish the exact candidate, check contract and effects authority, plus a baseline for any comparison; invent no Change or Verify owner.
 
 ## Execute and reconcile evidence
 
@@ -40,7 +40,7 @@ Implement owns ordinary self-checks. Main-agent inspection can assess results, b
 
 Reuse traceable observations, checks and reviews while their target, acceptance boundary and relevant inputs still apply. Changed code, dependencies, configuration, tools or environment invalidate affected evidence; role changes and delivery-scope confirmation alone do not. Include excluded worktree inputs when assessing a staged slice, and recognize behavior changes in normative Specs or executable Skills even when stored as Markdown.
 
-Check paths, diff, outcomes, omissions and evidence applicability. Reuse executor checks when applicable. Independent semantic review may use implementer test evidence; required independent execution must run. Keep commands, results, tested boundaries and decisive sources with their existing owner, including failures, unavailable checks and superseded results. Add no evidence ledger.
+Check paths, diff, outcomes, omissions and evidence applicability. Reuse executor checks when applicable. Independent semantic review may use implementer test evidence; required independent execution must run. Preserve original evidence and verdicts with their existing owner; Change retains only applicable conclusions and material failure dispositions. Add no evidence ledger.
 
 For required correction/re-review, load [review convergence](references/coordination-review.md). Batch compatible findings into one correction, run covering checks, then review finding resolution and new risks in the correction. Stop for changed scope/authority, unsafe replay, missing required capability, non-convergence or no new discriminating evidence. Required failures remain incomplete.
 
@@ -56,7 +56,7 @@ Load [interruption recovery](references/coordination-recovery.md) for pause/resu
 
 ## Maintain records and prepare delivery
 
-During execution update Tasks/Verify directly for actual outcomes when scope, contract, design and knowledge remain accurate. Consolidate repeated conclusions for the same scope and candidate; retain distinct inputs, outcomes, material failures and evidence references. When changing Blockers, use the [shared work-model syntax](references/work-model.md). Passing checks or recovery alone adds no whole-document rewrite. Routine narration stays in the conversation; retained execution evidence stays with its existing owner. Focus is replaceable recovery guidance, never acceptance or authority.
+During execution apply the [current work record rules](references/work-model.md#current-work-records), loading them when absent from context. Update affected Tasks/Verify directly when scope, contract, design and knowledge remain accurate; do not append attempts or postpone current-state corrections until archive. Use the same work model for Blockers syntax. Passing checks or recovery alone adds no whole-document rewrite. Focus supplies only missing recovery context, never acceptance or authority.
 
 Ordinary completion and checkpoint commits leave Change open; a generic commit request does not establish final delivery. At established final delivery or an explicit close request, load [delivery closeout](references/closeout.md). workflow.closeout is ask (default), auto or manual; no setting grants Git, push, publication, deployment, approval or human acceptance authority.
 
@@ -66,7 +66,8 @@ Operate command-owned state through RSP commands. Persist only open and archived
 
 Other conditional procedures:
 
-- [Setup and repair](references/setup-repair.md) for initialization, audit or repair.
+- [Architecture knowledge](references/architecture.md) when coordinating work on modeled structure or responsibilities.
+- [Setup and repair](references/setup-repair.md) before initialization, managed-asset inspection, upgrade or repair.
 - [Groups and dependencies](references/groups-dependencies.md) for grouped work.
 - [Context migration](references/context-migration.md) when a root/relevant legacy CONTEXT-MAP.md is found or migration requested; preserve context, discovery alone grants no migration.
 - [Conflict handling](references/conflict-handling.md) for an intersecting Git operation.

package/skills/rsp/references/architecture.md

@@ -0,0 +1,39 @@
+# Architecture knowledge
+
+Use when a task concerns a project's structure, responsibilities, dependencies or
+architecture model. Follow relevant CONTEXT navigation to `.rsp/architecture.json`
+when present. The model maps current structure and relationships to documents;
+Specs own contracts and decisions retain rationale. An absent model does not
+require creation or block work.
+
+## Read
+
+Read only the relevant nodes, relations and bound documents, using the selected
+project CLI's `rsp architecture --node <id> --json` or the model directly.
+Use the current checkout/worktree's content. Treat the model as navigation and
+check decisive claims against the owning code and contracts; it does not override
+them or establish a mandatory Skill execution order.
+
+## Update
+
+When an authorized implementation changes modeled responsibilities, boundaries,
+dependencies or document bindings, update the affected model entries with the
+implemented facts. Preserve stable IDs for unchanged identities and keep detailed
+contracts in their documents. Proposed structure stays in the Change Design until
+implemented. Read-only Shape and Review report discrepancies without editing.
+If a needed model correction is outside the authorized scope, return the gap to
+the owner rather than silently expanding the task.
+
+When authorized to add a model, register one link in root CONTEXT, reusing an
+existing entry or creating minimal CONTEXT if absent. Installation or upgrade
+alone neither creates the model nor rewrites context.
+
+## Check
+
+For affected model entries, implementation self-checks and Review compare the
+represented responsibilities and relations with the changed code and contracts.
+After model or bound-document changes, use `rsp doctor` for structural and
+document/chapter-reference checks, reusing applicable passing evidence under the
+ordinary verification rules. A pass does not establish semantic agreement with
+implementation. Keep this within the task's existing checks and review scope;
+unrelated tasks need no whole-model read, extra review or unconditional doctor run.

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

@@ -21,9 +21,9 @@ If inspection reports only `RSP project requires an update` without update autho
 Apply this sequence only for established final delivery or preparation/audit of closure. Routine knowledge updates use the bounded writeback above.
 
 1. **Verify outcome facts.** Establish the approved delivered result from current implementation, authoritative contracts and decisive evidence. Distinguish passed, failed, unverified and superseded conclusions. This establishes truth, not a preliminary full-document rewrite; plans and recovery notes alone cannot establish current facts.
-2. **Distill Focus as needed.** Integrate only verified outcomes, evidence applicability or material limits missing from Change; no useful addition means no edit. Recovery state alone supplies no required acceptance evidence.
+2. **Distill Focus as needed.** Integrate only verified outcomes, evidence applicability or material limits missing from Change; no useful addition means no edit. Resolve or safely transfer outstanding recovery obligations before discarding their notes. Recovery state alone supplies no required acceptance evidence.
 3. **Write back knowledge as needed.** Using the verified result and Change delta, decide current facts and lasting rationale independently using the methods below. Update existing owners only when justified. No stable change means no edit; a delivered contract that leaves its authoritative Spec stale requires correction before closeout. Do not copy the whole Change or its verification history into knowledge documents.
-4. **Converge the whole Change.** After necessary writeback, use `rsp-doc` and its artifact-lenses method when available to reconcile all six sections as one final document. Retain the delivered delta, relevant design, task outcomes, candidate-bound verification, material failures/limits and knowledge-update references; leave already-converged text unchanged. Reconcile superseded, misplaced or duplicate content. Keep process history in its report or conversation, Group integration conclusions in the Brief, and transient operation permissions distinct from product boundaries. Without Doc, perform the same bounded convergence locally without installation or replacing required Review.
+4. **Converge the whole Change.** After necessary writeback, use `rsp-doc`'s artifact method to reconcile all six sections under the [current work record rules](work-model.md#current-work-records). Retain the delivered delta, relevant design and result comparisons, applicable scoped evidence, material failure dispositions/limits and knowledge-update references; leave already-converged text unchanged. Remove obsolete plans and duplicate or misplaced content without moving history into a new report or Focus. Group integration conclusions stay in the Brief. Without Doc, perform the same bounded convergence locally without installation or replacing required Review.
 5. **Check final consistency, then archive when authorized.** Compare the final Change and knowledge owners with the verified result; an earlier review of another revision or a passing readiness command proves no text quality. Reuse applicable implementation/test evidence, check new knowledge/document edits, and fill only missing or invalidated coverage. Document-only writeback and archive preparation do not themselves invalidate code checks. Complete separately required Review before the archive gate below. Fix prose defects in scope, but return material contract or implementation contradictions to the decision, implementation or verification owner. Unresolved Required failures still block closeout.
 
 These are dependency constraints, not persisted phases or mandatory separate tool calls. Edit only what needs writeback; required updates cannot be waived. Resolve stale statements from verified outcomes. Preserve settled planning, unrelated style and original evidence/verdict owners; add no no-op reports. Author checks establish no independent review.

package/skills/rsp/references/focus-continuation.md

@@ -2,11 +2,15 @@
 
 Load when tracked work needs a recovery snapshot, a Capsule needs inspection or replacement, or a portable continuation handoff is required. Same-session worker continuation alone uses [coordinated interruption and recovery](coordination-recovery.md), not this format. Short direct tasks need no new WorkRef or Capsule.
 
-Core owns the selected WorkRef's replaceable recovery snapshot. At a pause, handoff or recovery-relevant checkpoint, update it only when the Change, evidence and existing snapshot are insufficient for safe continuation. Retain the minimum current state, evidence pointers, next action and resume conditions. Ordinary same-session progress needs no update. Use `rsp focus <work-ref> --capsule-file <path|->` to replace, not append. Respect nearer mutation restrictions. For Group work use the selected child's Capsule, not a Group marker. Empty markers remain valid.
+Core owns the selected WorkRef's optional recovery snapshot. At a pause, handoff or recovery-relevant checkpoint, create or replace it only when the existing snapshot is insufficient or stale. Keep only context unavailable from the Change, current workspace or existing evidence whose loss would make continuation unsafe or require costly repeated discovery. Ordinary same-session progress needs no update. Refer to Change items rather than maintain another task, verification or blocker list; a delivery blocker belongs in Change, with only missing operational detail here.
+
+Retain the current recovery position, necessary evidence pointers, next action and resume conditions. Unfinished experiments, pending cleanup and operations with uncertain effects may matter; a ruled-out approach needs only its still-applicable conclusion when repeating it would be costly. Do not record command sequences, attempts, repair/test rounds or how the diagnosis evolved. Use `rsp focus <work-ref> --capsule-file <path|->` to replace the snapshot as facts change, not append history.
+
+Remove notes when their obligations are discharged, obsolete or safely transferred to their existing owner. Do not clear unresolved effects or hard-to-reconstruct safety context merely to shorten the snapshot. An empty capsule file clears notes while retaining the focus marker; cleanup alone does not authorize unfocus, closure or deletion of evidence. Respect nearer mutation restrictions. For Group work use the selected child's Capsule, not a Group marker.
 
 The existing v1 format is bounded to 4096 UTF-8 bytes: one leading `<!-- rsp-focus:v1 -->`, blank lines, exactly one non-empty single-line `Current`, `Evidence`, `Next`, and at most one non-empty single-line `Resume check`. No other non-empty lines are valid. Keep raw logs/diffs, runtime identifiers, host paths, credentials and execution history out. The marker path selects work; its notes grant no authority or acceptance and are never worker transport or controller state.
 
-Before closeout, use the [durable-writeback sequence](durable-review.md): verify outcome facts, distill useful Focus facts and update stable knowledge as needed, then converge the whole Change and check final consistency before authorized archive. No useful Focus addition requires no edit; it waives neither necessary knowledge correction nor final Change convergence. Detailed evidence stays with its existing owner, never solely in the Capsule.
+Before closeout, use the [durable-writeback sequence](durable-review.md) to establish outcome facts and update their owners as needed. No useful Focus addition requires no edit; recovery obligations still need disposition before clearing the marker. Detailed evidence stays with its existing owner, never solely in the Capsule.
 
 When accepted work remains, return a localized continuation with these semantic fields in order: `WorkOwner`, `Authority`, `Current state`, `Changed artifacts`, `Fresh verification`, `Blockers`, `Next action`. A Change WorkOwner uses its WorkRef; a Group WorkOwner uses its Group reference and direct child Changes. Preserve technical values; the continuation is not a second state store.
 

package/skills/rsp/references/setup-repair.md

@@ -1,12 +1,15 @@
 # Setup and repair
 
-Load before initializing, inspecting or updating RSP-managed assets.
+Load before initializing, inspecting or updating RSP-managed assets, including upgrades.
 
 Use the runtime selected in AGENTS: an exact package pin in .rsp/version for
 consumer projects, or this checkout's built CLI when .rsp/source explicitly
-selects source mode. The two markers are mutually exclusive. An authorized package
-upgrade deliberately selects its exact target CLI; source update keeps the local
-selection. Never silently resolve @latest; package fetching requires separate authority.
+selects source mode. The two markers are mutually exclusive. Do not substitute a
+published package for source mode because version strings match. An authorized
+package upgrade deliberately selects its exact target CLI and runs its update for
+the complete managed environment; source update keeps the local selection. Never
+substitute @latest, a version range or an unverified global binary; package fetching
+requires separate authority. Upgrade notices grant no migration authority.
 
 - **Initialize:** rsp init [--agents-mode managed|print] [--with-project-setup] creates missing scaffolding and the complete core suite. Existing user files remain unchanged. Retry an incomplete init with the same target; repeated init cannot adopt a different pinned version. Retired Rules require update instead.
 - **Update:** rsp update replaces the selected package's owned assets; optional --dry-run previews without writes. No separate installation or migration switches are needed.
@@ -33,8 +36,10 @@ Concurrent external edits and crash recovery are unsupported. No recovery entry
 
 ## Project knowledge
 
-Keep architecture in .rsp/specs/design.md, contracts in domain Specs, navigation in
-CONTEXT and scoped instructions outside the managed AGENTS block. Use rsp specs to
+Keep architecture contracts in .rsp/specs/design.md, domain contracts in their Specs, navigation in
+CONTEXT and scoped instructions outside the managed AGENTS block. For an existing
+or explicitly requested architecture model, use [architecture knowledge](architecture.md)
+for its relationship to contracts and its context entry. Use rsp specs to
 query knowledge. A legacy context map selects [context migration](context-migration.md);
 discovery alone grants no merge or deletion. Semantic writeback and archive decisions
 remain outside deterministic setup. Missing required Skills stop dependent work;

package/skills/rsp/references/work-model.md

@@ -1,6 +1,6 @@
 # Shared work model
 
-Read when selecting, reporting or operating a tracked RSP owner and these definitions are not already available in the current context. Direct untracked work needs no RSP identity. This file defines identities, not a requirement to execute Core.
+Read when selecting, reporting or operating a tracked RSP owner, or writing/reviewing its records, and the relevant definitions are not already available in context. Direct untracked work needs no RSP identity. These shared definitions require no Core execution.
 
 ## Work shapes
 
@@ -24,4 +24,14 @@ Identity, focus, readiness, dependency state and capability availability grant n
 
 In a Change's Blockers, record only unresolved dependencies or decisions preventing required work. Write standalone `None` when none remain; keep non-blocking verification limits in Verify. Exact prerequisites use ``- requires `<work-ref>`: <reason>``. Other prose, including an explanation after `None`, remains an external blocker declaration.
 
-Use only the selected owner's relevant artifacts and authoritative project context. Installed files are shared across the suite, but separate workers do not inherit one another's loaded instructions. Reuse applicable definitions in the same context; obtain this file before depending on missing definitions. If the shared resource is unavailable, report an incomplete suite and stop identity-dependent actions rather than inventing a substitute or installing implicitly.
+Use only the selected owner's relevant artifacts and authoritative project context. Installed files are shared across the suite, but separate workers do not inherit one another's loaded instructions. Reuse applicable definitions in the same context; obtain this file before depending on missing definitions. If the shared resource is unavailable, report an incomplete suite and stop dependent actions rather than inventing a substitute or installing implicitly.
+
+## Current work records
+
+A Change retains six sections: Proposal, Spec, Design, Tasks, Verify and Blockers. During work it states the current authorized intent, approach and actual progress; at closeout it records the delivered outcome. Update affected content as facts change instead of appending rounds, dates or session summaries. Keep a date only when it matters to provenance or applicability. Record cleanup never authorizes dropping unmet scope or acceptance obligations.
+
+- **Tasks:** keep current checkable work and completion. Replace, split or merge tasks within authorized scope; reopen or rewrite invalidated results. Routine attempts, fixes, retries and individual check runs are not new tasks. Completion proves neither verification nor independent or human acceptance.
+- **Verify:** keep declared acceptance checks and their required/optional distinction, then retain only information needed to judge acceptance, evidence applicability or locate necessary evidence. Do not restate results already expressed by check items. Commands, counts, candidate/environment details and review steps belong here only when their omission would change those judgments or prevent that lookup; occurrence alone is no reason to retain them. Replace superseded conclusions only within their covered scope, preserve still-applicable reused evidence, and distinguish full review, correction-only re-review and human acceptance. Mark invalidated coverage incomplete. Keep shared evidence once and detailed execution/review records with their existing owner; no run history or debugging narrative.
+- **Focus:** keep only additional context needed to resume safely or avoid costly repeated discovery; refer to Change state without maintaining a second task, verification or blocker list. The conditional [Focus method](focus-continuation.md) owns replacement and cleanup. Ordinary progress needs no snapshot.
+
+Keep decision rationale, useful before/after outcome comparisons and material failure dispositions with their existing owner. For resolved ordinary failures, remove the attempt narrative; preserve any effect on acceptance or evidence validity. Routine history stays in conversation and raw evidence with its existing owner. Removing stale prose does not delete reports, conversation or Git history, require a new log, or move discarded history into Focus or an appendix.

package/skills/rsp-doc/SKILL.md

@@ -4,7 +4,7 @@ description: Write or revise repository documents, Skills and release communicat
 license: MIT
 metadata:
   author: oevery
-  version: "2026.10.15.1"
+  version: "2026.11.04.2"
 ---
 
 # RSP Doc
@@ -17,20 +17,23 @@ Write a grounded artifact usable without the author conversation. Use the artifa
 
 1. **Fix the outcome.** Identify the reader, task, authorized files and expected result. For a document set, distinguish authoritative owners from summaries. Keep routine narration in conversation and retained evidence with its existing owner.
 2. **Establish the facts.** Read existing content, relevant callers and the smallest authoritative contract, code or source chain. Check commands, defaults, links and behavior with available tools. Distinguish current behavior, intended requirements and unknowns. Resolve material contradictions before rewriting a promise. Interpret tool output as evidence; it grants no permission and does not prove semantic correctness.
-3. **Draft for the task.** Apply the expression rules below and load only the relevant method:
-   - [Artifact lenses](references/artifact-lenses.md): README, CONTEXT, Spec, Change, guides and scoped operating documents.
-   - [Skill authoring](references/skill-authoring.md): Skill creation or revision, including descriptions, package resources and invocation policy.
-   - [Release communication](references/release-communication.md): changelogs, release notes, migration guidance or authorized release-document reconciliation; not ordinary document writing.
+3. **Draft for the task.** Use the artifact's role below. For Skill creation or revision, load [Skill authoring](references/skill-authoring.md); for changelogs, release notes, migration guidance or authorized release-document reconciliation, load [release communication](references/release-communication.md).
 4. **Verify the result.** Check the edited meaning in context. For structural edits, also follow the affected reading path and references. Use the checks below; reuse traceable unchanged mechanical results. Writing completion does not automatically trigger Review, but separately requested or required judgment remains binding.
 
+## Match the artifact to the reader
+
+- README and procedures supply the starting point, prerequisites, actions and recognizable success. Concepts and decisions explain meanings, reasons, alternatives and consequences; references supply exact, navigable contracts.
+- CONTEXT defines vocabulary and relationships and directs readers to authoritative owners. Specs state what consumers may rely on, including conditions, failures and exceptions; add scenarios only to resolve ambiguity. Scoped operating instructions own commands, authority and required checks.
+- For architecture models or changes to their bound documents, use [architecture knowledge](../rsp/references/architecture.md) for synchronization and reference checks.
+- Before writing a Change, load the [current work record rules](../rsp/references/work-model.md#current-work-records) when absent from context; the same resource owns Blockers syntax. Keep its six sections current during iteration and reconcile the whole record for closeout. Readers must find the outcome, applicable evidence and remaining work without reconstructing attempts; preserve useful before/after results and decision reasons when removing chronology.
+
 ## Check facts and reading paths
 
 Use the checks relevant to the change:
 
-- Check whether readers can find information, understand conditions, act or judge compliance, and recognize unknowns.
 - Check affected links, anchors, examples and metadata with existing tools. Execute examples only within safe authorized scope.
+- Keep repository references portable: use project-root-relative file citations and document-relative Markdown links, following any existing machine-field path contract. Keep execution-root locations separate from durable file references; retain necessary external locations, original evidence and host-required display paths without copying local checkout prefixes into authored repository references.
 - For linked artifacts, compare shared claims, terminology, defaults and handoffs against their authoritative owner. Correct authorized summaries and links without copying full definitions or changing unassigned owners. Report out-of-scope contradictions to their owner.
-- Recheck facts, quantifiers, defaults, failures, permissions and terminology after editing. Report actual checks and remaining gaps.
 - API comments and embedded guidance: compare claims with their contract and implementation without assuming either side correct. Keep ordinary inline comments locally accurate and useful: retain constraints, rationale or usage that nearby code does not make clear, and remove restatement that adds no information; no full writing workflow is needed. Compiler/tool annotations retain implementation ownership.
 - Examples: label illustrative pseudocode or incomplete snippets; check copyable commands against real prerequisites, outcomes and safe use without inferring execution or installation authority.
 
@@ -47,12 +50,12 @@ For a failed command, inspect cause and actual effects before recovery. Change a
 
 ## Write precisely
 
-- Organize around the reader's task: operations need actions and success signals; contracts need guarantees and exceptions; design needs reasons and tradeoffs. Explain unfamiliar concepts through their task-relevant meaning; include mechanisms needed to reason, troubleshoot or assess guarantees. Reference entries need no forced tutorial. Do not force every artifact into an action list or closing next step.
+- Explain unfamiliar concepts and mechanisms needed for the reader to reason, troubleshoot or assess guarantees. Do not force every artifact into an action list, tutorial or closing next step.
 - State the actor, action and object directly. Prefer short, complete sentences when easier to follow. Separate independent actions; preserve causal and conditional links. Give each paragraph one useful purpose. Put prerequisites before use, conditions beside actions and exceptions beside their rules. Keep necessary local context; link branch-only detail with its reading condition and purpose.
 - Number steps when their order matters; make each step a bounded action. Use peer bullets for independent items and connected prose for reasoning. Use tables for useful fixed mappings/comparisons, not branching Skill judgments.
-- Remove empty introductions, rhetorical framing, repeated conclusions, filler and irrelevant chronology. Keep author voice, decision-relevant explanations, necessary reasoning and required audit evidence. Replace abstract aspirations with concrete actions. For prescriptive rules, use contrasts or counterexamples only to resolve likely ambiguity. Retain explanatory comparisons needed for understanding, decisions or migration; merge equivalent examples. No fixed sentence length, list size or compression ratio defines quality.
+- Remove filler, repetition and irrelevant chronology. Keep author voice, decision-relevant reasoning and required audit evidence. Prefer concrete actions; use contrasts or examples when they resolve a real ambiguity. No fixed sentence length, list size or compression ratio defines quality.
 - Preserve negation, conditions, exceptions, permissions, quantities, units and certainty. Merge failure explanations with the same decision effect. Retain permission, outcome, stop and safe-recovery conditions, including rare boundaries preventing unauthorized action, serious harm or unsafe replay. Keep incident details with their evidence owner. Do not turn a proposal or unknown into a verified fact. Shorter wording proves no behavioral equivalence.
-- Wording edits preserve meaning, information ownership, heading anchors and technical literals: code blocks, commands, paths, identifiers, links, versions and numeric values. Structural edits may merge, move or reorder content within scope while preserving completeness and references. Behavior changes and technical corrections need their own scope and checks; shortening prose grants neither.
+- Wording edits preserve meaning, ownership, anchors and technical literals. Structural edits may merge, move or reorder content within scope, checking completeness and references. When the request authorizes simplifying instructions, remove an unnecessary obligation rather than merely restating it; verify the remaining behavior and safety. Wording-only authority does not permit that contract change.
 - Use ordinary words for conjunctions. Preserve technical syntax; reserve | for closed alternatives, / for established pairs, → for defined transitions and : for label/value boundaries.
 
 ## Preserve ownership

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

@@ -6,7 +6,7 @@ Use for creating or revising a Skill. Apply Doc's language, expression and autho
 
 - For creation, resolve the goal, inputs and observable result before choosing structure.
 - Honor an explicit destination; otherwise use project instructions and host constraints. Check for existing content before creating files.
-- For revision, inspect the authored package and its callers. Name the failure or missing capability; preserve unrelated adaptations.
+- For revision, inspect the authored package and its callers. State the revision's purpose and supporting evidence; preserve unrelated adaptations.
 - Start with SKILL.md. Use a host initializer when useful; add resources only for a real task need.
 - Preserve existing packages and global configuration. Creation is not installation or publication.
 
@@ -20,7 +20,7 @@ Use for creating or revising a Skill. Apply Doc's language, expression and autho
 ## Make execution concise
 
 - Organize the ordinary task around its goal, necessary inputs, authorized action, completion evidence and real stops. Choose headings for the task, not a universal template. Continue ordinary authorized checks. Prescribe order only for correctness, safety or contract dependencies.
-- Before adding an instruction, reuse or revise the rule already owning that decision. Merge repeated entry/step/return explanations and failure conditions with the same effect. For example, combine "read the guide" and a later "only for release notes" into "for release notes, read the guide." Add an incident-derived constraint only for a reusable contract gap, not noncompliance or tool/fixture failure alone. Preserve trigger, authority, failure and output meaning.
+- Revise the existing owner before adding a rule for the same decision. Merge repeated conditions and remove instructions no longer needed within the authorized contract delta. An incident warrants a new constraint only for a reusable gap, not noncompliance or tool/fixture failure alone.
 - Keep shared guidance and necessary local safety context visible. Link substantial branch-only knowledge with its reading condition and purpose; ordinary tasks need no unrelated recovery or delivery detail. A short Skill needs no router or extra files. Split or merge resources only when it improves the reading path, not when it merely moves mandatory text. Honor the declared distribution boundary. RSP ships as a suite: shared concepts may reference Core resources directly; independent Skills keep their own resource closure. Never depend on a maintainer repository Spec.
 - Retain generic teaching or old model-compensation instructions only for a current task-specific need. A newer model label alone proves neither redundancy nor safe removal of a constraint.
 - Reuse tools for deterministic work; the Skill owns method selection and interpretation within its authority. Preserve named mandatory commands, provenance, independence and protected operations when replacing a tool-only method. Add a script only when repetition or fragility warrants it, and run changed helpers safely. Check incoming links before moving resources.

package/skills/rsp-implement/SKILL.md

@@ -4,7 +4,7 @@ description: Diagnose unexplained symptoms read-only or implement authorized bou
 license: MIT
 metadata:
   author: oevery
-  version: "2026.10.16.2"
+  version: "2026.11.04.3"
 ---
 
 # RSP Implement
@@ -22,12 +22,18 @@ Query RSP settings only for a decision depending on an unresolved value. Use the
 Mutation requires one of:
 
 - A bounded direct task with explicit scope and acceptance; no WorkRef or RSP writeback.
-- An explicit or AI-resolved ready Change from the FocusSet, with settled acceptance and exact product authority. Multiple markers are candidates; a Group Brief is context, not executable work.
+- 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.
+
+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.
@@ -45,19 +51,17 @@ Git delivery, publication, deployment, approval, and out-of-scope deletion requi
 
 ## Admit boundaries and permanent tests
 
-Inspect existing owners and callers before adding logic. Reuse behavior and business rules that satisfy the accepted outcome. Keep each rule and its invariants with one clear owner so ordinary changes stay local. Similar code with different responsibilities may stay separate; do not force reuse through unrelated flags or speculative interfaces.
+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.
 
-Add a validator, fallback, defensive copy, capability, state machine, compatibility path or public option only for an explicit requirement or an evidenced producer, production consumer, trust/lifecycle transition and material consequence. Typed same-process values, imagined callers and test/document-only consumers establish no production boundary.
+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.
+
+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.
 
-Before creating or extending a permanent test:
+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.
 
-- **Value:** reuse sufficient test, type/static, build or acceptance evidence first. Otherwise identify the observable consequence, distinct plausible regression at its production seam, evidence gap and proportionate maintenance cost.
-- **Expectations and setup:** derive outcomes from the agreed contract or an independent example, not the tested computation. If fixture construction, platform behavior, fault injection or scheduling leaves the target condition uncertain, inspect the arranged state or use a targeted probe. This requires no precondition assertion or mutation run for every test.
-- **Real consequence:** use real collaborators when fast, deterministic and practical; otherwise substitute the necessary boundary while preserving the relevant behavior. Exercise consumer-owned behavior through covered downstream adapters or forwarding hops. A nearest-spy, emitted-message or forwarding assertion covering only an already-covered hop adds insufficient evidence, even in an existing test file.
-- **Assertions:** one final-message assertion can suffice for the agreed consumer outcome. Pin error details or interaction counts/order only when the contract needs them; otherwise assert outcomes and effects, including rejection.
-- **Maintenance:** keep scenario-defining inputs and assertions visible; share incidental setup for clarity rather than repetition alone. Keep nearby tests protecting independent consequences, but do not allocate tests per touched file, wrapper, hop, branch or constant.
+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.
 
 ## Continue within the evidence boundary
 
@@ -67,7 +71,7 @@ Stop for a repeated failure without new discriminating evidence, non-convergence
 
 ## Implement and verify
 
-Implement the smallest complete slice. Update authorized Change sections only for necessary plan/contract changes, outcomes, blockers and scoped verification. Update Tasks after outcomes exist. Keep routine narration in conversation and required or tool-owned evidence with its existing owner; copy no execution history into Change or a new process record. Direct work reports outcomes without RSP artifact mutation.
+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.
 
 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.
 

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. 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.
 
@@ -43,6 +41,8 @@ When fixed reviewed artifacts include changelogs, release notes, migration guide
 
 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.
 
+When the reviewed scope affects modeled structure, responsibilities, dependencies or bindings, apply [architecture knowledge](../rsp/references/architecture.md) within that scope.
+
 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.
 
 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.
@@ -58,16 +58,16 @@ Responses follow explicit language instruction, personal instructions, then conv
 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. 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.
+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 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.
 
-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`: required/optional checks proving settled acceptance, not adding new public requirements; then applicable scoped results and gaps;
 - `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.