Implement MDY standard

[ggodlewski]

Implement MDY standard from:

mieweb/kerebron#115

Sample file:

https://github.com/mieweb/templit/blob/main/samples/simple.mdy

1. Run branch with: npx nx serve app-demo
2. Go to preview
3. In the editor type: Name: (#q1)

4. Copy editor content, paste to editor

---
q1:
  value: John
q2:
  value: email@example.com
---
Name: [John](#q1)

Email: [email@example.com](#q2)

[ggodlewski]

@horner can you have a look a this implementation?
@lattln can you add @horner as reviewer? I don't have access to this repo. Do you have access to rocket to notify him?

[lattln]

@horner can you have a look a this implementation? @lattln can you add @horner as reviewer? I don't have access to this repo. Do you have access to rocket to notify him?

done. will notify him. @ggodlewski

[lattln]

Code looks good, will do QA

[horner]

@ggodlewski We should only do this in a rich-text-mdy field and not rich-text. I think its an interesting idea to add it into the input of an eSheet, but I think this is like a snake eating itself. I think adding a rich-text-mdy type would be cool but we should differentiate it from a ordinary rich-text input.

I want there to be a mdy output of esheet that is consumable by a kerebron editor independent of the original esheet.

[lattln]

• Support existing eSheet field IDs, including hyphenated IDs such as what-is-your-email, in both typed and loaded MDY references.

q1:  
 value: q1
whatemail:
  value: 
---
q1: [q1](#q1)

q2: [email](#whatemail)

q3: (\\\\\\#what-color)

• Prevent richtext responses from being included as whole MDY documents in another rich-text field’s generated front matter.

Dirty Submission

---\nq1:\n  value: q1\nwhatemail:\n  value: \n---\nq1: [q1](#q1)\n\nq2: [w](#whatemail)\n\nq3: (\\\\\\#what-color)\n

• Return rich-text answers as structured data instead of an opaque Markdown string:

{
  answer: {
    frontmatter: {
      q1: { value: 'John' },
    },
    body: 'Name: [John](#q1)\n',
  },
}

• Reconstruct the complete MDY document only when supplying content to Kerebron.
• Define front-matter ownership and merge precedence: generated from eSheet responses, authored document data, or a documented hybrid.
• Update MDY references in rich-text content when a referenced eSheet field ID is renamed.
• Add focused tests for hyphenated IDs, MDY load/save behavior, structured response output, multiple rich-text fields, and field-ID renames.

[ggodlewski]

Nesting richtext won't work because MDY does not support multiline text.

[horner]

@ggodlewski

The data layer is full YAML parsed by js-yaml (parse.ts:1), so multiline text is fully supported via block scalars:

note:
  id: note-1
  text: |
    Line one.

    Line two — even **markdown** can live here.

The custom part of the pipeline (frontmatter.ts:6) only splits the --- fences; everything between them goes straight to the YAML parser, multiline included.

The real constraint on nesting rich text is elsewhere: a field link [display text](#id) is a CommonMark inline link, so the body projection of a value can't contain block-level content (paragraphs, lists, headings) inside the link text. So:

• Multiline/rich text in front matter: works fine (YAML block scalars).
• Rich multi-block display inside a single field-link span: doesn't work — but that's an inline-link limitation, not a "no multiline text" limitation. The spec's escape hatch would be rendering such a value as ordinary markdown blocks in the body (via the template) rather than as one chip.