[Release] Finish Phase 0 external exit evidence

[jongan69]

Outcome

Close the non-code release-containment gates while keeping every current binary out of production.

Acceptance checklist

• Withdraw or reject iOS 0.1.0 build 4 in App Store Connect and attach non-sensitive evidence
• Confirm Android 0.1.0 build 3 remains draft/held and unavailable to production users
• Complete backend package publication issue [Release] Publish and verify opendating-protocol 0.1.1 OpenDating#7
• Pin the verified opendating-protocol@0.1.1 artifact and remove the temporary mobile routing mirror
• Verify deletion, discovery gestures, and candidate-profile navigation on physical iOS and Android devices from the exact release candidate
• Record protected CI run, signed tag, source SHA, EAS artifact IDs/checksums, store state, migrations, and rollback evidence in the release record
• Update release/manifest.json only when every Phase 0 exit gate has evidence

Related operations blocker

Cloudflare deployment provenance and isolation are tracked in jongan69/OpenDating#8.

Non-waivable rule

No current binary ships while the release manifest is blocked.

[jongan69]

Audit of the Phase 0 gates — verified against the repo at e890b9e

The most important finding is that the last item on this checklist had already been actioned prematurely, in the direction that removes the containment this issue exists to enforce.

release/manifest.json declared an approval that does not exist

The manifest carried "status": "approved" with "blockers": [], "approvedAt": "2026-08-09T00:00:00Z", and "approvedBy": "jongan69" — alongside a null gitSha and null artifact IDs, and with none of the gates below satisfied. Meanwhile README, docs/RELEASE-STATUS.md, docs/DEPLOYMENT.md, and docs/ROADMAP-1.0.md all correctly stated the opposite.

The manifest is the machine-readable source of truth, so two things followed:

• npm run release:validate, a CI gate, reported "structurally valid and currently approved" — a green signal for a release with zero exit evidence.
• The only remaining barrier to npm run submit:ios / submit:android was the null-gitSha regex. approvedAt and approvedBy were already populated, so recording a SHA would have opened the production path with none of the evidence below collected. That is the exact failure mode the non-waivable rule in this issue is written to prevent.

Corrected in #12: status blocked, approval fields nulled, and the checklist below encoded as machine-readable blockers so both gates now name the real reasons.

Per-item status

Gate	Status
Withdraw/reject iOS 0.1.0 build 4	Not verifiable from the repo — needs App Store Connect evidence
Confirm Android 0.1.0 build 3 held	Not verifiable from the repo — needs Play Console evidence
Backend package publication (jongan69/OpenDating#7)	Open. Registry latest is still 0.1.0; blocked on the npm E401
Pin verified opendating-protocol@0.1.1, remove routing mirror	Blocked upstream. The dependency was a caret range ^0.1.0, which would have silently accepted 0.1.1 the moment it published — ahead of the verification this gate requires. Exact-pinned to 0.1.0 in #12. The mirror at src/lib/opendating/request-routing.ts stays until 0.1.1 is verified
Physical-device verification	Partial. docs/APP-REVIEW-NOTES.md records only Samsung SM-A166U1 / Android 16. No iOS physical-device walkthrough is recorded, and the doc contradicts itself: line 142 says an iPadOS recording is attached, lines 150-151 say it is pending
Record CI run, signed tag, SHA, artifact IDs/checksums, store state, migrations, rollback	Not started. Every corresponding manifest field is null
Update the manifest only when every gate has evidence	Was violated; now corrected (above)

Also found, outside this checklist

1. Private vulnerability reporting is disabled. .github/ISSUE_TEMPLATE/config.yml publishes a "Report security issues privately" link to /security/advisories/new, but the API reports {"enabled": false} for this repo. Non-maintainers currently have no working private reporting path. Repo setting — needs a maintainer to enable it.
2. Consent-record validation gaps, both raised on Terms consent gate: in-app safety-screening disclosure and hardening #10 and never carried into fix: address all CodeRabbit review comments + build infra #11 when it superseded that PR. isCurrentPolicy checked only the version string, so a record naming the shipped version with an empty or pre-effective-date timestamp passed the gate; and logout swallowed acceptance-cleanup failures while deleting the identity first, failing open. Fixed in fix: correct release manifest state and tighten consent validation #12, along with two further paths the original report did not cover — deleteAccount and importAccount never cleared the record at all, and Settings → Terms never compared the record's bound pubkey to the signed-in key.
3. PR fix: override image-size and uuid vulnerable transitive deps #8's image-size half must not be re-landed. It was closed unmerged and its CVE-2025-71330/71329 override never landed. Re-landing would break asset bundling: metro passes a file path string at Assets.js:177 and image-size 2.x accepts only ArrayBuffer/ArrayBufferView. Verified empirically against 2.0.2. Closing fix: override image-size and uuid vulnerable transitive deps #8 was correct; the time-limited exception (expires 2026-09-30) remains the right treatment, and security/audit-exceptions.json now records why so it is not blindly retried at expiry.
4. OPENDATING_RELEASE_APPROVED is not restricted to a release manager. docs/DEPLOYMENT.md states only an authorized release manager may set it, but assert-release-ready.mjs only compares it to "true" and no workflow restricts who can set it. Either enforce it in the protected environment or relax the claim.
5. Audit exceptions do not validate provenance. check-production-audit.mjs matches on package name, affectedRange, and advisory IDs only, so runtime-package entries can implicitly allow advisories outside the documented build-only subgraph the rationale describes.

Ten stale CodeRabbit threads on #8 and #9 were verified fixed on main and resolved. Items 1, 4, and 5 above remain open and unresolved.