From 32d916f17f34a7d1b43703eed3558b7e194984cd Mon Sep 17 00:00:00 2001 From: Christian Nennemann Date: Tue, 31 Mar 2026 21:37:21 +0000 Subject: [PATCH] =?UTF-8?q?fix:=20principle=20#27=20=E2=80=94=20add=20grai?= =?UTF-8?q?n=20of=20salt,=20clarify=20scope=20(prototyping=20vs=20producti?= =?UTF-8?q?on)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 6813e66..fe313b8 100644 --- a/README.md +++ b/README.md @@ -283,16 +283,16 @@ Plan-Do-Check-Act after every sprint, not just at the end. Check catches bugs be **Origin:** Sprint 1-3 each had a PDCA cycle that caught rate limiting issues, SSE race conditions, and Caddy routing gaps. -### 27. Test in Production, Not in Mocks +### 27. Test in Production (for fast prototyping) -For single-user tools: test against the real deployment. Mocks hide integration bugs. +For single-user tools in rapid prototyping: test against the real deployment. Mocks hide integration bugs. **Grain of salt:** This applies to MVPs and personal tools. For multi-user, shared, or safety-critical systems, use proper staging environments and test suites. -- `curl` against the live API after each deploy -- Try the PWA on your actual phone -- Submit real jobs through the real worker -- Read the real debug logs +- Fast prototyping: `curl` against live API, try PWA on real phone, submit real jobs +- Production-grade: staging environment, automated test suite, canary deploys +- The principle is about speed of feedback, not skipping quality gates +- Know when you've graduated from prototype to product — then add proper testing -**Origin:** "Committe regelmäßig und test in production — keine mocks!" +**Origin:** "Committe regelmäßig und test in production — keine mocks!" (during rapid MVP sprint) ### 28. Changelog as First-Class Artifact