Campus Placement Engine v0.1.0-alpha.3

Campus Placement Engine v0.1.0-alpha.3

The third public alpha strengthens the placement-day mutation boundary and the
managed-hosting contract while preserving the dependency-light, independently
self-hosted product.

What changed

• Board moves and returns now reserve and complete idempotency evidence in the
  same database transaction as application state, event, audit, and outbox
  writes. Exact retries return the stored result; conflicting or stale requests
  fail without retaining a partial reservation.
• Capability grants, system-role synchronization, and module enable or disable
  operations now converge to one exact state. Disabled modules cannot retain
  effective capabilities through an administrator wildcard, while custom roles
  remain institution-owned.
• Migration runners reject unknown, missing, or callback-mutated registry rows
  instead of claiming success. Publication and package checks continue to reject
  private quarantine material, runtime data, unsafe archive paths, and incomplete
  release contents.
• PostgreSQL production connections now use a strict policy requiring
  verify-full, a readable absolute trust root, a bounded connection timeout,
  non-persistent sessions, and an explicit direct or session-affine pool mode.
  Transaction pooling is unsupported. Insecure TLS is available only through an
  exact opt-in for loopback test databases.
• The release workflow always runs the conditional PostgreSQL TLS contract.
  Strict TLS policy, parsing, redaction, and loopback behavior are covered
  statically and locally. When the optional production-shaped endpoint secret is
  absent on this evaluation tag, whose complete shape is
  v<major>.<minor>.<patch>-alpha.<number>, live post-connect negotiated-TLS
  evidence is explicitly skipped and is not claimed for this release. Beta,
  release-candidate, stable, malformed alpha lookalikes, and other tags require
  the endpoint.

Upgrade from alpha.1 or alpha.2

Preserve the current database, backups, runtime configuration, and data/
directory. Replace only the application files with the verified alpha.3 package,
then run:

php placement upgrade
php placement doctor
php placement readiness

Review the upgrade backup before removing any prior application release. Unknown
migration history, ownership ambiguity, or institution-identity drift fails
closed and requires operator review rather than registry edits.

PostgreSQL and hosted operation

Cloud consumers must pin the immutable alpha.3 commit and release artifact,
verify its SHA-256 and managed-hosting contract, and test direct or
session-affine advisory-lock behavior against their exact endpoint. A passing
loopback CI database is not evidence for a production provider, pooler, trust
root, failover configuration, or restore process.

Release boundary

This remains an evaluation alpha. The release does not claim production capacity
or unattended managed-service readiness for a particular institution. Real use
still requires institution-approved security and privacy review, verified DNS
and certificates, secret management, monitoring and on-call operations,
encrypted offsite backups, isolated restore drills, and a controlled pilot.
Unless the release run is supplied CPE_POSTGRES_TLS_TEST_URL, it also carries
no live negotiated-TLS evidence from a production-shaped PostgreSQL endpoint.
That omission is permitted only because this tag matches the complete
v<major>.<minor>.<patch>-alpha.<number> evaluation-alpha convention; later
beta, release-candidate, stable, malformed, or other tag classes must supply the
endpoint before publication.

Real candidate records, runtime databases, exports, credentials, backups, and
private historical material are not included in release assets and must never be
committed to the repository.