To spec

Take the current conversation context and codebase understanding and synthesize an implementation-ready specification. Do not interview the user or start a new discovery process. Reuse decisions, terminology, constraints, and answers that are already available.

Read CONTEXT.md, docs/glossary.md, relevant ADRs in docs/decisions/, and any grill notes or referenced material. Inspect the codebase when needed to accurately describe the current state.

Process

1. Explore the repository and relevant existing tests, if the current state has not already been established. Use glossary vocabulary and respect relevant ADRs.
2. Identify the highest useful testing seam for the feature. Prefer an existing seam over a new one, and prefer the highest seam that verifies external behavior. Aim for one seam where practical; propose new seams only when necessary.
3. Present the proposed testing seam briefly for user review before finalizing the spec. This is a focused design checkpoint, not a discovery interview.
4. Write the spec using the template below.
5. Publish the approved spec to the configured tracker. Apply the ready-for-agent label when the tracker supports labels. With local Markdown configured, save it to docs/specs/<feature-name>.md and mark its status ready-for-agent.

Problem Statement

Describe the problem from the user's perspective.

Solution