Dependency authentication

Manage authentication for private dependencies and local development secrets: npm (Font Awesome), Composer (Yoast SEO Premium and related private packages), VIP local environment variables, and the Firebase Admin service account JSON.

Admin Columns Pro has been removed from the platform. PRC_PLATFORM_ACP_LICENSE is no longer required.

Private Font Awesome Registry Auth (.npmrc generation)

The Font Awesome Pro packages are only consumed by plugins/prc-icon-library, which builds SVG sprite assets that are committed to the repo. Day-to-day development and all CI workflows use npm ci --omit=optional so they never touch the private registry — no token required.

You only need a Font Awesome token when you actually need to regenerate the sprite assets in plugins/prc-icon-library/build/icons/sprites/ (rare).

When you do need to rebuild sprites

op signin   # if needed
npm run gen:npmrc
npm install --include=optional --workspace=@prc/icon-library
npm run --workspace=@prc/icon-library build:sprites
git add plugins/prc-icon-library/build/icons/sprites

Or with an explicit env var:

export PRC_PLATFORM_FONTAWESOME_TOKEN=<your-token>
npm run gen:npmrc
npm install --include=optional --workspace=@prc/icon-library
npm run --workspace=@prc/icon-library build:sprites
git add plugins/prc-icon-library/build/icons/sprites

Mechanism

Font Awesome Pro packages live in plugins/prc-icon-library/package.json as optionalDependencies. With --omit=optional (the default in CI and the bootstrap script), npm never resolves them.
Script bin/setup/generate-npmrc.sh writes a local .npmrc when a token is resolved. It runs via the root preinstall npm script. If no token is found, the script no-ops cleanly.
.npmrc is listed in .gitignore so it never enters version control.

Credentials resolved (in order):

Explicit environment variable (overrides)
1Password CLI credential field from the Platform Secrets vault item titled with the matching PRC_PLATFORM_* constant (local op signin, or CI when OP_SERVICE_ACCOUNT_TOKEN is set)

Credential	1Password item (title, Platform Secrets vault)	Env override
Font Awesome npm token	`PRC_PLATFORM_FONTAWESOME_TOKEN`	`PRC_PLATFORM_FONTAWESOME_TOKEN`

Optional vault override:

export PRC_PLATFORM_SECRETS_OP_VAULT="Platform Secrets"

Security notes

Rotate the token if it was ever committed elsewhere.
The generated .npmrc gets chmod 600 permissions.
Never echo the token in logs; the script avoids printing it.
Deploy/build/ship workflows install the 1Password CLI and pass OP_SERVICE_ACCOUNT_TOKEN so generate-npmrc.sh can resolve the token from Platform Secrets. Those workflows run npm ci --omit=optional, so private Font Awesome packages are still skipped. Env var overrides still win when set.

Composer Private Credentials (auth.json generation)

We also avoid committing auth.json for private Composer services. Instead we generate it when needed.

Script: bin/setup/generate-composer-auth.sh

Credentials resolved (in order):

Explicit environment variable (overrides)
1Password CLI credential field from the Platform Secrets vault item titled with the matching PRC_PLATFORM_* constant (local op signin, or CI when OP_SERVICE_ACCOUNT_TOKEN is set)

Local development (1Password CLI)

If the 1Password CLI (op) is installed and signed in, the script reads each credential from the item in the Platform Secrets vault whose title matches the constant below:

Credential	1Password item (title, Platform Secrets vault)	Env override
GitHub OAuth (pewresearch VCS repos)	`PRC_PLATFORM_GITHUB_TOKEN`	`PRC_PLATFORM_GITHUB_TOKEN`

Optional vault override:

export PRC_PLATFORM_SECRETS_OP_VAULT="Platform Secrets"

Generate manually:

op signin   # if needed
npm run gen:composer-auth
composer install

CI

Deploy/build/ship workflows install the 1Password CLI and pass OP_SERVICE_ACCOUNT_TOKEN (GitHub Environment secret for staging deploys; repo-level secret for build-release / ship-plugins). Generators then read Platform Secrets the same way as local. Env var overrides still work:

export PRC_PLATFORM_GITHUB_TOKEN=xxxxx     # GitHub fine-grained PAT for pewresearch repos

PRC_PLATFORM_GITHUB_TOKEN may resolve into auth.json when that vault item exists. The script still has a dormant Admin Columns auth path for legacy Composer deps; it does not run unless composer.json / composer.lock mention admincolumns.

Notes:

auth.json is gitignored.
Script only writes the sections for which credentials were resolved.
Permissions are restricted to 600.
Safe to re-run; file is replaced atomically.
Running npm run composer auto-generates auth.json first on the host.
Use npm run composer:container ONLY if you explicitly need Composer inside the VIP dev-env container (vip dev-env exec).

VIP Local Environment Variables (vip-env-vars.local.php generation)

Local VIP dev-env reads platform secrets from vip-config/vip-env-vars.local.php (gitignored). The file is generated — do not edit it manually.

Script: bin/setup/generate-vip-env-vars.sh

Credentials resolved (in order):

Explicit PRC_PLATFORM_* environment variables (CI / overrides)
1Password CLI credential field from every item in the Platform Secrets vault whose title starts with PRC_PLATFORM_ (local dev)

Local development (1Password CLI)

op signin   # if needed
npm run gen:vip-env-vars

Or as part of bootstrap / all local auth generation:

npm run bootstrap
# or
npm run gen:auth

Each secret is stored as an API Credential item titled with its constant name (e.g. PRC_PLATFORM_SLACK_TOKEN). To add or update a secret, create or edit the matching item in Platform Secrets, then re-run the generator.

Optional vault override:

export PRC_PLATFORM_SECRETS_OP_VAULT="Platform Secrets"

One-time bulk import from an existing local file:

python3 bin/setup/import-vip-env-vars-to-1password.py

CI / non-1Password environments

Set PRC_PLATFORM_* environment variables; 1Password lookup is skipped when CI=true or GITHUB_ACTIONS is set. Bootstrap and the generator no-op cleanly when no credentials are resolved.

Notes:

vip-env-vars.local.php is gitignored.
Permissions are restricted to 600.
Safe to re-run; the file is replaced when credentials resolve.
Environment variables override 1Password values for the same key.

VIP-CLI Auth (`~/.config/configstore/vip-go-cli.json`)

VIP-CLI automation (e.g. npm run vip:sync, remote vip @pewresearch.* commands in Cloud Agents / CI) needs a User ID + Personal Access Token instead of interactive vip login. Bind whichever VIP account should act — a shared bot, or your own user. See VIP-CLI Automation.

Script: bin/setup/generate-vip-cli-auth.sh

npm alias: npm run gen:vip-cli-auth (also included in npm run gen:auth and npm run bootstrap; run automatically by bin/setup/cursor-cloud-vip-start.sh).

Credentials resolved (in order) for both values:

Explicit environment variable
1Password CLI credential field from the Platform Secrets vault item titled with the matching PRC_PLATFORM_* constant

Credential	Env / 1Password item
VIP User ID	`PRC_PLATFORM_VIP_BOT_USER_ID`
Personal Access Token	`PRC_PLATFORM_VIP_BOT_TOKEN`

Writes:

{
  "vip-go-cli-uuid": "<PRC_PLATFORM_VIP_BOT_USER_ID>",
  "vip-go-cli": "<PRC_PLATFORM_VIP_BOT_TOKEN>"
}

to ~/.config/configstore/vip-go-cli.json with mode 600. The file lives outside the repo and is never committed. Safe to re-run; skipped cleanly when either credential is unresolved.

Verify:

npm run gen:vip-cli-auth
vip whoami

Remote VIP Environment Variables (1Password → `vip config envvar`)

vip-env-vars.local.php covers local dev. Remote environments (production, alpha, beta, canary) read their secrets from VIP platform env vars. bin/setup/sync-vip-env-vars.sh reconciles a remote environment's env vars with the Platform Secrets vault.

Script: bin/setup/sync-vip-env-vars.sh <env> [--dry-run] [--prune] [--app <name>] [--vault <name>]

npm alias: npm run sync:vip-env-vars -- <env> --dry-run

Model

Tags select membership. An item is deployed to an environment iff it carries that environment's tag (allowlist: production, alpha, beta, canary). Items tagged local or depot (and no VIP env tag) are skipped with no warning. Other untagged items are reported and skipped.
Remote var name = item title (e.g. PRC_PLATFORM_SLACK_TOKEN), with no VIP_ENV_VAR_ prefix (that prefix is a local-dev-only shim).
Value resolution: a field labeled exactly with the environment name (e.g. production) overrides the shared credential field. This supports the same title having a different value per environment (either via a per-env field or via duplicate-title items with disjoint env tags).
(title, env) must be unique after tag filtering; ambiguity is a hard error. Items are resolved by 1Password item ID, so duplicate titles are safe.
Always-set strategy. VIP does not expose stored values, so every desired var is written on each run. The sync is non-destructive — remote vars not in the desired state are only deleted with --prune.
Effect timing: remote env var changes take effect on the next deploy.

Auth

System	CI	Local
1Password	`OP_SERVICE_ACCOUNT_TOKEN`	`op signin` (desktop app integration)
VIP	`WPVIP_DEPLOY_TOKEN`	`vip login`

Usage

op signin
npm run sync:vip-env-vars -- canary --dry-run   # preview plan, no changes
npm run sync:vip-env-vars -- canary             # apply

Env overrides: PRC_PLATFORM_VIP_APP (default pewresearch), PRC_PLATFORM_SECRETS_OP_VAULT (default Platform Secrets).

Notes

Deploy wiring (a pre-deploy sync step in deploy-manager/action.yml and build-release.yml, with per-environment 1Password service accounts) is a planned follow-up; the script is currently run manually.
Never echoes secret values; values are piped to vip ... set --from-file via a mode-600 temp file that is removed immediately.

Firebase service account (`private/firebase-service-account.json`)

The Kreait Firebase PHP SDK needs a Google Cloud service account JSON key in WPCOM_VIP_PRIVATE_DIR. That file is never committed. It is generated at local bootstrap and injected into the VIP deploy zip at deploy time.

Script: bin/setup/generate-firebase-service-account.sh --env <env>

npm alias: npm run gen:firebase-sa (writes the staging key for local)

Also included in npm run gen:auth and bin/setup/bootstrap.sh.

Model

One runtime filename: private/firebase-service-account.json (gitignored).
Two keys (write-time selection via 1Password tags) — same Platform Secrets profile as sync-vip-env-vars.sh:
- Two items, both titled PRC_PLATFORM_FIREBASE_SERVICE_ACCOUNT
- One tagged production → prc-app-prod SA in the credential field
- One tagged alpha, beta, canary, local → prc-platform-staging SA
- Value resolution: per-env field override, else credential (same as sync)
CLI mapping: --env production|alpha|beta|canary|local selects by that tag; --env staging is an alias for the non-prod item (tag local).
Env override: PRC_PLATFORM_FIREBASE_SERVICE_ACCOUNT (raw JSON) skips 1Password when set.
Plugin: prc-firebase always reads WPCOM_VIP_PRIVATE_DIR/firebase-service-account.json — no env branching.

These items are for file generation / deploy injection only. sync-vip-env-vars.sh skips PRC_PLATFORM_FIREBASE_SERVICE_ACCOUNT (file-only title) so the JSON is not pushed as a VIP env var.

Cloud Functions deploy key (`PRC_PLATFORM_FIREBASE_DEPLOY_ACCOUNT`)

CI function deploys use a separate service account from the WordPress Admin SDK key. Script: bin/setup/generate-firebase-service-account.sh --purpose deploy.

Item title PRC_PLATFORM_FIREBASE_DEPLOY_ACCOUNT, tag depot only (no VIP env tags). Same rule as other CI-only items.
Fields are GCP project ids from firebase/.firebaserc, not VIP env names: prc-platform-staging (audience/render on alpha/beta/canary), prc-app-prod (audience/render on production), prc-platform-prod (reddit-game and vip-logs on production). The resolved JSON project_id must match the field.
Env override: PRC_PLATFORM_FIREBASE_DEPLOY_ACCOUNT (raw JSON).
Grant roles/iam.serviceAccountUser on PROJECT_ID@appspot.gserviceaccount.com to this deploy account, not to firebase-adminsdk-fbsvc@…. 1st-gen Cloud Functions run as the App Engine default SA. The deployer must be allowed to act as that account.
Restrict 1Password read to the Depot environment service accounts (alpha / beta / canary / production), same ACL as WPVIP_DEPLOY_TOKEN. The default PR-job service account must not read this item.

deploy-firebase-functions.sh calls --purpose deploy. deploy-manager and build-release keep --purpose runtime (default) so VIP zips still get the Admin SDK key.

Auth

Context	How credentials are resolved
Local	`op signin` → `npm run gen:firebase-sa` / `gen:auth` / bootstrap
CI deploy	`OP_SERVICE_ACCOUNT_TOKEN` + 1Password CLI in `deploy-manager` / `build-release`

--strict makes the script fail (instead of warn-and-skip) when credentials cannot be resolved — used by deploy workflows.

Deploy injection

The service account is written after the long-lived artifact is saved and before vip app deploy, so GitHub Release zips and Actions artifacts never contain the private key:

Staging (deploy-manager): compress → upload artifact → generate into wrap_folder/private/ → re-zip → deploy
Production (build-release deploy-to-production): download release zip → unzip → generate → re-zip → deploy

GitHub Environments production, alpha, beta, and canary must define secret OP_SERVICE_ACCOUNT_TOKEN (1Password service account with read access to Platform Secrets). The build-release build job and ship-plugins also need a repo-level OP_SERVICE_ACCOUNT_TOKEN (those jobs have no Environment).

Ops checklist (key rotation / history scrub)

After shipping the generate-at-deploy change:

Create new GCP service account keys for prod and staging; store them as two Platform Secrets items titled PRC_PLATFORM_FIREBASE_SERVICE_ACCOUNT (credential = full JSON): one tagged production, one tagged alpha,beta,canary,local. Leave old GCP keys active until cutover.
Ensure OP_SERVICE_ACCOUNT_TOKEN is set on GitHub Environments production, alpha, beta, canary.
Confirm local: npm run gen:firebase-sa writes private/firebase-service-account.json.
Deploy alpha → beta/canary → production; verify Firebase Admin / audience CLI commands.
Disable/delete the old GCP keys that were previously committed to git.
Separate follow-up: scrub git history for private/firebase-service-account-*.json (git filter-repo / BFG) — coordinate a force-push; lower urgency once keys are rotated.
Close Linear PRC-173 / GitHub #3071 when steps 1–5 are done.

GA4 service account (`private/ga4-service-account.json`)

The @prc/analytics Google Analytics provider calls the GA4 Data API with a Google Cloud service account JSON key in WPCOM_VIP_PRIVATE_DIR. Same model as Firebase: the file is never committed, generated locally / injected at deploy, and not synced as a VIP env var.

Script: bin/setup/generate-ga4-service-account.sh --env <env>

npm alias: npm run gen:ga4-sa (writes the non-prod key for local)

Also included in npm run gen:auth and bin/setup/bootstrap.sh.

Model

One runtime filename: private/ga4-service-account.json (gitignored).
Two keys (write-time selection via 1Password tags) — same Platform Secrets profile as Firebase / sync-vip-env-vars.sh:
- Two items, both titled PRC_PLATFORM_GA4_SERVICE_ACCOUNT
- One tagged production → production GA4 SA in the credential field
- One tagged alpha, beta, canary, local → non-prod GA4 SA
- Value resolution: per-env field override, else credential
CLI mapping: --env production|alpha|beta|canary|local; --env staging aliases to tag local.
Env override: PRC_PLATFORM_GA4_SERVICE_ACCOUNT (raw JSON) skips 1Password when set.
Property ID (separate VIP env var): PRC_PLATFORM_GA4_PROPERTY_ID — defined in vip-config/keys-and-tokens.php via _get_key(). Blank locally until provisioned.
Plugin: prc-analytics reads WPCOM_VIP_PRIVATE_DIR/ga4-service-account.json — no env branching on the JSON path.
Client-side gtag remains PRC_PLATFORM_GOOGLE_GTAG_ID only; unrelated to this server SA.

sync-vip-env-vars.sh skips PRC_PLATFORM_GA4_SERVICE_ACCOUNT (file-only title) so the JSON is not pushed as a VIP env var.

Provisioning checklist

Create a GCP service account with Analytics Data API access; grant Viewer / Analyst on the GA4 property.
Store SA JSON as Platform Secrets items titled PRC_PLATFORM_GA4_SERVICE_ACCOUNT (tags: production vs alpha,beta,canary,local).
Set PRC_PLATFORM_GA4_PROPERTY_ID as a normal VIP env var / Platform Secrets credential field.
Local: npm run gen:ga4-sa → private/ga4-service-account.json.
Deploy workflows inject wrap_folder/private/ga4-service-account.json next to the Firebase SA (deploy-manager, build-release).

Auth

Context	How credentials are resolved
Local	`op signin` → `npm run gen:ga4-sa` / `gen:auth` / bootstrap
CI deploy	`OP_SERVICE_ACCOUNT_TOKEN` + 1Password CLI in `deploy-manager` / `build-release`

Verify with: wp prc analytics ga analyze-post <url> --period_start=30d

BIMI PEM (`private/bimi.pem`)

The prc-bimi MU-plugin serves Brand Indicators for Message Identification (BIMI) material from WPCOM_VIP_PRIVATE_DIR/bimi.pem at /bimi/key (primary site only). That file is never committed. It is injected into the VIP deploy zip at production deploy time only — not alpha, beta, or canary.

Script: bin/setup/generate-bimi-pem.sh --env production

Not included in bootstrap.sh / gen:auth (local and staging do not need BIMI).

Model

One runtime filename: private/bimi.pem (gitignored).
One Platform Secrets item titled PRC_PLATFORM_BIMI_PEM, tagged production, with the full PEM in the credential field (or a production field override). 1Password stores that field as one line (newlines become spaces). generate-bimi-pem.sh re-wraps the value to RFC 7468 PEM before writing private/bimi.pem.
CLI: --env production writes the file. Non-production --env values warn and skip (or fail with --strict).
Env override: PRC_PLATFORM_BIMI_PEM (raw PEM text) skips 1Password when set.
Consumer: client-mu-plugins/prc-bimi/prc-bimi.php always reads WPCOM_VIP_PRIVATE_DIR/bimi.pem.

sync-vip-env-vars.sh and generate-vip-env-vars.sh skip PRC_PLATFORM_BIMI_PEM (file-only title) so the PEM is not pushed as a VIP env var or into vip-env-vars.local.php.

Auth

Context	How credentials are resolved
Local (optional)	`op signin` → `bin/setup/generate-bimi-pem.sh --env production`
CI production deploy	`OP_SERVICE_ACCOUNT_TOKEN` + 1Password CLI in `build-release` `deploy-to-production`

Deploy injection

Written after the long-lived GitHub Release zip is saved and before vip app deploy, same timing as Firebase/GA4:

Production (build-release deploy-to-production): download release zip → unzip → generate Firebase + GA4 + BIMI into wrap_folder/private/ → re-zip → deploy
Staging (deploy-manager): does not inject BIMI

Ops checklist

Create Platform Secrets item titled PRC_PLATFORM_BIMI_PEM, tag production, put the full PEM (including BEGIN/END lines) in credential.
Confirm OP_SERVICE_ACCOUNT_TOKEN on GitHub Environment production can read Platform Secrets (already required for Firebase/GA4).
After the next production release, verify the primary-site /bimi/key (and /bimi/key.pem) endpoint returns RFC 7468 PEM that openssl x509 can parse — not a single-line flattened string, and not the missing-file message.
Expect alpha/beta/canary /bimi/key to report a missing PEM after staging deploys that no longer include a committed file.

Depot CI secrets (Platform Secrets tag `depot`)

.depot/workflows loads secrets from the Platform Secrets vault. Config (non-secret) values come from Depot CI variables (vars.*). GitHub Actions copies under .github/workflows still use GitHub secrets and vars during dual-run.

The only Depot secrets that stay in Depot CI are:

OP_SERVICE_ACCOUNT_TOKEN — bootstrap for op; chicken-and-egg
GITHUB_TOKEN — runner-issued

Named secrets are op item get after 1password/install-cli-action@v4, via .depot/workflows/load-depot-secrets and bin/setup/load-depot-secrets.sh.

Tag rules

Reuse an existing VIP item only when the credential is the same. Add tag depot. Do not remove VIP env tags (production / alpha / beta / canary). The extra tag must not change VIP membership.
New CI-only items get tag depot and no VIP env tags. Env-specific values use field labels (alpha, production, …), not extra env tags.
Never tag a CI-only item with a VIP env. Example: tagging WPVIP_DEPLOY_TOKEN with production would make bin/setup/sync-vip-env-vars.sh try to write that name onto WordPress.
Do not store OP_SERVICE_ACCOUNT_TOKEN in 1Password for this loader.

Item titles

Loader input is a named list of workflow env vars. Titles match those names. Jobs request that named list; they never run op item list --tags depot.

Reuse the existing PRC_PLATFORM_GITHUB_TOKEN item (Composer GitHub OAuth and Depot git/gh bot). Add tag depot. Keep VIP env tags. GitHub Actions copies under .github/ still read secret PRC_PLATFORM_GITHUB_BOT_TOKEN during dual-run; that secret is the same credential.

New items, tag depot only, credential field unless noted:

Secrets: CLAUDE_API_KEY, LINEAR_ACCESS_KEY, PRC_PLATFORM_GITHUB_BOT_USERNAME, SENTRY_RELEASE_TOKEN, SLACK_RELEASE_CHANNEL_ID, WP_ACCESS_TOKEN
Optional: LINEAR_API_KEY (cut already skips if empty)
Per-env fields (no VIP env tags): WPVIP_DEPLOY_TOKEN, PRC_PLATFORM_SLACK_APP_ID, and PRC_PLATFORM_SLACK_APP_CONFIG_TOKEN with labels alpha, beta, canary, production. Leave credential empty so jobs without environment: cannot pick a value.

op signin
bin/setup/load-depot-secrets.sh --check --names \
  CLAUDE_API_KEY,LINEAR_ACCESS_KEY,PRC_PLATFORM_GITHUB_TOKEN,PRC_PLATFORM_GITHUB_BOT_USERNAME,SENTRY_RELEASE_TOKEN,SLACK_BOT_TOKEN,SLACK_RELEASE_CHANNEL_ID,WP_ACCESS_TOKEN \
  --optional LINEAR_API_KEY
GITHUB_ENVIRONMENT=production bin/setup/load-depot-secrets.sh --check \
  --names WPVIP_DEPLOY_TOKEN,PRC_PLATFORM_SLACK_APP_ID,PRC_PLATFORM_SLACK_APP_CONFIG_TOKEN

--check verifies the depot tag and a usable field. It prints names only.

Service account ACL

Repo-level OP_SERVICE_ACCOUNT_TOKEN is available to PR jobs. If that service account can read WPVIP_DEPLOY_TOKEN, a workflow edit can pull production deploy credentials.

Keep using Depot environment variants of OP_SERVICE_ACCOUNT_TOKEN (alpha / beta / canary / production) on jobs that already set environment: (.depot/workflows/deploy-to-staging.yml, .depot/workflows/build-release.yml). In 1Password, grant only those service accounts read on WPVIP_DEPLOY_TOKEN, PRC_PLATFORM_SLACK_APP_ID, PRC_PLATFORM_SLACK_APP_CONFIG_TOKEN, and PRC_PLATFORM_FIREBASE_DEPLOY_ACCOUNT. The default CI service account used by pr-title / changeset-check must not.

Composer and Font Awesome generators still use OP_SERVICE_ACCOUNT_TOKEN the same way as before. This loader only covers Depot workflow secrets.* that are not those two exceptions. Config names use Depot CI variables (vars.*).

Depot CI variables

These names are not Platform Secrets items. Set them in Depot project settings (vars.*). GitHub copies still read the matching Actions variables during dual-run.

LINEAR_PIPELINE_ID — Linear scheduled pipeline ID (planned-release creation)
LINEAR_WORKSPACE_URL — e.g. https://linear.app/pewresearch
STALE_PR_TRIAGE_GITHUB_LOGIN — fallback @ mention for bot-authored PRs
ENVIRONMENT_ALIAS — Depot environment variants: alpha → @pewresearch.alpha, beta → @pewresearch.beta, canary → @pewresearch.canary, production → @pewresearch.production. Jobs that set environment: resolve the matching variant.
Optional flags (omit to keep scheduled jobs dry-run): BRANCH_CLEANUP_LIVE, STALE_PR_DIGEST_LIVE

Vault inventory

--check against Platform Secrets (names and tags only; re-run after vault edits):

Required items, tag depot, usable value: CLAUDE_API_KEY, LINEAR_ACCESS_KEY, PRC_PLATFORM_GITHUB_BOT_USERNAME, SLACK_BOT_TOKEN, SLACK_RELEASE_CHANNEL_ID, WP_ACCESS_TOKEN.

Reuse VIP item: PRC_PLATFORM_GITHUB_TOKEN tags alpha,beta,canary,depot,production. Same credential as GitHub secret PRC_PLATFORM_GITHUB_BOT_TOKEN during dual-run.

Per-env fields, tag depot only (no VIP env tags): WPVIP_DEPLOY_TOKEN, PRC_PLATFORM_SLACK_APP_ID, and PRC_PLATFORM_SLACK_APP_CONFIG_TOKEN resolve for alpha, beta, canary, and production when GITHUB_ENVIRONMENT is set. Staging fields share the staging Slack app; production fields are the production Nexus app. The config token is an app configuration token (xoxe.xoxp-…), not PRC_PLATFORM_SLACK_TOKEN / xoxb.

Optional and absent (keep scheduled jobs dry-run): LINEAR_API_KEY. BRANCH_CLEANUP_LIVE and STALE_PR_DIGEST_LIVE are Depot CI variables; leave them unset.

An OP_SERVICE_ACCOUNT_TOKEN item tagged depot exists in the vault. Do not use it for this loader; Depot CI still injects that secret from Depot.

Remaining ops:

Confirm the default CI service account can read depot items except WPVIP_DEPLOY_TOKEN, PRC_PLATFORM_SLACK_APP_ID, PRC_PLATFORM_SLACK_APP_CONFIG_TOKEN, and PRC_PLATFORM_FIREBASE_DEPLOY_ACCOUNT
Confirm env-specific service accounts can read WPVIP_DEPLOY_TOKEN, the Slack app config items, and PRC_PLATFORM_FIREBASE_DEPLOY_ACCOUNT
After merge, smoke workflow_dispatch on a low-risk Depot workflow (for example release-version dry path or stale-pr-digest dry-run)

Private Font Awesome Registry Auth (.npmrc generation)

When you do need to rebuild sprites

Mechanism

Security notes

Composer Private Credentials (auth.json generation)

Local development (1Password CLI)

CI

VIP Local Environment Variables (vip-env-vars.local.php generation)

Local development (1Password CLI)

CI / non-1Password environments

VIP-CLI Auth (~/.config/configstore/vip-go-cli.json)

Remote VIP Environment Variables (1Password → vip config envvar)

Model

Auth

Usage

Notes

Firebase service account (private/firebase-service-account.json)

Model

Cloud Functions deploy key (PRC_PLATFORM_FIREBASE_DEPLOY_ACCOUNT)

Auth

Deploy injection

Ops checklist (key rotation / history scrub)

GA4 service account (private/ga4-service-account.json)

Model

Provisioning checklist

Auth

BIMI PEM (private/bimi.pem)

Model

Auth

Deploy injection

Ops checklist

Depot CI secrets (Platform Secrets tag depot)

Tag rules

Item titles

Service account ACL

Depot CI variables

Vault inventory

VIP-CLI Auth (`~/.config/configstore/vip-go-cli.json`)

Remote VIP Environment Variables (1Password → `vip config envvar`)

Firebase service account (`private/firebase-service-account.json`)

Cloud Functions deploy key (`PRC_PLATFORM_FIREBASE_DEPLOY_ACCOUNT`)

GA4 service account (`private/ga4-service-account.json`)

BIMI PEM (`private/bimi.pem`)

Depot CI secrets (Platform Secrets tag `depot`)