docs(articles): improve clarity and rephrase sections in testing-telos draft

- Replaced "cheap" with "inexpensive" for better tone.
- Explicitly introduced "telos" with Aristotle reference.
- Rephrased sentences for better flow and conciseness.
- Updated risk distribution description for precision.

articles/drafts/testing-telos.md

@@ -1,10 +1,10 @@
 # Testing Telos
 
-The classic *Testing Pyramid* is not wrong; it is simply *incomplete*. It was forged for one specific kind of engineering work: the steady addition of new user-facing features. In that narrow context the pyramid makes perfect sense: a broad base of fast, cheap unit tests, a smaller middle layer of integration tests, and a thin apex of end-to-end checks. The shape itself is the visual signature of a particular *telos*—the final cause or purpose—of that work.  
+The classic *Testing Pyramid* is not wrong; it is simply *incomplete*. It was forged for one specific kind of engineering work: the steady addition of new user-facing features. In that narrow context the pyramid makes perfect sense: a broad base of fast, inexpensive unit tests, a smaller middle layer of integration tests, and a thin apex of end-to-end checks. The shape itself is the visual signature of a final cause or ultimate purpose of that work. The word that Aristotle used for this concept, was *telos*.
 
-But software engineering is not a single kind of work. Different engineering goals demand different testing strategies. The pyramid is only one of four natural shapes that emerge when we observe what teams actually *do* in practice. Each shape is the visible expression of a distinct *purpose*.  
+Software engineering is not a single kind of work. Different engineering goals demand different testing strategies. The famous pyramid is only one of four natural shapes that emerge when we observe what teams actually *do* in practice. Each shape is the visible expression of a distinct *telos*.  
 
-In Aristotelian terms, testing is *techne*—a craft. A craftsman does not begin with a fixed form and force every material into it. He begins with the *purpose* the artifact must serve, then lets the material and the method follow. The testing strategy is the form; the engineering goal is the telos. When the two are mismatched, confidence is illusory and effort is wasted.  
+In Aristotelian terms, software testing (and software development) is *techne* — a craft. A craftsman does not begin with a fixed form and force every material into it. He begins with the *purpose* the artifact must serve, then lets the material and the method follow. In testing, the software is the material object; the testing strategy is the form; and the engineering goal is the telos. When these causes are mismatched, confidence is illusory and effort is wasted.  
 
 What follows are the four archetypal testing shapes we have observed across real projects. Each includes its visual metaphor, its characteristic purpose, the strategy it demands, the distribution of risk it creates, and the signals that tell us our work has succeeded.
 
@@ -18,7 +18,7 @@ What follows are the four archetypal testing shapes we have observed across real
 
 **Testing Strategy** Heavy emphasis on unit tests at the base. Integration tests validate that the new feature interacts correctly with existing components. A thin layer of end-to-end tests confirms the primary user-facing workflow. This is the classic pyramid in its native habitat.
 
-**Risk Distribution** Risk is concentrated around the new code. Failures are usually local and predictable. Adjacent components may be affected through integration points, but the blast radius is bounded. You generally know where to look when something breaks.
+**Risk Distribution** Risk is concentrated on the new code. Failures are usually local and predictable. Adjacent components may be affected through integration points, but the blast radius is bounded. You generally know where to look when something breaks.
 
 **Confidence Signals** New behavior is exercised thoroughly at the unit level. Integration boundaries are tested. At least one end-to-end path covers the primary user workflow. Edge cases are captured in lower-level tests. When the base is solid, the upper layers provide confirmation, not discovery.