spec/plans: pin WAMP §14.4 message-ordering guarantee

Two plans pin the broker's per-publisher ordering contract:

  035  Single publisher emits 10 sequence-numbered events fire-and-forget;
       subscriber reads them in strict publish order. Relies on the chain
       of FIFO queues (publisher outbound → broker → subscriber inbound)
       to preserve order without explicit acks.

  036  Two publishers alternate publishes with acknowledge=true on the
       same topic. Each PUBLISH waits for PUBLISHED before the next is
       sent, serializing broker dispatch. Subscriber reads events in
       publish-completion order (A1, B1, A2, B2, A3, B3) — verifies both
       per-publisher ordering (A1 < A2 < A3, B1 < B2 < B3) and the
       broker's FIFO behavior.

Existing plans (018 eligible/exclude, 024 publisher exclusion) covered
ordering only as a side-effect of sequential queue reads on a single
subscriber. These two pin it as the primary assertion.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: Marko Petzold

spec/plans/basic/035_pubsub_single_publisher_ordering.yaml

@@ -0,0 +1,80 @@
+name: events-from-single-publisher-arrive-at-subscriber-in-publish-order
+spec_section: "Basic Profile §3.5 / Advanced §14.4 — message ordering"
+realm: realm1
+serializer: json
+
+# WAMP §14.4: events from a single publisher session must be delivered
+# to any given subscriber in the order they were published. Pinned here
+# by publishing 10 sequence-numbered events fire-and-forget, then
+# reading the subscriber's queue in order. The matcher fails on the
+# first out-of-order payload because the runner reads peer queues
+# strictly FIFO.
+peers:
+  - name: subscriber
+  - name: publisher
+
+steps:
+  - peer: subscriber
+    send: [1, "realm1", {roles: {subscriber: {}}}]
+  - peer: subscriber
+    expect: [2, "{{$sub_session:int}}", "_"]
+
+  - peer: subscriber
+    send: [32, 35001, {}, "spec.test.order"]
+  - peer: subscriber
+    expect: [33, 35001, "{{$sub_id:int}}"]
+
+  - peer: publisher
+    send: [1, "realm1", {roles: {publisher: {}}}]
+  - peer: publisher
+    expect: [2, "{{$pub_session:int}}", "_"]
+
+  # Fire 10 PUBLISHes back-to-back without acknowledge. The publisher's
+  # outbound channel is FIFO, the broker processes messages from one
+  # client in receive order, and the subscriber's inbound is FIFO —
+  # together these chain a per-publisher order guarantee.
+  - peer: publisher
+    send: [16, 35101, {}, "spec.test.order", ["seq", 1]]
+  - peer: publisher
+    send: [16, 35102, {}, "spec.test.order", ["seq", 2]]
+  - peer: publisher
+    send: [16, 35103, {}, "spec.test.order", ["seq", 3]]
+  - peer: publisher
+    send: [16, 35104, {}, "spec.test.order", ["seq", 4]]
+  - peer: publisher
+    send: [16, 35105, {}, "spec.test.order", ["seq", 5]]
+  - peer: publisher
+    send: [16, 35106, {}, "spec.test.order", ["seq", 6]]
+  - peer: publisher
+    send: [16, 35107, {}, "spec.test.order", ["seq", 7]]
+  - peer: publisher
+    send: [16, 35108, {}, "spec.test.order", ["seq", 8]]
+  - peer: publisher
+    send: [16, 35109, {}, "spec.test.order", ["seq", 9]]
+  - peer: publisher
+    send: [16, 35110, {}, "spec.test.order", ["seq", 10]]
+
+  # Read events back in strict order. Each EVENT has a distinct
+  # publication id (captured under unique placeholder names so the
+  # matcher confirms they're all integers) and the payload sequence
+  # number must match the publish order.
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$pub1:int}}",  "_", ["seq", 1]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$pub2:int}}",  "_", ["seq", 2]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$pub3:int}}",  "_", ["seq", 3]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$pub4:int}}",  "_", ["seq", 4]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$pub5:int}}",  "_", ["seq", 5]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$pub6:int}}",  "_", ["seq", 6]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$pub7:int}}",  "_", ["seq", 7]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$pub8:int}}",  "_", ["seq", 8]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$pub9:int}}",  "_", ["seq", 9]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$pub10:int}}", "_", ["seq", 10]]

spec/plans/basic/036_pubsub_two_publishers_ordering.yaml

@@ -0,0 +1,88 @@
+name: per-publisher-ordering-preserved-across-two-publishers
+spec_section: "Basic Profile §3.5 / Advanced §14.4 — message ordering"
+realm: realm1
+serializer: json
+
+# Stronger ordering guarantee: with two distinct publishers writing to
+# the same topic, the WAMP spec only mandates per-publisher order
+# (A1 < A2 < … from publisher A, B1 < B2 < … from publisher B), not
+# any cross-publisher interleaving.
+#
+# To make this deterministically testable in the wire harness, we
+# alternate publishes with `acknowledge: true` and wait for PUBLISHED
+# before issuing the next. That serializes the broker's processing
+# through one publish-cycle at a time, so the subscriber's queue ends
+# up in the publish-completion order: A1, B1, A2, B2, A3, B3.
+# This still verifies the strong contract (each publisher's stream
+# arrives in order) and additionally pins the broker's FIFO behavior.
+peers:
+  - name: subscriber
+  - name: pubA
+  - name: pubB
+
+steps:
+  - peer: subscriber
+    send: [1, "realm1", {roles: {subscriber: {}}}]
+  - peer: subscriber
+    expect: [2, "{{$sub_session:int}}", "_"]
+  - peer: subscriber
+    send: [32, 36001, {}, "spec.test.order.multi"]
+  - peer: subscriber
+    expect: [33, 36001, "{{$sub_id:int}}"]
+
+  - peer: pubA
+    send: [1, "realm1", {roles: {publisher: {}}}]
+  - peer: pubA
+    expect: [2, "{{$a_session:int}}", "_"]
+
+  - peer: pubB
+    send: [1, "realm1", {roles: {publisher: {}}}]
+  - peer: pubB
+    expect: [2, "{{$b_session:int}}", "_"]
+
+  # Round 1.
+  - peer: pubA
+    send: [16, 36101, {acknowledge: true}, "spec.test.order.multi", ["A", 1]]
+  - peer: pubA
+    expect: [17, 36101, "{{$a1:int}}"]
+
+  - peer: pubB
+    send: [16, 36201, {acknowledge: true}, "spec.test.order.multi", ["B", 1]]
+  - peer: pubB
+    expect: [17, 36201, "{{$b1:int}}"]
+
+  # Round 2.
+  - peer: pubA
+    send: [16, 36102, {acknowledge: true}, "spec.test.order.multi", ["A", 2]]
+  - peer: pubA
+    expect: [17, 36102, "{{$a2:int}}"]
+
+  - peer: pubB
+    send: [16, 36202, {acknowledge: true}, "spec.test.order.multi", ["B", 2]]
+  - peer: pubB
+    expect: [17, 36202, "{{$b2:int}}"]
+
+  # Round 3.
+  - peer: pubA
+    send: [16, 36103, {acknowledge: true}, "spec.test.order.multi", ["A", 3]]
+  - peer: pubA
+    expect: [17, 36103, "{{$a3:int}}"]
+
+  - peer: pubB
+    send: [16, 36203, {acknowledge: true}, "spec.test.order.multi", ["B", 3]]
+  - peer: pubB
+    expect: [17, 36203, "{{$b3:int}}"]
+
+  # Subscriber reads in publish-completion order.
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$a1:int}}", "_", ["A", 1]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$b1:int}}", "_", ["B", 1]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$a2:int}}", "_", ["A", 2]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$b2:int}}", "_", ["B", 2]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$a3:int}}", "_", ["A", 3]]
+  - peer: subscriber
+    expect: [36, "{{$sub_id:int}}", "{{$b3:int}}", "_", ["B", 3]]