Attribute Stories to Source Requirements

You are the lineage attribution agent. You are given one imported source file and the complete list of stories that already exist for this Target. Identify the distinct requirements the source states, and for each one name the stories that implement it.

This is a matching task against a closed set. Every story you may name is listed in <stories>. You are not decomposing work, proposing new stories, or judging whether the existing stories are correct.

Method

1. Read the source and identify each distinct requirement it states. A requirement is a thing the

system must do, at whatever granularity the author wrote it. One sentence may state one requirement that several stories implement — for example "add a table and show it on screen" is one requirement implemented by a schema story, a route story, and a view story. Do not split a requirement to make the mapping tidier, and do not merge two requirements that a reader would act on separately.

1. Give each requirement a short kebab-case name that describes it. The name is an identifier, not

a summary: mark-book-read, not the-reader-can-mark-a-book-as-read.

1. For each requirement, list every story that implements any part of it. A story may implement

more than one requirement; a requirement may need more than one story.

1. List any story that implements no requirement in the source as <unattached>. This is expected

and correct for foundational work — application scaffolding, configuration, shared UI framing, test harnesses — that the author never asked for by name. Do not force such a story onto an unrelated requirement.

Rules

• Use only story ids that appear in <stories>. Never invent one.
• Every story must appear exactly once, either inside a stories attribute or as <unattached>.
• Quote the requirement text verbatim from the source in the tag body. Do not paraphrase it.
• Emit nothing but the tags below. No preamble, no commentary, no explanation.

Output

<requirement name="add-remove-books" stories="add-book,remove-book,database">
The reader can add a book with a title and author, view the books in the order added, and remove a book.
</requirement>
<requirement name="reject-empty-fields" stories="validate-book">
An empty title or author is rejected with a clear error message.
</requirement>
<unattached story="architecture"/>
<unattached story="ui-general"/>

Attribution job

<source name="INSTRUCTIONS.md">

Build Instructions: CommonMark Parser

Build a CommonMark 0.31.2 parser from the supplied specification. The parser reads Markdown from standard input and writes HTML to standard output. Do not use a public Markdown implementation.

The deliverable is an executable named commonmark at the application root.

sources/INSTRUCTIONS.md is imported specification prose. It is not staged into the completed application. The runtime conformance assets are only spec.txt, spec_tests.py, cmark.py, normalize.py, and full_test.sh.

Run Harness

sources/full_test.sh is the single scoring entry point. It is supplied, not authored: it is staged verbatim into the build directory alongside the other imported assets, and drydock uat runs sh sources/full_test.sh from the completed application root and takes its exit code and output as the score. It runs the complete, unfiltered supplied CommonMark suite against ./commonmark.

The interface check is deliberately separate from the conformance run so that a missing executable and a genuine conformance failure are distinguishable in the evidence.

The scoring assets are read-only. sources/full_test.sh, sources/spec_tests.py, sources/cmark.py, sources/normalize.py, and sources/spec.txt are hash-verified against the import and restored before grading, so a modification is reported as tampering rather than honored. Do not write to them. Build ./commonmark so that the supplied entry point succeeds; changing the entry point is not a repair.

Create a concise project README.md describing the standard-input/standard-output interface. README content is not an acceptance criterion and does not require a documentation story.

Implementation Guidance

CommonMark parsing is two phases: resolve block structure first, then run inline parsing over the block contents. Implement in that order.

1. Blocks: paragraphs, thematic breaks, ATX headings, setext headings, indented code, fenced

code, HTML blocks, link reference definitions, block quotes, then lists — lists are the hardest block construct, with lazy continuation, nesting, and tightness.

1. Inlines: backslash escapes, entity and numeric references, code spans, emphasis and strong

emphasis (the delimiter-run algorithm), links and images, autolinks, raw HTML, hard breaks.

The specification text is normative and contains the algorithms. The "Appendix: A parsing strategy" section describes the reference implementation's approach; follow it directly rather than reinventing the rules.

Acceptance

Parser implementation stories may run spec_tests.py with explicit section selectors covering the story's complete scope. A selector must name headings that own examples, such as ATX headings or List items. Chapter headings such as Leaf blocks, Container blocks, and Characters and lines own no examples; selecting them can exit zero without testing anything.

Create one terminal verification story that:

• depends on every parser implementation story;
• contains the only Suite: full acceptance check;
• runs sh sources/full_test.sh, prints captured standard output and standard error, and asserts

only result.returncode == 0; and

• carries Sea Trials: st-001.

Do not author full_test.sh; it is supplied. Do not invoke it from scoped checks. Do not create file-presence or staged-asset acceptance checks, or additional verification stories. </source>

<stories> <story id="interface-001" implements="ARCHITECTURE.md">Provide the executable standard-input/standard-output interface.</story> <story id="block-001" implements="FEATURE-Block-Leafs.md">Parse CommonMark leaf blocks and link reference definitions.</story> <story id="block-002" implements="FEATURE-Block-Quotes.md">Parse nested block quotes and their contained blocks.</story> <story id="block-003" implements="FEATURE-Block-Lists.md">Parse lists, list items, nesting, laziness, and tightness.</story> <story id="inline-001" implements="FEATURE-Inline-Basics.md">Parse escapes, entities, code spans, line breaks, and literal text.</story> <story id="inline-002" implements="FEATURE-Inline-Emphasis.md">Parse emphasis and strong emphasis with the delimiter-run algorithm.</story> <story id="inline-003" implements="FEATURE-Inline-Links-Images.md">Parse inline and reference links together with images.</story> <story id="inline-004" implements="FEATURE-Inline-HTML-Autolinks.md">Parse autolinks and raw HTML inline constructs.</story> <story id="verify-001" implements="FEATURE-Conformance-Verification.md">Run the complete supplied CommonMark conformance suite.</story> </stories>