Keep the work when the process stops

Scout gained deployed scheduler catch-up and one-time keyword rank collection that releases the worker while results are pending. Alongside those production changes, local db3 demonstrations made bookings inspectable, restored a Scout environment and ran the starter inside Electron. The common engineering question was what survives when a process pauses, restarts or moves somewhere else. The useful answers came from saved state and explicit ownership.

• db3 Studio · booking behaviour. The booking demonstration made that question visible at application level. Customers, classes and bookings were connected to an activity view; duplicate bookings were rejected, and a simulated failed confirmation could be retried without creating another booking. SQLite held the data. Three tests, build checks and a browser walkthrough supported that small demonstration. Email remained simulated, and authentication, AI and cloud workspaces were outside it. A working retry showed one behaviour clearly without proving the wider Studio architecture.
• GrowthScout · thirty prepared topics. Scout’s preparation policy expanded from seven upcoming items to all thirty, including trials. Matching completed research could be reused, repeated passes avoided duplicate jobs, and an unused worldwide search-volume lookup was removed. The writing allowance remained three trial articles. Preparing evidence and consuming a writing allowance are different operations, and keeping them separate made the policy easier to explain. That Tuesday implementation passed local checks; past-dated empty items still needed a separate backfill.
• GrowthScout · scheduler catch-up. The scheduler exposed a less visible version of the same problem. Queue insertion takes time, so evaluating only the current minute can miss work that became due during insertion. The deployed fix evaluates every elapsed minute and keeps each job attached to its original due time. A controlled clock advanced thirteen seconds per enqueue: ten initial jobs and two later jobs were each queued once and completed against a real database and queue. A crash between claiming and enqueueing still needed reconciliation. Catching up elapsed time and recovering every partial operation are separate guarantees.
• GrowthScout · resumable rank collection. Rank collection then gave waiting a proper state. Preparation saves the provider task ID, releases its worker and resumes after sixty seconds to check that same request. Deliberate waits do not consume failure retries or buy another lookup. A configurable forty-five-minute deadline allows preparation to continue with a warning. The deployment check found 202 saved baselines; that is an observation from the check, not a running total. Recurring tracking remained future work. The later article display also required the saved ranking URL to match the article, preventing another page’s position from becoming this page’s success.
• db3 · recovery and desktop experiments. Recovery and desktop work tested different boundaries. The corrected local recovery drill restored source, database and uploads and passed readiness checks; recovery on another host remained unfinished. Sunday’s Electron experiment reused the starter’s existing Vue client and API. One edit appeared in Chrome and Electron, login survived a desktop restart, notes persisted and browser inbox changes reached desktop over WebSocket. The macOS bundle still connected to local Vite and lacked distribution signing and notarization. Those are useful prototype results with specific next steps.
• DOM Studio · previews and demonstrations. DOM Studio explored ownership at component scale. Its local font picker reused the combobox and requested preview fonts for the selected family and current results. Metadata stayed lightweight; the component owned its stylesheet lifecycle. Focused tests and the build passed, while the selected Saturday record left browser verification unfinished. The homepage demonstrations also became more hands-on, with Kanban, filtering and a poster designer. These examples help explain a library through behaviour, provided the demonstration’s limits stay visible.
• db3 · readable development logs. The shared logger now shows pending requests with elapsed time, grouped request/response blocks, readable JSON and coordinated Vite/API output. Production and file logs retain structured JSON. The local change passed 829 framework tests, with eight Redis tests skipped, plus launcher, type and package checks.
• GrowthScout · consistent competitor discovery. Onboarding and settings now share suggestion handling, exclusions and hover/focus explanations. Loading more retains earlier suggestions. Explanations remain session-only, so saved competitors do not gain them retrospectively. Thirty focused tests, type checks and the SPA build passed; this fix was not deployed.
• GrowthScout · typography controls. Font and weight controls share a row, font names preview their typefaces, and the large sample follows the selected family and weight. Default and weights 100–900 preserve existing custom values. Desktop/mobile layouts, keyboard selection, thirteen tests and build checks passed locally; this was not deployed.

My takeaway is to make the durable record explicit before adding another process around it. A provider task ID, scheduled minute, booking or session gives a restart something concrete to resume. The remaining work follows the same principle: reconcile interrupted claims, prove recovery on another host and finish browser lifecycle checks. The selected notes cover all seven days, but they are not a complete inventory of Steve’s work; release coverage and unfinished checks remain limited to the recorded observations.