Ten minutes with Casework

Casework is a small sample service: a team’s case queue with a browser page, an HTTP API, and RBS build and test targets. This walkthrough adds one improvement the team asks for — an Overdue cases filter — and shows the result at every step. It assumes a project already imported from the Casework sample with a branch workspace open on cases.go.

1. Read the code (1 minute)

Open web.go (the page and its Show cases selector) and cases.go (selectCases, and the fixed demonstration date demoToday, which keeps the walkthrough repeatable).

2. Prove the baseline and see it running (2 minutes)

rbs build //:server && rbs test //:test --no-cache

Expect Test PASSED: test and Successfully passed all targets.

CASEWORK_ADDR=127.0.0.1:8177 rbs run //:server

Expect Casework demo: http://127.0.0.1:8177 (synthetic data; fixed demo date 2026-09-14); the process keeps running. Open Tools → Browser, enter that URL: the page lists four cases under All. The preview is served through ReasonOS; you never connect to the branch server directly.

3. Describe the behavior as a test, watch it fail (2 minutes)

Append to cases_test.go and save:

func TestOverdueCases(t *testing.T) {
	got, err := selectCases(sampleCases(), "overdue")
	if err != nil {
		t.Fatalf("overdue filter refused: %v", err)
	}
	if len(got) != 1 || got[0].ID != "CW-101" {
		t.Fatalf("overdue = %+v; want exactly CW-101 (open, due 2026-09-12, before %s)", got, demoToday)
	}
	for _, c := range got {
		if c.ID == "CW-102" {
			t.Fatalf("due-today case CW-102 must not be overdue: %+v", c)
		}
		if c.ID == "CW-104" {
			t.Fatalf("closed case CW-104 must not be overdue: %+v", c)
		}
	}
}

In a second terminal: rbs test //:test. Expect --- FAIL: TestOverdueCases with overdue filter refused: status must be all, open or closed — the service does not know the word yet.

4. Make the change, pass the gate (2 minutes)

Replace selectCases in cases.go:

func selectCases(cases []Case, status string) ([]Case, error) {
	if status != "" && status != "all" && status != "open" && status != "closed" && status != "overdue" {
		return nil, fmt.Errorf("status must be all, open, closed or overdue")
	}
	selected := make([]Case, 0, len(cases))
	for _, c := range cases {
		matches := status == "" || status == "all" || c.Status == status
		if status == "overdue" {
			matches = c.Status == "open" && c.Due < demoToday
		}
		if matches {
			selected = append(selected, c)
		}
	}
	return selected, nil
}

Add the option in web.go after Closed cases: <option value="overdue">Overdue cases</option>. Save both, then:

rbs test //:test --no-cache
rbs coverage //:test

Expect Result: PASSED and a line coverage above the sample’s 80% floor.

5. Preview the improvement (1.5 minutes)

In the first terminal press Ctrl-C and run the same rbs run command again (the binary is rebuilt). In the Browser panel load http://127.0.0.1:8177/?demo=2 (re-entering an unchanged URL does not reload; a changed query does) and choose Overdue cases: exactly CW-101 appears. All, Open and Closed still work.

6. Work on it together (1 minute)

Open the same branch workspace in a second browser window. In that window use Split Editor Right and open web.go in the right-hand pane (under one sign-in, a second window opening the file in the same pane position takes over the first window’s connection; the split pane is the verified way around that — see Collaboration). Turn Collab on in both windows. Type (late work) after Overdue cases in the second window: the first window shows it as it is typed — press Cmd+F there and search late work if the line is wider than the pane. Save in the second window; the branch’s file now carries the shared edit.

What this shows, and what it does not

Understand → change → verify → preview → collaborate in one workspace, with real build and test results at each step. Two windows on one login show shared editing, not two authenticated people; the sample uses synthetic data and a fixed date on purpose.

Getting Started

Build

Languages

Containers & Deploy

Infrastructure

CI & Remote Builds

Team Workflow

1. Read the code (1 minute)

2. Prove the baseline and see it running (2 minutes)

3. Describe the behavior as a test, watch it fail (2 minutes)

4. Make the change, pass the gate (2 minutes)

5. Preview the improvement (1.5 minutes)

6. Work on it together (1 minute)

What this shows, and what it does not

​1. Read the code (1 minute)

​2. Prove the baseline and see it running (2 minutes)

​3. Describe the behavior as a test, watch it fail (2 minutes)

​4. Make the change, pass the gate (2 minutes)

​5. Preview the improvement (1.5 minutes)

​6. Work on it together (1 minute)

​What this shows, and what it does not

1. Read the code (1 minute)

2. Prove the baseline and see it running (2 minutes)

3. Describe the behavior as a test, watch it fail (2 minutes)

4. Make the change, pass the gate (2 minutes)

5. Preview the improvement (1.5 minutes)

6. Work on it together (1 minute)

What this shows, and what it does not