Gate protected branches and release publishing on release-blocking validation

[TheSilkky]

Gate protected branches and release publishing on release-blocking validation

Priority

P1

Type

ci

Labels

Suggested GitHub labels:

• backlog
• ci
• security
• testing
• deployment
• maintenance

Branch scope

• Current branch: develop
• Current HEAD: 3555d1fd531ecd4b51b85779618bf4717514aa25
• Target branch: develop
• Original reviewed branch/ref: upgrade-codex-reports-and-repo-full-validation-security-review
• Original reviewed commit SHA: e609ff86028c81bd149839e03d1ffc0eb2ee9e4a
• Merged source pull request: #378
• Target release/version: unreleased
• Scope classification: release-blocker-current-branch
• Revalidation status: Revalidated against develop at 3555d1fd531ecd4b51b85779618bf4717514aa25 on 2026-07-12; repeat if develop moves before issue creation.

Summary

Make protected-ref and publication controls enforce every release-blocking security, PostgreSQL, relay, and disposable optional-backend validation signal.

Context

Existing workflow jobs provide several useful signals, but the active protected-ref requirements and publication dependencies do not enforce the complete release-blocking set. Public CI also lacks a complete disposable PostgreSQL, S3-compatible, and Valkey stack job.

Issues #49, #137, #249, and #305 added individual vulnerability, PostgreSQL, readiness, and relay signals. This draft tracks their complete enforcement plus the missing optional-backend full-stack signal; it should not recreate already-working jobs unnecessarily.

Proposed change

Add a stable disposable full-stack CI job, make publication paths depend on all release-blocking jobs, align the release prompt and development documentation, and update the relevant live rulesets only after the new check names have emitted successfully.

Keep every CI service disposable and synthetic. Do not use production credentials, private endpoints, or real evidence.

Acceptance criteria

• CI exercises PostgreSQL, S3-compatible encrypted storage, and Valkey together using disposable services.
• Vulnerability, PostgreSQL, relay-image, and full-stack optional-backend results gate the applicable publication paths.
• Binary attestation/upload and both image publications depend on every applicable release-blocking job.
• The release-check prompt and development docs name the selected release-blocking validation commands and signals.
• Stable emitted check names are verified before ruleset requirements are changed.
• Develop, main, and release/v* rulesets require the approved signals where applicable.
• Tag-only publication behavior remains correctly scoped.
• No production secrets, private services, raw identifiers, or user data are introduced.

Tests / validation

• Validate workflow syntax with the repository's established workflow checker.
• Run scripts/check-markdown-links.py.
• Run go test ./...
• Run go vet ./...
• Run the disposable full-stack, retry, and relay smoke variants.
• Run git diff --check.
• Inspect a public Actions run and its emitted check names.
• Re-read the live rulesets after any separately approved settings update.
• Revalidate against the target branch before public issue creation.

Out of scope

• Bypassing branch protection or publication controls.
• Using real credentials, production services, private endpoints, or user evidence.
• Treating CI success as production readiness, a formal audit, or proof that no vulnerabilities exist.
• Folding private vulnerability details into public workflow logs, docs, or issue discussion.
• Changing unrelated repository settings.

Notes

Report reference: docs/reports/2026-07-10-proofline-unreleased-technical-review.md, public finding F-009.

Related completed work includes issues #49, #137, #249, and #305 and PRs #55, #143, #255, and #314.

This local draft does not authorize a GitHub ruleset or repository-settings mutation.