spec-researchlisted

# OpenSpec Proposal Writing Guide for creating `proposal.md` -- the WHY document that anchors the entire workflow. ## Output Path Write to: `{specs_path}/proposal.md` **Path Enforcement**: The `specs_path` MUST be `.scaffolding/conversations/{UUID}/specs/` where `{UUID}` is a valid UUID (format: `xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`). NEVER use descriptive folder names. ## Required Sections | Section | Purpose | Content | |---------|---------|---------| | **Why** | Motivation | 1-2 sentences. What problem? Why now? | | **What Changes** | Scope | Bullet list. New capabilities, modifications, removals. Mark **BREAKING** | | **Capabilities** | Contract | New + modified capabilities (kebab-case names) | | **Impact** | Blast radius | Affected code, APIs, dependencies, systems | | **Agent Assignment** | Routing | Table of agents, roles, artifacts | | **Rollback Plan** | Safety | Revert points, manual steps, affected systems | ## Capabilities Section (Critical) This section creates the contract between proposal and design phases. ### New Capabilities - Use kebab-case: `user-auth`, `data-export`, `api-rate-limiting` - Each becomes a requirement group in design.md - Brief description of what the capability covers ### Modified Capabilities - Only list if spec-level REQUIREMENTS change (not just implementation) - Check `.scaffolding/openspec/specs/` for existing names - Leave empty if no requirement changes ## Quality Checklist - [ ] Goals are concrete and measurable (not v