Daily note
Finish the path to production
Scout recovered failed articles and connected its public blog, db3 shipped bounded progress delivery and blog links, and new advertising stayed paused pending review.
- WebSockets
- AI agents
Tuesday closed several gaps between work being saved and work being usable. Across Steve’s projects, article recovery reached production, publishing gained a working public destination, and previously local crawler and progress safeguards joined a verified release. Advertising and a small camera prototype reached more limited, explicitly unfinished stages.
Publishing flow
A snapshot, a page, then a live check
GrowthScout’s Content API publishing path keeps editable work separate from the version readers can see.
Content API adapter
Save the publication
Successful publication stores a sanitised snapshot, separate from the editable article, and marks the article published.
Public website
Render the snapshot
The API feeds the server-rendered blog and article pages. Readers receive published content without depending on the editor.
Queued verification
Check the live URL
A subsequent check verifies the public page. Publication does not wait for that check to create the page it needs to inspect.
Publication makes content available; verification provides evidence that the public URL serves it.
- GrowthScout and db3 · recover articles without replaying completed tools. A deployed agent fix preserves provider-stop diagnostics instead of misreporting a deadline, and retries eligible rejected model requests without repeating tools that already completed. Four failed article runs were recovered as saved drafts with images; one needed a further retry before saving. The original discarded provider error remains unknown. Validation recorded 963 framework tests and 3,464 Scout tests, followed by completed recovery jobs and green production health. These were recovered drafts, not four published articles.
- GrowthScout · connect automatic publishing to the public blog. The marketing blog now reads the production publication feed, with server-rendered article content, structured data, RSS and sitemap support. Content API settings gained an editable public blog URL. Automatic publishing uses the same fresh URL check and publication operation as manual Publish, removing the stale-check skip. Sixty focused tests passed, the settings form was verified in production, and the final release check found three live articles. Scheduled publishing still does not bulk-publish older drafts.
- GrowthScout and db3.ai · make published content easier to find. Hosted-blog cards gained featured-image thumbnails, with nine image loads checked in the live verification. Marketing contact links were corrected, and db3.ai gained visible Blog links to its hosted publication, including a checked mobile layout. The combined release put both sites on the same verified revision with healthy services. GitHub’s broader Scout check subsequently completed successfully that afternoon; the framework workflow on that revision was skipped, so it is not counted as a passing framework suite.
- GrowthScout and db3 · put bounds around live progress. The release completed the safeguards that were local on Monday. Each website job permits up to 32 in-flight progress publications and retains only the latest unsent snapshot under pressure, including terminal state. The shared WebSocket layer also limits pending sends before authorization; overloaded connections disconnect instead of building an unlimited backlog. Saved job state remains authoritative. The combined checks included 69 Scout tests, 52 WebSocket tests and an overload regression for stalled delivery, plus types, packaged-consumer checks and production builds.
- GrowthScout · stop treating protected email links as broken pages. A small shared crawl-link rule now excludes Cloudflare’s email-protection endpoints from both page discovery and broken-link checks. Ordinary missing pages remain reportable. The earlier website-level opt-out was removed, retaining email protection while fixing the crawler’s interpretation. Sixty-six focused tests, types and conventions passed before the rule joined the combined deployed release. Existing findings still need a successful recheck to clear; deployment alone does not rewrite their history.
- GrowthScout · save six ads across three product needs. Six ads were created across AI visibility and tracking, automated content marketing, and the Scout marketing agent. The saved copy, approved artwork and per-ad UTM parameters were checked. All six ads and all three groups remain paused and await platform review. This is completed campaign preparation, with no delivery, spend or conversion outcome claimed.
- Dog Monitor · build a local camera-viewer prototype. An isolated macOS app and phone-friendly viewer provide camera/audio controls and short check-in sessions. Six relay tests and local UI checks passed, and a temporary remote-access route was started. macOS camera and microphone consent remained outstanding, while the remote browser check was blocked. The result is a built prototype; a working live feed and remote viewing were not verified.
The release reconciliation also produced a practical workflow recommendation: use main for a single active stream, reserve worktrees for parallel work, and give one owner responsibility for integration and deployment. A shared command showing what is local, merged and actually live remains proposed. My useful takeaway is that a green check needs an identity: which revision, which application, and which part of the journey it proves.