🛠️ Lab 2 — Write and Commit Your Capstone's Founding ADRs (50 pts)

Goal: Produce 3–5 well-formed Architecture Decision Records for your capstone project, committed to version control in a doc/adr/ directory, plus one concrete SLI/SLO pair that defines success for your system. Everything in this lab is free, text-based, and runs entirely in your existing Git repo — no new paid services required. Steps:

  1. Create the ADR directory. In your capstone repo, create doc/adr/. Add a short doc/adr/README.md that explains the numbering convention (e.g., NNNN-title-with-dashes.md) and links to the MADR template.
  2. Adopt a template. Copy the free MADR (Markdown Architectural Decision Records) template from adr.github.io/madr, or the classic Nygard template if you prefer its shorter form. Either is acceptable — be consistent across all your ADRs.
  3. (Optional) Install adr-tools. If you want automatic numbering and file management, install Nat Pryce's free adr-tools CLI, run adr init doc/adr to set up the directory, and use adr new "<decision title>" for each subsequent ADR. This is optional — hand-numbering markdown files works fine too.
  4. Identify 3–5 foundational decisions you've already made or are actively making for your capstone. Good candidates: model-serving approach (e.g., FastAPI + local GPU vs. managed endpoint), cloud vs. local deployment, database/vector-store choice, agent framework or orchestration choice, authentication/security approach. Pick decisions that would be expensive to reverse later.
  5. Write each ADR with Title, Status (mark all as "Accepted" unless you're genuinely still deciding, in which case use "Proposed"), Context (the constraints and at least one rejected alternative), Decision, and Consequences (both the upside and the trade-off you're accepting). Use the AWS Prescriptive Guidance ADR process doc as a structural rubric — it lays out what a strong Context and Consequences section should contain.
  6. Commit your ADRs to Git with a clear commit message (e.g., docs: add ADR-0001 through ADR-0004 for capstone architecture). Push to your remote repository.
  7. Define one SLI/SLO pair. In a new short markdown file (doc/success-metrics.md), name one SLI that matters for your capstone (e.g., p95 inference latency, retrieval precision@5, uptime), set a concrete SLO with a time window, and note what your error budget (1 − SLO) means in practice for your project.
  8. (Optional) Track requirements in GitHub Projects. Create a free GitHub Project (table or board view) with an Issue per major requirement, and add custom fields for the linked SLI/SLO and target date.

Deliverables: A link to your repo's doc/adr/ directory (or a zip/PDF export if your repo is private) showing 3–5 committed ADRs, plus your doc/success-metrics.md file with one named SLI, a concrete SLO, and the resulting error budget explained in your own words.