ShipProof v0.10.0

ShipProof v0.10.0 — Executable Assurance and Reproducible Evidence

ShipProof v0.10.0 turns the post-0.9 development plan into enforceable local contracts. The default workflow remains read-only, offline, deterministic, and dependency-free. This release does not bulk-promote research candidates or claim precision from unreviewed findings.

Highlights

• The dependency-free public website source now ships in English and Thai with explicit sample labeling, no analytics, and no repository upload path. Support, feature, and rule-proposal surfaces route questions and evidence to the correct public or private channel.
• A separate manual npm trusted-publishing workflow validates an immutable release tag, repeats the complete package gate, uses a protected environment and OIDC, and has no long-lived-token fallback. npm availability is not claimed until that external relationship succeeds.
• Current documentation is scanner-derived at 635 executable rules, and a structure contract fails if the authoritative English, Thai, rule, research, plan, or release claims drift again.
• MCP-specific rules SP271–SP275 now require visible MCP context. File helpers no longer masquerade as traversal, real environment-access syntax is covered, and SP275 detects explicitly unbounded tool schemas instead of flagging validated input.
• All 635 executable scanner rules now have machine-readable assurance coverage for positive, negative, adversarial, CWE/control, remediation, and false-positive boundaries.
• The first 25-candidate polyglot batch was triaged before implementation. Three candidates reached research-only fixture_ready status, 22 were rejected from the batch, and zero were promoted without representative shadow evidence.
• Optional compiler/analyzer evidence reports now capture analyzer versions and distinguish unavailable, timeout, output-limit, crash, and findings states. Project-contained tools require explicit consent, and diagnostics are bounded and credential-redacted.
• Scanner performance reports include deterministic workload identity, warmup and sample counts, median and p95 timing, peak RSS, runtime identity, and separate clean, adversarial-regex, and large-file budgets.
• Controlled-corpus results report TP, FP, FN, and TN against sink-level labels while preserving source/helper files as context. The opt-in real-world evaluator pins six reviewed public repositories by full commit and license permalink.
• Every hidden legacy CLI alias has a tested 1.0 removal path and an explicit replacement. Version 0.10 keeps the warning-only compatibility window.

Evidence boundary

The three promotion prototypes are not executable ShipProof rules and do not change the 635-rule public catalog. Their fixtures show that a detector shape is testable; they do not establish representative precision.

Real-world evaluator output marks findings as unreviewed. A successful fetch and scan proves corpus identity and evaluator availability, not that each finding is a true or false positive. Precision claims require checked-in human labels and sample counts.

Performance values are observations tied to the reported machine, runtime, corpus digest, and configuration. They are not universal throughput guarantees and do not replace authorized production-shaped load tests.

Compatibility

The supported public commands remain check, scan, explain, gate, labs, init, config validate, doctor, and mcp. Hidden legacy aliases continue to emit migration warnings in 0.x. When the package major reaches 1, the parser rejects those aliases with exit code 2 and points to their replacements.

Exit codes remain 0 for pass, 1 for gate failure, and 2 for invalid or unavailable evidence. Existing v1 JSON schemas remain compatible; new evidence-adapter fields are additive.

Verification

Before a tag is created, the release must pass the complete lint/test/package/consumer suite, schema and command goldens, the direct high-severity self-scan, controlled head-to-head thresholds, and clean/adversarial/large-file benchmark budgets. Harness acceptance checks remain required when a release change was executed through the opt-in Harness workflow. Publishing, tagging, and pushing remain separate maintainer actions.