capture-issuelisted

# Capture Issue Convert a newly reported or discovered problem, bug, or feature request into one canonical, implementation-ready GitHub Issue containing the SDD phases `Specify` and `Clarify`. ## Workflow 1. Read repository instructions, issue templates, label conventions, documentation, code, tests, and relevant history. 2. Search open issues and relevant closed issues before creating anything. 3. Decide whether to update an existing canonical issue, comment with missing evidence, create a new issue, or produce a ready-to-post draft when GitHub writes are unavailable. 4. For bugs, investigate enough to capture: - observed behavior - expected behavior - reproduction steps - affected environment - version, commit, or branch when relevant - severity and impact - concrete evidence - validation already attempted - known workaround - blockers or dependencies 5. Apply `grilling` directly for material unresolved decisions. Do not route through `grill`, because `grill` is a manual conversational wrapper and does not create work artifacts. 6. Route to `domain-model` when domain terminology, states, rules, entities, or relationships are materially ambiguous. 7. Route to `research` when current external evidence affects the requested behavior. 8. Create or update exactly one canonical issue. Label it following the repository's own convention, or [LABELS.md](LABELS.md) when it has none. Apply only clearly applicable values, and never invent one to fill a