写入的答案所展示的实体与读取不同，以及整体对象更新¶

问题：https://github.com/morluto/rea/issues/4933

结果¶

代理根据一个提示为五个应用构建了环境，这些应用是提示流从未见过的（Vikunja、Ghost、EspoCRM、Paperless-ngx 和 Miniflux）。两个写入模型缺口扣留了它们的大部分创建和编辑：

• 创建的响应是实体的另一种视图，不同于其读取所呈现的视图。 Paperless 对标签创建的响应缺少其条目读取所显示的 document_count。EspoCRM 对联系人创建的响应缺少其条目读取所显示的九个字段。Vikunja 对标签创建的响应带有不完整的 created_by，且时间戳精确到纳秒，而读取显示完整用户和整秒。Ghost 对标签创建的响应缺少其列表所显示的 count。状态仅依据响应构建实体，因此回读与创建相矛盾。
• 整体对象更新会把应用推导出的内容发回。 Paperless 的 UI 将标签的旧 slug 与新名称一起发送，而应用会重新对新名称生成 slug。Ghost 的 UI 发送其读取到的 updated_at，而应用会盖上一个新的时间戳。该更新被扣留为 unexplained-change，或者其首次调用的值被固定，导致后续调用发生冲突。

行为¶

• 回读。 当在下次写入之前对已创建实体的首次读取显示出创建响应所缺少的字段，或将其时钟以另一种精度表示时，观察到的实体采用这些内容，计划会记录该读取（observation.read 及其形状）。
• 如果条目读取在其他方面与响应一致，它就会提供自己的字段和时钟拼写（纳秒时钟的整秒，或微秒时钟的微秒），并且不再确认该创建。如果某个条目读取在另一个值上不一致，或省略了其条目视图会渲染的响应字段，它仍会检查该创建，并与之相矛盾。
• 列表读取可能显示对象的较少键，它只添加响应缺少的字段，并且仍会检查该创建。
• 没有显示任何新内容的读取会保持观察不变，并且仍确认该创建。
• 服务过程会合并两个已记录的相同对象，因此被服务的创建会以其响应的形状作答，并存储两者的字段。创建响应中生成的时钟独立于所存储的回读精度，保留该响应所记录的精度。
• 重新加盖时间戳的时钟。 一个更新成员以实体原先持有的时钟被发回，并被存储为接近调用时刻的新时钟，这就是 clock 规则，接受任意值。
• 重新推导的 slug。 当一个更新成员的值被存储为另一个成员的 slug，且该调用按原发送值存储了那个成员时，这就是来自该成员的 slug 规则，接受任意值。
• 兼容的保存。 一个调用回显了已推导出的 slug，或在其自身记录的秒内持有一个时钟，都不会与已展示的推导相冲突，无论调用顺序如何。slug 推导还必须复现更早的保存；一个明确的自定义 slug 如果不一致，仍会扣留该更新。

不需要这些功能的计划和视图保持不变。

验收¶

• 之前被扣留的记录现在可以服务 EspoCRM 的联系人创建和 Paperless 的标签编辑。
• 如果某个创建的条目回读在另一个值上与其响应不一致，它仍被判定为矛盾。
• 在 69 个已记录的捕获中，没有任何写入工具会从已服务变为被扣留。