FEAT: Discovery Video Service Subscription

tests/README.md

@@ -12,7 +12,7 @@ The upload to storage is a plain `PUT` to the presigned URL the API hands out,
 with no AWS SDK involved, because that is exactly what a real client does.
 
 ```
-features/video_upload.feature   the scenarios, in Gherkin
+features/*.feature              the scenarios, in Gherkin
 suite_test.go                   the gobdd suite: step registration + per-scenario world
 steps_test.go                   what each step does
 client_test.go                  HTTP plumbing and the wire types
@@ -68,6 +68,26 @@ Both steps of the upload flow, end to end:
   the category lookup itself failing produces
 - answering 409 for a key that was already registered, rather than queueing a
   second transcoding job for the same file
+- announcing a video on the catalogue topic once its job comes back COMPLETE,
+  carrying its id, title, playback URL and the **names** of its categories —
+  and announcing nothing for a job that ended in an error
+
+- the read side building its catalogue from those announcements: the video
+  turns up in discovery under the id cms issued, a video still transcoding is
+  not there at all, and a video announced a second time is updated rather than
+  colliding with its own row
+
+The publication scenarios read `tests-catalogue-events`, the suite's **own**
+queue on the catalogue topic — not discovery's. A consumer destroys what it
+reads, so sharing discovery's queue would have the suite and the running
+service race for every announcement and each see about half. Delivery is raw,
+so a message body is the announcement with no SNS envelope.
+
+The ingestion scenarios need `discovery` up as well as `cms`; they read it over
+HTTP at `DISCOVERY_BASE_URL` (default `http://localhost:8080`).
+Like the job-state publisher they stand in for AWS, so they are the second
+place the suite reaches for the AWS SDK; everything a real client does still
+goes over plain HTTP.
 
 ## Adding a scenario