Campus Placement Engine v0.1.0-alpha.5

Campus Placement Engine v0.1.0-alpha.5

The fifth public alpha makes the self-hosted Engine easier to evaluate and gives
its release process materially stronger browser, accessibility, and upgrade
evidence. It remains independently usable without Campus Placement Cloud.

What changed

• A pinned Playwright and axe-core release harness now exercises the installed,
  server-rendered Engine in Chromium, Firefox, and WebKit before publication.
  It covers authentication, role boundaries, protected routes, every key
  administrator screen, public aggregates, board preferences, keyboard focus,
  narrow screens, zoom, reduced motion, forced colours, and serious/critical
  accessibility findings using synthetic records only.
• Board auto-refresh is now visible, pausable, and announced without forced HTML
  meta refresh. Forms discovered by the browser pass now have explicit labels,
  and top-bar contrast meets the automated release gate.
• CI and release download the exact immutable alpha.4 archive and prove a
  backup-first upgrade preserves institution, account, candidate, company, and
  application rows while converging to the exact current migration history.
• The public site now leads with candidate placement outcomes, includes a
  captioned walkthrough recorded from the real synthetic Engine, and offers a
  clear university-pilot path. The repository adds a short installation guide,
  deployment examples, and adopter FAQ.
• Release artifacts and GitHub Pages outputs retain bounded contents, fixed
  checksums, generated-only demonstrations, and no runtime state or credentials.

Upgrade from alpha.4 or earlier

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

php placement upgrade
php placement doctor
php placement readiness

The upgrade command creates and verifies a pre-migration backup before applying
new migrations. Never delete migration or ownership rows to force an upgrade.

Browser qualification boundary

The automated release matrix uses Linux Chromium, Firefox, and WebKit. A real
Safari and representative assistive-technology pass remains part of the
deployment checklist because an engine-equivalent browser run is not the same
evidence as the target operating system, browser, and screen reader.

Release boundary

This is still an evaluation alpha. It does not claim that a particular
university's privacy, security, accessibility, capacity, recovery, or support
requirements are satisfied. A production deployment requires institution
approval, a successful rehearsal, encrypted offsite backups, an isolated
restore drill, monitored TLS and workers, named incident ownership, and
provider-specific evidence.

If CPE_POSTGRES_TLS_TEST_URL is absent, this evaluation-alpha release may skip
live negotiated-TLS evidence and must report that omission. Beta, release-
candidate, stable, malformed, and other tag classes continue to fail publication
without that production-shaped endpoint evidence.

Campus Placement Engine v0.1.0-alpha.4

Campus Placement Engine v0.1.0-alpha.4

The fourth public alpha turns the Engine into a safer integration platform while
making day-to-day placement operations easier to understand. It remains a
dependency-light, independently self-hosted product; Cloud is optional and does
not own placement behaviour or institution records.

What changed

• Installed systems now fail closed when durable authorization state is missing,
  invalid, or unavailable. Protected routes and commands return fixed denials
  without exposing records, and optional observers can no longer roll back core
  placement decisions.
• The public integration contract now governs a privacy-reviewed application
  status event, signed institution webhooks, institution-local service accounts,
  bounded read APIs, and one controlled application-transition command. API
  retries are idempotent and state changes require the expected aggregate
  version.
• Webhook delivery is asynchronous, encrypted at rest through externally
  supplied keys, HTTPS-only, redirect-free, SSRF-resistant, retryable, and
  dead-lettered with audited replay. Worker fencing and concurrency contracts run
  on SQLite and PostgreSQL.
• A new Candidate opportunities workspace gives authorized university teams
  one outcome-focused view of candidates who need action. It uses existing
  product records, distinguishes unavailable evidence from an empty queue, and
  hides action links the current role cannot use.
• Integration setup and health now use consistent language and show worker,
  backlog, dead-letter, TLS, encryption-key, and database readiness without
  exposing endpoints or secrets. php placement support-report emits a bounded,
  privacy-safe diagnostic document for support handoffs.
• Installation, migration, database ownership, backup/restore, package, and
  concurrency boundaries received additional negative-path and PostgreSQL
  coverage. The release archive includes all governed contracts, examples,
  documentation, and verification tests while excluding runtime and quarantined
  material.

Upgrade from alpha.1, alpha.2, or alpha.3

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

php placement upgrade
php placement doctor
php placement readiness

Configure webhook encryption keys and the Integration worker before enabling
signed webhooks. Create narrowly scoped service accounts only for approved
integrations. Unknown migration history, ownership ambiguity, authorization
state failure, or institution-identity drift fails closed and requires operator
review rather than manual registry edits.

Hosted and Connector operation

Cloud consumers must pin this exact release commit, artifact SHA-256,
managed-hosting contract, and contracts/public-integration.v1.json digest.
Connector artifacts, tenant-local credentials, execution isolation, runtime
receipts, canary evidence, and rollback generations remain separate deployment
proofs; none are implied by the Engine package alone. Placement payloads and
institution API credentials must never enter the Cloud control plane.

Release boundary

This remains an evaluation alpha, not a claim of production capacity or an
unattended SaaS for a particular university. Real deployment still requires an
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.

If CPE_POSTGRES_TLS_TEST_URL is absent, this evaluation-alpha release may skip
live negotiated-TLS evidence from a production-shaped PostgreSQL endpoint and
must report that omission. Beta, release-candidate, stable, malformed, and other
tag classes fail before publication without that evidence.

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

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.

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.

Campus Placement Engine v0.1.0-alpha.1

Campus Placement Engine v0.1.0-alpha.1

The first public alpha makes it easier for university placement teams to try a
complete, self-hosted placement workflow with synthetic data.

What is included

• Guided first-run setup for institution identity, placement cycle, workflow,
  terminology, administrator access, and optional sample data.
• Live placement operations across candidate, company, coordinator, and
  placement-office roles.
• Scheduling, interview movement, placement decisions, imports, reports,
  privacy operations, readiness checks, and checksum-backed backups.
• A ZIP for the simplest download path and a tarball for server operators.
• SHA-256 sidecars, a combined SHA256SUMS file, and built-in archive
  inspection with php placement verify-package.

Install

Download the ZIP and its checksum, extract it, and run:

php placement setup

See the
installation guide
for local, shared-hosting, Apache, and Nginx paths.

Alpha boundaries

• Treat this release as an evaluation and pilot candidate, not an unattended
  production-service guarantee.
• Test with synthetic data first and complete the release/readiness checklist
  before any real placement cycle.
• The managed SaaS signup and automated infrastructure layer is being developed
  separately; this release is the complete self-hosted Engine.
• Operators remain responsible for HTTPS, access control, backups, monitoring,
  and the security of the server on which they install it.

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