Feat говорит, что построить, не говоря как; stack говорит, как это делает технология. Эта страница пишет по одному и соединяет их через умения, которые одному нужны, а другой предоставляет.
Агент создаёт оба слота через `vibe init package`, задаёт их виды в [манифестах](../glossary/index.xml#manifest), пишет спецификацию feat, критерии приёмки и требование [возможности](../glossary/index.xml#capability), пишет описание stack, его соглашения и возможность, которую он предоставляет, и проверяет каждый. Когда проект позже ставит feat, резолвер ищет пакет, предоставляющий `ui:page-host`, среди stack-пакетов проекта; stack ему подходит, и двое сопоставляются, хотя ни один не называет другого.
Feat описывает, что фича делает для своего пользователя, в терминах, которые может реализовать любой stack: назначение, поведение, критерии приёмки, нужные данные, что происходит, когда что-то идёт не так. Он никогда не называет фреймворк. Его [манифест](../glossary/index.xml#manifest) объявляет умения, которые ему нужны от stack, как возможности, `namespace:name@constraint`, и больше ничего о технологии.
| Путь | Назначение |
| `vibevm/vibespecs/feats/<name>/SPEC.md` | что фича делает, для кого и зачем |
| `vibevm/vibespecs/feats/<name>/acceptance.md` | наблюдаемые критерии, которым должна отвечать сборка |
| `vibevm/vibespecs/feats/<name>/data-model.md`, `api.md`, `ui-flows.md`, `failure-modes.md` | те части, что применимы, по одной теме на файл |
В манифесте: `[requires] capabilities = ["ui:page-host@^1"]` и, для feat, которому вообще нужен stack, `[compatibility] requires_kinds = ["stack"]`.
Stack — технологический контекст: он говорит, как абстрактные умения, о которых просит feat, реализуются одним набором инструментов, и может привязать [фазы](../glossary/index.xml#phase) сборки и тестирования [жизненного цикла](../glossary/index.xml#lifecycle) к этому тулчейну. Его манифест объявляет, что он предоставляет, `[provides] capabilities = ["ui:page-host@1.0"]`, а документы спецификации описывают каждую предоставляемую возможность в отдельном файле, плюс соглашения, инструменты и выкладку.
| Путь | Назначение |
| `vibevm/vibespecs/stacks/<name>/STACK.md` | что такое этот stack и когда его выбирать |
| `vibevm/vibespecs/stacks/<name>/capabilities/<capability>.md` | по файлу на предоставляемое умение: как оно реализовано |
| `vibevm/vibespecs/stacks/<name>/conventions.md`, `tooling.md`, `deployment.md` | именование и раскладка, команды сборки и тестов, как сборка поставляется |
| `vibevm/vibespecs/boot/<name>.xml` | необязательный фрагмент, который показывает активный stack на старте сессии |
Stack может также привязать в манифесте [вклады](../glossary/index.xml#contribution) жизненного цикла, чтобы `vibe build` и `vibe test` в проекте-потребителе запускали тулчейн stack без дополнительной настройки.
Возможность — абстрактный интерфейс: пространство имён, двоеточие, имя и, необязательно, [ограничение версии](../glossary/index.xml#version-constraint). Feat требует; stack предоставляет; резолвер сопоставляет их при установке и отказывает проекту, чьим feat нужно умение, которого не предоставляет ни один установленный stack. Выбирайте имена по тому, что умение делает для фичи, а не по технологии: `ui:page-host`, `db:relational`, `auth:oauth-callback`.
Слово `stack` называет и бандл [семейства](../glossary/index.xml#family): пакет вида `stack`, в котором нет ничего, кроме точных пинов участников языкового семейства. В реестре и то и другое stack; различает их описание.
Критерии приёмки feat — то, что агент проверяет после сборки; пишите их как наблюдаемые [факты](../glossary/index.xml#fact), а не как пожелания.
Два feat, требующие одну возможность, могут быть удовлетворены одним stack; проект с несколькими stack помечает один как активный для сборки.