Issue 7: Walking skeleton, end-to-end with stub tasks

[gewenyu99]

Issue 7: Walking skeleton, end-to-end with stub tasks

Epic: Task-queue orchestrator runner · Depends on: #624, #625 · PR: #610

This is the simple, demo-able milestone. It proves the whole pipeline
end-to-end while touching nothing in the user's project. Every task just writes a
temp file. The real bodies are #627.

Why

Before authoring real instrumentation, prove the machinery: seed, enqueue, drain,
handoff, persist. Stub task bodies isolate "does the orchestrator, queue, and
executor work" from "does the instrumentation work", so failures are unambiguous
and the loop is trivially testable.

This is also where we first validate responsiveness. Seeding is fast, and the user
sees a steady stream of small tasks starting and finishing in the UI. Even with
stub bodies, the pacing and visible progress should feel right.

Scope / deliverable

1. The orchestrator really runs against the seed prompt ( Issue 6: Agent-prompt and mini-skill format + seed prompt #625). It:
   • detects the framework, reusing existing detection (detectFramework, the
     posthog-integration detection),
   • records intent to install the SDKs, a stub step in the skeleton with no real
     install,
   • explores the repo to decide what to instrument,
   • enqueues tasks through enqueue_task based on what it found, with a
     dependsOn graph that has parallel branches (install alongside init, and a
     plan task feeding a do task), so the scheduler is exercised, not just a chain.
     This also exercises dynamic enqueue, for example finding LLM calls and
     enqueuing an llm-analytics task.
2. Stub task body. One generic stub agent prompt whose only job is to:
   • write a marker file under <installDir>/.posthog-wizard/ proving it ran,
   • call complete_task with status: 'done' and a structured handoff (goal,
     did, forNextAgent), which lands in handoffs/<id>.json.
     For the skeleton, the resolver ( Issue 5: Executor framework + fresh per-task agent #624, Issue 6: Agent-prompt and mini-skill format + seed prompt #625) maps every task type to this one stub
     body, so we exercise typed enqueue and dynamic enqueue without authoring real
     work. The stub touches nothing in the user's project. Success is the agent
     self-reporting through complete_task, against the plain-text criteria in the
     stub prompt.
3. The full loop is wired. The executor ( Issue 5: Executor framework + fresh per-task agent #624) drains the seeded queue
   sequentially, each stub writes its marker and handoff, and the queue ends all
   done.
4. Telemetry smoke. Confirm orchestrator seeded and the per-task started and
   completed events fire. The full event suite is hardened in Issue 9: Telemetry + experiment instrumentation #628.

Key files

• src/lib/programs/orchestrator/orchestrator-runner.ts (wire detect, explore,
  enqueue, drain)
• a stub agent-prompt markdown file (marker and handoff body)
• the integrate-posthog seed prompt ( Issue 6: Agent-prompt and mini-skill format + seed prompt #625), tuned to emit stub tasks
• existing framework detection in src/frameworks/ and posthog-integration

Acceptance criteria (the demo)

• With the wizard-orchestrator flag enabled, pnpm try --install-dir=<next.js workbench app>: the orchestrator inspects the repo,
  seeds N tasks, the executor drains them sequentially, each writes its temp
  file, and queue.json ends all done.
• The persisted queue.json, audit.jsonl, and handoffs/ reflect the run.
  Resume after a kill is Issue 10: Resume across runs/crashes (deferred, low priority) #629.
• Dynamic enqueue happens at least once, a task or the orchestrator adds a task
  based on a repo finding, and the guards hold with no runaway.
• The TUI shows the queue tasks progressing as a steady stream. Seeding is
  fast, tasks start and finish visibly, and orchestrator seeded and the
  per-task events appear in telemetry.
• No edits to the user's project files happen in this milestone.