Skip to content

Capstone

Capstone · prereq Containers, Kubernetes & Helm, AWS, Terraform, CI/CD, Secret Management, Observability — as relevant to the chosen project; (stretch) GitOps. · ~2–4 days

Every module up to now ends in a contained exercise and a self-check gate. The capstone changes the unit of work: one real, end-to-end project, built with everything learned so far and shipped through a real git flow, then defended decision-by-decision in an extended gate. There's no toy version of this and no partial credit — it's the synthesis exercise the whole path has been building toward.

TL;DR — in 30 seconds:

  • One end-to-end project — pick from the menu below, or bring your own — shipped through a real git flow (branch → small commits → PR), not a toy exercise. No partial credit.
  • You run the shape of every prior beat yourself, over that one project: Scope (restate + plan) → Ship (branch → small commits → PR) → Defend (extended self- or peer-run gate) → Portfolio.
  • The extended gate adds a fifth question beyond the standard four: Operate — "it's broken at 2am, walk me through your first five minutes." Provenance is graded too: blind-trusting any agent-generated chunk you can't explain how you verified is an automatic fail.

Learning objectives

By the end, the junior can:

  • Scope a real end-to-end project into a defensible plan — restating the problem and approach before writing code.
  • Ship it through a real git flow: branch → small commits → a merged PR, drawing on the tools from modules 03–21 as the project needs.
  • Defend every decision in the extended gate — walkthrough, alternative, failure/debug, provenance, and the "operate it at 2am" question.
  • Assemble a portfolio artifact (the merged change + its gate log) they can walk any interviewer through.

Format note. The capstone is integrative, so it does not repeat the five per-topic beat headings — it runs all five over one project:

  • Scope = Learn + Pair (restate the project and plan)
  • Ship = Do (the merged PR)
  • Defend = Prove (the extended gate below)
  • Portfolio + deck mastery = Retain

Its gate is a superset of the standard four — a documented exception, per the Socratic gate.

flowchart LR
    A(["Pick a project<br/>(menu or your own)"]) --> B["Scope (Learn + Pair)<br/>restate project + plan"]
    B --> C["Ship (Do)<br/>branch → commits → PR"]
    C --> D["Defend (Prove)<br/>extended gate"]
    D --> E["Portfolio (Retain)<br/>assemble portfolio.md"]
    E --> F(["Capstone complete"])
Do it with Claude

Pair, Do and Prove run in Claude Code, with the onboarding-tutor skill. Click a button to copy the exact prompt, then paste it into Claude Code in this repo.

What makes a good capstone project

Whether you pick from the menu below or bring your own, it should:

  • Touch ≥ 3 modules' worth of skills end to end — at minimum a container, a deploy target, and a pipeline; more of the roadmap is better.
  • Have a clear, checkable done (acceptance criteria written up front).
  • Be completable in a few days, not weeks.
  • Be safe to run and safe to show — no real production traffic or secrets, a sample app is fine.

Pick one, adapt it, or propose your own of similar scope:

  1. Containerize + deploy. Take any small sample app, write a rootless Containerfile, and deploy it to a dev Kubernetes cluster with a Helm chart.
  2. Pipeline it. Add a CI/CD pipeline (GitHub Actions) that builds, tests, and pushes an image on merge, with secrets pulled from a real secret store rather than hardcoded.
  3. Provision it. Write the Terraform to stand up whatever infrastructure the app needs (a cluster namespace, a database, networking) instead of clicking it together by hand.
  4. Observe it. Add metrics and logs for the running app, and build one Grafana dashboard that would actually help you at 2am.
  5. Full lifecycle (recommended). Combine the above into one project: containerize → version control + CI/CD pipeline → provision with Terraform → deploy to Kubernetes with Helm → wire up secrets → observability (metrics/logs + a dashboard) → (stretch) GitOps for the deploy step instead of a push-based pipeline.

The run

  1. Scope — restate the project, acceptance criteria, and a plan before writing code. Done when: you have a written restatement of the project, acceptance criteria, and a plan — sanity-checked with the onboarding-tutor or a peer.
  2. Ship — do the work through a real git flow (branch → small commits → PR), pairing with the tutor and delegating parts to agents but verifying everything. Done when: the project is merged as a PR through that git flow.
  3. Defend — the extended gate (below).

Common gotchas

  • Starting to code before writing down the plan. Fix: Scope isn't optional overhead — restate the project, acceptance criteria, and plan, and get a sanity-check first. Coding ahead of that is the fastest way to build the wrong thing.
  • Letting an agent write a chunk you can't explain. Fix: for every agent-generated piece, know what it was and how you verified it (tests run, output inspected, docs cross-checked) before Defend — "it looked right" is a blind-trust fail, not a pass.
  • Skipping the real git flow for speed. Fix: the done-condition for Ship is a merged PR reached through branch → small commits → PR, same as any other change — not a direct push or a single giant commit.
  • Having no named alternative for a design choice. Fix: the Alternatives gate question expects at least two real decisions, each justified against a specific alternative you considered and rejected — pick those while you work, not while being asked.
  • Assembling portfolio.md only after the gate. Fix: collect the PR link, acceptance-criteria mapping, and your provenance story as you go — reconstructing them from memory afterward is where detail gets lost.

The extended gate (superset of the standard four)

Run as a self- or peer-review (the onboarding-tutor skill in adversarial mode, or a peer standing in for it), covering the whole change:

  1. Walkthrough — every meaningful file/resource in the PR, explained.
  2. Alternatives — at least two design choices, justified against a named alternative each.
  3. Failure & debug — how it fails in production and how you'd diagnose it.
  4. Provenance — for every agent-generated chunk: what it was, and how you verified it (tests run, output inspected, docs cross-checked). Blind-trust anywhere = fail.
  5. Operate — "It's deployed and broken at 2am. Walk me through your first five minutes."

Done when: all five gate questions above have been run and recorded as a pass.

Pass = capstone complete

On pass, record it in the gate log and note which earlier modules proved weak — those are the highest-priority improvements for your own review (the Area's self-improvement loop).

Worked example (illustrative — the menu's "full lifecycle" option, filled in)

Project: "Containerize a small internal service and make it deployable to a dev cluster, with a pipeline and a dashboard." Spans: Containers (a non-root Containerfile) + Kubernetes/Helm (a minimal chart) + CI/CD (build/push on merge) + Observability (one Grafana dashboard) — 4 modules' skills, dev-only so blast radius is near zero. Acceptance (written up front): image builds rootless; helm install brings the service up in dev; a bad value is caught at helm template review; the pipeline builds and pushes on merge; a dashboard shows at least one useful signal; a rollback is demonstrated. The run: scope it → ship it through a real git flow (branch → small commits → PR) with the tutor → defend it in the extended gate → assemble your portfolio (below).

Your portfolio (what a completed capstone produces)

On passing the capstone you leave with evidence you can show any employer — assemble it as portfolio.md:

  • The capstone PR (link) + its written acceptance criteria and how each was met.
  • The gate-log across every module — each module's "defended / checked by / weak spots" line: proof you can explain your work, not just run it (this is the interview-ready evidence).
  • Deck mastery — the SE Onboarding deck themes you can recall unprompted (see module 13, Interview & Placement).
  • One AI-native provenance story — a concrete case where an agent drafted something, you verified it, and you can say exactly how you verified it.

A clean capstone gate + this portfolio = a repo and a story you can walk any interviewer through.

Done when: portfolio.md exists with all four pieces above.

Key takeaways

  • The capstone doesn't repeat the five-beat headings — it runs them over one real project: Scope = Learn + Pair, Ship = Do, Defend = Prove, Portfolio = Retain.
  • A good project touches ≥ 3 modules' worth of skills and has acceptance criteria written up front — not discovered along the way. The menu above gives a ready-made default; bringing your own is fine too.
  • Scope is sanity-checked before any code is written — restating the project, criteria, and plan first is what makes the rest defensible, not overhead to skip.
  • Ship means a merged PR through a real git flow (branch → small commits → PR) — pairing with the tutor and delegating to agents is fine, but everything gets verified.
  • The extended gate is a superset run as self- or peer-review: the standard four (walkthrough, alternatives, failure & debug, provenance) plus Operate — "broken at 2am, walk me through your first five minutes." Provenance is graded on its own: unable to say how you verified an agent-generated chunk = fail.
  • The portfolio (portfolio.md) is the interview-ready evidence: the PR + acceptance mapping, the gate-log across every module, deck mastery, and one concrete AI-native provenance story.
Check yourself — how is the capstone's extended gate different from the standard four-question gate every earlier module uses?

It's a superset run as self- or peer-review: it keeps the standard four (walkthrough, alternative, failure & debug, provenance) and adds a fifth — Operate — "it's deployed and broken at 2am, walk me through your first five minutes."

Check yourself — you used an agent to write most of a Terraform module for your capstone project. What must you be able to say about it at Defend?

Not just that it works — provenance: which parts the agent wrote, and specifically how you verified each one (tests run, output inspected, docs cross-checked). Being unable to say how you verified an agent-generated chunk is a fail, regardless of whether the code itself is correct.

Check yourself — why does a good capstone project need to be low-blast-radius rather than mission-critical?

It's likely your first time shipping something real end-to-end alone. Keeping it dev-only or in a contained area means a scoping or execution mistake costs little while the skill — scoping, shipping, defending — is still being proven for the first time.

Go deeper — curated resources

Hand-picked external material to take this topic further — the best books, courses, talks, and writing. Cost is tagged Free, Free online (full text/course free on the web), or Paid.