FWIW, if you have Time Machine running, you might be able to get at an old copy of the file. My hunch is the ‘error’ is in fact the unexpected results of some overlooked experimentation; this is because I’ve never known a prototype to fail in the way described. Trying to guess the cause isn’t possible from the data at hand and a list of guesses would be a trial to write - and to read!
One way to experiment with Action code with less automation is to place your code into a Stamp. When applied, a stamp is run once only on the selected item— or each each selected item if more than one. This can make it easier to see if the outcome of the code is as expected, before placing it in more automated contexts like an OnAdd.
I think I may have found one possible cause of your glitch if a note has the same title ($Name) as a prototype, or your have two prototypes the same, odd results may occur. I suspect this is what happened in your case.
Tinderbox does allow two notes of the same name. It also allows two prototypes of the same name or a same-named pair of prototype and normal note. However, testing just now in the latter two cases off effects can occur (I gave each note/prototype a different set of key attributes). In such a scenario Tinderbox can have a problem figuring our which of the same-named notes it the source prototype.bI’m not sure if that is what hit you but it is a possibility. TL;DR - if unsure of detail always give prototype notes a unique name. A common method is to use a prefix so the prototype has a name you’d never likely use for a normal content note, thus “pNote” or “_note” or “*note”, etc., rather than “note”.
Footnote. For historical reasons Tinderbox built-in prototypes don’t use such an approach. 10+ years back the app was a lot simpler and such accidents were less likely. Changing the prototypes’ names now would, likely break someone’s code that had worked for years, or at least their use of such prototypes.