This is a brand new wizard run tracking system, which supports both:

• Local runs: syncs state from the user's local machine
• Cloud runs: spawns a worker (temporal + sandbox) that runs the wizard

New concept: Wizard Worker. A wizard worker is an isolated sandbox running on our infrastructure, which we use to download the user's project (either via a git repository, or a zip upload), and run the wizard there.

For its first release, we keep the same sync system (task list updates).

To-do:

• API implementation
• Make state transition and worker step atomic.
• Move serializers/deserializers to class methods
• Files should have one concern. Do not mix configuration, with service code, with serializing.
• Hoist constant variables to a config file
• Make wizard version configurable.
• Add endpoint for a Wizard Registry
• Review naming for service boundaries
• Review the new cancellation/reliability/queue ordering/idempotency/fingerprint changes
• Review the reconciliations system. Why do we need to track whether a run was dispatched?
• Review the WizardWorker model. Should we save the provisioned sandbox data?
• Review the hardcoded daily limits? Why didn't it use the throttlers?
• Sandbox/temporal usage??
• Hook up the Wizard's handoff to the PR description.
• Provision a artifacts bucket https://github.com/PostHog/posthog-cloud-infra/pull/10081
• Artifacts bucket, chart PR https://github.com/PostHog/charts/pull/14662
• Check auth access patterns. Do we have the right scopes?
• Check MCP access patterns Should we expose it?
• Server-side instrumentation
• Observability and monitoring
• Add a lifecycle hook system: attach temporal activities pre/post lifecycle stages. Use-case: email-sending.
• Remove all references to opaque Exception's
• Review naming of logic folder files, like "lifecycle". It is unclear which files are exposing public methods
• Cloud runs SLOs and SLA
• Squash migrations
• Review scaling policy for wizard temporal worker
• We have domain limiters, but we also need http-level limiting
• Surface wizard errors to the wizard run
• Add instructions about repository requirements (e.g. SDK required)
• Fix git signing issue
• Show link to github repository
• Add git diff component (+ -)
• Compatible instrumentation
• Hide local runs until we have state sync from local runs

Open questions:

1. How will we couple the wizard run status, with the wizard state itself?

Rollout order

• 1. infra resources provisioning: https://github.com/PostHog/posthog-cloud-infra/pull/10081
• 2. temporal wizard worker provisioning: https://github.com/PostHog/charts/pull/14662
• 3. wizard handoff file generation: feat: export handoffs to host paths wizard#1141
• 3. wizard error catalog: feat: stable error catalog with machine-readable error codes wizard#1148
• 3. fix: allow dev sandboxes to set MCP endpoint wizard#1163
• 4. wizard worker stack below
  Then:
• create new sync system which allows for user interaction
• rollout cloud self-driving

PR stack

• Foundation: feat(wizard): add run registry foundation #85921 adds the run schema and registry.
• Sessions: refactor(wizard): package session infrastructure #91819 packages session infrastructure.
• Storage: feat(wizard): add run storage services #91820 adds run, artifact, worker, and observability storage.
• Execution: feat(wizard): execute cloud runs #91821 adds cloud worker and Temporal execution.
• API: feat(wizard): expose cloud run APIs #91822 registers APIs, workers, schedules, generated clients, and docs.
• UI: feat(wizard): add wizard run interface #89523 adds the Wizard run interface.
• TODO: instrumentation
• TODO: wizard command snapshot test
• TODO: wizard run creation lock (concurrent requests)

Review each PR in stack order. The UI PR is the final layer.