Radians wrap, which is why nothing throws. Hand a drawing function 30 when you meant 30 degrees and it reads 30 radians: that is 1718.87 degrees, four and three quarter turns, arriving at 278.87 degrees once you take the remainder [1]. The arc still gets drawn. Slices that should sit apart can land on top of each other and read as one wedge, which is the symptom the author describes two weeks after the demo passed, when a teammate opens the file in Safari [18]. Mixing units on geometry calls is, per the post, the most common cause of arc-starts-in-the-wrong-place tickets [19].
The grep list is the cheapest item in the checklist: `Math.PI`, `* 180`, `* 360` and `/ 57.29`, each occurrence required to carry an adjacent comment naming the surface it targets [7]. That last string is a rounded 180/pi. Using 57.29 instead of 57.2957795 moves a full turn by about 0.036 degrees [2], which nobody will ever see on a pie chart. The grep is therefore about direction rather than precision: multiplying where you needed to divide is the whole bug class, and the constant is only the fingerprint.
Bare constants hide the same mistake. The post contrasts `const SLICE_ANGLE = 0.5236` with `const SLICE_ANGLE_DEG = 30` [10]. Convert one and you get the other: 0.5236 rad is 30.0001 degrees [3]. Both draw the same slice. Only one of them survives being read by someone who does not already know which surface the file targets.
The boundary rule is where the checklist earns its keep. Three.js works in radians throughout and ships `THREE.MathUtils.degToRad` because of how often that trips people [6]. CSS Values and Units Level 4 accepts `rad` as well as `deg`, but the authoring tools and design specs feeding your code emit degrees [5]. So a radians-native codebase still receives degrees, and the answer is one conversion in the deserialiser or a single `toSceneUnits()` call rather than a conversion at every call site [16]. Imported formats behave the same way: a DWG floorplan or a DICOM slice arrives in whatever unit the format mandated and is converted once [17].
The last item is the expensive one. Rendering the scene with deliberately wrong inputs, where -30 in place of 30 should produce a different but still valid picture and total breakage indicates a double conversion [11], needs a harness that can compare renders. That is a CI project, not a review habit. The boundary rule also assumes you have a boundary; if `arc()` calls are spread across twenty components, "convert in the deserialiser" is a refactor, and a per-file review pass will not surface it. Note too that SVG's conventions are per call: `getPointAtLength()` works in the path's authored user units, whatever those were [14]. In my context the grep list and the unit-suffixed constants are worth adopting on the next diff, and the render test waits until something already renders in CI.
