A frontmatter list with one item is classified as an enum, so an attribute changes kind when a second value arrives

[heitorrapcinski]

The need, distilled

FacetExtractor decides the kind of an attribute by the number of values it happens to hold, not by the form the author wrote. kindOf only answers list when values.length > 1, so a frontmatter written as a list of one item is classified as enum:

tags: [contracts]          # kind: enum
tags: [contracts, budget]  # kind: list

The same attribute therefore has two different kinds across the notes of one vault, decided by a fact about a single note. Everything downstream that reads the kind — the display of a value as a chip or as text, and prefix matching once dates match by prefix — becomes inconsistent for reasons nobody can see from the note.

It also breaks a property worth keeping: adding a second value to an attribute MUST NOT change what that attribute is.

This was found by running the published conformance suite of the Markdown Profile against the extractors, which is the first thing that suite did.

Type

Defect, the product diverges from what the document already states.

Business rules created or changed

None. RN-DSC-020 already says the classification is by the shape of the value, and a list written with one item is a list. This is the code disagreeing with the rule, not the rule needing a new one.

Documents this delivery will update

• None. The rule already says it; the fix makes the code obey it. The justification is in the definition of done.

Definition of done

• tags: [contracts] and a dash list with a single item are classified as list.
• A scalar value stays enum: it is the written form that decides, not the count.
• The conformance case frontmatter/a-list-of-one-is-still-a-list passes.
• The frontend, which today infers a list from the brackets in splitFrontmatter, agrees with the extractor rather than reaching the same answer by another road.

What is declaredly left out

Any change to the forty-character prose ceiling or to the cardinality ceiling.

[heitorrapcinski]

Triage of the v0.5.0 cycle — accepted, and it is the first thing in the cycle.

The order is not a preference. #61 wires the published conformance suite into the build, and this is the case that suite fails on. Landing them the other way round means the first commit of the cycle breaks the build with a defect that predates it, and the reflex when that happens is to skip the case.

No rule is created, and that is the point: RN-DSC-020 already says the classification is by the shape of the value written, and a list of one item is a list. The fix is the code catching up with a rule that has been in force since it was written.

The last clause of the definition of done is the load-bearing one: the frontend has to agree with the extractor rather than reach the same answer by another road. splitFrontmatter infers a list from the brackets today, which is right by accident here and will not stay right by accident.

[heitorrapcinski]

Fixed on the branch of the cycle, in ab09148 on release/v0.5.0.

The cause was one level below kindOf: parseFrontmatter flattened every entry into a string[], which threw away the only thing that could distinguish tags: contracts from tags: [contracts]. Deciding the kind by the count was the consequence, not the mistake. The reader now carries the written form out with the values, and kindOf reads the form.

The property that was breaking is now a test of its own: the kind of tags: [contracts] and of tags: [contracts, budget] is asserted to be the same value, so a future change cannot restore the old behaviour without saying so.

On the frontend clause of the definition of done: splitFrontmatter already treated brackets and a dash line as a list, so it was right and the extractor was wrong. It may not import the extractor — the frontend takes types from @memorysmith/contracts and nothing else from the backend — so what makes them agree is that both are now pinned to the same four cases, in src/shared/api/markdown.test.ts, with a comment saying why the duplication is deliberate. #61 replaces both sets with the published conformance cases, which is where frontmatter/a-list-of-one-is-still-a-list gets proved by name.

Closed as completed. It reaches main with the pull request of the cycle (§7.4).