31 lines
1.3 KiB
Markdown
31 lines
1.3 KiB
Markdown
## Why
|
|
|
|
<!-- Explain the motivation for this change. What problem does this solve? Why now? -->
|
|
|
|
## What Changes
|
|
|
|
<!-- Describe the intended outcome and explicit non-goals without technologies,
|
|
APIs, files, dependencies or implementation decisions. -->
|
|
|
|
## Capabilities
|
|
|
|
### New Capabilities
|
|
<!-- Capabilities being introduced. 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>`: <brief description of what this capability covers>
|
|
|
|
### Modified Capabilities
|
|
<!-- 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>`: <what requirement is changing>
|
|
|
|
## Impact
|
|
|
|
<!-- Affected users, processes or system areas at scope level only. -->
|