# 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="stage_test.sh">
#!/bin/sh
# stage_test.sh — governed stage gate. Runs one slice of the authoritative suite.
#
# Same contract as full_test.sh, scoped to the cases a single story owns: build the decoder,
# then run the installed toml-test suite over the pattern given as $1. Exit status is the
# verdict and the whole verdict. Do not filter, skip, or reinterpret.
set -eu
if [ $# -ne 1 ]; then
  echo "usage: stage_test.sh <toml-test -run pattern>" >&2
  exit 2
fi
TOML_TEST_VERSION="${TOML_TEST_VERSION:-v2.2.0}"
export TOML_TEST_VERSION
go build -o toml-decoder ./cmd/toml-decoder
DECODER="$PWD/toml-decoder" exec sh sources/run_conformance.sh -run "$1"
</source>

<stories>
  <story id="architecture" implements="ARCHITECTURE.md">Define the Go parser modules, command boundary, tagged JSON contract, and standard-library constraints.</story>
  <story id="decoder-contract" implements="FEATURE-Decoder-Contract.md">Build the stdin-to-tagged-JSON decoder command.</story>
  <story id="decoder-invalid-input" implements="FEATURE-Decoder-Invalid-Input.md">Report invalid TOML through the decoder process boundary.</story>
  <story id="decoder-tagged-json" implements="FEATURE-Tagged-JSON.md">Encode parsed TOML values using the required tagged JSON representation.</story>
  <story id="lexical-strings" implements="FEATURE-Lexical-Strings.md">Parse TOML basic, multiline basic, literal, and multiline literal strings.</story>
  <story id="lexical-numbers" implements="FEATURE-Lexical-Numbers.md">Parse TOML integers, floating-point values, special floats, and booleans.</story>
  <story id="lexical-datetime" implements="FEATURE-Lexical-Datetime.md">Parse offset datetime, local datetime, local date, and local time values.</story>
  <story id="lexical-whitespace-comments" implements="FEATURE-Lexical-Whitespace-Comments.md">Process TOML whitespace, comments, line endings, continuations, and encoding rules.</story>
  <story id="keys-forms" implements="FEATURE-Key-Forms.md">Parse bare, quoted, and dotted TOML keys.</story>
  <story id="structures-arrays" implements="FEATURE-Arrays.md">Parse TOML arrays and nested array values.</story>
  <story id="keys-semantics" implements="FEATURE-Key-Semantics.md">Enforce TOML key uniqueness and scalar-to-table definition rules.</story>
  <story id="structures-inline-tables" implements="FEATURE-Inline-Tables.md">Parse TOML inline tables and nested inline-table keys.</story>
  <story id="structures-inline-table-closure" implements="FEATURE-Inline-Table-Closure.md">Enforce closure of TOML inline tables.</story>
  <story id="tables-standard" implements="FEATURE-Standard-Tables.md">Parse standard TOML table headers and implicit tables.</story>
  <story id="tables-redefinition" implements="FEATURE-Table-Redefinition.md">Enforce standard-table redefinition and structure-conflict rules.</story>
  <story id="tables-arrays" implements="FEATURE-Arrays-of-Tables.md">Parse arrays of TOML tables and nested table elements.</story>
  <story id="tables-arrays-ordering" implements="FEATURE-Arrays-of-Tables-Ordering.md">Enforce array-of-table ordering and conflict rules.</story>
  <story id="conformance" implements="FEATURE-Conformance.md">Run the complete pinned TOML 1.0.0 conformance suite.</story>
</stories>