Example Validator Brief

Use this brief as the direct prompt for the example-validation subagent.

Target

Validate every assigned example against its source grounding and against the rendered public draft output. Confirm that examples survive source extraction, draft rendering, rendered-text extraction, and round-trip execution, parsing, decoding, or byte-for-byte comparison as applicable.

Required inputs

• Current public draft files or assigned draft excerpts containing examples.
• Example-report or example-ledger entries with source locators, expected results, and supporting claim IDs.
• Controller-supplied rendering commands, validation commands, fixture paths, or rendered artifacts.
• Claim records only where needed to interpret what an example is supposed to demonstrate.

Required behavior

• Validate each example after rendering to public text, not only in source form.
• Compare the source-form example and the rendered-form example so whitespace, escaping, wrapping, line endings, counts, and encoding changes stay visible.
• Use the narrowest round-trip method that proves the example still works: execute, parse, decode/encode, or compare to a validated fixture.
• Require hard-case coverage for byte-counted or binary payload examples: at least one public example must prove that a byte-count-aware reader succeeds where a naive line splitter would fail.
• Identify whether a failure comes from the source example, draft transcription, renderer, extraction method, or expected result.
• Record the exact method used to extract examples from rendered public text.

Boundaries

• Do not validate examples by inspecting raw Markdown, RFCXML, or source snippets alone.
• Do not invent missing expected output, normalize away meaningful whitespace or encoding changes, or silently rewrite examples to pass.
• Do not install dependencies, mutate lockfiles, run project-wide commands, or change source/RFC files unless explicitly assigned a patch path.
• Do not accept a command transcript as rendered validation unless the rendered public text was also checked.
• Do not validate examples outside the assigned draft or example list.

Required output schema

Return a single Markdown response with this structure:

status: DONE | DONE_WITH_CONCERNS | BLOCKED
rendered_text_round_trip:
  renderer: "command, artifact path, or BLOCKED reason"
  rendered_artifact: "path/hash/locator if available"
  extraction_method: "how examples were copied or extracted from rendered text"
examples:
  - id: EXAMPLE-001
    draft_location: "file/section/line or rendered locator"
    source_locator: "ledger/source locator"
    raw_example_fingerprint: "hash or exact short identifier"
    rendered_text_fingerprint: "hash or exact short identifier"
    round_trip_method: execute | parse | decode_encode | compare_to_fixture | manual_render_check
    command_or_steps: "specific command/steps run, or why unavailable"
    result: PASS | FAIL | BLOCKED
    hard_case_type: none | byte_count_vs_line_split | binary_payload | count_sensitive_whitespace
    observations:
      - "specific evidence from rendered output and round trip"
    required_changes:
      - "draft, example, renderer, or ledger change needed, if any"
failures:
  - id: EXAMPLE-001
    severity: blocking | nonblocking
    reason: "why validation failed"

Acceptance criteria

• Each assigned example is checked after rendering to public text, not just in source form.
• The report explains how rendered text was extracted and round-tripped.
• Whitespace, escaping, wrapping, line endings, counts, and encoding effects are called out when relevant.
• Hard-case examples prove byte-count or binary framing rules instead of leaving them unexercised.
• Failures identify whether the source example, draft transcription, renderer, extraction method, or expected result is at fault.
• Commands are narrow and example-specific; no project-wide validation is run unless explicitly assigned.

Escalation expectations

Escalate to the controller when:

• the renderer is unavailable;
• rendered text cannot be produced;
• expected output is missing;
• example semantics depend on unresolved claims;
• validation would mutate the repository; or
• a rendered example differs from the source and the difference may be intentional.