从每次调用中学习创建、排序数组和引用实体¶

Issue: https://github.com/morluto/rea/issues/4933

结果¶

在 derived-values 变更之后，基于 prompt 构建的环境中的创建仍会因写入模型未涵盖的四个原因而被扣留或失败：

• 创建计划仅从工具的第一次调用中学习，因此后续调用发送了第一次未发送的成员（如 Linkding 的 shared），或遗漏了某个成员，即使在其他所有方面都与计划一致，也会被拒绝。
• Linkding 将 tag_names 按排序存储，因此以其他顺序发送标签的调用不会得到回显，其创建会被扣留或产生矛盾。
• Homebox 的 item 创建在其发送的 parentId 和 entityTypeId 之外，还将父级和类型作为完整对象（parent、location、entityType）返回。若将它们作为常量保留，就会把这些成员固定为记录到的值。
• 列表显示的某些对象所含键少于实体实际持有的键：Homebox 列出 item 的父级时不包含父级自身的类型，Keycloak 列出用户的 access 时只显示一个键。创建实体的对象会完整渲染，因此列表检查失败。

行为¶

• 每次调用。 后续创建会单独解释，并在两次调用显示相同字段时合并到计划中；但对于某个引用而言，若一次未发送该成员的调用确实省略了它（先前创建添加的成员会保留），则两个规则共同约束的每个字段的约束都一致，而无规则约束的字段保持单一取值。任一调用发送过的成员都被接受，仅那些每次调用都发送的成员才是必需的；调用遗漏但被回显的成员，取值自该调用存储的值（body.defaults）。仅当没有任何已持有实体或先前调用以固定宽度显示它时，时钟才扩展为 trimmed。后续创建若存在分歧，计划保持原样并照旧判断；若某次调用遗漏了计划会填充的成员，同时在其他方面显示了该字段，则为 unexplained-change。合并规则保持计划的原有顺序。
• 排序数组。 当应用按码点顺序而非发送时的顺序存储所发送的字符串时，回显即为 sorted；服务时也会按排序存储。普通回显与排序回显互相一致，计划保留排序版本，因为数组已经有序的调用无法体现这一点；一旦某次调用按原发送顺序存储了乱序字符串，它们就不再一致。
• 引用。 当创建或更新的对象字段包含某发送成员所命名的实体的字段（按状态持有它们的方式）时，该字段即为 reference（成员、类型、字段）。命名此类实体的多个成员会解析为与字段同名的那个成员。该成员接受任意值。重放和服务会在其持有的状态中查找该实体；服务会拒绝命名了环境未持有、或在多个集合中持有的实体的调用；当调用未发送该成员时，该字段在实体和创建应答中均不出现。若某次更新发送了命名该字段已重复包含的实体的成员，则它会保留先前调用所显示的 reference。
• 嵌套视图键。 如果某个视图始终以相同的键（任意顺序）显示某字段的对象，且键数少于实体存储的键，则按首次记录的顺序在 nested_fields 中命名这些键；从未记录过的已存储对象也会以这些键渲染。

不需要这些行为的计划和视图保持不变。

验收¶

• Linkding 通过 prompt 记录的 bookmark 创建（回读时标签按排序列出）能够被服务，Homebox 的 item 创建也能被解释，且不会固定其父级或类型。
• 在 69 个记录的捕获中，没有任何写入工具从可服务变为被扣留。