[Question][v2.0.1][MemoryCore L0] Message ID、写入确认、timestamp 与 ID 格式 Contract 确认

[2p42c7vsdg]

[Question][v2.0.1][MemoryCore L0] Message ID、写入确认、时间戳及 ID 格式的正式语义确认

我们正在将 TencentDB Agent Memory v2.0.1 用作一个本地 Agent 的显式长期记忆存储，并在调用方实现严格的 write → read-back 校验。

环境：

• TencentDB Agent Memory：v2.0.1
• 本地 self-hosted MemoryCore
• DSH 私有实例，本机端口映射为 127.0.0.1:8422
• 仅显式写入，capture / extraction 自动路径关闭
• 调用方通过自定义 adapter 调用 L0 conversation write/query
• 每次写入后立即回读，校验正文、SHA-256、accepted_ids 与时间字段

我们已经阅读 v2.0.1 源码，因此下面主要希望确认的是官方 Contract / 保证语义，而不是单次实现观察。

Q1｜L0 message ID 的唯一性与复用

v2.0.1 中观察到生成的 ID 形如：

msg-146ffd82314e

请确认官方 Contract：

1. 一个 L0 message ID 的唯一性范围是什么：单 session、单 identity、单 Memory 实例，还是更大范围？
2. 是否保证一个已经分配过的 ID 永远不会再次分配给另一条消息？
3. 调用方是否可以把 accepted_ids 中的 ID 作为一次具体写入的永久唯一归因依据？

如果这里只是概率唯一而不是 Contract 保证，也请明确说明。

Q2｜完全相同正文的重复写入

如果在相同 identity / task_id / session 下，短时间连续两次写入完全相同的正文：

1. 是否保证生成两条独立 L0 message；
2. 是否保证得到两个不同 ID；
3. L0 是否存在任何按正文、hash 或其他字段进行 dedup / idempotency 的机制？

如果存在幂等或去重，请说明对应 key 与触发条件。

Q3｜code: 0 + accepted_ids 的持久化语义

收到：

{"code":0,"data":{"accepted_ids":[...],"accepted_versions":["v1"],"total_count":1}}

时，请确认：

1. 是否表示 L0 authoritative store 的写操作已经成功完成；
2. 返回成功后，对同一实例立即执行 conversation query，是否具有 read-after-write consistency；
3. L1/L2/L3 后续异步 pipeline 是否与上述 L0 成功语义完全独立；
4. 是否存在返回 code:0 + accepted_ids 后 L0 实际仍不可读取的正常情况；
5. 如果一个包含多条 message 的请求在中间部分失败，是否可能出现“前几条已经持久化、整个请求最终返回失败”的 partial write。

我们关注的是 L0 本身，不要求异步 L1 extraction 已完成。

Q4｜timestamp 与 recorded_at 的正式语义

v2.0.1 API 同时允许 message 携带 timestamp 与 recorded_at。

请确认：

1. timestamp 的正式定义；
2. recorded_at 的正式定义；
3. 当调用方不传二者时，各自由谁生成；
4. conversation query 返回的 messages[].timestamp 对应原始 message timestamp、server recorded_at，还是其他字段；
5. 是否存在官方规定的时间精度或最大时钟偏差保证。

我们的调用方与 MemoryCore 位于同一台物理机器，但希望避免依赖未经定义的 NTP / clock-skew 假设。

Q5｜Message ID 格式是否属于稳定 API Contract

v2.0.1 实际观察为：

msg-<hex>

请确认：

1. msg- 前缀是否属于稳定 Contract；
2. hex 字符集及长度是否保证；
3. 后续版本是否允许改为更长 ID、UUID、其他前缀或其他 opaque ID；
4. 客户端是否应把 message ID 当作 opaque string，而不对具体格式做 fail-closed 校验。

我们的目的不是依赖内部实现，而是确定客户端验证器哪些条件可以成为长期稳定的机器 Gate。

如果 v2.0.1 与当前最新版的 Contract 已有差异，也烦请分别说明：

• v2.0.1 的保证；
• 当前推荐版本的保证；
• 是否属于 breaking change。

感谢。