Skip to content

RSP 3.1.0

Choose a tag to compare

View all tags
@oevery oevery released this 30 Jul 13:46
· 224 commits to main since this release
v3.1.0
This tag was signed with the committer’s verified signature.
oevery Oevery
GPG key ID: FF2F947EF8595DC8
Verified
Learn about vigilant mode.
312f973
This commit was signed with the committer’s verified signature.
oevery Oevery
GPG key ID: FF2F947EF8595DC8
Verified
Learn about vigilant mode.

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

Assets 2
Loading