What quality bar do you expect from your team, and how do you enforce it?

Set the bar by risk rather than by a uniform rule. Define what must be true before code ships (tests that catch the realistic failure modes, review by somebody who can genuinely challenge it, instrumentation on the new path, a documented way back) and automate as much of that as possible in the pipeline. Enforce through defaults and automation instead of nagging in code review.

I set it by blast radius. A change to the payments path and a change to a marketing page do not deserve the same ceremony, and applying one standard to both means you either slow everything down or get burned where it counts. For anything that matters, my checklist is tests that would actually catch the realistic failure rather than coverage percentage theater, a reviewer who understands the domain well enough to disagree, instrumentation on the new path so we can watch it in production, and a documented way back. Then I push as much of that into the pipeline as I can, because standards that rely on humans remembering during review decay in about a month. Lint, test gates, migration checks, a rollback note required in the template. When somebody senior works around it, I treat it as a conversation about the standard rather than about them, because usually they have a real reason and the standard is wrong. If it happens twice with no reason, that is a performance conversation, not a process one.