@oevery/rsp 3.1.0-beta.0 → 3.1.0-beta.2

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.
@@ -0,0 +1,17 @@
1
+ # Durable review
2
+
3
+ Load this reference only after required Tasks and verification pass, or when auditing archive readiness.
4
+
5
+ Run `rsp check --focused` and `rsp show --focused --json`, or `rsp ready <name> --json` for an explicit Change. Treat `durableReview.factCandidateTargets` and `decisionRecordsPath` as routing advice, not permission. Spec delta markers are planning aids and are never promoted automatically.
6
+
7
+ Choose current facts and rationale independently. Use no update when there is no stable fact or lasting rationale worth rereading.
8
+
9
+ Write a current-fact update only when implementation changed a stable behavior, boundary, default, or constraint that future maintainers need. Prefer the smallest existing domain Spec, `.rsp/specs/design.md` for project-wide boundaries/navigation, or an explicitly authorized scoped `CONTEXT.md`/`AGENTS.md`; create a new Spec only for reusable project-level truth that fits nowhere existing.
10
+
11
+ Create or update a Decision Record only for a hard-to-reverse or surprising choice with a real tradeoff. It owns rationale, alternatives, tradeoffs, and consequences—not duplicated current facts. Choose one exact file under `durableReview.decisionRecordsPath`, not the directory itself.
12
+
13
+ Never use generated indexes, archives, `.rsp/rsp-rules.md`, or the managed RSP block as ordinary writeback targets. Keep narrative history, debugging notes, task chronology, and transient evidence out of Specs and Decisions.
14
+
15
+ Before archive, compress the Change to current design, completed outcomes, decisive evidence, omissions, remaining risks, and blockers. Archive only after required updates are written or explicitly unnecessary. Ordinary work needs later explicit Git authority for one independently reviewable logical commit. In qualified managed continuation, lifecycle closeout is independent from Git and follows the effective `manage.closeout` ceiling: `manual` leaves archive advisory, while `lifecycle` or `local` permits `rsp archive <change-work-ref>` after Core durable review unless nearer authority narrows it. For a shallow Group with lifecycle closeout, independently review and archive each child, re-derive completion, and run `rsp group close <group>` only after every child and Group gate passes. Inspect each complete lifecycle diff before deciding Git separately. Only `local` or explicit current-turn Git authority can make a scoped recovery checkpoint or terminal commit eligible; `manual` and `lifecycle` grant no commit. Terminal small work defaults to no commit, while terminal non-small work still needs explicit delivery or evidenced recovery value plus nearer-rule permission. A separately authorized release operation may use a dedicated release commit. Push remains separate and requires the user to mention it explicitly.
16
+
17
+ When commit eligibility and authority exist, give `rsp-commit` one envelope containing the Change, Group/wave, or confirmed release owner, exact allowed paths, decisive evidence, lifecycle state, and current authority. If that Skill is unavailable, perform the same bounded manual action: reread nearest authority and owner; inspect staged, unstaged, and untracked paths, the cached diff, and recent non-merge messages; stop without staging on ambiguity or stale evidence; stage only allowed paths; re-inspect the complete cached boundary; derive a repository-consistent Conventional subject plus a proportionate body and truthful RSP trailers; create one local commit; then observe its complete message, paths, remaining worktree, and remote safety without amending or performing any external action.
@@ -0,0 +1,11 @@
1
+ # Groups and dependencies
2
+
3
+ Load this reference before creating, focusing, planning, or closing grouped or dependent work.
4
+
5
+ - Executable WorkRefs are `<change>` or one direct `<group>/<change>` child. Deeper paths are unsupported.
6
+ - Use a Change Group only for at least two independently executable Changes sharing a goal or completion contract. Create it with `npx -y @oevery/rsp group create <group> [goal]`, replace placeholders, and declare each direct child under `Slices` before creating it.
7
+ - `<group>/brief`, stored as `<group>/00-brief.md`, is not executable or focusable. Read it before a selected child. Its declaration order guides navigation and its blockers are inherited as external blockers, not graph edges.
8
+ - Declare an exact prerequisite only as `- requires \`<change-work-ref>\`: <reason>` under the dependent Change's `Blockers`. Targets must be executable Changes.
9
+ - Use `rsp status --json` as the derived dependency view. `plan.nodes`, `ready`, `edges`, `blocked`, and `waves` are authoritative for the current inspection. Each edge means “change requires prerequisite”; filtered plans retain transitive prerequisite context.
10
+ - Do not infer nested ownership from the human dependency forest, create a parallel graph, or copy live delivery state into a Group Brief. Archived prerequisites resolve without rewriting dependents; incomplete inspection fails closed.
11
+ - Archive children independently. Close the brief with `rsp group close <group>` only after every direct child and group completion gate passes.
@@ -0,0 +1,45 @@
1
+ # Managed routing
2
+
3
+ Load this reference only for a requested completion or continuation that is not a report-only review or release operation and is either explicitly managed or has effective `manage.activation: auto` in status. Missing configuration preserves `explicit` activation with `local` closeout compatibility. Invalid configuration fails closed as `explicit` plus `manual` and must remain visible.
4
+
5
+ ## PREFLIGHT — resolve the owner
6
+
7
+ Treat the requested goal and independently allowed planning and product mutations as a transient authority envelope. Automatic activation grants controller selection only and never adds planning or product-mutation authority. Resolve the smallest sufficient owner before testing Manage eligibility.
8
+
9
+ - Reuse one unambiguous selected ready owner.
10
+ - Return tiny settled work to direct engineering without a synthetic Change or controller artifact.
11
+ - For clear non-trivial work with no sufficient ready owner, an explicit managed request authorizes only in-scope RSP planning artifacts unless the user requests no edits. Under automatic activation, route to Shape only when the current request or nearer authority independently permits those artifacts; configuration alone never does. Then re-read status/readiness and re-evaluate without another authorization round.
12
+ - If repository evidence leaves a material product, acceptance, public-interface, scope, mutation-authority, external-action, or human choice, Shape returns the single highest-impact owner decision and creates no implementation or controller artifact.
13
+
14
+ PREFLIGHT is complete only when one selected ready Change or shallow Group owns the requested outcome and no material decision remains.
15
+
16
+ ## QUALIFY — select or decline Manage
17
+
18
+ Select `rsp-manage` only for one selected ready Change or shallow Group with genuinely independent slices, long authorized continuation, or interruption recovery. Ineligible work returns to ordinary Core or Discipline action. Automatic routing is policy-selected, bounded by the requested goal, and not inferred from readiness alone.
19
+
20
+ ## CONTINUE — rederive from evidence
21
+
22
+ After accepted managed progress, re-read `rsp status --json` and apply PREFLIGHT again.
23
+
24
+ - Continue a clear in-scope ready successor.
25
+ - When ownership is clearly missing, Manage suspends dispatch and returns discovery evidence to Core. Shape keeps a cohesive correction in its Change, gives one independently verifiable and archivable result one Change, or gives at least two such results sharing one goal one shallow Group. Core then requalifies without another authorization round.
26
+ - Stop naturally only when neither a ready successor nor clearly missing ownership remains.
27
+ - Stop earlier for a material behavior, acceptance, public-interface, scope, mutation-authority, external-action, or human decision.
28
+
29
+ Never persist the goal envelope, WorkSet, waves, discovery classification, or transition chronology.
30
+
31
+ ## CONVERGE — bound review correction
32
+
33
+ After a managed fixed-scope re-review, correlate the report, selected Change, original authority, fresh verification, and transient convergence count. Return an in-scope `accepted` remaining or new Finding as `correction-needed` to another bounded Address Review pass without asking the user to continue. Address Review never self-loops.
34
+
35
+ Allow at most three Address Review passes per Change and stop earlier when the same Finding remains after two completed corrections. Stop for `needs-clarification`, material behavior/interface/scope or authority change, verification-budget expansion, an additional real-host/provider/network run outside existing authority, failed or unavailable decisive verification, or repeated non-convergence. Never persist the convergence count or correction chronology.
36
+
37
+ ## CLOSE — apply the bounded preset
38
+
39
+ Use effective `manage.closeout` as an automatic grant ceiling, narrowed by nearer restrictions and host enforcement. `manual` grants neither automatic archive nor commit. `lifecycle` grants lifecycle closeout after Core durable review but no Git action. `local` adds the existing exact-path local checkpoint or terminal-commit eligibility. Explicit current-turn authority may allow a named local action that the preset does not automate; denial still wins.
40
+
41
+ When lifecycle closeout is granted, archive a Change after Core durable review. A shallow Group independently reviews and archives each child, re-derives completion, then runs `rsp group close <group>` only after every child and the Group gate pass. Inspect the complete lifecycle diff after each mutation, including terminal owners.
42
+
43
+ Decide Git delivery separately. Under `local` or explicit commit authority, accepted downstream work may justify an exact-path recovery checkpoint unless commits are reserved or denied. Terminal small work defaults to no commit; terminal non-small work needs explicit delivery or evidenced recovery value plus nearer-rule permission. After deriving the owner, allowed paths, decisive evidence, lifecycle state, and authority, hand staging, structured message construction, one local commit, and post-commit observation to `rsp-commit`; when unavailable, return the equivalent bounded Core manual action against the same owner.
44
+
45
+ Push requires an explicit user mention plus an unambiguous remote, branch, and milestone. Never force-push; preserve local commits on failure. Managed authority never includes publication, deployment, approval, or human acceptance.
@@ -0,0 +1,11 @@
1
+ # Setup and repair
2
+
3
+ Load this reference only before initializing, auditing, migrating, or repairing RSP-managed state.
4
+
5
+ 1. Initialize with `npx -y @oevery/rsp init [--agents-mode managed|print] [--with-project-setup]`.
6
+ 2. `--with-project-setup` creates and focuses `changes/project-setup.md`. Without it, create that Change only when explicit bootstrap tracking is still needed.
7
+ 3. Put project-wide boundaries and Spec navigation in `.rsp/specs/design.md`, cohesive reusable facts in the smallest domain Spec, and stable operating instructions in the nearest project-owned `AGENTS.md` outside its managed block.
8
+ 4. Diagnose with `npx -y @oevery/rsp doctor`. Apply only deterministic repairs with `doctor --fix` or `rsp update`; `fixed` entries are real filesystem mutations, while an empty list means nothing changed.
9
+ 5. Do not use repair commands to decide stale focus, semantic durable updates, or archive readiness.
10
+
11
+ For manual audit, require `.rsp/`, managed roots, and nested Spec parents to be real directories. Require the project `AGENTS.md`, managed markers, fallback/config files, indexes, and placeholders to be regular files. Confirm the managed block, `specs/design.md`, configured Decision Record directory, valid group briefs and direct children, supported path depth, and focus markers matching executable Changes. Symlinks, special files, incomplete inspection, and file/directory identity collisions fail closed.
@@ -1,10 +1,10 @@
1
1
  ---
2
2
  name: rsp-address-review
3
- description: Resolve one fixed rsp-review report for an RSP-tracked change. Use when the user authorizes disposition of review findings, bounded fixes for accepted findings, fresh verification, re-review, or a recoverable artifact-scoped handoff; keep the reviewer report-only and never infer Git or publication authority.
3
+ description: Resolve one fixed rsp-review report for an RSP-tracked change. Use when the user or a qualified managed goal authorizes disposition, bounded fixes, fresh verification, re-review, or recovery; keep the reviewer report-only and never infer Git or publication authority.
4
4
  license: MIT
5
5
  metadata:
6
6
  author: oevery
7
- version: "2026.07.22.1"
7
+ version: "2026.07.25.1"
8
8
  ---
9
9
 
10
10
  # RSP Address Review
@@ -15,7 +15,7 @@ Render headings, field labels, explanations, and conclusion prose in the languag
15
15
 
16
16
  ## Fix scope and authority
17
17
 
18
- Require the review report, its fixed comparison or file set, the selected Change and sibling Group Brief when applicable, relevant project authority, and explicit permission for any proposed mutation. Read the current worktree and the smallest behavior chain needed to verify each Finding. Preserve unrelated modified, staged, and untracked work.
18
+ Require the review report, its fixed comparison or file set, the selected Change and sibling Group Brief when applicable, relevant project authority, and either explicit user permission or Core-confirmed original managed authority for proposed mutation. Read the current worktree and the smallest behavior chain needed to verify each Finding. Preserve unrelated modified, staged, and untracked work.
19
19
 
20
20
  Identify a Finding by its report order plus severity, title, and location. Stop if the report, comparison, Change, or Finding identity is missing or conflicting. A report grants investigation only: correction, verification, re-review, Git delivery, publication, deployment, approval, and external actions retain their own authority. Never infer Git or publication authority.
21
21
 
@@ -35,7 +35,7 @@ In one resolution pass, implement the smallest complete correction for accepted
35
35
 
36
36
  After the last relevant edit, run fresh verification for the affected behavior and the selected Change. A failed, unavailable, stale, or omitted check cannot close an accepted Finding. If a check exposes another defect, return it as evidence; do not begin an automatic retry loop.
37
37
 
38
- Require a fresh fixed-scope re-review before claiming resolution. Return a re-review request containing the original comparison, selected authority, post-fix file set or immutable comparison, implementation summary, dispositions, and verification evidence. The re-review remains report-only. On resume with its report, correlate original Findings as resolved or remaining and treat any new Finding as unresolved input for a later authorized pass.
38
+ Require a fresh fixed-scope re-review before claiming resolution. Return a re-review request containing the original comparison, selected authority, post-fix file set or immutable comparison, implementation summary, dispositions, and verification evidence. The re-review remains report-only. On resume with its report, correlate original Findings as resolved or remaining and return any new Finding as unresolved input to Core. Address Review never self-loops. Only qualified Manage may classify an in-scope `accepted` Finding as `correction-needed` and re-enter another bounded pass under the original managed authority and its separate convergence limit; standalone work requires new authority.
39
39
 
40
40
  ## Handoff and recovery
41
41
 
@@ -58,4 +58,4 @@ To recover, reopen every authority pointer, confirm the WorkRef and comparison s
58
58
 
59
59
  ## Return ownership
60
60
 
61
- Report the disposition table, changed artifacts, preserved unrelated work, fresh verification, re-review status, and the handoff when anything remains. Resolution is complete only when every Finding has a supported disposition, every accepted Finding has a verified correction, the fresh fixed-scope re-review is clean, and no `needs-clarification` input remains. Never claim archive, commit, push, publication, deployment, or approval.
61
+ Report the disposition table, changed artifacts, preserved unrelated work, fresh verification, re-review status, and the handoff when anything remains. Name `correction-needed` only when Core supplied a qualified managed continuation; it is not an external blocker or durable Change state. Resolution is complete only when every Finding has a supported disposition, every accepted Finding has a verified correction, the fresh fixed-scope re-review is clean, and no `needs-clarification` input remains. Never claim archive, commit, push, publication, deployment, or approval.
@@ -0,0 +1,69 @@
1
+ ---
2
+ name: rsp-codebase-audit
3
+ description: Audit one explicitly bounded repository or subtree for evidence-backed structural risks before implementation work is selected. Use for report-only discovery of ownership, dependency, production-path, change-amplification, or verification mismatches; do not use for security, performance, dependency, framework, style, or production-readiness audits.
4
+ license: MIT
5
+ metadata:
6
+ author: oevery
7
+ version: "2026.07.26.1"
8
+ ---
9
+
10
+ # RSP Codebase Audit
11
+
12
+ Discover the few structural risks worth considering next. Return a report only.
13
+
14
+ ## Trigger and input
15
+
16
+ Use this Skill when the user wants to discover material structural risks in an existing codebase before a Change, fixed review scope, or bounded design question exists. Require one explicit repository or subtree boundary and honor narrower user questions and exclusions. An RSP Change is not required; if one is focused, use it only when it matches the requested scope.
17
+
18
+ Read nearest project instructions and context first. Then inspect only the smallest useful chain of entry points, direct callers or consumers, state and data owners, relevant configuration, and focused tests. Treat implementation, tests, comments, and directory structure as evidence rather than product authority.
19
+
20
+ Do not substitute this audit for security, performance, dependency, framework, style, production-readiness, or speculative cleanup work. Return that mismatch and the required specialist owner instead.
21
+
22
+ ## Authority
23
+
24
+ The user owns the audit boundary and requested outcome. Project instructions, Specs, and decisions own established constraints. A focused Change may provide intent or scope but grants no additional mutation authority.
25
+
26
+ This Skill owns only its response report. It never modifies project code, tests, configuration, documentation, RSP artifacts, focus, lifecycle state, Git state, or external systems. It does not create a Change, choose product intent, design a solution, apply a fix, or invoke another Skill.
27
+
28
+ ## Action and verification
29
+
30
+ After scope and authority are fixed, read [structural audit lenses](references/structural-lenses.md) and select only the lenses relevant to evidence already encountered. Trace concrete owners and live paths; do not scan every directory or apply every lens mechanically.
31
+
32
+ Qualify a finding only when exact repository evidence establishes a reachable trigger, a realistic impact, and the implicated ownership or behavior chain. Verify a seam-dependent finding by naming the direct production consumer and confirming whether its actual callee reaches or bypasses the seam. Compare focused tests or other verification evidence with that same live path when the finding depends on claimed coverage.
33
+
34
+ Do not infer a finding from directory names, pattern matching, code size, framework taste, a generic checklist, or an isolated abstraction without a demonstrated downside. Prefer no finding to a weak finding. Stop inspecting when the requested boundary has enough evidence for at most five material findings, no qualifying finding remains, or further confidence requires authority or evidence outside the boundary.
35
+
36
+ ## Output
37
+
38
+ Render headings, field labels, explanations, and conclusions 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, while preserving paths, severity labels, confidence values, and the result values `findings`, `clean`, and `scoped uncertainty`.
39
+
40
+ Return findings ranked by material impact, then confidence. Emit at most five and use this shape:
41
+
42
+ ```md
43
+ ## Audit scope
44
+ - Boundary: <repository or subtree>
45
+ - Authority: <instructions, constraints, and material gaps>
46
+ - Inspected: <entry points and smallest behavior chains>
47
+ - Excluded: <explicit exclusions and unsupported specialist audits>
48
+
49
+ ## Findings
50
+ ### [P1-P3] <structural risk>
51
+ - Lens: <ownership | dependency | production path | change amplification | verification>
52
+ - Evidence: <exact paths and concrete chain>
53
+ - Trigger: <reachable condition>
54
+ - Impact: <real consequence>
55
+ - Confidence: <high | medium | low>
56
+ - Next owner: <smallest shaping or design question, or user decision>
57
+
58
+ ## Coverage
59
+ - <checked paths, unresolved uncertainty, and unobserved runtime behavior>
60
+
61
+ ## Result
62
+ <findings | clean | scoped uncertainty, with the smallest next action>
63
+ ```
64
+
65
+ Use `clean` when the inspected boundary contains no evidenced structural risk. Use `scoped uncertainty` when missing authority, inaccessible evidence, or an unsafe runtime requirement prevents judgment; name exactly what is missing and its owner. Do not manufacture advice to fill the report.
66
+
67
+ ## Stop
68
+
69
+ Stop before auditing when the boundary or owner intent is materially ambiguous. Stop during inspection when evidence requires credentials, an unsafe or destructive probe, production side effects, mutation, or material expansion beyond the explicit boundary. Return the evidence collected, the unverified claim, and one smallest next action. Never continue into shaping, design, implementation, review, archive, Git delivery, publication, deployment, or approval.
@@ -0,0 +1,35 @@
1
+ # Structural audit lenses
2
+
3
+ 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.
4
+
5
+ ## Ownership and sources of truth
6
+
7
+ Trace where important state or data is created, validated, mutated, persisted, recovered, and consumed. Look for competing writers, duplicated authority, or a lifecycle whose transitions are split across owners that cannot enforce the same invariants. A cache, projection, generated artifact, or test fixture is not automatically a competing source of truth. Report only when a reachable path can diverge and the divergence has a concrete consequence.
8
+
9
+ ## Module and dependency direction
10
+
11
+ 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.
12
+
13
+ ## Production-path reachability
14
+
15
+ Trace the smallest complete path from a real entry point to the behavior under examination. For an adapter, validator, normalizer, wrapper, or policy seam, name the direct production caller and its actual callee. Report a bypass only when the live consumer reaches a different path, and distinguish an unused seam from a seam used by another valid entry point. Do not treat API existence, registration, generated code, or an isolated passing test as proof of lifecycle integration.
16
+
17
+ ## Change amplification and repeated knowledge
18
+
19
+ Use repository history only when it is available and necessary; otherwise trace one representative behavior across schemas, types, adapters, callers, configuration, tests, and documentation. Report amplification when one behavioral change requires independently maintained edits because ownership is fragmented. Similar text, generated output, deliberate boundary translation, and test fixtures are not duplication by themselves. Code reduction is never the objective.
20
+
21
+ ## Verification mismatch
22
+
23
+ Map focused tests, assertions, or checks to the same production path and public behavior claimed by the implementation. Look for tests that exercise only an isolated seam while the live consumer bypasses it, or verification that cannot observe the relevant state transition or failure contract. Missing tests alone are not a structural finding; establish that existing evidence creates false confidence or leaves a material invariant unverified.
24
+
25
+ ## Finding gate and ranking
26
+
27
+ Before retaining a finding, answer all of these from repository evidence:
28
+
29
+ 1. What exact entry point, owner, caller, or artifact anchors it?
30
+ 2. What reachable condition triggers the problem?
31
+ 3. What realistic user, operator, data, or change-cost impact follows?
32
+ 4. Which evidence confirms the full chain, and what remains unobserved?
33
+ 5. What is the smallest next owner: a user decision, shaping question, or one bounded design question?
34
+
35
+ 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.
@@ -0,0 +1,42 @@
1
+ ---
2
+ name: rsp-commit
3
+ description: Create one authorized, exact-scope local commit for an RSP-owned Change, Group wave, or confirmed release boundary with a repository-consistent structured message.
4
+ license: MIT
5
+ metadata:
6
+ author: oevery
7
+ version: "2026.07.26.1"
8
+ ---
9
+
10
+ # RSP Commit
11
+
12
+ Create one reviewable local commit after Core or qualified Manage has already derived the owner, allowed paths, decisive verification, lifecycle state, and commit authority. Skill availability grants none of those facts. Accept only one Change, one integration-coupled Group wave, one Group closeout, or one confirmed release commit boundary.
13
+
14
+ ## Audit the envelope
15
+
16
+ Read nearest project authority, the relevant open Change, Group Brief and children, archive, or confirmed release owner, then inspect `git status`, staged, unstaged, and untracked paths, the cached diff, and recent non-merge commit messages. Recheck the supplied verification and lifecycle facts against current repository state.
17
+
18
+ Stop without staging when the owner, allowed paths, commit authority, verification, lifecycle state, or logical boundary is missing, ambiguous, stale, or conflicts with unrelated work. Stop when an allowed path contains mixed owned and unrelated changes that cannot be staged without guessing. Never infer archive, Group closeout, commit, push, tag, publication, approval, amend, rebase, force-push, or history-rewrite authority.
19
+
20
+ ## Derive the message
21
+
22
+ Choose subject language from explicit current instruction, then nearest repository authority, then the clear style of recent non-merge commits. Response language, RSP artifact language, and preferences remembered from another repository do not select it. When recent history is materially mixed and no nearer rule resolves it, return the single language decision to its owner.
23
+
24
+ Use the repository's established Conventional Commit form when present. Derive type and scope from the owned outcome and repository history, not from the conversation. Keep the subject concise and imperative or otherwise repository-consistent.
25
+
26
+ A tiny or mechanical boundary may be subject-only when that subject fully explains it. For a non-trivial Change, integration wave, Group closeout, or release commit, add two to four concise bullets covering:
27
+
28
+ - the observable outcome;
29
+ - material behavior or compatibility boundaries; and
30
+ - an important omission or risk when one affects review.
31
+
32
+ Do not copy file lists, command transcripts, routine verification output, execution chronology, or the full Change/archive. Add only truthful trailers: one `RSP-WorkRef:` per included WorkRef, `RSP-Group:` when the Group is the commit owner, authoritative external references already owned by the work, and `BREAKING CHANGE:` only for an actual breaking change. Never invent an issue, co-author, sign-off, breaking change, or AI attribution.
33
+
34
+ ## Commit the exact boundary
35
+
36
+ Stage only the explicit allowed paths. Re-read `git status --short`, inspect the complete cached path list and cached diff, and confirm they represent exactly one owner boundary with no sensitive material. If the cached boundary is wrong, stop and leave unrelated work untouched; do not repair it by broad staging, destructive reset, or history rewrite.
37
+
38
+ Create one local commit with the prepared subject, optional body, and trailers. Do not push, tag, publish, amend, rebase, or force-push. Afterward observe `HEAD`, the complete committed message, committed paths, remaining worktree state, and remote refs when a remote-safety assertion is required. A commit command succeeding is insufficient if the observed message or paths differ from the prepared boundary.
39
+
40
+ ## Return the receipt
41
+
42
+ Return the commit SHA, owner and included WorkRefs, committed paths, parsed subject/body/trailers, remaining worktree paths, and explicit omissions. Report a stop before staging, commit failure, or post-commit mismatch truthfully; never silently amend or create a second commit to repair the first.
@@ -1,21 +1,26 @@
1
1
  ---
2
2
  name: rsp-design
3
- description: Resolve one material domain-model, module/seam, or evidence-seeking design question for an explicit or unambiguously focused RSP Change without implementing production behavior or writing durable project truth.
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.
4
4
  license: MIT
5
5
  metadata:
6
6
  author: oevery
7
- version: "2026.07.22.2"
7
+ version: "2026.07.26.1"
8
8
  ---
9
9
 
10
10
  # RSP Design
11
11
 
12
- Resolve one design question and return the result to its existing RSP owner. Do not implement the result.
12
+ Resolve one design question. Do not implement it.
13
13
 
14
14
  ## Establish the question and authority
15
15
 
16
- Require an explicit WorkRef or exactly one unambiguous focus marker. Read the nearest project instructions and context, the RSP core Skill or fallback protocol, the selected Change and sibling Group Brief, then the smallest relevant Specs, decisions, code, tests, callers, and runtime evidence.
16
+ State one explicit bounded design question. Read project authority and the smallest relevant Specs, decisions, code, tests, callers, and runtime evidence.
17
17
 
18
- State the single material question before analysis. If the WorkRef, question, required evidence, owner intent, or mutation authority is missing or ambiguous, stop with the smallest blocker. Never invent product intent.
18
+ Choose one ownership mode:
19
+
20
+ - **Pre-Change Design:** use when no Change is selected and the request already contains one bounded design question. Remain report-only and return to the user. If outcome, scope, non-goals, acceptance, or decomposition remains materially unclear, return the request to Shape instead of creating an implicit planning owner. Do not invent a WorkRef, continuation, or artifact.
21
+ - **Tracked Design:** require an explicit WorkRef or exactly one unambiguous focus marker. Read the selected Change and sibling Group Brief, then return the result to the same WorkRef.
22
+
23
+ Stop on an ambiguous question, evidence boundary, owner intent, authorized-write owner, or required mutation authority. Never invent product intent.
19
24
 
20
25
  ## Load one design mode
21
26
 
@@ -25,11 +30,11 @@ Load only the reference matching the question:
25
30
  - Read [module and seam design](references/module-seams.md) for interface obligations, caller complexity, adapters, test surfaces, or seam placement.
26
31
  - Read [reversible exploration](references/reversible-exploration.md) only when a material conclusion depends on unobserved behavior and a cheap safe probe can provide it.
27
32
 
28
- Keep evidence-driven conclusions separate from choices only the owner can make. Compare at least one credible alternative when alternatives exist; do not manufacture options for a conclusion forced by evidence or authority.
33
+ Separate evidence-driven conclusions from owner choices. Compare one credible alternative when alternatives exist; do not manufacture options when evidence or authority forces the conclusion.
29
34
 
30
35
  ## Preserve artifact ownership
31
36
 
32
- Default to report-only. When the user or project explicitly authorizes updating the selected Change, write settled planned design only under its `Design` section. Do not write Specs, Decision Records, `CONTEXT.md`, `AGENTS.md`, production code, lifecycle state, focus, archives, or Git state. Identify possible durable current facts or rationale only as artifact-routing candidates for the Core durable review.
37
+ Default to report-only. Pre-Change Design never mutates artifacts. In Tracked Design, when the user or project explicitly authorizes updating the selected Change, write settled planned design only under its `Design` section. Do not write Specs, Decision Records, `CONTEXT.md`, `AGENTS.md`, production code, lifecycle state, focus, archives, or Git state. Identify possible durable current facts or rationale only as artifact-routing candidates for the Core durable review.
33
38
 
34
39
  An exploration additionally requires explicit disposable-code authority and the cleanup contract in its reference. A design request alone grants neither production mutation nor external side-effect authority.
35
40
 
@@ -37,7 +42,7 @@ An exploration additionally requires explicit disposable-code authority and the
37
42
 
38
43
  Follow Core's response-versus-artifact language boundary: use the requested language for natural prose, while any authorized `Design` update follows the selected Change's language and canonical headings. Do not use a technical token alone as a response label; retain it only in parentheses after a localized label. Return these semantic fields:
39
44
 
40
- - selected WorkRef and exact question;
45
+ - ownership mode, selected WorkRef when tracked, and exact question;
41
46
  - inspected evidence and material gaps;
42
47
  - recommendation and evidence-driven reasoning;
43
48
  - credible alternatives and tradeoffs;
@@ -45,4 +50,4 @@ Follow Core's response-versus-artifact language boundary: use the requested lang
45
50
  - artifact routing and any authorized Change update;
46
51
  - smallest next action.
47
52
 
48
- Return to Shape or the user against the same WorkRef. Do not create parallel state, recursively invoke another Skill, implement, review, archive, stage, commit, push, publish, deploy, or approve.
53
+ Pre-Change results return to the user; name Shape as the smallest next action only when accepted work needs an executable owner. Tracked results return to Shape or the user against the same WorkRef. Do not create parallel state, recursively invoke another Skill, implement, review, archive, stage, commit, push, publish, deploy, or approve.
@@ -1,53 +1,52 @@
1
1
  ---
2
2
  name: rsp-manage
3
- description: Continue one explicitly requested focused RSP Change through genuinely independent bounded slices or interruption recovery while keeping ordinary work on existing Core and Discipline paths.
3
+ description: Continue one bounded managed goal selected explicitly or by effective project policy across ready RSP Changes or shallow Change Groups.
4
4
  license: MIT
5
5
  metadata:
6
6
  author: oevery
7
- version: "2026.07.24.1"
7
+ version: "2026.07.26.1"
8
8
  ---
9
9
 
10
10
  # RSP Manage
11
11
 
12
- Manage one focused Change only after the user explicitly requests managed continuation. Keep RSP artifacts as durable truth and process data transient.
12
+ Manage one selected ready Change or shallow Change Group after Core selects it from an explicit managed request or effective `manage.activation: auto` policy. Keep RSP artifacts as durable truth and process data transient. The requested goal defines the authority envelope; automatic activation grants selection only, not mutation authority.
13
13
 
14
14
  ## Qualify before mutation
15
15
 
16
- Require one focused, ready Change and sufficient mutation authority. Snapshot the user authority, nearest instructions and context, Group Brief when present, Change, relevant Specs and Decisions, current RSP status, and worktree once.
16
+ Before dispatch, read each qualified WorkRef—including successors—complete Change or Brief/children, Specs/Decisions, authority, `rsp status --json`, and worktree. Missing configuration preserves `explicit` activation with `local` closeout compatibility; invalid configuration fails closed as `explicit` plus `manual` and remains an error.
17
17
 
18
- Activate only for at least two non-overlapping mutation scopes with independent verification, genuinely long authorized continuation, or interruption recovery whose stale-evidence cost justifies orchestration. A small single slice, tightly coupled scopes, or host worker availability alone is ineligible. On decline, make no mutation, create no dispatch envelope, receipt, budget, or controller state, and return the exact Core or Discipline next action without executing it.
18
+ Eligible Change needs independent scopes or long/recovery; Group needs two ready children or long/recovery. Small, coupled, or worker-only work is ineligible. Decline without mutation/controller artifact; return Core/Discipline action.
19
19
 
20
- Identify allowed mutations, required verification, unavailable acceptance, and lifecycle, Git, publication, deployment, approval, or other external-action boundaries. Preserve unrelated work. Unless the user sets a tighter limit, allow at most four worker dispatches and one corrective retry for the whole run.
20
+ Preserve unrelated work; release identity needs explicit authority. Allow four worker dispatches and one worker corrective retry across the whole managed run; owner transitions do not reset them.
21
21
 
22
- ## Dispatch only real work
22
+ ## Dispatch owned work
23
23
 
24
- Send an internal compact envelope only to a worker that will execute an eligible slice:
24
+ Send a compact envelope: WorkRef, objective, authority, evidence, stop boundary. For a Group, dispatch child WorkRefs only in the derived `plan.waves` wave. Parallelize independent mutations; shared paths, lockfiles, generated artifacts, and integration outputs overlap unless an authorized isolated workspace exists. Keep blockers, later waves, overlaps, and dependent verification sequential. Workers receive no implied focus, lifecycle, Git, publication, deployment, or approval authority. Choose the cheapest decisive check and one integration gate at most.
25
25
 
26
- ```md
27
- - WorkRef: <focused Change>
28
- - Objective: <one observable slice>
29
- - Authority: <exact inputs and allowed mutations>
30
- - Return: <changed artifacts, decisive verification, omissions, and stop boundary>
31
- ```
26
+ ## Continue from evidence
32
27
 
33
- Parallelize only non-overlapping mutation scopes with independent verification. Keep overlapping mutations and dependent verification sequential. Workers receive no implied focus, lifecycle, durable-write, Git, publication, deployment, approval, or cleanup authority.
28
+ Inspect diff and verification before accepting results; rerun `rsp status --json`. For a Group restrict it to declared children.
34
29
 
35
- For each slice choose the cheapest decisive focused check. Run at most one broader integration gate, and only when combined mutations create integration risk or project authority requires it. Do not multiply checks per worker or retain disposable process tests.
30
+ At owner boundaries, Core re-derives from goal. Continue a clear in-scope ready successor. Stop only when neither a ready successor nor clearly missing ownership remains. Otherwise suspend dispatch and return evidence to Core; Core routes Shape and requalifies without another authorization round. Manage neither classifies discovery nor changes topology.
36
31
 
37
- ## Continue from current evidence
32
+ Stop when discovery changes behavior, acceptance, interfaces, scope, mutation, or external authority. Retry only evidenced corrections. During recovery, reread authority and evidence. Never create controller status or parallel lifecycle state.
38
33
 
39
- After each return inspect the actual diff and freshly observed verification. Accept a slice only when the owned output exists, decisive checks pass, omissions are named, and the Change still owns the result. Continue only after positive progress.
34
+ ## Converge managed review
40
35
 
41
- Use the one corrective retry only when new evidence identifies an in-scope correction. Otherwise stop at the failure. Inspect current worktree and evidence after returns, but reread stable authority only during interruption recovery or when evidenced authority or worktree drift could invalidate the snapshot.
36
+ After fixed-scope re-review, Core correlates the report, Change, original authority, verification, and transient pass count. When an `accepted` Finding stays inside original behavior, acceptance, paths, mutation authority, and verification budget, start another Address Review pass without asking the user to continue. Address Review never self-loops.
42
37
 
43
- Treat handoffs as transient pointers, never project truth. During recovery, reread current authority and referenced evidence, return changed or unverifiable completion to pending, and enforce the remaining finite limits. Never create durable controller status, retry graphs, receipts, or parallel lifecycle state.
38
+ Allow at most three Address Review passes per Change, separate from worker retry, and stop when the same Finding remains after two completed corrections. Also stop for `needs-clarification`, material product/interface/scope change, new mutation or external authority, an additional real-host/provider/network run outside existing verification authority, or failed/unavailable decisive verification. Return the single required owner input. Treat an eligible in-scope Finding as `correction-needed`, not an external blocker. Keep counts and correction chronology transient.
44
39
 
45
- ## Preserve artifact and authority boundaries
40
+ ## Preserve boundaries
46
41
 
47
- Keep dispatch details, retry history, limits, and process chronology out of Changes, Specs, Decision Records, and the user-facing final result. Update the selected Change only with converged requirements, completed outcomes, decisive evidence, omissions, and real blockers. Durable facts and rationale still use Core's normal artifact-routing decision.
42
+ 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.
48
43
 
49
- Treat archive guidance as advisory unless the run has explicit lifecycle-closeout authority and Core has completed its durable decision. Archive never grants Git or publication authority.
44
+ 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 Core durable review but no Git action. `local` grants lifecycle closeout plus the existing exact-path local checkpoint or terminal-commit eligibility. Explicit current-turn authority may allow a local action not automated by the preset; denial wins.
50
45
 
51
- Stop at an unresolved owner decision, unavailable service, credential, device, environment, or human acceptance; missing external-action authority; verification without an evidenced in-scope correction; drift; or exhausted limits. Do not route around the boundary.
46
+ When granted, close lifecycle before any commit. For Change, after Core durable review run `rsp archive <change-work-ref>` and inspect the complete lifecycle diff. For shallow Group, durable-review/archive each child independently, rederive completion, then when all children plus Group gate pass run `rsp group close <group>`; inspect the complete lifecycle diff after each mutation. This includes terminal owners. Stop unless review and clean boundaries are proven.
52
47
 
53
- Return only completed and pending slices, fresh verification, omissions, the real boundary owner, and one next action. Do not expose dispatch, retry, or budget chronology and do not claim archive, Git, publication, deployment, approval, or human acceptance that was not completed under explicit authority.
48
+ Decide commit separately. Under `local` or explicit commit authority, downstream work may justify one recovery checkpoint: give `rsp-commit` owner, paths, evidence, lifecycle, and authority to stage exact owned paths, inspect cached boundary, commit one reviewable Change or integration-coupled wave, then derive status. Apply to Group/release owners; use Core fallback if unavailable. Terminal small owners default to no commit. A terminal non-small owner commits only for explicit delivery or evidenced recovery value when nearer rules allow. Without clean exact boundary, return without staging. Archive grants no Git or publication authority.
49
+
50
+ Push is opt-in only when user explicitly mentions push and remote, branch, and Group or goal milestone are unambiguous or accepted. Push there, or earlier only for required remote CI, recovery, or collaboration. Never force-push, infer push from commit authority, or push a protected or ambiguous branch. Failure preserves local commits and stops at remote boundary. Return to Core before a separate release operation and dedicated release commit.
51
+
52
+ Stop on unavailable dependencies, missing authority, failed verification, drift, or limits. Return WorkRefs, verification, omissions, boundary owner, and next action. Do not expose retry chronology or claim unobserved completion.