breaking-change-detectionlisted

# Breaking Change Detection ## Purpose Standardize how a change is classified against Semantic Versioning by reasoning about its effect on *consumers*, including behavioral breaks that leave the syntax intact. Humans get binary compatibility right only about 60% of the time; this methodology closes the gap with an explicit decision matrix and per-ecosystem catalogs. Tech-agnostic. ## First: is the change on the public surface? Only changes to the **public API surface** can be breaking or minor. Establish the surface before classifying (detailed per ecosystem in `references/breaking-change-catalog.md`): | Ecosystem | Public surface | |-----------|----------------| | JS/TS | `package.json` `exports`/`main`, named/default exports, `.d.ts` | | Python | `__all__`, non-`_` names, entry points | | Go | Capitalized identifiers outside `internal/` | | Java/C# | `public`/`protected` members of exported packages | | Rust | `pub` items reachable from the crate root | | CLI | flags, subcommands, arg order, exit codes, stdout format | | HTTP | routes, methods, request/response schema, status codes | | GraphQL | types, fields, args, nullability, enum values | | Config | recognized keys, env vars, defaults | A change entirely within private/internal code is at most a PATCH. ## The decision matrix | Change | Classification | |--------|----------------| | Remove/rename a public export, field, route, flag, env var | **MAJOR** | | Change a signature (add required param, reorder, retype,