@oevery/rsp 3.3.0 → 4.0.0

package/skills/rsp-implement/references/diagnosis.md

@@ -0,0 +1,10 @@
+# Read-only diagnosis
+
+Load only for an unexplained, conflicting, intermittent, or multi-layer symptom, including a diagnosis-only request. A diagnosis request permits inspection and safe diagnostic commands, not edits to tests, instrumentation, fixtures, Change, or production. Those need separate exact mutation authority. A bounded symptom may be investigated without a ready Change or WorkRef. Do not silently turn diagnosis into a fix.
+
+1. Reproduce the smallest safe symptom or label supplied evidence and its limits; state expected and actual behavior.
+2. Trace the production path to the first divergence and confirm that the suspected seam is reached by a real consumer.
+3. Compare live hypotheses by distinct predictions and run the smallest safe discriminating check.
+4. Confirm only a cause explaining the symptom and excluding credible alternatives. Otherwise return unresolved with one next check or environmental blocker.
+
+Return confirmed or unresolved, evidence limits, cause and owning layer or remaining hypotheses, scope impact and next action. Diagnosis-only ends here read-only. Continue ordinary or risk-selected test-first implementation when existing fix authority covers the confirmed cause and owner. Stop for changed owner, scope, behavior, acceptance or authority. Diagnose subsequent check failures from new evidence and correct in scope. Stop when repeated attempts add no discriminating evidence or fail to converge. Write decisive facts to a tracked Change only with separate artifact authority.

package/skills/rsp-implement/references/finding-resolution.md

@@ -0,0 +1,21 @@
+# Bounded fixed-report finding resolution
+
+Load only for one fixed read-only Review report and its original comparison or file set. Inspect report identity (order, severity, title, location), current checkout, investigation authority and the smallest affected behavior chain. Read the selected Change when tracked; an authorized direct investigation needs no Change. A report alone grants no investigation, correction, fresh external checks or Git authority. Preserve unrelated staged, modified and untracked work.
+
+Give every Finding one evidence-backed disposition:
+
+- `accepted`: the issue is confirmed against the governing contract and bounded investigation evidence.
+- `rejected`: direct evidence disproves it or authority does not require the suggestion.
+- `needs-clarification`: intended behavior, reproducible trigger, owner or safe investigation scope is missing.
+
+Acceptance of a finding grants no correction authority. If only investigation is authorized, return dispositions and the smallest next action without edits.
+
+## Correct only with separate authority
+
+Confirm the intended correction and exact mutation boundary before fixing accepted Findings in one bounded pass. One correction may address several findings while preserving their separate dispositions.
+
+After the last edit, rerun affected or missing declared checks and reuse traceable passes for unaffected inputs. Preserve the original report and return dispositions, actual changed paths, comparison, checks and limits to the caller. Failure, unavailability or stale evidence cannot close a Finding; the implementer cannot certify review-clean.
+
+Use this method for one correction. For requested or required correction/review, [Core review convergence](../../rsp/references/coordination-review.md) owns fresh Review, continuation and pass limits. Direct invocation needs no earlier Core execution; its caller applies that loop only to the remaining authorized review obligation. For repair-only requests, return the correction and unperformed review status. Claim no acceptance or new review assignment.
+
+Stop this pass for changed scope or authority, an unresolved material requirement, `needs-clarification`, unsafe effects or missing decisive evidence. Do not start a second local retry counter or reset the caller's count. Return any unresolved Findings and the exact next decision or evidence needed.

package/skills/rsp-implement/references/test-first.md

@@ -0,0 +1,7 @@
+# Risk-selected test-first implementation
+
+Load only after a clear authorized behavior and owning production/test seam are known, when test-first is explicitly required or a concrete changed risk makes pre-mutation RED materially safer. An unexplained symptom goes to diagnosis first. Require test and product mutation authority and an executable focused check. A test cannot create product authority, a public compatibility path, or an unreachable state.
+
+Identify the observable consequence, one distinct plausible regression, gap in current checks and maintenance cost. Add the smallest test at the real consumer seam. Run it before production mutation and observe the expected behavioral RED. Syntax, fixture, environment or unrelated baseline failures are not RED. If it passes, improve the discriminating check or stop. Make the smallest GREEN change and rerun the same check. Refactor only for a concrete improvement while green; do not widen interfaces or add test-only hooks to force GREEN.
+
+Retain a permanent test only when it protects observable behavior or a real boundary with distinct future value and proportionate cost, unless user/Change/project authority requires retention. Otherwise remove the disposable probe and helpers safely, then rerun affected decisive checks and reuse applicable unaffected evidence for the final state. Record final verification and omissions, not test chronology. Stop for changed owner/authority, unexplained failure, unavailable decisive environment, or non-convergence; within the same authorized scope use new failure evidence to diagnose and correct without an artificial Core handoff. No Git, review, archive, or external action follows from this method.

package/skills/rsp-review/SKILL.md

@@ -1,72 +1,73 @@
 ---
 name: rsp-review
-description: Review an RSP-tracked code, document, or mixed change against a fixed comparison scope and project authorities without modifying files. Use for read-only findings before fixes, durable review, archive, or delivery; keep Code and Document states separate and never implement, commit, publish, or approve.
+description: Judge a fixed change or file set, or discover evidenced structural risks in an explicitly bounded repository or subtree. Authorized supporting checks are part of this read-only review; declared-check reporting alone belongs to Verify. No repair or approval.
 license: MIT
 metadata:
   author: oevery
-  version: "2026.08.19.1"
+  version: "2026.10.16.5"
 ---
 
 # RSP Review
 
-Review one fixed change scope without modifying it. Be concise, separate Code and Document judgment, and emit one deduplicated report.
+For tracked work, read the [shared work model](../rsp/references/work-model.md) when its identity and ownership definitions are missing from the current context. Use logical WorkRefs in commands and reports; cite file locations separately. Direct invocation needs no prior Core execution.
+
+Review one fixed change/file set or bounded structural scope read-only. Apply relevant perspectives and report each issue once. Run supporting checks within this review; named checks alone require no separate Verify pass. Honor combined requests and independent-evidence obligations. Judging implementation completeness grants no lifecycle completion or closeout authority.
 
 ## Fix scope and authority
 
 Resolve before judging:
 
-- one immutable comparison point or explicit fixed file set;
-- reviewed files, including relevant untracked files named by the user;
-- the selected Change and, for grouped work, its Group Brief;
+- one immutable comparison point or explicit fixed file set for change review; for structural discovery, one explicit repository/subtree boundary and its observed checkout state, without requiring a diff;
+- content being judged, including relevant untracked files named by the user, distinguished from reference-only authority and evidence;
+- the selected WorkOwner when tracked: a Change WorkRef, or a Group reference with its Group Brief and direct child Changes; an untracked review may use the explicit request and fixed file set without creating a Change;
 - nearest project instructions and only relevant Specs and Decision Records;
 - any caller-supplied implementation summary.
 
-Do not switch branches or mutate the worktree to discover scope. If the comparison point is unavailable, report the review as blocked. If multiple focus markers or authorities select different intent, name the conflict, mark dependent pipelines blocked, and do not guess. Continue only pipelines whose inputs remain authoritative.
+Do not switch branches or mutate the worktree to discover scope. If a required change-review comparison point is unavailable, report the review as blocked. If the selected WorkOwner, included WorkRefs, or authorities select different intent, name the conflict, mark dependent pipelines blocked, and do not guess; multiple focus markers alone are only candidate context. Continue only pipelines whose inputs remain authoritative.
+
+The user request fixes the requested outcome and allowed operations subject to nearest project instructions. The selected WorkOwner defines the intended delta: a Change uses its WorkRef, while a Group uses its Brief and direct child Changes. Specs define current contracts, boundaries, and necessary constraints; Decision Records define lasting rationale. Implementation and tests are evidence, not authority for missing requirements. Report missing authority instead of inventing a rule, acceptance criterion, or preference.
+
+## Select perspectives before loading
+
+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.
+- **[Document](references/document-review.md):** factual explanation, usability, navigation and maintenance of reviewed content, including API/TSDoc comments, requirements and human- or agent-facing guidance.
+- Mixed targets receive both applicable perspectives; complete Skill instruction reviews normally need both. Ordinary implementation comments need local accuracy/clarity checks, not an automatic full Document pass; bounded wording changes need only affected perspectives. Illustrative pseudocode needs logical consistency, not an invented runtime or production test gate.
+
+When fixed reviewed artifacts include changelogs, release notes, migration guides or public release descriptions, also use [release communication checks](references/release-communication.md) within the Document pipeline. Ordinary documents and release evidence read only as authority do not select this method.
 
-The user request fixes the requested outcome and allowed operations subject to nearest project instructions. The selected Change defines the intended delta, Specs define stable current facts, and Decision Records define lasting rationale. Implementation and tests are evidence, not authority for missing requirements. Report missing authority instead of inventing a rule, acceptance criterion, or preference.
+## Inspect the fixed scope
 
-## Classify before loading
+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.
 
-Do not read a pipeline reference until scope and authority are fixed. Then:
+Reuse traceable test evidence while its tested scope and relevant code, dependencies, configuration, tools, inputs and environment still apply. Run authorized checks only for gaps, invalidated results, changed risk or explicitly required execution. Distinguish reused evidence from new observations.
 
-1. Classify only fixed reviewed artifacts. **Code** includes executable code, tests, configuration, scripts, schemas, executable prompts, Skills, commands, hooks, and workflows. **Document** includes requirements, plans, Changes, Specs, Decision Records, ADRs, explanatory documentation, and user-facing documentation. An executable document may require both.
-2. Inputs read only as authority or evidence are authority-only, not reviewed artifacts. With no reviewed artifacts, a pipeline is `skipped`, never `clean`. Record missing, ambiguous, or conflicting authority in Review Scope, Coverage, and Verdict, not as a Finding from a skipped pipeline.
-3. Load [Code review](references/code-review.md) only if Code applies and [Document review](references/document-review.md) only if Document applies. A mixed review loads both; authority-only artifacts trigger neither.
+For re-review, inspect the actual correction and affected behavior against the original scope, expanding within it for evidenced consequences. Earlier clean verdicts do not establish a changed target; unchanged tests need no rerun solely for a new judgment. Perform the requested semantic review: neither passing tests nor an implementer summary supplies that judgment or required independence.
 
-Run every applicable pipeline and merge the same underlying issue into one cross-artifact finding. Inspect in order: fixed status and diff, selected authority, then the smallest direct behavior chain and tests needed for a concrete question. Stop when all applicable pipelines can be judged; do not search unrelated files or broaden authority to fill Coverage or Findings.
+Recover a tool-only fault within the fixed scope using another permitted read-only method after inspecting its scope and effects. Preserve the comparison, authority, named checks, required evidence and independence; project mutation and unsafe probes remain prohibited.
+
+Missing comparison or authority blocks dependent pipelines; other gaps follow the applicable gate. Keep supported findings and identify affected judgments without inventing a product defect or whole-review blocker. An unestablished required judgment is not clean.
 
 ## Report
 
-Render headings, field labels, explanations, and verdict prose in the language explicitly requested by the user; otherwise follow nearest project instructions, then the conversation language. Treat the shape below as semantic field order rather than fixed English wording: translate its human-facing labels when the output language differs. Preserve paths, commands, identifiers, WorkRefs, severity labels `P0`-`P3`, and the values `issues_found`, `clean`, `skipped`, and `blocked` unchanged; when their language differs from the response, retain those values only as secondary exact tokens beside localized narration.
-
-Use this shape:
-
-```md
-## <localized Review Scope heading>
-- <localized Comparison label>: <fixed ref, range, or file set>
-- <localized Intent label>: <authorities, missing, or ambiguous>
-- <localized Code label>: <issues_found | clean | skipped | blocked>
-- <localized Document label>: <issues_found | clean | skipped | blocked>
-- <localized Excluded label>: <paths and reasons, or none>
-
-## <localized Findings heading>
-### [P0-P3] <title>
-- <localized Artifact kind label>: <code | document | cross-artifact>
-- <localized Axis label>: <pipeline axis>
-- <localized Location label>: <path:line or precise section>
-- <localized Authority label>: <authority or observed invariant>
-- <localized Evidence label>: <conflicting behavior or text>
-- <localized Impact label>: <real consequence>
-- <localized Suggested action label>: <smallest correction; no edit>
-- <localized Confidence label>: <high | medium | low>
-
-## <localized Coverage heading>
-- <checked and unverified scope, including non-actionable missing coverage>
-
-## <localized Verdict heading>
-<blocked | findings | clean, with the smallest next action>
-```
-
-Omit Finding entries when none exist. `clean` means an applicable pipeline was reviewed with no actionable issue; `skipped` means no applicable artifacts; `blocked` means required scope or authority was unavailable. Deduplicate one underlying issue across pipelines, then order by severity and path. Use P0 for critical security, data, or breakage risk, P1 for normal-path contract failure, P2 for a meaningful edge or maintenance risk, and P3 only for narrow actionable improvement.
+Responses follow explicit language instruction, personal instructions, then conversation language, never project artifact-language settings. Preserve paths, commands, identifiers, WorkOwner/WorkRefs, `P0`-`P3` and `issues_found | clean | skipped | blocked`; use localized narration with differing machine values as secondary exact tokens.
+
+Preserve the information below without mandatory headings or one line per field. Use a compact report for a clean bounded review, omit empty Findings and unrelated no-op fields, and honor explicitly required formats:
+
+- Scope: WorkOwner or direct request, fixed comparison, authoritative intent, applicable perspectives and material exclusions.
+- Findings when present: severity/title, 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.
+- 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.
+
+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.
+
+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.
 
 Return a report only. Do not edit files, apply fixes, change focus, create RSP artifacts, switch branches, stage, commit, push, open a PR, publish, delete, trigger external review, or approve. Later actions require separate explicit authority.

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

@@ -1,15 +1,30 @@
 # Code review
 
-Load this reference only when the fixed reviewed artifacts make the Code pipeline applicable.
+Load for behavior or tool semantics within the fixed reviewed content. Document examples, API comments and executable instructions can need Code checks without making their entire containing file or evidence source an implementation-review target.
+
+Match checks and evidence to the actual role and changed risk:
+
+- Copyable examples: syntax, prerequisites, API/command compatibility, outcomes and dangerous side effects; execute only with authority.
+- API comments: declared inputs, returns and failures against authority and implementation. Type, compiler, lint or generation annotations can affect tooling despite comment syntax.
+- Illustrative pseudocode: logic/contract consistency, not mandatory compilation, runtime dependencies or production tests.
+- Real changed seams and public behavior: retain the applicable reachability and regression gates below; do not impose them on prose or unchanged code read as evidence.
 
 Check in this order:
 
-1. Safety and correctness: reachable bugs, data loss, security violations, invalid state transitions, broken contracts, unsafe failures, and regressions.
-2. Change and Spec fidelity: observable behavior against explicit intent and stable facts.
-3. Project standards: only rules established by nearest instructions or authoritative local conventions.
-4. Production reachability — hard gate before completing a seam-dependent Finding or returning `clean` for a changed seam: when behavior depends on an adapter, wrapper, validator, normalizer, registration, loader, generated wire-up, bin, worker, subprocess, plugin assembly, or another shipped entry path, name the smallest real production entry chain and verify that it reaches the changed seam. Direct or isolated seam tests are insufficient when they bypass that entry chain. Put the checked entry path in Evidence or Coverage. If the shipped path bypasses the seam, or the required reachability evidence is missing, report the gap and do not return `clean` or present an isolated seam fix as sufficient.
-5. Regression evidence — hard gate before `clean`: for every changed Code artifact, compare public return and failure behavior at the comparison point with the reviewed diff. Changing failure delivery between throw/rejection, sentinel values, `null`, status codes, or result objects is always a failure-contract change, even when implementation matches the selected Change. Without a focused test or other explicit verification evidence, emit a Finding and return `issues_found`. Absence of a new test is not actionable by itself: apply the simple deterministic-correction exception when the public behavior shape is preserved and no risky branch, state transition, concurrency, persistence, security behavior, or failure delivery changes, even though the corrected value differs. The exception never applies to a failure-contract change.
-6. Test and seam value — hard gate before `clean` when the diff adds or preserves a permanent test, public seam, validator, fallback, capability, compatibility path, or generic option: classify its consumers as production, non-production, or ambiguous. Tests and documentation alone do not make behavior production-load-bearing. For each questioned permanent test, identify its observable consequence, distinct plausible regression, why existing evidence misses it, and maintenance cost. Report test-only generality, wrapper or forwarding-hop assertions, shared-constant restatement, source-string coupling, or duplicate failure coverage only when a concrete real owner or smaller evidence path exists. Do not recommend deleting or merging tests that protect independent consequences, and do not infer that fewer tests are inherently better.
-7. Simplicity: unnecessary abstraction, duplication, indirection, dependency, or scope expansion with a concrete smaller alternative; never trade away required behavior.
+1. **Safety and correctness:** reachable bugs, data loss, security violations, invalid transitions, broken contracts, unsafe failures and regressions.
+2. **Change and Spec fidelity:** observable behavior against explicit intent and stable facts.
+3. **Project standards:** user rules, nearest instructions and relevant Specs. Check ordinary comments for local accuracy and useful information that nearby code does not make clear, such as constraints, rationale or usage; restatement without added information is unnecessary. Document owns fuller expression/usability checks when applicable; cite agreed requirements, not taste. For reviewed Skills, compare trigger, inputs, authority, failures, output, completion, verification and conditional loading with the baseline. Trace relevant branches and required local safety guidance; report concrete misroutes or missing contracts. Static pruning or a newer model label proves neither behavioral equivalence nor quality or cost gain.
+4. **Production reachability — hard gate for a changed seam:**
+   - For adapter, wrapper, validator, normalizer, registration, loader, generated wire-up, bin, worker, subprocess, plugin assembly or other shipped-entry behavior, name the smallest production chain and verify it reaches the seam. Isolated tests bypassing it are insufficient.
+   - Record that entry path in Evidence or Coverage before completing a seam-dependent Finding or returning `clean`. Missing evidence or a bypassed seam requires a reported gap, no `clean`, and no isolated-fix sufficiency claim.
+5. **Regression evidence — hard gate before `clean`:**
+   - Compare each changed Code artifact's public return and failure behavior with the fixed baseline. Changes between throw/rejection, sentinel, `null`, status code or result object are failure-contract changes even when intended. Require focused tests or other explicit verification for the affected judgment. If decisive evidence is unavailable, report the gap and block that judgment under the shared report contract. Emit a Finding for a demonstrated defect or an evidenced violation of an explicit project/task verification requirement, not absence of a new test alone.
+   - Simple deterministic correction is excepted when public behavior shape is preserved and no risky branch, state transition, concurrency, persistence, security or failure delivery changes, despite a corrected value. Failure-contract changes are never excepted.
+6. **Test and seam value — hard gate before `clean`:**
+   - For 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.
+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.

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

@@ -1,15 +1,32 @@
 # Document review
 
-Load this reference only when the fixed reviewed artifacts make the Document pipeline applicable.
+Load for explanation or usage guidance within the fixed reviewed content, including Skill instructions and API/TSDoc comments. Apply the dimensions relevant to the reader's task; a short inline comment needs no synthetic introduction, document scaffold or standalone writing pass.
 
-Classify each document by its semantic role: requirement/Change, implementation plan, Spec, Decision Record/ADR, or explanatory/user documentation. Then check:
+- Compare API comments and copyable examples with the smallest authoritative contract and implementation: inputs, outputs, failures, prerequisites and consequences.
+- Label illustrative pseudocode and incomplete snippets; neither is a verified runnable recipe. A code fence or evidence-source read does not select Code by itself, and review grants no execution authority.
+- Code handles applicable behavior/tool checks, not a duplicate writing pass. Report one text/behavior mismatch once without automatically treating implementation as correct.
+- Skill guidance: descriptions discriminate neighboring intents; actions have prerequisites/results and conditional links have a reading purpose. Keep common safety and minimum actionable context local. Tables serve short stable mappings, not branching procedures; concise wording preserves substantive qualifiers.
 
-1. Authority and traceability of claims and decisions.
-2. Internal and cross-artifact coherence, including current implementation facts.
-3. Completeness and ambiguity: undefined terms, unverifiable completion, and choices disguised as decisions. Report an unresolved product, operational, rollback, migration, or completion choice as an ambiguity Finding when no authority resolves it; ask for owner judgment and mark a dependent result blocked only when the choice prevents coherent review.
-4. Feasibility of named paths, interfaces, sequencing, safety, migration, and executable verification, at the detail appropriate to the document role.
-5. Scope and concision: scope leakage, duplicate authority, unrelated requirements, or verbosity hiding a contract.
+Classify each document by its semantic role: requirement/Change, implementation plan, Spec, Decision Record/ADR, context/navigation, operating instruction, or explanatory/user documentation. Then check:
 
-Before the Document verdict, enumerate every unresolved choice in each changed document. Any unresolved product, operational, rollback, migration, ownership, or completion choice must either have resolving authority or produce an ambiguity Finding; do not stop after finding other defects.
+1. **Purpose:** identify the intended reader, available prior knowledge, and reading task. Missing framing matters when it causes a wrong decision or prevents that task, not merely when a preferred introduction is absent.
+2. **Grounding:** verify authority and traceability of claims and decisions, including commands, defaults, conditions, limits, and failure outcomes. For shortened text, check lost negation, exceptions, permissions, quantities, units, certainty or necessary reasoning. Technical literals must not change under wording-only authority. Compare internal and cross-artifact meaning; polished prose can still make a false promise.
+3. **Usability:** judge task usability separately from factual accuracy. Procedures need usable actions and success signals, contracts assessable conditions, and decisions reasons and tradeoffs. Against the intended reader's prior knowledge, check findability, prerequisites, definitions, causal and conditional links and visible unknowns without the author conversation. Retain mechanisms needed to reason, troubleshoot or judge guarantees; otherwise true internals may still leave the required action unclear. Preserve necessary teaching and local safety without demanding tutorials in references. Fixed order needs a correctness, safety or contract reason.
+4. **Ownership:** check scope, duplicate authority, and choices disguised as settled decisions. An unresolved choice warrants an ambiguity Finding when it prevents the reviewed content from serving its declared task or safe use. Respect draft state and narrower review scope; intentionally deferred or out-of-scope choices are limits, not automatic defects. 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.
+
+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.
+
+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.
+
+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 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.

package/skills/rsp-review/references/release-communication.md

@@ -0,0 +1,21 @@
+# Release communication checks
+
+Load only when the fixed Document review scope includes release communication. Apply these checks alongside Document review; this method needs no installed Doc Skill and adds no writing, publication or approval authority.
+
+## Fix evidence and intended state
+
+Establish the released unit, range, requested surfaces and draft, final or published state from the request and authoritative project release conventions. A claimed version needs explicit user or repository release authority; do not infer it from commit ordering or a plausible next version.
+
+Read only the direct behavior, net diff, accepted fragments and verification needed to judge the fixed claims. Generated inventories and commit summaries are leads, not delivered behavior. Missing decisive range or behavior evidence blocks dependent judgments; unknown product or operational choices follow Document review's ambiguity rule. Do not broaden the reviewed set into a repository-wide release audit.
+
+## Check the communication
+
+- **Net outcome:** claims describe delivered final behavior, not reverted additions, implementation chronology or rejected session-only proposals. Material public, compatibility, packaging, security and operator effects are neither invented nor omitted.
+- **User action:** affected users can identify breaking changes, deprecations, old/new behavior, ordered migration steps, applicable compatibility windows, success checks and known recovery paths. Required safe commands, API forms and versions remain exact; a file link cannot replace a required action or consequence.
+- **Consistency:** selected surfaces agree with authoritative versions, dates, supported environments and references. Changelogs, notes and migration guides serve their distinct audiences rather than duplicating one transcript. Public links are stable and do not expose private identifiers.
+- **Evidence limits:** historical checks identify their revision or date; unavailable platform or live-release verification is not described as completed. Document correctness proves neither package verification nor release readiness.
+- **Lifetime and authority:** drafts disclose unresolved identity without inventing versioned claims. Final shipped prose remains publication-invariant and uses target tags or immutable comparisons, not moving HEAD. Credentials and transient authentication/publication progress stay out of retained artifacts. A document task never grants commit, tag, push, publish or immutable-history repair.
+
+For an explicitly scoped post-publication comparison, inspect observed public state against the selected immutable candidate. Report mutable-document corrections or an immutable discrepancy's corrective owner; never edit, move a tag or rewrite a package. An unknown external state remains unverified.
+
+Apply project-required release checks and closeout conditions only when they govern this judgment. Do not impose a universal Release Change, separate release commit, archive requirement or publication checklist. Return findings, coverage and limitations in Review's existing report; a clean Document result is not release approval.

package/skills/{rsp-structural-audit/references/structural-lenses.md → rsp-review/references/structural-review.md}

@@ -1,6 +1,6 @@
-# Structural audit lenses
+# Structural review
 
-Load this reference only after the audit boundary and authority are fixed. Select the smallest relevant set of lenses; do not turn them into a completion checklist.
+Load for requested structural discovery or a concrete structural risk within an already fixed review boundary. Select the smallest relevant set of lenses; do not turn them into a completion checklist.
 
 ## Candidate selection in a broad boundary
 
@@ -14,7 +14,7 @@ Trace where important state or data is created, validated, mutated, persisted, r
 
 Start from a direct consumer and list what it must know about the provider: policy, representation, ordering, failure behavior, configuration, and lifecycle. Look for dependency direction that forces an owner to understand another module's internals, or a boundary that leaks enough decisions to amplify ordinary changes. An import, large module, circular-looking name, or missing interface is not sufficient; establish actual caller burden or invalid-state exposure.
 
-For suspected shallow indirection, reason through removal before calling it redundant. If removal eliminates the apparent complexity, the layer may be pass-through. If required policy, invariants, or failure knowledge instead disperses into callers, the layer may be earning locality. Thinness alone proves neither result; retain a Finding only when the live chain also establishes a reachable trigger and concrete impact.
+Before calling a layer redundant, trace what its removal would do. Eliminated complexity suggests pass-through; policy, invariants or failure knowledge dispersed into callers suggests useful locality. Thinness proves neither. Retain a Finding only with a reachable trigger and concrete impact in the live chain.
 
 ## Production-path reachability
 
@@ -36,6 +36,6 @@ Before retaining a finding, answer all of these from repository evidence:
 2. What reachable condition triggers the problem?
 3. What realistic user, operator, data, or change-cost impact follows?
 4. Which evidence confirms the full chain, and what remains unobserved?
-5. What is the smallest next owner: a user decision, shaping question, or one bounded design question?
+5. What is the smallest correction or unresolved owner/design question?
 
-Discard the finding when any of the first three answers is speculative. Rank retained findings by impact and confidence, not ease of cleanup. Use P1 for a normal-path structural failure with significant correctness or data consequences, P2 for a meaningful edge or recurring change risk, and P3 only for a narrow actionable maintenance risk. Do not emit P0 from this general structural audit; route suspected critical security, safety, or data-loss work to the appropriate specialist or incident owner.
+Discard the finding when any of the first three answers is speculative. Rank retained findings by impact and confidence, not ease of cleanup. Use Review's severity and verdict semantics. Select only material supported findings; missing coverage stays explicit and does not justify an unqualified clean claim. Do not turn the report into an implementation, replacement design or automatic handoff.

package/skills/rsp-shape/SKILL.md

@@ -1,35 +1,43 @@
 ---
 name: rsp-shape
-description: Shape or rigorously challenge unclear non-trivial work into one executable RSP Change or a justified shallow Change Group without implementing it.
+description: Resolve bounded design questions read-only or clarify material choices and plan authorized work as one executable Change or justified shallow Group. Not decision approval, implementation or final-record cleanup.
 license: MIT
 metadata:
   author: oevery
-  version: "2026.08.05.1"
+  version: "2026.10.15.2"
 ---
 
 # RSP Shape
 
-Do not implement the shaped work.
+For tracked work, read the [shared work model](../rsp/references/work-model.md) when its identity and ownership definitions are missing from the current context. Use logical WorkRefs in commands and reports; cite file locations separately. Direct invocation needs no prior Core execution.
 
-Follow Core's response-versus-artifact language boundary for all user-visible control narration; when the response language differs, keep exact canonical values only as secondary parenthesized or code-formatted tokens.
+Choose the branch before loading detail: bounded design advice is read-only and may have no Change; explicit planning-artifact work shapes or refines a Change/Group. Neither branch implements product behavior.
+
+Shape clarifies decisions and writes planning artifacts, including Markdown. The authorized DecisionOwner approves material choices. Doc may word settled decisions and reconcile final work records. Return unresolved material choices to Shape; prose cleanup cannot settle them.
+
+Responses follow explicit instruction, personal instructions, then conversation language. Preserve existing artifact language and canonical identifiers, commands and values. For new artifacts, use explicit instruction, effective configuration, scoped project instructions, then conversation language.
+
+Resolve needed RSP settings, including defaults and inheritance, through the selected CLI's successful `rsp config --json` summary; refresh on relevant drift or recovery. Raw YAML is diagnostic only. Projection failure blocks dependent choices, not independent authorized work; return material conflicts to the owner.
 
 ## Establish the boundary
 
-Read the request, authority, Core or fallback, Change and Brief, then only decisive evidence.
+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.
 
 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.
 
-Return the request directly to implementation when it is tiny and concrete or the selected Change is already ready. Do not rewrite settled work for style or completeness.
-
-During an explicit managed goal, its original planning-artifact authority remains valid for clear in-scope discovery. Keep a cohesive correction in the current Change; create one Change for an independently closable result, or one shallow Group for at least two such results sharing the goal. Return the ready WorkOwner to Core for fresh qualification without another authorization round. Stop on changed behavior, acceptance, public interfaces, goal scope, mutation authority, or external action.
+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.
 
 ## Resolve material ambiguity
 
-Inspect the repository before asking. Ask only for an owner decision changing behavior, data, interfaces, compatibility, safety, ownership, migration, or acceptance. Write only authorized answers.
+Inspect the repository before asking. Ask for unresolved owner decisions affecting behavior, data, interfaces, compatibility, safety, ownership, migration or acceptance. Reuse settled answers until evidence invalidates them. Ordinary implementation choices within that contract need no new decision or planning pass. Write only authorized answers.
 
-Shape owns two transient questioning modes. Ordinary clarification asks one to three related material questions, while explicit deep clarification asks exactly one DecisionOwner question per turn. A Core or Manage `StopDisposition: return-to-shape` may enter either mode, but Shape resumes execution only by returning a ready WorkOwner to Core for fresh route derivation; it never resumes Manage directly.
+Derive requirements and acceptance checks from settled authority. Do not make a preferred implementation or unsettled public behavior, failure contract, default or compatibility choice mandatory. Keep replaceable internal choices in Design, label material alternatives as proposals and put readiness-blocking decisions in Blockers.
 
-Read [deep clarification](references/deep-clarification.md) when the user explicitly asks for rigorous challenge, a high-risk decision remains, or one design question returns. Prefer the installed `rsp-design` capability; otherwise use its fallback.
+Choose permitted methods within the branch. Recover a diagnosed read/search fault against unchanged goal, scope, authority, baseline and evidence. Inspect artifact/focus effects before replaying planning mutations; unknown effects or unsafe replay stop that action. Required RSP commands/checks cannot be replaced by prose or tool status.
+
+Ask one to three related material questions ordinarily, one DecisionOwner question per turn for deep clarification. Resume unresolved decisions from fresh facts and return the ready owner to Core; a method change alone restarts no workflow.
+
+For a bounded design question, load only the relevant [domain modeling](references/domain-modeling.md), [module and seam design](references/module-seams.md), or [reversible exploration](references/reversible-exploration.md) method. Read [deep clarification](references/deep-clarification.md) only for explicit rigorous challenge or dependent high-risk decisions. Advice does not create or modify an artifact, authorize a disposable code probe, or turn a recommendation into product authority.
 
 Read [external issue input](references/external-issue-input.md) only when a Change declares an issue relationship or the request asks to shape from an issue URL.
 
@@ -37,43 +45,14 @@ Never invent a product decision. When a material choice or mutation authority re
 
 ## Choose the owner
 
-Read [complex shaping](references/complex-shaping.md) when clarification needs multiple rounds, slices share one completion contract, or independently closable owners converge on terminal delivery.
-
-When Shape must establish a new WorkRef, preserve an explicit valid user-supplied identity through canonical normalization. Otherwise follow an explicit nearest project or domain WorkRef naming convention. If neither exists, infer ASCII lowercase kebab-case from stable domain or technical vocabulary. Artifact, commit, response, host locale, and TUI language settings never select or translate WorkRef language. Safe Unicode remains available through explicit input or project/domain convention; never rename an existing open or archived identity because language or naming guidance changes.
-
-Prefer one ordinary Change only for one observable outcome sharing a consistency, focused-verification, review, archive, and rollback boundary. Change granularity does not prescribe Git commit count; never split or merge Changes merely to enforce a Change-to-commit mapping. Use a shallow Group for independent outcomes under one goal; an integration gate never merges them. A shared completion contract gates Group closure, not child archive unless declared there. Keep Brief `Slices`, child `Blockers`, and derived readiness. Add no hierarchy.
+For authorized planning-artifact work, read [planning and readiness](references/planning.md) before choosing or naming an owner, writing a Change/Group, or updating the selected Design. Read-only design advice needs none of those artifact procedures.
 
-Keep one observable outcome per Change:
-
-- `Proposal`: outcome, scope, non-goals;
-- `Spec`: requirements and acceptance;
-- `Design`: boundaries and choices;
-- `Tasks`: executable steps;
-- `Verify`: decisive evidence;
-- `Blockers`: dependencies and decisions, or `none`.
-
-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 current-plan and final-evidence snapshot, not an append-only execution log. Replace superseded evidence; keep process in the response. Before archive, retain final decisive verification, gaps, and risks.
-
-Use domain language. Mention agents only as real product actors or constraints, not authors or execution narrators.
+Read [complex shaping](references/complex-shaping.md) when authorized planning involves multiple material decisions or independently acceptable outcomes with dependencies/integration. Work shape does not enable agent delegation.
 
 ## Apply the Shape Ready gate
 
-A Change is ready only when:
-
-- outcome, non-goals, and acceptance are concrete;
-- product and mutation authority are settled;
-- affected boundaries and material constraints are known;
-- no hidden assumption can change implementation or acceptance;
-- Tasks are executable without performing them;
-- Verify proves the result without process chronology; Blockers are truthful;
-- one Change or a justified shallow Group is the smallest sufficient owner.
-
-After mutation, run the focused RSP check. Return WorkRef, artifacts, validation, and next action or blocker.
-
-When the gate passes, return a `ControlOutcome` for phase Shape with the ready `WorkOwner` WorkRef, decisive readiness evidence, `NextOwner: Core`, and a resume rule that Core freshly derives the route.
+For planning, apply the complete [Shape Ready gate](references/planning.md#apply-the-shape-ready-gate), then run the focused RSP check after authorized mutation. On pass, return the ready Change WorkRef or Group reference, artifacts and decisive evidence for Core to continue the authorized objective without another user request.
 
-When a material decision prevents readiness, return a non-ready `ControlOutcome` for phase Shape with `StopDisposition: ask-owner`, the decisive evidence, the `DecisionOwner`, the required answer, and a resume rule that reruns Shape from fresh evidence after the answer.
+For read-only design, lead with the recommendation and decisive evidence. Include credible tradeoffs, owner decisions and a next action only when relevant to the current question; do not restate settled context or force a planning report. Create or mutate no plan automatically.
 
-For any other blocker, return a non-ready Shape `ControlOutcome` with the applicable canonical `StopDisposition`, decisive evidence, `NextOwner`, required input, and resume rule. Do not relabel unresolved fog as ready work.
+When a material decision prevents readiness, stop with decisive evidence, the DecisionOwner and required answer; resume from fresh relevant evidence after that answer. For other blockers, state the actual missing input, next owner and safe resume condition. Use canonical machine fields such as `StopDisposition` only when a real consumer requires them. Do not report unresolved material decisions as ready work.

package/skills/rsp-shape/references/complex-shaping.md

@@ -1,6 +1,8 @@
 # Complex shaping
 
-Read this reference only when material clarification needs more than one round, several direct slices share one completion contract, or independently closable owners converge on terminal delivery.
+Read for authorized planning with multiple material decisions or independently acceptable outcomes with dependencies/integration. This method does not select agent topology.
+
+Use existing planning authority for clear in-scope discovery. Keep cohesive corrections in the Change. Use a separate Change for an independently closable result, or a shallow Group when at least two results have dependencies or integration obligations. Return the ready owner without another authorization round. Configuration grants no planning/product authority. Changes to behavior, acceptance, interfaces, scope, mutation authority or external action need an owner decision.
 
 ## Close material decisions
 

package/skills/rsp-shape/references/deep-clarification.md

@@ -8,15 +8,15 @@ Inspect the available code, tests, project instructions, Specs, and Decision Rec
 
 ## RSP design return
 
-When `rsp-design` is available, it is the canonical domain or module design capability for an RSP-tracked question. Otherwise use an equivalent project-selected capability or Core's compact manual design fallback. Return one bounded design task containing:
+For an RSP-tracked domain or module design question, use Shape's conditional design method and return one bounded result containing:
 
 - the unresolved design question;
 - authoritative project inputs by path;
 - the expected existing artifact or decision output;
 - its permitted mutation boundary;
-- the same returning WorkRef.
+- the same returning WorkOwner reference.
 
-The selected capability owns only the design analysis, while existing project documents retain domain and architecture authority. Consume its settled result and evidence on return, then resume Shape against the same Change.
+Design analysis does not grant artifact mutation; existing project documents retain domain and architecture authority. Consume settled evidence in the same Shape request and continue against the same Change only when authorized.
 
 ## Traverse one decision at a time
 
@@ -28,4 +28,4 @@ This branch fulfills `StopDisposition: return-to-shape`; it does not resume the
 
 ## Completion criterion
 
-Finish the deep branch when every material dependent decision is either owner-confirmed or recorded as one explicit blocker, the project design task has returned to the same WorkRef when used, and no artifact changed before shared understanding was confirmed.
+Finish the deep branch when every material dependent decision is either owner-confirmed or recorded as one explicit blocker, the project design task has returned to the same WorkOwner when used, and no artifact changed before shared understanding was confirmed.

package/skills/rsp-shape/references/domain-modeling.md

@@ -0,0 +1,13 @@
+# Domain modeling (Shape design method)
+
+Use this procedure only for a question about domain language, identity, lifecycle, invariants, relationships, or ownership.
+
+Use authoritative context, Specs, code, tests and user language to resolve:
+
+- Existing terms and contradictions; do not silently choose a conflicting source.
+- Identity, owners, allowed transitions, invariants and relationships. Distinguish domain concepts from transport, storage, UI and helper representations.
+- Observable lifecycle scenarios across creation, transitions, failure, cancellation, deletion and relevant scope boundaries, not type names alone.
+
+Propose the smallest coherent model explaining the evidence. Check it against at least one edge case and one existing production consumer; separate evidence-forced conclusions from choices needing owner confirmation.
+
+Return canonical terms, definitions, ownership and lifecycle implications, conflicts with current usage, alternatives, and unresolved owner decisions. Planned vocabulary may update only the authorized selected Change `Design`; flag possible current-fact or rationale destinations without writing them.

package/skills/rsp-shape/references/module-seams.md

@@ -0,0 +1,13 @@
+# Module and seam design (Shape design method)
+
+Use this procedure only for a question about an interface, caller complexity, adapter, test surface, or seam placement.
+
+Before proposing a seam, trace the direct production consumer's complete call/data path and confirm it reaches the candidate owner. Then judge:
+
+- Caller obligations: inputs, outputs, invariants, ordering, failures, configuration, cancellation and relevant performance constraints.
+- Actual behavior/policy variation, not hypothetical interfaces or pass-through wrappers for symmetry.
+- Credible placements by caller leverage, implementation locality, dependency direction, state ownership and a public surface usable by both callers and tests.
+
+Recommend the smallest interface hiding meaningful complexity without moving domain ownership. State migration and compatibility consequences; implement nothing.
+
+Return the proposed owner, seam, interface obligations, affected consumers, verification surface, alternatives, and unresolved owner decisions. Treat code sketches as explanatory output only; do not write production code.

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

@@ -0,0 +1,42 @@
+# Authorized planning and readiness
+
+Load only for authorized planning-artifact work, before choosing or naming an owner, creating/refining a Change or Group, or updating the selected Change Design. Advice alone grants no artifact mutation.
+
+## Choose and name the owner
+
+For a new WorkRef, canonically normalize a valid user-supplied identity. Otherwise follow the nearest explicit project/domain naming convention; absent both, infer ASCII lowercase kebab-case from stable domain or technical terms. Artifact, commit, response, host locale and TUI language settings do not select or translate WorkRefs. Explicit input or project/domain conventions may use safe Unicode. Language or naming changes never rename existing open or archived identities.
+
+Prefer one ordinary Change only for one observable outcome sharing a consistency, focused-verification, review, archive, and rollback boundary. Change granularity does not prescribe Git commit count; never split or merge Changes merely to enforce a Change-to-commit mapping. Use a shallow Group for independently acceptable/deliverable outcomes with dependencies or integration obligations; complexity and worker count alone do not justify it; an integration gate never merges them. A shared completion contract gates Group closure, not child archive unless declared there. Keep Brief `Slices`, child `Blockers`, and derived readiness. Add no hierarchy.
+
+## Write one outcome
+
+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;
+- `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.
+
+Use domain language. Mention agents only as real product actors or constraints, not authors or execution narrators.
+
+## Apply the Shape Ready gate
+
+A Change is ready only when:
+
+- outcome, non-goals, and acceptance are concrete;
+- product and mutation authority are settled;
+- affected boundaries and material constraints are known;
+- no hidden assumption can change implementation or acceptance;
+- Tasks are executable without performing them;
+- Verify proves the result without process chronology; Blockers are truthful;
+- one Change or a justified shallow Group is the smallest sufficient owner.
+
+After authorized planning mutation, run the focused RSP check. Readiness permits Core to continue only the already authorized objective; it grants no product, lifecycle, Git or external authority.