{
  "context": "This criteria evaluates how well the implementation demonstrates understanding of at-least-once delivery semantics, message deduplication, and queue state management patterns as found in the @walletconnect/types package. The focus is on proper use of queue management concepts including state tracking, message acknowledgment, and deduplication mechanisms.",
  "type": "weighted_checklist",
  "checklist": [
    {
      "name": "Queue State Management",
      "description": "Implementation correctly maintains and transitions between IDLE and ACTIVE queue states. The QueueState type should be properly defined and used, with state changing to ACTIVE during message processing and returning to IDLE when complete.",
      "max_score": 20
    },
    {
      "name": "Message Structure",
      "description": "Messages are properly structured with unique identifiers and payloads. The Message interface should include an 'id' field for tracking and a generic 'payload' field for message data.",
      "max_score": 10
    },
    {
      "name": "Sequential Processing",
      "description": "Messages are processed in FIFO order (first-in, first-out). The queue should maintain insertion order and process messages sequentially, ensuring that earlier messages are handled before later ones.",
      "max_score": 15
    },
    {
      "name": "Acknowledgment Mechanism",
      "description": "Implementation provides an explicit acknowledge() method that marks messages as successfully processed. This method should be separate from the processing logic and update the internal tracking of processed messages.",
      "max_score": 15
    },
    {
      "name": "Message Deduplication",
      "description": "System tracks processed message IDs and prevents duplicate processing. The enqueue() method should return false when attempting to add a message with an ID that has already been processed, and isProcessed() should correctly report message processing status.",
      "max_score": 20
    },
    {
      "name": "At-Least-Once Delivery",
      "description": "Messages remain in the queue until explicitly acknowledged. If processing fails or handler throws an error, the message should stay in the queue for retry rather than being automatically removed or lost.",
      "max_score": 15
    },
    {
      "name": "Handler Pattern",
      "description": "Uses MessageHandler function type that accepts a Message and returns a Promise. This async handler pattern allows for proper error handling and supports the acknowledgment flow required for at-least-once delivery.",
      "max_score": 5
    }
  ]
}