Capstone Ship & Document
- Execute the final production deploy through the pipeline and verify it with smoke tests and gates
- Finalize the four shipped documents: README, architecture doc, runbook, and eval report
- Rehearse the demo end-to-end twice against the live production system
- Tag v1.0 and make the repo read as a portfolio piece to a cold reviewer
| Pre-flight: scorecard check + rollback re-verify | 10 min |
| Guided: ship through the pipeline + tag v1.0 | 25 min |
| Guided: the four-document pass | 30 min |
| Practice: two timed dress rehearsals | 20 min |
| Cold-reader send + fixes from their answers | 15 min |
| Punch-list close-out + quiz | 20 min |
Builds on: Day 165 — Proposals & architecture docs · Day 167 — Demo craft · Day 177 — Quality gates passed
A ribbon-cutting is not the day the building gets built — everything was finished and inspected before the mayor shows up with scissors. The ceremony is for the record: the plaque goes on the wall, the keys and the manuals are handed over, and from this day forward the building is judged as a finished thing, not a construction site. Buildings that skip the handover — no manuals, no labeled breaker box — become buildings nobody can maintain, however well they were built.
Today you cut the ribbon on 60 days of capstone work. The deploy itself should be boring — your Day 152 pipeline has done it dozens of times, and boring deploys are the achievement. The real work is the handover: four documents that let a stranger run, judge, and extend the system without you in the room. The README is the front door; the architecture doc is the floor plan with the WHY behind each wall; the runbook is the labeled breaker box; the eval report is the inspection certificate. Then the plaque: git tag v1.0. From tonight, this repo is not your homework — it is your evidence.
For a career changer, the capstone repo IS the resume's load-bearing wall: recruiters spend 90 seconds in it, senior engineers 10 minutes, and both decide from the docs, not the code. A repo with an honest eval report and a real runbook is vanishingly rare in candidate portfolios and signals exactly what AI teams struggle to hire: someone who ships AND operates. FDE interviews go further — "walk me through your architecture doc" is a standard round, and today you write the doc you will be walking people through for the next year.
Guided practice
Ship it through the pipeline
25 min- Pre-flight: confirm yesterday's scorecard is committed and green (or honestly ticketed); re-verify the rollback path on staging — deploy previous tag, confirm health, return.
- Final pass on main: version bump, changelog entry summarizing the finale week, push.
- Watch the pipeline: tests → eval gate → build → deploy. If ANY stage fails, fix through the pipeline — no console cowboy moves on ship day.
- Post-deploy verification: smoke suite against the production URL; one real question answered with citations; one refusal path exercised; dashboard shows the traffic; alerts armed.
git tag -a v1.0 -m "Docs-QA assistant v1.0 — 180-day capstone"and push the tag. Screenshot the green pipeline for the presentation.
The documentation pass
30 minWork the four documents in reviewer order. Timebox: README 8 min, architecture 10, runbook 6 (it exists — finalize), eval report 6 (regenerated yesterday — frame it).
- README: rewrite the top third for a cold reader — what/why in three sentences, demo GIF or screenshot, mini architecture diagram, verified quickstart, doc links, limitations section (3 honest bullets).
- Architecture doc: C4 context + containers + one component zoom, then the decisions log — minimum five ADR-style entries with the road-not-taken named (chunking strategy, hybrid + rerank, model choice, deployment model, eval/gate design).
- Runbook: fold in Day 176's failure-mode table; confirm the five playbooks reference real commands against the PRODUCTION deployment; add the "first 15 minutes" page as the cover.
- Eval report: add a one-page executive summary up front (Day 171's register): what was measured, headline numbers with intervals, known gaps, tickets. A hiring manager reads only this page — make it sufficient.
- Cross-link all four from the README and re-verify every link and command.
On your own
Dress rehearsal, twice
20 minRun the Day 167 demo script against production, out loud, standing up, timed. Run 1: clean path — problem, magic moment (a real question answered with citations), how it works (architecture doc on screen), the numbers (scorecard), next steps. Run 2: same script, but induce your planned failure mid-demo (kill network or point at a dead route) and execute the recovery — cached answer or honest refusal — while narrating without apology.
Constraints: 10-minute cap per run, hard; no restarting a run for stumbles — recovering from stumbles IS the rehearsal; record (audio is enough) and note one concrete fix after each run.
Hints: the most common rehearsal finding is a demo question whose answer changed since the corpus was updated — pin your demo questions and verify their answers TODAY, then never touch the corpus before Demo Day.
v1.0: the portfolio-grade release
Finish the day with: production serving the v1.0 tag, verified by smoke tests and one live cited answer; all four documents finalized and cross-linked; open tickets visible and triaged in the tracker; demo rehearsed twice with timings and one fix noted per run; and a repo whose front page survives the 90-second cold read. Final act: send the repo link to one person who has never seen it (friend, community peer) and ask exactly two questions: "what is this?" and "could you run it?" Their answers tonight are your last cheap feedback before Demo Day.
Common mistakes & misconceptions
- Shipping around the pipeline "just today." The pipeline IS the deliverable's credibility; one manual hotfix on ship day and your CI/CD story becomes fiction in the very repo meant to prove it.
- Writing the architecture doc as a WHAT without a WHY. Component lists are read in 30 seconds and forgotten; the decisions log with named alternatives is what makes reviewers say "this person thinks like a senior."
- Hiding limitations to look finished. Senior reviewers hunt for the limitations section first — its absence reads as either dishonesty or blindness, both worse than any listed limitation.
- A README quickstart that drifted. It worked in yesterday's fresh clone — but you changed config today; re-verify AFTER the final deploy, not before.
- Rehearsing only the clean path. Day 167's law: the demo that has never failed in rehearsal will fail on stage; the recovery run is the one that buys you calm.
- Updating the corpus after pinning demo questions. The answer that changed overnight is the classic Demo Day face-plant; freeze the corpus and the questions together.
Q1. On ship day the pipeline's eval gate fails on a flaky judge case. The right move is:
Q2. Which part of the architecture doc do experienced interviewers weight most heavily?
Q3. Why rehearse the demo WITH an induced failure against production?
Go deeper — curated resources
- Write the release announcement — Draft the 150-word internal launch note (Day 171's exec register): what shipped, the headline numbers, known limits, where to ask questions. Post it to the repo's Discussions as the v1.0 announcement.
- v1.0 live in production via the pipeline; smoke + live cited answer verified
- Four documents finalized, cross-linked, and command-verified
- Both rehearsals done and timed, failure-recovery included; fixes noted
- Cold reader contacted; punch list closed or ticketed; quiz ≥ 2/3
← Back: This is Day 119's v0 arriving at v1.0 through every gate the program built: Day 152's pipeline shipped it, Day 165's doc structures carried it, Day 167's rehearsal discipline staged it, and yesterday's scorecard certified it.
Forward →: Day 179 mines this repo for interview stories — every decision-log entry is an answer waiting for a question. Day 180 presents it, and the job-search checklist puts this URL at the top of your resume.
Unlocks: D180 Demo Day