v4.0.0

4.0.0 (2026-10-24)

⚠ BREAKING CHANGES

• skills: Individual core Skill installation is no longer supported.
  Install the complete suite and inspect customized obsolete audit directories
  before forced migration.
• research: Maintainer research no longer supports sealed-study,
  coverage or custom bundle commands. Write ordinary timestamped reports and
  use explicit capture recovery and cleanup commands.
• research: Maintainer studies use brief and --brief in place of question
  and --question. Historical sealed bytes are preserved without implicit migration.
• workflow: Replace manage configuration with workflow.delegation and
  workflow.closeout, defaulting to off/ask. Legacy manage mappings require explicit
  migration; rsp update does not convert them or grant Git authority.
• evaluation: retire the former Skill runner commands and case/suite
  formats. Use tests/skills/evaluate.py and native Harbor task/job settings.
• rsp: rsp commit, its snapshot flags and JSON receipt are removed.
  Use rsp-commit with native Git and a prepared message file.
• runtime: RSP requires project Skills. Use an exact target CLI,
  explicit version adoption and selected legacy Rules removal after preserving
  custom content, then refresh the complete Skill suite before resuming work.
• skills: rsp-manage moves into rsp; rsp-design moves into rsp-shape; rsp-diagnose, rsp-tdd and rsp-resolve-findings move into rsp-implement. Inspect existing Skill trees before explicitly forcing migration.
• setup: skills install, the Skill installer UI, doctor --fix, and
  the update adoption/removal switches are retired. Use init for setup and
  update [--dry-run] for managed upgrades; save managed customizations first.

Features

• ci: integrate pinned xova project workflows (86f790c)
• ci: unify code and docs checks with shared caches (44b790a)
• cli: add config inspection and streamline status output (ca774af)
• docs: add reader-focused documentation workflow (0cd01fd)
• docs: unify document and skill authoring (0ab61cb)
• eval: select exact calibration samples (d966e3c)
• runtime: distinguish source checkouts from pinned projects (622fcb1)
• runtime: pin project versions and retire Rules (74bd852)
• workflow: separate delegation from delivery closeout (178eaaa)

Bug Fixes

• archive: check history summary before archiving (c630a4b)
• eval: align four task fixtures with their output contracts (a85ee98)
• eval: distinguish inherited regrade usage from current duration (0bec0bc)
• eval: distinguish saved provenance in comparison reports (cb92ce4)
• eval: distinguish unavailable grading in reports (fe5ea05)
• eval: expose cached token usage with source attribution (fb33f16)
• eval: handle missing calibration expectations and labels (4b36217)
• eval: preserve comparisons with unreadable baseline trials (a344d48)
• eval: preserve reports on verifier discovery errors (f42d2dd)
• eval: preserve reports when execution status is unreadable (2c2ad02)
• eval: preserve reports when grading details are unreadable (1042872)
• eval: preserve reports when job plans are unavailable (aaf64cb)
• eval: preserve reports when usage evidence is unreadable (ce6bc98)
• eval: preserve reports with unreadable trial results (62e1592)
• eval: reject stale usage from corrupt session JSON (189124f)
• eval: report baseline plan completeness (8550f7e)
• eval: require complete calibration expectations (43f31ce)
• eval: retain calibration identity for regrades missing manifests (8dda2aa)
• eval: retain root-cause locations in exception records (6976c81)
• eval: retain unscored calibration when manifests are unavailable (e7bbb19)
• eval: specify next-action and evidence-reference formats (598474a)
• rsp: clarify focus writeback and archive evidence boundaries (1cde234)
• rsp: enforce writeback order and remove evaluation quotas (a2014ea)
• skills: align work selection and change record guidance (1f29dcc)
• skills: clarify routing and work-record boundaries (47a5231)
• skills: clarify test expectations and useful comments (37b7ec0)
• skills: gate commit writes on successful prerequisites (ca5b6a6)
• skills: unify core suite identity and review boundaries (b53390c)
• testing: enforce evaluation evidence and acceptance (1d4cd37)
• tests: make skill review evidence traceable (1f50a60)
• tests: preserve task evidence without blanket redaction (79cb6d2)
• test: stabilize fixture evidence across CI color settings (6ae5b10)

Code Refactoring

• evaluation: migrate skill testing to Harbor and Reward Kit (adbc2ed)
• research: simplify capture recovery and dated reports (d22805e)
• research: support upstream discovery and traceable coverage (8b96947)
• rsp: streamline delivery and verification evidence (899e90a)
• setup: unify ownership-based project updates (2a2e7ea)
• skills: consolidate workflow and stabilize evaluations (fff714b)

RSP 3.3.0

RSP 3.3.0

RSP 3.3.0 strengthens completion evidence, recovery, and managed execution while reducing repeated agent context. It adds direct Specs navigation, bounded Focus Capsules, a dedicated verification Skill, stricter archive and commit boundaries, and a release gate that combines deterministic package acceptance with provider-backed behavior evidence.

Completion and verification

• Classify acceptance-critical checks under Verify ### Required and additional environment, compatibility, scale, or confidence coverage under ### Optional.
• Make rsp ready, rsp show, and JSON output expose the required completion gate and optional coverage warnings separately.
• Make rsp archive fail without moving a Change when Tasks, Required verification, or blockers remain incomplete.
• Add rsp-verify as a bounded read-only verification Discipline while keeping worker identity, independence, acceptance, and closeout with Manage.
• Preserve legacy unclassified Verify items as Required so existing incomplete acceptance is never silently weakened.

Direct Specs navigation

• Use rsp specs to read the current Specs and Decision Record tree directly without a daemon, database, or generated navigation file.
• Add exact-path detail and bounded case-insensitive literal search with explicit limits, source paths, and diagnostics.
• Stop creating generated INDEX.md and 00-index.md files for fresh projects and new Specs.
• Let rsp update remove only recognized generated indexes whose metadata matches their owning directory; owner-controlled, unreadable, or replaced reserved content stops without overwrite or deletion.

Recovery and managed execution

• Add strict Focus Capsule v1 input through rsp focus --capsule-file <path|-> for sparse Current, Evidence, Next, and optional Resume check recovery pointers.
• Keep existing bounded unversioned focus content readable with a warning, without treating it as structured recovery or fresh authority.
• Refine Manage into explicit solo, delegated, and coordinated modes with host-attributed worker results, bounded correction, and independent-verification obligations.
• Keep execution-location selection and cross-branch integration with the host, user, and Git instead of implying a Skill-owned workspace runtime.
• Reduce repeated context through progressive disclosure while retaining complete fresh assignments when worker continuity is unavailable.

CLI, dashboard, and local delivery

• Separate CLI command capability, execution, and presentation boundaries while retaining the documented command surface and machine-readable JSON contracts.
• Improve the dashboard with unified Work, Specs, and History navigation, bounded search, semantic and exact document views, and safe Markdown presentation.
• Make rsp commit --message-file validate an existing staged boundary, reject literal \n transport mistakes, invoke Git through a direct process boundary, and verify the resulting message and committed paths.
• Keep commit, cross-branch integration, push, tag, publication, deployment, approval, and human acceptance as separate authorities.

Release integrity and Skill quality

• Add a serial deterministic release campaign covering Skill security, metadata, documentation, build, typecheck, lint, the complete test suite, and packed installed-package workflows.
• Add provider-backed release behavior checks for final-output residue, protected commit and release surfaces, required negative facts, test restraint, and direct routing.
• Add six paired routing scenarios for direct, solo, delegated, independent-verification, sequential, and parallel execution topologies with reusable exact-identity evidence.
• Add deterministic Skill security preflight for package scripts, permissions, secrets, dependencies, injection surfaces, and MCP metadata, with exact-hash suppressions.
• Replace brittle wording and size gates with semantic checks where exact prose is not the public contract.

The release candidate passed the deterministic release campaign, including 91/91 test files and 888/888 tests, plus 10/10 provider behavior runs and 18/18 candidate routing runs across the six declared scenarios. Provider token and latency measurements remain diagnostic: the five common-model routing scenarios used fewer total tokens in aggregate, while the separately rerun parallel scenario was approximately neutral in aggregate. These observations do not claim provider-general or model-general performance.

Upgrade

RSP 3.3 requires Node.js 22 or later. Existing 3.2 projects need no dedicated migration. Refresh the managed fallback and package-owned Skills, then inspect project health:

npx -y @oevery/rsp@latest update
npx -y @oevery/rsp@latest skills install --dry-run --force
npx -y @oevery/rsp@latest skills install --force
npx -y @oevery/rsp@latest doctor

If rsp update reports owner-controlled reserved Specs index content, review that file instead of replacing or deleting it automatically. If an existing Change no longer passes rsp ready, complete its Tasks and Required verification or explicitly move additional non-blocking coverage under Verify ### Optional before archiving.

Existing Change, Group, archive, Spec, Decision Record, configuration, and WorkRef identities remain compatible. rsp create --lite compatibility forms remain accepted for one release cycle with deprecation guidance.

Compatibility and known limitations

• Automatic Manage activation selects a controller only when an observable coordination obligation exists; it grants no planning, mutation, lifecycle, Git, publication, deployment, approval, or human-acceptance authority.
• Focus Capsules are recovery pointers, not authority or durable evidence stores. Legacy marker prose remains readable but is not projected as structured recovery.
• The provider-backed routing evidence covers six fixed repository scenarios. Five scenarios used one configured model and the separately rerun parallel scenario used another; this is complete scenario coverage, not one homogeneous model matrix.
• Token, latency, tool-call, baseline, and pair-delta measurements are diagnostic and have no release threshold.
• PTY interaction, Windows terminals, broad independent-project behavior, provider-general performance, and publication reconciliation remain outside the observed local candidate evidence.
• Tag creation, push, hosted release creation, registry publication, deployment, and approval remain separately authorized operations.

Full comparison: v3.2.0...v3.3.0

RSP 3.2.0

RSP 3.2.0

RSP 3.2.0 makes agent control flow easier to reason about and everyday work easier to scan. It unifies route and ownership decisions across Core and Manage, adds human-readable work summaries without weakening stable identities, and reduces routine Skill context while preserving the existing authority boundaries.

Explicit control and managed execution

• Use one transient control model across Core, Shape, Discipline Skills, and Manage, with explicit route, owner, stop, resume, acceptance, and closeout outcomes.
• Keep Core responsible for resolving the WorkRef owner and selecting direct, specialist, managed, shaping, or stopped routes.
• Let a selected Manage run own same-goal execution, evidence-frontier decisions, review convergence, acceptance, and eligible closeout until a real route boundary changes.
• Select automatic Manage for non-small and multi-surface completion work while keeping settled one-step work direct.
• Preserve specialist routing for fixed-scope review, release operations, and isolated design questions.
• Keep controller state transient: Changes, Group Briefs, Specs, Decision Records, Git history, and published artifacts remain the durable owners.

Clearer work identity and presentation

• Add human-readable Change and Group summaries to rsp status --json, plain status, the terminal dashboard, and archive history.
• Keep canonical WorkRefs unchanged as stable machine identities, even when their summaries or surrounding narration use another language.
• Default newly inferred WorkRefs to ASCII lowercase kebab-case when neither the user nor project authority specifies a naming convention.
• Preserve explicit Unicode WorkRefs, project-owned naming policies, and every existing open or archived identity.
• Localize human-facing progress, route, stop, and handoff narration independently from artifact language, commit language, canonical commands, paths, and enum values.

Leaner Skill loading

• Clarify the distinction between default suite Skills and optional project Skills without changing the packaged inventory.
• Reduce the generated fallback protocol to the safety kernel needed when the full rsp Skill cannot be loaded.
• Move inactive Manage interruption, review-convergence, and closeout procedures behind conditional loading.
• Let code-only and document-only reviews load only their applicable detailed pipeline while mixed reviews retain both.
• Replace high-amplification wording assertions with semantic contract helpers where exact prose is not itself the public contract.

Upgrade

RSP 3.2 requires Node.js 22 or later. Existing 3.1 projects need no dedicated migration. Use the stable package, then refresh the managed fallback and package-owned Skills separately:

npx -y @oevery/rsp@latest update
npx -y @oevery/rsp@latest skills install --dry-run
npx -y @oevery/rsp@latest skills install
npx -y @oevery/rsp@latest doctor

Existing Change, Group, archive, Spec, Decision Record, configuration, and WorkRef identities remain compatible. The new summary projections are additive presentation fields derived from existing authored content.

Compatibility and known limitations

• Automatic Manage activation selects a controller only; it does not grant planning, product mutation, lifecycle, Git, publication, deployment, approval, or human-acceptance authority.
• ASCII lowercase kebab-case is only the fallback for newly inferred WorkRefs. RSP does not rename existing identities or override an explicit user or project convention.
• Human-readable summaries are derived from authored frontmatter, Proposal outcomes, or Group goals. Missing or placeholder summaries remain absent rather than replacing canonical identities.
• The managed control model is covered by deterministic contracts and bounded repository evaluations. Provider behavior, broad productivity comparisons, and real-world acceptance outside the observed scenarios remain unclaimed.
• Commit, tag, push, hosted release creation, registry publication, deployment, and approval remain separately authorized operations.

Full comparison: v3.1.1...v3.2.0

RSP 3.1.1

RSP 3.1.1

RSP 3.1.1 hardens structured commit-message delivery so multiline bodies remain correct across tool, shell, and Git boundaries. It includes the complete stable 3.1 workflow described in the 3.1.0 release notes.

Reliable multiline commit messages

• Require actual line breaks or a safely prepared message file for structured multiline commit bodies instead of relying on shell interpretation of \n.
• Inspect the raw committed message after Git succeeds and treat unintended literal \n sequences as a post-commit mismatch.
• Stop and report the mismatch without inferring amend, second-commit, or other history-repair authority.
• Retain a focused Skill contract test for the transport and post-commit observation requirements.

Upgrade

RSP 3.1 requires Node.js 22 or later. Use the stable package, then refresh managed project files and package-owned Skills separately:

npx -y @oevery/rsp@latest update
npx -y @oevery/rsp@latest skills install --dry-run
npx -y @oevery/rsp@latest skills install
npx -y @oevery/rsp@latest doctor

RSP 3.1.0 remains available as a GitHub release but was not published to npm. Version 3.1.1 is the first stable 3.1 package published to the registry. Registry users upgrading from 2.x must follow the 3.0 migration guide, then apply the 3.1 migration guide.

Compatibility and known limitations

• This patch changes the packaged rsp-commit operational contract; it does not add a CLI commit command or make arbitrary shells reinterpret escape sequences.
• Existing Change, archive, configuration, and CLI behavior remains compatible with 3.1.0.
• Push, tag creation, hosted release publication, registry publication, deployment, approval, amend, and other history repair remain separately authorized operations.

Full comparison: v3.1.0...v3.1.1

RSP 3.1.0

RSP 3.1.0

RSP 3.1 turns the repository-native artifact foundation introduced in 3.0 into a more complete engineering workflow for inspectable planning, managed continuation, recovery, review, and release work. It keeps authority explicit while making complex work easier to navigate and resume.

Highlights

Inspect current work and retained history

• Open a read-only terminal dashboard for Changes, Groups, and bounded archive history.
• Query retained work with rsp history, inspect dependency plans and stable execution waves through rsp status, and use compact single-line JSON across automation-facing inspection commands.
• Use rsp ready for the canonical read-only archive-readiness projection and hierarchical 00-index.md files to navigate large Spec trees without making generated indexes authoritative.

Coordinate larger work without hiding authority

• Configure automatic or explicit Manage routing and choose manual, lifecycle, or eligible local-commit closeout independently.
• Coordinate long-running Changes, shallow Group waves, bounded review-correction convergence, and later-turn scope expansion while keeping shared mutation and verification resources sequential when required.
• Distinguish status updates, explicit pause, owner release, blockers, and drift-safe resume without persisting a second controller ledger.
• Prepare exact-scope local commits through the packaged rsp-commit capability while leaving push, publication, deployment, approval, and human acceptance separately authorized.

Recover and trace work safely

• Restore one archived Change or Group Brief without rewriting immutable history. Group recovery remains an explicit Group-then-child sequence.
• Attach validated external issue relationships to Changes without adding provider credentials or remote issue mutation to the CLI.
• Keep legacy archives readable while new writes fail closed on invalid metadata, ambiguous identities, unsafe paths, or unsupported structure.

Use a stronger project and Skill model

• Install the default package-owned Skill suite from the exact CLI package, preview conflicts, perform force-gated identity migrations transactionally, and install the optional structural audit by name.
• Use report-only pre-change design, diagnosis, TDD, implementation, review, finding resolution, release documentation, managed execution, and structural audit as independently invocable capabilities.
• Configure durable artifact and commit prose language without constraining response language, and use safe Unicode WorkRefs while retaining all existing ASCII identities.
• Preserve canonical Markdown through one lossless semantic document model and keep inactive procedures behind conditional owners to reduce ordinary runtime context.

Upgrade

RSP 3.1 requires Node.js 22 or later. Use the stable package, then refresh managed project files and package-owned Skills separately:

npx -y @oevery/rsp@latest update
npx -y @oevery/rsp@latest skills install --dry-run
npx -y @oevery/rsp@latest skills install
npx -y @oevery/rsp@latest doctor

RSP 3.0.0 was released on GitHub but was not published to npm. Registry users upgrading from 2.x must first follow the 3.0 migration guide, then apply the 3.1 migration guide. Existing 3.1 beta projects should run the same update, Skill refresh, and doctor sequence.

Compatibility and known limitations

• Existing Changes and archives remain compatible under the documented migration rules. The semantic document model does not rename canonical headings or rewrite existing artifacts.
• Recovery preserves immutable archives and requires explicit owner selection; it does not infer which historical acceptance is incomplete.
• Issue relationships remain local metadata. The CLI does not fetch issue bodies, store provider credentials, or mutate remote issue state.
• The release is covered by the complete self-host candidate gate, package inventory and clean-install checks, retained provider evaluations, and independent boats-cloud use across managed lifecycle, recovery, Windows/Electron acceptance, and full client verification.
• Live host scheduling across a real multi-turn pause/resume interaction, stochastic provider behavior, and broad comparative productivity claims remain unverified.
• Push, tag creation, hosted release publication, registry publication, deployment, approval, and human acceptance remain separate external actions.

Full comparison: v3.0.0...v3.1.0

RSP 3.1.0-beta.5

RSP 3.1.0-beta.5

RSP 3.1.0-beta.5 makes issue-originated work traceable without provider lock-in, completes the missing recovery path for archived Change Groups, and gives managed interruption a safer, explicit continuation contract.

Issue traceability without remote coupling

• Attach one external issue when creating a Change with --issue, defaulting to a non-closing relates relationship or accepting explicit --issue-relation closes intent.
• Validate optional issue frontmatter before mutation, rejecting credential-bearing URLs, fragments, duplicates, unsafe schemes, unsupported shapes, and unknown relationships.
• Project normalized relationships through plain and JSON status, show, and history surfaces while keeping existing Changes and legacy archives readable.
• Let Shape retrieve real issue content through available host capabilities or degrade honestly to authentication, pasted source data, or a link-only draft. The CLI itself performs no provider request and stores no retrieved issue body.
• Let terminal commit preparation use closing syntax only for an owned completed Change with explicit closes intent and safely resolved provider identity; checkpoints and ambiguous ownership remain non-closing.

Explicit recovery for archived Groups

• Add rsp group reopen <group> --reason <text> [--from <archive-path>] for one exact archived Group Brief.
• Preserve the selected archive unchanged, restore the same logical Group identity, and bind new incomplete completion evidence to that retained Brief.
• Validate archive identity, ambiguity, collisions, canonical structure, empty work/focus subtrees, evidence replay, and target safety before mutation, with rollback on failure.
• Keep recovery deliberately two-step: Group reopen restores only the Brief; rsp reopen <group>/<child> separately restores and focuses the affected child. Other children and dependents remain untouched.

Recoverable managed interruption

• Treat a progress question as a status update that continues an otherwise authorized run instead of a terminal stop.
• Distinguish explicit pause, explicit owner release, environmental or verification blockers, and resume without adding persisted controller state.
• Preserve the focused WorkRef by default across pause and blockers, and return the ordered continuation fields needed to recover incomplete work.
• Re-read repository authority and selected artifacts, inspect drift, requalify Manage, and refresh stale evidence before resumed mutation.

Smaller runtime context and stronger release checks

• Move inactive managed, release, and reopen procedures behind their single conditional owners while retaining eager routing, authority, safety, fallback, and return contracts.
• Reduce representative loaded-path and provider input usage without introducing a glossary, private notation, or cross-Skill runtime dependency; fixed adjudicated behavior cases remained equivalent.
• Restore typecheck as a passing release gate and keep bounded test concurrency so full-suite and clean-install verification remain repeatable.

Upgrade and opt-in usage

Pin the exact prerelease identity, then refresh both RSP-managed files and package-owned Skills:

npx -y @oevery/rsp@3.1.0-beta.5 update
npx -y @oevery/rsp@3.1.0-beta.5 skills install --dry-run
npx -y @oevery/rsp@3.1.0-beta.5 skills install
npx -y @oevery/rsp@3.1.0-beta.5 doctor

Users upgrading directly from a registry-installed 2.x release must first follow the RSP 3.0 migration guide. Issue relationships, Group recovery, and managed interruption details are in the 3.1 migration guide.

Compatibility and known limitations

• This prerelease remains opt-in; publishing it under the npm beta dist-tag does not promote npm latest.
• Existing Changes and archives without issue metadata remain compatible. No provider credentials, fetched issue content, or remote issue lifecycle state are persisted.
• Group recovery preserves immutable archives and requires an explicit Group-then-child sequence; it does not infer which child acceptance is incomplete.
• The exact candidate is covered by the complete self-host release gate, clean-install package check, deterministic recovery contracts, and retained fixed-case provider evaluation. Live host scheduling across a real multi-turn status or pause interaction, stochastic provider behavior, and broader productivity claims remain unverified.
• Push, tag, GitHub Release creation, npm publication, deployment, approval, and human acceptance remain separate external actions.

Full comparison: v3.1.0-beta.4...v3.1.0-beta.5

RSP 3.1.0-beta.4

RSP 3.1.0-beta.4

RSP 3.1.0-beta.4 makes multilingual collaboration durable without constraining conversation language, strengthens WorkRef identity for Unicode projects, and makes automatic Manage routing more decisive while preserving conservative execution boundaries.

Durable language without conversation lock-in

• Configure one shared default for artifact and commit prose with optional per-surface overrides. Response language remains owned by each user and session rather than repository configuration.
• Reject unsupported language.response configuration instead of silently forcing one collaboration language across a project.
• Generate canonical RSP scaffolds with neutral <…> placeholders and verbatim user input so the CLI does not invent conflicting English prose.
• Keep existing artifact language stable unless translation is explicitly authorized; configuration grants no Git action or translation authority.

Safe Unicode work identity

• Use lowercase or caseless Unicode letters, marks, and decimal numbers in WorkRef segments, including direct grouped identities such as 听说训练/模拟朗读.
• Normalize command input to NFC, bound both code-point and UTF-8 byte lengths, and reject unsafe punctuation, traversal, unsupported depth, non-canonical stored paths, and normalization collisions.
• Preserve existing ASCII lowercase kebab-case identities without migration or byte changes.

Lossless semantic document structure

• Route Change and Group Brief readers through stable semantic section identities instead of scattered heading strings.
• Preserve canonical Markdown as the storage format; localized or near-match headings are not accepted as protocol aliases.
• Keep source text and exact section spans so reopen and other surgical writers preserve unknown content, comments, whitespace, CRLF boundaries, and unrelated authored prose.
• Retain existing CLI JSON, diagnostic codes, lifecycle behavior, history, dependency, and scaffold contracts.

More decisive automatic Manage

• Under manage.activation: auto, classify each selected ready continuation as either fully one-step direct work or managed non-small work; no ambiguous middle case falls back to a conservative guess.
• Requalify later implementation when an earlier report, design, tiny, or small route expands into cross-module work, real-host verification, review convergence, lifecycle delivery, or a ready successor.
• Delegate at least one implementation worker for qualified work when workers are available, while the controller retains ownership, integration verification, review convergence, lifecycle, and Git decisions.
• Keep overlapping paths, generated state, provider sessions, real hosts, hardware, and dependent verification sequential. Parallel dispatch requires isolated mutation paths and verification resources.
• Report whether Manage was selected or declined, the decisive reason, and the applicable sequential or parallel boundary without persisting controller state.

Upgrade and opt-in usage

Pin the exact prerelease identity, then refresh both RSP-managed files and package-owned Skills:

npx -y @oevery/rsp@3.1.0-beta.4 update
npx -y @oevery/rsp@3.1.0-beta.4 skills install --dry-run
npx -y @oevery/rsp@3.1.0-beta.4 skills install
npx -y @oevery/rsp@3.1.0-beta.4 doctor

Users upgrading directly from a registry-installed 2.x release must first follow the RSP 3.0 migration guide. Language, Unicode WorkRef, and automatic Manage details are in the 3.1 migration guide.

Compatibility and known limitations

• This prerelease remains opt-in; publishing it under the npm beta dist-tag does not promote npm latest.
• No persisted Markdown format or CLI JSON schema migration is required for the semantic document model.
• The exact candidate is covered by the complete self-host release gate and clean-install package check. Automatic Manage has been dogfooded in the RSP checkout, but broader independent-project routing frequency, comparative token cost, and productivity remain unverified.
• Push, tag, GitHub Release creation, npm publication, deployment, approval, and human acceptance remain separate external actions.

Full comparison: v3.1.0-beta.3...v3.1.0-beta.4

RSP 3.1.0-beta.3

RSP 3.1.0-beta.3

RSP 3.1.0-beta.3 makes project history easier to navigate and incomplete work safer to recover, while tightening managed closeout and clarifying the published Skill surface. It is intended for opt-in evaluation of repository-native lifecycle work without granting remote delivery or publication authority.

Recoverable history and bounded navigation

• Use rsp history as the authoritative bounded archive query instead of a generated global Archive Index. TUI History and status archive trends consume the same validated inspection path.
• Navigate Specs through generated per-directory 00-index.md files that list only direct child Specs and populated child directories. Decision Records remain outside the Specs projection.
• Run rsp update to migrate recognized generated Archive and Specs indexes. Unrecognized files at reserved paths are preserved for explicit owner review rather than overwritten or removed.
• Restore an archived executable Change with rsp reopen <work-ref> --reason <text> when fresh evidence disproves its original acceptance. The archive remains immutable, multiple matches require exact --from selection, and genuinely new scope still belongs in a new corrective Change.

Deterministic managed closeout

• Qualify long-running continuation and interruption recovery independently from parallel work, and rederive routing when a direct task materially expands into a larger implementation boundary.
• Invoke local Commit once for an eligible, qualified, clean, verified non-small terminal boundary. Small terminal work, recovery checkpoints, lifecycle mutation, push, tag, and publication keep their separate authority requirements.
• Gate automatic lifecycle and local closeout on the current Manage qualification so configuration cannot grant closeout after Core declines or stops selecting Manage.

Skill identities and migration

• Use rsp-resolve-findings instead of rsp-address-review for correcting accepted findings and requesting re-review.
• Use the optional rsp-structural-audit instead of rsp-codebase-audit for report-only evidence-backed structural risk discovery.
• Existing obsolete package-owned directories require an explicit force-gated transactional migration. Preview and apply it with the exact prerelease package:

npx -y @oevery/rsp@3.1.0-beta.3 skills install --dry-run --force
npx -y @oevery/rsp@3.1.0-beta.3 skills install --force

The installer preserves unrelated Skills, rejects unsupported obsolete targets, and restores prior directories if replacement activation rolls back. Full upgrade details are in the 3.1 migration guide.

Readiness and structural audit

• Use rsp ready <work-ref> as the canonical read-only readiness projection. rsp archive <work-ref> --dry-run remains a deprecated compatibility route to the same human result.
• Structural Audit now distinguishes selection heuristics from Findings: history may select a candidate chain, and shallow indirection may be tested by deletion reasoning, but every Finding still requires a reachable trigger, concrete impact, and owner evidence.
• Published Skill tests now protect portable metadata and semantic behavior rather than imposing mechanical body word caps.

Opt-in usage

Pin the exact prerelease identity rather than relying on a moving dist-tag:

npx -y @oevery/rsp@3.1.0-beta.3 init
npx -y @oevery/rsp@3.1.0-beta.3 update
npx -y @oevery/rsp@3.1.0-beta.3 doctor

RSP 3.1 requires Node.js 22 or newer. Users upgrading directly from a registry-installed 2.x release must first follow the RSP 3.0 migration guide.

Compatibility and known limitations

• This prerelease remains opt-in; publishing it under the npm beta dist-tag does not promote npm latest.
• The exact candidate is covered by the self-host release gate and clean-install package check. Broader real-project lifecycle acceptance, provider-backed structural-audit evaluation, and comparative productivity remain unverified.
• Commit, push, tag, GitHub Release creation, npm publication, deployment, and external post-publication verification require separate authority and are not implied by the candidate itself.

Full comparison: v3.1.0-beta.2...v3.1.0-beta.3

RSP 3.1.0-beta.2

RSP 3.1.0-beta.2

RSP 3.1.0-beta.2 turns the initial managed-continuation prototype into a policy-controlled project workflow, broadens the composable Skill suite, and makes release and local Git boundaries more explicit. It is intended for opt-in evaluation of longer, multi-owner engineering work without granting remote delivery or publication authority.

Managed execution policy

• Configure manage.activation as explicit or auto and choose manage.closeout from manual, lifecycle, or local. Invalid configuration fails closed, and both plain and JSON status output expose the effective policy.
• New rsp init projects start with automatic Manage selection and lifecycle-only closeout. Existing projects without a manage block preserve the compatible explicit-selection and eligible-local-closeout behavior.
• Execute ready children of a shallow Change Group in dependency waves, recover long-running goals through compact continuations, and converge bounded in-scope review corrections while keeping unrelated work untouched.
• Treat automatic routing as controller selection only. Planning, product mutation, archive, commit, push, publication, deployment, approval, and human acceptance remain independently authorized.

Skill discovery and composition

• Use bare rsp skills in a dual TTY to inspect the packaged inventory and confirm one atomic project installation. Scripts and CI can use rsp skills list or rsp skills list --json for deterministic discovery.
• Install the eleven default lifecycle Skills together, or install the optional rsp-codebase-audit by exact name. Existing unrelated project Skills remain untouched, and divergent package-owned targets still require --force.
• Use report-only Pre-Change Design when the user already owns one bounded design question but no Change exists. Broader or ambiguous work still returns to Shape.
• Use the optional codebase-audit capability to report evidenced ownership, dependency, production-path, change-amplification, or verification risks before selecting implementation work.
• Use rsp-commit only after Core or qualified Manage has derived one exact local commit boundary with explicit authority and fresh verification. It never grants push, tag, publication, amend, rebase, or history-rewrite authority.

Release and project integrity

• Reject a release candidate when its manifest reuses a version tag finalized at another commit, and run the complete metadata, build, typecheck, lint, test, and clean-install package gates from prepublishOnly.
• Keep release identity selection explicit, implementation Changes independently reviewable, and versioned shipped surfaces in a separate release boundary.
• Organize the self-hosted project model into focused domain Specs and load detailed Core procedures only when their route is active, reducing routine instruction weight without weakening fallback behavior.

Opt-in usage

Pin the exact prerelease identity rather than relying on a moving dist-tag:

npx -y @oevery/rsp@3.1.0-beta.2 init
npx -y @oevery/rsp@3.1.0-beta.2 skills list
npx -y @oevery/rsp@3.1.0-beta.2 skills install --dry-run

RSP 3.1 requires Node.js 22 or newer. Users upgrading directly from a registry-installed 2.x release must first follow the RSP 3.0 migration guide.

Compatibility and known limitations

• This prerelease remains opt-in; publishing it under the npm beta dist-tag does not promote npm latest.
• The exact candidate is covered by the self-host release gate. From boats-cloud, the packaged CLI started successfully, reported that the repository is not RSP-initialized, listed the exact Skill inventory, and completed installation preflight without mutation. Real-project RSP lifecycle mutation, human acceptance, and comparative productivity remain unverified.
• Commit, push, tag, GitHub Release creation, npm publication, deployment, and external post-publication verification require separate authority and are not implied by this candidate.

Full comparison: v3.1.0-beta.1...v3.1.0-beta.2

RSP 3.1.0-beta.1

RSP 3.1.0-beta.1

RSP 3.1.0-beta.1 tightens the release workflow exposed by the first 3.1 beta. It separates behavioral qualification from mutable release identity, keeps version selection late, and makes implementation delivery and release finalization independently reviewable.

The product capabilities introduced in 3.1.0-beta.0 remain unchanged: the read-only terminal dashboard, bounded archive inspection, compact JSON output, exact-package Skill installation, and explicit managed continuation are still the 3.1 beta surface.

Release workflow integrity

• Reuse retained real-host evidence when only the package version changes, while continuing to reject Skill, Skill tree, inventory, behavior-file, input, score, or evidence-integrity drift.
• Classify package-bound documentation as publication-invariant and keep pending publication, authentication state, OTPs, and browser-authentication URLs out of durable release surfaces and retained summaries.
• Leave manifests, target changelog headings, exact-version commands, versioned release notes, and tag comparisons unchanged until the user or authoritative repository configuration confirms the release identity.
• Complete and, when authorized, commit each implementation Change independently before a dedicated Release Change and release commit finalize versioned shipped surfaces.
• Reject mismatched identities, Unreleased target headings, comparisons against HEAD, and known preparation-state markers before packaging.

Opt-in usage

Pin the exact prerelease identity rather than relying on a moving dist-tag:

npx -y @oevery/rsp@3.1.0-beta.1 init
npx -y @oevery/rsp@3.1.0-beta.1 skills install --dry-run
npx -y @oevery/rsp@3.1.0-beta.1 skills install

RSP 3.1 requires Node.js 22 or newer. Users upgrading directly from a registry-installed 2.x release must first follow the RSP 3.0 migration guide.

Compatibility and known limitations

• This prerelease remains opt-in; publishing it under the npm beta dist-tag does not promote npm latest.
• Real-project acceptance in boats-cloud remains unverified.
• Tagging, GitHub Release creation, npm publication, and external verification require separate authority and are not implied by this candidate.

Full comparison: v3.1.0-beta.0...v3.1.0-beta.1