Мой воркспейс

Ты находишься в пустой папке. Разверни в ней базовый рабочий воркспейс для совместной работы человека и AI-агента.

Не ограничивайся описанием: создай все перечисленные каталоги и файлы, проверь результат, инициализируй git-репозиторий и сделай первый коммит.

Не записывай реальные секреты в создаваемые файлы. Используй только заглушки и документированные тестовые IP-адреса.

Все блоки с готовым содержимым файлов копируй дословно. Не сокращай их, не пересказывай, не объединяй строки и не меняй форматирование. После создания перечитай каждый файл и построчно сравни его с соответствующим блоком этой инструкции. Если нашёл расхождение, исправь файл до проверки и коммита.

## 1. Создай структуру

```text
.
├── CLAUDE.md
├── .gitignore
├── .claude/
│   └── skills/
│       └── ops-log/
│           └── SKILL.md
├── .vault/
│   ├── .gitkeep
│   └── inventory.yaml
├── projects/
├── infra/
│   ├── README.md
│   ├── servers/
│   ├── services/
│   └── people/
├── journal/
│   ├── README.md
│   └── YYYY-MM.md
├── playbooks/
│   └── README.md
├── scripts/
├── data/
│   └── .gitkeep
└── templates/
    ├── project-readme.md
    ├── project-brief.md
    ├── project-spec.md
    └── server-card.md
```

Вместо `YYYY-MM.md` используй текущий год и месяц системной даты.

Сохрани пустые каталоги `projects/`, `scripts/`, `infra/servers/`, `infra/services/`, `infra/people/`, `.vault/` и `data/` в git с помощью файлов `.gitkeep`. Содержимое `.vault/` и `data/`, кроме этих двух файлов `.gitkeep`, должно оставаться локальным.

## 2. Создай .gitignore

Запиши в `.gitignore`:

```gitignore
# Секреты и локальные доступы
.vault/*
!.vault/.gitkeep

# Выгрузки, отчёты и генерируемые данные
data/*
!data/.gitkeep

# Локальное окружение
.env
.env.*
!.env.example

# Системные файлы
.DS_Store
```

Проверь, что `.vault/inventory.yaml` действительно игнорируется git. Файл должен существовать локально, но не должен попасть в первый коммит.

## 3. Создай CLAUDE.md

Запиши следующее содержимое:

```markdown
# Рабочий воркспейс

## Назначение

Это единая точка входа для работы человека и AI-агента. Любую задачу сначала
пробуй решать через этот воркспейс, даже если она выглядит разовой.

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

## Структура

- `projects/` — активная работа; один проект живёт в `projects/<slug>/`.
- `infra/servers/` — карточки серверов: роль, сервисы, эксплуатация и история.
- `infra/services/` — карточки внешних сервисов и платформ.
- `infra/people/` — карта ответственности и рабочих контактов.
- `journal/` — хронология выполненных задач, один файл на месяц.
- `playbooks/` — повторяемые сценарии диагностики и регламентных работ.
- `.vault/` — локальные параметры доступа; содержимое не попадает в git,
  кроме `.gitkeep`.
- `scripts/` — переиспользуемая автоматизация.
- `data/` — выгрузки и генерируемые результаты; содержимое не попадает в git,
  кроме `.gitkeep`.
- `templates/` — шаблоны проектов и карточек.

## Соглашения

- Каждый проект создавай в `projects/<slug>/`.
- Скрипты общего назначения размещай в `scripts/`.
- Результаты выгрузок и временные отчёты размещай в `data/`.
- Не выдумывай факты, доступы, результаты команд и состояние систем.
- Перед изменением существующего объекта прочитай его документацию и историю.
- После изменения проверь результат способом, независимым от команды записи.

## Секреты

Хосты, реальные IP-адреса, пользователи и другие локальные параметры
подключения храни только в `.vault/inventory.yaml`. Пароли, приватные ключи,
токены и API-ключи держи в менеджере паролей, системном хранилище или secret
manager. В `.vault/inventory.yaml` записывай только ссылку на секрет.

В коммитимых файлах оставляй стабильную ссылку:

`vault: servers.<имя>`

или:

`vault: services.<имя>`

Карточка описывает, что находится в системе и как с ней работать. Vault
описывает, как получить доступ.

Никогда не добавляй содержимое `.vault/` в git, кроме пустого файла
`.vault/.gitkeep`. Перед коммитом проверяй staged-файлы на наличие секретов.

## Протокол закрытия задачи

Задача не считается завершённой без прохода скилла `ops-log`.
Вызывай его автоматически в конце каждой выполненной задачи, а не только
после слов «зафиксируй» или «запиши в журнал».

- журнал обновляется после задачи с проверяемым результатом;
- карточки `infra/`, vault и плейбуки обновляются, если были затронуты;
- если карточка или плейбук соврали, исправь их в момент обнаружения;
- поправку пользователя сохрани вместе с объяснением, почему она нужна
  и когда применяется;
- если одна поправка встретилась в третий раз независимо, предложи поднять
  её в это правило или в отдельный скилл;
- не коммить изменения без явной просьбы пользователя, кроме первоначального
  коммита при разворачивании этого воркспейса.

Для чисто разговорного ответа, в котором ничего не диагностировалось,
не создавалось и не изменялось, запись в журнале не нужна.

Первоначальное разворачивание пустого воркспейса не записывай в журнал:
это установка рабочей среды, а не выполненная рабочая задача.
```

## 4. Создай .claude/skills/ops-log/SKILL.md

Запиши:

```markdown
---
name: ops-log
description: Протокол закрытия задачи — фиксация результата в journal/, infra/, playbooks/ и .vault плюс шаг «уроки». Вызывай автоматически в конце КАЖДОЙ выполненной задачи, не только по явной просьбе «зафиксируй», «запиши в журнал», «добавь в базу знаний» или «оформи плейбук».
---

# ops-log — протокол закрытия задачи

Перенеси подтверждённые знания из текущей сессии в воркспейс: что делали,
где работали и чем закончилась задача.

Ничего не выдумывай. Если факта, команды или результата не было в сессии,
не добавляй его в документы.

Это обязательный финал каждой выполненной задачи. Для чисто разговорной
сессии, в которой ничего не менялось и не диагностировалось, фиксация не нужна.

## 1. Журнал

Добавь запись в `journal/YYYY-MM.md` по формату из `journal/README.md`.

- Если файла текущего месяца нет, создай его.
- Новую запись помещай сверху, сразу после заголовка месяца.
- Укажи дату и короткое название.
- В поле «Где» дай ссылки на затронутые карточки или проект.
- В поле «Что» уложи в 2–5 строк симптом или задачу, выполненные действия
  и проверенный результат.
- В поле «Плейбук» дай ссылку или поставь `—`.

Журнал обновляется после задачи с проверяемым результатом: если изменилось
состояние системы, закончилась диагностика или появилось знание для следующей
сессии. Ответ на вопрос и мелкая правка формулировки сами по себе записи
не требуют.

## 2. Карточки

Для каждого затронутого сервера, внешнего сервиса или человека:

- если карточка существует, добавь запись в раздел «История» и исправь
  устаревшие факты в остальных разделах;
- если карточки нет, создай её в `infra/servers/`, `infra/services/`
  или `infra/people/`;
- добавь новую карточку в соответствующую таблицу `infra/README.md`;
- связывай запись истории со свежей записью журнала.

Минимальная карточка сервера должна содержать роль, ссылку `vault:`,
состав сервисов, способ эксплуатации, проверки и историю.

## 3. Vault

Если появились новые параметры доступа — хост, реальный IP, пользователь, порт
или панель — добавь их в `.vault/inventory.yaml`. Для пароля, ключа или токена
сохрани только ссылку на менеджер секретов.

В коммитимых файлах используй только ссылку вида:

`vault: servers.<имя>`

или:

`vault: services.<имя>`

Не выводи секреты в журнал, карточки, плейбуки, сообщения о завершении
и историю git.

## 4. Плейбук

Если случай может повториться — диагностика, регламентная операция или уже
встречавшаяся ошибка — предложи создать либо обновить плейбук.

После согласия пользователя создай файл в подходящем подкаталоге
`playbooks/` по структуре:

1. симптом;
2. диагностика с конкретными командами;
3. трактовка результатов и развилки;
4. подтверждённая причина;
5. исправление;
6. проверка результата;
7. прецедент с датой и ссылкой на журнал.

Добавь ссылку на плейбук в `playbooks/README.md`, журнал и карточку объекта.

Для действительно одноразового случая достаточно журнала.

## 5. Уроки

Проверь два контура самоулучшения.

### Знания соврали

Если карточка или плейбук оказались неверны — например, устарела команда,
сменился порт, изменился путь или больше не существует сервис, — документ
должен быть исправлен в момент обнаружения.

Перед завершением убедись, что исправление внесено. Не оставляй известную
ошибку следующей сессии.

### Поправка пользователя

Если пользователь поправил способ работы:

- зафиксируй саму поправку;
- запиши, почему она нужна;
- укажи ситуации, в которых её применять;
- выбери подходящий приёмник: карточку, плейбук, README проекта или локальное
  правило.

Если та же поправка встретилась в третий раз независимо, предложи поднять
её в `CLAUDE.md` или отдельный скилл. Не превращай единичное предпочтение
в глобальное правило.

## 6. Отчёт

Покажи пользователю список изменённых файлов и одной строкой объясни каждую
правку.

Не делай коммит без явной просьбы пользователя. Исключение — первый коммит,
прямо требуемый инструкцией разворачивания воркспейса.
```

## 5. Создай journal/README.md

Запиши:

```markdown
# Журнал задач

Журнал — краткая хронология выполненной работы: что делали, где и чем
закончилась задача.

На каждый месяц используется файл `YYYY-MM.md`. Новые записи добавляются
сверху скиллом `ops-log`.

## Формат записи

## YYYY-MM-DD — короткое название задачи

- **Где:** ссылки на затронутые карточки, проекты или сервисы
- **Что:** 2–5 строк: симптом или задача → действия → проверенный результат
- **Плейбук:** ссылка на повторяемый сценарий или «—»

Не помещай в журнал пароли, токены, приватные ключи, реальные закрытые
адреса и другие секреты. Для доступов используй только `vault:`-ссылки.
```

Создай файл текущего месяца `journal/YYYY-MM.md`:

```markdown
# Журнал — YYYY-MM
```

Подставь фактический текущий год и месяц. Не добавляй выдуманных задач.

## 6. Создай playbooks/README.md

Запиши:

```markdown
# Плейбуки

Плейбуки — повторяемые сценарии диагностики и регламентных работ.

Создавай плейбук, если случай может повториться или если ошибка уже возникала.
Одноразовую работу фиксируй только в журнале.

## Структура плейбука

# Название сценария

## Симптом

Что наблюдает человек или система. Укажи проверяемые признаки.

## Перед началом

Какие нужны права, ссылки `vault:` и условия безопасности.

## Диагностика

Конкретные команды в порядке выполнения. Для каждой проверки объясни:

- какой результат считается нормой;
- что означает отклонение;
- к какому следующему шагу перейти.

## Причина

Подтверждённая причина. Не перечисляй неподтверждённые догадки как факт.

## Исправление

Пошаговое изменение с командами, границами полномочий и способом отката.

## Проверка

Как независимо убедиться, что проблема устранена и побочных эффектов нет.

## Прецеденты

- YYYY-MM-DD — краткий итог и ссылка на запись журнала.

## Индекс

### Диагностика

Пока пусто.

### Регламентные работы

Пока пусто.
```

## 7. Создай infra/README.md

Запиши:

```markdown
# Инфраструктура

`infra/` — карта серверов, внешних сервисов и ответственности: куда агент
идёт, что там находится, как с этим работать и что происходило раньше.

Секреты хранятся только в `.vault/inventory.yaml`. Карточки ссылаются
на них ключом `vault: <раздел>.<имя>`.

## Слои

- `infra/servers/` — машины и среды: роль, сервисы, деплой, зависимости,
  проверки и история.
- `infra/services/` — облака, DNS, панели, SaaS и другие внешние сервисы.
- `infra/people/` — зоны ответственности и рабочие точки контакта.
- `journal/` — хронология задач.
- `playbooks/` — повторяемые сценарии.

## Серверы

| Карточка | Назначение | Vault |
|---|---|---|

## Внешние сервисы

| Карточка | Назначение | Vault |
|---|---|---|

## Люди и зоны ответственности

| Карточка | Зона ответственности | Контакт |
|---|---|---|
```

## 8. Создай шаблон карточки сервера

Запиши в `templates/server-card.md`:

```markdown
# {{Название сервера}}

- **Роль:** {{для чего нужна машина}}
- **Среда:** {{production, staging, development или другая}}
- **Доступ:** `vault: servers.{{ключ}}`
- **Ответственный:** {{ссылка на карточку в infra/people или «не определён»}}

## Что работает

| Компонент | Назначение | Как запущен |
|---|---|---|
| {{сервис}} | {{роль}} | {{systemd, Docker, Kubernetes, вручную}} |

## Эксплуатация

- **Деплой:** {{проверенная последовательность или ссылка на плейбук}}
- **Логи:** {{пути или команды без секретов}}
- **Конфигурация:** {{пути или источник конфигурации}}
- **Зависимости:** {{другие серверы и внешние сервисы}}

## Проверки

Безопасные команды проверки состояния. Опиши ожидаемый результат каждой.

## Особенности и ограничения

- {{что легко сделать неправильно}}
- {{что требует отдельного согласования}}
- {{какие действия опасны или необратимы}}

## Связанные плейбуки

- Пока нет.

## История

- YYYY-MM-DD — карточка создана.
```

При создании реальной карточки не оставляй выдуманную строку истории:
подставь настоящую дату и причину появления карточки.

## 9. Создай .vault/inventory.yaml

Файл должен существовать локально, но оставаться исключённым из git.

Запиши в него только заготовку с комментариями и тестовыми значениями:

```yaml
# Этот файл содержит локальные параметры подключения и ссылки на секреты.
# Он исключён из git. Не копируй его значения в коммитимые документы.
# Пароли, приватные ключи и токены храни в менеджере секретов, не здесь.
#
# В карточках используй ссылки:
#   vault: servers.billing_prod
#   vault: services.cloud_provider

servers:
  billing_prod:
    host: 203.0.113.10
    user: deploy
    credentials_ref: "password-manager://infrastructure/billing-prod"
    panel: https://panel.example.com
    notes: "пример: доступ через бастион, порт нестандартный"

  ci_runner:
    host: 203.0.113.20
    auth: ssh-key
    credentials_ref: "system-keychain://ssh/ci-runner"

services:
  cloud_provider:
    account: team@example.com
    credentials_ref: "secret-manager://cloud/provider-api"

sheets:
  planning_2026: https://docs.google.com/spreadsheets/d/EXAMPLE

own_ips:
  vpn_exit: 198.51.100.5  # пример: собственный IP для сверки при аудитах
```

Не заменяй тестовые значения реальными параметрами подключения во время
первоначального разворачивания.

## 10. Создай шаблоны проекта

Запиши в `templates/project-readme.md`:

```markdown
# {{Название проекта}}

{{Одно-два предложения: что это за проект и зачем он нужен}}

- `brief.md` — исходная задача, цели и контекст.
- `spec.md` — спецификация реализации.
- `scripts/` — рабочие скрипты проекта.
- результаты выгрузок — в `data/` корня воркспейса.

## Состав

{{По мере появления перечисли дополнительные каталоги и их назначение}}

## Запуск

{{Требования и проверенные команды запуска}}

## Проверка

{{Как убедиться, что результат корректен}}

## Секреты

Доступы хранятся в `.vault/inventory.yaml`. Здесь используются только
ссылки вида `vault: services.<имя>`.
```

Запиши в `templates/project-brief.md`:

```markdown
# {{Название проекта}}

## Задача

{{Что нужно сделать и зачем}}

## Цели

- [ ] {{Измеримая цель 1}}
- [ ] {{Измеримая цель 2}}

## Контекст

- **Дедлайн:** {{дата или «не задан»}}
- **Стейкхолдеры:** {{кто заинтересован}}
- **Ограничения:** {{что важно учесть}}
- **Зависимости:** {{системы, люди и решения}}

## Результат

{{Как выглядит проверяемый успех}}

## Не входит в задачу

- {{Явная граница проекта}}
```

Запиши в `templates/project-spec.md`:

```markdown
# Спецификация: {{Название проекта}}

## Обзор

{{Что именно реализуется}}

## Требования

- {{Требование 1}}
- {{Требование 2}}

## Входные данные

{{Источники, форматы и ограничения}}

## Реализация

{{Архитектура, алгоритмы, структуры и ключевые решения}}

## Выходные данные

{{Формат результата и место сохранения}}

## Ошибки и граничные случаи

- {{Сценарий и ожидаемое поведение}}

## Проверка

- [ ] {{Проверка результата}}
- [ ] {{Проверка отсутствия побочных эффектов}}

## Откат

{{Как безопасно отменить изменение, если это применимо}}
```

## 11. Проверь структуру и безопасность

Перед коммитом:

1. Выведи дерево созданных файлов.
2. Проверь, что существует файл журнала текущего месяца.
3. Проверь, что `.vault/inventory.yaml` существует.
4. Создай временный файл `data/ignore-probe`, проверь через `git check-ignore -v`, что `.vault/inventory.yaml` и этот файл игнорируются, затем удали пробный файл.
5. Убедись, что `.vault/inventory.yaml` отсутствует среди staged-файлов.
6. Проверь, что все Markdown-файлы непустые.
7. Просмотри `git diff --cached --name-only` и `git diff --cached`. Ищи пароли, токены, приватные ключи, реальные закрытые адреса и файлы окружения. Если в системе установлен gitleaks, дополнительно запусти проверку staged-изменений с редактированием найденных значений. Не выводи возможные секреты в итоговый ответ.
8. Не добавляй в репозиторий локальные системные файлы.
9. Убедись, что созданные файлы совпадают с блоками инструкции и не были сокращены или перефразированы.

Если обнаружишь проблему, исправь её до коммита.

## 12. Инициализируй git и сделай первый коммит

Выполни:

```bash
git init
git add .
git status --short
git diff --cached --check
git config --get user.name
git config --get user.email >/dev/null
git commit -m "Initialize AI workspace"
```

Если коммит невозможен только из-за отсутствующих `user.name` или `user.email`, не придумывай идентичность человека и не меняй глобальную конфигурацию. Попроси пользователя указать значения, настрой их локально для этого репозитория и затем заверши первый коммит.

Если имя и email уже настроены, перед коммитом покажи имя автора и подтверди, что email задан, не выводя сам адрес. Не меняй существующую идентичность без просьбы.

После коммита ещё раз проверь:

```bash
git status --short
git ls-files
```

Рабочее дерево должно быть чистым. `.vault/inventory.yaml` и локальное содержимое `data/` не должны присутствовать в `git ls-files`. Файлы `.vault/.gitkeep` и `data/.gitkeep`, наоборот, должны присутствовать: благодаря им оба каталога восстановятся после `git clone`.

## 13. Покажи памятку человеку

После успешного разворачивания выведи краткий итог: какие каталоги созданы, какой файл журнала открыт для текущего месяца и какой hash получил первый коммит.

Затем покажи эту памятку:

### Первая неделя с воркспейсом

1. Решайте через него каждую рабочую задачу, даже если она кажется разовой.
2. В конце задачи проверяйте, что агент выполнил `ops-log`. Если забыл — прямо потребуйте пройти протокол закрытия.
3. Если карточка или плейбук соврали, исправляйте документ сразу, в той же задаче.
4. Локальные параметры подключения записывайте в `.vault/inventory.yaml`, а пароли, ключи и токены — в менеджер секретов. В остальных файлах оставляйте только `vault:`-ссылки.
5. Не создавайте плейбук ради количества. Создавайте его, когда сценарий действительно можно повторить.
6. В конце недели просмотрите журнал: из повторяющихся задач выберите первый сценарий для автоматизации или нового плейбука.