cesnimda
ce76046a29
- consolidate API ownership and remove dead vendor code - add Stripe billing, learning paths, and public CV hardening - add migration, recovery, security, audit, and browser gates
55 lines
5.4 KiB
Markdown
55 lines
5.4 KiB
Markdown
# Blockers
|
|
|
|
Updated: 2026-07-31
|
|
|
|
## Stripe billing
|
|
|
|
- **Blocked:** Activating roadmap item 7.5 in production.
|
|
- **Why:** Hosted Checkout, customer-portal sessions, signed subscription webhooks, persisted billing state, and Premium-role provisioning are implemented. The Stripe product, recurring price, portal, webhook registration, and production credentials must be created outside the repository.
|
|
- **Required:** Configure the Premium recurring price, enable the Stripe customer portal, register `/api/billing/webhook` for `customer.subscription.created`, `customer.subscription.updated`, and `customer.subscription.deleted`, then supply `STRIPE_SECRET_KEY`, `STRIPE_PRICE_PREMIUM`, and `STRIPE_WEBHOOK_SECRET` through the deployment environment. Do not place secret values in source control or chat.
|
|
- **Recommended:** One monthly Premium price first; add annual billing only after the monthly flow is operating.
|
|
- **Current access check:** No Stripe CLI or `STRIPE_SECRET_KEY`, `STRIPE_PRICE_PREMIUM`, or `STRIPE_WEBHOOK_SECRET` environment configuration is available in this workspace, so activation cannot be performed safely here.
|
|
|
|
## Public registration verification
|
|
|
|
- **Blocked:** Completing a real-browser production signup check.
|
|
- **Why:** The 2026-07-31 anonymous production check confirms `allowRegistration=true`, `turnstileEnabled=true`, and Google sign-in enabled. Completing Turnstile and creating a disposable account requires an interactive production browser session.
|
|
- **Required:** Register one disposable account through Turnstile, verify email/sign-in/rate-limit behavior, then remove the account if it is not needed.
|
|
- **Recommended:** Monitor Turnstile and rate-limit failures during the first public rollout; decide whether free-only onboarding remains open before Stripe activation.
|
|
|
|
## CI runner verification
|
|
|
|
- **Blocked:** Proving that the current release gate completes on the self-hosted runner.
|
|
- **Why:** The workflow now runs the complete backend, frontend, dependency-audit, browser, and production-build checks, but historical runner failures were intermittent and the current working tree has not been submitted to remote CI. Local success cannot prove runner health.
|
|
- **Required:** Submit the reviewed changes and run the Gitea workflow. If it still fails early, inspect the job log and `journalctl -u act_runner`/runner resources on the host.
|
|
- **Recommended:** Keep the full gate intact; fix the runner instead of skipping or filtering tests.
|
|
|
|
## React Router security release
|
|
|
|
- **Blocked:** Clearing the final two moderate React Router package findings without introducing a higher-severity advisory.
|
|
- **Why:** The reported paths affect redirects and SSR hydration. This application uses declarative `BrowserRouter` (not SSR/RSC), and post-login redirects reject protocol-relative and backslash paths. The redirect-fixed React Router 7.18.2 release is itself covered by a high-severity RSC advisory; npm's suggested high-severity fix downgrades to a release that reintroduces the moderate redirect findings. No published version clears both sets.
|
|
- **Required:** Upgrade React Router when a release clears both the redirect/SSR findings and the RSC advisory, then rerun Jest, production build, and Playwright.
|
|
- **Recommended:** Keep 6.30.3 plus the explicit redirect allowlist until that release; do not force an audit-driven major downgrade/upgrade that leaves tests unable to load.
|
|
|
|
## Production DataProtection key rotation
|
|
|
|
- **Blocked:** Closing roadmap item 1.4.
|
|
- **Why:** Keys remain recoverable from git history and can only be rotated on the production host. Rotation invalidates protected payloads/cookies and must be coordinated by the operator.
|
|
- **Required:** Rotate the production DataProtection key ring and confirm completion.
|
|
- **Recommended:** Back up the current key ring securely, rotate during a short maintenance window, then verify login, reset links, and encrypted application data.
|
|
|
|
## Production verification and deployment
|
|
|
|
- **Blocked:** Authenticated production smoke tests, backup restore verification against real data, OAuth-provider checks, and deployment.
|
|
- **Why:** These require production access, real credentials, and operator authorization.
|
|
- **Required:** Follow `docs/release-candidate-review.md` and `docs/release-checklist.md` on the production host.
|
|
- **Recommended:** Verify backup/restore before deployment, then exercise login, existing application counts, Career Workspace, public CV refresh/download, AI, and attachments in order.
|
|
- **Current access check:** No `PROD_HOST`, `PROD_USER`, or `PROD_SSH_KEY` environment configuration is available. A read-only batch SSH probe to `jobs.cesnimda.uk:22` timed out, so no production operation was attempted.
|
|
|
|
## Legacy job/application column cutover
|
|
|
|
- **Blocked:** Removing the opportunity columns duplicated between `JobApplication` and `Job`.
|
|
- **Why:** The compatibility dual-write protects existing production rows and older clients. Dropping columns safely requires proving every production application has a correct `JobId` and rehearsing the migration against a restored backup.
|
|
- **Required:** Provide/authorize a recent production backup restore, verify the backfill report, and confirm that backward API compatibility is no longer required.
|
|
- **Recommended:** Use an expand/contract release: first stop legacy reads after a verified backfill, observe one release, then drop the duplicate columns in the following migration.
|