Make the working state survive the next step

Tuesday’s work focused on preserving useful state across boundaries: a connected blog surviving session loading, discovery evidence surviving storage, and routine jobs retaining capacity while article generation runs. Several fixes reached production. The remaining reliability work has passing checks without yet having live proof.

• GrowthScout · a verified blog connection and a usable dashboard. Restored hosted-blog configuration passed real DNS and HTTPS verification, and the blog landing page loaded. Publishing remained deliberately disconnected. A separate client validator had rejected the saved hosted-blog platform value even when authentication succeeded, leaving the dashboard empty. The deployed session fix accepts that value and adds an explicit error with retry. Live user/site loading and recovery behaviour were checked; 106 tests, the build and health checks passed.
• GrowthScout · keep competitor evidence with its URL. A deployed migration changed stored competitors to one { url, evidence } shape. Historical entries retain null evidence rather than invented explanations, and the database reader rejects the old string-array format. Settings and keyword context showed the migrated competitors. Eighty-four focused tests and migration replay passed; fresh discovery and a live save were not exercised. The deployed schema was subsequently reconciled into main.
• GrowthScout · protect routine work from expensive queues. Queue isolation was merged and deployed: one worker excludes article and image jobs, four shared workers can process all queues, and a dedicated image worker remains. This reserves capacity for other work while keeping spare shared capacity available. Focused tests, the build, public health and all three queue heartbeats passed. At the recorded check, an old worker was still finishing a crawl and cleanup was waiting gracefully; full CI was still running.
• GrowthScout · reliability fixes ready for review. One pending PR retries embedding publication once using already-generated vectors and reports tracking failures without exposing request content. Another records when a worker lane first enters monitoring, preventing an immediate overdue alert before its first canary while retaining alerts for stale completions. Their final Scout CI runs passed 3,047 and 3,048 tests respectively. Neither was deployed in the recorded window, and the production database lock holder remained unknown.
• GrowthScout · release from an identifiable source. The deployed release process now requires clean, committed, merged main. This followed reconciliation of changes that had reached production separately. Local checks and live web/API revision and health verification passed. GitHub CI was not a deployment gate in this change, so the new source rule should not be read as proof that every release passed every remote suite.
• DOM Studio · checkout no longer depends on email setup. The pricing-page checkout path was separated from licence-email configuration. Both purchase buttons were deployed and verified in a live browser to open the correct Stripe payment page. No payment was submitted. Licence emails and email-based account setup still needed configuration, keeping successful redirection distinct from the full purchase-and-delivery journey.
• db3 · a concrete path to workers on another machine. The infrastructure review concluded that the existing database queue already supports multiple workers through atomic claims, renewable reservations and coordinated rate limits. The proposed first step is a worker-only second host, private database connectivity and shared object storage. Deployment profiles, existing media migration, remote notification access and coordinated releases still need work. This was a documented implementation sequence, not a provisioned multi-host system.