jobtrackingapp/BLOCKERS.md

Blockers

Updated: 2026-08-15

Stripe billing

• Blocked: Activating roadmap item 7.5 in production.
• Why: Hosted Checkout, customer-portal sessions, signed subscription webhooks, persisted billing state, and Pro-role provisioning are implemented. The Stripe product, recurring price, portal, webhook registration, and production credentials must be created outside the repository.
• Required: Configure the Pro 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, the recurring price_... value in the legacy-named STRIPE_PRICE_PREMIUM setting, and STRIPE_WEBHOOK_SECRET through the deployment environment. Do not place secret values in source control or chat.
• Recommended: One monthly Pro price first; add annual billing only after the monthly flow is operating.
• Current access check: Production has test-mode secret and webhook values, but STRIPE_PRICE_PREMIUM currently contains a prod_... Product ID. Checkout requires the recurring price_... Price ID. The publishable key is not used by hosted Checkout.
• Runbook: Follow docs/operations/stripe-activation.md, completing test mode before creating or installing live-mode values.

Document parser dependency and isolation

• Blocked: SEC-006 dependency remediation and the dependent SEC-007 parser-isolation package.
• Why: The repository contains reachable parser advisories. Resolving compatible fixed versions and proving the new environment requires package-index access, which repository policy does not authorize implicitly. SEC-007 deliberately follows that compatibility update so isolation is tested against the actual fixed stack.
• Required: Explicitly authorize package-index/internet access for the parser dependency resolution. No production data or malicious sample is required.
• Recommended: Resolve and hash compatible versions first, run the benign extraction corpus and audit, then implement bounded child-process/container isolation against that exact environment.

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; keep email verification required.
• Current status: Production returns allowRegistration=true, turnstileEnabled=true, googleEnabled=true, and microsoftEnabled=false. A registration request without a Turnstile token is rejected with HTTP 400. SMTP is configured and enabled. The operator reports AUTH_REQUIRE_EMAIL_VERIFICATION is now enabled; the disposable interactive signup is still required to prove the deployed behavior end to end.

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: After the current pull request passes CI and is approved, follow docs/release-candidate-review.md and docs/release-checklist.md on the production host. Confirm the admin-only version badge matches the deployed commit, then run the authenticated application workspace, Career, CV, attachment, email-verification and rollback checks.
• 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: Read-only SSH access is confirmed to the LAN production host as both root and pi using the existing id_ed25519 identity. All four containers are healthy and the host has 44 GB free. No production change or deployment was attempted.
• Current status: Anonymous production checks confirm the frontend and /api/auth/config return HTTP 200. The public /health path currently returns the SPA HTML shell; the release branch proxies that exact path to the backend and includes a regression test. Gitea PR 28 exists and an earlier complete PR gate passed; the newest local checkpoint still needs its remote CI run after push. The current local release matrix passes, including Chromium 9/9. React Router is now 7.18.2 and the recorded local dependency audit is clean, so the superseded router/runner blockers were removed.

Account deletion retention and restore policy

• Blocked: Enabling SEC-009 self-service deletion in production and declaring backup erasure complete.
• Why: Repository code can implement a readable export and idempotent live-data deletion behind a disabled gate, but it cannot truthfully choose legal retention periods, backup expiry, provider obligations or the tombstone lifetime needed to prevent restoration from resurrecting an erased account.
• Required: Decide retention periods for operational backups, audit/security records and deletion tombstones; identify any legal hold/export obligations; approve the restore behavior for deleted identities.
• Recommended: Keep production self-service deletion disabled until a restored-backup rehearsal proves that tombstones suppress resurrection. Continue repository export/deletion implementation with explicit retention metadata and no automatic backup deletion.

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. The release branch now backfills missing opportunities on startup, synchronizes both creation paths, and leaves all legacy columns intact. Dropping columns still requires production validation and an observation release.
• Required: After deployment, run the read-only report in docs/operations/job-opportunity-cutover.md against production and a restored backup, then 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.