Sdd:contradiction

Contradiction checker (sdd:contradiction)

Determine Change (если $ARGUMENTS пуст)

Если $ARGUMENTS непуст — используй как PATH и переходи к следующему разделу.

Если $ARGUMENTS пуст:

Режим A — контекст очевиден. Если в текущем разговоре уже обсуждался конкретный чендж (например, только что выполнялся другой sdd-скилл или пользователь явно упоминал имя ченджа) — НЕ вызывай никаких инструментов. Через AskUserQuestion покажи список:

1. Продолжить с `` (наиболее вероятный)
2. Выбрать другой чендж

Если пользователь выбрал вариант 2 — переходи к режиму B.

Режим B — контекст неоднозначен. Если чендж из разговора определить нельзя — выполни через Bash tool:

git branch --show-current
git status --short
ls openspec/changes/

Сканируй openspec/changes/, ранжируй кандидатов по трём сигналам (убыв. приоритет):

1. Имя ветки совпадает с именем директории ченджа.
2. В openspec/changes// есть изменённые/untracked файлы по git status.
3. Директория существует и не архивирована (нет .sdd-state.yaml со stage: archived).

Через AskUserQuestion покажи нумерованный список до 7 кандидатов (отсортированных по убыванию релевантности, с пометкой «наиболее вероятный» у первого). Остальные скрыты с пометкой «ещё N».

Дождись выбора. Используй выбранный чендж как PATH = openspec/changes/.

SCOPE CONSTRAINT

Все правки выполняются исключительно внутри openspec/changes//. MUST NOT изменять файлы вне этой директории, включая skills/, .claude/, openspec/specs/.

Identity check (если PATH — change-директория)

Если PATH является change-директорией (содержит proposal.md и .sdd.yaml), перед основным анализом:

1. Получи текущий email через Bash tool:

``bash python3 "${CLAUDE_SKILL_DIR}/../scripts/identity.py" `` Если скрипт вернул exit ≠ 0 — выведи stderr и остановись.

1. Прочитай owner: из .sdd.yaml через:

``bash python3 "${CLAUDE_SKILL_DIR}/../scripts/_sdd_yaml.py" read "" ``

1. Если owner пуст или совпадает с email → продолжай молча.
2. Если owner != email → выведи warning:

⚠ Это change owner=, ты . Перезаписать на тебя? Через AskUserQuestion. При согласии: ``bash python3 "${CLAUDE_SKILL_DIR}/../scripts/_sdd_yaml.py" set-owner "" "" `` При отказе — остановись с сообщением «работа над чужим change'ем отклонена».

Если PATH — не change-директория — пропусти этот шаг молча.

Cross-spec preamble (если PATH — change-директория)

Если PATH является change-директорией (содержит proposal.md), перед основным анализом:

1. Найди contradiction.py в scripts/ рядом со скиллом: ${CLAUDE_SKILL_DIR}/scripts/contradiction.py
2. Вызови через Bash tool:

``bash python "${CLAUDE_SKILL_DIR}/scripts/contradiction.py" "" 2>&1 ``

1. Прочитай stdout. Он содержит:

• Секции --- Capability: () [] --- для каждой загруженной спеки:
• [PRIMARY/merges-into] — capability из .sdd.yaml.merges-into, найденная в index
• [PRIMARY/creates] — capability из .sdd.yaml.creates, уже в index (live)
• [PRIMARY/creates DRAFT] — capability из .sdd.yaml.creates, не в index (draft)
• без метки — background capability (весь остальной index)
• Секция --- ADJACENT Capabilities --- — capabilities из index, тематически смежные с change но незадекларированные; только listing, не включать в scope анализа
• Summary: total_discovered, total_loaded, draft_specs_loaded, primary_capabilities, merges_into_missing, adjacent_capabilities, skipped
• Warnings о missing files и missing merges-into capabilities

1. Включи загруженные PRIMARY и background спеки в scope анализа. PRIMARY-capabilities анализируй в первую очередь. ADJACENT — только информационный раздел, в анализ не включай.
2. В отчёте добавь строку после заголовка:

Analyzed: capabilities from index (или index.yaml not found если скрипт сообщил об этом).

1. Capabilities, пропущенные из-за missing files, перечисли в отдельной секции отчёта:

--- Skipped capabilities ---

Если PATH — не change-директория (файл, произвольная директория) — пропусти этот шаг молча.

---

Никакого внешнего кода, Python-модуля, curated-словаря или fixture-тестов нет. Всё делаешь ты, модель, в одном прогоне.

Input handling

Пользователь передаёт PATH — один или несколько пробел-разделённых путей (файлов или директорий). Каждый путь раскрывается в список файлов; наборы объединяются в единый scope проверки.

Если путь не существует — выведи ERROR: path not found: для каждого несуществующего пути и продолжи анализ по оставшимся (не останавливайся полностью). Если ни одного валидного пути нет — остановись.

После раскрытия всех путей определи режим по составу набора:

1. Файл (один файл, нет proposal.md) → читай только его, применяй in-file детекторы (numeric, reference, deontic, semantic, redundancy).
2. Change-директория (набор содержит proposal.md) → change-directory-режим: читай все четыре артефакта (proposal.md, design.md, tasks.md, specs/**/spec.md), ограничивая scope переданными файлами. Если в change-директории присутствует domain.md — включай его в scope наравне с opsx-артефактами; все тринадцать детекторов применяются к нему без исключений. Применяй все тринадцать детекторов.
3. Произвольная директория (без proposal.md в корне) → прочитай все текстовые файлы рекурсивно: *.md, *.sh, *.py, *.yaml, *.yml, *.json, *.txt, *.toml, *.ini, Makefile, Dockerfile.
4. Корень проекта (. или openspec/) → whole-project scan с поиском cross-change coupling; читай только файлы внутри PATH.

Детекторы, требующие конкретных артефактов (coverage, placement, spec-count, semantic-completeness, derivability, what-changes-coverage, decisions-coverage, completeness), запускаются только если соответствующие артефакты присутствуют в наборе; иначе — пропускаются с пометкой [detector: N/A — required artifacts not in scope] в Summary. Детектор completeness дополнительно вне change-directory-режима пропускается с пометкой [completeness: N/A — not a change-directory].

Граница анализа. Во всех режимах PATH — жёсткая граница. Ссылки на файлы вне PATH проверяй только на существование (reference-детектор); referenced файлы не читай и не включай в анализ.

Phase 1 — EXPAND (conditional)

Выполняй только если PATH — ранняя change-директория: proposal.md почти пустой ( design.md > proposal.md > tasks.md

Эвристика рекомендательная. Override по делу: если дубликат — Why-статистика или motivational narrative, SSOT может остаться в `proposal.md`. Пометь предложение как `heuristic`.

**Для каждой группы подготовь конкретный pointer-rewrite:**

- какой текст оставить в SSOT-файле дословно;
- какой короткий pointer подставить в остальные места: «см. `` → ».

Эти предложения будут представлены как `[warning] redundancy` в фазе VALIDATE, а сами предложенные новые pointer'ы пройдут через детектор `reference` там же — чтобы каскадные broken-pointers были видны сразу.

**Исключения из redundancy-детекции:**

- fenced-code-blocks с shebang-строкой (`#!/bin/bash`, `#!/usr/bin/env python`);
- YAML frontmatter (`---\n...\n---`);
- Markdown-разделители (`---`, `***`, `___`);
- чисто-пунктуационные строки;
- короткие cross-ref-подписи («см. D5», «Req X»).

## Phase 3 — VALIDATE

Применяй **тринадцать детекторов** в фиксированном порядке: `numeric` → `reference` → `deontic` → `semantic` → `redundancy` → `coverage` → `placement` → `spec-count` → `semantic-completeness` → `derivability` → `what-changes-coverage` → `decisions-coverage` → `completeness`. Результаты пусть копятся отдельно по детекторам — формат отчёта ниже требует сгруппированного вывода.

### 3.1 — numeric (hard, severity=error)

Находи утверждения с числами и устойчивым subject'ом:

- счётчики (количество однотипных сущностей: «N records», «K fields», «M items per group»);
- пороги, лимиты, таймауты, TTL («30 дней», «5 retries», `MAX_RETRIES=3`);
- номера портов, версии, коэффициенты.

Группируй по subject'у (нормализация контекста: «N items of type A» и «N items of type B» — разные subject'ы даже при одном числе, не смешивай). Если для одного subject'а в разных местах встречаются разные числа — флаг.

Формат issue: `:: [error] numeric: '' =  here vs  (at :)`.

### 3.2 — reference (hard, severity=error, 3 подстратегии)

Подстратегии — один класс `reference` с полем `sub_kind`:

1. **file** — упоминания файлов (`scripts/*.sh`, `manifest/*.md`, `.claude/*`, относительные пути). Проверяй существование на диске.
2. **make-target** — упоминания `make `. Если в корне проекта есть `Makefile`, проверяй наличие цели. Если `Makefile` нет — пропусти с warning в stderr, не флагай.
3. **pointer** — cross-doc ссылки вида «см. `` → >», «`.md:`». Резолви целевой файл и секцию. Проверяй, что секция / Requirement / параграф с таким именем есть в целевом файле.

**Exception — plan-artefacts.** Если файл явно упоминается в `tasks.md` текущего change как создаваемый этим change'ем (формулировки «создать», «добавить», «ввести файл X», «новый файл»), НЕ флагай его как missing, даже если физически отсутствует. Эвристика: присутствие пути в tasks.md + глагол-индикатор создания.

Формат issue: `:: [error] reference: '' —  [sub_kind=]`.

### 3.3 — deontic (hard, severity=error)

Для каждой **сущности** собирай все модальные утверждения:

- **positive markers**: `SHALL`, `MUST`, «обязан», «SHOULD», «MAY», «активно используется», «required», «SHALL вызывать», «SHALL содержать»;
- **negative markers**: `SHALL NOT`, `MUST NOT`, `SHOULD NOT`, «не вводится», «не регистрируется», «не должен», «запрещено», `deprecated`, «отклонено», «отказ», «not introduced», `~~Requirement~~` (strikethrough в заголовке Requirement).

Извлекай **subject** — имя сущности: quoted identifier (`` `scripts/foo.sh` ``, `"foo"`), Requirement-name, имя параметра/эндпоинта/таблицы/политики. Нормализуй: whitespace-collapse, lowercase ASCII, strip кавычек.

Группируй по canonical subject. Флаг, если в группе есть и positive, и negative.

**Exceptions:**

- **Scope-restrictor в одном предложении** («SHALL X только если Y», «SHALL NOT X без Y», «SHALL ... кроме Z») — это уточнение scope, не конфликт.
- **Scenario-уровень модалок** (`#### Scenario:` → `WHEN ... THEN ...`) парсится отдельно от Requirement-уровня. У Scenario свой WHEN-scope, модалки внутри не смешивай с Requirement-модалками.
- **Разные subject'ы** — `scripts/foo.sh SHALL ...` и `scripts/bar.sh SHALL NOT ...` — не конфликт.

Формат: `:: [error] deontic: ''  here vs  (at :)`.

### 3.4 — semantic (hard, severity=error)

Сам выцепляй **темы** из текста (не из внешнего словаря):

- пути файлов и директорий;
- политики (например, «triger — manual-only», «все репы — субмодули»);
- правила (формат записи, schema);
- идентификаторы (имена репозиториев, ветки, commit-ref);
- конфигурационные значения.

Для каждой темы собери все claim'ы из разных мест и сравни по смыслу (не по буквам). Нормализация:

- whitespace / case / trailing `/` / singular-plural — не флагай;
- форматирование (backticks, quotes) — не флагай;
- разные буквальные значения («manifest/repos.md» vs «manifest/submodules.yaml») — флагай.

**Polarity** определяй по контексту самой темы (вместе с деонтикой, но в semantic — про factual claim). Если одно место утверждает о теме, а другое отрицает или переопределяет — это semantic расхождение.

В отчёте обязательно перечисли выделенные темы в секции `Subjects covered by semantic detector` — для прозрачности покрытия, чтобы пользователь видел что ты проверял.

**User-provided ignore.** Если в том же обращении пользователь говорит «subject X — известный false positive» или «игнорируй » — повторно выдай отчёт без этого subject'а, не требуя перезапуска.

Формат: `:: [error] semantic: '' = '' here vs '' (at :)`.

### 3.5 — redundancy (soft, severity=warning)

Используй результаты фазы COMPRESS. Каждая группа дубликатов:

- выведи **все** локации (N записей для N мест),
- укажи **suggested SSOT** с пометкой `(heuristic, override as needed)`,
- добавь **pointer-rewrite suggestion**: «оставить полный текст в ``, в остальных — `см.  → `»,
- прогони предложенные новые pointer'ы через `reference` подстратегию `pointer`. Если какой-то из них после consolidation стал бы broken — добавь warning «after fixing this redundancy, pointer X might break at :».

**User override SSOT.** Если пользователь в том же обращении укажет другой SSOT («SSOT для этого блока — proposal.md, не design.md») — пересчитай pointer-rewrite относительно указанного SSOT и повторно валидируй новые pointer'ы. Без перезапуска.

Redundancy **не растит exit-код**. Это только warning.

Формат: `:: [warning] redundancy: '' duplicated in : (suggested SSOT: , heuristic)`.

### 3.6 — coverage (soft, severity=warning)

**Только в режиме change-директории.** В остальных режимах пропускай с пометкой `[coverage: N/A — required artifacts not in scope]` в Summary.

Алгоритм:
1. Прочитай `proposal.md` — секцию `### New Capabilities`. Собери список capabilities.
2. Прочитай все `specs/**/spec.md` — собери все `### Requirement:` блоки.
3. Для каждого Requirement и каждого capability проверь: есть ли в `tasks.md` хотя бы одна задача, в тексте которой упоминается имя Requirement / capability или ключевые слова его тела (совпадение по смыслу, не по байтам).
4. Непокрытые элементы → `[warning] coverage:` в Soft warnings.

Severity `warning` — несопоставленный Requirement не обязательно ошибка (может быть намеренно отложен). Coverage **не растит exit-код**.

Формат: `specs//spec.md:: [warning] coverage: 'Requirement: ' has no corresponding task in tasks.md`.
Capability: `proposal.md:: [warning] coverage: 'Capability: ' has no corresponding task in tasks.md`.

### 3.7 — placement (soft, severity=warning)

**Только в режиме change-директории.** В других режимах пропускай с пометкой `[placement: N/A — required artifacts not in scope]` в Summary.

Детектор проверяет, что каждый тип информации находится в артефакте, соответствующем его роли в OpenSpec-графе:

- `proposal.md` — «почему»: бизнес-контекст, мотивация, capabilities-list, impact.
- `design.md` — «как»: архитектурные решения, rationale, trade-offs, alternatives.
- `spec.md` — «что»: тестируемые контракты, Requirement-блоки, Scenario-блоки.
- `tasks.md` — «реализация»: конкретные шаги, чекбоксы, файлы-к-созданию.

Флагируй следующие паттерны с severity `warning`:

1. **Requirement-блок вне spec.md** — строка `### Requirement:` или `#### Requirement:` найдена в `proposal.md`, `design.md` или `tasks.md`.
2. **Implementation-step внутри spec.md** — чекбокс `- [ ]` / `- [x]` или нумерованный список в секции с заголовком, содержащим «task», «step», «implement», «шаг», «задача», найден в `spec.md`.
3. **Rationale-блок в spec.md без WHY-заголовка** — абзац с маркерами («потому что», «because», «rationale», «trade-off», «we chose», «решили», «альтернатива», «alternative») найден в `spec.md` и не вложен в явный `### Why`, `**Why:**` или `**Why ():**` заголовок.

Если блок невозможно однозначно классифицировать — выдавай warning с пометкой `ambiguous`.

Формат: `:: [warning] placement: `.

### 3.8 — spec-count (soft, severity=warning)

**Только в режиме change-директории.** В других режимах пропускай с пометкой `[spec-count: N/A — required artifacts not in scope]` в Summary.

Детектор проверяет три условия:

1. **Capability без спеки** — считать пункты в `### New Capabilities` в `proposal.md` и сравнивать с числом `specs/**/spec.md` файлов. Если capabilities > spec-файлов — флаг. Если `### New Capabilities` отсутствует или пуста — вывести `[spec-count: N/A — no structured capabilities list in proposal.md]` и пропустить п.1; п.2 и п.3 выполнять всегда.

2. **Задача без спеки** — для каждой задачи в `tasks.md` (строка с чекбоксом или нумерованным пунктом): проверить, содержит ли текст задачи имя, путь или ключевые слова хотя бы одного из `specs/**/spec.md`. Если нет — флаг.

3. **Спека-заглушка** — `specs/**/spec.md` содержит 0 `### R

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [Hedgehogues](https://github.com/Hedgehogues)
- **Source:** [Hedgehogues/awesome-claude](https://github.com/Hedgehogues/awesome-claude)
- **License:** MIT

Install and usage instructions live in the source repository linked above.