karvey-requirementslisted

# Karvey Requirements ## Purpose Generate requirements in EARS format for the change, produce the spec-delta with ADDED/MODIFIED/REMOVED operations, and register the Features in the team's tracker (`../karvey/rules/management-adapters.md`) or PLAN.md. ## Execution steps ### Step 1 — Load context Enter the phase through the state tool (refused, with the reason, if init is not done): ```bash python3 "${CLAUDE_PLUGIN_ROOT}/scripts/karvey-state.py" advance "{change-id}" requirements ``` Read: - `docs/spec/changes/{change-id}/spec.json` - `docs/spec/changes/{change-id}/prd.md` (PRD generated in karvey-init) - `docs/spec/specs/{capability}/spec.md` (current living spec) - `../karvey/rules/ears-format.md` - `../karvey/rules/living-specs.md` - `../karvey/rules/security-tiers.md` The requirements must derive from the PRD and cover its objectives and acceptance criteria. **Multi-agent / multi-repo context** (see `../karvey/rules/multi-agent.md`): - If `links.parent` is set, also read the **parent change's** `prd.md` and acceptance criteria in its repo: this child's requirements trace to the parent PRD. - For each `decisions` entry (`D-NN@{repo}`), read the decision in the operations repo's decision log. - For each `inputs.*` entry (`design`, `design_system`, `copy`, `legal`), read the file **at the pinned commit** (`git -C {repo} show {commit}:{path}`), not the working copy. If an input the requirements need is missing or unpinned, ask for it — never assume "the latest version"