From a3cfcf0b037ae45bd3d919c1f3f8d824aa8af4f9 Mon Sep 17 00:00:00 2001 From: Danil Pismenny Date: Thu, 6 Aug 2026 13:54:14 +0500 Subject: [PATCH 1/3] docs: add 4+1 viewpoint coverage --- README.md | 1 + .../flows/feature-artifact-catalog.md | 1 + template/memory-bank/flows/feature.md | 46 ++++++++++++++++++- .../flows/templates/feature/design.md | 30 +++++++++++- 4 files changed, 75 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 332faeb..d9ae868 100644 --- a/README.md +++ b/README.md @@ -102,6 +102,7 @@ service setup-команды проекта; он намеренно не пер Источники полезных практик: +- [4+1 architectural view model](https://en.wikipedia.org/wiki/4%2B1_architectural_view_model) — источник stakeholder-oriented проверки Logical, Process, Development и Physical views через driving scenarios; - [`dapi/zelma`](https://github.com/dapi/zelma); - [`brandymint/merchantly`](https://github.com/brandymint/merchantly); - [`alfagen/mercury`](https://github.com/alfagen/mercury); diff --git a/template/memory-bank/flows/feature-artifact-catalog.md b/template/memory-bank/flows/feature-artifact-catalog.md index 40c42c9..c63715a 100644 --- a/template/memory-bank/flows/feature-artifact-catalog.md +++ b/template/memory-bank/flows/feature-artifact-catalog.md @@ -59,6 +59,7 @@ audience: humans_and_agents | Artifact | Question answered | Trigger | Default form / suggested path | Ownership | Template | | --- | --- | --- | --- | --- | --- | +| 4+1 viewpoint coverage and correspondence | Достаточно ли одно решение описано для Logical, Process, Development, Physical concerns и driving Scenarios, и согласованы ли эти projections? | Любой required `design.md` | Sections in `design.md`; отдельный artifact не создаётся | Только cross-references между canonical owners; views не вводят новые facts | [Design](templates/feature/design.md) | | `design.md` | Какое решение выбрано и почему? | `Design required: yes` | `features/FT-XXX/design.md` | `root`: manifest, selected design и default owner неделегированных feature-local solution facts | [Design](templates/feature/design.md) | | C4 view | Какие system, container, component или critical code boundaries и bindings затронуты? | Срабатывает C4 trigger из feature flow | Embedded Mermaid/table; при росте `diagrams/-c4.md` | `derived-view` для feature-local projection или `external-dependency` для canonical shared model; не заменяет Architecture Coverage Decision | pattern in Design | | Component responsibility map | Как распределена ответственность между modules/services? | Новая decomposition, orchestration или ownership transfer | Table or C3 view in `design.md` | Selected responsibilities остаются `SOL-*` / `SD-*` | pattern only | diff --git a/template/memory-bank/flows/feature.md b/template/memory-bank/flows/feature.md index 5b82605..ec62651 100644 --- a/template/memory-bank/flows/feature.md +++ b/template/memory-bank/flows/feature.md @@ -147,6 +147,46 @@ C4 можно не создавать, если изменение одновр 3. C4 artifact не должен содержать execution steps, file-level TODO или test commands. 4. Если C4 level required, `Solution Ready` недостижим без artifact-а или ссылки на уже существующий canonical C4/design artifact, который покрывает affected boundary. +## 4+1 Viewpoint Coverage Requirements + +Каждый required `design.md` до `Solution Ready` обязан проверить решение через +модель 4+1: Logical, Process, Development, Physical и driving Scenarios. Это +stakeholder/concern coverage поверх canonical facts, а не пять новых владельцев +архитектуры и не обязательство создать пять документов или диаграмм. + +- **Logical View** показывает предоставляемое поведение, domain meaning и + requirements. Он ссылается на canonical `brief.md`, `UC-*`, PRD и domain + owners и обязателен для любой designed feature. +- **Process View** показывает runtime behavior: взаимодействия, ordering, + state transitions, concurrency, failure и recovery. Не путай его с Feature + Flow: Feature Flow управляет delivery lifecycle, а Process View описывает + исполняемую систему. +- **Development View** показывает устойчивую организацию code modules, + components, interfaces и ownership с точки зрения разработчика. + `implementation-plan.md` не является Development View: он владеет порядком + работы, а не архитектурой реализации. +- **Physical View** показывает runtime/deployment topology: deployable nodes, + queues, stores, environment/config bindings и operational boundaries. +- **Scenarios (+1)** связывают остальные views через `SC-*`, применимые + project-level `UC-*` и negative/error paths. Scenario используется как input + design analysis и затем как основа проверки, а не только как финальный test. + +Logical View и Scenarios всегда получают `covered`. Process, Development и +Physical получают `covered` при применимом trigger либо обоснованный `N/A`. +Каждая строка называет stakeholder/concern, canonical owner/refs и optional +supporting projection. Supporting views ссылаются на canonical IDs и не вводят +новые requirements, decisions, contracts или topology facts. + +До `Solution Ready` каждый `SC-*` из `brief.md` должен присутствовать в +Cross-View Correspondence: scenario/requirement → применимые runtime semantics +→ code/component ownership → deployment topology → `CHK-*`/`EVID-*`. Для +неприменимого view фиксируется `N/A`, а не выдумывается искусственная связь. + +4+1 дополняет, но не заменяет C4 и Architecture Coverage Decision: 4+1 +проверяет stakeholder concerns, C4 выбирает структурный zoom level, а +Architecture Coverage проверяет components, connectors, configuration, +behavioral semantics и quality/evolution concerns. + ## Architecture Coverage Requirements Каждый required `design.md` до `Solution Ready` обязан явно проверить достаточность архитектурного описания по пяти аспектам: components, connectors, configuration, behavioral semantics и quality/evolution concerns. Это обязательный analysis decision, а не требование создать пять разделов, отдельные файлы или diagrams: компактные факты остаются в `design.md`, а неприменимый аспект получает обоснованный `N/A`. @@ -274,6 +314,8 @@ flowchart LR - [ ] `design.md` содержит ≥ 1 `SOL-*` - [ ] `design.md` ссылается минимум на один canonical `REQ-*` из sibling `brief.md` - [ ] `design.md` фиксирует C4 applicability decision; если C4 level required, C4 artifact или ссылка на canonical C4/design artifact присутствует в design-pack +- [ ] 4+1 Viewpoint Coverage Decision фиксирует `covered` для Logical View и Scenarios, а для Process, Development и Physical — `covered` или обоснованный `N/A`, stakeholder/concern, canonical refs и optional supporting projection +- [ ] Cross-View Correspondence содержит каждый `SC-*` из `brief.md` и связывает его с requirement, применимыми Process/Development/Physical refs и `CHK-*`/`EVID-*`; неприменимые связи отмечены `N/A` - [ ] Architecture Coverage Decision фиксирует `covered` или обоснованный `N/A` для components, connectors, configuration, behavioral semantics и quality/evolution concerns - [ ] при cross-component interaction явно показаны bindings/topology, direction, connector kind и значимые interaction semantics; один перечень components недостаточен - [ ] Design Verification выбирает каждый analysis class по риску через `required: yes/no`; required analyses имеют method и result/evidence, а `no` имеет причину @@ -459,7 +501,7 @@ Canonical testing policy живёт в [../engineering/testing-policy.md](../eng 1. Любой canonical `brief.md` использует как минимум `REQ-*`, `NS-*`, `SC-*`, `CHK-*`, `EVID-*`. 2. Любой `brief.md` со `status: active` задает хотя бы один explicit test case через `SC-*`. 3. `brief.md` может использовать только минимальный problem-space набор для compact feature package или расширенный набор feature IDs по необходимости; отдельные problem-space templates не используются. -4. Любой required `design.md` использует как минимум один `SOL-*`, один `C4-*` decision, Architecture Coverage Decision и Design Verification selection и связывает solution refs минимум с одним `REQ-*` из sibling `brief.md`. +4. Любой required `design.md` использует как минимум один `SOL-*`, один `C4-*` decision, 4+1 Viewpoint Coverage Decision, Cross-View Correspondence, Architecture Coverage Decision и Design Verification selection и связывает solution refs минимум с одним `REQ-*` из sibling `brief.md`. 5. Любой `design.md` фиксирует selection rationale для C4 applicability; выбранные C4 views используют `C4-*` и связываются с `SOL-*`, `SD-*`, `CTR-*`, `INV-*` или ADR refs. 6. Любой `design.md`, где есть принятые feature-local решения, использует `SD-*`; `ALT-*`, `TRD-*`, `CTR-*`, `INV-*`, `FM-*` и `RB-*` применяются только когда соответствующая solution-semantics действительно нужна. 7. Любой optional support doc использует только local support IDs и traceability к canonical refs; он не вводит новые canonical `REQ-*`, `SC-*`, `CHK-*` или `EVID-*`. @@ -469,7 +511,7 @@ Canonical testing policy живёт в [../engineering/testing-policy.md](../eng 1. Scope в `brief.md` фиксируется через `REQ-*`, non-scope через `NS-*`. 2. Verify в `brief.md` связывает `REQ-*` с test cases через `Acceptance Scenarios`, feature-specific `NEG-*`, `Traceability matrix`, `Test matrix` и `Evidence contract`. -3. `design.md`, если есть, связывает `REQ-*` из `brief.md` с `SOL-*`, `ALT-*`, `TRD-*`, `C4-*`, `SD-*`, `CTR-*`, `INV-*`, `FM-*`, `RB-*` и accepted ADR refs. +3. `design.md`, если есть, связывает каждый `SC-*` и применимые `REQ-*` из `brief.md` с Logical, Process, Development и Physical refs через Cross-View Correspondence; canonical solution traceability отдельно связывает `REQ-*` с `SOL-*`, `ALT-*`, `TRD-*`, `C4-*`, `SD-*`, `CTR-*`, `INV-*`, `FM-*`, `RB-*` и accepted ADR refs. 4. `implementation-plan.md` ссылается на canonical IDs из `brief.md` и, если есть, применимые `SOL-*`, `C4-*`, `SD-*`, `CTR-*`, `INV-*`, `FM-*`, `RB-*` и accepted ADR refs в Design Realization Mapping и `Implements`; `Verifies` содержит связанные `CHK-*`, а `Evidence IDs` — подтверждающие `EVID-*`, образуя trace chain от canonical ref до evidence. 5. Если sequencing блокируется неизвестностью, план фиксирует её как `OQ-*`, а не прячет в prose. 6. Если выполнение требует человеческого подтверждения для рискованных действий, план фиксирует это через `AG-*`. diff --git a/template/memory-bank/flows/templates/feature/design.md b/template/memory-bank/flows/templates/feature/design.md index 0f814a2..6848a68 100644 --- a/template/memory-bank/flows/templates/feature/design.md +++ b/template/memory-bank/flows/templates/feature/design.md @@ -23,7 +23,7 @@ canonical_for: Создавай `design.md`, когда фича требует solution-space reasoning: выбор подхода, trade-offs, contracts, invariants, failure modes, rollout/backout, ADR/C4/data-flow/diagram dependencies или design-pack из нескольких документов. -На стадии анализа обязательно заполни C4 applicability decision, Architecture Coverage Decision и risk-based Design Verification. C4 artifact обязателен только когда trigger из [feature.md#c4-analysis-requirements](../../feature.md#c4-analysis-requirements) требует C1/C2/C3/C4; отдельные diagrams/contracts остаются conditional, но coverage analysis обязателен для любого required `design.md`. +На стадии анализа обязательно заполни C4 applicability decision, 4+1 Viewpoint Coverage Decision, Cross-View Correspondence, Architecture Coverage Decision и risk-based Design Verification. C4 artifact обязателен только когда trigger из [feature.md#c4-analysis-requirements](../../feature.md#c4-analysis-requirements) требует C1/C2/C3/C4; отдельные diagrams/contracts остаются conditional, но coverage analysis обязателен для любого required `design.md`. `design.md` не заменяет `brief.md`: требования, acceptance criteria и evidence contract остаются в `brief.md`. `design.md` также не является execution plan: file-level touchpoints, атомарные шаги, команды тестов и checkpoints принадлежат `implementation-plan.md`. @@ -93,6 +93,34 @@ canonical owner — `external-dependency` и не входит в состав p - `C3` - Component: modules/services/state machines внутри container. - `C4` - Code: только когда class/interface-level structure является архитектурным решением. +## 4+1 Viewpoint Coverage Decision + +Эта таблица проверяет stakeholder/concern coverage, не создавая новых canonical +owners. Logical View и Scenarios обязательны. Для Process, Development и +Physical выбери `covered` при применимом trigger или обоснованный `N/A`. +Supporting projection не владеет facts и должна ссылаться на canonical IDs. + +Process View означает runtime behavior проектируемой системы, а не Feature +Flow. `implementation-plan.md` не является Development View: он описывает +execution sequence, а не устойчивую структуру code modules. + +| View | Stakeholders / concerns | Status | Canonical owner / refs | Supporting projection | Reason if N/A / coverage note | +| --- | --- | --- | --- | --- | --- | +| Logical | Users, product/domain owners; capabilities, rules, meaning | `covered` | `brief.md` `REQ-*`; применимые `UC-*`, PRD/domain refs | domain/use-case projection / `none` | Где определено observable behavior | +| Process | Runtime, reliability/performance owners; interactions, state, ordering, concurrency, failure/recovery | `covered` / `N/A` | `design.md` `CTR-*` / `INV-*` / `FM-*` или delegated contract / ADR | sequence / state / data-flow / `none` | Как покрыта runtime dynamics или почему она не меняется | +| Development | Developers/maintainers; modules, components, interfaces, code ownership | `covered` / `N/A` | `design.md` `SOL-*` / `SD-*`, `engineering/architecture.md` или ADR | C3/C4 / component map / `none` | Как покрыта implementation structure или почему она не меняется | +| Physical | Operations/platform owners; deployables, nodes, queues/stores, config bindings, deployment topology | `covered` / `N/A` | `design.md` `SOL-*` / `SD-*` / `RB-*`, `ops/*` или ADR | C2 / deployment view / `none` | Как покрыта runtime topology или почему она не меняется | +| Scenarios (+1) | Users/operators/reviewers; end-to-end and negative journeys | `covered` | `brief.md` `SC-*` / `NEG-*`; применимые `UC-*` | feature-local `FUC-*` / sequence / `none` | Какие scenarios формируют и проверяют решение | + +### Cross-View Correspondence + +Добавь по строке для каждого `SC-*` из `brief.md`. Используй только ссылки на +canonical facts; для неприменимого view укажи `N/A`. + +| Scenario / requirement | Logical refs | Process refs | Development refs | Physical refs | Verification refs | +| --- | --- | --- | --- | --- | --- | +| `SC-01` / `REQ-01` | `REQ-01`, применимый `UC-*` | `CTR-01`, `INV-01`, `FM-01` / `N/A` | `SOL-01`, `C4-L3-*`, `SD-01` / `N/A` | `C4-L2-*`, `RB-01`, ops ref / `N/A` | `CHK-01`, `EVID-01` | + ## Architecture Coverage Decision Для каждого аспекта выбери `covered` или обоснованный `N/A`. Analysis обязателен; дополнительные artifacts создавай только по trigger. В `Canonical owner / refs` укажи документ-владелец и stable IDs, а supporting view не считай canonical owner. Каждый отдельный artifact должен быть проиндексирован в Design Pack; external dependency индексируется, но не входит в его состав. From 013f55e2f45316af3d5cc0475a5092eb81b63db4 Mon Sep 17 00:00:00 2001 From: Danil Pismenny Date: Thu, 6 Aug 2026 14:00:30 +0500 Subject: [PATCH 2/3] docs: separate methodology sources from downstream repos --- README.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index d9ae868..79175ce 100644 --- a/README.md +++ b/README.md @@ -100,12 +100,19 @@ service setup-команды проекта; он намеренно не пер ## Развитие шаблона -Источники полезных практик: +### Методические источники - [4+1 architectural view model](https://en.wikipedia.org/wiki/4%2B1_architectural_view_model) — источник stakeholder-oriented проверки Logical, Process, Development и Physical views через driving scenarios; +- Nenad Medvidovic, Richard N. Taylor, [*A Classification and Comparison Framework for Software Architecture Description Languages*](https://ics.uci.edu/~taylor/documents/2000-ADLs-TSE.pdf) — источник архитектурной модели components, connectors и configurations. + +### Downstream-репозитории и практические полигоны + +Эти репозитории используют и адаптируют Memory Bank под конкретные проекты. +Опыт их эксплуатации может становиться источником обобщаемых правил для +шаблона, но их project-specific факты остаются в downstream-копиях. + - [`dapi/zelma`](https://github.com/dapi/zelma); - [`brandymint/merchantly`](https://github.com/brandymint/merchantly); -- [`alfagen/mercury`](https://github.com/alfagen/mercury); -- Nenad Medvidovic, Richard N. Taylor, [*A Classification and Comparison Framework for Software Architecture Description Languages*](https://ics.uci.edu/~taylor/documents/2000-ADLs-TSE.pdf) — источник архитектурной модели components, connectors и configurations. +- [`alfagen/mercury`](https://github.com/alfagen/mercury). Добавляйте в шаблон только обобщаемые правила. Названия продуктов, инфраструктурные детали и другие project-specific факты должны оставаться в downstream-копии `memory-bank/`. From b3bdce4044f39fc1f91f37e9dddc4dc60fd0f1fc Mon Sep 17 00:00:00 2001 From: Danil Pismenny Date: Thu, 6 Aug 2026 14:07:38 +0500 Subject: [PATCH 3/3] docs: make 4+1 coverage enforceable --- README.md | 2 +- template/memory-bank/flows/feature.md | 22 ++++++++++++++++--- .../flows/templates/feature/design.md | 16 +++++++++----- 3 files changed, 30 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 79175ce..660f737 100644 --- a/README.md +++ b/README.md @@ -102,7 +102,7 @@ service setup-команды проекта; он намеренно не пер ### Методические источники -- [4+1 architectural view model](https://en.wikipedia.org/wiki/4%2B1_architectural_view_model) — источник stakeholder-oriented проверки Logical, Process, Development и Physical views через driving scenarios; +- Philippe Kruchten, [*Architectural Blueprints — The “4+1” View Model of Software Architecture*](https://arxiv.org/abs/2006.04975) — первичный источник stakeholder-oriented проверки Logical, Process, Development и Physical views через driving scenarios; [краткий обзор](https://en.wikipedia.org/wiki/4%2B1_architectural_view_model); - Nenad Medvidovic, Richard N. Taylor, [*A Classification and Comparison Framework for Software Architecture Description Languages*](https://ics.uci.edu/~taylor/documents/2000-ADLs-TSE.pdf) — источник архитектурной модели components, connectors и configurations. ### Downstream-репозитории и практические полигоны diff --git a/template/memory-bank/flows/feature.md b/template/memory-bank/flows/feature.md index ec62651..b822be2 100644 --- a/template/memory-bank/flows/feature.md +++ b/template/memory-bank/flows/feature.md @@ -171,8 +171,21 @@ stakeholder/concern coverage поверх canonical facts, а не пять но project-level `UC-*` и negative/error paths. Scenario используется как input design analysis и затем как основа проверки, а не только как финальный test. +### View Applicability Predicates + +| View | `covered` обязателен, когда | `N/A` допустим, когда | +| --- | --- | --- | +| Logical | Всегда: designed feature реализует или изменяет capability, rule или observable engineering/operations outcome из `brief.md` | Никогда | +| Process | Selected solution меняет runtime interactions, state transitions, ordering, sync/async boundary, concurrency, failure propagation или recovery behavior | Все runtime semantics остаются у существующих canonical owners без изменений, а scenario не вводит новый temporal/failure path | +| Development | Selected solution меняет module/component/interface responsibilities, code ownership, dependency direction или внутреннюю decomposition | Решение полностью использует существующую implementation structure и не перераспределяет ответственность или dependencies | +| Physical | Selected solution меняет deployable/runtime nodes, queue/store boundary, environment/config binding, network/trust placement или deployment topology | Решение выполняется в существующей topology и не меняет runtime placement или bindings | +| Scenarios (+1) | Всегда: каждый `SC-*` участвует в Cross-View Correspondence | Никогда | + +Если evidence недостаточно, чтобы доказать `N/A`, view остается `covered` и +анализ продолжается либо unresolved applicability проходит Human Gate. + Logical View и Scenarios всегда получают `covered`. Process, Development и -Physical получают `covered` при применимом trigger либо обоснованный `N/A`. +Physical получают `covered` по predicates выше либо обоснованный `N/A`. Каждая строка называет stakeholder/concern, canonical owner/refs и optional supporting projection. Supporting views ссылаются на canonical IDs и не вводят новые requirements, decisions, contracts или topology facts. @@ -257,6 +270,9 @@ Feature-local `ui-reference/README.md` ссылается на `engineering/ui-d ## Migration Strategy - Новые feature packages обязаны сразу следовать структуре `brief.md -> optional design.md -> implementation-plan.md`. +- Новый `design.md` обязан сразу содержать 4+1 Viewpoint Coverage Decision и Cross-View Correspondence. +- Existing active/archived `design.md`, который уже прошёл `Solution Ready` до принятия 4+1 rules, сохраняет прежний gate state, пока его canonical solution facts не меняются; documented prior review или pinned template revision служит evidence grandfathering. +- При material change существующего design pack grandfathering прекращается: перед повторным `Solution Ready` добавь 4+1 coverage и correspondence по текущему contract. Одна только execution continuation без изменения canonical solution facts не требует retroactive backfill. - При миграции старого package layout сначала назначь canonical owners: problem-space content переносится в `brief.md`, required solution-space content — в root `design.md` или явно проиндексированный constituent. - После миграции package не должен сохранять duplicate active owners для problem space или solution space. - Миграция может происходить постепенно, package-by-package. @@ -314,7 +330,7 @@ flowchart LR - [ ] `design.md` содержит ≥ 1 `SOL-*` - [ ] `design.md` ссылается минимум на один canonical `REQ-*` из sibling `brief.md` - [ ] `design.md` фиксирует C4 applicability decision; если C4 level required, C4 artifact или ссылка на canonical C4/design artifact присутствует в design-pack -- [ ] 4+1 Viewpoint Coverage Decision фиксирует `covered` для Logical View и Scenarios, а для Process, Development и Physical — `covered` или обоснованный `N/A`, stakeholder/concern, canonical refs и optional supporting projection +- [ ] 4+1 Viewpoint Coverage Decision применяет View Applicability Predicates и фиксирует `covered` для Logical View и Scenarios, а для Process, Development и Physical — `covered` или evidence-backed `N/A`, stakeholder/concern, canonical refs и optional supporting projection - [ ] Cross-View Correspondence содержит каждый `SC-*` из `brief.md` и связывает его с requirement, применимыми Process/Development/Physical refs и `CHK-*`/`EVID-*`; неприменимые связи отмечены `N/A` - [ ] Architecture Coverage Decision фиксирует `covered` или обоснованный `N/A` для components, connectors, configuration, behavioral semantics и quality/evolution concerns - [ ] при cross-component interaction явно показаны bindings/topology, direction, connector kind и значимые interaction semantics; один перечень components недостаточен @@ -501,7 +517,7 @@ Canonical testing policy живёт в [../engineering/testing-policy.md](../eng 1. Любой canonical `brief.md` использует как минимум `REQ-*`, `NS-*`, `SC-*`, `CHK-*`, `EVID-*`. 2. Любой `brief.md` со `status: active` задает хотя бы один explicit test case через `SC-*`. 3. `brief.md` может использовать только минимальный problem-space набор для compact feature package или расширенный набор feature IDs по необходимости; отдельные problem-space templates не используются. -4. Любой required `design.md` использует как минимум один `SOL-*`, один `C4-*` decision, 4+1 Viewpoint Coverage Decision, Cross-View Correspondence, Architecture Coverage Decision и Design Verification selection и связывает solution refs минимум с одним `REQ-*` из sibling `brief.md`. +4. Любой новый required `design.md` и существующий design pack, повторно входящий в `Solution Ready` после material solution change, использует как минимум один `SOL-*`, один `C4-*` decision, 4+1 Viewpoint Coverage Decision, Cross-View Correspondence, Architecture Coverage Decision и Design Verification selection и связывает solution refs минимум с одним `REQ-*` из sibling `brief.md`; grandfathered packages следуют Migration Strategy. 5. Любой `design.md` фиксирует selection rationale для C4 applicability; выбранные C4 views используют `C4-*` и связываются с `SOL-*`, `SD-*`, `CTR-*`, `INV-*` или ADR refs. 6. Любой `design.md`, где есть принятые feature-local решения, использует `SD-*`; `ALT-*`, `TRD-*`, `CTR-*`, `INV-*`, `FM-*` и `RB-*` применяются только когда соответствующая solution-semantics действительно нужна. 7. Любой optional support doc использует только local support IDs и traceability к canonical refs; он не вводит новые canonical `REQ-*`, `SC-*`, `CHK-*` или `EVID-*`. diff --git a/template/memory-bank/flows/templates/feature/design.md b/template/memory-bank/flows/templates/feature/design.md index 6848a68..07f08bd 100644 --- a/template/memory-bank/flows/templates/feature/design.md +++ b/template/memory-bank/flows/templates/feature/design.md @@ -99,18 +99,22 @@ canonical owner — `external-dependency` и не входит в состав p owners. Logical View и Scenarios обязательны. Для Process, Development и Physical выбери `covered` при применимом trigger или обоснованный `N/A`. Supporting projection не владеет facts и должна ссылаться на canonical IDs. +Применимость определяй только по +[View Applicability Predicates](../../feature.md#view-applicability-predicates): +если evidence недостаточно для `N/A`, продолжи analysis или используй Human +Gate. Process View означает runtime behavior проектируемой системы, а не Feature Flow. `implementation-plan.md` не является Development View: он описывает execution sequence, а не устойчивую структуру code modules. -| View | Stakeholders / concerns | Status | Canonical owner / refs | Supporting projection | Reason if N/A / coverage note | +| View | Stakeholders / concerns | Status | Canonical owner / refs | Supporting projection | Applicability trigger / N/A evidence | | --- | --- | --- | --- | --- | --- | -| Logical | Users, product/domain owners; capabilities, rules, meaning | `covered` | `brief.md` `REQ-*`; применимые `UC-*`, PRD/domain refs | domain/use-case projection / `none` | Где определено observable behavior | -| Process | Runtime, reliability/performance owners; interactions, state, ordering, concurrency, failure/recovery | `covered` / `N/A` | `design.md` `CTR-*` / `INV-*` / `FM-*` или delegated contract / ADR | sequence / state / data-flow / `none` | Как покрыта runtime dynamics или почему она не меняется | -| Development | Developers/maintainers; modules, components, interfaces, code ownership | `covered` / `N/A` | `design.md` `SOL-*` / `SD-*`, `engineering/architecture.md` или ADR | C3/C4 / component map / `none` | Как покрыта implementation structure или почему она не меняется | -| Physical | Operations/platform owners; deployables, nodes, queues/stores, config bindings, deployment topology | `covered` / `N/A` | `design.md` `SOL-*` / `SD-*` / `RB-*`, `ops/*` или ADR | C2 / deployment view / `none` | Как покрыта runtime topology или почему она не меняется | -| Scenarios (+1) | Users/operators/reviewers; end-to-end and negative journeys | `covered` | `brief.md` `SC-*` / `NEG-*`; применимые `UC-*` | feature-local `FUC-*` / sequence / `none` | Какие scenarios формируют и проверяют решение | +| Logical | Users, product/domain owners; capabilities, rules, meaning | `covered` | `brief.md` `REQ-*`; применимые `UC-*`, PRD/domain refs | domain/use-case projection / `none` | `Always`; где определено observable behavior | +| Process | Runtime, reliability/performance owners; interactions, state, ordering, concurrency, failure/recovery | `covered` / `N/A` | `design.md` `CTR-*` / `INV-*` / `FM-*` или delegated contract / ADR | sequence / state / data-flow / `none` | Какой runtime predicate сработал или evidence, что semantics не меняется | +| Development | Developers/maintainers; modules, components, interfaces, code ownership | `covered` / `N/A` | `design.md` `SOL-*` / `SD-*`, `engineering/architecture.md` или ADR | C3/C4 / component map / `none` | Какой structure predicate сработал или evidence, что ownership/dependencies не меняются | +| Physical | Operations/platform owners; deployables, nodes, queues/stores, config bindings, deployment topology | `covered` / `N/A` | `design.md` `SOL-*` / `SD-*` / `RB-*`, `ops/*` или ADR | C2 / deployment view / `none` | Какой topology predicate сработал или evidence, что placement/bindings не меняются | +| Scenarios (+1) | Users/operators/reviewers; end-to-end and negative journeys | `covered` | `brief.md` `SC-*` / `NEG-*`; применимые `UC-*` | feature-local `FUC-*` / sequence / `none` | `Always`; какие scenarios формируют и проверяют решение | ### Cross-View Correspondence