Hunt for values that were never computed but are returned as measurements (hardcoded constants, pinned fixture counts, name-prefix censuses)

[gsdali]

The class

A value that was never computed, returned through an API whose shape says it was measured. The
caller cannot tell the difference, because a fabricated answer and a real one have the same type,
the same plausible magnitude, and no error channel between them.

This keeps recurring, has been found by accident every time, and nothing in the tree looks for it.
Opening this to make it something we hunt rather than something we stumble into.

Confirmed instances

Production code returning a constant that reads as a measurement:

• OCCTBridge_Healing.mm:248 — result.selfIntersectionCount = 0; // Would require more expensive computation. Every Shape.analyze() result has reported zero self-intersections since the field
  existed. Not "none found": never looked. Documented as such only just now, in healed()/fixSolid() can demote a solid to a shell while reporting isValid == true #702's PR.
• Shape.centerOfMass returns the bounding-box centre, not the centre of mass #605 — Shape.centerOfMass returned the bounding-box centre. A number of the right type and a
  believable magnitude, for a different quantity.
• Zero-mass BRepGProp results are returned as successful answers, and the sentinel is not (0,0,0) #609 — zero-mass BRepGProp results returned as successful answers, with the fabricated magnitude
  an open shell produces.
• GeomConvert_ApproxSurface at GeomAbs_C0 returns a degree-1 collapse while reporting IsDone and a maxError five orders of magnitude too small #522 — MaxError() reported 4.08e-15 unchanged from tolerance 1e-1 down to 1e-7, because the
  quantity it summed had been zeroed. A confidence number that was structurally incapable of moving.
• joinBezierPatches silently drops weights on rational patches and reports success (the second and last compiled-out NotImplemented guard) #725 (just filed) — joinBezierPatches reports IsDone() == true while having silently dropped
  the weights.
• The math solver/optimizer dimension arguments trap, and MathSolver.leastSquares reads out of bounds #640 / PR fix(#640): the math dimension family rejects invalid input instead of trapping or reading out of bounds #716 — math_GaussSetIntegration returns IsDone() == true and a wrong value for any
  input with more than one variable.

Tests pinning a hardcoded number that encodes the bug rather than the answer:

• OCCTEdgeGetConvexity depends on face argument order, so detectPocketsAAG() reports a pocket on a plain convex box #703 / PR fix(#703): OCCTEdgeGetConvexity no longer depends on face1/face2 order #720 — the "real pocket" fixture asserted 1 pocket for eight months. Measured: it removed
  0.0 volume. It never overlapped the box. The 1 was entirely the defect it was meant to guard.
• The math solver/optimizer dimension arguments trap, and MathSolver.leastSquares reads out of bounds #640 — a test asserted the 2-variable integral equals 0.5. The correct value is 1.0. The pin
  had frozen a wrong answer as the expected one, and "fix the literal" would have frozen a second
  wrong answer, since the class cannot produce 1.0 at all.
• healed()/fixSolid() can demote a solid to a shell while reporting isValid == true #702 / PR fix(#702): analyze()'s free-edge detection was dead code; isValidSolid already answers the demotion question #717 — a total was about to be pinned as a constant when the fixture turned out to carry
  a pre-existing nonzero gapCount. Computing the expected value from the real fields is what
  stopped the test pinning a coincidence.

Censuses reporting a count nobody measured: #558 said 14, measured 28. #571 said 3, measured 6.
#583 said five, measured six. #595 said six, measured nine. #640 said 13, measured 20. The pattern
is a count derived from a name prefix rather than from the behaviour.

Why it survives review

All three sub-kinds pass every gate we have. The value has the right type, so it compiles. It has a
plausible magnitude, so it does not look wrong. The test asserting it is green, so CI is green. A
--self-test over it can be 6/6 while proving nothing, which is the exact failure
okf/policies/prove-the-test-fails.md was written about after it happened twice in one script.

The common root is that absence and zero are spelled the same way. 0 self-intersections, 0
concave edges, 0.0 error, an empty array: each is both the "nothing here" answer and the "never
looked" answer, and the API offers no way to distinguish them. #583, #595 and #609 all resolved the
same way, by making the not-measured case representable (nil, a sentinel that cannot collide) so
the two stop sharing a spelling.

Proposed work

1. Sweep for the production form. Start from the 14 sites where a comment already admits it
   (grep -rniE "would require|not implemented|placeholder|hardcod" over Sources/), then the
   harder set: any bridge field assigned a literal on a path that reads like a computation. For each,
   decide: compute it, make the absence representable, or remove the field. selfIntersectionCount
   is the obvious first one, and removal looks right, since Shape.isSelfIntersecting(timeout:)
   already answers it properly.
2. Sweep the test form. Any #expect(x.count == <literal>) on a fixture whose geometry nobody
   re-derived. The check that works is the OCCTEdgeGetConvexity depends on face argument order, so detectPocketsAAG() reports a pocket on a plain convex box #703 one: assert the fixture does what its name says
   (volume actually removed, faces actually shared) before asserting the count. A pinned count with
   no accompanying assertion about the fixture is the smell.
3. Consider a gate script. Detecting "this literal was never derived" is not decidable in
   general, but the narrow form is: a struct field assigned only a literal across every path in its
   own constructor. Worth a spike before committing to it.

Scope 1 and 2 for v2.0.0 if they stay tractable; the gate script is a follow-up.

Related: #605, #609, #583, #595, #522, #640, #703, #725. Policy:
okf/policies/prove-the-test-fails.md.

[gsdali]

Sub-kind 2 should grow a shape found while fixing #723 (PR #734): a hardcoded fixture parameter, not a hardcoded expected value.

Issue703EdgeConvexityOrderTests' through-hole test parameterised plate thickness over 20/40/60/120 but left the drill's Z offset at a fixed -5. Because Shape.box(width:height:depth:) is centred, the plate spans -t/2 to +t/2, so the drill never reached the bottom face at any thickness: a test named throughHole... built a blind pocket in every case.

That is the same failure as a pinned count, one level down. The value that stopped meaning what its name said was an input, not an assertion, and no assertion on the output could catch it. It also defeated my own verification: I reconstructed the fixture in C++ with a corner-based BRepPrimAPI_MakeBox rather than the centred Shape.box, measured a genuine through-hole, and reported it as the fixture's ground truth.

Detector shape worth considering: a parameterised test whose arguments: vary one dimension, where a geometric constructor in the body uses a literal in the same axis. That is mechanically findable and would have caught this one.