@oevery/rsp 4.0.0 → 4.2.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@oevery/rsp",
   "type": "module",
-  "version": "4.0.0",
+  "version": "4.2.0",
   "description": "RSP (Reliable Software Practice), a repository-native engineering workflow for humans and AI agents",
   "author": "oevery",
   "license": "MIT",
@@ -40,10 +40,11 @@
     "skills:package-check": "node scripts/skill-package-check.mjs",
     "prepublishOnly": "pnpm run release:check",
     "release": "release-it",
-    "build": "tsup",
-    "dev": "tsup --watch",
+    "build": "node scripts/build.mjs",
+    "dev": "node scripts/dev.mjs",
     "docs:build": "vitepress build docs",
     "docs:check": "node scripts/docs-check.mjs",
+    "doctor": "node dist/cli.mjs doctor",
     "docs:deploy": "wrangler deploy",
     "docs:dev": "vitepress dev docs",
     "docs:preview": "vitepress preview docs",
@@ -55,9 +56,12 @@
     "test:diagnostics": "vitest run --config tests/diagnostics/vitest.config.ts",
     "test:pack": "node tests/code/package/package-check.mjs",
     "test:skills": "uv run --frozen --project tests/skills python tests/skills/evaluate.py",
-    "release:check": "pnpm run build && pnpm run typecheck && pnpm run lint && pnpm run test:code && pnpm run test:skills check && pnpm run skills:security-check && pnpm run docs:check"
+    "release:check": "pnpm run build && pnpm run doctor && pnpm run typecheck && pnpm run lint && pnpm run test:code && pnpm run test:skills check && pnpm run skills:security-check && pnpm run docs:check",
+    "test:viewer:browser": "node tests/code/architecture/browser-check.mjs"
   },
   "dependencies": {
+    "@likec4/core": "1.60.0",
+    "@likec4/layouts": "1.60.0",
     "citty": "^0.2.2",
     "hast-util-from-html": "^2.0.3",
     "ink": "~8.0.0",
@@ -72,19 +76,34 @@
   },
   "devDependencies": {
     "@antfu/eslint-config": "^9.5.1",
+    "@likec4/diagram": "1.60.0",
+    "@radix-ui/react-dialog": "1.3.1",
+    "@radix-ui/react-select": "2.4.1",
+    "@radix-ui/react-slot": "1.5.0",
+    "@radix-ui/react-tooltip": "1.4.1",
     "@release-it/conventional-changelog": "12.0.2",
+    "@tailwindcss/cli": "4.3.4",
     "@types/hast": "^3.0.5",
     "@types/mdast": "^4.0.4",
     "@types/node": "^22.20.1",
     "@types/react": "^19.3.0",
-    "eslint": "^10.13.0",
+    "@types/react-dom": "^19.3.0",
+    "class-variance-authority": "0.7.1",
+    "clsx": "2.1.1",
+    "esbuild": "^0.28.2",
+    "eslint": "^10.14.0",
     "ink-testing-library": "^4.0.0",
-    "release-it": "21.1.1",
+    "mermaid": "12.3.0",
+    "playwright-core": "1.64.1",
+    "react-dom": "~19.3.1",
+    "release-it": "21.1.2",
     "smol-toml": "^1.9.1",
+    "tailwind-merge": "3.7.0",
+    "tailwindcss": "4.3.4",
     "tsup": "^9.0.0",
     "typescript": "^5.9.3",
     "vitepress": "^1.6.4",
-    "vitest": "^5.0.5",
-    "wrangler": "^4.151.3"
+    "vitest": "^5.1.0",
+    "wrangler": "4.157.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.06.1"
 ---
 
 # RSP Core
@@ -15,15 +15,17 @@ Carry the authorized request through execution, applicable evidence and needed k
 
 Before mutation, read nearest instructions and relevant CONTEXT; establish intent, authority and the existing owner from evidence. Use known paths and discover missing context as needed. An explicit WorkRef wins; multiple focus markers alone do not block work. Preserve dirty work and its owner. Before switching owners, check overlapping product and knowledge paths; overlap transfers no authority.
 
-- **Direct:** a clear bounded request needing no durable continuity. Create no Change and run no tracking preflight merely to execute it.
-- **Change:** one delivery/acceptance boundary needing sustained work or cross-session recovery. Read its six sections and relevant Specs; Focus is only a sparse recovery pointer.
+- **Direct:** a local, explicit modification with a clear result and verification boundary. Interface changes, multiple files, strict checks or repeated execution alone require no Change or tracking preflight.
+- **Change:** one delivery/acceptance boundary whose implementation needs a shared record of related behavior, responsibility, compatibility or acceptance decisions. Actual staged delivery, handoff or deferred obligations can also require this record. It need not span sessions or split into independently deliverable parts. Read its six sections and relevant Specs; Focus is only a sparse recovery pointer.
 - **Group:** independently acceptable/deliverable child Changes with dependencies or integration obligations. Read the Brief then select a child; the Brief is not executable work. File count, complexity and agent count alone do not create a Group.
 
+Read-only advice, diagnosis and review create no implementation Change. Establish actual impact before selecting new work; reconsider when authorized scope materially expands, not for routine corrections or failed checks. Continue a matching existing owner only for the same outcome or remaining obligations; shared files or modules alone establish no ownership. A short plan or design discussion alone requires no Change. Preserve explicit user and project tracking requirements.
+
 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:
+Select capabilities from their descriptions and the task contract. Executors reuse applicable entrypoint and method text already in context, load missing or changed instructions, and inspect sources; Core consults method details when needed for its own work or a concrete coordination question. Select the responsibility needed now:
 
 - rsp-shape: bounded read-only design or authorized planning; reopen planning only for material unresolved choices.
 - rsp-implement: diagnosis, authorized implementation or accepted-finding correction, including ordinary own checks.
@@ -32,7 +34,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 +42,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; apply the current work record rules to Change summaries. 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,9 +58,9 @@ 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.
+For tracked work, apply the [current work record rules](references/work-model.md#current-work-records) during execution. Load them only 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.
+Ordinary completion and checkpoint commits leave Change open. Before a tracked commit, inspect actual remaining Tasks: incomplete work selects a checkpoint; all Tasks complete selects [delivery closeout](references/closeout.md), even with missing or failed verification. Reuse an explicit applicable checkpoint or closure choice without asking again. Also load closeout for established final delivery or an explicit close request. workflow.closeout is ask (default), auto or manual; no setting grants Git, push, publication, deployment, approval or human acceptance authority.
 
 For necessary stable-knowledge updates, load [durable writeback](references/durable-review.md) to establish facts, update their owners and reconcile affected records. Final delivery or closure additionally requires whole-Change convergence and consistency checks. Reuse applicable evidence and fill missing or invalidated coverage and separately required review. Already-accurate records need no edit; current readiness is a lifecycle observation, not semantic acceptance.
 
@@ -66,7 +68,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/closeout.md

@@ -1,16 +1,16 @@
 # Final delivery and lifecycle closeout
 
-Load for an established final-delivery boundary, an explicit close request, or a delivery question requiring checkpoint classification. Ordinary completion never activates closeout. A generic commit request defaults to a checkpoint unless final delivery is already established; checkpoints keep Change open and require only the authorized slice and applicable evidence.
+Load for an established final-delivery boundary, an explicit close request, or a tracked commit whose Tasks are complete. Inspect actual remaining work and correct inaccurate records before classification. Task completion triggers a closure decision, not archive eligibility; missing or failed checks do not suppress the decision. Ordinary completion without a delivery request leaves work open. Reuse an explicit applicable checkpoint or closure choice. Checkpoints keep Change open and require their own applicable evidence.
 
 ## Decide closure independently of Git
 
 Use the validated workflow.closeout setting from rsp config --json:
 
-- ask (default): prepare a concrete final boundary, applicable evidence and required knowledge/Change updates, then ask whether to close before terminal staging. Reuse explicit closure authority already granted; do not ask twice.
-- auto: close eligible work at established final delivery without another closure request, subject to nearer denial.
+- ask (default): inspect the concrete boundary, existing evidence and specific gaps, then ask before staging whether to finish necessary checks and records, archive when eligible and commit if authorized, or make only an eligible checkpoint and leave work open. Do not require every check or final-record update before asking. A selected conditional closeout authorizes its necessary preparation and eligible archive; do not ask again when gates pass.
+- auto: prepare closeout for a completed-task delivery or established final delivery and close only eligible work, subject to nearer denial.
 - manual: close only on an explicit close request. Authorized final commits may leave work open and must report that fact.
 
-Explicit refusal keeps work open. A decision to leave it open does not block an otherwise authorized commit. Neither policy, readiness nor archive grants Git authority. An explicit standalone close request can close eligible work without a commit. Do not interpret finishing implementation, a pass, a successor task or elapsed time as final delivery.
+Explicit refusal keeps work open. A decision to leave it open does not block an otherwise authorized, verified commit. Neither policy, readiness nor archive grants Git authority. An explicit standalone close request can close eligible work without a commit. A pass, a successor task or elapsed time alone selects no closure. After closeout is selected, resolve failures within existing authority; if blocked, report the gap without silently falling back to a checkpoint commit.
 
 ## Reconcile the final boundary
 

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

@@ -21,10 +21,10 @@ 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; clearing Focus cannot substitute for knowledge writeback.
 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.
-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.
+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), including Verify admission. Retain the delivered delta, relevant design and knowledge-update references; leave already-converged text unchanged. Remove obsolete plans and duplicate or misplaced content. 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.** 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. Retain separately required Review as an unresolved obligation until its result is available. Fix prose defects in scope, but return material contract or implementation contradictions to the decision, implementation or verification owner. Return unresolved Required failures with the convergence result.
 
 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.
 
@@ -75,10 +75,7 @@ Create or update a Decision Record only for a hard-to-reverse or surprising choi
 
 Never use generated indexes, archives, or the managed RSP block as ordinary writeback targets. Keep narrative history, debugging notes, task chronology, and transient evidence out of Specs and Decisions.
 
-## Prepare the Change for archive
+## Return the convergence result
 
-Before archive, require the converged final Change, completed or unnecessary knowledge writeback, applicable passing verification, current readiness and every separately required Review clean. Authorized archive preserves Change and clears its Focus marker; clearing the Capsule cannot substitute for writeback. Archive grants no local commit authority.
-
-## Deliver with explicit boundaries
-
-[Delivery closeout](closeout.md) owns checkpoint/final classification, the ask/auto/manual closure decision, Group-close sequence and exact Git handoff. Ordinary completion leaves work open. Apply the selected policy and current gates regardless of delegation. Git delivery separately needs explicit authority for one independently reviewable logical commit; closure grants none. Reuse applicable evidence.
+Return the converged records and unresolved gaps to [delivery closeout](closeout.md),
+which owns the closure decision, archive gates and Git handoff.

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,12 +1,12 @@
 # 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
 
-Direct work is a clear bounded request without durable continuity needs. Change retains one acceptance/delivery boundary for sustained work or recovery. Group coordinates independently acceptable/deliverable child Changes with dependencies or integration obligations. Complexity, file count and worker count alone select neither Group nor delegation. Agent topology is a separate execution choice.
+Direct handles local explicit modifications. Change retains one acceptance/delivery boundary whose related implementation decisions or actual staged, handoff or deferred obligations need a shared record. Session duration, interface edits and strict verification alone do not select a Change; independent slices are not required. Group coordinates independently acceptable/deliverable child Changes with dependencies or integration obligations. Complexity, file count and worker count alone select neither Group nor delegation. Agent topology is a separate execution choice. Core owns selection and scope reassessment; existing ownership follows the same outcome or remaining obligations, not shared paths.
 
-Ordinary completion and checkpoint commits leave a Change open. Final delivery or an explicit close request uses the closeout policy; reopen is exceptional recovery, not the normal iteration path.
+Ordinary completion and checkpoint commits leave a Change open. A tracked commit with completed Tasks, established final delivery or an explicit close request uses the closeout policy. Task completion triggers the decision even when verification remains incomplete; eligibility still gates archive. Reopen is exceptional recovery, not the normal iteration path.
 
 ## Identity and ownership
 
@@ -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:** allow only Required/Optional checklists and an optional `### Conclusions` with short, non-nested bullets. No prose paragraphs, tables, logs or process subsections. Check applicable passes; uncheck failed, unrun or invalidated coverage. Revise check items when authorized scope or acceptance changes without dropping unmet obligations. An item may include a brief result or evidence locator, not repeated results, run counts or repair history. Conclusions hold only current acceptance limits, evidence applicability conditions or required failure dispositions that the checklist cannot express; one fact per bullet. Replace stale conclusions rather than append rounds. Preserve full-review, correction-only re-review and human-acceptance scope. Remove resolved findings unless they still affect acceptance, evidence reuse or required audit. Keep detailed evidence with its existing owner.
+- **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 and useful outcome comparisons in their owning sections; they do not exempt Verify text from the admission rule above. Do not relocate discarded narration into another section, Focus, an appendix or a new report. Prose cleanup does not remove tests, raw evidence, reports, conversation or Git history.

package/skills/rsp-commit/SKILL.md

@@ -4,7 +4,7 @@ description: Inspect or create one authorized exact-scope local commit for direc
 license: MIT
 metadata:
   author: oevery
-  version: "2026.10.16.1"
+  version: "2026.11.06.1"
 ---
 
 # RSP Commit
@@ -36,7 +36,7 @@ Purpose is separate from kind:
 - A checkpoint keeps the Change open and delivers a verified current slice without claiming completed acceptance, closing an issue or requiring archive.
 - A terminal delivery claims completion only for its selected boundary. Tracked terminal inputs require complete Tasks, decisive Required Verify and no active blocker; legacy unclassified Verify is Required. Optional omissions remain explicit but do not block. Direct work uses its own acceptance, not an invented lifecycle gate.
 
-A generic commit request is a checkpoint unless final delivery is already established. For tracked final delivery, resolve the closure decision through [Core closeout](../rsp/references/closeout.md) before staging, including direct invocation; do not repeat an already settled decision. Commit pauses for its owning capability to perform necessary writing or authorized lifecycle work. Lifecycle authority stays upstream. If terminal delivery includes authorized archive or Group closeout, require that action and its inspected diff before staging. Do not archive, update Specs or clean up a Change inside Commit. A valid explicitly authorized local commit without lifecycle authority does not gain it or require an invented archive.
+Before staging a tracked commit, inspect the selected owner's Tasks and actual remaining scope. Incomplete Tasks select a checkpoint; all Tasks complete selects [Core closeout](../rsp/references/closeout.md), even when Required checks or review are incomplete or failed. Generic commit wording must not bypass that decision. Reuse an explicit applicable checkpoint or closure choice; do not ask twice. For multiple included WorkRefs, assess their boundaries separately rather than infer Group completion. Commit pauses for its owning capability to correct stale records, perform necessary writing or authorized lifecycle work. If terminal delivery includes authorized archive or Group closeout, require that action and its inspected diff before staging. Do not archive, update Specs or clean up a Change inside Commit. A checkpoint still needs its own applicable verification; absent lifecycle authority neither grants closure nor prohibits an otherwise authorized checkpoint.
 
 ## Audit before staging
 

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 Verify admission and Blockers syntax. Keep its six sections current during iteration and reconcile the whole record for closeout. Apply those rules to existing text as well as additions.
+
 ## 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.
 
@@ -75,7 +79,7 @@ After final mutation, establish minimum sufficient evidence for tracked Required
 
 - Reuse traceable passing results when the tested boundary and relevant code, dependencies, configuration, tools, inputs and environment still apply. Phase changes and unrelated edits do not invalidate evidence.
 - Run missing, failed or invalidated checks and risk-justified additions, including checks affected by integration. Named checks retain their method and coverage; explicit reruns and independent execution remain binding.
-- For an unfixed method, choose the cheapest decisive existing test, static check, build or acceptance evidence; a new test is not required.
+- If no verification method is prescribed, choose the lowest-cost existing test, static check, build or other evidence that decisively establishes acceptance. A new test is not required.
 - Match the actual target, inputs, coverage and completion to the declared check. Invocation errors or incomplete observations do not by themselves prove a product defect. Record command, tested scope, result, source and omissions, distinguishing reused evidence from new execution. Failed, unavailable or untraceable evidence cannot establish completion.
 
 Before completion, apply the same admission criteria to retained tests. Remove disposable probes, fixtures and helpers that add no distinct future confidence unless retention is required by user, Change or project authority; establish sufficient evidence for the final retained state.