Refactoring Mastery — Sprint Checkpoint Repository

This repository is the hands-on workspace for the sprint checkpoints.

Branch model

• starter: learner-facing working branch
• complete: instructor/reference branch

Why the repository is structured this way

Each checkpoint is the last spec in its milestone. The platform teaches the thinking.
The repository carries the hands-on code, tests, commits, and local workflow.

That split matters because:

1. the checkpoint should feel like real engineering work
2. learners should run tests and make commits locally
3. TypeScript and Python tracks should stay parallel, not mixed together
4. each milestone should have a clean, isolated workspace
5. starter and complete should differ only in learner task state, not in structure

Repository layout

refactoring-mastery/
├─ docs/
│  ├─ sprint-overview.md
│  ├─ repo-workflow.md
│  └─ branch-strategy.md
├─ checkpoints/
│  ├─ 01-evaluate-and-decide/
│  │  ├─ README.md
│  │  ├─ CONSTRAINTS.md
│  │  ├─ DECISIONS.md
│  │  ├─ typescript/
│  │  │  ├─ package.json
│  │  │  ├─ tsconfig.json
│  │  │  ├─ src/
│  │  │  └─ tests/
│  │  └─ python/
│  │     ├─ requirements.txt
│  │     ├─ src/
│  │     └─ tests/
│  ├─ 02-refactor-the-billing-workflow/
│  ├─ 03-add-a-feature-to-prove-extensibility/
│  ├─ 04-transform-the-pricing-engine/
│  ├─ 05-clean-up-a-tangled-service-interface/
│  ├─ 06-restructure-an-inheritance-hierarchy/
│  ├─ 07-restructure-the-codebase-without-breaking-tests/
│  ├─ 08-manual-refactor-vs-ai-refactor-side-by-side/
│  └─ 09-write-and-defend-a-refactoring-proposal/
└─ .github/
   └─ workflows/
      └─ checkpoint-ci.yml

How to work as a learner

1. Fork the repository
2. Clone your fork
3. Stay on starter branch
4. Move into the milestone checkpoint you are currently on
5. Choose typescript or python
6. Write characterization tests
7. Make the required safe structural change
8. Commit your work
9. Compare against complete only after finishing

Milestone design rule

Every milestone gets exactly one checkpoint workspace:

• one scenario
• one decision document
• one TypeScript implementation
• one Python implementation
• one consistent task contract

That makes the repository predictable, which is important because predictability reduces learner navigation cost.