DevOps PeachClaude is good at saying a task is finished. Our job is to make that sentence come with evidence. Everything below is cheap compared with fixing a broken page that learners have already seen.
The layers of checking
| Layer | Command or method | Catches |
|---|---|---|
| Syntax | node --check worker/api.js, a script that compiles the inline JS |
A missing bracket that blanks the whole site |
| Content rules | python3 tools/check_content.py content/<track>/<module> |
Broken YAML, duplicate ids, lessons over the word limit, invalid build steps |
| Data build | python3 tools/preview/build_site_data.py |
Modules that fail to render |
| Behaviour | Headless browser: open the page, click, read the result | A button that does nothing, a 404 from the API |
| Looks | Screenshots at 1440, 1024 and 390 px, light and dark | Overflow, unreadable text, the wrong theme |
| Independent review | tech-reviewer agent for graded content |
Wrong answers, ambiguous questions |
Ask for the check in the request itself: "…then run check_content and send me screenshots at desktop and phone width." When Claude cannot run something (no network to the real API, for example), the honest answer is "not verified", and you test that part yourself.
Mocks for the parts you cannot reach
The profile pages call a server API that does not exist on a laptop. We tested them two ways: the Worker code with an in-memory fake database in Node, and the page with the API calls intercepted in the browser and answered with sample data. Neither proves production works, but both catch most mistakes before deploy.
The commit routine
Our rules, all in CLAUDE.md:
- Commit only when the owner asks.
- On the default branch, create a branch first.
- Add only the files you changed. Our Windows checkout shows hundreds of files as modified just because of line endings; committing those would bury the real change.
- Write a commit message that says what changed and why.
Deploy: know which part changed
DevOps Peach is static files plus a small Cloudflare Worker for accounts and the leaderboard.
- Only
site/changed → push; the static files are published with the next deploy. worker/changed → runnpx wrangler deploy, or the new API routes do not exist and the page shows errors.- A new database migration →
npx wrangler d1 migrations apply devopslearn --remotefirst, then deploy.
Put the follow-up commands into the work log entry, so whoever pushes does not forget them. Then open the live site and look at the change yourself. It takes thirty seconds and it is the only check that proves the thing your learners will see.