Starlight Part 3: The Autonomous Era — Headless CI/CD and Mutation Fingerprinting

Stability Sensing: Knowing When the Page is Ready ## One Command to Run Everything ## The No-Code Recorder ## What's New in v3.0.1 ## When to Use Starlight ## What's Next for Starlight ## Next Steps In Part 2: Mission Control, we explored the visual dashboard that lets you monitor the Starlight constellation in real-time. But in practice, most enterprise automation runs in CI/CD pipelines, headless, in the background. This is Starlight v3.0: The Autonomous Era. We've moved beyond visibility. The constellation can now sense its environment and run without human intervention. The upgraded Starlight Mission Control — Visualizing stability in real-time. The hardest problem in browser automation isn't clicking a button—it's knowing *when* to click. Traditional scripts use arbitrary waits like wait\_for\_timeout(3000), which are either too slow or too fast. Starlight v3.0 introduces Mutation Fingerprinting to solve this. When you record a test using the built-in recorder, Starlight doesn't just capture your clicks. It also measures how long the page takes to "settle" after each action using the browser's MutationObserver API. For example, if a page needs 450ms of DOM silence before it's truly stable, that timing is saved with the action. During playback, the Pulse Sentinel uses this data to wait exactly the right amount of time—no more, no less. Temporal Intelligence Temporal Intelligence The result: Tests that are fast when they can be, and patient when they need to be. Running a multi-agent system used to mean opening multiple terminals: one for the Hub, one for each Sentinel, and one for your test. That's a lot of moving pieces. With v3.0, we've simplified this to a single command: The CLI Orchestrator handles the lifecycle automatically: This makes Starlight straightforward to integrate into GitHub Actions, GitLab CI, or any CI/CD pipeline. The test recorder has been upgraded with an in-browser HUD (Heads-Up Display). When you start a recording from Mission Control, a small floating panel appears on the page. This lets you create tests by interacting with your site normally, while adding semantic meaning where it matters. The latest patch fixed an issue where the checkpoint and stop buttons in the HUD weren't responding. The fix involved: These are the kinds of edge cases you discover when building automation tools—the automation framework was automating away its own UI dialogs. Starlight is designed for complex, dynamic web applications where: For simple, static sites, traditional automation tools work fine. Starlight shines when the environment is unpredictable. Observability & Telemetry (Phase 10) OpenTelemetry integration for Datadog/Grafana, Slack/Teams webhooks, and SLA dashboards. Natural Language Intent (Phase 13) Plain English test writing, Gherkin support, and auto-generated BDD scenarios. Sentinel Marketplace (Phase 15) Community registry for custom Sentinels and one-command installation. The foundation we've built—the Hub, Sentinels, and the Starlight Protocol—is designed to be extensible. The marketplace will let teams share solutions for common obstacles (cookie banners, CAPTCHA handlers, login flows) rather than solving them from scratch. Built with ❤️ by Dhiraj Das The mission is autonomous. The value is measurable. The future is visible. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse CODE_BLOCK: node bin/starlight.js test/my_mission.js --headless Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: node bin/starlight.js test/my_mission.js --headless CODE_BLOCK: node bin/starlight.js test/my_mission.js --headless - Starts the Hub and waits for it to be ready - Launches the Sentinels (Pulse, Janitor, etc.) - Runs your test - Generates the report and cleans up - Tag Next Click: Give a meaningful name to your next action (e.g., "Login Button" instead of a raw selector) - Add Checkpoints: Insert named markers like "Cart Updated" to track logical milestones - Stop Recording: End the session and save the generated test file - Replacing browser-native dialogs (which Playwright intercepts) with in-HUD controls - Ensuring recording functions are available before page navigation - Using a fresh browser instance for each recording session - Pages have frequent DOM changes (animations, lazy loading) - Unexpected popups and modals appear - Selectors change due to dynamic IDs or framework updates - You need detailed reports showing what happened during a test - Clone the repository - Run npm install and pip install -r requirements.txt - Start Mission Control: node launcher/server.js - Open http://localhost:3000 and explore