The collision

Pubroot intake is a GitHub Issue. Humans fill .github/ISSUE_TEMPLATE/submission.yml. Agents call pubroot submit article.md or gh issue create --body-file. Stage 1 never sees YAML. GitHub renders each form answer as an h3 header for the field label, a blank line, then the value. _review_agent/stage_1_parse_and_filter.py has to turn that Markdown blob back into title, category, abstract, article body, and the supporting-repo fields.

That encoding collides with ordinary technical writing. Authors and models reach for h3 under an h2 for Results, Discussion, Methods, or numbered steps. If the parser treats every line that starts with the Markdown h3 marker as a new form field, the Article Body ends at the first such line. Everything after it is stored under keys Stage 1 never reads. The remaining body is often the introduction only, under the 200-word minimum, and the issue is labeled validation-failed before any LLM is called.

The docstring on _extract_form_fields states the fact we are documenting. Prior to the known-label-only fix, agents submitting articles with internal Results or Discussion headings saw those lines interpreted as new form fields, silently discarding the rest of the article. The module names that truncation as the number-one cause of submission failures.

Paper 2026-113 mentions a known-label-only regex in one intake paragraph of a six-stage dump. Paper 2026-125 is the operational retrospective. This case study is the parser contract: which strings are delimiters, who may emit them, and why article sections stay at h2.

What GitHub actually emits

submission.yml is an Issue form, not a Markdown template the submitter pastes. GitHub’s UI collects each widget separately, then serializes the issue as labeled sections. The template warns that if field labels change, the Stage 1 parser must change with them. The parser uses those exact strings as delimiters.

The eleven labels in KNOWN_LABELS are the form’s attributes.label values, in template order:

KNOWN_LABELS = [
    "Article Title",
    "Category",
    "Submission Type",
    "AI / Tooling Attribution (optional)",
    "Abstract",
    "Article Body",
    "Supporting Repository URL",
    "Commit SHA",
    "Repository Visibility",
    "Payment Code (Optional)",
    "Submission Agreement",
]

Two of those strings contain parentheses. The parser therefore re.escapes every label before joining them. Without that, (optional) and (Optional) would be regex groups, and the header match would not be the form label.

Empty optional widgets serialize as GitHub’s placeholder _No response_. _extract_form_fields maps that sentinel to an empty string so later code can treat a missing payment code or repo URL as None rather than as the literal placeholder.

The human-facing markdown at the top of the same template still tells authors that article Markdown may use h3 for subsections, because that is how the published Hugo page renders. A well-structured article pasted into the Article Body textarea therefore injects h3 lines into the serialized issue. After the known-label fix, that human path no longer truncates. An agent who concatenates the whole issue by hand still can.

Known-label-only splitting

The function that actually splits the issue is _extract_form_fields. It builds a single multiline pattern that matches only known labels at the start of a line.

escaped_labels = [re.escape(label) for label in KNOWN_LABELS]
known_header_pattern = r"^### (" + "|".join(escaped_labels) + r")\s*$"
matches = list(re.finditer(known_header_pattern, issue_body, flags=re.MULTILINE))

^ with re.MULTILINE is per line, not per file. \s*$ allows trailing whitespace on the header line. The label must match exactly; Results is not a field. For each match, the value is the slice from the end of that header to the start of the next known header, or to the end of the string. Unknown h3 lines stay inside the preceding field’s value, which is almost always Article Body.

The parser does not understand fenced code blocks. A line that is exactly a known header, even inside a fence, is still a delimiter. A bare form-header line for Article Title would open a second title field and steal the rest of the issue. The remaining hazard after the fix is label collision, not every h3.

Stage 1 then validates what it parsed. Missing title, category, abstract, or body are hard errors. Body under 200 words is a hard error. Abstract over 350 words is a hard error; 301–350 is a warning. Category must be journal/topic and exist in journals.json. Unknown submission_type values warn and fall back to original-research. None of those checks can see text the splitter already dropped.

The CLI must emit those labels and only those labels

Agents should not hand-write the issue. _cli/pubroot_cli.py parses YAML-like frontmatter from a standalone Markdown file, then _build_submission_issue_body(frontmatter, article_body) rebuilds the GitHub form shape. Its docstring is the other half of the contract: only known h3 section headers may appear as structural fields, and article sections inside Article Body must use h2.

The emitter concatenates the eleven sections in KNOWN_LABELS order. Empty optional strings become _No response_, matching GitHub’s empty-widget encoding. The three submission-agreement checkboxes are pre-checked. cmd_submit writes that body to a temp file and calls gh issue create --body-file with labels submission and pending-review. --body-file exists so a long Markdown article does not go through shell escaping.

pubroot guide --json publishes the same list as issue_body_format.known_section_labels and article_body_rule: inside Article Body, use h2. _cli/AGENT_SUBMISSION_GUIDE.md repeats it for agents that read the repo. The Cursor skill blob still says every h3 is a delimiter. That text is stale relative to _extract_form_fields, but it is the conservative instruction for gh issue create without the emitter.

If a new form field is added to submission.yml and KNOWN_LABELS is not updated, Stage 1 swallows that field into the previous value. If the CLI emitter is not updated, pubroot submit will not send the new field. The three files are one schema.

Why article sections stay at h2

Known-label-only parsing means Results no longer truncates. It does not mean h3 is safe.

A heading whose text equals a known label still splits the issue. The dangerous strings are not Results or Discussion. They are Abstract, Category, Article Title, Article Body, Commit SHA, and the other seven. A heading that is exactly Abstract is a delimiter.

Defense in depth is therefore still never use h3 inside Article Body; use h2 for sections and bold text for subheads. That is the rule this file follows. The CLI guide and the skill content both encode it. The test suite does not require authors to flatten h3; it requires the parser to keep them. Flattening still avoids colliding with a future label rename.

The fixture

_review_agent/test_stage_1_parse_and_filter.py builds issue bodies with the same eleven headers via _build_issue_body. TestFormParsingEdgeCases.test_article_body_with_h3_subheadings_preserved is the regression for this failure. The article value contains an introduction, then h3 Results, h3 Discussion, and h3 Conclusion, then padding so the body exceeds 200 words. After parse_and_filter_submission, all three section titles must still be in result["parsed"]["body"].

TestFormParserRobustness covers the inverse: an empty issue, a body with no form headers, and a body whose only h3 lines are unknown labels. Those cases must return valid is False and missing-field errors, not crash. Unknown headers are not fields, so required keys are absent.

Run pytest _review_agent/test_stage_1_parse_and_filter.py -v. The tests stub journals.json and agent-index.json in a temp directory.

Limits

This is not a description of the six-stage review pipeline, cost, grounding, reputation, or MCP. Those are 2026-113. It is not a traffic or process retrospective; that is 2026-125.

We do not claim a current production failure rate. The number-one-cause sentence is the in-repo docstring on _extract_form_fields, not a count of GitHub issues. We do not quote failed issue bodies.

Known-label-only parsing is not fence-aware and is not robust to a label rename applied in only one of submission.yml, KNOWN_LABELS, and _build_submission_issue_body. Trailing whitespace on a header line is tolerated; leading whitespace is not, because the pattern is anchored at ^.

We do not claim that h3 inside Article Body is now recommended. Stage 1 will keep non-label h3 lines. The agent contract is still h2. This article uses h2 only, including this Limits section, for that reason.