Error-type expectations (BadRequestData vs InvalidRequest; collection verbs; empty attr)
Error-type expectations that hinge on under-specified spec points (broker is consistent and defensible in each):
- **059_01_* / 007_02_02 / 015_01_01 / 050_02_02** — `BadRequestData` vs `InvalidRequest` split is inconsistent across the suite; § 8 needs a clear rule.
- **002_02_01 / 054_02_02 / 056_02_02** — confused expectations for verbs on the `/entities/` collection (broker: 400 for purge, 405 for undefined verbs).
- **016_02_06 / 016_02_04** — empty path segments on `PATCH /temporal/entities/{id}/attrs/{attrId}/{instanceId}`. `016_02_06` is an **embedded** empty segment (`…/attrs//{instanceId}`, broker **400**); `016_02_04` a **trailing** one (`…/attrs/{attrId}/`, broker **405**) — both currently expect 405. RFC 3986 §6 collapses neither (only dot-segments), so a trailing empty component is just as significant as an embedded one; the broker's 405-for-trailing rests on a trailing-slash convention, not on the RFC. § 8 should state how embedded vs trailing empty path components (and `//` / `///`) are handled so the status code is deterministic. See comment for the full analysis.
issue