jpdev v0.14.0

jpdev v0.14.0

This release completes the v0.14.0 milestone with four changes:

• Bind pull-request evidence reuse to the pinned API's merge event (#70, #74).
• Account for nested process groups in the RSS guard (#65, #72).
• Permit reviewed verifier replacement with a complete guarantee mapping (#69, #75).
• Share acceptance mapping and complexity-control rules across agent instructions and operating policy (#71, #73).

Pull-request evidence reuse

The pinned API version omits merge_commit_sha from associated pull-request records.
The gate now requires exactly one server-recorded timeline merged event whose
commit_id matches the branch commit. Missing, malformed, ambiguous or mismatched
merge evidence refuses reuse with reuse-pull-request, so checks run fresh.
The complete timeline also supplies the existing base-change check. Repository,
branch, head, run, tree, parent, input and artifact checks remain in force.

Captured API-shape projections and handwritten regression cases cover the changed
binding. A live API plan replay with original source and recorded runner/environment
inputs selected reuse for 21 checks. This demonstrates the plan with those recorded
inputs; it was not a fresh hosted-runner execution and did not execute consumer checks.

RSS guard

The guard samples resident memory across the launched session, including descendants
in separate process groups. It continues monitoring after the leader exits and cleans
up session process groups on a memory limit, wall-clock limit or handled interruption.
Its diagnostics now describe the session rather than one process group.

For Go race runs that require a large virtual address reservation, the documented
explicit outer RSS guard can be combined with JPDEV_GO_ULIMIT_KB=unlimited while
retaining the existing wrapper's lock, cache, read-only module mode and inner timeout.
No default resource limit changes.

This is a sampled, cooperative guard. A descendant that creates a new session escapes
its accounting and cleanup. Shared resident pages can be counted more than once.
It is not a security containment mechanism. Process tests exercise the guard and
wrapper; they do not establish that a consumer's Go race suite passed.

Adoption and operating policy

An adopter may replace an existing verifier only through reviewed compatibility work
that maps every previous guarantee to a gate check, configuration entry or unchanged
release job. An unmapped guarantee blocks replacement. Passing the kit's tests alone
does not establish adopter equivalence.

The shared instructions require one current acceptance mapping, the smallest design
that preserves accepted contracts, accurate completion states, reuse of existing
harnesses, planned resource headroom, preserved failure evidence and grouped fix
rounds. Generated instruction copies remain synchronized with their canonical files.
Ownership, delegation, stop/handoff, review, CI and release gates remain in force.

Validation and rollout

The implementation batch passed all eight local checklist steps, including 449 tests,
and each merged PR passed exact-head lint, tests and DCO checks. Independent same-vendor
reviews report no findings; #74 includes the clean-room security round. The PR records
identify the reviewers, evidence, additional probes and limitations.

The release preparation follows the separate full-checklist, exact-head CI, complete
release-diff review, signed-tag and protected-publication gates in docs/releasing.md.
The workflow verifies main CI evidence, packages the tagged source and attests both
the tarball and its checksum file before publication.

This release updates judgment-pack-devkit only. It does not update consumer copies,
enable evidence reuse in a consumer, replace a consumer verifier or authorize rollout.
Each adoption remains a separately authorized and reviewed repository change.