Skip to main content

PR Preview admission

Directory, Catalog, Wiki and Platform separate the credentials a develop build receives from those any other ref receives. They do it with Vercel environment scoping, not with a Git filter: every staging credential is a Preview variable scoped to the develop branch, and generic Preview (every other branch) holds none. So a PR Preview builds credential-free, and only develop, which changes only through reviewed PRs, builds with staging credentials.

None of the four vercel.json files carries a git.deploymentEnabled rule. develop deploys automatically on every merge, and other branches keep default eligibility, subject to the project's other controls. scripts/vercel-preview-admission.test.ts pins that. Do not add a wildcard rule: Vercel permits deployment when any matching rule is true. See Vercel Git configuration. Existing ignored-build commands remain build optimizations.

Credential-free PRs depend on the provider's environment and ref bindings and on connected-resource grants. They do not provide authenticated access to shared staging backends. Manual, API and CLI deployment, redeployment, promotion, running jobs and existing deployments are governed separately.

Enable one project​

  1. Keep its Preview admission disabled while preparing and reviewing the source change. Complete required repository checks and obtain explicit human approval for the exact merge candidate.
  2. Verify that generic Preview holds no credential, from names-only variable metadata: every staging credential must be scoped to the develop branch. A feature branch's configuration does not establish another ref's behavior. Preserve the Production branch, fork and access controls, installation/build settings, function limits and crons.
  3. Resolve pre-change pending Git events with supported provider evidence or an explicitly authorized resolution. An empty deployment list alone does not prove there are no pending Git events. If this state is unknown, leave the switch disabled and record the missing evidence.
  4. Check names-only project and shared-variable bindings plus integration and resource grants for every admitted scope. Do not reveal values. Reconcile manual/API deployment authority separately; Git filtering does not enforce it. Record the operator, exact project and restoration authorization.
  5. Enable the verified project's Preview admission and read back the change, checking other controls remain unchanged. The switch admits eligible pending and future refs/events, not just one chosen commit. Record observed project/ref/SHA and terminal deployment states using bounded metadata reads. A Ready build does not prove backend or authenticated functionality.

Staging refresh​

From INF-847 until 2026-11-04, the four vercel.json files carried { "git": { "deploymentEnabled": { "develop": false } } }, and staging refreshed only by separately approved manual deployments. That hold was lifted on 2026-11-04 by a reviewed PR, with Gregor's approval. Before it merged, this evidence was recorded:

  • All four zones were already serving current code. Platform, Directory and Catalog served a09b4aba81, and Wiki served 85248dea76. Between those SHAs and the restoring PR's base, develop changed only CI scripts and docs. The one migration in that range was already applied to staging.
  • The develop aliases were projects-dev.planetb2b.com, constellation-dev.planetb2b.com and catalog-dev.planetb2b.com, plus each project's *-git-develop-planet-b2-b.vercel.app. Vercel moves these to the newest develop deployment on its own.
  • The staging cron caller (staging-cron-tick.yml, Staging Cron environment) targets STAGING_PT_BASE_URL=https://projects-dev.planetb2b.com and the Wiki's git-develop alias. Both follow the newest develop deployment, so cron and code versions move together.
  • On all four projects, generic Preview held no variable, and every Preview variable was scoped to develop (names-only metadata).

Every merge to develop now rebuilds the zones its ignoreCommand admits. Platform has no ignore command, so it builds on every merge. Apply a migration to staging before the PR that needs it merges, as the release-and-migrations skill describes. Otherwise the new build serves code against an older schema.

Rollback and staging​

To stop automatic staging refreshes again, add the exclusion back to the affected vercel.json files and update scripts/vercel-preview-admission.test.ts in the same reviewed PR. A hold does not cancel running work, remove deployments or revoke credentials; those actions need their own scope. Never move a credential into generic Preview to make a build pass.

Evidence boundary​

Record candidate, merged/effective and enabled states distinctly. Source completion and Preview admission do not close the credential-response work in INF-847 or release INF-801. Keep restricted evidence in the response owner's records, outside published docs.