meaningful-contributionlisted

# Meaningful Contribution Treat the deliverable as a change plus credible evidence that it works. Match the depth of proof to the change's risk, and never claim checks that were not run. ## Establish the proof contract Before editing: 1. State the user-visible or system-visible behavior that must change. 2. Identify the narrowest way to observe that behavior. 3. List the important failure modes and non-happy paths. 4. Find the repository's own instructions and existing test patterns. 5. Choose the evidence required for completion. For a bug fix, reproduce the failure before changing code whenever feasible. For a feature, define concrete acceptance examples. For a refactor, define the behavior and interfaces that must remain unchanged. ## Build the smallest coherent change - Prefer the smallest change that fully satisfies the proof contract. - Keep names, types, and abstractions truthful. A name is a contract; rename or redesign anything that requires “it says X, but really means Y” to understand it. - State expected inputs, outputs, state transitions, and behavior for invalid or unexpected inputs. - Fit the repository's established domain model and patterns. Do not introduce a competing abstraction without a clear need. - Read every changed line in context after generation. Remove accidental complexity, dead branches, broad casts, and unrelated cleanup. ## Prove behavior in layers Use the applicable layers below. Do not substitute static inspection for runtime eviden