И последнее по SDD. Последнее, но важное.

SDD - это упор на актуальную спецификацию. Т.е. на аналитику.
Из 5-10 шагов по SDD workflow к чистой разработке относится один - /opsx:apply и /speckit.implement соответственно.

Достаточно ли этого?
Для простых фичей, но при этом имеющих свою аналитику - да.
А для более сложных есть superpowers) С TDD, параллельной разработкой в разных worktree, с расширенным код-ревью и отладкой

И в обоих случаях он отлично ложится в workflow, заменяя собой упомянутые выше шаги. И ложась т.об. в середину процесса.

Два нюанса:
1) brainstorming из superpowers в такой схеме становится ненужным и заменяется аналогами из SDD фреймворков
2) writing-plans (из superpowers) нужно оставить, так как это разная детализация.
В SDD таски написаны на уровне аналитика, а writing-plans пишет классы, импорты, тесты, команды запуска скриптов.
По сути из плана, созданного через superpowers, написать код может любой джун. И ему даже скучно будет)
Или самая дешевая модель.

Тогда может возникнуть другой вопрос - а нужен ли план, созданный SDD фреймворком?
В целом не обязателен. Но если он создается одной командой с другими артефактами - можно и оставить. Или подтюнить соответствующий скил.

Еще одно важное замечание. Я встречал случаи, когда superpowers тоже относят к SDD.
Нет, ну формально конечно спека по итогу brainstorming создается, как и план по итогу writing-plans.
Но это спека и план с деталями реализации, т.к. superpowers прям заточен под разработку.
Поэтому на мой взгляд по факту это не SDD фреймворк. Ну или как минимум - не SDD для команд, где есть явная роль аналитика.

И последний момент - нужно ли использовать два фреймворки - OpenSpec + superpowers - в связке?
А точнее когда нужно их использовать?
Ответ в общем очевиден - для достаточно больших фичей, когда в репозитории по итогу разработки фичи должна остаться спецификация. Либо это требование организации, либо решение команды.

#ai #ai_harness #dev_workflow

Небольшая иллюстрация чем отличаются superpowers и OpenSpec на примере артефакта tasks.

OpenSpec, план работ по одной task-е

## 1. Chain и policy

- [ ] 1.1 `data/label_policy.yaml`: добавить `service_id_chain` (дефолт `[service, service.name, app, app.kubernetes.io/name, job]`); загрузчик policy сохраняет порядок, поставляет дефолт при отсутствии поля
- [ ] 1.2 Функция извлечения `extract_service_id(labels, chain) -> (service_id, service_source)` — чистая, ≤N dict-lookup'ов; юнит-тесты: порядок приоритета (`service` бьёт `app`), fallback на `app`/`job`, пустой chain → `('', 'none')`, provenance-значения

superpowers, кусочек плана по той же task-е

### Task 1: Service ID Extraction Chain + Policy

**Files:**
- Create: `src/meta/service_id.py`
- Modify: `data/label_policy.yaml`
...

**Interfaces:**
- Produces: `extract_service_id(labels: dict[str, str], chain: list[str]) -> tuple[str, str]` — returns `(service_id, service_source)`
...

#### Step 1: Add `service_id_chain` to `label_policy.yaml`

- [ ] **Step 1.1: Edit `data/label_policy.yaml`** — append after `max_virtual_series`:

```yaml
# service_id_chain — ordered keys for deriving a metric's service identity
# (T2-22). The first key present in observed labels wins. Chain order:
# intentional instrumentation labels → infra labels → scrape labels.
# Changing the chain requires re-profiling affected metrics + regenerating
# templates (chain is part of the metric-identity contract).
service_id_chain:
- service
- service.name
- app
- app.kubernetes.io/name
- job
```

#### Step 2: Write failing tests for `extract_service_id`

- [ ] **Step 2.1: Create `tests/meta/test_service_id.py` with failing tests:**

```python
"""Unit tests for service_id extraction chain (T2-22)."""
from meta.service_id import extract_service_id

DEFAULT_CHAIN = ["service", "service.name", "app", "app.kubernetes.io/name", "job"]

def test_intentional_key_wins_over_infra():
labels = {"service": "payments", "app": "payments-prod-1"}
sid, src = extract_service_id(labels, DEFAULT_CHAIN)
assert sid == "payments"
assert src == "label:service"
...

ну и далее по TDD.
В плане даже команды запуска тестов и git add\git commit будут.

Детализация мягко говоря сильно отличается)

#ai