Query and read barrier
Queries must be routed to the Delay Shard that owns the Command's receipt or Source Position. A random healthy Worker cannot answer an applied result from a stale local projection.
Queued versus applied
A CommandQueuedReceipt identifies the ingress persistence event and gives the caller a locator for later lookup. It does not prove Schedule application. A CommandAppliedReceipt or equivalent query result is produced only after the shard has durably recorded an APPLIED or REJECTED outcome.
Query Barrier
The Query Barrier is a Source Position through which an ACTIVE_FOR_COMMANDS shard must have durably applied Commands before answering a read-after-command query conclusively. It is based on source progress and physical identity, not on receipt arrival at the SDK.
The barrier does not require every Destination Lane to be READY. A message can have a conclusive applied state while its destination is waiting for capability, capacity, recovery, retry, or evidence work.
Safe projections
The query path verifies command identity, canonical hash, route/partition, source metadata, and the relevant state version. It distinguishes full state, compact terminal state, evidence-expired state, and pending state rather than inventing fields that are no longer retained.
Query results also retain the difference between business application and external publication:
APPLIED Schedule -> Delayed Message state exists
PUBLISHING -> a durable admission exists; producer outcome is pending
UNCERTAIN -> side effect cannot yet be classified
PUBLISHED -> capability-specific destination evidence exists
Source anchors
docs/Nereus Delay V1 设计.md, section 17.docs/adr/0018-route-queries-by-receipt-and-read-through-a-source-barrier.md.docs/adr/0034-make-command-application-deterministic-under-replay.md.