Подключение к проекту DWE

Вы только что склонировали репозиторий, в корне которого лежит workspace.yml, а README предлагает «запустить dwe». Это руководство объясняет, что делать дальше, что сообщает каждая из первых команд и какое состояние DWE оставляет на диске по ходу дела.

Требования

Сам dwe — это один бинарь; локальный стек, которым он управляет, основан на Docker. Перед первым запуском убедитесь:

Бинарь dwe доступен в PATH — dwe --version выводит строку с версией.
Docker-демон доступен — docker info отрабатывает без ошибки.
В корне репозитория есть workspace.yml (маркер проекта).
Если проект хранит в репозитории зашифрованные секреты (ключ secrets.recipient в workspace.yml), вам нужен ещё и приватный age-identity проекта. Попросите его у коллеги — он отдаёт его командой dwe secrets key export. dwe secrets status показывает, может ли эта машина уже читать зашифрованные значения.

Если что-то из этого не так, dwe validate точно скажет, чего не хватает. Иначе можно читать дальше.

Проверка после клонирования

В корне проекта выполните:

dwe validate

dwe validate объединяет все статические проверки: env-пробы (docker-демон, docker-бинарь, git, шелл, порты), схему конфига (каждый YAML под workspace/), переводы и заданные проектом preflight-проверки. Зелёный прогон означает, что проект внутренне согласован, а ваша машина удовлетворяет его базовым требованиям.

Если нужна краткая обзорная сводка, запустите dwe без аргументов — он выведет шапку проекта и текущий статус, ничего при этом не выполняя. Полное описание возможностей валидации и модели severity — в ../reference/config/validate.md.

Первый деплой

Пайплайн деплоя — это то, что превращает свежесклонированный репозиторий в работающий стек. В корне проекта:

dwe deploy

Что происходит, по порядку:

Онбординг ключа (только если у проекта есть зашифрованные секреты, а на этой машине нет identity для них). В терминале dwe deploy предлагает принять ключ раньше всего остального; при согласии открывается скрытый ввод, identity сохраняется в ~/.config/dwe/keys/<recipient>.key, и деплой продолжается в том же вызове. Отказ завершает команду сразу же, с подсказкой, что делать. Запуск без терминала, с --output json или под DWE_NONINTERACTIVE=1 предложение пропускает целиком, и деплой тогда останавливается на preflight-гейте secrets.unresolved, который называет нечитаемые значения. dwe run и dwe restart делают то же предложение. См. Зашифрованные секреты.
Мастер первичной настройки (только при первом запуске). Проект может объявить промты в workspace/setup.yml — конфликты портов, выбор опциональных сервисов, лицензионные ключи, всё, что мейнтейнер пометил как машинно-локальное. Ваши ответы попадают в workspace/local.yml (в gitignore).
Preflight. Те же проверки validate работают как ворота; падения прерывают здесь, а не посреди деплоя.
Шаги деплоя. Проектный workspace/deploy.yml (и per-service deploy.yml) выполняются по порядку — сборка образов, подтягивание зависимостей, сидинг баз, генерация артефактов template-паков (IDE-конфиг, AGENTS.md, gitignored-хелперы).
Запись в журнал. DWE сохраняет результат деплоя и config_hash в .dwe/deploy/state.yml, чтобы последующие деплои могли пропускать шаги, которые не изменились.

Чтобы посмотреть план без выполнения — dwe deploy plan. Чтобы изучить журнал после прогона — dwe deploy state show.

Справочник: ../reference/config/setup.md, ../reference/config/deploy/index.md, ../reference/concepts/getting-started.md.

Дашборд `info`

dwe info

dwe info — это печатаемая «обложка» проекта. Она показывает шапку (брендированную через workspace/styles.yml), URL-ы и host-алиасы для каждого включённого сервиса, плюс секции, которые мейнтейнер добавил в workspace/info.yml — креды, ссылки на внутренние тулы, «где найти X» и т.п.

URL-ы и хосты берутся из двух источников: явные записи в info.yml и auto-блоки (type: auto-urls / type: auto-hosts), которые разворачиваются из ports: / hosts: каждого сервиса. Если вы переназначите порт в workspace/local.yml, дашборд отразит это на следующем рендере.

Справочник: ../reference/config/info.md, ../reference/config/styles.md.

Запуск стека

После успешного деплоя контейнеры не обязательно запущены — задача deploy в том, чтобы привести проект к known-good состоянию на диске, а не поднять сервисы. Чтобы поднять стек:

dwe run

Команда поднимает все включённые сервисы через Docker Compose. dwe status показывает, что запущено, что упало и общее здоровье стека. dwe logs <service> следит за логами одного сервиса (Ctrl-C выходит; стек продолжает работать).

Остановить всё — dwe stop. Перезапустить — dwe restart.

См. daily-workflow.md для полного набора повседневных команд.

Что теперь лежит на диске

Первый деплой создаёт несколько gitignored-каталогов в корне проекта:

Путь	Владелец	Назначение
`.dwe/`	DWE	Журнал деплоя, lock-файлы проекта, кэш промта, внутренние состояния. Можно удалять; DWE пересоздаст при следующем запуске.
`snapshots/`	DWE	Снапшоты, созданные через `dwe snapshot create`. Пусто на свежем проекте.
`backups/`	Вы / команды проекта	Дампы БД и прочее, создаваемые во время разработки.
`workspace/local.yml`	Вы	Машинно-локальные оверрайды (порты, хосты, набор включённых сервисов). Пишется мастером первичной настройки и командами `dwe services enable/disable`.

Stateful-данные сервисов (БД, кэши, очереди) живут в именованных томах Docker, а не в папке в корне проекта. Это ваши данные — удалять с осторожностью (см. docker volume ls / dwe reset).

Всё под workspace/, кроме local.yml, лежит в git и шарится с командой. Всё остальное из таблицы остаётся локально на машине.

Что дальше

daily-workflow.md — команды, к которым вы будете обращаться каждый день (статус, логи, шелл, проектные команды).
troubleshooting.md — куда смотреть, когда что-то перестало работать.
switching-tasks-with-snapshots.md — поставить фичу на паузу посреди работы, переключиться на хотфикс и вернуться.