Greptile Summary

This PR fixes issue #1887 by making route registration follow the path declaration order in the OpenAPI spec rather than sorted alphabetical order. On routers that match in registration order (Fiber, Gorilla/mux) this gives users direct control over precedence between overlapping paths.

• pkg/util/loader.go: enables IncludeOrigin = true so kin-openapi records each path's source line; OperationDefinition gains a SpecOrder int populated from pathItem.Origin.Key.Line.
• pkg/codegen/operations.go: refactors all GenerateXServer functions to use the new GenerateTemplatesIntoBuffer helper, feeding sortOperationsBySpecOrder(operations) only to the registration template while leaving interface/middleware generation in the existing sorted order.
• internal/test/servers/routeorder/: new Fiber integration test that verifies /templates/privates/shortcuts dispatches to the earlier-declared {visibility}/shortcuts route rather than the later-declared privates/{id} route.

Confidence Score: 4/5

Safe to merge with minor follow-up; the core logic is sound and well-tested, but the route-registration order change is unconditional and will cause all existing generated files to diff on the next make generate run.

The implementation is correct — sortOperationsBySpecOrder makes a defensive copy, uses a stable sort, and handles the all-zero fallback cleanly. All nine router backends are updated in parallel, the new test directory follows the prescribed layout, and the generated fixtures show the expected ordering. The two open questions are: a misplaced godoc and whether the unconditional ordering change should be gated behind a compat flag.

pkg/codegen/operations.go — the doc comment placement and the compat-flag question both live here.

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
pkg/codegen/operations.go:1069-1074
**Misplaced godoc comment**

The line `// OperationDefinitions returns all operations for a swagger definition.` (originally the godoc for `OperationDefinitions`) is now the *first line* of `pathItemSourceLine`'s doc comment block. As a result, `go doc` will show `pathItemSourceLine` as starting with "OperationDefinitions returns all operations for a swagger definition.", and `OperationDefinitions` itself (line 1081) has no godoc at all. The `OperationDefinitions` comment line should be moved back to immediately precede `OperationDefinitions`, with a blank line separating the two function doc blocks.

### Issue 2 of 2
pkg/codegen/operations.go:1917-1924
**Unconditional behavior change — consider a compat flag**

Route-registration order now follows spec declaration order for all backends and all users, with no opt-out. The project's stated practice is that behavior-changing features be opt-in via a configuration flag (`compatibility` or `output-options`) rather than silent breaking changes. Users on order-dependent routers (Fiber, Gorilla/mux) who previously worked around the alphabetical ordering by arranging their spec paths alphabetically will silently get different runtime routing on the next code-gen run. It is worth asking whether this should be gated behind a flag (e.g. `compatibility.register-routes-in-spec-order`) so the change is opt-in rather than unconditional.

_{Reviews (1): Last reviewed commit: "Register handlers in spec order" | Re-trigger Greptile}

IMO, I think this may be an option we want a compatibility config option for @mromaszewicz, especially if it changes intent for everyone's specs

This only affects fiber and gorilla, and only in the case where a parameterized shallow path comes before a deeper path.

For example, if you have:

• /api/something/:param
• /api/something/anotherthing/foo

The first is going to shadow the second.

In every other router, path registration is order independent, so it's a no-op change, just a bit of generated code churn.

I think I want this default-on, but I can add an opt out flag (even though spec editing can accomplish the same thing)