Clean stale Railway checks and add phased improvement plan

[Convospanai-outreach]

Context

The stale Railway project illustrious-warmth has been handled in the Railway dashboard, but GitHub still shows historical Railway status contexts on existing commits.

Latest inspected main commit before this issue:

bbd3d472f64ccc9c6ca52be50ddc651bd33d6e73
Merge PR #37: codex/post-pr35-merge-release-gate

Observed GitHub status contexts on that commit included both active airy-balance Railway services and stale illustrious-warmth Railway services. airy-balance is the active/canonical Railway project. illustrious-warmth should no longer appear in required release checks.

Primary task

Create a focused PR to document and verify stale Railway check removal from GitHub release gates.

Investigate

1. Re-check latest main commit statuses after the Railway dashboard cleanup.
2. Confirm whether new commits still receive any illustrious-warmth Railway status contexts.
3. Confirm whether GitHub branch protection still lists any stale required status checks:
   • illustrious-warmth - convospan-api-split
   • illustrious-warmth - convospan-full-scaffold
4. Confirm the active Railway contexts that should remain:
   • airy-balance - convospan-api-split
   • airy-balance - convospan-full-scaffold
5. Clarify that historical commit statuses may remain visible on old commits, but should not appear on new commits once stale GitHub deploy triggers are disconnected.
6. If branch protection cannot be read or changed from the available tooling, document the exact manual GitHub UI steps required.

Manual GitHub UI steps to document if required

Repo Settings > Branches > main > Branch protection rule > Required status checks

Remove stale required checks:

illustrious-warmth - convospan-api-split
illustrious-warmth - convospan-full-scaffold

Keep active required checks only if they are intended release gates:

airy-balance - convospan-api-split
airy-balance - convospan-full-scaffold
Vercel
CI / Web Build (apps/web)
CI / API Strict Typecheck (apps/api)
Production Readiness Gate / Production Stability Audit (apps/web)
Vercel Parity Build / vercel-parity-build
CodeQL checks
Supabase Preview
Register Docker Images to GHCR / build-and-push, only if GHCR publishing is required for release

Second task: add next phased improvement plan

Create a phased plan for the next production-readiness improvements after CI/deploy gate cleanup.

Required plan sections:

Phase 1: Release gate cleanup

• Remove stale illustrious-warmth checks from required GitHub checks.
• Confirm airy-balance is canonical Railway project.
• Confirm GHCR build-and-push policy: required release gate or optional image publication.
• Verify latest main has no stale duplicate Railway failures.

Phase 2: API origin and proxy readiness

• Confirm exact production backend API origin from active Railway API service or custom API domain.
• Document whether API_INTERNAL_ORIGIN should be set in Vercel production.
• Do not guess or set env values from code alone.
• Verify /api/proxy does not recurse and points to the correct backend when configured.

Phase 3: Production smoke and approval-route validation

• Re-run custom-domain smoke on https://www.craftmyfunnel.live.
• Confirm public pages render with no login redirect.
• Confirm public pages no longer emit unnecessary /api/auth/session client calls.
• Confirm approval/legal pages show correct support email and no old email values.

Phase 4: Database schema readiness without production mutation

• Do not run production migrations.
• Reconfirm current live DB drift evidence.
• Prepare a non-destructive migration sequencing plan for missing Clerk/invite schema.
• Keep destructive DELETE FROM "EdgeNode" migration quarantined until separately reviewed.

Phase 5: PR #6 decomposition

• Do not merge PR Gmail business mail control #6 as-is.
• Split PR Gmail business mail control #6 into small reviewable PRs:
  • schema-safe slice
  • Gmail/mailbox control slice
  • UI slice
  • API integration slice
  • docs/audit slice
• Ensure each slice has validation and no cross-cutting schema/env surprises.

Phase 6: controlled beta readiness package

• Produce a final readiness matrix.
• List all still-blocking external dashboard values.
• List launch blockers vs beta blockers.
• Do not claim production readiness unless every gate is green and DB/env blockers are resolved.

Files to add/update

• docs/audits/stale-railway-check-removal.md
• docs/plans/next-phased-production-improvements.md
• docs/codex/WORKFLOW_STATE.md

Validation

Run safe checks only:

npm run typecheck --workspace apps/web
npm run typecheck --workspace apps/api
npm run build --workspace apps/api

Run web build only if time allows and record duration honestly:

npm run build --workspace apps/web

Hard constraints

• Do not touch DB schema.
• Do not create Prisma migrations.
• Do not run production migrations.
• Do not change Supabase production data.
• Do not change Vercel/Railway/Clerk/Redis secrets or env values.
• Do not touch PR Gmail business mail control #6 except to document the decomposition plan.
• Do not run destructive SQL.
• Do not disable security checks silently.
• Do not claim production readiness.

Expected PR title

Document stale Railway check cleanup and phased improvement plan