Campus Placement Engine v0.1.0-alpha.2

Campus Placement Engine v0.1.0-alpha.2

The second public alpha focuses on safe upgrades and dependable operations while
preserving the complete self-hosted placement workflow from alpha.1.

What changed

• Browser, CLI, worker, and recovery failures now use reviewed messages and
  opaque incident references instead of exposing raw exception or destination
  details. Structured logs apply restrictive secret and path redaction.
• Setup authorization is fail-closed. Environment-token exchange requires
  direct HTTPS or the explicit secure-session override used behind a reviewed
  TLS-terminating proxy.
• Hosted installation identity is immutable and can be established only during
  the atomic hosted install. Installation stages, concurrent starts, ownership,
  migration locks, rollback uncertainty, and connection discard have dedicated
  regression contracts.
• Domain-event and notification workers use fenced claims, stable opaque
  idempotency keys, bounded stale-claim recovery, and truthful claim-lost or
  outcome-unknown results.
• New backups include checksum-bound ownership and institution-identity
  metadata. Restore rejects driver, owner, identity, checksum, and SQLite
  archive-identity mismatches before modifying the target.
• Logical portability preserves the installed target identity. Hosted targets
  reject bundles whose institution identity does not match exactly.
• Managed readiness and metrics authorization remains concealed before tenant
  resolution, including repeated malformed and unauthorized requests.

Upgrade from alpha.1

Preserve the original database and backups, replace only application files, keep
the existing runtime configuration and data/ directory, then run:

php placement upgrade

For an installed public alpha.1 database, the upgrade verifies the complete
legacy Engine signature and immutable institution identity, permanently claims
Engine ownership, writes a current metadata-backed pre-migration backup, and
then migrates. Mixed, partial, opposite-plane, or identity-drifted databases
fail closed. Keep the pre-upgrade database and every backup sidecar until the
upgraded installation passes readiness and an application smoke test.

Recover old backup artifacts

Alpha.1 SQLite backups have a one-entry checksum and cannot be restored
directly. Preserve the old archive and checksum, and create a new copy:

php placement convert-legacy-backup /secure/path/to/old.sqlite \
  --confirm=CONVERT --target-dir=/secure/path/to/converted

The source is never overwritten. The converted copy receives ownership
evidence, identity metadata, and a two-entry checksum. Alpha.1 SQLite import
rollback manifests similarly report legacy_conversion_required and require
an explicit rollback-import --convert-legacy --confirm=CONVERT step.

Metadata-free PostgreSQL .pgdump backups and alpha.1 PostgreSQL import
rollback snapshots are deliberately not converted or restored in place. The
CLI reports legacy_postgres_isolated_validation_required: preserve the dump
and checksum, restore into an isolated PostgreSQL database, verify schema,
ownership, installed marker, and institution identity, and then create a new
current-format backup.

PostgreSQL evidence boundary

CI and the release workflow exercise the database, worker, backup, installation,
locking, cleanup, and managed-hosting contracts against fresh PostgreSQL 17
databases. PostgreSQL pre-restore inspection with pg_restore --list proves
structural readability only. It does not prove the archive's institution rows;
that requires an isolated restore drill. This alpha does not claim production
capacity or unattended disaster-recovery validation for a particular hosting
environment.

Release expectations

A release candidate is acceptable only after the full SQLite suite, focused
security and recovery contracts, upgrade and legacy-backup fixtures produced
from the unmodified v0.1.0-alpha.1 tag, exact alpha.2 packages built from the
tagged source, fresh PostgreSQL workflow jobs, publication checks, package and
checksum verification, and extracted-package smoke tests all pass.
Operators should also complete the deployment and release checklists, verify
HTTPS and monitoring through their real proxy, and perform an institution-owned
backup and recovery drill before using real candidate data.

This remains an evaluation alpha. Real candidate records, runtime databases,
exports, credentials, backups, and private historical material are not included
in release assets.