# 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 ``. 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. 2. 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`. 3. 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. 4. List any story that implements no requirement in the source as ``. 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 ``. Never invent one. - Every story must appear exactly once, either inside a `stories` attribute or as ``. - 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 ```text The reader can add a book with a title and author, view the books in the order added, and remove a book. An empty title or author is rejected with a clear error message. ``` # Attribution job # Build Instructions: CommonMark Parser Build a CommonMark 0.31.2 parser from the supplied specification. Read Markdown from standard input and write HTML to standard output. Do not use a public Markdown implementation. The sole definition of product success is `sh full_test.sh` returning exit code `0`. `full_test.sh` runs the complete, unfiltered supplied CommonMark suite. Treat the suite runner's exit status as the verdict; do not parse or hardcode its printed tally. `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`, and `normalize.py`. ## 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. 2. 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 Do not create acceptance checks asserting that imported or staged files merely exist. Do not create a scoped check by invoking `full_test.sh`; it is intentionally full-suite only. Parser implementation stories may run the supplied harness with explicit section selectors that cover the whole story scope. A section selector must select examples. `spec.txt` nests example-bearing headings such as `ATX headings` and `List items` under chapter titles such as `Leaf blocks`, `Container blocks`, and `Characters and lines`; the chapter titles own no examples of their own, so a selector naming one matches nothing, exits zero, and proves nothing. Select on the headings that own examples, and cover a chapter by naming all of them. The final verification story depends on all parser stories, creates `full_test.sh`, and has exactly one terminal `Suite: full` acceptance check. The check prints captured standard output and standard error and asserts only `result.returncode == 0`. It carries `Sea Trials: st-001`. Do not add separate verification stories for script presence, focused verification, staged assets, or complete verification. Deliver a concise project `README.md` documenting the standard-input/standard-output interface and the `sh full_test.sh` command. Define parser architecture and module boundaries. Implement the standard-input and standard-output parser entry point. Define deterministic parser process errors and exit behavior. Document parser operation and conformance verification. Parse CommonMark leaf blocks. Parse nested block quotes and lazy continuation. Parse CommonMark list items and list structure. Parse escapes and character references. Parse code spans and line breaks. Parse emphasis and strong emphasis using delimiter rules. Parse links and images. Parse autolinks and raw HTML. Render parsed block structure as CommonMark HTML. Render parsed inline structure as CommonMark HTML. Normalize URL, title, attribute, and special-character output. Stage and exercise the supplied conformance harness within bounded story scopes. Run the complete supplied CommonMark conformance suite.