Establish Psyche security, release, support, and governance readiness

[BunsDev]

Outcome

Establish the security, support, release, and governance controls required to publish and maintain Psyche as a protocol relied on by multiple OpenCoven repositories.

Parent roadmap: #9
Priority: P1, with minimum security floor in Phase 0
Target phases: Phase 0 and Phase 4
Accountable owner: @BunsDev

Minimum security and ownership floor

• SECURITY.md with supported versions/surfaces, private reporting route, disclosure expectations, and ordinary-support boundary.
• CODEOWNERS for core contracts, store/migrations, Coven boundary, surfaces, conformance, evidence, CI, release, and docs.
• Pull-request template requiring scope, risk, contract impact, migration, rollback, generated artifacts, tests, and affected consumers.
• Issue forms that do not solicit secrets, raw prompts, unrestricted terminal output, private repository data, environment dumps, or full personal paths.
• Branch/ruleset policy applying required checks and review to maintainers and administrators.
• Dependency review, secret scanning, and provenance controls aligned with existing cargo-deny/gitleaks checks.

Release contract

• Define supported artifact types and distribution channels.
• Define versioning for protocol schema/profile, Rust implementation, npm wrapper, and conformance runner.
• Produce SBOM/provenance/checksums and signed immutable release metadata.
• Verify packed artifacts from a clean install rather than source-relative imports.
• Define release candidate, stable, deprecation, emergency patch, and rollback procedures.
• Retain compatibility matrix and downstream canary evidence for every stable release.
• Define support windows and upgrade/downgrade policy.

Acceptance criteria

• Sensitive surfaces have explicit owners and protected review.
• Direct/bypass changes cannot silently skip required checks.
• Public reporting guidance never encourages protected-data disclosure.
• Every stable release resolves to immutable source and artifact digests.
• Downstream consumers can identify supported versions and migration paths.
• A release cannot be called stable while a required consumer canary is red or absent.
• Emergency changes are named, time-bounded, auditable, and followed by restoration/review.
• One release rehearsal proves build, conformance, pack/install, provenance, downstream canary, and rollback.

Non-goals

• Claiming readiness from community-health file presence alone.
• Publishing private signing or vulnerability details.
• Replacing organization-wide policy.
• Supporting every internal/experimental record indefinitely.

Dependencies

• Land Psyche repository and agent-readiness foundation #10 readiness foundation.
• Publish Psyche protocol v1 schemas, golden vectors, and conformance runner #11 protocol artifact definition.
• Define OpenCoven cross-repository protocol ownership and compatibility #12 ownership and downstream compatibility policy.

Evidence

Link the governance PRs/settings evidence, release runbook, rehearsal, artifact digests, provenance, downstream canaries, review resolution, and final stable release.