You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make main the single trustworthy dependency/release baseline, close or deliberately disposition every current issue, and publish the latest compatible @bsv/* stack with reproducible security and quality evidence.
No dependency PR is merged solely because it is automated. Lockfile delta, advisory impact, peer compatibility, package builds/tests, Sonar/Codecov, and release order all remain required review inputs.
Enable Dependabot alerts, grouped-security controls, update-branch support, auto-merge capability, and merged-branch cleanup; deliberately pause automatic security-fix PR generation during the current consolidation after GitHub emitted separate per-directory PRs.
Install additive repository rules that enforce resolved review threads and the proven status-check set while allowing maintainers/admins to merge without code-owner or last-pusher approval requirements.
Have a Sonar organization admin disable Automatic Analysis; then enable the CI scanner and enforce the new-code quality gate (zero new issues, Security/Reliability/Maintainability A, reviewed hotspots 100%, duplication <3%, coverage >=90%).
Verify Dependabot accepts the consolidated configuration after it lands.
Every issue currently open must end in one of: merged fix, documented decision, linked successor, or explicit not-planned closure. No silent bulk closure.
Produce a leaf-to-root release graph, synchronize first-party ranges, and publish in dependency order.
Verify every published package from a clean consumer install (ESM, CJS, browser where applicable), provenance, npm dist-tags, and tarball contents.
Run full conformance, CI, Sonar, Codecov, Socket, and advisory checks on the release commit.
Publish release notes and a compatibility matrix; confirm downstream repos can install the latest stack.
Close this milestone only when the latest intended code is on npm and all in-scope issues have a recorded disposition.
Merge standard
A PR is ready only when it is current with main, has no unresolved review thread, passes the protected merge gate and security checks, introduces no new Sonar issue, meets patch coverage, and has an explicit release/rollback note when it changes a published package. Independent review remains preferred when practical, but maintainers/admins may approve or use their authorized bypass to merge; GitHub authors cannot formally approve their own PR.
Outcome
Make
mainthe single trustworthy dependency/release baseline, close or deliberately disposition every current issue, and publish the latest compatible@bsv/*stack with reproducible security and quality evidence.Target date: 2026-08-20 (PT).
Scope decisions
Phase 1 — governance and trustworthy analysis
pnpm installfindings reported on PR feat(wallet-toolbox): horizontally scale Storage with shared async sessions #283.Phase 2 — security and correctness blockers
identifyAdmissibleOutputsskips signature verification (missingawait) #68 — restore SHIP/SLAP signature verification.POST /admin/health-checkwith empty body leaks a destructuringTypeErroras the response message #69 andPOST /submitwith empty body leaks a V8TypeErroras the response message #71 — stop leaking runtime errors at HTTP boundaries.Phase 3 — compatibility upgrades and static-analysis debt
test:coverage.Phase 4 — functional and interoperability backlog
createNonce/verifyNonceare misleading for auth — and redundant with signatures #168 before making breaking changes.POST /lookupunknown-service error has a trailing space in the message #70.Phase 5 — documentation and issue hygiene
Phase 6 — coordinated publication
npm-productionenvironment.Merge standard
A PR is ready only when it is current with
main, has no unresolved review thread, passes the protected merge gate and security checks, introduces no new Sonar issue, meets patch coverage, and has an explicit release/rollback note when it changes a published package. Independent review remains preferred when practical, but maintainers/admins may approve or use their authorized bypass to merge; GitHub authors cannot formally approve their own PR.