Scrum is based on an empirical process control system. It assumes that not everything is known and that knowledge will emerge over time. Trying to specify every acceptance criteria in exact detail may not be possible and may take way more time than needed.
It's not possible to know all acceptance criteria in advance.
Instead, Scrum explains that the ...
There is a lot more that's structurally wrong with your situation than you think, and based on your tone and framing you yourself appear to be part of the problem. Your company appears to have an immature organizational structure without mutual respect between roles, and various people involved in this situation seem to be communicating poorly. Only ...
Besides for dns's suggestion to add it to treat his submission like any other pull request and test it thoroughly, you also need to add values to your concerns.
Create a document explaining the cost, in man hours, of each concern:
We'd have to rewrite everything
That means X coding hours, X testing hours and X debugging hours.
It's not great code
You could treat his submission like any other pull request: give him feedback like you would any other code review. If he understands the conventions of your team, if he knows your team doesn't put code into production without acceptable test coverage, then he might take the feedback seriously and improve the code.
Code quality is, however, only part of ...
If the quality of the product isn't good, is the Scrum Team fault
It is never the stakeholder fault!
According to the Scrum Guide (2019), the Scrum Reviews are
"informal meetings" in which the stakeholders are invited to
participate and collaborate. Being "informal meetings" we expect
the requests, needs and ideas presented by the stakeholders
to be ...
The product owner is responsible for defining all the items in the backlog with enough detail for the team to be able to work on them. Acceptance criteria is part of those details. The product owner needs to have these clearly expressed before work begins.
Of course it's also the team's responsibility to make an effort to understand the items from the ...
Why are you talking about blame?
Your Question reads, to me, like "Something went wrong. Who do we blame?"
The only situation in which "responsibility" (read: blame) should be relevant is when it is necessary - namely, when selling to an external party. In which case, the only valid answer could ever be: "Check your contract". This is a question for a ...
Have a customer or product owner to worry about making all the acceptance criteria known in advance?
We shouldn't expect the customer and Product Owner to get requirements perfectly right every time. The reasons for this are:
It is very difficult to think of everything when defining a requirement
Excessive time spent defining requirements is a form of ...