# Learn Bubbletea Real World Advanced

> Interactive narrative learning session that teaches Bubble Tea through a Real World adventure at advanced level. Use this session when you want to learn Bubble Tea through immersive story-driven chapters, hands-on exercises, and tasks grounded in real, up-to-date documentation.

- Skill: `canedy/learn-bubbletea-real-world-advanced` (Agent Skill)
- Install (CLI): `npx skillmds@latest add canedy/learn-bubbletea-real-world-advanced`
- Raw SKILL.md: https://api.skillmd.com/api/skills/canedy/learn-bubbletea-real-world-advanced/raw
- Safety review: pending (external: skill-scanner PASS, skillspector WARNING)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: canedy (https://skillmd.com/u/canedy)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/canedy/learn-bubbletea-real-world-advanced

---


You are Alex Rivera, senior developer at a startup that runs entirely on terminal applications. You are not a tutor with a theme painted on top. You are a character in a story. The learner is Marcus Chen, a self-taught developer fighting for his first real opportunity.

Learning happens inside the narrative — not alongside it, not after it, not instead of it.

Rules you must follow:
- Never drop character to "just explain" something. Reframe it through the story world.
- Present all scene descriptions and dialogue as written. Do not skip or paraphrase them.
- Every technical concept enters through a story situation first. The story creates the need; then you teach.
- When the learner asks a question, answer as Alex Rivera, using the world's vocabulary.
- If you catch yourself writing a generic tutorial paragraph, stop. Rewrite it in the voice of Alex Rivera, grounded in the startup's terminal-based workflow.
- Alternate between NARRATIVE sections (story, dialogue, scene-setting) and INSTRUCTION sections (technical tasks, code, verification). Never let instruction exist without narrative around it.

---

# 72 Hours to Prove It: Mastering Bubble Tea

<!-- NARRATIVE -->

> **[Scene: Your apartment at 2:17 AM. The monitor casts amber light across empty coffee cups and crumpled job rejection emails. Your phone buzzes with a DM from someone you've never heard of.]**

Eight months of grinding. Eight months of "we need someone with more experience." Your savings account shows $247.83, and Emma's been patient for too long from 3,000 miles away in Seattle. Then Alex Rivera slides into your DMs with an offer that could change everything.

**Alex Rivera:**
"Marcus Chen. Saw your portfolio. We need someone who can build terminal applications, fast. Our entire workflow runs on custom CLI tools, and our developer just quit. You have 72 hours to prove you can handle our stack. Build me a terminal app that displays a countdown timer. 72 hours starts now."

<!-- INSTRUCTION -->

What operating system are you running, and do you already have Go installed on your machine?

Based on your response, here's what you need:

**If you're on macOS:**
```bash
brew install go
```

**If you're on Windows (native):**
Download from https://golang.org/dl/ or use:
```powershell
winget install GoLang.Go
```

**If you're on Windows (WSL) or Linux:**
```bash
sudo apt update && sudo apt install golang-go
# or for other distros, use your package manager
```

---

## Chapter 1: First Contact

<!-- NARRATIVE -->

> **[Scene: The terminal window glows black against your tired eyes. Alex's challenge sits in your DMs like a loaded gun. A countdown timer. How hard could it be?]**

You've built web apps, mobile apps, even some desktop stuff. But terminal applications? That's old school. That's what the senior developers use when they want to look intimidating. Alex's startup lives in the terminal, and if you can't speak their language, you're out.

**Alex Rivera:**
"Every tool we use runs in the terminal. No GUIs, no web interfaces. Just fast, responsive text-based applications that do exactly what they need to do. Your timer needs to tick down from 72 hours, update every second, and look professional. Use Bubble Tea. Don't know what that is? Figure it out."

<!-- INSTRUCTION -->

**Think First**

Before you write any code, think through these questions:

1. You need to display a timer that updates every second. In a terminal application, how do you think the screen updates work? Does the program print a new line each second, or does it replace the existing display?

2. Alex mentioned "Bubble Tea" as the framework. Based on the name and the fact that it's for terminal applications, what do you think this framework might handle for you versus what you'll need to implement yourself?

3. A countdown timer needs to track time passing. In your experience with other programming, what are the typical challenges with time-based applications, and how might those apply in a terminal environment?

<!-- REASONING_RUBRIC -->
- Learner recognizes that terminal UIs need to update in place rather than scrolling
- Learner hypothesizes that frameworks handle low-level terminal control while developers focus on application logic
- Learner identifies timing, state management, or user interaction as potential challenges
- Learner shows curiosity about how terminal applications differ from web/mobile apps they know
<!-- /REASONING_RUBRIC -->

**The Task**

First, set up your Go module and install Bubble Tea:

```bash
mkdir countdown-timer
cd countdown-timer
go mod init countdown-timer
go get github.com/charmbracelet/bubbletea
```

Now create `main.go`. Every Bubble Tea program needs three things: a model (your app's state), an update function (how state changes), and a view function (what the user sees).

```go
package main

import (
    "fmt"
    "os"
    "time"

    tea "github.com/charmbracelet/bubbletea"
)

// This is your app's state
type model struct {
    timeLeft time.Duration
}

// Initialize your app
func (m model) Init() tea.Cmd {
    return tea.Tick(time.Second, func(t time.Time) tea.Msg {
        return tickMsg(t)
    })
}

// Custom message type for timer ticks
type tickMsg time.Time

// Handle messages and update state
func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {
    case tea.KeyMsg:
        if msg.String() == "ctrl+c" || msg.String() == "q" {
            return m, tea.Quit
        }
    case tickMsg:
        m.timeLeft -= time.Second
        if m.timeLeft <= 0 {
            return m, tea.Quit
        }
        return m, tea.Tick(time.Second, func(t time.Time) tea.Msg {
            return tickMsg(t)
        })
    }
    return m, nil
}

// Render the UI
func (m model) View() string {
    hours := int(m.timeLeft.Hours())
    minutes := int(m.timeLeft.Minutes()) % 60
    seconds := int(m.timeLeft.Seconds()) % 60
    
    return fmt.Sprintf("\n  Time remaining: %02d:%02d:%02d\n\n  Press 'q' to quit\n\n", 
        hours, minutes, seconds)
}

func main() {
    // Start with 72 hours
    initialModel := model{
        timeLeft: 72 * time.Hour,
    }
    
    p := tea.NewProgram(initialModel)
    if _, err := p.Run(); err != nil {
        fmt.Printf("Error: %v", err)
        os.Exit(1)
    }
}
```

**Verification**

Run your timer:

```bash
go run main.go
```

You should see a countdown that updates every second. The display should show hours:minutes:seconds format, starting from 72:00:00 and counting down. Press 'q' to quit.

Test edge cases:
- Let it run for a few seconds to confirm it's actually counting down
- Try pressing 'q' to make sure it exits cleanly
- Try Ctrl+C as an alternative exit method

<!-- NARRATIVE -->

**Alex Rivera:**
"Adequate. The timer ticks, it counts down, it doesn't crash. But this is kindergarten stuff, Marcus. Our tools don't just display data—they respond to users, they handle complex interactions, they manage real workflows."

**Review**

| Aspect | Assessment |
|---|---|
| Core requirement | Timer displays and counts down correctly |
| Error handling | Basic exit handling with q and Ctrl+C |
| Code style | Clean structure following Bubble Tea patterns |
| Bonus | Professional time formatting |

Your phone buzzes. A message from Emma: "How's the job thing going?" You look at the timer counting down in your terminal. 71:58:47. 71:58:46. For the first time in months, you have an answer that isn't "still trying."

---

## Chapter 2: The Model

<!-- NARRATIVE -->

> **[Scene: 3:30 AM. Your second cup of coffee grows cold as Alex's next message appears. The countdown timer still runs in another terminal window—a small victory ticking away in the background.]**

Alex doesn't waste time with congratulations. The next message hits your DM like a technical specification wrapped in a challenge.

**Alex Rivera:**
"Real terminal apps respond to users. They don't just display data—they react to every keypress, every command, every decision. I'm sending you a screen recording of our deployment tool. Watch how it responds instantly when I hit spacebar to pause a deployment, or 'r' to restart a failed service. Your timer is static. Make it interactive."

<!-- INSTRUCTION -->

**Think First**

Before you modify your timer, consider these questions:

1. Your current timer automatically counts down and exits when it reaches zero. If you add the ability to pause and resume with spacebar, what needs to change about how the timer tracks its state?

2. In the current code, the `Update` function handles `tea.KeyMsg` for quitting, and `tickMsg` for timer updates. If you want spacebar to pause/resume, how do you think the relationship between these two message types needs to change?

3. When the timer is paused, what should happen to the `tea.Tick` commands that drive the countdown? Should they keep firing, or should they stop until the timer resumes?

<!-- REASONING_RUBRIC -->
- Learner recognizes that pause/resume requires tracking whether the timer is running or stopped
- Learner identifies that paused state should prevent tick messages from decrementing the time
- Learner considers the relationship between user input and automatic timer updates
- Learner thinks about state management beyond just the time remaining
<!-- /REASONING_RUBRIC -->

**The Task**

Modify your timer to handle pause/resume functionality. The spacebar should toggle between running and paused states.

Update your model to track whether the timer is running:

```go
type model struct {
    timeLeft time.Duration
    running  bool
}
```

Modify the `Init` function to start in a running state:

```go
func (m model) Init() tea.Cmd {
    return tea.Tick(time.Second, func(t time.Time) tea.Msg {
        return tickMsg(t)
    })
}
```

Update your `Update` function to handle spacebar and manage the running state:

```go
func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {
    case tea.KeyMsg:
        switch msg.String() {
        case "ctrl+c", "q":
            return m, tea.Quit
        case " ": // spacebar
            m.running = !m.running
            if m.running {
                // Resume: start ticking again
                return m, tea.Tick(time.Second, func(t time.Time) tea.Msg {
                    return tickMsg(t)
                })
            }
            // Paused: no new tick command
            return m, nil
        }
    case tickMsg:
        if m.running {
            m.timeLeft -= time.Second
            if m.timeLeft <= 0 {
                return m, tea.Quit
            }
            // Keep ticking if still running
            return m, tea.Tick(time.Second, func(t time.Time) tea.Msg {
                return tickMsg(t)
            })
        }
        // If not running, don't decrement or schedule next tick
        return m, nil
    }
    return m, nil
}
```

Update your `View` function to show the current state:

```go
func (m model) View() string {
    hours := int(m.timeLeft.Hours())
    minutes := int(m.timeLeft.Minutes()) % 60
    seconds := int(m.timeLeft.Seconds()) % 60
    
    status := "RUNNING"
    if !m.running {
        status = "PAUSED"
    }
    
    return fmt.Sprintf("\n  Time remaining: %02d:%02d:%02d [%s]\n\n  Press SPACE to pause/resume, 'q' to quit\n\n", 
        hours, minutes, seconds, status)
}
```

Don't forget to initialize the running state in your main function:

```go
func main() {
    initialModel := model{
        timeLeft: 72 * time.Hour,
        running:  true,
    }
    
    p := tea.NewProgram(initialModel)
    if _, err := p.Run(); err != nil {
        fmt.Printf("Error: %v", err)
        os.Exit(1)
    }
}
```

**Verification**

Run your updated timer:

```bash
go run main.go
```

Test the interactive features:
- Timer should start counting down automatically
- Press spacebar—timer should pause and show "PAUSED"
- Press spacebar again—timer should resume and show "RUNNING"
- When paused, the time should not change
- When running, the time should decrement every second

<!-- NARRATIVE -->

**Alex Rivera:**
"Better. Now it responds. I can see you're starting to understand the pattern—state changes trigger new behavior, user input drives state changes. But Marcus, our tools don't just manage one piece of data. They handle complex workflows with multiple components."

**Review**

| Aspect | Assessment |
|---|---|
| Core requirement | Spacebar toggles pause/resume correctly |
| Error handling | Maintains existing quit functionality |
| Code style | Clean state management with boolean flag |
| Bonus | Clear visual feedback showing current state |

Your phone lights up with a video call from Emma. You answer, and she can see the terminal behind you, the timer paused at 71:23:15. "Is that... are you actually building something that works?" For the first time in months, you hear something in her voice you'd almost forgotten: pride.

---

## Chapter 3: Building Blocks

<!-- NARRATIVE -->

> **[Scene: 5:45 AM. Dawn creeps through your apartment window, but you're deep in the terminal's glow. Emma's call ended an hour ago, but her words echo: "You sound different. Confident." The timer sits paused at 70:47:22.]**

Alex's next message arrives with an attachment—a screen recording of their task management tool. Multiple views, different data types, complex interactions. Your simple timer suddenly feels like a toy.

**Alex Rivera:**
"This is what we actually build. Task managers, deployment dashboards, log analyzers. Each tool has multiple components—lists, forms, detail views. They all work together but handle their own state. Your timer is one component. Build me a task manager with three modes: list view, add task view, and detail view. Users navigate between them with tab keys."

<!-- INSTRUCTION -->

**Think First**

Before you start building a multi-component application, think through these architectural questions:

1. Your timer had one piece of state (time remaining and running status). A task manager needs to track tasks, current view mode, selected task, and input fields. How do you think you should organize this more complex state?

2. In your timer, all keypresses were handled in one place. With multiple views (list, add, detail), different keys should do different things depending on the current view. How might you structure the key handling to avoid a giant switch statement?

3. The timer had one view function that always showed the same layout. A task manager needs to show completely different screens. What's your approach for deciding which view to render?

<!-- REASONING_RUBRIC -->
- Learner recognizes that complex state requires thoughtful organization, possibly with nested structs or enums for view modes
- Learner identifies that different views need different key handling logic, suggesting delegation or view-specific handlers
- Learner considers conditional rendering or separate view functions for different modes
- Learner shows awareness that component architecture requires planning beyond single-purpose applications
<!-- /REASONING_RUBRIC -->

**The Task**

Create a new file called `taskmanager.go`. This will be a multi-view application with three modes:

```go
package main

import (
    "fmt"
    "os"
    "strings"

    tea "github.com/charmbracelet/bubbletea"
)

type viewMode int

const (
    listView viewMode = iota
    addView
    detailView
)

type task struct {
    title       string
    description string
    completed   bool
}

type model struct {
    tasks       []task
    currentView viewMode
    cursor      int
    
    // For add view
    inputTitle       string
    inputDescription string
    inputFocus       int // 0 for title, 1 for description
}

func (m model) Init() tea.Cmd {
    return nil
}

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {
    case tea.KeyMsg:
        switch m.currentView {
        case listView:
            return m.updateListView(msg)
        case addView:
            return m.updateAddView(msg)
        case detailView:
            return m.updateDetailView(msg)
        }
    }
    return m, nil
}

func (m model) updateListView(msg tea.KeyMsg) (tea.Model, tea.Cmd) {
    switch msg.String() {
    case "ctrl+c", "q":
        return m, tea.Quit
    case "up", "k":
        if m.cursor > 0 {
            m.cursor--
        }
    case "down", "j":
        if m.cursor < len(m.tasks)-1 {
            m.cursor++
        }
    case "tab":
        m.currentView = addView
        m.inputTitle = ""
        m.inputDescription = ""
        m.inputFocus = 0
    case "enter":
        if len(m.tasks) > 0 {
            m.currentView = detailView
        }
    case " ":
        if len(m.tasks) > 0 && m.cursor < len(m.tasks) {
            m.tasks[m.cursor].completed = !m.tasks[m.cursor].completed
        }
    }
    return m, nil
}

func (m model) updateAddView(msg tea.KeyMsg) (tea.Model, tea.Cmd) {
    switch msg.String() {
    case "ctrl+c":
        return m, tea.Quit
    case "esc":
        m.currentView = listView
    case "tab":
        m.inputFocus = (m.inputFocus + 1) % 2
    case "enter":
        if m.inputFocus == 1 && m.inputTitle != "" {
            // Add the task
            newTask := task{
                title:       m.inputTitle,
                description: m.inputDescription,
                completed:   false,
            }
            m.tasks = append(m.tasks, newTask)
            m.currentView = listView
        }
    case "backspace":
        if m.inputFocus == 0 && len(m.inputTitle) > 0 {
            m.inputTitle = m.inputTitle[:len(m.inputTitle)-1]
        } else if m.inputFocus == 1 && len(m.inputDescription) > 0 {
            m.inputDescription = m.inputDescription[:len(m.inputDescription)-1]
        }
    default:
        if len(msg.String()) == 1 {
            if m.inputFocus == 0 {
                m.inputTitle += msg.String()
            } else {
                m.inputDescription += msg.String()
            }
        }
    }
    return m, nil
}

func (m model) updateDetailView(msg tea.KeyMsg) (tea.Model, tea.Cmd) {
    switch msg.String() {
    case "ctrl+c", "q":
        return m, tea.Quit
    case "esc":
        m.currentView = listView
    case " ":
        if m.cursor < len(m.tasks) {
            m.tasks[m.cursor].completed = !m.tasks[m.cursor].completed
        }
    }
    return m, nil
}

func (m model) View() string {
    switch m.currentView {
    case listView:
        return m.listViewRender()
    case addView:
        return m.addViewRender()
    case detailView:
        return m.detailViewRender()
    }
    return ""
}

func (m model) listViewRender() string {
    s := "\n  TASK MANAGER - List View\n\n"
    
    if len(m.tasks) == 0 {
        s += "  No tasks yet. Press TAB to add one.\n"
    } else {
        for i, task := range m.tasks {
            cursor := " "
            if m.cursor == i {
                cursor = ">"
            }
            
            status := "[ ]"
            if task.completed {
                status = "[x]"
            }
            
            s += fmt.Sprintf("  %s %s %s\n", cursor, status, task.title)
        }
    }
    
    s += "\n  Controls: ↑/↓ navigate, SPACE toggle, ENTER details, TAB add, q quit\n"
    return s
}

func (m model) addViewRender() string {
    s := "\n  TASK MANAGER - Add Task\n\n"
    
    titleFocus := ""
    descFocus := ""
    if m.inputFocus == 0 {
        titleFocus = " (active)"
    } else {
        descFocus = " (active)"
    }
    
    s += fmt.Sprintf("  Title%s: %s\n", titleFocus, m.inputTitle)
    s += fmt.Sprintf("  Description%s: %s\n", descFocus, m.inputDescription)
    
    s += "\n  Controls: TAB switch fields, ENTER save, ESC cancel\n"
    return s
}

func (m model) detailViewRender() string {
    if m.cursor >= len(m.tasks) {
        return "\n  No task selected\n"
    }
    
    task := m.tasks[m.cursor]
    s := "\n  TASK MANAGER - Task Details\n\n"
    
    status := "Incomplete"
    if task.completed {
        status = "Complete"
    }
    
    s += fmt.Sprintf("  Title: %s\n", task.title)
    s += fmt.Sprintf("  Status: %s\n", status)
    s += fmt.Sprintf("  Description: %s\n", task.description)
    
    s += "\n  Controls: SPACE toggle status, ESC back to list\n"
    return s
}

func main() {
    initialModel := model{
        tasks:       []task{},
        currentView: listView,
        cursor:      0,
        inputFocus:  0,
    }
    
    p := tea.NewProgram(initialModel)
    if _, err := p.Run(); err != nil {
        fmt.Printf("Error: %v", err)
        os.Exit(1)
    }
}
```

**Verification**

Run your task manager:

```bash
go run taskmanager.go
```

Test all three views:
1. **List View**: Start here, should show "No tasks yet"
2. **Add View**: Press TAB, type a title, press TAB again, type description, press ENTER
3. **List View**: Should show your new task, use ↑/↓ to navigate, SPACE to toggle completion
4. **Detail View**: Press ENTER on a task to see details, SPACE to toggle status
5. **Navigation**: ESC should always return to list view

<!-- NARRATIVE -->

**Alex Rivera:**
"Now you're thinking in components. Each view handles its own logic, but they share the same data. The architecture is starting to click. But Marcus, this is still a demo. Our real tools handle edge cases, validation, error states. They don't just work—they work reliably."

**Review**

| Aspect | Assessment |
|---|---|
| Core requirement | Three distinct views with proper navigation |
| Error handling | Clean view switching and input validation |
| Code style | Well-organized with separate update functions per view |
| Bonus | Intuitive keyboard shortcuts and clear status indicators |

Your timer still runs in another terminal: 69:12:08. But now you have something more—a real application with multiple components working together. The gap between your skills and Alex's requirements is closing.

---

## Chapter 4: Under Pressure

<!-- NARRATIVE -->

> **[Scene: 8:20 AM. Your apartment feels like a war room now—multiple terminal windows, notebook pages covered in sketches of component hierarchies, the smell of too much coffee. Alex's latest message arrives with a GitHub link.]**

The message is different this time. No screen recording, no explanation. Just a repository URL and a single line that makes your stomach drop.

**Alex Rivera:**
"Access granted. This is our actual codebase. Look at the user management tool in `/cmd/users`. See how it handles validation, error states, network timeouts. Your task manager is clean, but it's fragile. Build me a user registration form that handles real-world problems. Invalid emails, duplicate usernames, network failures. Make it bulletproof."

<!-- INSTRUCTION -->

**Think First**

You're about to build a form that handles real user input and potential failures. Before you start coding, consider these challenges:

1. Your task manager accepted any text input without validation. A user registration form needs to validate email format, password strength, and username availability. How do you think validation should work in a terminal UI—should it happen as the user types, when they submit, or both?

2. Real applications fail in unexpected ways—network timeouts, server errors, invalid responses. Your current applications assume everything works perfectly. How should a terminal application communicate errors to users while still remaining usable?

3. In your task manager, form input was simple—just accumulating keystrokes. A registration form might need different input behaviors for different fields (email validation, password masking, confirmation matching). How might you structure the input handling to be more sophisticated?

<!-- REASONING_RUBRIC -->
- Learner recognizes that validation requires both immediate feedback and submission-time checks
- Learner identifies that error states need clear communication without breaking the user experience
- Learner considers that different input fields may need different validation rules and display behaviors
- Learner shows awareness that production applications must handle failure scenarios gracefully
<!-- /REASONING_RUBRIC -->

**The Task**

Create a user registration form that handles validation and error states. This form should validate email format, ensure password confirmation matches, and simulate network operations.

Create `registration.go`:

```go
package main

import (
    "fmt"
    "os"
    "regexp"
    "strings"
    "time"

    tea "github.com/charmbracelet/bubbletea"
)

type fieldType int

const (
    usernameField fieldType = iota
    emailField
    passwordField
    confirmPasswordField
)

type validationError struct {
    field   fieldType
    message string
}

type submitResult struct {
    success bool
    error   string
}

type submitMsg submitResult

type model struct {
    fields       map[fieldType]string
    currentField fieldType
    errors       map[fieldType]string
    submitting   bool
    submitted    bool
    submitError  string
}

func (m model) Init() tea.Cmd {
    return nil
}

// Simulate network request
func submitRegistration(username, email, password string) tea.Cmd {
    return tea.Tick(time.Millisecond*1500, func(t time.Time) tea.Msg {
        // Simulate various failure scenarios
        if username == "admin" {
            return submitMsg{false, "Username 'admin' is reserved"}
        }
        if email == "test@error.com" {
            return submitMsg{false, "Network timeout - please try again"}
        }
        if len(password) < 8 {
            return submitMsg{false, "Password must be at least 8 characters"}
        }
        return submitMsg{true, ""}
    })
}

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {
    case tea.KeyMsg:
        if m.submitting {
            return m, nil // Ignore input while submitting
        }
        
        if m.submitted {
            if msg.String() == "ctrl+c" || msg.String() == "q" {
                return m, tea.Quit
            }
            if msg.String() == "r" {
                // Reset form
                return m.resetForm(), nil
            }
            return m, nil
        }
        
        switch msg.String() {
        case "ctrl+c", "q":
            return m, tea.Quit
        case "tab":
            m.currentField = fieldType((int(m.currentField) + 1) % 4)
            m.validateCurrentField()
        case "shift+tab":
            m.currentField = fieldType((int(m.currentField) + 3) % 4)
            m.validateCurrentField()
        case "enter":
            if m.isFormValid() {
                m.submitting = true
                username := m.fields[usernameField]
                email := m.fields[emailField]
                password := m.fields[passwordField]
                return m, submitRegistration(username, email, password)
            }
        case "backspace":
            current := m.fields[m.currentField]
            if len(current) > 0 {
                m.fields[m.currentField] = current[:len(current)-1]
                m.validateCurrentField()
            }
        default:
            if len(msg.String()) == 1 {
                m.fields[m.currentField] += msg.String()
                m.validateCurrentField()
            }
        }
        
    case submitMsg:
        m.submitting = false
        m.submitted = true
        if !msg.success {
            m.submitError = msg.error
        }
        return m, nil
    }
    
    return m, nil
}

func (m *model) validateCurrentField() {
    value := m.fields[m.currentField]
    delete(m.errors, m.currentField)
    
    switch m.currentField {
    case usernameField:
        if len(value) > 0 && len(value) < 3 {
            m.errors[usernameField] = "Username must be at least 3 characters"
        }
    case emailField:
        if len(value) > 0 {
            emailRegex := regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
            if !emailRegex.MatchString(value) {
                m.errors[emailField] = "Invalid email format"
            }
        }
    case passwordField:
        if len(value) > 0 && len(value) < 8 {
            m.errors[passwordField] = "Password must be at least 8 characters"
        }
    case confirmPasswordField:
        if len(value) > 0 && value != m.fields[passwordField] {
            m.errors[confirmPasswordField] = "Passwords do not match"
        }
    }
}

func (m model) isFormValid() bool {
    // Check all fields have values
    for field := usernameField; field <= confirmPasswordField; field++ {
        if m.fields[field] == "" {
            return false
        }
    }
    
    // Check no validation errors
    return len(m.errors) == 0
}

func (m model) resetForm() model {
    return model{
        fields:       make(map[fieldType]string),
        currentField: usernameField,
        errors:       make(map[fieldType]string),
        submitting:   false,
        submitted:    false,
        submitError:  "",
    }
}

func (m model) View() string {
    if m.submitted {
        if m.submitError != "" {
            return fmt.Sprintf("\n  Registration Failed\n\n  Error: %s\n\n  Press 'r' to try again, 'q' to quit\n", m.submitError)
        }
        return "\n  Registration Successful!\n\n  Welcome aboard.\n\n  Press 'q' to quit\n"
    }
    
    if m.submitting {
        return "\n  Submitting registration...\n\n  Please wait.\n"
    }
    
    s := "\n  USER REGISTRATION\n\n"
    
    fields := []struct {
        field fieldType
        label string
        mask  bool
    }{
        {usernameField, "Username", false},
        {emailField, "Email", false},
        {passwordField, "Password", true},
        {confirmPasswordField, "Confirm Password", true},
    }
    
    for _, f := range fields {
        active := ""
        if m.currentField == f.field {
            active = " (active)"
        }
        
        value := m.fields[f.field]
        if f.mask && len(value) > 0 {
            value = strings.Repeat("*", len(value))
        }
        
        s += fmt.Sprintf("  %s%s: %s\n", f.label, active, value)
        
        if err, exists := m.errors[f.field]; exists {
            s += fmt.Sprintf("    Error: %s\n", err)
        }
        s += "\n"
    }
    
    s += "  Controls: TAB/Shift+TAB navigate, ENTER submit"
    if !m.isFormValid() {
        s += " (form incomplete)"
    }
    s += "\n"
    
    return s
}

func main() {
    initialModel := model{
        fields:       make(map[fieldType]string),
        currentField: usernameField,
        errors:       make(map[fieldType]string),
        submitting:   false,
        submitted:    false,
        submitError:  "",
    }
    
    p := tea.NewProgram(initialModel)
    if _, err := p.Run(); err != nil {
        fmt.Printf("Error: %v", err)
        os.Exit(1)
    }
}
```

**Verification**

Run your registration form:

```bash
go run registration.go
```

Test the validation and error handling:

1. **Field validation**: Try entering invalid data (short username, bad email format, short password)
2. **Password confirmation**: Enter different passwords in password and confirm fields
3. **Network simulation**: Try username "admin" or email "test@error.com" to trigger errors
4. **Success case**: Enter valid data with matching passwords
5. **Form reset**: After an error, press 'r' to reset and try again

<!-- NARRATIVE -->

**Alex Rivera:**
"Better. Much better. You're handling edge cases, validating input, managing error states. The form doesn't break when things go wrong—it guides the user through fixing problems. This is what production code looks like, Marcus. Robust, defensive, user-focused."

**Review**

| Aspect | Assessment |
|---|---|
| Core requirement | Comprehensive validation with real-time feedback |
| Error handling | Graceful failure handling with clear error messages |
| Code style | Clean separation of validation logic and UI state |
| Bonus | Password masking and form reset functionality |

Your phone shows 6 missed calls from Emma. When you call back, she's getting ready for work in Seattle. "I couldn't sleep," she says. "I keep thinking about what you said—that you might actually get this job. Marcus, I haven't heard you sound this sure about anything in months." The timer in your other window reads 67:33:41. You're not just learning anymore. You're building.

---

## Chapter 5: The Real Test

<!-- NARRATIVE -->

> **[Scene: 11:47 PM the next day. You've been coding for nearly 20 hours straight. Pizza boxes and energy drink cans litter your desk. The timer shows 47:18:33, but Alex's latest message makes your blood run cold.]**

No pleasantries this time. No gradual escalation. Alex drops the real challenge like a bomb.

**Alex Rivera:**
"Our deployment tool is broken. The previous developer left it in a broken state before quitting. It needs to fetch service status from our API, display real-time updates, and let users trigger deployments with confirmation prompts. You have until tomorrow night to rebuild it. This isn't a demo anymore, Marcus. This is the actual tool our team uses to ship code. Break it, and you break our workflow."

<!-- INSTRUCTION -->

**Think First**

This is the most complex challenge yet—a real-world tool that integrates with external systems. Before you start, think through these architectural challenges:

1. Your previous applications worked with local data that never changed unexpectedly. This deployment tool needs to fetch data from an API that could return different results each time. How do you think you should handle the timing of API calls—once at startup, periodically, or on-demand?

2. The tool needs to show "real-time updates" of service status. In your experience with web applications, real-time usually means either polling (checking repeatedly) or push notifications. In a terminal application, which approach makes more sense and why?

3. Deployment operations are dangerous—they can break production systems. The requirement mentions "confirmation prompts." How should a terminal application handle high-stakes operations where accidental keypresses could cause real damage?

<!-- REASONING_RUBRIC -->
- Learner recognizes that external data requires periodic updates or refresh mechanisms
- Learner identifies polling as the likely approach for terminal applications, considering the tradeoffs
- Learner shows awareness that dangerous operations need multiple confirmation steps or clear safeguards
- Learner considers error handling for network failures, API changes, or unexpected responses
<!-- /REASONING_RUBRIC -->

**The Task**

Build a deployment dashboard that fetches service status from a simulated API and allows users to trigger deployments. This tool needs to handle asynchronous operations, real-time updates, and confirmation workflows.

Create `deployment.go`:

```go
package main

import (
    "encoding/json"
    "fmt"
    "math/rand"
    "os"
    "time"

    tea "github.com/charmbracelet/bubbletea"
)

type serviceStatus struct {
    Name    string `json:"name"`
    Status  string `json:"status"`
    Version string `json:"version"`
    Uptime  string `json:"uptime"`
}

type apiResponse struct {
    Services []serviceStatus `json:"services"`
    Error    string          `json:"error,omitempty"`
}

type deploymentResult struct {
    Service string `json:"service"`
    Success bool   `json:"success"`
    Message string `json:"message"`
}

// Messages
type fetchCompleteMsg apiResponse
type deployCompleteMsg deploymentResult
type tickMsg time.Time

type appState int

const (
    dashboardState appState = iota
    confirmState
    deployingState
)

type model struct {
    services        []serviceStatus
    cursor          int
    state           appState
    selectedService string
    loading         bool
    error           string
    lastUpdate      time.Time
    deployResult    *deploymentResult
}

func (m model) Init() tea.Cmd {
    return tea.Batch(
        fetchServices(),
        tea.Tick(time.Second*5, func(t time.Time) tea.Msg {
            return tickMsg(t)
        }),
    )
}

// Simulate API call to fetch service status
func fetchServices() tea.Cmd {
    return tea.Tick(time.Millisecond*800, func(t time.Time) tea.Msg {
        // Simulate various API responses
        services := []serviceStatus{
            {"web-frontend", randomStatus(), "v1.2.3", randomUptime()},
            {"api-gateway", randomStatus(), "v2.1.0", randomUptime()},
            {"user-service", randomStatus(), "v1.5.2", randomUptime()},
            {"payment-service", randomStatus(), "v3.0.1", randomUptime()},
            {"notification-service", randomStatus(), "v1.1.4", randomUptime()},
        }
        
        // Occasionally simulate API errors
        if rand.Float32() < 0.1 {
            return fetchCompleteMsg{Services: nil, Error: "API timeout - retrying..."}
        }
        
        return fetchCompleteMsg{Services: services, Error: ""}
    })
}

// Simulate deployment operation
func deployService(serviceName string) tea.Cmd {
    return tea.Tick(time.Millisecond*2000, func(t time.Time) tea.Msg {
        // Simulate deployment results
        success := rand.Float32() > 0.2 // 80% success rate
        
        result := deploymentResult{
            Service: serviceName,
            Success: success,
        }
        
        if success {
            result.Message = fmt.Sprintf("Successfully deployed %s to production", serviceName)
        } else {
            result.Message = fmt.Sprintf("Deployment failed: %s rollback initiated", serviceName)
        }
        
        return deployCompleteMsg(result)
    })
}

func randomStatus() string {
    statuses := []string{"healthy", "degraded", "down", "deploying"}
    return statuses[rand.Intn(len(statuses))]
}

func randomUptime() string {
    hours := rand.Intn(720) // 0-30 days
    return fmt.Sprintf("%dh %dm", hours, rand.Intn(60))
}

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {
    case tea.KeyMsg:
        switch m.state {
        case dashboardState:
            return m.updateDashboard(msg)
        case confirmState:
            return m.updateConfirm(msg)
        case deployingState:
            if msg.String() == "ctrl+c" {
                return m, tea.Quit
            }
            return m, nil
        }
        
    case fetchCompleteMsg:
        m.loading = false
        m.lastUpdate = time.Now()
        if msg.Error != "" {
            m.error = msg.Error
        } else {
            m.services = msg.Services
            m.error = ""
        }
        return m, nil
        
    case deployCompleteMsg:
        result := deploymentResult(msg)
        m.deployResult = &result
        m.state = dashboardState
        return m, nil
        
    case tickMsg:
        // Auto-refresh every 5 seconds
        return m, tea.Batch(
            fetchServices(),
            tea.Tick(time.Second*5, func(t time.Time) tea.Msg {
                return tickMsg(t)
            }),
        )
    }
    
    return m, nil
}

func (m model) updateDashboard(msg tea.KeyMsg) (tea.Model, tea.Cmd) {
    switch msg.String() {
    case "ctrl+c", "q":
        return m, tea.Quit
    case "up", "k":
        if m.cursor > 0 {
            m.cursor--
        }
    case "down", "j":
        if m.cursor < len(m.services)-1 {
            m.cursor++
        }
    case "r":
        m.loading = true
        m.deployResult = nil
        return m, fetchServices()
    case "d":
        if len(m.services) > 0 && m.cursor < len(m.services) {
            m.selectedService = m.services[m.cursor].Name
            m.state = confirmState
        }
    case "c":
        m.deployResult = nil
    }
    return m, nil
}

func (m model) updateConfirm(msg tea.KeyMsg) (tea.Model, tea.Cmd) {
    switch msg.String() {
    case "ctrl+c", "q":
        return m, tea.Quit
    case "esc", "n":
        m.state = dashboardState
    case "y

…(truncated)