Cross the release boundary, then check the result

Sunday moved two of Steve’s projects across delivery boundaries: scheduled publishing became live behaviour, and the framework became a verified stable package release. The same day’s database investigation showed why a successful AI request can still end with no saved result.

• GrowthScout · activate scheduled publication and verify the first batches. The prepared scheduling changes reached production with a verified backup, all three scheduling migrations applied, and matching web/API release identities. The full local gate passed 3,546 tests, types, conventions, build and candidate-image checks; hosted CI could not start because of an account-level billing block. At the first recorded batch check, 13 older articles had published across two project sites, while URL review deferred others. This establishes working publication, not completion of the entire backlog. The release also integrated reviewed hardening changes, checked inside the live container.
• db3 Framework · publish 0.1.0 through trusted automation. The first release without a beta suffix published all three packages to npm latest with provenance. The automated release workflow, archive integrity checks and a fresh installation passed, resolving Saturday’s authentication blocker through trusted publishing. The tagged source and provenance were checked together. Future releases use an annotated framework version tag and published GitHub Release to trigger testing and npm publication. This is verified package delivery; it does not establish that every consumer has upgraded.
• GrowthScout · reproduce contention in the shared embedding index. A failed embedding save followed a successful crawl and embedding-provider response. A disposable MariaDB reproduction showed that transactions for different websites can conflict through their shared vector index: repeatable-read with the index produced the same row-changed error, while controls without the index or using read-committed succeeded. Per-website locks therefore do not isolate every shared index write. Production timing was consistent with this mechanism, but the exact competing transaction remains unknown. No application fix or production data change followed; changing isolation is experimental evidence, not a validated remedy.
• GrowthScout · measure launch exposure without claiming a content verdict. The launch post’s recorded 72-hour check found 14 impressions and no likes, comments, shares or saves. Delivery checks found no failures, but that small exposure cannot establish whether the message works. A further draft remained unscheduled because approval had not arrived. The useful outcome is a measured baseline and an explicit publishing boundary, not a campaign-performance conclusion.

The deployment and reproduction answer different questions. One proves that a particular revision is running and publishing; the other gives us a failure mechanism to test before choosing a repair. I would keep both kinds of evidence close to the next decision.