Worker Queue Message
定义
Worker Queue Message 是 Worker Service - Claude-Mem 摘要 中 queue.messages 数组里的单条记录结构，用来表示 Worker Service 队列中的一个工作项。该记录不是笼统的“任务”概念，而是带有明确字段的结构化消息：它既标识这条消息本身，也把消息连接到本地 session、Claude session，并记录其处理状态与处理时间。
从示例可见，这类消息记录至少包含以下字段集合：
idsession_db_idclaude_session_idmessage_typestatusretry_countcreated_at_epochstarted_processing_at_epochcompleted_at_epoch
在本文档中的语境
该结构出现在 Worker Service 的队列状态展示中，属于整个队列视图的一部分。文档同时给出了：
queue.messages：当前队列中的具体消息记录totalPending：待处理总数totalProcessing：处理中总数totalFailed：失败总数stuckCount：卡住的工作数量recentlyProcessed：最近已处理完成的消息摘要sessionsWithPendingWork：仍有待处理工作的 session 列表
因此，Worker Queue Message 的作用，是把这些聚合计数背后的“单条工作项”具体化。它是理解 Worker Service Queue State 的最细粒度对象之一。
关键组成
标识与归属字段
id 是消息记录自身的标识符。示例中该值为 123，说明队列中的每条消息都有独立编号，可与其他消息区分。
session_db_id 用于连接本地 session 记录。示例中其值为 45，表示这条工作属于本地数据库中的某个 session。
claude_session_id 用于连接 Claude 侧的 session 标识。示例中其值为 "abc123"。这说明一条队列消息同时保留了本地 session 标识与 Claude session 标识，两者职责不同：
session_db_id连接本地数据库里的 sessionclaude_session_id连接 Claude 体系中的 session 标识
这种双重归属意味着 Worker Service 处理消息时，不只是知道“要做什么”，还知道“这项工作分别隶属于哪一个本地 session 与哪一个 Claude session”。
消息类型字段
message_type 表示这条消息承载的工作类型。示例中其值为 observation，因此可以明确说明：该队列至少承载 observation 类型的工作。
原文没有列出更多 message_type 枚举值，因此目前只能确认 observation 是一个已出现的实际类型，不能从这段材料继续外推出全部类型集合。
状态与重试字段
status 表示消息当前所处的处理状态。示例中 queue.messages 内的记录为 pending，说明该消息当时仍在等待处理，尚未完成。
retry_count 表示这条消息已被重试的次数。示例中其值为 0，这表明该消息尚未发生重试。
把 status=pending 与 retry_count=0 放在一起看，可以得到更具体的判断：这是一条还未完成、且截至该快照时尚未进入重试流程的待处理消息。
处理生命周期时间轴
created_at_epoch、started_processing_at_epoch、completed_at_epoch 三个字段共同构成消息的处理生命周期时间轴。
它们分别对应：
created_at_epoch：消息被创建的时间started_processing_at_epoch：消息开始被 Worker 处理的时间completed_at_epoch：消息处理完成的时间
示例中的待处理消息具有如下取值：
created_at_epoch = 1730886600000started_processing_at_epoch = nullcompleted_at_epoch = null
这组值说明该消息已经创建，但还没有进入实际处理阶段，也尚未完成。因此在 pending 示例中，后两个时间戳为 null 是有意义的状态表达，而不是缺失数据。
换言之，至少在这份文档语境里：
- 已创建但未开始处理的消息，可以只有
created_at_epoch有值 - 当消息尚处于
pending时，started_processing_at_epoch与completed_at_epoch可以为null
与已处理消息的对照
文档还给出了 recentlyProcessed 中的一条记录：
id = 122session_db_id = 44status = processedcompleted_at_epoch = 1730886500000
这条对照记录表明，完成后的消息会呈现 status=processed，并拥有 completed_at_epoch。
因此，与 queue.messages 中那条 pending 消息相比，可以归纳出一个清晰边界：
pending消息示例中，completed_at_epoch为nullprocessed消息示例中，completed_at_epoch已有具体 epoch 时间值
不过，recentlyProcessed 示例只展示了部分字段，没有再次列出 claude_session_id、message_type、retry_count 或 started_processing_at_epoch。这说明“最近已处理列表”展示的是摘要视图，而不是完整消息结构的逐字段复刻。
细节与边界
1. 这是记录结构，不是整个队列状态
Worker Queue Message 只描述单条消息；它不同于整个队列的聚合状态。像 totalPending=5、totalProcessing=2、totalFailed=0、stuckCount=1 这些字段属于队列整体统计，不属于单条消息记录本身。
2. 已知字段来自示例，当前材料未给出完整约束
现有材料明确展示了上述 9 个字段，但没有说明：
- 每个字段是否都是必填
status的全部可能取值message_type的完整枚举retry_count的上限或重试策略
因此，本条目应把它理解为“来源示例中可确认的消息结构”，而不是已经穷尽所有实现细节的正式 schema。
3. null 具有状态语义
在这份示例中，started_processing_at_epoch 与 completed_at_epoch 为 null，并不是无意义空值，而是明确表示该消息尚未开始处理、尚未完成。也就是说，这两个字段的空值本身参与描述生命周期阶段。
4. session 维度可从消息回溯到队列级列表
示例里当前待处理消息的 session_db_id 为 45，而队列级还有 sessionsWithPendingWork = [44, 45, 46]。这表明单条消息记录中的 session 归属，可以与队列级“哪些 session 仍有待处理工作”的列表相互印证。