refactor: make sdd-lab review-driven (WealthLedger/specs#66)
Replace executable schema checks with explicit review-driven readiness, add a requirement-writing profile, and incorporate review clarifications for source traceability and comparative validation.
This commit was merged in pull request #68.
This commit is contained in:
@@ -1,17 +1,21 @@
|
||||
# Process Record
|
||||
|
||||
**Mode:** <!-- guide: lab | delivery -->
|
||||
**Class:** <!-- guide: standard | complex -->
|
||||
**Issue:** <!-- guide: Gitea Issue link -->
|
||||
**Mode:** <!-- lab | delivery -->
|
||||
**Class:** <!-- standard | complex -->
|
||||
**Issue:** <!-- ссылка на Gitea Issue -->
|
||||
|
||||
## Change Profile
|
||||
|
||||
<!-- guide: One row per conditional artifact, all ten rows required. Selected =
|
||||
yes|no. Reason cites the concrete trigger from the instruction table or why
|
||||
it does not apply; "lab practice" is a valid reason only in lab mode and
|
||||
must name the practice. -->
|
||||
<!-- Строка на каждый условный артефакт, все десять обязательны. Выбран = yes|no.
|
||||
Причина называет конкретный trigger из instruction артефакта или объясняет, почему
|
||||
он не применим; «lab: практика …» допустима только в lab и называет практику.
|
||||
Пример:
|
||||
| failure-model | yes | синхронизация брокера повторяет неидемпотентную запись |
|
||||
| nfr | no | нет новых обязательств по задержке, объёму или хранению |
|
||||
| data-mapping | yes | lab: практика data mapping |
|
||||
Плохо: `| nfr | no | N/A |` — причина должна объяснять, почему не нужно. -->
|
||||
|
||||
| Artifact | Selected | Reason |
|
||||
| Артефакт | Выбран | Причина |
|
||||
| --- | --- | --- |
|
||||
| research | | |
|
||||
| ux-design | | |
|
||||
@@ -26,32 +30,40 @@
|
||||
|
||||
## Gate Log
|
||||
|
||||
<!-- guide: Append-only, chronological. Scope = artifact ids covered by the
|
||||
decision. Validation = commands run and their results, review verdicts.
|
||||
Decision = `approved "<quoted owner words>"`, `rejected`, `changes requested`
|
||||
or `invalidated: <reason>`. Never write a decision the owner did not give. -->
|
||||
<!-- Только дописывание, по хронологии. Scope — ids артефактов в решении.
|
||||
Validation — выполненные команды и результаты, вердикты review.
|
||||
Decision — `approved "<дословные слова владельца>"`, `rejected`,
|
||||
`changes requested` или `invalidated: <причина>`. Никогда не записывай решение,
|
||||
которого владелец не давал. ПОСЛЕДНЯЯ строка gate — его состояние; более поздняя
|
||||
rejected / changes requested / invalidated снимает этот gate и все последующие.
|
||||
Для Specs: Validation отмечает нормоконтроль и смысловую проверку набора по
|
||||
spec-writing.md; Findings — конкретные неясности/пропуски и их разрешение.
|
||||
Пример:
|
||||
| G1 | 2026-10-29 | proposal, change-profile | `openspec validate` OK; readiness: plan OK | product-analyst: 1 major — закрыт в Open Decisions | approved "ок, идём дальше" (сессия) |
|
||||
| G2 | 2026-10-30 | specs | `openspec validate --strict` OK; readiness: plan OK | qa-engineer: в Scenario нет значения THEN | changes requested |
|
||||
Плохо: `approved` без цитаты владельца; строка G4 со Scope `design`. -->
|
||||
|
||||
| Gate | Date | Scope | Validation | Findings | Decision |
|
||||
| Gate | Дата | Scope | Validation | Findings | Decision |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
|
||||
## Descoped Work
|
||||
|
||||
<!-- guide: Tasks removed from tasks.md after G3. Reason and approving gate are
|
||||
required. Leave the header row only when nothing was descoped. -->
|
||||
<!-- Tasks, удалённые из tasks.md после G3. Причина и gate решения обязательны.
|
||||
Если ничего не снято — только строка заголовка. -->
|
||||
|
||||
| Task | Reason | Gate |
|
||||
| Task | Причина | Gate |
|
||||
| --- | --- | --- |
|
||||
|
||||
## Lab Journal
|
||||
|
||||
<!-- guide: lab mode: one row per completed stage, written right after it.
|
||||
Unique findings = what this stage found that no other stage did.
|
||||
Cost = subagent calls, approximate tokens or time. delivery mode: optional. -->
|
||||
<!-- lab: строка на каждую завершённую стадию, сразу после неё. Уникальные находки —
|
||||
то, что нашла только эта стадия. Стоимость — вызовы сабагентов, примерно токены
|
||||
или время. delivery: необязательно. -->
|
||||
|
||||
| Stage | Role / subagent | Unique findings | Decisions | Risks found / excluded | Handoff issues | Skills | Cost | Transferable |
|
||||
| Стадия | Роль / сабагент | Уникальные находки | Решения | Риски найдены / исключены | Проблемы передачи | Skills | Стоимость | Переносимо |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
|
||||
## Retrospective
|
||||
|
||||
<!-- guide: Written after G4. Which stages paid off, which were redundant for this
|
||||
class of change, what to change in the schema. Facts first, then opinion. -->
|
||||
<!-- После G4. Какие стадии окупились, какие были лишними для этого класса change,
|
||||
что поменять в schema. Сначала факты, потом мнение. -->
|
||||
|
||||
Reference in New Issue
Block a user