Appendix A — The Fast-Start Workbench

“For which of you, desiring to build a tower, does not first sit down and count the cost, whether he has enough to complete it?” — Luke 14:28 (ESV)

Week 1 of an eight-week course cannot be spent installing things. That is the whole design constraint of this appendix, and everything below is bent to it. You have 160 hours across eight weeks, about twenty a week, and Chapter 1 already spends most of Week 1 on the decision that actually matters — which brief you adopt and how far you cut it. The bench is not the work. The bench is the thing that must be standing before Monday afternoon so the work can start.

So here is the promise: the whole workbench goes up in one sitting, in under two hours, on day one, on a laptop you do not own and cannot install software on. Not a weekend. Not a hundred dollars. One sitting.

It is small because it is only five things, and one of them is a decision. You choose where you work — a browser or your own machine — and then you build four pieces, none of which cares what language you eventually write:

1. A repository with the canonical structure, because every milestone lands in a named slot inside it.
2. A project board with a limit on it, wired to requirement identifiers from Week 2.
3. An hours log in version control, because Chapter 1 §1.6 grades honesty and Week 4 grades pace.
4. A diagramming tool whose source you can commit, because Week 3 asks for architecture diagrams inside a specification.

Path A installs nothing. No administrator rights, no BIOS setting, no sudo, no download. It works from a locked-down school or work laptop, a Chromebook, a borrowed machine, or a library computer, and it is the default — not the consolation prize. Read on and you will see why it is often the stronger setup: a browser student’s environment is defined by a file in the repository, which means a grader can reproduce it, which is exactly what Week 7 tests. Path B is a local toolchain on a machine you control. Faster, offline-capable, and it needs rights a school laptop very often does not grant. Read A.1, pick, build, and then run the verification pass in A.12 before Friday.

Two things run through every section.

Every price, version, allowance, and free-tier limit here is approximate and dated to 2026. Vendors change them without warning and without apology — one large cloud provider halved a well-known free allotment mid-2026 in a quiet blog post. Treat every number below as a snapshot that tells you the shape of the thing, then read the vendor’s own page before you commit money or a deadline to it, and write the number down with the date you checked it. That habit is not pedantry; it is a graded line in Week 7, when docs/handoff.md has to tell a successor what this system costs to run.

Do the work yourself. Ask an assistant to explain a push rejection — that is the green zone in Chapter 1 §1.8 and it is a good use of it. Do not paste a setup script you do not understand into a terminal and call the bench built. And never take a free-tier limit, a price, or a license term from a model: those are exactly the facts it invents most fluently.

A.0 — The Two-Hour Clock

This is the sitting. Do it in this order; each row assumes the one above it exists.

The verification pass in A.12 costs another twenty minutes and belongs later in the week — Thursday, not Monday, when there is something real to verify. Chapter 1 §1.12 budgets 2.5 hours for this appendix across the whole week: these 105 minutes, that verification pass, and the time you spend reading. If you find yourself in hour four, stop and re-read A.1 — you have wandered onto Path B without the rights to finish it.

Coach’s Note — Do not do row 8 last because it looks optional. It is the row that tells you, on day one, whether your institution has disabled the thing Week 3 depends on. Finding that out on the Monday of Week 3, with a walking skeleton due Friday, costs you a quarter of a milestone. Finding it out today costs you ten minutes and an email to your IT desk.

A.1 — Choose Your Environment

Be honest about the machine and the permissions you actually have. None of this is about ambition.

The compression fact that changes this appendix. In the sixteen-week edition you do not have to run a line of code until its Week 9 — more than half the term to sort out compute. Here the walking skeleton is due in Week 3, which is 37% of the way in. You do not have to provision everything on day one, but you do have to know your compute path on day one and prove it works before Week 3 starts. That is row 8 of the clock, and it is why it is in the first sitting rather than deferred.

Milestone → minimum environment

The left column is what the course asks; the right is the smallest environment that can deliver it. Read down it and notice how much of an eight-week capstone is a browser and a text file.

What you do not need for this course. No GPU. No expensive laptop. No paid editor. No paid diagramming tool. No domain name. No paid continuous-integration plan. No container-desktop licence. If somebody tells you a senior capstone requires you to buy hardware, hand them this table.

Coach’s Note — The most expensive mistake available to you this week is provisioning for Week 7. Students spin up a managed database, a hosting account, and an API key on day one — before there is a design, sometimes before there is a project — and by Week 6 one of the three has changed terms, lapsed, or started billing. Stand up the backbone now. Add each service in the week its milestone actually needs it. In an eight-week course that window is narrow, not absent: the decision is Week 3, the host is Week 7.

A.2 — Path A: The Browser-Only, No-Admin Path (the default)

Nothing installed. Everything below runs in a browser tab on a machine you do not own.

Step 1 — A GitHub account (15 minutes, and ten of them are the Pack)

Sign up free at https://github.com. Use an email that still works after you graduate; your capstone repository is a link you will send a hiring manager eighteen months from now, and a dead school address is a locked account.

Free personal accounts have for years included unlimited public and private repositories, the built-in Projects boards, and Actions minutes — unmetered for public repositories, with a monthly included allowance for private ones. That has been stable, but tiers change; confirm current terms at https://docs.github.com before you depend on any of it. If your institution provides accounts or a GitHub Classroom organization, prefer it and ask one question in writing up front: does the account survive graduation, and can you transfer the repository out? If the answer is no, keep the capstone on a personal account and add your instructor as a collaborator.

Then verify your student status at https://education.github.com/pack. The Student Developer Pack bundles free and discounted offers from a rotating set of vendors — the contents change constantly, so I will not tell you what is in it, only that it is the highest-return ten minutes in this appendix. Several things A.9 tells you to pay for may already be free to you, and in a 160-hour course, ten minutes that removes a Week-7 hosting bill is a good trade.

Step 2 — The browser editor (5 minutes)

For Weeks 1 and 2 you are writing documents, not running code. GitHub ships an editor for exactly that: open any repository you own and press the . key. A full editor opens in the tab — file tree, search, multi-file edit, commit and push from the sidebar. Nothing installs. It works on a Chromebook and on a laptop whose IT department has locked everything down.

Know its one limit so it does not surprise you: it is an editor, not a computer. No terminal, nothing executes. Fine for docs/charter.md; useless for a walking skeleton, which is why there is a Step 3 and why Step 3 happens today.

Step 3 — A cloud development environment (10 minutes today; the workhorse from Week 3)

From Week 3 you need something that executes code, installs dependencies, and runs a test suite. The default recommendation is GitHub Codespaces: a Linux container running a full editor in your browser, with a real terminal, launched from your repository in about a minute. You are root inside it. No admin rights on your laptop are involved at any point.

As of 2026 a free personal account has included a monthly allowance on the order of 120 core-hours and 15 GB of storage — roughly 60 hours a month on a two-core machine. Verify that in GitHub’s current billing documentation. Two things bite students, and both bite harder in a course this short:

• Storage bills on stopped environments, not just running ones. Delete environments you are done with; do not merely stop them. A forgotten codespace quietly eats the allowance you wanted for Week 6.
• The disk is not backup. Anything not committed and pushed can vanish. Commit at the end of every session — which you owe anyway, because Milestone 1 grades a commit history spanning at least three distinct days.

The piece that makes this better than a local setup: in Week 3, when you know your stack, commit a .devcontainer/devcontainer.json describing the environment — base image, language version, extensions, and a postCreateCommand that runs script/setup. The environment stops being a private fact about your laptop and becomes a versioned artifact of the project. A grader, a classmate, or the successor you write docs/handoff.md for opens the repository and gets the identical machine. The specification lives at https://containers.dev. Do not guess at the file now — you do not know your stack until Week 3.

If your institution disables Codespaces, or you burn the allowance, three fallbacks in the order I recommend them: a browser IDE that runs real code in a tab (Replit and StackBlitz both do; free tiers vary and change — read the current terms), a hosted notebook such as Google Colab if your project is Python and genuinely notebook-shaped, or a small cloud virtual machine reached from a browser shell (A.9), which costs a few dollars a month or nothing at all.

Today, all you owe is proof: launch one, run echo hello and git status in its terminal, then delete it. Ten minutes. You now know the path exists before the week you need it.

Step 4 — Prove Path A works (part of row 4 of the clock)

1. Create a repository on GitHub. Private is fine; you can open it in Week 8.
2. Press . in it. The browser editor opens.
3. Create README.md with one real sentence about what this repository is. Commit from the sidebar with the message M1: repository created.
4. Confirm the commit shows on the repository’s main page with today’s date.
5. Open the Actions tab and confirm it is available to you. Week 3 requires it. Better to learn today if your institution has turned it off.

A.3 — Path B: The Local Path (needs admin rights and your own machine)

If you own the machine and can install software, a local toolchain is faster, works on a plane, and consumes nobody’s monthly allowance. If you cannot get administrator rights, use Path A and do not fight it. You lose nothing that is graded, and a week spent negotiating with an IT desk is 12.5% of this term.

Set your identity once, before the first commit, or the history is attributed to somebody who is not you:

git config --global user.name  "Your Name"
git config --global user.email "you@example.edu"
git config --global init.defaultBranch main

Then authenticate pushes — pick one and stop thinking about it:

• A fine-grained personal access token, scoped to the capstone repository with contents read/write, used as the password when Git prompts. git config --global credential.helper store caches it, and note what that means: the token lands in a plain-text file in your home directory. Fine on a machine only you use; not fine on a shared one.
• An SSH key. ssh-keygen -t ed25519 -C "capstone", then paste the public file (~/.ssh/id_ed25519.pub) into your GitHub SSH keys. Never paste the private one anywhere, ever — including into an assistant.

One rule that saves Week 7: whatever toolchain you install in Week 3, pin its version in a file in the repository — .nvmrc, .python-version, .tool-versions, go.mod, whatever your ecosystem uses — and repeat the version in your README.md prerequisites. The single most common clean-machine failure is a project that runs on the author’s minor version and nowhere else.

A.4 — The Repository and Its Structure (25 minutes)

The repository is not storage. It is the deliverable. Seventy-five percent of your grade — the 50 percent final plus the 25 percent of milestones that build it — is a link to it, and every milestone lands in a named slot inside it. Build the whole tree today with placeholders so that each later week is a matter of filling a slot rather than deciding where something goes — and so that empty slots stay visible, which is the point.

The canonical layout is Chapter 1 §1.6, and it is identical to the sixteen-week edition’s, deliberately, so the two books never disagree about a path. Here is how to create it.

In the browser (Path A). GitHub’s web editor creates a directory when you type a path containing slashes. Give every file a one-line placeholder naming what it is and which week fills it — an empty file is invisible in a diff; a placeholder is a to-do list you cannot lose. One exception: docs/hours-log.csv is data, not prose, so give it the header row from A.6 and nothing else. The Week-1 check script reads that file by name and expects those columns. Git does not track empty directories, so src/, tests/, script/, docs/adr/, docs/change-requests/, and .github/workflows/ each need a .gitkeep — an empty file whose only job is to exist.

From a terminal (Path B, or inside a cloud development environment):

mkdir -p docs/adr docs/change-requests docs/diagrams docs/evidence docs/interviews \
         src tests script tools .github/workflows
touch docs/adr/.gitkeep docs/change-requests/.gitkeep docs/diagrams/.gitkeep \
      docs/evidence/.gitkeep docs/interviews/.gitkeep \
      src/.gitkeep tests/.gitkeep script/.gitkeep .github/workflows/.gitkeep

for f in charter scoping-decision ai-usage requirements definition-of-done \
         architecture plan risk-register skeleton-trace design-review \
         test-plan test-results defect-log \
         runbook clean-machine-test handoff retrospective; do
  [ -e "docs/$f.md" ] || printf '# %s\n\n_Placeholder — written in its week._\n' "$f" > "docs/$f.md"
done

# The hours log is data, not prose. Seed it with the header row, exactly this one.
[ -e docs/hours-log.csv ] || \
  printf 'date,start,end,hours,phase,hat,task,estimate_hours,blocked_hours,notes\n' > docs/hours-log.csv

git add -A && git commit -m "M1: canonical repository structure"

Three paths in there are easy to get subtly wrong, and getting them wrong is a real defect because the grader’s checklist and the two books all use the same names: script/ is singular, and it holds one-word command verbs — script/setup, script/test, script/smoke — from Week 3. docs/change-requests/ is a directory, one CR-nnn-*.md file per request from Week 4, indexed by the change table at the top of CHANGELOG.md. And docs/adr/ takes one file per decision, starting with three of them in Week 3.

Then do the two things that are cheap now and expensive later.

Write .gitignore first — before there is anything worth ignoring. GitHub publishes per-ecosystem templates at https://github.com/github/gitignore; take the one for your likely stack and add to it in Week 3. The rule to internalize today: .env never enters the repository, and Git history is permanent memory. Mechanics are in A.8.

Decide the licence, or defer it with a date. Read the actual text at https://spdx.org/licenses/ or https://choosealicense.com/, and check whether your institution claims rights in student work — many do, and it is a five-minute question now and an ugly one in Week 7. Not ready? Commit a LICENSE file containing a dated line saying the decision is deferred to Week 3 and why. A dated deferral is a decision. An empty file is a hole.

One warning about the history itself: do not delete and re-create the repository in Week 3 because the early commits embarrass you. The history is evidence, it is graded, and a repository whose first commit is dated in Week 3 of an eight-week course tells a story you do not want told.

A.5 — The Board, Wired to Requirement Identifiers (20 minutes)

A board is a queue with a limit. Without the limit it is a list, and a list of forty things is a mood.

GitHub Projects is the default recommendation because it lives beside the repository and can link a card to an issue, an issue to a branch, and a branch to the commits that closed it. That chain is what lets you answer, in Week 6, “which commits implemented FR-EXP-02?” with a query instead of an archaeology expedition. Create one from the repository’s Projects tab, in the browser, free.

Set it up once, this way:

• Five columns: Backlog, This Week, In Progress, Blocked, Done.
• A work-in-progress limit of two in In Progress. If your tool does not enforce limits, name the column In Progress (max 2) and honor it. The limit is the entire value of the board.
• Three custom fields on every card: Estimate (hours, a number), Hat (which of the seven from Chapter 1 §1.3), and Requirement (the identifier from your specification — empty this week, mandatory from Week 2).

That third field is the wiring, and in eight weeks it pays back faster than anything else on this bench. From Week 2 every card carries an identifier, every branch is named for one (fr-pan-06-expiring-list), and every commit subject carries one. Two weeks of small discipline, and then Week 6’s traceability matrix and Week 7’s change log mostly write themselves out of git log.

Cards are verifiable work items, not nouns. Compare Build the backend — which cannot be finished, estimated, or moved to Done without an argument with yourself — against:

FR-EXP-02 — List items expiring within the configured window
Estimate: 3h   Hat: developer   Branch: fr-pan-06-expiring-list
Done when: FR-EXP-02's acceptance criteria pass and CI is green on main.

A size, a home, and a stopping condition. Six cards like that today, about the bench itself, and you have met the Milestone 1 requirement.

If you would genuinely rather use another tool — a Kanban service, a spreadsheet, index cards on a wall — use it, on one condition: it must survive to Week 8. A board abandoned in Week 4 is worse than no board, because it makes you feel tracked while telling you nothing. Whatever you choose, link to it from README.md so a grader can see it.

A.6 — The Hours Log (15 minutes)

docs/hours-log.csv, in the repository, under version control, from day one. Not a spreadsheet in your downloads folder, not an app on your phone, not your memory. The columns are fixed, and every later chapter refers back to them:

date,start,end,hours,phase,hat,task,estimate_hours,blocked_hours,notes

In Week 5 you add one more, ai_assisted, when Chapter 5 asks for it. Until then, these ten.

The template and the audit script both ship with Chapter 1 as companion files — week1_check.py in particular, which audits your repository against the canonical tree and prints hours by week, by phase, and by hat against the 160-hour budget with your running estimate-to-actual ratio. Copy it into tools/ and run it every Friday:

python3 tools/week1_check.py --root . --log docs/hours-log.csv

Path A students: you can maintain the log entirely in the browser. Edit the CSV in GitHub’s web editor and commit — sixty seconds at the end of a session, and the commit timestamp is itself a small piece of evidence. To run the script without a local Python installation you have two options. Open a cloud environment for two minutes and run the command above. Or — better, and it doubles as continuous-integration practice two weeks before Week 3 needs it — add a workflow at .github/workflows/hours.yml that runs the same command on every push and prints the report in the Actions log. Then your weekly total and your structure audit are one click away from any browser, forever. Actions is unmetered for public repositories and metered on private ones; check your current allowance before you schedule anything to run on a timer.

The rules that make the number mean something are Chapter 1 §1.6, and I will repeat only the one this appendix can enforce: log at the end of the session, not the end of the week. A retro-filled log is fiction with a file extension. Put it wherever you will actually reach it — a pinned browser tab, a terminal alias, a phone bookmark to the file on github.com, which is editable from a phone if that is what it takes.

Coach’s Note — “A false balance is an abomination to the LORD, but a just weight is his delight” (Proverbs 11:1, ESV). Nobody audits this file. No grader can prove your 2.5 was really a 2.0. That is exactly why it measures you rather than your project — and in a course where one week is an eighth of the term, it is also the earliest instrument that can tell you that you are behind while there is still time to cut.

A.7 — A Diagramming Tool Whose Source You Can Commit (10 minutes)

Week 3 requires component diagrams inside docs/architecture.md, and Week 7 requires an architecture overview with a diagram a stranger can read. In the sixteen-week edition that pressure arrives at its Week 6. Here it arrives in Week 3, which is why you prove the tool works today rather than the night before.

One requirement eliminates most of what students reach for first: if you cannot commit the source, it is not a tool you can use in this course. A photograph of a whiteboard does not diff. A drawing locked inside a service you will stop paying for does not survive the handoff. Your successor needs to edit the diagram, not admire it.

House convention, matching Chapter 3 and Chapter 7: commit both the source and the rendered image, under docs/diagrams/. The source so it can be edited, the image so it displays anywhere — including in a presentation slide in Week 8 and in a PDF nobody can regenerate. Name files for what they show: context.mmd and context.svg, not diagram2-final-FINAL.

Start with Mermaid unless you have a specific reason not to. Nothing installs, it renders where the grader is already looking, and — the property that actually matters — when the architecture changes in Week 6, the diagram shows up in the same pull request as the change. Diagrams outside version control go stale silently, and a stale architecture diagram is worse than none, because it is confidently wrong.

Today’s proof is one three-box diagram in any Markdown file, displayed as a picture rather than as code. Ten minutes.

A.8 — Secrets and Keys, in One Page

The rule is simple and the mechanics are worth learning once: no credential ever enters the repository. Not in a config file, not in an architecture decision record, not “temporarily,” not in a commit you plan to amend. Git history is permanent public memory, and a key pushed at 1 a.m. is a key scraped by breakfast. This is also a drafted non-functional requirement in most of the Appendix B briefs — no credential at any commit in its history — so it is graded, not advisory.

Where the secret actually lives, by path:

In all four the code reads an environment variable and never knows the difference. That is the point: one code path, four storage locations, no if statements about where you are running.

Commit a .env.example listing every variable your application reads, each with a placeholder value. It doubles as documentation and it is what makes the clean-machine test possible in Week 7. The rule that goes with it: your application must start with only .env.example values plus a local data store. If it cannot, your README’s promise is a lie and a grader will find out.

Two mistakes, both expensive:

• Never echo a secret in a CI step, never dump the whole environment, and never enable shell tracing in a step that touches one. Providers mask registered secret values in logs on a best-effort basis, and that masking does not survive you transforming the value.
• If a secret is already committed, rotate first, clean second. Revoke the credential at the provider and issue a new one before you touch the history. Rewriting history does not reach forks, clones, caches, or anybody’s terminal scrollback. Rotation is the fix; cleaning history is the tidy-up. Then log the incident — Week 4’s design review asks.

A.9 — What Your Project Adds, and the Week to Add It

The backbone above is free and universal. Your project may want more. Read the relevant paragraph in the week the milestone needs it — the compressed calendar makes that window narrow, not optional.

A data store. Start by asking whether you need a server at all. For a single-user or small-group capstone, an embedded database in a file — SQLite is the usual answer, DuckDB for analytical shapes — costs nothing, installs nothing, needs no account, no host, and no credentials, and it survives the handoff perfectly because it is a file with a schema in migrations. Several Appendix B briefs say exactly this. If you genuinely need a client-server database — concurrent writers, a hosted deployment, a type your embedded option cannot express — free tiers of managed Postgres and MySQL exist from several vendors, and the Student Developer Pack often includes credits. Whichever you choose: read the current terms yourself, write down what happens when they end, and put it on the watch list in A.10. Note what the decision costs you here that it would not cost in a longer course — a managed database is a second new thing, and Chapter 3 caps your novelty load at two.

A place to host it. Chapter 7 covers what “deployed” honestly means for each shape of project, and the short version is that not every project needs a server. A static site or client-only application deploys to free static hosting wired to your repository — GitHub Pages is free for public repositories, though terms change; verify. A command-line tool “deploys” as a tagged release with a built artifact attached, and hosting one to look impressive wastes hours you do not have. A web application with a data store is the one shape that reliably costs something, and the cheapest paths that work are a small platform-as-a-service hobby plan or one small virtual machine. As a rough shape, as of 2026, all of it to be verified on the vendor’s own page: a small virtual machine from a budget provider runs about $4–6 a month (Hetzner has been near €4; DigitalOcean, Linode, and Vultr in the same neighborhood); Oracle Cloud has offered an Always Free ARM instance, approximately 2 cores and 12 GB of memory in mid-2026 after a cut from a more generous earlier allotment; and Azure for Students has offered around $100 of credit with no credit card required for verified students, renewable while enrolled. Reach any of them with no admin rights at all: ssh ships inside Windows 10 and 11 and macOS, and the vendors’ browser shells need nothing installed whatsoever. Write the number and the date you read it into docs/handoff.md; never quote a free tier from memory into a document that gets graded.

A model API, if your project has an AI feature. Prices, free allowances, rate limits, and context windows change more often than anything else in this appendix and vary by vendor, plan, and region, so this book gives you no number. Read the vendor’s own pricing page, write it into your assumptions with the date, and re-check before Week 7. Four controls that hold regardless of vendor: develop against the smallest model that exhibits the behavior you are testing; cache responses during development so you are not paying to re-run one prompt forty times; stub the client in your automated tests and put real-provider tests behind a flag you run by hand, or CI will bill you on every push; and set a spending limit if the vendor offers one. A small model running locally is a legitimate zero-marginal-cost development path if you have the machine for it — but a hosted CI runner cannot reach a model on your laptop, so anything CI must exercise is stubbed or pointed at a hosted endpoint.

Anything else. Two rules. Do not buy it before Week 3, when your design has justified it in writing. And if it costs money you do not want to spend, that is a constraint — it goes in your requirements as one and is graded as one. A capstone shaped honestly around a real limitation earns more than a capstone that pretended the limitation away and ran out of money in Week 6.

Coach’s Note — The sentence I want you able to say in your Week-8 presentation is: “Here is what this system costs to run, per month, and here is what happens when the free tier ends.” Every student who can say that has a project somebody could actually take over. Every student who cannot has a demo. The difference is about thirty minutes of reading vendor pages, done in the right week.

A.10 — The Free-Tier Watch List and the Teardown Checklist

Free tiers end. They sleep after inactivity, they expire on a date, they get halved in a quiet blog post, they convert to paid at a threshold nobody told you about. The failure is always the same and always at the worst time: it is Week 6, your integration works, and the service your project depends on has stopped answering.

The fix is a table, started the day you create your first account. Keep it in docs/handoff.md — the placeholder already exists from today’s scaffold, it is a required section there in Week 7 anyway, and starting it now costs nothing.

Fill in real numbers from the vendor’s page — not from a blog post, and not from an assistant, which will state expired limits with total confidence. Then set two reminders: one in Week 4, where the design review’s environment audit asks whether your bench still works and when your free tiers end, and one in Week 7, before you write the handoff. Every row also becomes a risk-register row in Week 3 with an expiry date on it; Chapter 4’s review checklist looks for exactly that.

Notice the last column. It is what turns a billing detail into a design requirement: if the answer to “what breaks” is “the whole system, silently,” you have found a non-functional requirement and a risk, and you found them in Week 3 instead of Week 6.

The teardown checklist

Anything you provision gets torn down when you are done with it. Run this every time — after a spike, after a rented machine, after a cloud environment, after the term:

1. Pull off anything you need first. Data, logs, a final database dump, screenshots for the presentation. Once it is deleted it is gone.
2. Delete, do not merely stop. A stopped virtual machine can still bill for its disk; a stopped cloud development environment still bills for storage.
3. Revoke the keys that belonged to it, at the provider. A live key for a dead service is pure liability.
4. Check the billing dashboard the next morning and confirm the spend actually stopped — the next day, when the meter has caught up, not the same afternoon.
5. Update the watch list so the row reflects reality. A handoff document listing a service you deleted is a landmine for your successor.
6. If you set a budget alert, leave it on. It costs nothing and it is the only thing standing between you and a surprise.

Coach’s Note — Set a spending alert on every account that can charge you, the day you create it, at a number that would genuinely upset you — twenty dollars, five, whatever is real for your life. Ninety seconds. The students who get a shocking bill are never the reckless ones; they are the ones who provisioned something in Week 3, forgot it existed, and found out in January.

A.11 — A Clean Machine, When You Need One

Three weeks demand it. Week 6 tags a release candidate that must clone clean and pass ./script/test. Week 7 runs the clean-machine test that produces docs/clean-machine-test.md. Week 8 repeats it on somebody else’s machine before you submit. “Clean” means one specific thing: nothing your project installed is already there. Your laptop is not clean. It has never been clean. It carries three years of toolchains, environment variables you set in 2024, and a global package your project silently depends on.

Four ways to get a genuinely clean environment, all free:

The protocol is the same in all four: start a timer, open only README.md, follow it literally, type nothing it does not tell you to type, and write down every place you had to improvise. Each improvisation is a defect in your documentation and each one costs points in Week 8. And the rule that makes the test real: you may not fix the environment. You may only fix the README. The moment you reach past the document to make something work, you have stopped testing and started rehearsing.

A.12 — Verify the Whole Workbench Before Week 1 Ends

This is the acceptance test for your bench. Run it Thursday of Week 1, before the milestone is due. Twenty minutes, and it is the cheapest version of a test you will run three more times this term in far more expensive weeks.

Every path — the eight checks that must pass:

1. The repository exists on GitHub and you can reach it from a browser you are not signed into as yourself. If it is private, confirm your instructor’s access instead.
2. The canonical tree is committed. From the file view, or from a terminal, ls -R docs shows every slot from Chapter 1 §1.6, each with a placeholder — and script/ is singular, and docs/change-requests/ is a directory.
3. You can commit from where you actually work. Change one line in README.md, commit, and see it on github.com within a minute. Path A: from the browser editor. Path B: with git push.
4. The history spans more than one day. Milestone 1 requires work across at least three distinct days. If today is your first day, this is a reminder rather than a failure — but it is a reminder with a deadline on it.
5. The board is live and linked. Five columns, a stated work-in-progress limit, at least six cards carrying an estimate, a hat, and a stopping condition — and a link from README.md.
6. The hours log has real rows, each with estimate_hours filled in before the session, and the check script agrees with the file.
7. A diagram renders. A three-box Mermaid diagram in any Markdown file, displayed by GitHub as a picture rather than as code. You are not designing anything yet; you are proving the tool works two weeks before Week 3 depends on it.
8. The clean-clone smoke test passes. This is the one that matters most.

git clone <your-repo-url> /tmp/bench-check
cd /tmp/bench-check
ls -R docs                                        # the whole tree is really there
python3 tools/week1_check.py --root . --log docs/hours-log.csv

Then read your own README.md as if you had never seen the project. Can you tell what this is, who owns it, what state it is in, which brief it came from, and where to look next? If not, fix the README, not your memory. Delete /tmp/bench-check when you are done.

Path A students, do the equivalent: create a new cloud development environment from the repository — not the one you have been working in — and confirm the tree, the log, and the report are all there. Then delete it. That is the same test, and it is closer to what Week 7 will do to you.

Two extra checks on Path B:

git --version && git config --get user.name && git config --get user.email
git log --oneline -n 5        # your commits, attributed to you, with real dates

And one check that belongs only to this edition: open a terminal — in the cloud environment or locally — and run one command in the language you think you will use in Week 3. Not a project. One command that proves the runtime exists and you can reach it. If Week 3’s stack decision goes somewhere else, fine; you have lost ninety seconds. If it does not, you have removed the single most common Week-3 surprise in an accelerated course.

If every check that applies to you passes, the bench is real and you can stop thinking about tooling until Week 3. That is the actual goal: a bench you never have to think about again. Write down in your charter’s capacity section which path you took and whether you have administrator rights — Chapter 3 and Chapter 7 will both ask, and the answer changes what you should promise.

A.13 — Counting the Cost, Applied to a Bench

“For which of you, desiring to build a tower, does not first sit down and count the cost, whether he has enough to complete it?” — Luke 14:28 (ESV)

That verse opens Chapter 1, and that chapter is careful to say what it is actually about: Jesus is telling a crowd that following him is not a casual affiliation, and the half-built tower is a picture of someone who signed up without understanding the price. It is not a project-management proverb. But it works as a picture precisely because his hearers already knew something true about human labor — that a wise builder sits down first, and that the shame lands not on the one who could not, but on the one who began without knowing.

Apply it to the smallest possible thing: a bench, on a Monday, in a course with no slack in it.

Counting the cost of a workbench means refusing two opposite temptations. The first is over-provisioning — the managed database, the hosting account, the paid plan bought in Week 1 for a project not yet designed. That is not diligence; it is anxiety wearing diligence’s clothes, and it produces exactly the Week-6 failure it was meant to prevent, because half of it lapses while you are not looking. The second is pretending the constraint away — working on a locked-down laptop and telling yourself you will figure out the environment later, which in this edition means Week 3, with a walking skeleton due Friday and no way to run code. Eight weeks does not forgive either one. Sixteen weeks might; this is the honest difference between the two editions, and it is the same difference the two-thirds rule describes about scope.

Between them sits the honest middle: name what you actually have — this machine, these permissions, this budget, these 160 hours — and build the smallest bench that holds the work. Then tear down what you are finished with. Every teardown checklist here, every “the cheapest path that works,” every “do not buy this,” is one discipline applied to resources you were entrusted with rather than resources you earned. Paul makes that the standard for stewards in 1 Corinthians 4:2, and Jesus puts it in the smallest possible terms: “One who is faithful in a very little is also faithful in much” (Luke 16:10, ESV). A forgotten cloud instance billing quietly through Christmas is a very little. So is a five-dollar-a-month virtual machine you kept because deleting it felt like admitting the term was over. They are still yours to account for. And “whatever you do, work heartily, as for the Lord and not for men” (Colossians 3:23, ESV) governs the manner of the work, not its scale — which is the whole permission you need to build something small and finish it well.

There is a specific comfort here for the student reading this on a borrowed Chromebook in a library, worrying that everyone else has better equipment. They do not have a better capstone. The grade in this course is carried by requirements a stranger can verify, decisions you can defend, tests that trace to promises, documentation that gets somebody running, and a repository somebody else could take over. Not one of those costs a dollar. The most impressive project I can imagine coming out of this course — the one a hiring panel would remember — could be built end to end from the free tier described in this appendix, and the student who builds it will have learned something the student with the expensive laptop did not: how to size the work to the resources, which is most of what engineering actually is.

So sit down. Count what you have. Build the bench in one sitting, today, and then stop touching it.

The tower is the point, not the scaffolding.

See you on Monday.

Up next: Return to Chapter 1, whose milestone is the workbench you just built plus the project you are about to choose — and choose it from Appendix B, the Fast-Start Catalog. Every template and worked example for the documents that land on this bench is in Appendix C; the grading contract, the full rubric, and the submission checklist are in Appendix D; the vocabulary is in Appendix E.