@oevery/rsp 3.2.0 → 3.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (37) hide show
  1. package/README.md +4 -3
  2. package/README.zh-CN.md +3 -2
  3. package/dist/{chunk-SEGJLWRE.mjs → chunk-7HXQNBIG.mjs} +447 -734
  4. package/dist/{chunk-JYDEJEM4.mjs → chunk-QM2UVPQK.mjs} +47 -30
  5. package/dist/{chunk-ZORUJTVS.mjs → chunk-TSUDEX5Y.mjs} +1163 -104
  6. package/dist/cli.mjs +5332 -3047
  7. package/dist/entry-GIDNR7CJ.mjs +1846 -0
  8. package/dist/{entry-RG6HREUN.mjs → entry-YAW3PYFA.mjs} +2 -2
  9. package/package.json +12 -7
  10. package/rules/rsp-rules.md +6 -5
  11. package/skills/rsp/SKILL.md +26 -57
  12. package/skills/rsp/references/control-outcome.md +31 -0
  13. package/skills/rsp/references/durable-review.md +18 -1
  14. package/skills/rsp/references/focus-continuation.md +9 -0
  15. package/skills/rsp/references/implementation-evidence.md +12 -0
  16. package/skills/rsp/references/managed-routing.md +9 -8
  17. package/skills/rsp/references/response-language.md +11 -0
  18. package/skills/rsp/references/setup-repair.md +3 -3
  19. package/skills/rsp-commit/SKILL.md +24 -9
  20. package/skills/rsp-design/SKILL.md +1 -1
  21. package/skills/rsp-diagnose/SKILL.md +3 -1
  22. package/skills/rsp-implement/SKILL.md +15 -5
  23. package/skills/rsp-manage/SKILL.md +56 -51
  24. package/skills/rsp-manage/references/closeout.md +3 -1
  25. package/skills/rsp-manage/references/delegation.md +47 -0
  26. package/skills/rsp-manage/references/interruption-recovery.md +15 -3
  27. package/skills/rsp-manage/references/review-convergence.md +3 -1
  28. package/skills/rsp-release-docs/SKILL.md +13 -13
  29. package/skills/rsp-release-docs/references/publication-lifecycle.md +4 -0
  30. package/skills/rsp-resolve-findings/SKILL.md +2 -2
  31. package/skills/rsp-review/SKILL.md +9 -12
  32. package/skills/rsp-review/references/code-review.md +3 -2
  33. package/skills/rsp-shape/SKILL.md +1 -1
  34. package/skills/rsp-tdd/SKILL.md +10 -2
  35. package/skills/rsp-verify/SKILL.md +40 -0
  36. package/dist/entry-I22OUIW5.mjs +0 -888
  37. package/skills/rsp/references/release-operations.md +0 -9
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: rsp-design
3
- description: Resolve one material domain-model, module/seam, or evidence-seeking design question before a Change or for an explicit or focused RSP Change without implementing production behavior or writing durable project truth.
3
+ description: Resolve one material domain-model, module or seam, or evidence-seeking design question before a Change or for an explicit or focused RSP Change without implementing production behavior or writing durable project truth.
4
4
  license: MIT
5
5
  metadata:
6
6
  author: oevery
@@ -4,7 +4,7 @@ description: Diagnose one selected RSP Change when a reproducible or materially
4
4
  license: MIT
5
5
  metadata:
6
6
  author: oevery
7
- version: "2026.07.22.1"
7
+ version: "2026.08.21.1"
8
8
  ---
9
9
 
10
10
  # RSP Diagnose
@@ -41,6 +41,8 @@ Return:
41
41
  - investigation mutations, if explicitly authorized;
42
42
  - exactly one next action.
43
43
 
44
+ The result expresses only whether the cause was confirmed. When Manage invoked the diagnosis, report any owner, scope, or authority change separately in the impact boundary; never combine it with the result value or wrap it in a second universal worker schema.
45
+
44
46
  For `confirmed`, name one correction entrypoint owned by the same Change; do not apply it. For `unresolved`, name the next discriminating check or blocker. Update that Change's Tasks, Verify, or Blockers only with authority and observed facts. Preserve unrelated work and never infer Git, delivery, publication, or approval authority.
45
47
 
46
48
  When correction, further discrimination, or other work remains, use Core's compact continuation fields in order: `WorkRef`, `Authority`, `Current state`, `Changed artifacts`, `Fresh verification`, `Blockers`, and `Next action`. Put the result, reproduction limit, cause or hypotheses, decisive evidence, and impact boundary in `Current state`; put authorized investigation mutations in `Changed artifacts`. Reopen authority pointers, inspect drift, and refresh decisive evidence before resuming. This response is not durable truth or a second state store; persist it only with explicit path authority.
@@ -1,10 +1,10 @@
1
1
  ---
2
2
  name: rsp-implement
3
- description: Implement exactly one selected, ready RSP Change within explicit mutation authority. Use when the user asks to implement or fix tracked work and requires code/tests plus truthful Tasks, Blockers, and fresh verification evidence; never infer Git, publication, review, TDD, or diagnosis authority.
3
+ description: Implement exactly one selected, ready RSP Change within explicit mutation authority. Use when the user asks to implement or fix tracked work and requires code and tests plus truthful Tasks, Blockers, and fresh verification evidence; never infer Git, publication, review, TDD, or diagnosis authority.
4
4
  license: MIT
5
5
  metadata:
6
6
  author: oevery
7
- version: "2026.07.29.1"
7
+ version: "2026.08.23.1"
8
8
  ---
9
9
 
10
10
  # RSP Implement
@@ -17,7 +17,7 @@ Follow Core's response-versus-artifact language boundary for all user-visible co
17
17
 
18
18
  Require an explicit WorkRef or one unambiguous focus marker. A Group Brief is context, not executable work. Stop when selection, readiness, product authority, acceptance, or required decisions are unresolved.
19
19
 
20
- Read nearest instructions, Core or fallback, Change and Brief, relevant Specs and decisions, worktree, then the smallest owning code/test chain. Use normal repository discovery; do not guess owners.
20
+ Read nearest instructions, Core or fallback, Change and Brief, relevant Specs and decisions, current checkout, then the smallest owning code and test chain. Use normal repository discovery; do not guess owners. Operate only in the execution location actually supplied by the host; Implement never selects or migrates execution environments.
21
21
 
22
22
  ## Preserve authority
23
23
 
@@ -25,6 +25,12 @@ Identify outcome, owners, verification, and pre-existing work. Modify only Chang
25
25
 
26
26
  Git delivery, publication, deployment, approval, and out-of-scope deletion require separate explicit authority. For conflicts, inspect base/ours/theirs, preserve unrelated work, resolve only evidenced scope, rerun checks, and stop before staging, continuing, aborting, or committing. Verify named findings first.
27
27
 
28
+ ## Admit boundaries and permanent tests
29
+
30
+ Before adding a validator, fallback, defensive copy, capability, state machine, compatibility path, or public option, identify its current producer, production consumer, actual trust or lifecycle transition, and material consequence. A typed same-process value, imagined future caller, or test/document-only consumer does not establish a production boundary. Keep an explicitly required seam, but otherwise do not create one when this evidence is missing.
31
+
32
+ Before creating or extending a permanent test, identify the observable consequence, one distinct plausible regression in the owning production seam, why existing evidence misses it, and the maintenance cost. Prefer an existing test, type or static check, build, or acceptance check when it already owns the risk. When the requested behavior belongs to a consumer and downstream adapters or forwarding hops already have owners and coverage, exercise the consumer through those existing seams to the observable consequence. A nearest-spy, emitted-message, shared-constant, or forwarding assertion that only re-proves the downstream hop is not sufficient, even when added to an existing test file. Do not add one test per touched file, wrapper, forwarding hop, branch, or shared constant. Multiple nearby tests remain justified when each protects an independent consequence.
33
+
28
34
  ## Classify implementation evidence
29
35
 
30
36
  Apply these routes in order before mutation and after failure:
@@ -41,9 +47,13 @@ Implement the smallest complete slice. Update Tasks after outcomes exist; keep u
41
47
 
42
48
  After final mutation, run required Change checks and narrower risk checks. Fresh verification is required, but a new test is only one evidence option; prefer the cheapest decisive existing test, static check, build, or acceptance evidence. Record command, scope, result, and omissions. Prior runs are stale; failed or unavailable verification cannot support completion. Rerun after relevant edits.
43
49
 
44
- Keep a new test only when it protects observable behavior or a real boundary, adds distinct future confidence, avoids duplicate or implementation-detail coverage, and has proportionate maintenance cost. Otherwise remove the disposable test, fixture, and helper before completion, then use smallest sufficient final evidence. User, Change, and project retention requirements remain authoritative.
50
+ Keep a new or extended test only when it still satisfies the admission evidence, protects observable behavior or a real boundary, adds distinct future confidence, avoids duplicate or implementation-detail coverage, and has proportionate maintenance cost. Otherwise remove the disposable test, fixture, and helper before completion, then use smallest sufficient final evidence. User, Change, and project retention requirements remain authoritative.
51
+
52
+ Before returning, reread changed comments, test names, documentation, and handoff prose from the accepted result and each surface's authoritative baseline. Build the final handoff only from the accepted Change, actual changed paths, final verification, material omissions or risks, executed external actions, and pre-existing user work that must be attributed. A rejected session-only alternative, correction, or temporary attempt is not an omission or boundary: do not name it, paraphrase it, or turn it into an unrequested `did not add` or `did not use` compliance claim.
53
+
54
+ Preserve a negative fact when a reader without the session needs it to understand an actual baseline removal, safety or compatibility boundary, migration, audit result, failed external action, unresolved risk, or explicitly requested comparison. Preserve required facts and pre-existing user work; never change executable behavior, public contracts, tests, snapshots, or diagnostics merely to clean wording.
45
55
 
46
- Record concise fresh evidence when Change Verify owns it. Do not create a receipt store or mandate one shell wrapper.
56
+ Record concise fresh evidence when Change Verify owns it.
47
57
 
48
58
  ## Return ownership
49
59
 
@@ -4,93 +4,98 @@ description: Coordinate one eligible long-running, recovery, or multi-slice RSP
4
4
  license: MIT
5
5
  metadata:
6
6
  author: oevery
7
- version: "2026.08.05.2"
7
+ version: "2026.08.22.3"
8
8
  ---
9
9
 
10
10
  # RSP Manage
11
11
 
12
- Manage one requested goal selected by Core from an explicit request or effective `manage.activation: auto`. Enter only with one selected shape-ready Change or shallow Group plus a transient handoff containing the goal, WorkRef, authority envelope, decisive qualification evidence, closeout ceiling, and return boundaries. Once selected, this Skill solely owns same-goal revalidation, interruption and resume, review convergence, acceptance, lifecycle closeout, and commit eligibility and orchestration. Exact staging, message construction, local commit execution, and post-commit observation remain owned by `rsp-commit`. Keep artifacts durable and process data transient. The goal defines authority; automatic activation grants selection, not mutation.
12
+ Manage one requested goal selected by Core from an explicit request or effective `manage.activation: auto`. Enter only with one selected shape-ready Change or shallow Group plus the goal, WorkRef, authority envelope, decisive qualification evidence, closeout ceiling, and return boundaries. Manage owns same-goal coordination, evidence acceptance, review convergence, lifecycle closeout, and eligible Commit orchestration. Exact Git procedure remains owned by `rsp-commit`. Keep artifacts durable and process data transient. Automatic activation grants selection, not mutation.
13
13
 
14
14
  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.
15
15
 
16
- ## Selected-goal entry
16
+ ## Validate the selected goal
17
17
 
18
- Core resolves ownership before this Skill is entered. Manage has no pre-owner Intake and never creates, focuses, or reshapes a durable owner. Reject an incomplete handoff without mutation and return to Core with the missing owner, authority, qualification, closeout, or return-boundary evidence.
18
+ Core owns initial Manage qualification and the `selected | declined` route result. Manage never creates, focuses, reshapes, or requalifies a durable owner. Before mutation, reread the selected Change or Group, relevant Specs and Decisions, authority envelope, `rsp status --json`, current checkout, and decisive evidence.
19
19
 
20
- ## Validate the selected handoff before mutation
20
+ Stop and return to Core when the handoff is incomplete or a true owner, WorkRef topology, route, declared behavior, acceptance, interface, scope, mutation-authority, or external-action-authority boundary changed. Otherwise continue the selected goal without repeating qualification. Use only the execution location and worker capabilities supplied by the host; never infer isolation, identity, or completion.
21
21
 
22
- Core and its managed-routing reference solely own initial Manage qualification and the `selected | declined` route result. Manage never repeats the direct-versus-managed eligibility test or declines a valid selected handoff back to an ordinary Core or Discipline action.
22
+ Return one bounded managed phase result for Core's outer `ControlOutcome`:
23
23
 
24
- Before dispatch, validate the handoff against current evidence by re-reading all of the following:
24
+ - `solo`: no worker participates, including a bounded local Discipline action;
25
+ - `delegated`: one worker participates;
26
+ - `coordinated`: multiple workers participate or acceptance requires a separate verifier.
25
27
 
26
- - every selected WorkRef, including clear in-scope successors;
27
- - the complete owning Change, or the Group Brief and its children;
28
- - relevant Specs and Decisions;
29
- - the authority envelope, `rsp status --json`, and the current worktree.
28
+ Mode describes observed participation, not a host lifecycle model.
30
29
 
31
- Validate only handoff completeness and current drift: the selected owner and topology still match, the requested goal and route are unchanged, the authority envelope still permits the next action, owned paths remain exact and unmixed, and the decisive qualification evidence has not been invalidated. If the handoff is incomplete, evidence has drifted, or a true owner, topology, route, behavior, acceptance, interface, scope, mutation-authority, or external-action-authority boundary changed, stop without mutation and return the decisive evidence to Core. Otherwise continue the selected managed goal without repeating qualification. When dispatch applies, report only the concrete reason for sequential or parallel execution. Keep validation and dispatch reasoning transient.
30
+ ## Choose the smallest execution strategy
32
31
 
33
- Preserve unrelated work and require an explicit release identity. Allow four worker dispatches and one worker corrective retry across the whole managed run. Owner transitions do not reset either limit.
32
+ Use only as much coordination as the current evidence requires:
34
33
 
35
- ## Resolve the execution frontier
34
+ - `control-action`: one Manager-owned control-plane action;
35
+ - `longitudinal`: compatible successive work through one worker when the host supports continuation;
36
+ - `sequential`: ordered work with shared seams, writers, or verification resources;
37
+ - `parallel-wave`: independent slices with disjoint mutation and verification resources;
38
+ - `read-only-fan-out`: independent evidence gathering;
39
+ - `bounded-correction`: an evidenced same-scope correction;
40
+ - `independent-verify`: acceptance requires a different worker from the accepted implementation worker.
36
41
 
37
- After the selected handoff remains valid, classify every newly surfaced unknown before selecting work, in this fail-closed compatibility order: `out-of-goal` → `owner-decision` → `fog` → `evidence-needed` → `ready-to-execute`. The canonical `FrontierDisposition` is exactly `out-of-goal`, `owner-decision`, `fog`, `evidence-needed`, or `executable`; public `ready-to-execute` maps only to canonical `executable`.
42
+ These names explain Manager strategy only. They are not runtime states, persisted objects, or proof that dispatch occurred.
38
43
 
39
- - `out-of-goal` stops for topology or authority resolution with `StopDisposition: reroute`.
40
- - `owner-decision` stops with the single highest-impact question for its `DecisionOwner` when behavior, acceptance, public interface, scope, mutation authority, external action, or human acceptance is unresolved. Return `StopDisposition: ask-owner` to Core for fresh routing after the answer.
41
- - `fog` is not yet a precise question. Create no synthetic Task, Change, Blocker, or worker dispatch; return `StopDisposition: return-to-shape` to Core and halt the current managed control phase. Only Core may route authorized Shape. Do not continue an independently ready slice, dispatch another worker, or mutate product state. Resume only after Shape confirms a ready owner and Core freshly rederives the route.
42
- - `evidence-needed` is one precise factual question answerable without choosing any owner decision above. If evidence would cross one of those boundaries, take the applicable stop instead of selecting Fix.
43
- - Canonical `executable` permits lane selection only after ownership, authority, and required evidence are settled.
44
+ Derive `DispatchDisposition` after selection:
44
45
 
45
- `StopDisposition` is exactly `ask-owner`, `return-to-shape`, `reroute`, `retry-with-evidence`, `environment-blocked`, `verification-blocked`, or `capability-unavailable`. No stop disposition permits another worker dispatch, product mutation, lifecycle closeout, or Git action until its stated resume contract succeeds.
46
+ | Value | Use when | If unavailable |
47
+ | --- | --- | --- |
48
+ | `none` | No useful or required worker seam exists. | Run the bounded local Discipline. |
49
+ | `preferred` | Delegation improves focus or continuity without creating an acceptance obligation. | Continue locally within the same owner and authority. |
50
+ | `required` | The request or declared acceptance requires delegated work or a separate verifier. | Stop `capability-unavailable`; acceptance remains `incomplete`. |
46
51
 
47
- Every lane receives one transient `WorkerEnvelope` with these common fields: `WorkRef`, `lane`, `objective`, `current hypothesis` when one exists, `known evidence`, `allowed paths`, `allowed actions and commands`, `prohibited actions`, `comparison baseline`, `expected result schema`, `response language`, `localized control-narration rule`, and `stop conditions`. The narration rule requires human-facing receipt prose in the response language and preserves the exact result only as a secondary parenthesized or code-formatted token; it applies equally to private Inspect and Verify lanes that have no standalone Skill. Never include token counts or context-size targets; they do not influence dispatch, authority, continuation, completion, or acceptance.
52
+ `required` remains fail-closed for the current phase. Invoke an actual host worker capability before worker-owned work; never perform the assigned work locally and simulate worker participation or a worker result. If the host cannot start or attribute the required worker, stop before worker-owned mutation and keep acceptance incomplete. Convenience, cost, or local capability never downgrades it.
48
53
 
49
- - Diagnose reuses `rsp-diagnose` and remains read-only until it returns a discriminating cause or an explicit no-cause result. Its result is exactly one of `confirmed-same-scope`, `unresolved-same-scope`, or `boundary-changed`; the receipt also gives decisive evidence and the next safe discriminating check when one exists.
50
- - Inspect is a private Manager-only read-only lane. It gathers one independent evidence packet and may run alongside another read-only lane only when paths and verification resources are demonstrably isolated; otherwise keep it sequential. Its result is exactly one of `confirmed-same-scope`, `unresolved-same-scope`, or `boundary-changed`; the receipt also gives decisive evidence and the next safe discriminating check when one exists.
51
- - Fix reuses `rsp-implement`, receives explicit in-scope mutation authority, and is the sole product writer at its mutation boundary. Separate Group child mutation boundaries may overlap only under the existing isolated workspace and verification rule. Its result is exactly one of `changed-same-scope`, `no-change`, or `boundary-changed`; the receipt also gives `worker identity` when the host exposes it, changed paths, and fresh verification evidence.
52
- - Verify is a private Manager-only read-only lane and runs only for the Change-declared risk or after a failed correction. Its result is exactly one of `pass`, `failed-with-new-evidence`, `failed-without-new-evidence`, `unavailable`, or `boundary-changed`; the receipt also gives named checks, the observed diff boundary, `worker identity` when the host exposes it, and `independence: established | unavailable`. Fixed-scope review remains owned by `rsp-review`; Inspect and Verify are not public Skills.
54
+ ## Resolve the frontier
53
55
 
54
- Every receipt contains these common fields: `WorkRef`, `lane objective`, `effective authority`, `result`, `decisive evidence`, and `stop boundary`, plus the lane-specific fields above. Its human-facing narration follows the envelope's response language; when that differs from a canonical result value, localize the primary result explanation and retain the exact result only as a secondary parenthesized or code-formatted token. Inspect the actual diff and fresh verification before acceptance. After every ordinary same-goal Fix, Verify, Review, or Resolve Findings receipt, re-read status, owner, authority, diff, blockers, and decisive evidence internally before any later mutation or dispatch. Do not return to Core merely to repeat route selection or qualification.
56
+ Classify new unknowns in fail-closed order: `out-of-goal` → `owner-decision` → `fog` → `evidence-needed` → `executable`.
55
57
 
56
- Independent Verify is established only when its worker identity and the accepted Fix worker identity are both available and different. If the host cannot establish that identity boundary, record `independence: unavailable`; ordinary read-only Verify may still run, but Manager must not claim independent verification.
58
+ - `out-of-goal`: stop `reroute`.
59
+ - `owner-decision`: ask the `DecisionOwner` one highest-impact question; stop `ask-owner`.
60
+ - `fog`: create no synthetic work or mutation; stop `return-to-shape`.
61
+ - `evidence-needed`: collect one bounded factual answer without crossing an earlier boundary.
62
+ - `executable`: choose one Discipline only after ownership, authority, and required evidence are settled.
57
63
 
58
- Derive `AcceptanceDisposition` independently from execution; it is exactly `incomplete`, `evidence-complete`, or `review-clean`. Implementation verification, fixed-scope change review, and the durable writeback decision are separate gates. A required worker that was not created, did not return a valid required receipt, returned `unavailable` or `boundary-changed`, or could not satisfy required independent verification keeps acceptance `incomplete`. Accepted required receipts plus fresh declared verification may derive only `evidence-complete`; this verification is implementation verification. Only a clean fixed-scope change review may then derive managed `review-clean`. An execution receipt never derives `review-clean` directly; a verification receipt does not derive it either. The later durable writeback decision cannot substitute for fixed-scope change review. An unavailable required implementation worker cannot be replaced by controller mutation, and ordinary Verify cannot satisfy an acceptance contract that requires independent Verify.
64
+ Use Core's canonical stop vocabulary. No stop permits another dispatch, product mutation, lifecycle closeout, or Git action before its resume rule succeeds.
59
65
 
60
- Keep frontier classification, lane choice, envelopes, receipts, dispatch and retry counts, concurrency reasoning, and resume chronology response-only. Converged requirements and design belong in the selected Change, real dependencies in `Blockers`, and durable facts or rationale in the durable writeback decision. Create no frontier file, ticket map, ledger, registry, ambient hook, or numeric routing score.
66
+ ## Load worker delegation conditionally
61
67
 
62
- Total worker dispatch remains at most four. Before starting an optional Diagnose or Inspect dispatch, derive the currently known required remaining worker obligations: count one Fix when accepted mutation is still required and count one Verify when the declared acceptance risk or a failed correction still requires worker verification. Start the optional dispatch only when the remaining dispatch capacity covers that dispatch plus every known required obligation; otherwise skip it and preserve the completion path, or stop when no decisive path fits. This is dynamic capacity protection, not a fixed per-lane allocation.
68
+ For `DispatchDisposition: none`, do not read worker delegation procedure or claim worker participation; invoke the bounded local Discipline. For `preferred | required`, read [delegation and host evidence](references/delegation.md) before preparing a worker task or accepting a worker result.
63
69
 
64
- An evidenced failed correction permits at most one corrective retry. Start it only when new evidence makes another correction discriminating, the remaining dispatch capacity still covers the retry and every then-required Verify dispatch, and those remaining resources can still produce decisive acceptance evidence. A failure without new evidence, or a retry that cannot still be decisively verified, stops dispatch. Missing verification, drift, an authority boundary, or unavailable capability also stops dispatch. Use an explicit manual fallback only when it stays within the same owner and authority; Manager never absorbs an unavailable worker's unauthorized implementation.
70
+ Derive `AcceptanceDisposition` independently:
65
71
 
66
- ## Dispatch owned work
72
+ ```text
73
+ accepted required Discipline results + fresh declared verification → evidence-complete
74
+ evidence-complete + clean fixed-scope review → review-clean
75
+ ```
67
76
 
68
- Send a compact envelope that identifies the WorkRef, objective, authority, decisive evidence, and stop boundary. When the host supports workers and authorized implementation remains, dispatch at least one implementation worker; sequential execution does not permit the controller to absorb the whole implementation. The controller retains worker-result acceptance, integration verification, review convergence, lifecycle decisions, and commit eligibility and orchestration. It does not absorb Commit's exact Git procedure.
77
+ Every missing, invalid, unavailable, or boundary-changing required result keeps acceptance `incomplete`. Implementation verification, fixed-scope review, and the durable writeback decision remain separate gates.
69
78
 
70
- When dispatch cannot satisfy a required worker obligation, apply the AcceptanceDisposition rule above: return `StopDisposition: capability-unavailable`, keep acceptance `incomplete`, and stop. Absence of a dispatch event or receipt is never success, does not discharge the required obligation, and cannot be replaced by the controller claiming the worker's result.
79
+ ## Dispatch and convergence
71
80
 
72
- For a Group, dispatch child WorkRefs only in the current derived `plan.waves` wave. Assume shared paths, lockfiles, generated artifacts, integration state, real hosts, provider sessions, and hardware resources overlap unless an authorized isolated workspace and verification boundary exist. Keep blockers, later waves, overlaps, and dependent verification sequential. Dispatch in parallel only for isolated mutation paths and verification resources; delegation never implies concurrency. Workers receive no implied focus, lifecycle, Git, publication, deployment, or approval authority. Choose the cheapest decisive check and at most one integration gate.
81
+ Dispatch only for `preferred | required`; `none` invokes the local Discipline without synthetic delegation. Claim worker participation or counts only from host observations. If the host cannot start or attribute a required worker, stop before worker-owned mutation and keep acceptance incomplete.
73
82
 
74
- ## Continue from evidence
83
+ For a Group, dispatch only children in the current `plan.waves` wave. Keep shared writers, generated artifacts, test runners, browsers, Brokers, provider sessions, hardware, and other conflicting resources sequential unless the host and checkout evidence establish safe isolation. Delegation never implies concurrency. Run lane-local checks first, then at most one affected integration gate.
75
84
 
76
- Inspect diff and verification before accepting results; rerun `rsp status --json`. For a Group restrict it to declared children.
85
+ Do not impose a whole-run dispatch quota. Skip optional Diagnose or Inspect work unless it materially reduces uncertainty. Required independent Verify remains a separate obligation.
77
86
 
78
- Continue a clear in-scope ready successor while the goal, WorkRef topology, route, behavior, acceptance, interface, scope, and authority remain unchanged. Return to Core only when owner identity, topology, requested route, behavior, acceptance, public interface, scope, mutation authority, or external-action authority changes. At that boundary, suspend mutation, return decisive evidence, and never classify discovery or change topology; only Core may route authorized Shape and freshly select the next path.
87
+ ## Continue and load low-frequency branches
79
88
 
80
- Stop when discovery changes behavior, acceptance, interfaces, scope, mutation, or external authority. Retry only evidenced corrections. During recovery, reread authority and evidence. If incomplete archived child acceptance belongs to a closed Group, require separate explicit lifecycle authority for `rsp group reopen <group> --reason <text>` before `rsp reopen <group>/<child>`; restore neither children nor dependents implicitly. Never create controller status or parallel lifecycle state.
89
+ After inspecting changed paths, local diff, and declared verification, continue only while goal, WorkRef topology, route, behavior, acceptance, interface, scope, and authority remain unchanged. Return changed boundaries to Core.
81
90
 
82
- Read [interruption and recovery](references/interruption-recovery.md) only for a progress or status inquiry, explicit pause or release, an environment or verification stop, or resume from continuation pointers.
91
+ Load a low-frequency procedure only after its branch trigger is established:
83
92
 
84
- Read [managed review convergence](references/review-convergence.md) only after a fixed-scope re-review returns Findings or when an accepted in-scope Finding may require another bounded Resolve Findings pass.
93
+ - Read [interruption and recovery](references/interruption-recovery.md) only for a progress or status inquiry, explicit pause, environment or verification stop, or resume.
94
+ - Read [managed review convergence](references/review-convergence.md) only after an evidenced same-scope correction is needed or a fixed-scope review returns Findings.
95
+ - Read [lifecycle and delivery closeout](references/closeout.md) only when closeout becomes eligible from a valid selected handoff and `AcceptanceDisposition: review-clean`, for an authorized recovery checkpoint, or for an explicit push request. Before `review-clean`, every `manage.closeout` preset remains dormant.
85
96
 
86
- ## Preserve boundaries
97
+ If none of these triggers applies, do not read their references.
87
98
 
88
- Keep dispatch chronology out of Changes, Group Briefs, Specs, Decision Records. Changes retain converged requirements, outcomes, evidence, omissions, and blockers; Briefs retain shared completion without copied child state. Never persist the goal envelope, WorkSet, waves, or discovery classification.
99
+ Persist only accepted Tasks, decisive Verify evidence, and real Blockers; never transient coordination or acceptance process. Focus Capsules remain recovery pointers, never worker coordination or authority.
89
100
 
90
- Closeout requires a Core-selected and qualified handoff that remains valid under current evidence. For declined, unavailable, unselected, incomplete, or drifted handoffs, every `manage.closeout` preset is dormant; Core may report readiness/next action, but configuration executes neither archive nor commit. Earlier qualification does not carry forward across a new continuation without a fresh Core route result.
91
-
92
- Derive `CloseoutEligibility` independently; it is exactly `not-eligible`, `lifecycle-ready`, or `local-commit-ready`. Only `AcceptanceDisposition: review-clean` plus fresh owner, authority, exact diff, and decisive verification evidence can derive a ready value. Any other acceptance state derives `CloseoutEligibility: not-eligible`; neither archive nor commit runs.
93
-
94
- Read [lifecycle and delivery closeout](references/closeout.md) only after `CloseoutEligibility` becomes ready, when an explicitly authorized recovery checkpoint is being considered, or when the user explicitly requests push. The reference owns preset application, lifecycle commands, Commit handoff, and remote delivery constraints; this Skill retains the fail-safe above before loading it.
95
-
96
- Stop on unavailable dependencies, missing authority, failed verification, drift, or limits. When accepted work remains, preserve the focused owner unless explicit release or owner-conflict resolution requires otherwise, then return the incomplete continuation in this order: `WorkRef, Authority, Current state, Changed artifacts, Fresh verification, Blockers, and Next action`. Do not expose retry chronology or claim unobserved completion.
101
+ Stop on missing authority, unavailable capability, failed verification, drift, unsafe replay, or limits. When work remains, return `WorkRef, Authority, Current state, Changed artifacts, Fresh verification, Blockers, and Next action`. Do not claim review, archive, Commit, push, publication, deployment, approval, or human acceptance without its owning authority and evidence.
@@ -1,6 +1,8 @@
1
1
  # Lifecycle and delivery closeout
2
2
 
3
- Load this reference only after `CloseoutEligibility` becomes `lifecycle-ready` or `local-commit-ready`, when an explicitly authorized recovery checkpoint is being considered, or when the user explicitly requests push. The main Skill must first establish a valid selected handoff and retain its incomplete-or-drifted fail-safe.
3
+ Load this reference when closeout begins and `CloseoutEligibility` must be derived, when an explicitly authorized recovery checkpoint is being considered, or when the user explicitly requests push. The main Skill must first establish a valid selected handoff and retain its incomplete-or-drifted fail-safe.
4
+
5
+ Derive `CloseoutEligibility` independently; it is exactly `not-eligible`, `lifecycle-ready`, or `local-commit-ready`. Before deriving a ready value, run `rsp ready <change-work-ref> --json` for every terminal Change and require `completionGate: pass` plus `archiveReady: yes`. Only that machine gate, `AcceptanceDisposition: review-clean`, fresh owner, authority, exact diff, and decisive Required verification evidence can derive a ready value. Optional coverage warnings remain in the Receipt but do not block. Any other acceptance state derives `CloseoutEligibility: not-eligible`; neither archive nor commit runs. Human acceptance remains separate and unperformed unless the declared acceptance contract and current authority explicitly establish it.
4
6
 
5
7
  Valid selected handoff only: effective `manage.closeout` is an automatic grant ceiling narrowed by nearer restrictions and host enforcement. `manual` grants neither automatic archive nor commit. `lifecycle` grants lifecycle closeout after Manage-owned clean fixed-scope change review and a complete durable writeback decision but no Git action. `local` automatically grants lifecycle closeout and, for one eligible terminal non-small clean exact owned boundary, exactly one local Commit route without another user request. Separately justified recovery checkpoints remain possible within the same ceiling. Explicit current-turn authority may allow a local action not automated by the preset; denial wins.
6
8
 
@@ -0,0 +1,47 @@
1
+ # Delegation and host evidence
2
+
3
+ Load this reference only after Manage derives `DispatchDisposition: preferred | required` and before preparing a worker task or accepting a worker result.
4
+
5
+ ## Delegate one bounded task
6
+
7
+ Send one independently executable vertical slice. Start by telling the recipient that it is the already-dispatched Discipline worker for this assignment: it executes the bounded task directly and must not rerun parent Manage routing or require another worker. A delegated task includes only what the worker needs to act safely:
8
+
9
+ ```text
10
+ Work: <exact WorkRef>
11
+ Objective: <one bounded objective>
12
+ Authority: <exact owner sections or paths>
13
+ Read: <allowed read boundary>
14
+ Write: <allowed write boundary>
15
+ Verify: <required verification boundary>
16
+ Known facts: <only decisive current facts>
17
+ Prohibited actions: <explicit denials>
18
+ Stop conditions: <when to return without continuing>
19
+ Replay caution: <only when repeating effects may be unsafe>
20
+ ```
21
+
22
+ Omit empty optional fields. Do not attach host lifecycle schemas, correlation identifiers, JSON transport contracts, evaluator instructions, token targets, or acceptance fields. Workers receive no implied focus, lifecycle, Git, publication, deployment, approval, or nested-delegation authority. Nested delegation is prohibited unless the task explicitly grants a bounded descendant role and the parent remains responsible for its work and result.
23
+
24
+ Resume the same compatible worker only when the host makes that possible and the goal, role, authority, writer boundary, strategy, and evidence remain valid. Otherwise send a complete fresh task. A concise continuation may state changed facts, but never relies on hidden inheritance for authority or safety.
25
+
26
+ Each delegated Discipline owns its own result:
27
+
28
+ - **Diagnose:** `rsp-diagnose`; `confirmed | unresolved` with cause evidence and scope impact.
29
+ - **Inspect:** Manager-only read-only evidence packet.
30
+ - **Fix:** `rsp-implement`; `changed | no-change` with changed paths, verification, omissions, and any scope issue.
31
+ - **Verify:** `rsp-verify`; `pass | fail | unavailable` with named checks, evidence delta, omissions, and any scope issue.
32
+
33
+ Fixed-scope review remains owned by `rsp-review`. Manage adds no universal worker receipt and never asks a worker to report host identity, independence, admission, settlement, release, evidence validity, or acceptance.
34
+
35
+ ## Validate results and host facts
36
+
37
+ Treat three evidence sources separately:
38
+
39
+ - the worker-authored Discipline result states what the worker did and observed;
40
+ - host observations, when available, establish dispatch, attribution, activity, cancellation, completion, and whether different workers participated;
41
+ - Manager validates authority, actual changed paths, local diff, declared verification, omissions, and current acceptance.
42
+
43
+ Host facts are capabilities and observations, not RSP domain objects. Missing observations remain unavailable rather than inferred from prose, handles, elapsed time, topology, or successful tests. A worker never self-certifies identity, independence, resource release, evidence validity, or acceptance.
44
+
45
+ For required delegation, Manage must have an attributable worker-authored result that covers the assigned boundary. For required independent Verify, the host must establish that the accepted Fix and Verify came from different workers. If either condition cannot be established, acceptance remains `incomplete`. Manager must not author, repair, reconstruct, or substitute the missing worker result.
46
+
47
+ Inspect actual paths, diff, commands, outcomes, and omissions before accepting a result. A host-reported completion, a valid transport shape, successful integration tests, or absence of an error never substitutes for this validation.
@@ -1,7 +1,19 @@
1
1
  # Interruption and recovery
2
2
 
3
- Load this reference only for a progress or status inquiry, explicit pause or release, an environment or verification stop, or resume from continuation pointers.
3
+ Load this reference only for a progress or status inquiry, explicit pause, an environment or verification stop, or resume from continuation pointers.
4
4
 
5
- Treat a progress or status inquiry as an update, not a stop signal: report current evidence and continuing intent, then continue authorized work after the update while authority, verification, and blockers still permit it. For an explicit pause, interrupt active workers and confirm they have stopped before acknowledging the pause, keep the focused WorkRef selected, and do not mutate again until resume. Only an explicit release or unfocus request clears owner selection; ordinary pause and blockers preserve focus.
5
+ Reread the complete owner and authority only on a real invalidation, recovery, cross-session continuation, or closeout boundary.
6
6
 
7
- When an environment or verification boundary stops dispatch, preserve the focused owner. Update the Change only with durable blocker and verification facts, then return the incomplete continuation in this order: `WorkRef, Authority, Current state, Changed artifacts, Fresh verification, Blockers, and Next action`. Treat continuation prose only as pointers. On resume, reread the current authority, status, focused owner, worktree diff, blockers, and decisive evidence; mark stale or unverifiable claims pending and revalidate the selected handoff before mutation or worker dispatch. Never persist a paused state, worker registry, controller ledger, or execution chronology.
7
+ Treat a status inquiry as an update, not a stop signal. Report current evidence and continuing intent, then continue while authority, verification, and blockers permit it. Host liveness signals and elapsed time do not change a Discipline result or justify cancelling healthy work.
8
+
9
+ For an explicit pause, use the host's available interruption mechanism and confirm active workers or owned background processes have stopped before acknowledging the pause. Cancelling the caller's wait does not itself stop accepted work. Until stop is observed, do not start conflicting mutation or verification. A terminal message or partial output does not prove that owned work has ended.
10
+
11
+ Preserve the focused owner and focused WorkRef during ordinary pause or blockers. Only an explicit release or unfocus request, archive, or another authorized lifecycle action changes selection. Update the Change only with accepted outcomes, decisive verification, and durable blockers.
12
+
13
+ Manager may atomically replace the focused marker's optional Focus Capsule at a meaningful checkpoint. A valid v1 capsule contains one version declaration, exactly one single-line `Current`, `Evidence`, and `Next`, and at most one single-line `Resume check`. Exclude worker identities, host handles, machine-specific paths, raw messages, retry chronology, topology, authority, acceptance, logs, diffs, and duplicated Tasks. The capsule is a recovery pointer, never worker coordination, authority, or acceptance.
14
+
15
+ On resume, inspect actual effects before repeating work. An idempotent action may repeat after boundary inspection; an action requiring inspection must first check its prior effects; a non-repeatable action stops for recovery or owner input. Resume a compatible worker only when the host supports it and current authority, scope, writer boundary, strategy, and evidence still match. Otherwise send a complete fresh task.
16
+
17
+ For cross-session or cross-device recovery, distrust transient worker and liveness claims. Reread current authority, focused owner, status, checkout diff, dirty paths, blockers, execution location, and decisive evidence before mutation or delegation. Validate the selected handoff again, revalidate required verification, and re-establish any host evidence needed for worker attribution or independent verification. Host completion without an attributable required worker result keeps acceptance incomplete. Current authority always wins.
18
+
19
+ If incomplete archived child acceptance belongs to a closed Group, recovery requires separate explicit lifecycle authority for `rsp group reopen <group> --reason <text>` before `rsp reopen <group>/<child>`. Restore neither children nor dependents implicitly.
@@ -1,6 +1,8 @@
1
1
  # Managed review convergence
2
2
 
3
- Load this reference only after a fixed-scope re-review returns Findings or when an accepted in-scope Finding may require another bounded Resolve Findings pass.
3
+ Load this reference only after an evidenced same-scope correction is needed, a fixed-scope re-review returns Findings, or an accepted in-scope Finding may require another bounded Resolve Findings pass.
4
+
5
+ An evidenced same-scope failure permits at most three worker correction passes by default. Stop earlier on repeated evidence, non-convergence, changed scope or authority, unsafe replay, unavailable capability, or unverifiable correction. Required independent Verify remains a separate obligation.
4
6
 
5
7
  After fixed-scope re-review, Manage correlates the report with the selected Change, original authority, fresh verification, and transient pass count. An `accepted` Finding starts another Resolve Findings pass without asking the user to continue only when it remains inside the original behavior, acceptance, paths, mutation authority, and declared verification scope. Resolve Findings never self-loops.
6
8
 
@@ -4,7 +4,7 @@ description: Draft, audit, finalize, or reconcile evidence-based changelogs, rel
4
4
  license: MIT
5
5
  metadata:
6
6
  author: oevery
7
- version: "2026.07.26.1"
7
+ version: "2026.08.23.1"
8
8
  ---
9
9
 
10
10
  # RSP Release Docs
@@ -25,10 +25,10 @@ Before continuing, name the range, confirmed version or draft state, audience, s
25
25
 
26
26
  ## Select one branch
27
27
 
28
- - **Audit:** inspect fixed release prose and return findings without editing.
29
- - **Draft:** collect and project evidence. While identity can change, keep the ledger transient or use an existing release-fragment owner. Once identity is confirmed, update only authorized surfaces. Formal releases include release notes; update a changelog only when the repository owns one or the user asks; include migration guidance whenever users must act.
30
- - **Finalize for publication:** require confirmed identity and range, completed implementation Change closeout, and an exact clean candidate. An explicit tag, hosted release, registry publication, or equivalent public request must pass this branch even after prose review. Bind `ready` to the exact release commit.
31
- - **Reconcile published release:** observe the published identity and external surfaces, repair only authorized mutable surfaces, and assign immutable discrepancies to a corrective version or owner. Never rewrite a published package or move a tag to manufacture consistency.
28
+ - **Audit:** fixed release prose → inspect and return findings; no edits.
29
+ - **Draft:** when evidence projection is authorized. Mutable identity → transient ledger or existing release-fragment owner; confirmed identity → authorized surfaces only. Formal release → notes; owned or requested changelog → changelog; required user action → migration guidance.
30
+ - **Finalize for publication:** requires confirmed identity and range, completed implementation Change closeout, and an exact clean candidate. A tag, hosted release, registry publication, or equivalent public request selects this branch even after prose review. Bind `ready` to the exact release commit.
31
+ - **Reconcile published release:** requires an observed published identity and external surfaces. Repair authorized mutable surfaces; route an immutable discrepancy to a corrective version or owner. Never rewrite a published package or move a tag to manufacture consistency.
32
32
 
33
33
  Exactly one branch is active. Give every requested surface one disposition: draft, finalize, reconcile, audit only, not applicable, or blocked by a named decision.
34
34
 
@@ -36,7 +36,7 @@ Exactly one branch is active. Give every requested surface one disposition: draf
36
36
 
37
37
  A confirmed mechanical release does not require an RSP Change. Keep the ledger, command progress, authentication state, and publication handoff transient; manifests, changelog, release commit, tag, hosted release, and registry record own durable release history.
38
38
 
39
- Use an optional Release Change only when material version/range, migration, rollback, security, compatibility, cross-repository/team, multi-stage handoff, recovery, blocker, or acceptance decisions need a persistent owner. Do not create one for a checklist, verification transcript, or prose already owned by release surfaces.
39
+ Use an optional Release Change only when material version or range, migration, rollback, security, compatibility, cross-repository or cross-team, multi-stage handoff, recovery, blocker, or acceptance decisions need a persistent owner. Do not create one for a checklist, verification transcript, or prose already owned by release surfaces.
40
40
 
41
41
  ## Build evidence before prose
42
42
 
@@ -48,21 +48,19 @@ Read [evidence and surfaces](references/evidence-and-surfaces.md) before draftin
48
48
 
49
49
  Every relevant commit and work item must map to a net outcome or explicit exclusion. Collapse implementation chronology, omit additions reverted within the range, fold prerelease fixes into final behavior, and exclude internal work unless it changes public behavior, packaging, compatibility, security, operations, or release integrity.
50
50
 
51
+ Project each release surface from its audience, accepted range, and observed final state. Omit rejected session-only proposals, corrections, and temporary attempts that never entered the release baseline. A session-only proposal is not a release exclusion or omission: do not name or paraphrase it as a `without X`, `did not add X`, or `did not use X` compliance claim. Preserve actual removals, deprecations, compatibility boundaries, migrations, safety or security facts, failed external actions, requested comparisons, and unresolved risks when users or operators need them.
52
+
51
53
  ## Project distinct surfaces
52
54
 
53
55
  - **Changelog:** concise cumulative notable outcomes using the existing categories, or Keep a Changelog categories as fallback. Put breaking changes and required action first.
54
56
  - **Release notes:** audience-specific narrative led by the most important outcomes, required action, evidenced compatibility and limitations, plus the full range link. Do not merely duplicate the changelog.
55
- - **Migration notes:** identify affected users, ordered actions, changed defaults or removed surfaces, compatibility window, validation, and known rollback/support. Use a separate guide when this would overwhelm the notes.
57
+ - **Migration notes:** identify affected users, ordered actions, changed defaults or removed surfaces, compatibility window, validation, and known rollback and support paths. Use a separate guide when this would overwhelm the notes.
56
58
 
57
59
  Every claim must map to the ledger. Keep terminology aligned while respecting each surface's audience and lifetime.
58
60
 
59
- ## Finalize the exact candidate
60
-
61
- Read [publication lifecycle](references/publication-lifecycle.md) before a publication handoff or post-publication reconciliation.
61
+ ## Load publication lifecycle
62
62
 
63
- Finalization inspects public release surfaces and package inventory at the exact candidate—not every internal workflow artifact present in the tag. Require version, date, changelog, notes, migration guidance, comparisons, manifests, package inventory, release checks, and lifecycle closeout to agree. Shipped prose must remain true before, during, and after publication; transient publication or authentication state belongs only in the handoff.
64
-
65
- When Git delivery is authorized, implementation Changes remain independently reviewable and versioned shipped surfaces are finalized in a separate release commit. Return the version, immutable candidate ref, required external actions, fresh checks, omissions, and `ready` or `not ready`. `ready` means internally eligible for a separately authorized operation; it is neither publication authority nor evidence of publication.
63
+ Read [publication lifecycle](references/publication-lifecycle.md) before finalizing an exact publication candidate, preparing a publication handoff, or reconciling an observed publication. It owns exact-candidate consistency, package inventory, release-commit boundaries, readiness, and reconciliation.
66
64
 
67
65
  ## Protect authority and credentials
68
66
 
@@ -74,4 +72,6 @@ Treat one-time passwords, browser-auth URLs, device codes, tokens, and token-bea
74
72
 
75
73
  Before returning, confirm consistent range and identity; ledger coverage or explicit exclusions; claims bounded by evidence; prominent breaking, migration, security, deprecation, and known-limit information; convention-compatible links, dates, headings, language, and terminology; publication-invariant shipped prose; transient state with its owner; credential-free retained output; and edits limited to authorized paths.
76
74
 
75
+ The final handoff must directly state every material user or operator action needed to use, migrate, validate, rollback, or remain safe. A file link or generic summary may accompany the result but cannot replace the action. Preserve exact commands, API forms, versions, and other canonical action tokens while keeping the surrounding explanation concise and localized.
76
+
77
77
  Return the range, branch, changed or audited artifacts, coverage and exclusions, unresolved owner decisions, validation, handoff readiness when applicable, and whether any external action occurred.
@@ -4,6 +4,8 @@ Load this reference before finalizing an exact publication candidate or reconcil
4
4
 
5
5
  ## Finalization gate
6
6
 
7
+ Finalization inspects public release surfaces and package inventory at the exact candidate—not every internal workflow artifact present in the tag. Require version, date, changelog, notes, migration guidance, comparisons, manifests, package inventory, release checks, and lifecycle closeout to agree. Shipped prose must remain true before, during, and after publication; transient publication or authentication state belongs only in the handoff.
8
+
7
9
  Require all of the following at the exact candidate:
8
10
 
9
11
  - target version agrees across manifests, changelog heading/date, release notes, migration guidance, and exact-version assertions;
@@ -15,6 +17,8 @@ Require all of the following at the exact candidate:
15
17
 
16
18
  Any missing evidence yields `not ready` with the failed gate and owner. A `ready` result identifies the version, immutable candidate ref, required external actions, checks, and omissions without executing them.
17
19
 
20
+ When Git delivery is authorized, implementation Changes remain independently reviewable and versioned shipped surfaces are finalized in a separate release commit. Return the version, immutable candidate ref, required external actions, fresh checks, omissions, and `ready` or `not ready`. `ready` means internally eligible for a separately authorized operation; it is neither publication authority nor evidence of publication.
21
+
18
22
  ## Reconciliation
19
23
 
20
24
  After publication, observe the tag target, hosted release, registry version/dist-tags, and exact-version consumer command where applicable. Compare them with the finalization handoff and shipped inventory. Update authorized mutable surfaces only from observed state. Mark unknown facts unverified and record immutable drift with a corrective version or owner; never move tags or rewrite packages.
@@ -4,7 +4,7 @@ description: Resolve one fixed rsp-review report for an RSP-tracked change. Use
4
4
  license: MIT
5
5
  metadata:
6
6
  author: oevery
7
- version: "2026.07.28.1"
7
+ version: "2026.08.21.1"
8
8
  ---
9
9
 
10
10
  # RSP Resolve Findings
@@ -52,7 +52,7 @@ When work stops before a clean re-review, return Core's compact artifact-scoped
52
52
  - <localized Next action label>: <smallest bounded action and owner>
53
53
  ```
54
54
 
55
- The handoff contains authoritative pointers, not project truth. Return it in the response unless the user explicitly authorizes a path; never create a hidden receipt or persistent run state. It is not durable truth or a second state store. Exclude secrets, full logs, and duplicated Change text.
55
+ The handoff contains authoritative pointers, not project truth. Return it in the response unless the user explicitly authorizes an artifact path. Exclude secrets, full logs, and duplicated Change text.
56
56
 
57
57
  To recover, reopen every authority pointer, confirm the WorkRef and comparison still identify the intended scope, inspect current worktree drift, and revalidate claimed verification. Mark stale evidence pending instead of trusting the handoff. Continue only the named pass; host threads, agents, hooks, or proprietary resume features are optional and never required.
58
58
 
@@ -1,10 +1,10 @@
1
1
  ---
2
2
  name: rsp-review
3
- description: Review an RSP-tracked code, document, or mixed change against a fixed comparison scope and project authorities. 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.
3
+ 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.
4
4
  license: MIT
5
5
  metadata:
6
6
  author: oevery
7
- version: "2026.08.05.1"
7
+ version: "2026.08.19.1"
8
8
  ---
9
9
 
10
10
  # RSP Review
@@ -25,18 +25,15 @@ Do not switch branches or mutate the worktree to discover scope. If the comparis
25
25
 
26
26
  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.
27
27
 
28
- ## Classify the scope
28
+ ## Classify before loading
29
29
 
30
- - **Code:** executable code, tests, configuration, scripts, schemas, executable prompts, Skills, commands, hooks, and workflows.
31
- - **Document:** requirements, plans, Changes, Specs, Decision Records, ADRs, explanatory documentation, and user-facing documentation.
30
+ Do not read a pipeline reference until scope and authority are fixed. Then:
32
31
 
33
- Determine applicability only from artifacts inside the fixed comparison scope. A Change, Spec, instruction, implementation file, or test read only as authority or evidence is not thereby a reviewed artifact. Run each applicable pipeline; return `skipped` for a pipeline with no reviewed artifacts even when authority of that kind was inspected, and never return `clean` for authority-only documents. When such authority is missing, ambiguous, or conflicting, record it in Review Scope, Coverage, and Verdict; do not emit a Finding owned by a skipped pipeline. An executable document may need both; merge evidence for the same underlying issue into one cross-artifact finding.
32
+ 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.
33
+ 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.
34
+ 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.
34
35
 
35
- Inspect in a bounded order: fixed status/diff, selected authority, then only the smallest direct behavior chain and tests needed to resolve a concrete question. Stop when every applicable pipeline can be judged. Do not search unrelated files or broaden authority merely to fill Coverage or Findings.
36
-
37
- Read [Code review](references/code-review.md) only when the fixed reviewed artifacts make the Code pipeline applicable.
38
-
39
- Read [Document review](references/document-review.md) only when the fixed reviewed artifacts make the Document pipeline applicable. A mixed review reads both references; authority-only artifacts never trigger either reference by themselves.
36
+ 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.
40
37
 
41
38
  ## Report
42
39
 
@@ -70,6 +67,6 @@ Use this shape:
70
67
  <blocked | findings | clean, with the smallest next action>
71
68
  ```
72
69
 
73
- 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/breakage, P1 for normal-path contract failure, P2 for a meaningful edge or maintenance risk, and P3 only for narrow actionable improvement.
70
+ 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.
74
71
 
75
72
  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.
@@ -7,8 +7,9 @@ Check in this order:
7
7
  1. Safety and correctness: reachable bugs, data loss, security violations, invalid state transitions, broken contracts, unsafe failures, and regressions.
8
8
  2. Change and Spec fidelity: observable behavior against explicit intent and stable facts.
9
9
  3. Project standards: only rules established by nearest instructions or authoritative local conventions.
10
- 4. Production reachability — hard gate before completing a seam-dependent Finding: when a Finding or suggested correction depends on an adapter, wrapper, validator, normalizer, or similar seam, name the direct production caller, compare its actual callee with that seam, and verify that the changed production consumer actually reaches that seam. Put the comparison in Evidence or Coverage. If the live path bypasses the seam, report the bypass and do not present an isolated seam fix as sufficient.
10
+ 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.
11
11
  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.
12
- 6. Simplicity: unnecessary abstraction, duplication, indirection, dependency, or scope expansion with a concrete smaller alternative; never trade away required behavior.
12
+ 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.
13
+ 7. Simplicity: unnecessary abstraction, duplication, indirection, dependency, or scope expansion with a concrete smaller alternative; never trade away required behavior.
13
14
 
14
15
  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.
@@ -54,7 +54,7 @@ Keep one observable outcome per Change:
54
54
 
55
55
  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.
56
56
 
57
- A Change is a convergent current-plan/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.
57
+ 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.
58
58
 
59
59
  Use domain language. Mention agents only as real product actors or constraints, not authors or execution narrators.
60
60