[finding] The singular section: census is 4, not 3 — concept.mdx carries a 4th nameless one, plus two more in an unjudged JSON fence #13880

Description

@os-project-manager

Found while implementing #13759 (the three singular section: sites in layout-dsl.mdx).
Filed separately, not folded in: the triage ruling on #13759 fenced the population question
out of that PR, and this finding is exactly that question wearing a concrete example.

The measurement

Re-running the #13759 census with the same yaml parser and the same classifyYamlFence
the #11887 arm uses, on 8c6a7fc0b, over all of content/docs/**, with no marker filter:

yaml fences scanned : 148 (judged 145, skipped 3 on a syntax error)
singular `section:` mappings : 4
NAMELESS content/docs/protocol/objectui/concept.mdx:426 label="Billing Info" keys=label|fields
NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:235 label="Contact Information" keys=label|columns|fields
NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:263 label="Product Details" keys=label|columns|fields
NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:295 label=null keys=columns|fields

The population is 4, not the 3 the #13759 card recorded. #13759 fixed its three; the
concept.mdx one is untouched and still live.

Why the card counted 3 — the census was scoped by MARKER, not by shape

Not drift, and not a fourth that appeared since: - section: is present at concept.mdx:425
in af01080e3 itself, the commit the card measured on. Two control runs separate the
hypotheses:

  • re-running the census with the gate's own YAML_SECTIONS_KEY pre-filter
    (/(^|[^A-Za-z0-9_$.])sections\s*:/m) yields 0, not 3 — so the card did not use it;
  • grep for the marker yields exactly the card's 3:
    os:check-yaml FormSectionSchema key=section appears 3 times in content/docs/**, all in
    layout-dsl.mdx.

So the card's population was "fences carrying the singular key=section marker", and it was
reported as "the singular population across all of content/docs/**". concept.mdx carries
no os:check-yaml markers at all (check:yaml-examples reports it as 0 tagged / 10 untagged), so it is invisible to that scoping.

Why it is not a copy of the #13759 edit

The concept.mdx site is a different enclosing shape and needs a decision #13759 did not take:

customizations:
- field: phonerequired: true
- section: # <- the 4th nameless singular sectionlabel: Billing Infofields: [payment_terms, credit_limit]
  1. The enclosing shape has no schema. This is the page's "Layer 2: Admin Customization"
    example. A customizations:sequence of { field | section } overlay entries is
    declared nowhere in packages/spec — the only customizations in the authorable surface
    is tenant.zod.ts's z.record(z.string(), z.unknown()), a free-form record. Whether this
    fence teaches a real shape at all is the prior question; giving it a name polishes an
    example that may want removing or rewriting instead. Compare the steps: callout already
    on layout-dsl.mdx, which removed a phantom rather than repairing it.
  2. Its sibling fence is unjudged too, and is not YAML. The "Final Merged Layout" block
    directly below (concept.mdx:440) is a ```json fence carrying two more nameless
    sections ("label": "Contact Information", `"label": "Billing Info"`) inside a real
    `"sections": [ ... ]` array. `json` is in neither `TS_FENCE_LANGS` nor `YAML_FENCE_LANGS`,
    so both arms of `check-docs-section-name` pass over it. Fixing the YAML half alone would
    teach an anchor that vanishes from the merged output shown two paragraphs later.

Why the population question is the real subject

check-docs-section-name judges sections:sequences in both arms. This finding adds two
more shapes that carry form sections and that neither arm reaches — a singular section:
mapping, and a sections: array in a json fence — which is the same drift #10830 and #11887
each closed one selector at a time. Deciding the gate's population means deciding which keys
and which fence languages introduce a form section, together with how the os:check-yaml
marker vocabulary is read. That is a triage call, not a dev call, and it is the one #13759
deliberately deferred.

Sites, for whoever picks this up:

sitefenceshape
content/docs/protocol/objectui/concept.mdx:426```yaml, untagged- section: under customizations:, label: Billing Info
content/docs/protocol/objectui/concept.mdx:444```json, unjudged by both arms"label": "Contact Information"
content/docs/protocol/objectui/concept.mdx:452```json, unjudged by both arms"label": "Billing Info"

⛔ Not a schema change either way: FormSectionSchema.name stays .optional() (#10709,
reaffirmed #10830).

Back-links: #13759, #11887, #10830, #10709

Metadata

Metadata

Assignees

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
     blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
    }
    } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
    })();
    (function(){
    try {
    var __m = "github.com";
    var __re = new RegExp('^' + "github\\.com" + '
    
    Skip to content

    [finding] The singular section: census is 4, not 3 — concept.mdx carries a 4th nameless one, plus two more in an unjudged JSON fence #13880

    Description

    @os-project-manager

    Found while implementing #13759 (the three singular section: sites in layout-dsl.mdx).
    Filed separately, not folded in: the triage ruling on #13759 fenced the population question
    out of that PR, and this finding is exactly that question wearing a concrete example.

    The measurement

    Re-running the #13759 census with the same yaml parser and the same classifyYamlFence
    the #11887 arm uses, on 8c6a7fc0b, over all of content/docs/**, with no marker filter:

    yaml fences scanned : 148 (judged 145, skipped 3 on a syntax error)
    singular `section:` mappings : 4
    NAMELESS content/docs/protocol/objectui/concept.mdx:426 label="Billing Info" keys=label|fields
    NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:235 label="Contact Information" keys=label|columns|fields
    NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:263 label="Product Details" keys=label|columns|fields
    NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:295 label=null keys=columns|fields
    

    The population is 4, not the 3 the #13759 card recorded. #13759 fixed its three; the
    concept.mdx one is untouched and still live.

    Why the card counted 3 — the census was scoped by MARKER, not by shape

    Not drift, and not a fourth that appeared since: - section: is present at concept.mdx:425
    in af01080e3 itself, the commit the card measured on. Two control runs separate the
    hypotheses:

    • re-running the census with the gate's own YAML_SECTIONS_KEY pre-filter
      (/(^|[^A-Za-z0-9_$.])sections\s*:/m) yields 0, not 3 — so the card did not use it;
    • grep for the marker yields exactly the card's 3:
      os:check-yaml FormSectionSchema key=section appears 3 times in content/docs/**, all in
      layout-dsl.mdx.

    So the card's population was "fences carrying the singular key=section marker", and it was
    reported as "the singular population across all of content/docs/**". concept.mdx carries
    no os:check-yaml markers at all (check:yaml-examples reports it as 0 tagged / 10 untagged), so it is invisible to that scoping.

    Why it is not a copy of the #13759 edit

    The concept.mdx site is a different enclosing shape and needs a decision #13759 did not take:

    customizations:
    - field: phonerequired: true
    - section: # <- the 4th nameless singular sectionlabel: Billing Infofields: [payment_terms, credit_limit]
    1. The enclosing shape has no schema. This is the page's "Layer 2: Admin Customization"
      example. A customizations:sequence of { field | section } overlay entries is
      declared nowhere in packages/spec — the only customizations in the authorable surface
      is tenant.zod.ts's z.record(z.string(), z.unknown()), a free-form record. Whether this
      fence teaches a real shape at all is the prior question; giving it a name polishes an
      example that may want removing or rewriting instead. Compare the steps: callout already
      on layout-dsl.mdx, which removed a phantom rather than repairing it.
    2. Its sibling fence is unjudged too, and is not YAML. The "Final Merged Layout" block
      directly below (concept.mdx:440) is a ```json fence carrying two more nameless
      sections ("label": "Contact Information", `"label": "Billing Info"`) inside a real
      `"sections": [ ... ]` array. `json` is in neither `TS_FENCE_LANGS` nor `YAML_FENCE_LANGS`,
      so both arms of `check-docs-section-name` pass over it. Fixing the YAML half alone would
      teach an anchor that vanishes from the merged output shown two paragraphs later.

    Why the population question is the real subject

    check-docs-section-name judges sections:sequences in both arms. This finding adds two
    more shapes that carry form sections and that neither arm reaches — a singular section:
    mapping, and a sections: array in a json fence — which is the same drift #10830 and #11887
    each closed one selector at a time. Deciding the gate's population means deciding which keys
    and which fence languages introduce a form section, together with how the os:check-yaml
    marker vocabulary is read. That is a triage call, not a dev call, and it is the one #13759
    deliberately deferred.

    Sites, for whoever picks this up:

    sitefenceshape
    content/docs/protocol/objectui/concept.mdx:426```yaml, untagged- section: under customizations:, label: Billing Info
    content/docs/protocol/objectui/concept.mdx:444```json, unjudged by both arms"label": "Contact Information"
    content/docs/protocol/objectui/concept.mdx:452```json, unjudged by both arms"label": "Billing Info"

    ⛔ Not a schema change either way: FormSectionSchema.name stays .optional() (#10709,
    reaffirmed #10830).

    Back-links: #13759, #11887, #10830, #10709

    Metadata

    Metadata

    Assignees

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
      Skip to content

      [finding] The singular section: census is 4, not 3 — concept.mdx carries a 4th nameless one, plus two more in an unjudged JSON fence #13880

      Description

      @os-project-manager

      Found while implementing #13759 (the three singular section: sites in layout-dsl.mdx).
      Filed separately, not folded in: the triage ruling on #13759 fenced the population question
      out of that PR, and this finding is exactly that question wearing a concrete example.

      The measurement

      Re-running the #13759 census with the same yaml parser and the same classifyYamlFence
      the #11887 arm uses, on 8c6a7fc0b, over all of content/docs/**, with no marker filter:

      yaml fences scanned : 148 (judged 145, skipped 3 on a syntax error)
      singular `section:` mappings : 4
      NAMELESS content/docs/protocol/objectui/concept.mdx:426 label="Billing Info" keys=label|fields
      NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:235 label="Contact Information" keys=label|columns|fields
      NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:263 label="Product Details" keys=label|columns|fields
      NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:295 label=null keys=columns|fields
      

      The population is 4, not the 3 the #13759 card recorded. #13759 fixed its three; the
      concept.mdx one is untouched and still live.

      Why the card counted 3 — the census was scoped by MARKER, not by shape

      Not drift, and not a fourth that appeared since: - section: is present at concept.mdx:425
      in af01080e3 itself, the commit the card measured on. Two control runs separate the
      hypotheses:

      • re-running the census with the gate's own YAML_SECTIONS_KEY pre-filter
        (/(^|[^A-Za-z0-9_$.])sections\s*:/m) yields 0, not 3 — so the card did not use it;
      • grep for the marker yields exactly the card's 3:
        os:check-yaml FormSectionSchema key=section appears 3 times in content/docs/**, all in
        layout-dsl.mdx.

      So the card's population was "fences carrying the singular key=section marker", and it was
      reported as "the singular population across all of content/docs/**". concept.mdx carries
      no os:check-yaml markers at all (check:yaml-examples reports it as 0 tagged / 10 untagged), so it is invisible to that scoping.

      Why it is not a copy of the #13759 edit

      The concept.mdx site is a different enclosing shape and needs a decision #13759 did not take:

      customizations:
      - field: phonerequired: true
      - section: # <- the 4th nameless singular sectionlabel: Billing Infofields: [payment_terms, credit_limit]
      1. The enclosing shape has no schema. This is the page's "Layer 2: Admin Customization"
        example. A customizations:sequence of { field | section } overlay entries is
        declared nowhere in packages/spec — the only customizations in the authorable surface
        is tenant.zod.ts's z.record(z.string(), z.unknown()), a free-form record. Whether this
        fence teaches a real shape at all is the prior question; giving it a name polishes an
        example that may want removing or rewriting instead. Compare the steps: callout already
        on layout-dsl.mdx, which removed a phantom rather than repairing it.
      2. Its sibling fence is unjudged too, and is not YAML. The "Final Merged Layout" block
        directly below (concept.mdx:440) is a ```json fence carrying two more nameless
        sections ("label": "Contact Information", `"label": "Billing Info"`) inside a real
        `"sections": [ ... ]` array. `json` is in neither `TS_FENCE_LANGS` nor `YAML_FENCE_LANGS`,
        so both arms of `check-docs-section-name` pass over it. Fixing the YAML half alone would
        teach an anchor that vanishes from the merged output shown two paragraphs later.

      Why the population question is the real subject

      check-docs-section-name judges sections:sequences in both arms. This finding adds two
      more shapes that carry form sections and that neither arm reaches — a singular section:
      mapping, and a sections: array in a json fence — which is the same drift #10830 and #11887
      each closed one selector at a time. Deciding the gate's population means deciding which keys
      and which fence languages introduce a form section, together with how the os:check-yaml
      marker vocabulary is read. That is a triage call, not a dev call, and it is the one #13759
      deliberately deferred.

      Sites, for whoever picks this up:

      sitefenceshape
      content/docs/protocol/objectui/concept.mdx:426```yaml, untagged- section: under customizations:, label: Billing Info
      content/docs/protocol/objectui/concept.mdx:444```json, unjudged by both arms"label": "Contact Information"
      content/docs/protocol/objectui/concept.mdx:452```json, unjudged by both arms"label": "Billing Info"

      ⛔ Not a schema change either way: FormSectionSchema.name stays .optional() (#10709,
      reaffirmed #10830).

      Back-links: #13759, #11887, #10830, #10709

      Metadata

      Metadata

      Assignees

      Type

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions

        , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
        Skip to content

        [finding] The singular section: census is 4, not 3 — concept.mdx carries a 4th nameless one, plus two more in an unjudged JSON fence #13880

        Description

        @os-project-manager

        Found while implementing #13759 (the three singular section: sites in layout-dsl.mdx).
        Filed separately, not folded in: the triage ruling on #13759 fenced the population question
        out of that PR, and this finding is exactly that question wearing a concrete example.

        The measurement

        Re-running the #13759 census with the same yaml parser and the same classifyYamlFence
        the #11887 arm uses, on 8c6a7fc0b, over all of content/docs/**, with no marker filter:

        yaml fences scanned : 148 (judged 145, skipped 3 on a syntax error)
        singular `section:` mappings : 4
        NAMELESS content/docs/protocol/objectui/concept.mdx:426 label="Billing Info" keys=label|fields
        NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:235 label="Contact Information" keys=label|columns|fields
        NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:263 label="Product Details" keys=label|columns|fields
        NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:295 label=null keys=columns|fields
        

        The population is 4, not the 3 the #13759 card recorded. #13759 fixed its three; the
        concept.mdx one is untouched and still live.

        Why the card counted 3 — the census was scoped by MARKER, not by shape

        Not drift, and not a fourth that appeared since: - section: is present at concept.mdx:425
        in af01080e3 itself, the commit the card measured on. Two control runs separate the
        hypotheses:

        • re-running the census with the gate's own YAML_SECTIONS_KEY pre-filter
          (/(^|[^A-Za-z0-9_$.])sections\s*:/m) yields 0, not 3 — so the card did not use it;
        • grep for the marker yields exactly the card's 3:
          os:check-yaml FormSectionSchema key=section appears 3 times in content/docs/**, all in
          layout-dsl.mdx.

        So the card's population was "fences carrying the singular key=section marker", and it was
        reported as "the singular population across all of content/docs/**". concept.mdx carries
        no os:check-yaml markers at all (check:yaml-examples reports it as 0 tagged / 10 untagged), so it is invisible to that scoping.

        Why it is not a copy of the #13759 edit

        The concept.mdx site is a different enclosing shape and needs a decision #13759 did not take:

        customizations:
        - field: phonerequired: true
        - section: # <- the 4th nameless singular sectionlabel: Billing Infofields: [payment_terms, credit_limit]
        1. The enclosing shape has no schema. This is the page's "Layer 2: Admin Customization"
          example. A customizations:sequence of { field | section } overlay entries is
          declared nowhere in packages/spec — the only customizations in the authorable surface
          is tenant.zod.ts's z.record(z.string(), z.unknown()), a free-form record. Whether this
          fence teaches a real shape at all is the prior question; giving it a name polishes an
          example that may want removing or rewriting instead. Compare the steps: callout already
          on layout-dsl.mdx, which removed a phantom rather than repairing it.
        2. Its sibling fence is unjudged too, and is not YAML. The "Final Merged Layout" block
          directly below (concept.mdx:440) is a ```json fence carrying two more nameless
          sections ("label": "Contact Information", `"label": "Billing Info"`) inside a real
          `"sections": [ ... ]` array. `json` is in neither `TS_FENCE_LANGS` nor `YAML_FENCE_LANGS`,
          so both arms of `check-docs-section-name` pass over it. Fixing the YAML half alone would
          teach an anchor that vanishes from the merged output shown two paragraphs later.

        Why the population question is the real subject

        check-docs-section-name judges sections:sequences in both arms. This finding adds two
        more shapes that carry form sections and that neither arm reaches — a singular section:
        mapping, and a sections: array in a json fence — which is the same drift #10830 and #11887
        each closed one selector at a time. Deciding the gate's population means deciding which keys
        and which fence languages introduce a form section, together with how the os:check-yaml
        marker vocabulary is read. That is a triage call, not a dev call, and it is the one #13759
        deliberately deferred.

        Sites, for whoever picks this up:

        sitefenceshape
        content/docs/protocol/objectui/concept.mdx:426```yaml, untagged- section: under customizations:, label: Billing Info
        content/docs/protocol/objectui/concept.mdx:444```json, unjudged by both arms"label": "Contact Information"
        content/docs/protocol/objectui/concept.mdx:452```json, unjudged by both arms"label": "Billing Info"

        ⛔ Not a schema change either way: FormSectionSchema.name stays .optional() (#10709,
        reaffirmed #10830).

        Back-links: #13759, #11887, #10830, #10709

        Metadata

        Metadata

        Assignees

        Type

        Projects

        No projects

          Milestone

          No milestone

          Relationships

          None yet

          Development

          No branches or pull requests

          Issue actions

          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
          Skip to content

          [finding] The singular section: census is 4, not 3 — concept.mdx carries a 4th nameless one, plus two more in an unjudged JSON fence #13880

          Description

          @os-project-manager

          Found while implementing #13759 (the three singular section: sites in layout-dsl.mdx).
          Filed separately, not folded in: the triage ruling on #13759 fenced the population question
          out of that PR, and this finding is exactly that question wearing a concrete example.

          The measurement

          Re-running the #13759 census with the same yaml parser and the same classifyYamlFence
          the #11887 arm uses, on 8c6a7fc0b, over all of content/docs/**, with no marker filter:

          yaml fences scanned : 148 (judged 145, skipped 3 on a syntax error)
          singular `section:` mappings : 4
          NAMELESS content/docs/protocol/objectui/concept.mdx:426 label="Billing Info" keys=label|fields
          NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:235 label="Contact Information" keys=label|columns|fields
          NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:263 label="Product Details" keys=label|columns|fields
          NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:295 label=null keys=columns|fields
          

          The population is 4, not the 3 the #13759 card recorded. #13759 fixed its three; the
          concept.mdx one is untouched and still live.

          Why the card counted 3 — the census was scoped by MARKER, not by shape

          Not drift, and not a fourth that appeared since: - section: is present at concept.mdx:425
          in af01080e3 itself, the commit the card measured on. Two control runs separate the
          hypotheses:

          • re-running the census with the gate's own YAML_SECTIONS_KEY pre-filter
            (/(^|[^A-Za-z0-9_$.])sections\s*:/m) yields 0, not 3 — so the card did not use it;
          • grep for the marker yields exactly the card's 3:
            os:check-yaml FormSectionSchema key=section appears 3 times in content/docs/**, all in
            layout-dsl.mdx.

          So the card's population was "fences carrying the singular key=section marker", and it was
          reported as "the singular population across all of content/docs/**". concept.mdx carries
          no os:check-yaml markers at all (check:yaml-examples reports it as 0 tagged / 10 untagged), so it is invisible to that scoping.

          Why it is not a copy of the #13759 edit

          The concept.mdx site is a different enclosing shape and needs a decision #13759 did not take:

          customizations:
          - field: phonerequired: true
          - section: # <- the 4th nameless singular sectionlabel: Billing Infofields: [payment_terms, credit_limit]
          1. The enclosing shape has no schema. This is the page's "Layer 2: Admin Customization"
            example. A customizations:sequence of { field | section } overlay entries is
            declared nowhere in packages/spec — the only customizations in the authorable surface
            is tenant.zod.ts's z.record(z.string(), z.unknown()), a free-form record. Whether this
            fence teaches a real shape at all is the prior question; giving it a name polishes an
            example that may want removing or rewriting instead. Compare the steps: callout already
            on layout-dsl.mdx, which removed a phantom rather than repairing it.
          2. Its sibling fence is unjudged too, and is not YAML. The "Final Merged Layout" block
            directly below (concept.mdx:440) is a ```json fence carrying two more nameless
            sections ("label": "Contact Information", `"label": "Billing Info"`) inside a real
            `"sections": [ ... ]` array. `json` is in neither `TS_FENCE_LANGS` nor `YAML_FENCE_LANGS`,
            so both arms of `check-docs-section-name` pass over it. Fixing the YAML half alone would
            teach an anchor that vanishes from the merged output shown two paragraphs later.

          Why the population question is the real subject

          check-docs-section-name judges sections:sequences in both arms. This finding adds two
          more shapes that carry form sections and that neither arm reaches — a singular section:
          mapping, and a sections: array in a json fence — which is the same drift #10830 and #11887
          each closed one selector at a time. Deciding the gate's population means deciding which keys
          and which fence languages introduce a form section, together with how the os:check-yaml
          marker vocabulary is read. That is a triage call, not a dev call, and it is the one #13759
          deliberately deferred.

          Sites, for whoever picks this up:

          sitefenceshape
          content/docs/protocol/objectui/concept.mdx:426```yaml, untagged- section: under customizations:, label: Billing Info
          content/docs/protocol/objectui/concept.mdx:444```json, unjudged by both arms"label": "Contact Information"
          content/docs/protocol/objectui/concept.mdx:452```json, unjudged by both arms"label": "Billing Info"

          ⛔ Not a schema change either way: FormSectionSchema.name stays .optional() (#10709,
          reaffirmed #10830).

          Back-links: #13759, #11887, #10830, #10709

          Metadata

          Metadata

          Assignees

          Type

          Projects

          No projects

            Milestone

            No milestone

            Relationships

            None yet

            Development

            No branches or pull requests

            Issue actions

            , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
            Skip to content

            [finding] The singular section: census is 4, not 3 — concept.mdx carries a 4th nameless one, plus two more in an unjudged JSON fence #13880

            Description

            @os-project-manager

            Found while implementing #13759 (the three singular section: sites in layout-dsl.mdx).
            Filed separately, not folded in: the triage ruling on #13759 fenced the population question
            out of that PR, and this finding is exactly that question wearing a concrete example.

            The measurement

            Re-running the #13759 census with the same yaml parser and the same classifyYamlFence
            the #11887 arm uses, on 8c6a7fc0b, over all of content/docs/**, with no marker filter:

            yaml fences scanned : 148 (judged 145, skipped 3 on a syntax error)
            singular `section:` mappings : 4
            NAMELESS content/docs/protocol/objectui/concept.mdx:426 label="Billing Info" keys=label|fields
            NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:235 label="Contact Information" keys=label|columns|fields
            NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:263 label="Product Details" keys=label|columns|fields
            NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:295 label=null keys=columns|fields
            

            The population is 4, not the 3 the #13759 card recorded. #13759 fixed its three; the
            concept.mdx one is untouched and still live.

            Why the card counted 3 — the census was scoped by MARKER, not by shape

            Not drift, and not a fourth that appeared since: - section: is present at concept.mdx:425
            in af01080e3 itself, the commit the card measured on. Two control runs separate the
            hypotheses:

            • re-running the census with the gate's own YAML_SECTIONS_KEY pre-filter
              (/(^|[^A-Za-z0-9_$.])sections\s*:/m) yields 0, not 3 — so the card did not use it;
            • grep for the marker yields exactly the card's 3:
              os:check-yaml FormSectionSchema key=section appears 3 times in content/docs/**, all in
              layout-dsl.mdx.

            So the card's population was "fences carrying the singular key=section marker", and it was
            reported as "the singular population across all of content/docs/**". concept.mdx carries
            no os:check-yaml markers at all (check:yaml-examples reports it as 0 tagged / 10 untagged), so it is invisible to that scoping.

            Why it is not a copy of the #13759 edit

            The concept.mdx site is a different enclosing shape and needs a decision #13759 did not take:

            customizations:
            - field: phonerequired: true
            - section: # <- the 4th nameless singular sectionlabel: Billing Infofields: [payment_terms, credit_limit]
            1. The enclosing shape has no schema. This is the page's "Layer 2: Admin Customization"
              example. A customizations:sequence of { field | section } overlay entries is
              declared nowhere in packages/spec — the only customizations in the authorable surface
              is tenant.zod.ts's z.record(z.string(), z.unknown()), a free-form record. Whether this
              fence teaches a real shape at all is the prior question; giving it a name polishes an
              example that may want removing or rewriting instead. Compare the steps: callout already
              on layout-dsl.mdx, which removed a phantom rather than repairing it.
            2. Its sibling fence is unjudged too, and is not YAML. The "Final Merged Layout" block
              directly below (concept.mdx:440) is a ```json fence carrying two more nameless
              sections ("label": "Contact Information", `"label": "Billing Info"`) inside a real
              `"sections": [ ... ]` array. `json` is in neither `TS_FENCE_LANGS` nor `YAML_FENCE_LANGS`,
              so both arms of `check-docs-section-name` pass over it. Fixing the YAML half alone would
              teach an anchor that vanishes from the merged output shown two paragraphs later.

            Why the population question is the real subject

            check-docs-section-name judges sections:sequences in both arms. This finding adds two
            more shapes that carry form sections and that neither arm reaches — a singular section:
            mapping, and a sections: array in a json fence — which is the same drift #10830 and #11887
            each closed one selector at a time. Deciding the gate's population means deciding which keys
            and which fence languages introduce a form section, together with how the os:check-yaml
            marker vocabulary is read. That is a triage call, not a dev call, and it is the one #13759
            deliberately deferred.

            Sites, for whoever picks this up:

            sitefenceshape
            content/docs/protocol/objectui/concept.mdx:426```yaml, untagged- section: under customizations:, label: Billing Info
            content/docs/protocol/objectui/concept.mdx:444```json, unjudged by both arms"label": "Contact Information"
            content/docs/protocol/objectui/concept.mdx:452```json, unjudged by both arms"label": "Billing Info"

            ⛔ Not a schema change either way: FormSectionSchema.name stays .optional() (#10709,
            reaffirmed #10830).

            Back-links: #13759, #11887, #10830, #10709

            Metadata

            Metadata

            Assignees

            Type

            Projects

            No projects

              Milestone

              No milestone

              Relationships

              None yet

              Development

              No branches or pull requests

              Issue actions

              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
              Skip to content

              [finding] The singular section: census is 4, not 3 — concept.mdx carries a 4th nameless one, plus two more in an unjudged JSON fence #13880

              Description

              @os-project-manager

              Found while implementing #13759 (the three singular section: sites in layout-dsl.mdx).
              Filed separately, not folded in: the triage ruling on #13759 fenced the population question
              out of that PR, and this finding is exactly that question wearing a concrete example.

              The measurement

              Re-running the #13759 census with the same yaml parser and the same classifyYamlFence
              the #11887 arm uses, on 8c6a7fc0b, over all of content/docs/**, with no marker filter:

              yaml fences scanned : 148 (judged 145, skipped 3 on a syntax error)
              singular `section:` mappings : 4
              NAMELESS content/docs/protocol/objectui/concept.mdx:426 label="Billing Info" keys=label|fields
              NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:235 label="Contact Information" keys=label|columns|fields
              NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:263 label="Product Details" keys=label|columns|fields
              NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:295 label=null keys=columns|fields
              

              The population is 4, not the 3 the #13759 card recorded. #13759 fixed its three; the
              concept.mdx one is untouched and still live.

              Why the card counted 3 — the census was scoped by MARKER, not by shape

              Not drift, and not a fourth that appeared since: - section: is present at concept.mdx:425
              in af01080e3 itself, the commit the card measured on. Two control runs separate the
              hypotheses:

              • re-running the census with the gate's own YAML_SECTIONS_KEY pre-filter
                (/(^|[^A-Za-z0-9_$.])sections\s*:/m) yields 0, not 3 — so the card did not use it;
              • grep for the marker yields exactly the card's 3:
                os:check-yaml FormSectionSchema key=section appears 3 times in content/docs/**, all in
                layout-dsl.mdx.

              So the card's population was "fences carrying the singular key=section marker", and it was
              reported as "the singular population across all of content/docs/**". concept.mdx carries
              no os:check-yaml markers at all (check:yaml-examples reports it as 0 tagged / 10 untagged), so it is invisible to that scoping.

              Why it is not a copy of the #13759 edit

              The concept.mdx site is a different enclosing shape and needs a decision #13759 did not take:

              customizations:
              - field: phonerequired: true
              - section: # <- the 4th nameless singular sectionlabel: Billing Infofields: [payment_terms, credit_limit]
              1. The enclosing shape has no schema. This is the page's "Layer 2: Admin Customization"
                example. A customizations:sequence of { field | section } overlay entries is
                declared nowhere in packages/spec — the only customizations in the authorable surface
                is tenant.zod.ts's z.record(z.string(), z.unknown()), a free-form record. Whether this
                fence teaches a real shape at all is the prior question; giving it a name polishes an
                example that may want removing or rewriting instead. Compare the steps: callout already
                on layout-dsl.mdx, which removed a phantom rather than repairing it.
              2. Its sibling fence is unjudged too, and is not YAML. The "Final Merged Layout" block
                directly below (concept.mdx:440) is a ```json fence carrying two more nameless
                sections ("label": "Contact Information", `"label": "Billing Info"`) inside a real
                `"sections": [ ... ]` array. `json` is in neither `TS_FENCE_LANGS` nor `YAML_FENCE_LANGS`,
                so both arms of `check-docs-section-name` pass over it. Fixing the YAML half alone would
                teach an anchor that vanishes from the merged output shown two paragraphs later.

              Why the population question is the real subject

              check-docs-section-name judges sections:sequences in both arms. This finding adds two
              more shapes that carry form sections and that neither arm reaches — a singular section:
              mapping, and a sections: array in a json fence — which is the same drift #10830 and #11887
              each closed one selector at a time. Deciding the gate's population means deciding which keys
              and which fence languages introduce a form section, together with how the os:check-yaml
              marker vocabulary is read. That is a triage call, not a dev call, and it is the one #13759
              deliberately deferred.

              Sites, for whoever picks this up:

              sitefenceshape
              content/docs/protocol/objectui/concept.mdx:426```yaml, untagged- section: under customizations:, label: Billing Info
              content/docs/protocol/objectui/concept.mdx:444```json, unjudged by both arms"label": "Contact Information"
              content/docs/protocol/objectui/concept.mdx:452```json, unjudged by both arms"label": "Billing Info"

              ⛔ Not a schema change either way: FormSectionSchema.name stays .optional() (#10709,
              reaffirmed #10830).

              Back-links: #13759, #11887, #10830, #10709

              Metadata

              Metadata

              Assignees

              Type

              Projects

              No projects

                Milestone

                No milestone

                Relationships

                None yet

                Development

                No branches or pull requests

                Issue actions

                , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
                Skip to content

                [finding] The singular section: census is 4, not 3 — concept.mdx carries a 4th nameless one, plus two more in an unjudged JSON fence #13880

                Description

                @os-project-manager

                Found while implementing #13759 (the three singular section: sites in layout-dsl.mdx).
                Filed separately, not folded in: the triage ruling on #13759 fenced the population question
                out of that PR, and this finding is exactly that question wearing a concrete example.

                The measurement

                Re-running the #13759 census with the same yaml parser and the same classifyYamlFence
                the #11887 arm uses, on 8c6a7fc0b, over all of content/docs/**, with no marker filter:

                yaml fences scanned : 148 (judged 145, skipped 3 on a syntax error)
                singular `section:` mappings : 4
                NAMELESS content/docs/protocol/objectui/concept.mdx:426 label="Billing Info" keys=label|fields
                NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:235 label="Contact Information" keys=label|columns|fields
                NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:263 label="Product Details" keys=label|columns|fields
                NAMELESS content/docs/protocol/objectui/layout-dsl.mdx:295 label=null keys=columns|fields
                

                The population is 4, not the 3 the #13759 card recorded. #13759 fixed its three; the
                concept.mdx one is untouched and still live.

                Why the card counted 3 — the census was scoped by MARKER, not by shape

                Not drift, and not a fourth that appeared since: - section: is present at concept.mdx:425
                in af01080e3 itself, the commit the card measured on. Two control runs separate the
                hypotheses:

                • re-running the census with the gate's own YAML_SECTIONS_KEY pre-filter
                  (/(^|[^A-Za-z0-9_$.])sections\s*:/m) yields 0, not 3 — so the card did not use it;
                • grep for the marker yields exactly the card's 3:
                  os:check-yaml FormSectionSchema key=section appears 3 times in content/docs/**, all in
                  layout-dsl.mdx.

                So the card's population was "fences carrying the singular key=section marker", and it was
                reported as "the singular population across all of content/docs/**". concept.mdx carries
                no os:check-yaml markers at all (check:yaml-examples reports it as 0 tagged / 10 untagged), so it is invisible to that scoping.

                Why it is not a copy of the #13759 edit

                The concept.mdx site is a different enclosing shape and needs a decision #13759 did not take:

                customizations:
                - field: phonerequired: true
                - section: # <- the 4th nameless singular sectionlabel: Billing Infofields: [payment_terms, credit_limit]
                1. The enclosing shape has no schema. This is the page's "Layer 2: Admin Customization"
                  example. A customizations:sequence of { field | section } overlay entries is
                  declared nowhere in packages/spec — the only customizations in the authorable surface
                  is tenant.zod.ts's z.record(z.string(), z.unknown()), a free-form record. Whether this
                  fence teaches a real shape at all is the prior question; giving it a name polishes an
                  example that may want removing or rewriting instead. Compare the steps: callout already
                  on layout-dsl.mdx, which removed a phantom rather than repairing it.
                2. Its sibling fence is unjudged too, and is not YAML. The "Final Merged Layout" block
                  directly below (concept.mdx:440) is a ```json fence carrying two more nameless
                  sections ("label": "Contact Information", `"label": "Billing Info"`) inside a real
                  `"sections": [ ... ]` array. `json` is in neither `TS_FENCE_LANGS` nor `YAML_FENCE_LANGS`,
                  so both arms of `check-docs-section-name` pass over it. Fixing the YAML half alone would
                  teach an anchor that vanishes from the merged output shown two paragraphs later.

                Why the population question is the real subject

                check-docs-section-name judges sections:sequences in both arms. This finding adds two
                more shapes that carry form sections and that neither arm reaches — a singular section:
                mapping, and a sections: array in a json fence — which is the same drift #10830 and #11887
                each closed one selector at a time. Deciding the gate's population means deciding which keys
                and which fence languages introduce a form section, together with how the os:check-yaml
                marker vocabulary is read. That is a triage call, not a dev call, and it is the one #13759
                deliberately deferred.

                Sites, for whoever picks this up:

                sitefenceshape
                content/docs/protocol/objectui/concept.mdx:426```yaml, untagged- section: under customizations:, label: Billing Info
                content/docs/protocol/objectui/concept.mdx:444```json, unjudged by both arms"label": "Contact Information"
                content/docs/protocol/objectui/concept.mdx:452```json, unjudged by both arms"label": "Billing Info"

                ⛔ Not a schema change either way: FormSectionSchema.name stays .optional() (#10709,
                reaffirmed #10830).

                Back-links: #13759, #11887, #10830, #10709

                Metadata

                Metadata

                Assignees

                Type

                Projects

                No projects

                  Milestone

                  No milestone

                  Relationships

                  None yet

                  Development

                  No branches or pull requests

                  Issue actions