Bug fixes and small improvements

Keep the project's stated principles (a PRINCIPLES.md, AGENTS.md, CONTRIBUTING.md or similar), if it has them, in mind for every change — and these in any case: instrument before guessing, prefer the capability the code already has, and start from the outcome rather than the proposed mechanism.

Never assume or take a product decision. Even a small fix can change what the customer sees or how the product behaves — an error message, an edge-case outcome, a default. When it does, stop and ask the user what the final customer experience should be. Recommend a solution with your reasoning — the user decides.

The same goes for anything with a large blast radius. An architectural change, a new dependency, a change to the data or domain model — anything that requires deep understanding of the system and is expensive to reverse — does not belong in a bug fix without asking first. Ask in simple terms: one decision per question, what each option means, and what you recommend.