1 · Pre-flight security hygiene (P0)

TL;DR

Objective — confirm the Phase 10 consolidated verdict allows production, rotate every test-mode key and non-production password that touched a chat or log, vault plaintext credentials, re-scope over-privileged service accounts, and record the audit, so no convenience credential from iteration becomes a liability the moment real traffic arrives.

Steps at a glance:

1. Rotate every test-mode payment key — Roll each key that appeared in chat or log history, then revoke the old value at the source.
2. Rotate all non-production-side passwords — SMTP, database, and hosting-panel credentials — and any password that lived in a plaintext file.
3. Migrate plaintext credentials into a real secrets manager — Move every secret into the appropriate vault, then replace the plaintext store with pointers (or delete it and .gitignore it).
4. Re-scope over-privileged service accounts — Narrow each API key and the deploy user to the minimum permissions they actually need.
5. Record the audit — Capture what changed so the rotation is auditable later. An agent can draft this record from your notes.

User part + done-when

🔀 User part — 👤 credentials and authorization stay human-owned: gateway passwords, secret values, paid/provider approvals, and production dashboard access. 🤖 With an authorized browser or API token, the agent drives non-secret console navigation, prepares rotations, captures evidence, updates the audit record, and verifies revocation without printing any secret.

Done when the Phase 10-CONSOLIDATED verdict is 🟢 GO or explicitly accepted 🟡 CONDITIONAL GO, all test-mode keys + non-production passwords are rotated (old values revoked), plaintext credentials live in a vault, service-account scopes are minimized, and the audit summary is committed.  ·  ⏱ ~45 min  ·  🔀 mixed (👤 secrets/authorization, 🤖 provider-console audit after auth).

Background

Never skip this. Every production deploy starts here. Non-production and production are different security contexts: credentials that were convenient during iteration become liabilities the moment real traffic arrives.

Read the production row in Zaj-PROJECT.md before rotating or deploying anything. It must name the production URL/domain, hosting account, SSH alias, host/user/port, deploy target, source branch, DB name, web PHP, CLI PHP binary, credential pointer, noindex/robots posture, and last verified date. If any value is missing or stale, stop here and update the row before touching production.

Before reporting SSH access as blocked, inspect the operator’s existing machine config and test the recorded alias:

grep -nE '^Host |HostName|User|Port|IdentityFile' ~/.ssh/config 2>/dev/null
SSH_PRODUCTION_ALIAS="<production-alias-from-Zaj-PROJECT>"
PHPBIN="<production-cli-php-from-Zaj-PROJECT>"
ssh -o BatchMode=yes -o ConnectTimeout=8 "$SSH_PRODUCTION_ALIAS" "pwd && $PHPBIN -v | head -1"
# Expected: exit 0; alias/host/user/port match the production row

Treat anything pasted into an agent as compromised

AI chat transcripts may be logged, cached, or backed up by the harness or any intermediary. Any key, password, or token that appeared in a chat or log should be considered exposed and rotated before production goes live — regardless of whether the session was “private”.

Set the production Admin-Server posture before deploy

The production server’s monitoring agent must run in production mode, not a leftover staging posture. In ~/Admin-Server/config/server.env on the production host, confirm:

• SERVER_ENV="production" — drives the production alert prefix and standard palette.
• DIAGNOSTIC_MODE="false" — terse alerts, no debug noise.
• REDACT_PATHS="true" — masks $HOME in alert payloads (privacy + security).

If any still carry staging values (SERVER_ENV="staging", DIAGNOSTIC_MODE="true"), fix them before the production deploy, then confirm the displayed posture:

ssh <SSH_PRODUCTION_ALIAS> '~/Admin-Server/scripts/status.sh'
# Expected: ENV/REDACT/DIAGNOSTIC show production · true · false

Then re-run the shared-hosting liveness probe from the shared-hosting setup page. Production cannot deploy on a presence-only Admin-Server: cron-backed logs must be fresh with no STALE rows, monitored-paths.conf must include ~/.ssh/authorized_keys plus the production app path, and at least one production ops alert channel must pass a synthetic alert before you trust production monitoring.

Steps

Task P.0 — Verify the Phase 10-CONSOLIDATED verdict

Before rotating secrets or preparing the production release, prove the pre-launch verdict allows Phase 12 production to start.

Entry gate (Task P.0)

Phase 12 production is blocked unless the Phase 10-CONSOLIDATED verdict (Admin-Local/1-Project/4-Audit-Reports/...-phase-10-CONSOLIDATED.md) is 🟢 GO or an explicitly accepted 🟡 CONDITIONAL GO. 🔴 NO-GO = hard block, no exceptions. A missing verdict = STOP — deploy nothing.

1. Open the latest consolidated verdict and confirm the decision line is 🟢 GO or explicitly accepted 🟡 CONDITIONAL GO. If the report is missing, incomplete, or 🔴 NO-GO, stop before touching production.

   • ✅ The consolidated verdict exists and clears Phase 12 production to start.

2. Verify the production row in Zaj-PROJECT.md. Confirm production URL, deploy target, SSH alias, DB name, web PHP, CLI PHP binary, credential pointer, and last verified date are current. Re-run the SSH alias proof above.

   • ✅ Zaj-PROJECT.md has a current production row and SSH proof.

3. Verify production DNS + origin TLS before any deploy step. If Cloudflare is in front, this prevents the broken public state where production is orange-clouded but the current origin has no valid certificate.

   PROD_DOMAIN="<production-domain-from-Zaj-PROJECT>"
   EXPECTED_ORIGIN_IP="<production-origin-ip-from-Zaj-PROJECT>"
   
   dig +short "$PROD_DOMAIN" A | grep -Fx "$EXPECTED_ORIGIN_IP"
   curl -sI "https://$PROD_DOMAIN" | head -1
   echo | openssl s_client -connect "$PROD_DOMAIN:443" -servername "$PROD_DOMAIN" 2>/dev/null \
     | openssl x509 -noout -subject -issuer -dates
   # Expected: DNS matches the current origin; HTTPS is not 525; cert is valid and not expired

   If dig returns an old IP, stop — Cloudflare is talking to the wrong box. If Cloudflare returns 525, stop — issue the origin cert first (use DNS-only/grey cloud if Hostinger AutoSSL needs direct validation), then re-proxy and use Full (Strict).

   • ✅ Production DNS points at the current origin, origin TLS is valid, and Cloudflare is not returning 525.

1. Rotate every test-mode payment key

Roll each key that appeared in chat or log history, then revoke the old value at the source.

Who does this

🔀 User + Agent — 👤 the user owns login, secret reveal/copy, and final revocation authorization. 🤖 With an authorized browser session, the agent can navigate the gateway dashboard, identify each key to rotate, and verify the old key is revoked. Use vendor console automation for the safe browser pattern.

1. Roll each test-mode key in the gateway dashboard, update the affected non-production environment row/secret with the new value, and revoke the old key.

   • ✅ Every test-mode key is rotated and the old keys are revoked at the source.

2. Rotate all non-production-side passwords

SMTP, database, and hosting-panel credentials for any non-production environment — and any password that lived in a plaintext file.

Who does this

🔀 Authorized agent + user gate — 👤 User owns new password values, provider login, 2FA, and final rotation approval. 🤖 With an authorized browser/API session, the agent may navigate to the rotation screens, verify which accounts need rotation, capture non-secret evidence, and update Zaj-PROJECT.md/Zaj-BACKLOG.md; pause before any password entry or destructive revoke.

If an agent assists inside provider consoles after the user logs in, use the vendor console automation guide: the user owns login, password entry, and secret-copy moments; the agent can navigate, verify state, and prepare non-secret fields.

1. Rotate the non-production-side passwords — SMTP, database, hosting-panel, and anything that lived in a plaintext file.

   • ✅ All non-production-side passwords are rotated.

3. Migrate plaintext credentials into a real secrets manager

Move every secret into the appropriate vault, then replace the plaintext store with pointers (or delete it and .gitignore it).

Who does this

👤 User moves the secrets into a password manager / vault and removes the plaintext store.

1. Move every secret into the appropriate vault, then replace the plaintext store with pointers — or delete it and .gitignore it.

   • ✅ Plaintext credentials are replaced with vault pointers (or deleted + gitignored).

4. Re-scope over-privileged service accounts

Narrow each API key and the deploy user to the minimum permissions they actually need.

Who does this

🔀 Authorized agent + user gate — 👤 User approves the final minimum-permission scope set and any provider login/2FA. 🤖 With an authorized browser/API session, the agent may inspect current scopes, propose the least-privilege change, apply non-secret toggles after approval, and verify the resulting scopes; pause for any live-money, production-access, or account-owner confirmation.

For provider console navigation, use the vendor console automation guide and keep final authorization/scope approval human-owned.

1. Narrow each API key and the deploy user — payments, analytics, error tracking — to the minimum permissions they actually need.

   • ✅ Every service-account scope is narrowed to the minimum.

5. Record the audit

Capture what changed so the rotation is auditable later. An agent can draft this record from your notes.

1. Write the audit summary in your customizations log — what was rotated, what moved to the vault, what was re-scoped, and any accepted exceptions with the reason.

   • ✅ The audit summary is committed.

Checklist

Do not mark this step done until every box below is checked.

• 🔀 Entry gate (Task P.0) — Phase 10-CONSOLIDATED verdict exists and is 🟢 GO or explicitly accepted 🟡 CONDITIONAL GO; 🔴 NO-GO or missing verdict means deploy nothing.
• 🤖 Production row verified — Zaj-PROJECT.md records current production URL/domain, SSH alias, deploy target, DB name, web/CLI PHP, credential pointer, and last verified date; SSH alias proof exits 0.
• 🔀 Test-mode keys rotated — every test-mode payment key rolled; old keys revoked at the source; user owns secret values and provider authorization.
• 🔀 Non-production passwords rotated — SMTP, database, and hosting-panel credentials all changed; user enters new passwords, agent verifies non-secret evidence.
• 🔀 Credentials vaulted — plaintext secrets replaced with vault pointers (or deleted + gitignored); user owns secret capture, agent records pointers.
• 🔀 Scopes minimized — every API key and the deploy user narrowed to minimum permissions; user approves final scopes, agent verifies the resulting state.
• 🔀 Audit recorded — rotation/move/re-scope summary committed to the customizations log.

→Next step

Release & deploy