Summary
settings.write_defaults is specified as default true, and create says default-only fields must be written when this is true. But one conformance test currently expects a default-only field to be omitted when the type also has a generated field.
Spec references
04-configuration.md (settings.write_defaults default true; must write default-only fields when true)
12-operations.md create step 8 (must write default-only fields when write_defaults is true)
Conflicting test
tests/level-1/generated-default-interaction.yaml
- Group:
type with both generated and default on same field is valid
- Test:
create uses generated value not default
- Current expectation:
frontmatter_not_written: [category]
category is default-only (not generated). Under write_defaults: true (default), this should be written.
Proposed fix
Update the test to assert category is written (e.g. frontmatter_written: { category: "general" }).
This keeps generated-field precedence tests intact while aligning write behavior with the normative write_defaults semantics.
Summary
settings.write_defaultsis specified as defaulttrue, and create says default-only fields must be written when this is true. But one conformance test currently expects a default-only field to be omitted when the type also has a generated field.Spec references
04-configuration.md(settings.write_defaultsdefaulttrue; must write default-only fields when true)12-operations.mdcreate step 8 (must write default-only fields whenwrite_defaultsis true)Conflicting test
tests/level-1/generated-default-interaction.yamltype with both generated and default on same field is validcreate uses generated value not defaultfrontmatter_not_written: [category]categoryis default-only (not generated). Underwrite_defaults: true(default), this should be written.Proposed fix
Update the test to assert
categoryis written (e.g.frontmatter_written: { category: "general" }).This keeps generated-field precedence tests intact while aligning write behavior with the normative
write_defaultssemantics.