@oevery/rsp 3.3.0 → 4.1.0

package/skills/rsp/references/managed-routing.md

@@ -1,45 +0,0 @@
-# Managed routing
-
-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.
-
-## OWNER PREFLIGHT — Core resolves the owner without execution
-
-Use this route after Core has preserved the fixed-scope Review, release, isolated Design, and settled direct-work exceptions. Here fixed-scope Review means the explicit report-only fixed-scope change review. Under `manage.activation: explicit`, consider Manage only for an explicitly managed request. Under `manage.activation: auto`, qualify only from an observable coordination obligation; task size, file count, and elapsed effort are not substitutes.
-The tiny settled-work exceptions remain direct when the concrete session task is already clear and no sufficient ready WorkOwner exists. A Manage decline for that case reports the complete small-work exclusion and performs no Manage handoff or worker delegation; it does not manufacture a Change merely to satisfy controller entry.
-
-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. Core resolves the smallest sufficient owner before testing Manage eligibility, without dispatching work or mutating product state.
-
-Before focusing, dispatching, or mutating a different WorkRef, inspect dirty paths and the diff against the prior owner's declared and observed product or durable-truth paths. Overlap never changes owner implicitly: continue the same open WorkRef, explicitly reopen its archived acceptance when authorized and applicable, use an explicitly authorized integration owner, or stop for boundary resolution. Disjoint authorized work may proceed without staging or a forced commit; insufficient ownership evidence stops the transition.
-
-Core derives one ownership `ControlOutcome`. `WorkOwner` means the selected shape-ready Change or shallow Group. When one unambiguous ready WorkOwner exists, Core proceeds to QUALIFY. Missing or non-ready ownership uses `RouteDisposition: shape` only when the current request or nearer authority independently permits in-scope RSP planning artifacts; configuration alone never does. Shape returns the ready WorkOwner to Core, which re-reads status and freshly derives ownership, route, and qualification without another authorization round. A material product or authority decision stops with `StopDisposition: ask-owner` and names its `DecisionOwner`. An invalid WorkRef, topology, dirty-path, route, scope, or authority boundary stops with `StopDisposition: reroute` rather than converting it into a product question.
-
-A prior direct report, design, tiny, or small route is not sticky. Before later-turn mutation, rederive from the now-authorized objective and prospective work. Material expansion into cross-module implementation, multiple acceptance surfaces, repeated production-path correction, real-host validation, bounded review convergence, lifecycle delivery, or a clear ready successor requires Core to establish or reuse the smallest sufficient WorkRef and rerun owner preflight plus fresh Manage qualification before mutation. Unchanged tiny/small follow-ups remain direct; elapsed time and message count alone never trigger escalation.
-
-Owner preflight creates no Task, Blocker, worker task, frontier, ticket, run record, or synthetic WorkRef. Manage has no pre-owner Intake and never creates, focuses, or reshapes the durable owner.
-
-## QUALIFY — select or decline Manage
-
-Select `rsp-manage` only for one selected ready Change or shallow Group that qualifies through at least one independent path: genuinely independent slices, interruption recovery, distinct execution and acceptance owners, real-host, provider, or hardware verification, bounded finding convergence, managed lifecycle coordination, a clear ready successor, or prospective execution that contains more than one bounded phase or authority surface. A Change with one of these coordination obligations does not also need parallelizable slices. Derive the signal before dispatch from the authorized objective and expected phases; elapsed wall-clock minutes are never qualification evidence.
-
-A Group qualifies when it has at least two ready children, or when the continuation qualifies through prospective signals or recovery.
-
-Multiple files, Specs, product presentation, public documentation, or verification files do not by themselves qualify Manage. Under automatic activation, a hard near-miss remains direct when it has one owner, one writer, one execution phase, one integrated check, no recovery, no independent acceptance obligation, and no ready successor. Do not manufacture a second phase, worker, or acceptance surface from file layout.
-
-Substantial sequential work remains selected when a real multi-phase or authority obligation exists, such as implementation followed by independently owned acceptance, bounded review convergence, real-host verification, lifecycle closeout, or a ready successor. Sequential dispatch does not erase that coordination signal. Without such a signal, decline Manage and continue the ordinary Core or Discipline route. Worker-only work remains ineligible. Readiness alone does not qualify work without a requested completion or continuation, and automatic routing remains bounded by the requested goal.
-
-Make the route observable inside the single outer `ControlOutcome`: report `selected` with the decisive qualification signal, or `declined` with the complete direct-work exclusion and exact Core or Discipline action. Selection transfers current-phase control from Core to Manage; it does not imply worker delegation. The outer mode is `solo` before or without any worker, `delegated` when one worker participates, or `coordinated` when multiple workers participate or acceptance requires a separate verifier. Manage independently derives `DispatchDisposition: none | preferred | required` after selection. If dispatch applies, retain the strategy only as nested technical evidence and report the concrete overlap or isolation evidence that makes execution sequential or parallel. Selection, decline, dispatch disposition, and strategy reasoning remain transient and create no controller state.
-
-## HANDOFF AND RETURN — bound selected execution
-
-Core and this reference solely own initial qualification and the `selected | declined` route result. Core hands selected Manage the goal, WorkRef, authority envelope, decisive qualification evidence, closeout ceiling, and exact return boundaries as transient control data. Manage validates the current owner, authority, baseline, observed execution location, conflicting resources, acceptance surfaces, and diff drift, then chooses the smallest safe strategy; it never repeats direct-versus-managed eligibility. Selected execution remains wholly owned by `rsp-manage`.
-
-- Ordinary Fix, Verify, Review, or Resolve Findings receipts remain inside Manage for fresh same-goal revalidation.
-- A clear in-scope ready successor under the unchanged owner topology and authority may continue inside the same managed goal.
-- Owner identity, topology, requested route, behavior, acceptance, public interface, scope, mutation authority, or external-action authority changes return evidence to Core for fresh ownership and routing.
-- Shape is entered only through Core when durable owner refinement is independently authorized.
-
-The managed goal envelope and returned control objects remain transient.
-
-## Dormant closeout fail-safe
-
-If Manage was declined, unavailable, or unselected, every `manage.closeout` preset is dormant: ordinary Core may report readiness and the explicit next lifecycle or Git action, but configuration executes neither archive nor commit. Readiness, an earlier managed run, or project policy never substitutes for current selection and qualification. After selection, stop using this reference for execution detail; `rsp-manage` solely owns same-goal revalidation, interruption and resume, review convergence, acceptance, lifecycle closeout, commit eligibility and orchestration, and all corresponding authority stops. Exact staging, message construction, local commit execution, and post-commit observation remain owned by `rsp-commit`.

package/skills/rsp-design/SKILL.md

@@ -1,53 +0,0 @@
----
-name: rsp-design
-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.
-license: MIT
-metadata:
-  author: oevery
-  version: "2026.07.27.1"
----
-
-# RSP Design
-
-Resolve one design question. Do not implement it.
-
-## Establish the question and authority
-
-State one explicit bounded design question. Read project authority and the smallest relevant Specs, decisions, code, tests, callers, and runtime evidence.
-
-Choose one ownership mode:
-
-- **Pre-Change Design:** use when no Change is selected and the request already contains one bounded design question. When this Skill is installed, Core selects it instead of manually emulating the discipline; the manual fallback is only for an unavailable Skill. 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.
-- **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.
-
-Stop on an ambiguous question, evidence boundary, owner intent, authorized-write owner, or required mutation authority. Never invent product intent.
-
-## Load one design mode
-
-Load only the reference matching the question:
-
-- Read [domain modeling](references/domain-modeling.md) for vocabulary, identity, lifecycle, invariants, relationships, or ownership.
-- Read [module and seam design](references/module-seams.md) for interface obligations, caller complexity, adapters, test surfaces, or seam placement.
-- Read [reversible exploration](references/reversible-exploration.md) only when a material conclusion depends on unobserved behavior and a cheap safe probe can provide it.
-
-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.
-
-## Preserve artifact ownership
-
-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.
-
-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.
-
-## Return the bounded result
-
-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:
-
-- ownership mode, selected WorkRef when tracked, and exact question;
-- inspected evidence and material gaps;
-- recommendation and evidence-driven reasoning;
-- credible alternatives and tradeoffs;
-- unresolved owner decisions;
-- artifact routing and any authorized Change update;
-- smallest next action.
-
-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.

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

@@ -1,11 +0,0 @@
-# Domain modeling
-
-Use this procedure only for a question about domain language, identity, lifecycle, invariants, relationships, or ownership.
-
-1. Collect the project's existing terms from its authoritative context, Specs, code, tests, and user language. Record contradictions rather than silently choosing one source.
-2. Trace concrete scenarios across creation, transition, failure, cancellation, deletion, and relevant scope boundaries. Prefer observable lifecycle evidence over type names alone.
-3. Identify each concept's identity, owner, allowed transitions, invariants, and relationships. Distinguish a domain concept from a transport shape, persistence record, UI label, or implementation helper.
-4. Propose the smallest coherent vocabulary and ownership model that explains the evidence. Test it against at least one edge case and one existing production consumer.
-5. Separate conclusions forced by evidence from product choices that require owner confirmation.
-
-Return canonical terms, definitions, ownership and lifecycle implications, conflicts with current usage, alternatives, and unresolved owner decisions. Planned vocabulary may update only the authorized selected Change `Design`; flag possible current-fact or rationale destinations without writing them.

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

@@ -1,11 +0,0 @@
-# Module and seam design
-
-Use this procedure only for a question about an interface, caller complexity, adapter, test surface, or seam placement.
-
-1. Trace the direct production consumer and the smallest complete call/data path before proposing a seam. Confirm the live path reaches the candidate owner.
-2. List what callers must know: inputs, outputs, invariants, ordering, failures, configuration, cancellation, and relevant performance constraints.
-3. Locate where behavior or policy actually varies. Do not add an interface for hypothetical variation or wrap an existing pass-through for symmetry.
-4. Compare credible placements by caller leverage, implementation locality, dependency direction, state ownership, and whether callers and tests can use the same public surface.
-5. Recommend the smallest interface that hides meaningful complexity while preserving domain ownership. State migration or compatibility consequences without implementing them.
-
-Return the proposed owner, seam, interface obligations, affected consumers, verification surface, alternatives, and unresolved owner decisions. Treat code sketches as explanatory output only; do not write production code.

package/skills/rsp-diagnose/SKILL.md

@@ -1,48 +0,0 @@
----
-name: rsp-diagnose
-description: Diagnose one selected RSP Change when a reproducible or materially evidenced failure has an unexplained cause or owning layer. Use for conflicting, intermittent, or multi-layer symptoms before production correction.
-license: MIT
-metadata:
-  author: oevery
-  version: "2026.08.21.1"
----
-
-# RSP Diagnose
-
-Establish a confirmed cause before correction. Keep the selected Change as owner and return investigation evidence to it.
-
-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.
-
-## Establish bounds
-
-Resolve exactly one executable open Change from an explicit work reference or unambiguous focus. Read the user request, nearest project instructions, relevant context, RSP rules, the sibling Group Brief when present, the selected Change, and only the code, tests, logs, configuration, and worktree evidence needed to investigate.
-
-A diagnosis request grants read-only investigation and safe diagnostic command execution. Editing tests, instrumentation, fixtures, or the Change requires explicit mutation authority. Production correction is outside this Skill even when separate fix authority exists.
-
-Stop with one evidence request when the target, expected behavior, investigation scope, or safe reproduction conditions are unclear.
-
-## Diagnose
-
-1. **REPRODUCE.** Capture the smallest command or observation that exposes the symptom, its expected and actual result, and relevant conditions. When reproduction is unsafe or unavailable, label the supplied evidence and its limits. Continue only with a stable symptom or material evidence.
-2. **LOCATE.** Trace the live path to the first boundary where actual behavior diverges from expected behavior. Identify the affected layer and owner; verify that any suspected adapter, validator, cache, or wrapper is reached by the production consumer.
-3. **HYPOTHESIZE.** State the smallest set of live competing causes and the distinct observation each predicts. A single hypothesis is sufficient only when existing evidence already excludes credible alternatives.
-4. **DISCRIMINATE.** Run the smallest safe check that separates the leading hypotheses. Record the exact command or observation and decisive result. Prefer one discriminating check over broad speculative changes.
-5. **CONFIRM.** Confirm a cause only when observed evidence selects it over the remaining live alternatives and explains the reproduced symptom. Otherwise return `unresolved` with the missing evidence and one bounded next check.
-
-## Return evidence
-
-Return:
-
-- selected Change;
-- result: `confirmed` or `unresolved`;
-- reproduction or supplied-evidence limit;
-- cause and affected owner, or remaining hypotheses;
-- decisive evidence and impact boundary;
-- investigation mutations, if explicitly authorized;
-- exactly one next action.
-
-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.
-
-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.
-
-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.

package/skills/rsp-manage/SKILL.md

@@ -1,101 +0,0 @@
----
-name: rsp-manage
-description: Coordinate one eligible long-running, recovery, or multi-slice RSP goal across ready Changes or a shallow Group without expanding its authority.
-license: MIT
-metadata:
-  author: oevery
-  version: "2026.08.22.3"
----
-
-# RSP Manage
-
-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.
-
-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.
-
-## Validate the selected goal
-
-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.
-
-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.
-
-Return one bounded managed phase result for Core's outer `ControlOutcome`:
-
-- `solo`: no worker participates, including a bounded local Discipline action;
-- `delegated`: one worker participates;
-- `coordinated`: multiple workers participate or acceptance requires a separate verifier.
-
-Mode describes observed participation, not a host lifecycle model.
-
-## Choose the smallest execution strategy
-
-Use only as much coordination as the current evidence requires:
-
-- `control-action`: one Manager-owned control-plane action;
-- `longitudinal`: compatible successive work through one worker when the host supports continuation;
-- `sequential`: ordered work with shared seams, writers, or verification resources;
-- `parallel-wave`: independent slices with disjoint mutation and verification resources;
-- `read-only-fan-out`: independent evidence gathering;
-- `bounded-correction`: an evidenced same-scope correction;
-- `independent-verify`: acceptance requires a different worker from the accepted implementation worker.
-
-These names explain Manager strategy only. They are not runtime states, persisted objects, or proof that dispatch occurred.
-
-Derive `DispatchDisposition` after selection:
-
-| Value | Use when | If unavailable |
-| --- | --- | --- |
-| `none` | No useful or required worker seam exists. | Run the bounded local Discipline. |
-| `preferred` | Delegation improves focus or continuity without creating an acceptance obligation. | Continue locally within the same owner and authority. |
-| `required` | The request or declared acceptance requires delegated work or a separate verifier. | Stop `capability-unavailable`; acceptance remains `incomplete`. |
-
-`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.
-
-## Resolve the frontier
-
-Classify new unknowns in fail-closed order: `out-of-goal` → `owner-decision` → `fog` → `evidence-needed` → `executable`.
-
-- `out-of-goal`: stop `reroute`.
-- `owner-decision`: ask the `DecisionOwner` one highest-impact question; stop `ask-owner`.
-- `fog`: create no synthetic work or mutation; stop `return-to-shape`.
-- `evidence-needed`: collect one bounded factual answer without crossing an earlier boundary.
-- `executable`: choose one Discipline only after ownership, authority, and required evidence are settled.
-
-Use Core's canonical stop vocabulary. No stop permits another dispatch, product mutation, lifecycle closeout, or Git action before its resume rule succeeds.
-
-## Load worker delegation conditionally
-
-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.
-
-Derive `AcceptanceDisposition` independently:
-
-```text
-accepted required Discipline results + fresh declared verification → evidence-complete
-evidence-complete + clean fixed-scope review                   → review-clean
-```
-
-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.
-
-## Dispatch and convergence
-
-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.
-
-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.
-
-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.
-
-## Continue and load low-frequency branches
-
-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.
-
-Load a low-frequency procedure only after its branch trigger is established:
-
-- Read [interruption and recovery](references/interruption-recovery.md) only for a progress or status inquiry, explicit pause, environment or verification stop, or resume.
-- Read [managed review convergence](references/review-convergence.md) only after an evidenced same-scope correction is needed or a fixed-scope review returns Findings.
-- 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.
-
-If none of these triggers applies, do not read their references.
-
-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.
-
-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.

package/skills/rsp-manage/references/closeout.md

@@ -1,13 +0,0 @@
-# Lifecycle and delivery closeout
-
-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.
-
-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.
-
-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.
-
-When granted, close lifecycle before any commit. Change: after Manage-owned clean fixed-scope change review and the durable writeback decision run `rsp archive <change-work-ref>` and inspect the complete lifecycle diff. For shallow Group: review, decide durable writeback, and 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. Require proven review/clean-boundaries.
-
-Decide commit eligibility separately. Under `local` or explicit commit authority, downstream work may justify one recovery checkpoint: give `rsp-commit` the WorkOwner, paths, evidence, lifecycle state, and authority, then derive status from its receipt. Terminal small owners default to no commit. After lifecycle closeout, a qualified `local` terminal non-small Change or Group with known owner and paths, fresh decisive verification, clean exact boundary, and no nearer denial routes exactly once to `rsp-commit`; do not require the user to repeat `commit`. An ambiguous, mixed, stale, or denied boundary stops without staging. Apply the same owner envelope to explicitly authorized Group/release commits. If Commit is unavailable, return `StopDisposition: capability-unavailable` to Core for its bounded manual Commit fallback; Manage does not stage or commit. Archive grants no Git or publication authority.
-
-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.

package/skills/rsp-manage/references/delegation.md

@@ -1,47 +0,0 @@
-# Delegation and host evidence
-
-Load this reference only after Manage derives `DispatchDisposition: preferred | required` and before preparing a worker task or accepting a worker result.
-
-## Delegate one bounded task
-
-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:
-
-```text
-Work: <exact WorkRef>
-Objective: <one bounded objective>
-Authority: <exact owner sections or paths>
-Read: <allowed read boundary>
-Write: <allowed write boundary>
-Verify: <required verification boundary>
-Known facts: <only decisive current facts>
-Prohibited actions: <explicit denials>
-Stop conditions: <when to return without continuing>
-Replay caution: <only when repeating effects may be unsafe>
-```
-
-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.
-
-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.
-
-Each delegated Discipline owns its own result:
-
-- **Diagnose:** `rsp-diagnose`; `confirmed | unresolved` with cause evidence and scope impact.
-- **Inspect:** Manager-only read-only evidence packet.
-- **Fix:** `rsp-implement`; `changed | no-change` with changed paths, verification, omissions, and any scope issue.
-- **Verify:** `rsp-verify`; `pass | fail | unavailable` with named checks, evidence delta, omissions, and any scope issue.
-
-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.
-
-## Validate results and host facts
-
-Treat three evidence sources separately:
-
-- the worker-authored Discipline result states what the worker did and observed;
-- host observations, when available, establish dispatch, attribution, activity, cancellation, completion, and whether different workers participated;
-- Manager validates authority, actual changed paths, local diff, declared verification, omissions, and current acceptance.
-
-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.
-
-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.
-
-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.

package/skills/rsp-manage/references/interruption-recovery.md

@@ -1,19 +0,0 @@
-# Interruption and recovery
-
-Load this reference only for a progress or status inquiry, explicit pause, an environment or verification stop, or resume from continuation pointers.
-
-Reread the complete owner and authority only on a real invalidation, recovery, cross-session continuation, or closeout boundary.
-
-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.
-
-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.
-
-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.
-
-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.
-
-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.
-
-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.
-
-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.

package/skills/rsp-manage/references/review-convergence.md

@@ -1,9 +0,0 @@
-# Managed review convergence
-
-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.
-
-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.
-
-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.
-
-Allow at most three Resolve Findings passes per Change, separate from the worker retry limit. Stop when the same Finding remains after two completed corrections. Also stop for `needs-clarification`; a material product, interface, or scope change; new mutation or external authority; an additional real-host, provider, or network run outside existing verification authority; or failed or unavailable decisive verification. Return one owner input. Treat an eligible in-scope Finding as `correction-needed`, not an external blocker. Keep counts and correction chronology transient.

package/skills/rsp-release-docs/SKILL.md

@@ -1,77 +0,0 @@
----
-name: rsp-release-docs
-description: Draft, audit, finalize, or reconcile evidence-based changelogs, release notes, and migration notes for an explicit release operation.
-license: MIT
-metadata:
-  author: oevery
-  version: "2026.08.23.1"
----
-
-# RSP Release Docs
-
-Build one net-release evidence ledger and project it into repository-owned release surfaces. Git history locates evidence; it is not product truth.
-
-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.
-
-## Establish authority
-
-Resolve user scope, audience, language, format, references, and mutation authority first; then nearest project instructions, release-tool configuration, target-artifact conventions, and prior published releases. Higher-precedence evidence wins. Ask one focused question only when an unresolved owner choice materially changes the public result.
-
-Read [convention discovery](references/convention-discovery.md) when repository, personal, tool, or historical conventions must be located or reconciled. Do not invent configuration or persist preferences without authority.
-
-A release identity is confirmed only by explicit user instruction or authoritative repository release configuration. Never infer it from semantic-version ordering, prior prereleases, commits, planned prose, or package-manager convention. Until confirmed, keep work version-neutral and do not mutate manifests, target changelog headings, exact-version commands, versioned note paths, or tag comparisons.
-
-Before continuing, name the range, confirmed version or draft state, audience, surfaces, language, link style, and allowed mutations.
-
-## Select one branch
-
-- **Audit:** fixed release prose → inspect and return findings; no edits.
-- **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.
-- **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.
-- **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.
-
-Exactly one branch is active. Give every requested surface one disposition: draft, finalize, reconcile, audit only, not applicable, or blocked by a named decision.
-
-## Keep release coordination proportional
-
-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.
-
-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.
-
-## Build evidence before prose
-
-Inspect the smallest sufficient set: base and target refs; commits and net diff; relevant PRs, issues, Changes, fragments, and release PRs; public API, CLI, configuration, packaging, migration, security, and operator behavior; release surfaces and configuration; fresh verification and known acceptance gaps.
-
-Use direct consumers and diffs for behavior, work artifacts and public docs for meaning, and commit metadata for navigation. Reconcile disagreements explicitly. Historical verification must name its observed revision or date.
-
-Read [evidence and surfaces](references/evidence-and-surfaces.md) before drafting the ledger, classifying statement lifetime, or deciding exclusions. Read [output contracts](references/output-contracts.md) before introducing a format, preparing a major/breaking release, or producing multiple surfaces.
-
-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.
-
-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.
-
-## Project distinct surfaces
-
-- **Changelog:** concise cumulative notable outcomes using the existing categories, or Keep a Changelog categories as fallback. Put breaking changes and required action first.
-- **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.
-- **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.
-
-Every claim must map to the ledger. Keep terminology aligned while respecting each surface's audience and lifetime.
-
-## Load publication lifecycle
-
-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.
-
-## Protect authority and credentials
-
-This Skill never executes or grants authority for commit, tag, push, hosted release creation, registry publication, deployment, deletion, approval, or rewriting immutable history. Publication is a separate external operation.
-
-Treat one-time passwords, browser-auth URLs, device codes, tokens, and token-bearing query strings as credentials. Never retain their values in release prose, Changes, ledgers, logs, summaries, or responses. If a command would expose them to retained output, stop and let the authorized human authenticate in a trusted terminal; resume only with credential-free status.
-
-## Return an evidence-complete result
-
-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.
-
-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.
-
-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.

package/skills/rsp-release-docs/references/convention-discovery.md

@@ -1,65 +0,0 @@
-# Convention discovery
-
-Use this reference when a repository may have personal, project, tool, or historical release conventions. Discover; do not introduce a new configuration file merely to satisfy this Skill.
-
-## Authority sources
-
-Inspect only relevant, non-secret sources:
-
-1. Current user instructions, including requested audience, language, tone, links, output paths, and whether edits are allowed.
-2. Applicable instructions, with the nearest project instruction winning over broader host or personal defaults.
-3. Project release documents such as `CONTRIBUTING.md`, maintainer guides, or a documented release checklist.
-4. Existing target artifacts such as `CHANGELOG.md`, `NEWS.md`, release-note templates, upgrade guides, or an in-app What's New source.
-5. Release configuration and package scripts.
-6. Recent published releases and tags.
-
-Do not scan unrelated home-directory configuration. Do not print tokens, registry credentials, private URLs, authorization headers, or hidden release secrets. When a named config may contain secrets, inspect only the keys needed to identify release behavior. Keep a newly stated preference session-local unless the user explicitly authorizes an existing project or personal instruction owner.
-
-## Common configuration signals
-
-Look for these only when present or relevant:
-
-- `.github/release.yml`, Release Drafter, or GitHub Release templates;
-- release-please manifest/configuration;
-- `.changeset/config.json` and changeset fragments;
-- Towncrier, Changie, or similar news fragments;
-- `cliff.toml`, conventional-changelog, semantic-release, or commit-and-tag-version configuration;
-- monorepo package boundaries and per-package changelogs;
-- package scripts, CI release workflows, and version files;
-- tracker labels such as breaking, feature, fix, skip-changelog, or security.
-
-Treat generated release notes and automation output as evidence inventories. Human-facing claims still require semantic review.
-
-## Adaptation decisions
-
-Resolve these dimensions independently:
-
-| Dimension | Evidence to prefer |
-| --- | --- |
-| Audience | Explicit request, established release surface, prior releases |
-| Language | Explicit request, established target artifact, configured effective artifact language, nearest project instruction, prior published releases, conversation |
-| Voice | Existing artifact and product terminology |
-| Categories | Existing artifact/config; Keep a Changelog only as fallback |
-| Version and tags | Confirmed target, manifests, release config, prior tags |
-| References | Existing links and tracker policy; generic hierarchy only as fallback |
-| Output paths | Existing release owner or explicit path authority |
-| Detail | Audience needs, release risk, and existing cadence |
-
-Personal preferences refine the project format where compatible. Project-owned parsers, schemas, and release contracts win when a stylistic preference would break them. Report the conflict when the user must choose.
-
-For language specifically, follow Core's response-versus-artifact boundary. An explicit surface-specific request wins. Otherwise preserve an existing target artifact's established language. For a new release artifact, use the configured effective artifact language, then the nearest project or release instruction, prior published releases, and finally the conversation language. Configuration changes never translate an existing release surface by themselves.
-
-## Repository shapes
-
-- **Library or SDK:** emphasize public API, compatibility, deprecation, migration, runtime support, and precise references.
-- **Application:** emphasize visible workflows, changed defaults, operator action, rollout, and known limitations.
-- **CLI:** emphasize command/flag/config semantics, output contracts, migration, and shell compatibility.
-- **Monorepo:** determine the released unit before collecting evidence; avoid mixing unrelated packages.
-- **GitHub-Releases-only project:** draft release notes without creating `CHANGELOG.md` unless requested.
-- **Fragment-based project:** use accepted fragments as semantic evidence, then verify the net diff and release boundary.
-
-## Conflict examples
-
-- If the user requests Chinese release notes but `CHANGELOG.md` is consistently English, keep the changelog English and draft the release notes in Chinese unless the user explicitly asks to translate both.
-- If the user requests commit IDs but prior releases use PR links, preserve PR links and add commit links only for exact provenance unless the user explicitly overrides the project style.
-- If a tool requires two synchronized formats, update both from one ledger while preserving each parser's syntax.

package/skills/rsp-release-docs/references/evidence-and-surfaces.md

@@ -1,21 +0,0 @@
-# Evidence and surfaces
-
-Load this reference before drafting the release ledger, assigning statement lifetime, or deciding exclusions.
-
-## Evidence ledger
-
-Keep a transient table or equivalent notes with: evidence identifiers/links, net user or operator outcome, audience, breaking/deprecation/security/compatibility/migration impact, changelog and release-note dispositions, reference choice, and exclusion or uncertainty owner.
-
-The ledger is an analysis device, not a new project state store. Persist it only in an existing release-fragment system or explicitly authorized destination. It describes the released net state rather than commit chronology.
-
-## Surface lifetime
-
-- **Shipped surfaces:** package metadata and release communication captured by the tag or package, including README, changelog, repository notes, manifests, and migration guides. Internal workflow records keep their own artifact lifetime. Shipped statements must be publication-invariant: exclude “not yet published,” “available after publication,” pending authentication, unverified registry state, and comparisons ending at `HEAD`.
-- **Mutable public surfaces:** hosted release descriptions, safely mutable registry metadata, and other external records. Keep stable narrative aligned with shipped surfaces; add live verification only after observing it.
-- **Transient release state:** credentials, authentication, command progress, pending publication, and unverified availability. Keep it in an authorized tracker, temporary ledger, or response handoff—never shipped prose.
-
-When immutable published content is wrong, preserve it, explain the discrepancy on an authorized mutable surface, and name a corrective version or owner.
-
-## References
-
-Follow repository policy first. Otherwise add a version-level tag or comparison link, prefer PRs for implementation context, issues or tracked work for rationale and migration, and commits when no better semantic anchor exists or exact provenance is required. Links are optional per bullet and must be stable and public; do not expose private tracker identifiers.