contract: over-ceiling repeated uint32 filter 400 (categoryId[] etc.) is declared but never witnessed by a replaying golden

[SyniRon]

This was generated by AI — surfaced during the #194 swarm review (follow-up to #191).

Observation

The repeated uint32 filter parameters on GET /api/v1/tickets — categoryId[], statusId[], prefixId[], assignedUserId[], starterUserId[] — carry maximum: 4294967295 on their array items, and TestSpec_Uint32ParamsBounded structurally pins that the bound is declared. But:

• pb33f/libopenapi-validator does not enforce a numeric maximum on array items at request-validation time, and
• no golden replays an over-ceiling repeated filter (e.g. category_id=4294967296).

The request binder does produce a real 400 {"code":3,"message":"... value out of range"} for these inputs — it just isn't witnessed by a replaying golden the way the scalar case is (tickets/list_modified_since_over_uint32 witnesses the scalar binder behavior once).

Why it matters

Two-way contract coverage is the project's discipline: a declared error that no golden replays can drift silently. This is a completeness gap, not a correctness hole (the binder behavior is identical to the already-witnessed scalar path), but the array surface is currently un-pinned at the byte level.

Possible direction (for triage)

Add a golden, e.g. tickets/list_category_over_uint32 (?category_id=4294967296), witnessing the response-level 400, mirroring list_modified_since_over_uint32.

Surfaced by the test-coverage review on PR #194. needs-triage.

[SyniRon]

This was generated by AI during triage.

Agent Brief

Category: chore (contract-coverage backfill)
Summary: Add a replaying golden that witnesses the over-ceiling 400 for a repeated uint32 filter param on GET /api/v1/tickets, mirroring the already-witnessed scalar case.

Current behavior:
The repeated uint32 filter params on GET /api/v1/tickets — categoryId[], statusId[], prefixId[], assignedUserId[], starterUserId[] — carry maximum: 4294967295 on their array items, and a structural spec test pins that the bound is declared. But pb33f/libopenapi-validator does not enforce a numeric maximum on array items at request-validation time, and no golden replays an over-ceiling repeated filter. The request binder does produce a real 400 {"code":3,"message":"... value out of range"} for these inputs — behaviorally identical to the already-witnessed scalar path — but the array surface is not pinned at the response/byte level the way the scalar case is (the scalar modified_since over-ceiling golden witnesses it once).

Desired behavior:
At least one repeated/array uint32 filter has a replaying golden that witnesses the response-level 400 for an over-ceiling value, closing the two-way (declare + replay) coverage gap so the declared-but-unenforced array bound cannot drift silently.

Key interfaces:

• The contract battery (the table of replay cases) — add a case sending an over-ceiling value through a repeated uint32 filter, e.g. GET /api/v1/tickets?category_id=4294967296 with read:tickets auth, mirroring the existing scalar over-uint32 case.
• The golden corpus under the tickets group — record the corresponding golden capturing status 400, code 3, and the binder's "value out of range" body, in the same shape as the scalar over-uint32 golden.
• The existing structural spec test that pins the declared array-items maximum stays as-is — this issue adds the replay half, it does not replace the structural half.

Acceptance criteria:

• A new battery case sends an over-ceiling value through a repeated uint32 filter param (category_id suggested) wired with read:tickets auth.
• A recorded golden witnesses the response: status 400, code 3, and the binder's "value out of range" message for that param.
• The full golden suite (record + replay) is green, including the new case.
• The case carries a note documenting that it pins the response-level array bound, complementing the structural spec test that pins the declared bound (the same split the scalar case documents).

Out of scope:

• Making libopenapi-validator enforce numeric maximum on array items at request-validation time — the binder's 400 is the contract; this is coverage, not a behavior change.
• Goldens for all five repeated filters — one representative (category_id) closes the gap; more are welcome, not required.
• Any change to the binder behavior itself.

---

Dependency / sequencing (graph around #134):

• Independent of Phase 3 cutover: single listener, datastore type-swap, Keycloak removal, deliberate breaks live #134 — the binder behavior it witnesses already shipped (spec: OpenAPI under-describes real error behavior — undeclared 400s and missing uint32 bounds surfaced by property-based testing #191). The golden replays at the HTTP layer over the fake datastore and does not need the cutover.
• Lands before Phase 3 cutover: single listener, datastore type-swap, Keycloak removal, deliberate breaks live #134. Phase 3 cutover: single listener, datastore type-swap, Keycloak removal, deliberate breaks live #134's acceptance gate is "full golden suite green / two-way spec coverage green," and the golden corpus is its red suite — adding this golden first pins the array-400 surface before the cutover relies on the corpus, so the cutover is then verified to preserve it. It does not hard-gate Phase 3 cutover: single listener, datastore type-swap, Keycloak removal, deliberate breaks live #134.