fix: start lifecycle manager in web dashboard to update session status

[sujayjayjay]

Summary

• Integrates the lifecycle manager into the web dashboard's service initialization
• Lifecycle manager now starts automatically when the dashboard loads, polling session status every 30 seconds
• Fixes the root cause: session status was never updated after ao spawn because nothing was calling the lifecycle manager's polling loop

Problem

ao spawn writes status=spawning to the metadata file, but nothing ever updates it afterward. The dashboard shows all sessions as "spawning" indefinitely—even sessions where the agent has been working for hours, created PRs, and gone idle.

Solution

The lifecycle manager already existed in packages/core/src/lifecycle-manager.ts with full logic for:

• Checking if tmux session is alive → status=killed if dead
• Checking agent process activity → status=working
• Checking PR state via SCM plugin → status=pr_open, ci_failed, review_pending, etc.

The fix simply creates and starts the lifecycle manager in packages/web/src/lib/services.ts when services are initialized.

Test plan

• Start the dashboard with ao start
• Spawn a session with ao spawn
• Verify session transitions from "spawning" to "working" within 30 seconds
• Create a PR and verify status updates to "pr_open"
• CI checks should reflect in dashboard status

Closes #79

🤖 Generated with Claude Code

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Lifecycle manager interval never stopped, no cleanup

Low Severity

lifecycleManager.start() creates a setInterval that polls every 30 seconds, but stop() is never called anywhere in the web package and no shutdown handler is registered. The timer in the lifecycle manager is also not .unref()'d, so it keeps the Node.js event loop alive and can prevent graceful process shutdown (e.g., on SIGTERM during deploys). The stop() method exists on the LifecycleManager interface but is never wired to any cleanup path.

 

^{Triggered by project rule: BugBot Configuration}