Day 30 — Capstone Hardening & Retrospective

Updated

July 30, 2025

Day 30 — Capstone Hardening & Retrospective

Day 89 — Capstone harden & evidence

Stage VIII · ~3h
Goal: Produce an evidence pack proving the capstone meets Stage VII–VIII quality: tests, static analysis, govulncheck, performance note, security checklist delta, and packaging verification—no new features.

Important

No new features. Hardening converts “it worked on my machine” into reproducible proof for Day 90.

Why this day exists

A demo without evidence is a slideshow. Reviewers (employers, future you, Stage gates) want commands that regenerate proof. Day 89 is the close ritual before retrospective—not the day to invent domain scope.

Theory 1 — Evidence pack layout

Create evidence/ (or docs/evidence/):

evidence/
  README.md           # index of artifacts + how to regenerate
  test.txt            # go test -count=1 ./... output
  vet.txt
  staticcheck.txt
  govulncheck.txt
  bench-or-pprof.md   # summary + commands (profiles gitignored)
  load.md             # optional short load re-run
  security.md         # checklist delta from day81
  container-or-release.md
  demo-log.txt        # scripted demo output
# evidence/README.md
Go version:
Git SHA:
Date:
Regenerate: `./scripts/evidence.sh`

What belongs in git

Commit Do not commit
Text logs Multi-MB pprof blobs
Markdown summaries Secrets / .env
Scripts Machine-specific absolute paths only

Theory 2 — Evidence script

#!/usr/bin/env bash
# scripts/evidence.sh
set -euo pipefail
mkdir -p evidence
{
  echo "go: $(go version)"
  echo "sha: $(git rev-parse --short HEAD 2>/dev/null || echo none)"
  echo "date: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
} | tee evidence/README.md

go test -count=1 ./... 2>&1 | tee evidence/test.txt
go vet ./... 2>&1 | tee evidence/vet.txt
staticcheck ./... 2>&1 | tee evidence/staticcheck.txt
govulncheck ./... 2>&1 | tee evidence/govulncheck.txt

# optional load/bench — keep short
# go test -bench=. -benchmem ./internal/... | tee evidence/bench.txt

./demo.sh 2>&1 | tee evidence/demo-log.txt

Make executable: chmod +x scripts/evidence.sh demo.sh.

Commit text evidence; keep large profiles out of git (link paths in markdown).

Theory 3 — What “harden” means today

Action Yes No
Fix failing tests ✓
Fix govulncheck hits ✓
Tighten timeouts/body limits ✓
New features ✗
Drive-by refactors ✗ unless unblock tests

If a test is flake: fix or delete with reason—do not ignore.

Flake protocol

## known issues
- TestX flaked once under -count=20: root cause fixed by ...

Theory 4 — Security delta vs Day 81

Re-apply the security checklist to this SHA, not the Stage VI service.

# evidence/security.md
Compared to day81 checklist applied to capstone SHA abcdef1

| Item | Status | Fix if GAP |
|------|--------|------------|
| ReadHeaderTimeout | PASS | set 5s |
| Body limit | PASS | 1MiB MaxBytesReader |
| SQL placeholders | PASS | |
| pprof bind | PASS | 127.0.0.1:6060 |
| Auth on writes | PASS | bearer |
| govulncheck | PASS | clean |
| Secrets in repo | PASS | rg review |
| TLS story | PASS/N/A | day60 notes |

Quick secret scan:

rg -n "API_KEY|SECRET|password\s*=" --glob '!**/*_test.go' || true

Lab runbook (ordered)

1. Tests (45–60 min)

go test -count=1 ./...
go test -race ./...   # if time and pure-Go; skip if known cgo issues

Add only missing critical tests (auth deny, one domain rule, one adapter).

2. Static & vulns (20 min)

go vet ./...
staticcheck ./...
govulncheck ./...

Upgrade reachable vulns; re-test.

3. Performance snapshot (30 min)

Pick one:

  • Re-run a microbenchmark on hot package
  • 20s vegeta/hey against local service
  • One CPU pprof under demo load

Write evidence/bench-or-pprof.md with numbers + interpretation (not raw only).

4. Security delta (20 min)

Produce evidence/security.md with PASS/GAP.

5. Packaging (20 min)

docker build -t capstone:evidence .   # A/B
# or
./scripts/build-release.sh            # C

Record size/file output in evidence/container-or-release.md.

6. Demo freeze (15 min)

./demo.sh → save log. If fail, fix until pass—this blocks Day 90.

Worked example — performance note

## evidence/bench-or-pprof.md
Command: hey -z 20s -c 20 http://127.0.0.1:8080/v1/items
Result: ~900 RPS, p99 40ms, 0% errors
Bottleneck hypothesis: JSON encode dominates (pprof top: encoding/json)
Decision: acceptable for demo; future pool buffers

Worked example — container note

## evidence/container-or-release.md
docker build -t capstone:evidence .
Size: 18MB
User: nonroot
Health: /healthz
file bin/app: ELF 64-bit LSB executable, x86-64, statically linked

Regenerating evidence after a fix

./scripts/evidence.sh
git add evidence scripts
git commit -m "day89: refresh evidence after timeout fix"

What reviewers look for

  1. Commands are copy-pasteable
  2. SHA and go version match the demo binary
  3. Failures are not hidden (set -e)
  4. Interpretation accompanies numbers
  5. Demo log is from the same SHA as tests

Option-specific emphasis

Option Extra evidence
A Collector mock tests; metrics series present; safe defaults
B Migration idempotent; auth negative test; shutdown demo note
C Multi-arch file outputs; exit code tests; --help snapshot

CLI help snapshot

go run ./cmd/mytool --help 2>&1 | tee evidence/help.txt

Theory 5 — Minimum bar vs stretch evidence

Minimum (must have):

Artifact Command idea
Tests go test -count=1 ./...
Vet go vet ./...
Staticcheck staticcheck ./...
Vulns govulncheck ./...
Demo log ./demo.sh
Index evidence/README.md with SHA + go version

Stretch (pick ≥1 if time):

Artifact When useful
-race log Concurrency-heavy A/B
Bench numbers Hot path exists
hey/vegeta 20s HTTP service B/A
help.txt Option C UX proof
docker history summary Image layer curiosity

Do not burn the day on stretch if minimum is red.

Accepted-risk template (govulncheck)

## Accepted risk
ID: GO-20XX-XXXX
Module: example.com/dep@v1.2.3
Reachable: no / yes (path)
Why not upgraded: breaks API X; upgrade planned after demo
Mitigation: code path disabled behind flag; network not exposed
Owner: you
Review by: <date>

Commit this next to govulncheck.txt so Day 90 reviewers are not surprised.

CI sketch (optional)

# awareness — not required to implement today
# on PR: go test, vet, staticcheck, govulncheck
# main: plus docker build smoke

If you already have CI from earlier days, capture one green run URL or log snippet in evidence/ci-note.md.

Hour-by-hour suggestion

Time Focus
0:00–1:00 Tests + race if feasible
1:00–1:30 vet/staticcheck/govulncheck
1:30–2:10 perf/load note
2:10–2:40 security delta + packaging
2:40–3:00 evidence.sh + demo log

Common gotchas

Gotcha Fix
Evidence with absolute machine paths only Prefer commands regenerable
Committing 200MB profiles Summaries only
race detector + racy still shipping Fix or document known issue
demo pass but tests fail Tests gate demo
“I’ll gather evidence tomorrow” Day 90 is retro—not the day to discover red CI
Editing code without re-running pack evidence.sh is the close ritual
staticcheck not installed Install or note GAP with install command
Accepting vuln without note Document accepted risk + ticket

Checkpoint

  • evidence/ pack complete with index
  • go test green (logged)
  • vet + staticcheck + govulncheck logged
  • Perf or load note written
  • Security delta written
  • Packaging verified
  • demo.sh log captured
  • No new features added

Commit

git add .
git commit -m "day89: capstone harden evidence pack"

Write three personal gotchas before continuing.

Tomorrow

Day 90 — Retrospective & roadmap: run the demo checklist, write RETRO.md, and chart the next 30 days of Go learning.

Day 90 — Retrospective & roadmap

Stage VIII · ~3h
Goal: Close the Go volume deliberately—self-demo against a stage checklist, write RETRO.md, and draft a next-30-days learning roadmap (including Go 1.27+ awareness).

Note

This is a completion ritual, not a new feature day. Freeze the product; reflect and plan.

Why this day exists

Without reflection, 90 days becomes a blur of commands. A retrospective:

  • Certifies what you can demonstrate
  • Names remaining gaps without shame
  • Points effort after this volume (NixOS volume, job prep, deeper systems)

Done is a demo, a retro, and a next step—not a perfect program.

Theory 1 — Self-demo protocol

Block 60–90 minutes. Treat yourself as an external reviewer.

Demo sequence

  1. Open CAPSTONE.md pitch (30 seconds).
  2. Run ./demo.sh (or README path) cold.
  3. Show one test command green.
  4. Show one evidence file from Day 89.
  5. Optional: container run or file on release binary.
  6. Stop. Do not continue coding unless demo is broken.

Record in RETRO.md whether demo was pass / pass-with-notes / fail.

If the demo fails

Severity Action
Script flake Fix script only; re-run evidence if SHA changes
Real regression Fix minimal; re-run evidence.sh; note in RETRO
Scope never shipped Record FAIL honestly; roadmap item #1

Do not expand features to “save” the demo.

Theory 2 — Stage checklist map

Tick honestly:

Stages I–III — Language & concurrency

  • Toolchain / modules mental model
  • Types, slices, maps, structs
  • Interfaces & errors
  • Goroutines, channels, context, race detector

Stages IV–V — Generics, quality, stdlib I/O & HTTP

  • Generics judgment
  • Tables, fuzz, golden tests
  • io, JSON, net/http, slog

Stage VI — Data & APIs

  • database/sql + migrations
  • REST design + auth basics
  • Integration tests
  • TLS awareness

Stage VII — Ship quality

  • Cross-compile / tags
  • vet + staticcheck
  • pprof + benchmarks
  • GC awareness
  • Containers
  • Metrics + light traces
  • govulncheck

Stage VIII — Architecture & capstone

  • Package boundaries / hexagon lite
  • Config, shutdown, flags
  • Load + security pass
  • Capstone design + six build days + evidence

Gaps become roadmap fuel—not failure labels.

Theory 3 — RETRO.md template

# Go volume retrospective

Date:
Capstone option: A | B | C
Demo: PASS | PASS_WITH_NOTES | FAIL
Go version:
Git SHA:

## What shipped
- 

## What I'm proud of
1.
2.
3.

## What was harder than expected
1.
2.

## Top 5 personal gotchas (career memory)
1.
2.
3.
4.
5.

## Metrics of the journey (rough)
- Lab days completed:
- Capstone LOC (optional):
- Tools now comfortable: (pprof, vegeta, staticcheck, ...)

## Gaps to close next
| Gap | Why it matters | First action |
|-----|----------------|--------------|
| | | |

## Stage checklist
(paste ticks)

## Evidence pointer
- evidence/README.md SHA:

## Thanks / notes to future self

Writing tips

  • Pride items first (avoids harsh-only narrative).
  • Gotchas should be actionable (“always set ReadHeaderTimeout”), not vibes.
  • Gaps need a first action smaller than a week.

Theory 4 — Next 30 days roadmap

Pick a track (not all):

Track 1 — Production Go deepening

  • Read Go 1.26 release notes again; skim early 1.27 notes when available
  • Add integration tests with testcontainers or similar
  • Practice one incident-style debug (pprof on a bug you invent)

Track 2 — Systems / platform

  • Start or continue 90DaysOfX NixOS volume
  • Wire your capstone into a Nix flake devshell
  • Explore systemd + Go service unit

Track 3 — Job / portfolio

  • Public README + architecture diagram
  • 5-minute Loom-style demo script
  • Map capstone bullets to resume language

Track 4 — Language mastery

  • Work through 100 Go Mistakes items you have not hit
  • Contribute a small fix to a library you use
  • Read parts of the Go memory model / spec you skipped

Roadmap rule: ≤3 active goals for 30 days. Write them as weekly outcomes.

## 30-day roadmap
### Goal 1
Week 1:
Week 2:
### Goal 2
Week 1:
Week 2:
### Goal 3
Week 1:
Week 2:
### Deliberate non-goals
-

Example filled roadmap

### Goal 1 — Capstone on Postgres
Week 1: migrate SQLite store interface to Postgres in docker compose
Week 2: integration tests green in CI

### Goal 2 — NixOS volume days 1–10
Week 1: finish days 1–5 labs
Week 2: days 6–10 + flake for capstone

### Goal 3 — Public writeup
Week 1: architecture diagram + README polish
Week 2: short blog post from RETRO pride items

### Non-goals
- Rewrite in Rust
- Multi-region deploy

Theory 5 — Go version currency

Record:

go version

Note: this volume targeted Go 1.26. When 1.27 ships, schedule a half-day:

  1. Read release notes
  2. go fix / try toolchain upgrade on capstone
  3. Re-run scripts/evidence.sh

Link back to Day 37 habits (go126 quality day).

## Toolchain note
Volume target: Go 1.26
My binary: go1.26.x
Next upgrade review date:

Theory 6 — Closing the monorepo loop

You have walked an expert-shaped path from toolchain mental models through concurrency, HTTP, data, ship quality, architecture, and a capstone with evidence.

Suggested next in this monorepo: content/02-nixos/—or return to the standalone Go book for deeper topical libraries.

Optional git hygiene:

git tag go-volume-complete
# or note SHA in RETRO without tagging

Lab

Suggested workspace: capstone root + notes folder.

  1. Run the self-demo protocol; capture result.
  2. Write full RETRO.md.
  3. Complete stage checklist ticks.
  4. Write 30-day roadmap with ≤3 goals.
  5. Optional: tag git go-volume-complete or note SHA in RETRO.
  6. Spot-check go test ./... still green.
  7. Celebrate briefly—then stop coding.

Stretch

  • 10-bullet “teach Day 1 student” summary of the volume.
  • Compare capstone to Day 62 gate service—what improved?
  • Record a 3-minute voice note walking the demo (private).

Worked example — “teach Day 1 student” bullets (stretch)

Write ten lines future-you would tell week-one you:

  1. Modules, not GOPATH, define projects.
  2. Interfaces are satisfied implicitly—design small.
  3. context.Context is the cancellation bus.
  4. Table tests beat clever tests.
  5. ReadHeaderTimeout is not optional on HTTP servers.
  6. Metrics for aggregates; traces for single requests.
  7. Distroless + non-root is the default ship shape.
  8. Config loads once at the root; validate or exit 2.
  9. SIGTERM must drain; liveness ≠ readiness.
  10. Demo script + evidence pack beat slides.

Paste into RETRO.md under “notes to future self” if useful.

Compare to Stage VI gate (Day 62)

Question Answer in RETRO
What quality bar improved? e.g. container + metrics + shutdown
What is still weaker? e.g. integration tests sparse
Would Day 62 service pass Day 89 evidence? yes/no + why

This anchors growth in artifacts, not feelings.

Common gotchas

Gotcha Fix
Using day 90 to rebuild features Freeze; document as roadmap
Harsh self-grade only List pride items first
Infinite roadmap Cap at 3 goals
Skipping demo because “obvious” Run it once cold
Not recording Go version Future you needs it
RETRO as diary dump Use the template sections
Comparing to imaginary expert Compare to Day 1 you
Forgetting evidence SHA Copy from evidence/README.md
Roadmap goals without weekly cuts Force Week 1 / Week 2 lines

Checkpoint

  • Self-demo executed and recorded
  • RETRO.md written
  • Stage checklist completed honestly
  • 30-day roadmap with ≤3 goals
  • Capstone evidence still green (spot-check tests)
  • Volume closed—no silent “I’ll finish later”

Commit

git add .
git commit -m "day90: retrospective roadmap close volume"

After this volume

Ship carefully. Measure first. Keep interfaces small. Prefer boring packages.

Done is a demo, a retro, and a next step—not a perfect program.