K3 has two code reviews, with someone from your circle, in a public learning community, or as a self-review with a checklist. The first came at the end of module 3.3, at the pull request “Kladde without keys”. The second comes now and takes on all of the operations this module has built: the foundation, the pipeline, the runbooks, the alerts, the drills. You also write the operations manual. The two belong together. A review asks whether the code does what it should. The manual asks whether someone else can work with it when you’re not there.

What the review sees

The work of 3.10 is spread over many pull requests, and every one of them is already merged. A second review on each single one would be tedious and would never see the whole. One trick makes all the operations reviewable at once: a pull request from main against a branch that sits at the state before this module. GitHub then shows everything that has changed since as one diff, on which the reviewer can comment line by line. This pull request is never merged; it’s closed after the review.

PowerShell
# The commit with which lesson 3.10.1 was merged: the state before the operations work of this module.
$base = '<commit before 3.10.2>'
git switch --create review-2-base $base
git push --set-upstream origin review-2-base
git switch main
gh pr create --base review-2-base --head main --draft --title 'Review 2: operating the Kladde' --body-file docs/review-2.md

You find the commit with git log --oneline --first-parent main: it’s the merge commit of the pull request from 3.10.1. The pull request is a draft (--draft), so that nobody merges it by accident. Don’t delete review-2-base until the review is finished.

A diff over a whole module is big. So the reviewer needs a map, and you write it in docs/review-2.md, the text of the pull request:

## What this is about
The operations of the Kladde from module 3.10: foundation, pipeline, application without keys, import, alerts, load,
recovery, rebuild. Everything runs from an empty subscription; proven in docs/rebuild.md.

## Reading order
1. infra/foundation/ and scripts/foundation.ps1: who may do what (table in docs/operations.md)
2. .github/workflows/deliver.yml, deploy-environment.yml, scripts/deploy.ps1: the path of a change
3. infra/main.bicep, infra/apps.bicep: what the pipeline creates
4. infra/monitoring.bicep, ops/queries/: alerts and queries
5. scripts/restore-drill.ps1, teardown.ps1, rebuild.ps1: what touches or deletes data

## Evidence
- first run up to prod: <link>; check-release.ps1 ends with 0
- alert drill: docs/alarm-probe.md; load test: docs/load-test.md
- recovery: docs/recovery.md; rebuild: docs/rebuild.md

## Please check especially
- the condition under which the deploy identities assign roles (infra/foundation/modules/environment.bicep)
- that the deploy identity gives itself the data role on tenders-raw (infra/main.bicep, 3.10.8)
- that teardown.ps1 deletes nothing without explicit confirmation

## Not part of this review
- the application code from K2, except where the operations changed it

The reading order follows the risk, not the alphabet: first who may do what, last what deletes. And “Please check especially” isn’t an admission, it’s a help. You know best where you were unsure yourself.