# 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.
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 `<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

```text
<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="full_test.sh">
#!/bin/sh
# full_test.sh — scoring entry point. Do not filter, skip, or reinterpret.
#
# `drydock uat` runs `sh sources/full_test.sh` from the completed application root and takes its
# exit code and output as the score. The interface check is separate from the conformance run so
# that a missing or non-executable program and a genuine conformance failure are distinguishable
# in the evidence. The program path is the harness's only knowledge of the implementation
# language; the harness itself is language-neutral.
#
# The suite runs unfiltered: no --pattern, no --number, no selector of any kind. spec_tests.py
# exits with failed + errored, so exit 0 means the complete CommonMark 0.31.2 suite passed.
set -eu

if [ ! -x ./commonmark ]; then
    echo "error: no executable ./commonmark at the application root." >&2
    echo "The deliverable is an executable named commonmark that reads UTF-8 Markdown on stdin" >&2
    echo "and writes HTML to stdout." >&2
    exit 1
fi

# spec_tests.py imports cmark and normalize as siblings, so the staged directory has to be on the
# import path. The program is passed absolute because the runner spawns it from its own cwd.
PYTHONPATH="$PWD/sources${PYTHONPATH:+:$PYTHONPATH}"
export PYTHONPATH

set +e
output=$(python3 sources/spec_tests.py --program "$PWD/commonmark" --spec sources/spec.txt 2>&1)
status=$?
set -e

printf '%s\n' "$output"

# The runner exits with failed + errored, which a shell truncates modulo 256: exactly 256 or 512
# failures would exit 0 and read as a pass. The harness therefore confirms the tally rather than
# trusting the status alone, and reports a clean run only when both agree. This is the scoring
# instrument reading its own instrument; the acceptance check above it still asserts nothing but
# this script's exit code.
if [ "$status" -ne 0 ]; then
    exit 1
fi
if ! printf '%s\n' "$output" | grep -q '0 failed, 0 errored, 0 skipped'; then
    echo "error: conformance runner exited 0 but did not report a clean unfiltered suite." >&2
    exit 1
fi
</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>