Capstone Project Portfolio

Eight larger, self-directed projects. Each takes one to four weeks, produces something that did not exist before, and — for several of them — is a plausible upstream contribution to a real terminal.

The capstone proves you built the system. The portfolio proves you can extend it, which is the harder and more transferable skill.

The Projects

#	Project	Weeks	Difficulty	Touches
1	Sixel and the Kitty Graphics Protocol	3–4	●●●●○	DCS/APC parsing, image decoding, rendering
2	Reflow on Resize	2–3	●●●●●	The screen model, at its hardest
3	A GPU Renderer	2–3	●●●○○	`wgpu`, atlases, instanced drawing
4	A Windows ConPTY Backend	2–3	●●●●○	The `terminal-pty` boundary, tested for real
5	The Kitty Keyboard Protocol	1–2	●●●○○	Input encoding, modes, the Escape ambiguity
6	A WebAssembly Terminal Viewer	1–2	●●○○○	The core's portability, proven publicly
7	A Terminal Benchmark Suite	1–2	●●●○○	Measurement, across implementations
8	An Upstream Contribution	2–4	●●●●○	Everything, plus code review by strangers

Difficulty is about subtlety, not volume. Project 2 is the hardest thing in this book, and it is also the smallest diff.

How to Choose

If you want to…	Do
Work on rendering and graphics	1, 3
Solve a genuinely open problem	2, and 1
Prove your architecture was right	4, 6
Work on the protocol's future	1, 5
Get better at measurement	7
Contribute to open source	8 — and any of 1–7 makes a good PR
Do the least work for the most understanding	6, then 5

Recommended pairing: one building project (1, 3, 5) plus one proving project (4, 6, 7). The first shows you can add features; the second shows the foundation holds.

The Shape of Every Project

Each page follows the same structure, and your write-up should too:

   1. THE PROBLEM        what does not work today, concretely
   2. WHY IT IS HARD     the part that is not obvious
   3. THE DESIGN         with the alternatives you rejected
   4. MILESTONES         3-5 checkpoints, each independently demonstrable
   5. THE TESTS          how you know it works, mechanically
   6. THE MEASUREMENT    numbers, with the method
   7. WHAT YOU LEARNED   including what you got wrong

Ground Rules

Every project must:

Preserve the boundaries. Run scripts/boundary-audit.sh before and after. A feature that breaks a boundary is a feature implemented in the wrong crate.
Ship tests. New behavior means new unit tests, and at least one golden case.
Be measured. Not "it feels faster" — a number, and how you got it.
Be documented. A README a stranger could use, and a note about what you did not implement.
State its trade-offs. Every design has costs. Naming them is the deliverable that separates an engineer from someone shipping a feature.

And the meta-rule: pick the project you are most likely to finish. An implemented Project 6 is worth more than an abandoned Project 1.

The Write-Up

1,500–2,500 words per project. Shorter than the capstone write-up, same standard:

What I built, and what I deliberately did not.
The design decision that mattered most, with its alternatives.
The hardest bug, and what belief of yours was wrong.
The numbers.
What I would tell someone starting this tomorrow.

If the project became a PR, link it and summarize the review feedback. Reviewer comments are the most valuable paragraph you can write — they are the outside view of your work, which is exactly the thing you cannot generate yourself.

A Note on Scope

Every one of these can expand indefinitely. Project 1 alone could be a year. Time-box aggressively and ship the smallest complete thing:

   ✓ "Sixel images render at the correct position and size, palette only,
      no transparency, no scrolling interaction. Here are the limits and why."

   ✗ "Full sixel with transparency, animation, scroll integration, and
      the kitty protocol too."  ← eight months, never finished

A finished narrow thing with honest limits beats an unfinished broad one. That is true here and it is true at work.

Start with Project 1, or pick from the table above.

Open-Source Engineer & Contributor