because n is the number of hotdogs youre going to sell... so youre basically demonstrating if you sell more then a discount is applied

My point is that this Kata description is more akin to what developers may face in the real world, there is a principle and vision that the end user has set out, to extract the data in the way they've described.

If we as developers understand what they're trying to achieve and are deliberately ignoring that just because they've been unable to articulate it, then that is a failing of us as developers.

As you point out, there are a lot of variables such as PM interaction and customers that can cause us issues, but ultimately, I'd much rather be working with developers that see the bigger picture and ask questions than those who just blindly follow a specification, knowing it doesn't cover the outcomes that the business or customer want.

As a thinking principle in the application of this in the real world, it would be dangerous to throw away requirements simply because they had not been scoped accurately in tests... perhaps that is a failing of the CW culture

This needs a new test as not all rules are covered, in the instance where a persons name is present and capitalized, a number of the passing solutions would fail, I suggest:

Test.assertDeepEquals(findTheLocation("The bird was found by Steven Parker and in the parking lot at Park Ridge Reservation foraging under a sycamore tree."), "Park Ridge Reservation");

This is smart but doesn't quite follow the rules, in example, if new data was introduced:

The bird was found by Steven Parker and in the parking lot at North Chagrin Reservation foraging under a sycamore tree

North Chagrin Reservation should be returned.

This would fail. The instructions do specifically say to look for key words such as Reservation in order to qualify the sequence as a place name.

I'm not proud of this, at some point I will rework it properly