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