In short:
A user story describes desired behaviour of the system focussing on results and written in plain understandable language. More formally:
A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective.
A bug is something wrong in the system. Either a violation of requirements or something that will bother a user.
A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
That being said,
- If there is no evidence for expected behaviour then are all perceived issues a bug?
This means you need to talk to the developer and/or use common sense,
- If a change is made in a story that wasn't detailed in the criteria of the case, is that a bug?
Now you have an problem with procedure that does not necessarily means a bug is caused,
- Is any additional change not specified in a case a story? Even if it seems like a bug. e.g. is so obviously wrong that the oversight in the case should have been spotted.
It should be the other way around, a use case should hold more detail than a story. There may not be a neat mapping between them anyway of course.
It is always difficult to stay focused as a team while changes sweep through the already worked on features. That is why no such changes should be allowed during sprints. The above suggests that some mix-ups got in as there seem to be mismatching versions and/or discrepancies in the work to be done. Time for some Backlog Grooming?