Milestone 1 — Project Charter & Engineering System

“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)

Chapter: Chapter 1 — The Hats You Will Wear Week: 1 of 16 · Phase: Inception · Hat: Project manager (with a little release engineer) Due: End of Week 1. The commit history must show work on at least three distinct days — this deliverable cannot honestly be produced in one sitting, and the history is part of the evidence. Submit: A link to your repository, plus the Week-1 quiz on Canvas. Nothing is submitted as an attachment; the repository is the submission, this week and every week. Where it lands in the final package: docs/charter.md, docs/hours-log.csv, docs/ai-usage.md, README.md v0, and the repository structure itself. These feed the Week-16 rubric lines for the hours log, the ai-usage log, the README, and repository hygiene — and every later document in docs/ slots into the tree you build this week. AI policy: Open, and governed by the policy you write in this milestone. Green-zone use is free. Any Amber-zone use — including using an assistant to draft your calendar, your risk table, or your .gitignore — must appear in docs/ai-usage.md with all six columns filled. The charter’s §4 (definition of finished), §5 (non-goals), and §6 (risks) must be your own words about your own life; generated text there is a Red-zone violation, and it is obvious to read.

The Setup

It is Monday of your first week at a small company. You are the only engineer. There is no product specification on your desk, because nobody has decided what to build yet — that meeting is next week.

What do you do with the week?

The amateur waits. The professional sets up the shop. By Friday there is a repository with a structure that has a place for everything the project will need, a board with a limit on it, a log that will know where the hours went, and a written agreement about how the work will be done — including how the powerful new tool in the corner is allowed to be used. When the specification arrives on Monday, no time is spent on any of that. It is already there.

That is this milestone. It is the least glamorous week of the semester and it is the one that most reliably separates the capstones that finish from the capstones that get apologized for in December. You are laying a foundation in public, with a timestamp on every commit. Before you lay it — sit down and count.

Learning Targets

You will demonstrate that you can:

• Stand up an engineering system — repository, board, and log — that is stack-agnostic and ready before the work arrives.
• Write a charter whose purpose, definition of finished, and non-goals are specific enough that a stranger could check them.
• Count the cost honestly: audit your real capacity, name the weeks that are already broken, and decide in advance what you cut when you fall behind.
• Measure your own work with a log disciplined enough to produce a real estimate-to-actual ratio.
• Set an AI policy in writing before the pressure arrives, and disclose use in a form that constitutes evidence of judgment rather than a confession.
• Communicate state to a stranger in a README that answers what, who, where, and how.

The weekly status block — paste this into your submission comment

Every milestone submission carries these five lines. It takes two minutes, it is the same five lines every week, and it is the difference between an instructor who can help you in Week 6 and one who finds out in Week 14. Copy it into the Canvas submission comment when you submit — not into a document.

Shipped:     what actually works this week, in one line
Cut:         what I dropped or deferred, and where it went (backlog / change request / gone)
Hours:       planned N / actual N        (from docs/hours-log.csv)
Blocked on:  the one thing in my way, or "nothing"
Ship confidence: green | amber | red — if amber or red, the one thing that would move it

Say red when it is red. A red in Week 6 is a conversation and a scope cut. A red discovered in Week 15 is a grade. Nobody has ever been penalised in this course for an honest amber; the only expensive answer is the green that was not true.

Normal Tier

Required deliverables

1. A repository, on GitHub, containing the canonical structure from §1.5 of the chapter — every docs/ slot created with a placeholder, plus src/, tests/, .github/workflows/, .gitignore, and a LICENSE file or a dated deferral note. Commit history spans at least three distinct days.

2. docs/charter.md, from the provided template code/charter-template.md, with all eight sections completed except §2 (the project itself), which is marked <fill in Week 2>. In particular:

   • §1 Purpose — two or three sentences, verifiable, naming what will be true at the end.
   • §3 Capacity and constraints — every row filled, including administrator rights, money, and the two broken weeks.
   • §4 Definition of finished — three to six bullets someone else could check.
   • §5 Non-goals — at least five, each specific enough to point at in Week 10.
   • §6 Risks — at least three, each with an early warning sign and a response.
   • §7 Working agreement — including your ranked cut order for when you fall behind.

3. A project board, live, with five columns, an enforced work-in-progress limit, and at least six well-formed cards — each with an estimate, a hat, and a stopping condition.

4. docs/hours-log.csv, from the provided template code/hours-log.csv with the sample rows deleted, containing at least five real session rows totalling at least ten hours, each with estimate_hours filled in before the session began.

5. The hours report, code/hours_report.py, copied into tools/ and runnable against your log. Its total must match your log.

6. docs/ai-usage.md, from the provided template code/ai-usage-template.md, with a completed policy header — the spine rule, the zones, and the “Tools I have decided to use” table, which is filled in with the tools you have actually decided on or carries a single dated line saying you have decided to use none — plus either at least two real entries with all six columns filled or, if you genuinely had no Amber-zone use this week, one dated line under Entries saying so.

   This deliverable is graded the way Appendix C grades it in Week 16: on specificity, not on abstinence. Nobody is required to buy, install, or use an assistant to earn these points, and nobody is penalized for working without one — the log loses points for vagueness and for undisclosed use, never for a small number of honest entries. If you do want an assistant, several vendors have offered free, browser-reachable tiers, but those terms change without notice: check the current terms on the vendor’s own page before you rely on one, write down the date you checked, and put its expiry on the free-tier watch list in Appendix A §A.10 with everything else.

7. README.md v0 — what this repository is, who owns it, its current status, how to navigate docs/, and what is intentionally not here yet.

The bar, shown

This book’s promise is that you never have to guess what “good” means. Here is the charter, four times, wrong and then right.

§1 Purpose — bad

The purpose of this project is to create an innovative, user-friendly application that leverages modern technologies to solve real-world problems and demonstrate my skills as a software engineer.

Nothing in that sentence can be checked. “Innovative” by whose measure? “User-friendly” tested how? “Real-world problems” — which one, for whom? At the end of the semester nobody, including you, can say whether it happened.

§1 Purpose — good

By the end of Week 16 I will have shipped one small system that a person who has never met me can clone from GitHub, run by following the README on a machine I have never touched, and extend by picking up the next item on the board. Alongside it will sit the requirements, design, test, and handoff documents a professional team would expect. Success is not that the software impresses anyone; it is that a stranger can take it over.

Three checkable claims, one named test, and a stated definition of success that a grader and a stranger would evaluate identically.

§5 Non-goal — bad vs good

§6 Risk row — bad vs good

The bad row is a feeling. The good row is a plan with a date, a signal, and a named consequence — and it was written in Week 1, when it was cheap.

What this milestone feeds

Read that table as the answer to “why does this matter, it’s only Week 1.” Nothing here is a warm-up. Every row is a line item you are being graded on in December, opened early.

Normal-tier rubric (out of 100)

Medium Tier (+ up to 25% extra credit)

Pick what fits. Each of these buys you something real in a later week.

• A structure-check workflow. A minimal GitHub Actions job that fails if any canonical docs/ path is missing. Nine lines of YAML, and it means Week 9’s continuous integration is not the first time you have seen the tool.
• Issue and card templates. A repository issue template that forces a requirement identifier, an estimate, and a stopping condition on every card you will ever create. This makes it harder to create a bad card, which is worth more than remembering to.
• A pace tripwire. Add a --budget check to your weekly routine and write, in the charter, the specific cumulative-hours number at Week 4, Week 8, and Week 12 below which you will escalate — to your instructor, by name, in an email you have already drafted.
• A commit-message convention, documented and enforced. A CONTRIBUTING.md (yes, for a repository with one contributor) stating the FR-nnn: subject convention, plus a commit-msg hook that rejects messages without one.
• A calibrated estimate baseline. Log ten estimated-then-measured sessions this week instead of three, and report your ratio with the range, not just the mean. You will use this number in Week 7 and it will be the only real data you have.

Hard Tier (+ up to 25% additional extra credit)

Write the Cost Memo — two to three pages, addressed to your instructor, that does what no assistant can do for you, because every sentence in it requires knowing your own life and being willing to say something unflattering about it.

Cover all five:

1. The honest capacity audit. Not “I have fifteen hours.” Where do they come from? What are you giving up to get them? Name the specific commitment — a shift, a club, a game, a relationship’s regular evening — that will contest those hours in Week 10, and say what you will actually do when it does.

2. The two broken weeks, resolved. Name them, say why, and show the hours moved forward into a specific earlier week. Then say what happens if the move does not work.

3. Your ranked cut order, decided while it is cheap. When you are three weeks behind in Week 12, what is the first thing you cut? The second? The third? What will you not cut under any circumstances? Defend the ranking against the obvious objection: that the easiest thing to cut is always the documentation, and the documentation is most of what the 50% final is made of.

4. Your personal failure mode. Of the four in §1.1 — the late start, the oversized idea, the undocumented pile, the invisible process — which one is yours? You know. Say why, with evidence from a past project. Then design a tripwire: a specific, observable, dated signal that would tell you it is happening again, and name the person you will tell when it trips.

5. The AI line, in advance. Describe the specific moment this semester when you expect to be tempted past the line you drew in §1.8 — the actual week, the actual pressure, the actual shortcut. Then write the answer you commit to now. A policy that has not imagined its own violation is not a policy.

Graded on honesty, specificity, and self-knowledge. A polished memo that could describe any student earns nothing. A plain memo that could only describe you earns full credit.

Submission

Push everything, then submit the repository link and take the Week-1 quiz.

capstone/
├── README.md                 # v0 — what, who, status, navigation
├── LICENSE                   # chosen, or a dated deferral note inside
├── .gitignore
├── docs/
│   ├── charter.md            # the milestone's centerpiece
│   ├── hours-log.csv         # ≥5 real rows, ≥10 hours
│   ├── ai-usage.md           # policy header + ≥2 entries, or a dated no-use line
│   ├── adr/                  # empty, with .gitkeep
│   └── …                     # placeholders for every later week
├── src/                      # empty, with .gitkeep
├── tests/                    # empty, with .gitkeep
├── tools/
│   └── hours_report.py
└── .github/workflows/        # empty this week; Medium tier adds one

Plus, if you attempted it: docs/cost-memo.md (Hard tier).

Hints

• Do the charter’s §5 before §1. Non-goals are easier to write than purposes, and writing them first tells you what your purpose actually is. This trick works on every specification document you will ever write.
• Fill the capacity table with a calendar open. Not from memory. Memory is optimistic about Tuesdays.
• Write the log rows as you go, tonight. If you find yourself reconstructing Wednesday on Friday, that is the habit forming, and it is the wrong one. Mark reconstructed rows honestly; an admitted gap costs almost nothing and a fabricated row costs everything.
• Your first purpose statement will be bad. Everyone’s is. Write it, walk away, and rewrite it the next session — then log the rework. Rework logged is a sign of a working process, not a wasted hour.
• Do not choose your license by asking an assistant. Read the actual text at spdx.org/licenses or use choosealicense.com, and check whether your institution has a policy about student work. If you are not ready, write LICENSE with a dated line saying the decision is deferred to Week 5 and why. A dated deferral is a decision; an empty file is not.
• Six cards is a floor, not a target. But do not put forty on the board this week. A board you cannot see the bottom of stops being a plan and becomes a source of dread.

What Mastery Looks Like

A mastered Milestone 1 is boring to read and impossible to argue with.

The purpose statement names something checkable. The non-goals are specific enough that they will actually stop something — “no mobile client; web only, one browser target” rather than “I won’t over-engineer it.” The capacity table admits an inconvenient truth: that Thursdays are gone, that the laptop has no administrator rights, that eight of the fifteen hours are already spoken for by another course in Week 11. The risk table names a risk that is about the student, not about technology. The hours log has an odd number in it — 2.25, not 3 — because it was written from a clock rather than a memory. And the AI policy reads like something written by someone who intends to keep it, with a “never” column that has real things in it.

The tell is always the same. A mastered charter contains at least one sentence that was uncomfortable to write. A weak one contains none, because it was written to be read rather than to be true.

Coach’s Note — Nobody will audit your hours log. No grader can prove that a 2.5 was really a 2.0. That is exactly what makes it a measurement of you rather than of your project. Sixteen weeks from now the log will either be a record you can point to in an interview — “here is how long a system like this actually takes me” — or a small fiction you had to keep consistent. One of those is worth having.

When You’re Done

• Repository created; canonical tree committed; history spans ≥3 distinct days
• README.md v0 answers what, who, status, navigation, and what is deliberately absent
• Charter §1, §3, §4, §5, §6, §7 complete; §2 marked for Week 2
• At least five non-goals, each specific enough to point at later
• At least three risks with early warning signs and responses
• Ranked cut order written down before you need it
• Board live: five columns, WIP limit enforced, ≥6 cards with estimates and stopping conditions
• docs/hours-log.csv has ≥5 real rows, ≥10 hours, with pre-written estimates
• tools/hours_report.py runs from a clean clone; the total matches the log
• docs/ai-usage.md policy header complete, tools table decided (or a dated “none”); ≥2 six-column entries, or a dated line recording no Amber-zone use
• Licensing decided, or deferred with a date and a reason
• Fifteen weeks blocked on a real calendar; the two broken weeks resolved forward
• Clean-clone smoke test passed (the last rep in the exercises)
• Week-1 quiz taken

A theological footnote. “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). Jesus asks that question on the way to a much larger point — that following him costs everything, and that the crowd trailing after him should know it. He is not giving project advice. But he builds the point on something he assumes every listener already understands: that a half-built tower is a public grief, that the wise builder sits down first, and that the shame is not in being unable but in beginning without knowing. Counting the cost is therefore a humble act, not a timid one. It requires you to look squarely at your own limits, which is precisely what the capacity table in §3 of your charter makes you do, and precisely what every optimistic student avoids. Do it now, while the cost of an honest answer is only a smaller project. And take the comfort that belongs to it: the tower we could never finish, the debt we could never count, was paid by someone who did finish — “It is finished” (John 19:30, ESV). That is why we can afford to be honest about the small things we cannot do. Our standing does not depend on our estimates being right.