codex-bot
b9ec11f5ba
Replace executable schema checks with explicit review-driven readiness, add a requirement-writing profile, and incorporate review clarifications for source traceability and comparative validation.
49 lines
4.0 KiB
Markdown
49 lines
4.0 KiB
Markdown
<!--
|
||
Перед заполнением прочитай единый профиль:
|
||
openspec/schemas/wealth-ledger-sdd-lab/spec-writing.md.
|
||
Оставь только нужные этой дельте разделы; подсказки и образец не входят в результат.
|
||
Файл — specs/<capability-path>/spec.md с точным путём из Proposal.
|
||
|
||
Только новая capability: `## Purpose` в 1–2 предложения (от 50 символов).
|
||
Существующая capability: Purpose не добавляй.
|
||
|
||
Операции:
|
||
- `## ADDED Requirements` — новые полные блоки Requirement.
|
||
- `## MODIFIED Requirements` — полный существующий блок со всеми сохраняемыми
|
||
Scenario, затем изменённое поведение; heading совпадает точно.
|
||
- `## REMOVED Requirements` — heading Requirement плюс **Reason** и **Migration**.
|
||
- `## RENAMED Requirements` — только пары `FROM:` и `TO:`.
|
||
|
||
Каркас ADDED/MODIFIED: устойчивое имя → субъект SHALL <наблюдаемый результат>
|
||
с явным условием, если оно нужно → определения/таблица → Scenarios.
|
||
SHALL NOT — запрет; существующие MUST/MUST NOT равнозначны. Один Requirement —
|
||
одно независимо принимаемое обязательство, не подсчёт предложений или SHALL.
|
||
Сценарий: GIVEN — существенное исходное состояние, WHEN — событие,
|
||
THEN — конкретный наблюдаемый исход. Минимум один Scenario; границы/отказы/повторы
|
||
добавляй по смыслу. Новое правило в одном лишь сценарии недопустимо.
|
||
AND дополняет предыдущий тип шага GIVEN/WHEN/THEN.
|
||
Термины определены, величины имеют единицы и границы. Неизвестное — вопрос в
|
||
Open Decisions с владельцем и зависимым требованием, не придуманный ответ.
|
||
|
||
Для спорного/выведенного Requirement укажи источник перед первым Scenario по профилю.
|
||
Пример формата (подставь реальное согласованное решение):
|
||
**Источник (ненормативно):** [решение владельца](<URL-комментария-Issue>), пункт «Границы периода».
|
||
Ссылка остаётся пригодной после archive; норму полностью сформулируй в Requirement.
|
||
|
||
Учебный образец формы, не продуктовая политика:
|
||
## ADDED Requirements
|
||
### Requirement: Отбор операций за календарный период
|
||
При формировании отчёта система SHALL включать все и только операции выбранного
|
||
счёта, дата учёта которых входит в выбранный период включительно по Europe/Moscow.
|
||
|
||
#### Scenario: Последний день периода и следующий день
|
||
- **GIVEN** выбран период 01.10.2026–31.10.2026 и счёт A
|
||
- **AND** на счёте A есть операции X с датой учёта 31.10.2026 и Y с датой 01.11.2026
|
||
- **WHEN** формируется отчёт
|
||
- **THEN** отчёт включает X и не включает Y
|
||
|
||
Плохо: «корректно отбирать операции до конца месяца» — не определены месяц,
|
||
границы, дата отбора и счёт; «THEN список корректен» — нет проверяемого исхода.
|
||
Для таблиц решений и переходов используй эталоны из профиля.
|
||
-->
|