Loading
feat: implement POST /traffic-influence-devices
Replace the 501 stub with a device-scoped create that reuses the existing traffic influence create path: 201 + Location, idempotency, app ownership check, zone resolution, notifications, GET and DELETE.
- Model CAMARA Device, DeviceIpv4Addr and DeviceResponse in full (phone pattern, publicAddress plus privateAddress or publicPort, IPv4/IPv6 format, at least one identifier); malformed input is 400.
- No device is 422 MISSING_IDENTIFIER (two-legged tokens only). A networkAccessIdentifier alone is 422 SERVICE_NOT_APPLICABLE, since this spec's 422 enum has no UNSUPPORTED_IDENTIFIER; alongside a supported identifier it is dropped, as in QoD.
- Send the device to SRM as network_capability.target.device, in the same canonical shape QoD uses.
- Add deviceResponse (a single identifier) to onTrafficInfluenceChanged. GET and list never return the device.
- Bring the endpoint under conformance; allow 422 for generated bodies that omit the schema-optional device.
Payloads validated against SRM's bus models on refactor/tf-sdk-wiring and codex/tfsdk-consumer-qualification. SRM develop still rejects every TI/QoD activate (no service_instance_id/source_spec), unrelated to this.
Not done: a new intent for the same device does not replace the previous one, and deviceResponse always reports phone first, while tf-sdk realizes TI from the device IPv4 only.