The first revision is the addition of a nothing action before the find notes action to stop it searching against a list rather than the notes app. Look at the inline docs and the inputs for the find notes action to see why; but this explains why you only ever seemed to get the input parameter rather than the body of the note.
The second revision I made is just to highlight a stricter use. The find may return multiple (or no results). Really, you should check the number of results being returned and if > 1, pick a default (like the first item which I used as a default for my revision to your test shortcut), or you could offer up a further list that perhaps allows the user to preview or give a date to further narrow their choice.
Re revision 1, I was reading the inline docs but not sure if I understood why the “nothing” action solved the issue. I’ll google it tomorrow as it might be a “programming” reason/logic.
Re revision 2, appreciate it. I didn’t add it to the test shortcut because the text in the list action is very specific. But for the “real” shortcut I’ll add a count + if actions…though I liked the idea of creating a new list of notes to choose from. Not sure if I know how to do it, but will have a go
The nothing action is stopping the list item being passed in and interpreted as a list of notes; the body of that note being simply the list entry that presents as the result of the find.
Think of it as disrupting the data flow and remember that the content graph engine readily and implicitly converts between different types of data - e.g. list item to note.