The Foreground / Background Model
Stadium 8 runs two tracks at once. The foreground is the chat conversation you are having with Claude. The background is the implementation work Claude is doing silently: writing tests, writing code, running builds, executing Playwright. These two tracks overlap, which is what makes Stadium 8 fast.
How the Overlap Works
Section titled “How the Overlap Works”When you approve the story breakdown for an epic, implementation starts in the background. Claude does not disappear to go write code while you wait. Instead, Claude immediately moves back to the foreground and starts planning the next epic with you. Your planning time and Claude’s building time run in parallel.
The pattern looks like this: you approve epic 1’s stories, implementation starts in the background, and Claude immediately opens a foreground conversation about epic 2. By the time epic 1’s implementation finishes and Claude surfaces the results, the epic 2 plan may already be ready to approve.
When epic 1 is done and Playwright has passed, Claude pauses and gives you the QA checklist. You test in the browser. If you have already approved epic 2’s stories, its implementation can start in the background while you are doing manual QA on epic 1.
Why It Matters
Section titled “Why It Matters”In traditional development you wait for each step to complete before starting the next. You submit a requirement, wait for implementation, review it, wait for fixes, review again. Each step is sequential and every wait is dead time.
Stadium 8 keeps the conversation alive. You are never sitting idle waiting for code to be written. The only time the foreground conversation stops is at the three sign-off points. These are intentional pauses where your input is needed, not handoff delays.
A Short Example
Section titled “A Short Example”Say you are building a project management app. You type /start, Claude proposes five epics (auth, projects, tasks, team members, dashboard), and you approve. Claude proposes the story breakdown for the auth epic and you approve that too. Implementation of the auth epic starts in the background.
Claude immediately opens a foreground conversation: “Let’s plan the projects epic. Here’s what I’m thinking…” You spend the next twenty minutes shaping the projects epic: scoping stories, discussing edge cases. When you agree on the story breakdown for projects, you approve it.
Shortly after, Claude surfaces: “Auth epic is done. Playwright passed. Here’s your QA checklist.” You spend a few minutes in the browser checking the login flow. Meanwhile, the projects epic implementation has already started in the background. By the time you sign off on auth QA, Claude has built a substantial part of the projects epic.