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
5.4 KiB
5.4 KiB
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/webhookforcustomer.subscription.created,customer.subscription.updated, andcustomer.subscription.deleted, then supplySTRIPE_SECRET_KEY,STRIPE_PRICE_PREMIUM, andSTRIPE_WEBHOOK_SECRETthrough 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, orSTRIPE_WEBHOOK_SECRETenvironment 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.mdanddocs/release-checklist.mdon 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, orPROD_SSH_KEYenvironment configuration is available. A read-only batch SSH probe tojobs.cesnimda.uk:22timed out, so no production operation was attempted.
Legacy job/application column cutover
- Blocked: Removing the opportunity columns duplicated between
JobApplicationandJob. - Why: The compatibility dual-write protects existing production rows and older clients. Dropping columns safely requires proving every production application has a correct
JobIdand 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.