Merged.

Fix merged.

Just for completeness, the language is Clojure?

Approved.

• Category annotations are removed
• Added check for the case when petal has very small positive velocity

It makes more sense to me in hindsight after reading this. What confused me is that what you call an "analyzer" is in effect a database of excitation levels. It's not even implied that it performs any kind of filtering or transormation to those readings, it just stores them. As you said it's not a big deal regarding the kata itself, I was perhaps reading it too carefully, thinking it was relevant to the task.

• I'm not claiming that bugfix kata should always have the bug in the sample tests, it's just most often the case, so I was surprised. Your reasoning is worth a try, I cannot predict how the target audience will react to debugging something they cannot directly see.

• I guess the way the performance is evoked make sense if you aim for the 2-step bugfix you described. Maybe it was only confusing for me because I already knew that in is fast, whereas a beginner will not necessarily know it. The wording can stay the way it is then.

Okay now I see that I got some numbers related to peformance in the description wrong, probably as leftovers from older versons of tests :( Or maybe gfreeman is one sloppy reporter? :D

Ad remarks about nomenclature from your post below:

I am no domain expert, I just like the theme. I may, and surely do, get many domain-specific things wrong. Basically I hope that many imperfections can be hand-waved by the humorous sci-fi theme, but at the same time I do not want to make things blatantly wrong. But about this particular challenge, samples, and sensors, my imaginary B.Ü.R.P. experiment works as follows:

• the big list passed to the constructor (called by me "sample") is a list of values, possibly obtained from some historical data, which scientists hunt for. Scientists load it into the device in a preparation step for the experiment.
• When the experiment runs, an array of sensors detects particles, and passes each value measured by each sensor to the analyzer, to check if an observed particle carries an interesting value. What happens later is irrelevant, maybe they are counted, maybe plucked and collected in a jar, we were not told exactly.

This is, more or less, how I imagine the process, and nomenclature used by me is how I imagine it. It's applied loosely, but I do not want it to be blatantly wrong if it can be improved. I am open to any suggestions.

• Isn't it unusual for a bugfix kata that the bug only happens in the full tests and not the sample ones ?

• The device must remain responsive under large samples

  It's not completely clear with that wording that the device DOES currently perform well for large batches and must remain so. I initially took it that I also had to speed up the current implementation.

• There are some points in the lore that I found a bit confusing, but it may be my fault:

  • the Bogon Analyzer ingests a sample of measured bogon excitation levels

  In chemistry and data science, the word "sample" has different meanings. Is "sample" used here in its chemical sense, i.e. "a fraction of matter that will be fed to an instrument to measure its properties", or in the data science sense of "portion of data from a larger batch" ? It seems like it is the latter because of the word "measured", but then this sentence contradicts it:

  • In the second phase, external sensors query the analyzer

  If the analyzer already turned physical data (the sample) into digital data (the numbers), the "sensors" cannot be actual sensors that detect or measure some physical phenomenon; they are purely software-based and hence not really "sensors" in the sense I would understand it. It's as if the description was backwards and the sensors step should precede the analyzer step...

Please do not post solutions in kata discourses.

Okay, In this case, I will just remove Category annotations.

Not a problem.

In what language?

I am not sure if we need the Category annotation, it is ignored when running tests on CW. If you aim for grouping of test cases in test report, I would use C#\NUnit mechanisms for nesting: namespaces, nested classes, parametrized test methods, etc.