refactor: program folders export a config with no screens

[gewenyu99]

Phase 2 of Release C (#1320), PR 4 of 16, after #1379. Review PR. PRs 1 to 14 of this phase split one change into reviewable pieces and compile only as a stack: review them one by one, then land the whole phase together.

Problem

On main, each program folder builds its own TUI steps, calls getUI() for log lines and detected labels, and ends the process with wizardAbort. So no program runs without a UI.

Changes

• Each program's index.ts exports config: ProgramConfig in place of a named config such as posthogIntegrationConfig, with no steps. metrics, ai-observability, replay-vision and error-tracking state their own binding.
• A decided stop throws ProgramAbort instead of calling wizardAbort, in error-tracking, replay-vision and posthog-integration.
• The getUI() calls go. Each framework returns its label from getDetectedFrameworkLabel, and the Vercel environment upload and the audit ledger watcher take the runner context.
• Detection in posthog-integration, replay-vision, error-tracking and self-driving hands the framework's label to noteDetectedFramework, so a CI run prints the variant again, as on main.
• The project pick and composed runs move into runSteps: targetDir and onRunPrep for error tracking, runProgramId: 'posthog-integration' for self-driving. Detection that scans with runAgent gains onProgress.
• Focus on error-tracking, self-driving and replay-vision, which change most. The framework files move their label into getDetectedFrameworkLabel or only update imports.

Test plan

• This tree does not compile alone. On the top of the stack (docs: bring docs, readmes and skills in line with the layers #1392): pnpm typecheck 0 errors, pnpm lint 0 errors, 3,515 tests pass, pnpm build ok.

Created with PostHog Desktop

[github-actions]

🧙 Wizard CI

Run the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands:

Test all apps:

• /wizard-ci all

Test all apps in a directory:

• /wizard-ci ai-observability
• /wizard-ci basic-integration
• /wizard-ci feature-flags
• /wizard-ci mcp-analytics
• /wizard-ci replay-vision
• /wizard-ci revenue
• /wizard-ci self-driving
• /wizard-ci warehouse
• /wizard-ci warehouse-seeded

Test an individual app:

• /wizard-ci ai-observability/anthropic
• /wizard-ci ai-observability/google-adk
• /wizard-ci ai-observability/groq

Show more apps

• /wizard-ci ai-observability/manual-capture
• /wizard-ci ai-observability/openai
• /wizard-ci ai-observability/openai-agents
• /wizard-ci ai-observability/opentelemetry
• /wizard-ci ai-observability/vercel-ai
• /wizard-ci basic-integration/android
• /wizard-ci basic-integration/angular
• /wizard-ci basic-integration/astro
• /wizard-ci basic-integration/django
• /wizard-ci basic-integration/fastapi
• /wizard-ci basic-integration/flask
• /wizard-ci basic-integration/flutter
• /wizard-ci basic-integration/javascript-node
• /wizard-ci basic-integration/javascript-web
• /wizard-ci basic-integration/laravel
• /wizard-ci basic-integration/next-js
• /wizard-ci basic-integration/nuxt
• /wizard-ci basic-integration/python
• /wizard-ci basic-integration/rails
• /wizard-ci basic-integration/react-native
• /wizard-ci basic-integration/react-router
• /wizard-ci basic-integration/sveltekit
• /wizard-ci basic-integration/swift
• /wizard-ci basic-integration/tanstack-router
• /wizard-ci basic-integration/tanstack-start
• /wizard-ci basic-integration/vue
• /wizard-ci feature-flags/django
• /wizard-ci feature-flags/next-js
• /wizard-ci mcp-analytics/custom-dispatcher
• /wizard-ci mcp-analytics/typescript-sdk
• /wizard-ci replay-vision/javascript-node
• /wizard-ci replay-vision/next-js
• /wizard-ci replay-vision/react-vite
• /wizard-ci revenue/stripe
• /wizard-ci self-driving/astro
• /wizard-ci self-driving/fastapi
• /wizard-ci self-driving/nuxt
• /wizard-ci self-driving/react-router
• /wizard-ci self-driving/sveltekit
• /wizard-ci warehouse/monorepo-env
• /wizard-ci warehouse/multi-source-next
• /wizard-ci warehouse/stripe-node
• /wizard-ci warehouse/zero-source
• /wizard-ci warehouse-seeded/next-stripe
• /wizard-ci warehouse-seeded/next-stripe-declined

Test against a Context Mill branch:

• /wizard-ci all context-mill:my-branch

Add context-mill:<branch> to any command above to pin the Context Mill branch. It defaults to main.

Results will be posted here when complete.

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 2 · PR risk: 0/10

[johncwaters]

Note

Automated review. Not written by a human.

[johncwaters]

Note

Automated review. Not written by a human.

In an interactive scoped run, this runs as the run step's onRunPrep. scopeSession (run-program.ts:509) passes it a shallow session copy that is dropped after the run. So detectedFrameworkLabel lands on the copy, not the store, while analytics.setTag('detected_framework', …) still goes global. On main, getUI().setDetectedFramework wrote the variant label to the live store. Now the detected_framework session property in analytics.ts can disagree with the tag. prepSelfDrivingIntegration (self-driving/detect-agentic.ts:132) has the same problem.

Could the label reach the store? For example, give onRunPrep a store-backed setDetectedFramework, or have scopeSession copy detectedFrameworkLabel back through store.setDetectedFramework after prep.

[gewenyu99]

Folded into #1378 so the phase builds green PR by PR. This PR keeps its review; the code lands through #1378.