Lesson 8.6 · 90 minLaunch checklist and capstone

What you will have

Every item of the launch checklist is ticked with evidence in docs/launch-checklist.md, the handover document docs/handover.md is in the repository, and the student has recorded a walkthrough of one lead's full journey from ad click to the conversion reported back to the platform.

Video

The video for this lesson is not recorded yet.

Prompts used in this lesson

Part 3 — Claude audits, with evidence

Purpose: before I call this project launched, audit it against
docs/launch-checklist.md and give me evidence for every item. I will rely on
this report, so an honest "could not verify" is worth more to me than a tick.

Context: all project documents are in docs/. The live site is at [my domain].
You can run commands, read the code, query the TEST database, and load live
pages with the browser tools from lesson 1.6.

How to work:
1. Go through the checklist item by item. For each item record a status: PASS,
   FAIL, or OWNER (needs me, because it lives in an account you cannot see).
2. PASS requires evidence you produced in this session: the command and its
   relevant output, the file and line, the URL you loaded and what you observed,
   or a screenshot saved in docs/evidence/. Reading code that looks right is not
   evidence that the live site behaves right; say which of the two you did.
3. For OWNER items, write the exact steps I should take and what I should see.
4. Do not fix anything during the audit. Do not submit forms on the live site,
   do not sign in to the live admin, and do not change any data. Use the local
   test environment from lesson 8.4 for anything that writes.
5. Never print secrets. For the secrets check, report file names and variable
   names only.

Output: write the results into docs/launch-checklist.md under each item (status,
evidence, date). Then give me a summary: counts of PASS, FAIL and OWNER, the
FAIL items in order of risk to leads and to personal data, and anything in the
checklist you think is missing for this project.

Done when: every item has a status and either evidence or owner steps.

Fix the FAIL items in docs/launch-checklist.md, one at a time, highest risk
first. For each: explain the cause in one sentence, make the smallest change that
fixes it, run the build and the end-to-end tests, then re-check that item and
replace its evidence. Do not mark anything PASS without new evidence. Stop and
ask me if a fix needs a decision about content, design or legal wording.

Part 4 — The handover document

Purpose: write docs/handover.md so that a capable person who has never seen this
project can run it for a month without me.

Context: use the documents in docs/, CLAUDE.md, the code, vercel.json and the
names (never the values) in .env.local.

Sections:
1. What this system is, in one paragraph, and an updated diagram.
2. One lead's journey, step by step, naming the file or service at each step.
3. Accounts: a table of every external service - purpose, which environment
   variables belong to it (names only), where to renew its keys. Leave an
   "owner login" column empty for me to fill in.
4. Routines: weekly (docs/reports/PROMPT.md), monthly (docs/maintenance.md),
   before every push (the tests).
5. If this breaks: symptom, first thing to check, where the logs are.
6. Costs to watch: which services can generate a bill, and where the limit or
   budget for each is set. No amounts.
7. Known gaps: anything accepted in the security review or left OWNER/FAIL.

Constraints: plain language, no secrets, no invented details. If you are not
sure which account something belongs to, write a question for me, not a guess.

Done when: the file exists, every environment variable name in .env.local
appears in the accounts table, and you have listed your open questions.

Do along

Work on your own project and pause the video where a step says so. The capstone walkthrough is part of the lesson, not homework.

1. Pause after Part 2. Copy launch-checklist.md from the materials into docs/. Add or remove items to fit your business, but do not delete an area.
2. Pause after Part 3. Run the audit prompt from Part 3 with your domain. Open three PASS items at random and check that the evidence is real.
3. Run the fix prompt; answer Claude's questions; re-check each fixed item.
4. Work through the OWNER items in your accounts. Save cropped screenshots in docs/evidence/ and date each item.
5. Pause after Part 4. Run the handover prompt. Fill the owner column, answer the open questions, and test the document with a fresh session.
6. Pause after Part 5. Record the capstone walkthrough covering all seven stations, with personal data blurred. Store the video outside the repository and put its location in docs/handover.md.
7. After Part 6, commit and tag with the commands under "Recap and next".

Check your work

1. Open docs/launch-checklist.md. Expected: all twelve areas present; every item has PASS, a date and evidence; no FAIL remains, or each remaining one is listed under "Known gaps" in the handover with your reason.
2. Open docs/handover.md. Expected: every service you use is in the accounts table, and no password or key appears anywhere in the file.
3. Watch your recording. Expected: all seven stations appear in order, each visibly working, with no customer's personal data readable.

Common problems

• The audit returns every item as PASS within a minute → Claude read code and did not run or load anything → tell it: "Redo the audit; PASS needs output you produced or a page you loaded in this session. Mark the rest OWNER."
• The secrets check finds a key in Git history → it was committed at some point, even if later removed → treat the key as leaked: rotate it now as in 8.5, then ask Claude how to handle the history.
• The platform shows no returned conversion for the capstone lead → processing delay, a missing click identifier on that lead, or consent not given → check the lead's stored identifiers and the server log from 7.8; record that station later.

Homework

About 45 minutes, on your own, after the course has ended. The course is complete without it.

1. Let someone else try the handover. Give docs/handover.md and your walkthrough to one person who could cover for you. Ask them two questions they must answer from the document alone: where today's leads are, and what to check first when the uptime alert arrives. Add whatever they could not find. Done when: they answered both without your help, and the file still contains no password or key.
2. Your second weekly report. At the end of the next full week, run docs/reports/PROMPT.md again. Start by checking what the actions in your first report did. Done when: docs/reports/ holds a second dated report whose first finding refers to last week's actions, and which ends with at most three new ones.
3. Close your experiment on time. Put the end date from docs/experiments.md in your calendar now. On that day, close it as lesson 8.2 described: compare, write the result in the log, keep the winner, remove the test code, run the tests. Done when: the calendar entry exists today; on the end date, the log holds a result and names the next hypothesis.

Commit each change without a tag: git add -A, git commit -m "After the course: <what changed>", git push.

Save your work

git add -A
git commit -m "Lesson 8.6: launch checklist with evidence and handover document"
git tag lesson-8.6
git push
git push --tags