# Team Build — Extended Notes

*Not rendered in the platform yet. Reference for instructors and for
future "learn more" surfaces.*

## Purpose

The capstone of `1.welcome`. By this point a cadet has used every
tool they need: `mkdir`, `echo`, `git init`, `git config`, `git add`,
`git commit`, and shell scripting with `chmod +x`. This battle forces
them to combine all of it into a single artifact — a working
automation script — and to read someone else's script for the first
time.

## Skills Demonstrated

- Composing learned commands into a sequential program
- Writing a script with a correct shebang and execute bit
- Producing exact output from automation
- Reading another cadet's code well enough to score it
- Giving and receiving honest feedback under a time limit

## Common Pitfalls

- **One commit covering all three files** — defenders forget that the
  spec says *each file commits separately*. Three commits, not one.
- **File contents with extra whitespace** — `echo` adds a trailing
  newline by default, which is fine; trailing spaces on the line are
  not. Reviewers should `cat -A` to spot invisible characters.
- **Missing or wrong identity** — `git commit` will succeed even
  without `user.name` set if a fallback is configured globally;
  reviewers should check `git -C mission config user.name` directly.
- **Hardcoded absolute paths** — `cd /Users/...` breaks the moment
  the script runs on someone else's machine. Use relative paths.
- **`MISSION READY` printed inside another message** — the spec says
  "exactly". `echo "Done. MISSION READY now."` should fail review.
- **Forgetting `chmod +x`** — script runs fine via `bash launch.sh`
  but fails when executed directly. Reviewers should test both.

## Discussion Prompts (post-battle)

Ask the pair to discuss for 5 minutes after both rounds:

1. Whose script was easier to read? Why?
2. Was anything in the spec ambiguous? How would you tighten it?
3. What would you do differently if you wrote this from scratch
   today?
4. Did you find a bug your partner missed?

## Alternative Approaches

A cadet who's seen heredocs might write:

```bash
cat > manifest.txt <<EOF
Mission Apollo
EOF
```

Both `echo "..." > file` and heredoc are acceptable. The spec
doesn't require a specific style — only that the resulting file
content match exactly.

## Why This Is the Last Block of Welcome

This is the bridge between mechanical skill (typing commands) and
real engineering (composing them, reading others' code, judging
quality). Cadets who pass this battle have proven they can act as
both author and reviewer — the foundational loop of every
collaborative codebase. Python is built on this foundation.