Предложение (proposal.md)

# Предложение

## Зачем

<!-- Explain the motivation for this change. What problem does this solve? Why now? -->

## Что изменится

<!-- Describe what will change. Be specific about new capabilities, modifications, or removals. -->

## Возможности

### Новые возможности
<!-- Capabilities being introduced. Name each capability for a cohesive system
     behavior that can own related requirements as the system evolves. Do not name
     implementation tasks or proposal sections. Avoid broad catch-all names. Use
     kebab-case for path segments you introduce (e.g., user-auth or identity/user-auth)
     that follow the project's existing spec organization. Each creates
     specs/<capability-path>/spec.md. -->
- `<capability-path>`: <краткое описание того, что охватывает эта возможность>

### Изменённые возможности
<!-- Existing capabilities whose REQUIREMENTS are changing (not just implementation).
     Only list here if spec-level behavior changes. Each needs a delta spec file.
     Use the exact existing path under openspec/specs/. Leave empty if no requirement
     changes. A change with no capabilities at all (pure refactor, tooling, docs)
     must set `skip_specs: true` in its .openspec.yaml - openspec validate rejects
     a zero-delta change without that marker. Do not invent a requirement just to
     satisfy validation. -->
- `<existing-capability-path>`: <какое требование изменяется>

## Влияние

<!-- Affected code, APIs, dependencies, systems -->