@jakerdy/agentica 0.0.2 → 0.0.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +84 -51
- package/dist/cli.js +3 -3
- package/globals/use-agentica.md +6 -3
- package/package.json +6 -4
- package/prompts/commit.prompt.md +134 -0
- package/prompts/init.prompt.md +4 -3
- package/prompts/release.prompt.md +127 -0
- package/stacks/python/cli/structure.md +1 -0
- package/stacks/python/gui/structure.md +1 -0
- package/stacks/python/lib/structure.md +1 -0
- package/stacks/python/monorepo/structure.md +1 -0
- package/stacks/typescript/cli/structure.md +1 -0
- package/stacks/typescript/lib/structure.md +1 -0
- package/stacks/typescript/monorepo/structure.md +1 -0
- package/stacks/typescript/server/structure.md +1 -0
- package/stacks/typescript/spa/structure.md +1 -0
- package/templates/release/REL-0000 - Release Name.md +81 -0
package/README.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Agentica
|
|
2
2
|
|
|
3
|
-
[](https://github.com/jakerdy/agentica/releases/tag/v0.0.4)
|
|
4
4
|
[](LICENSE)
|
|
5
5
|
[](https://bun.sh)
|
|
6
6
|
|
|
@@ -13,26 +13,23 @@
|
|
|
13
13
|
|
|
14
14
|
## Prerequisites
|
|
15
15
|
|
|
16
|
-
- VSCode 1.109.0+
|
|
16
|
+
- [VSCode](https://code.visualstudio.com/) 1.109.0+
|
|
17
17
|
- GitHub Copilot
|
|
18
|
-
- Bun 1.3+
|
|
19
|
-
- Context7 (`Upstash.context7-mcp`) — опционально
|
|
18
|
+
- [Bun](https://bun.com/docs/installation) 1.3+ или [Node.js](https://nodejs.org/en/download) 18+ (для запуска CLI)
|
|
19
|
+
- Расширение Context7 (`Upstash.context7-mcp`) — опционально
|
|
20
20
|
|
|
21
21
|
## Quick Start
|
|
22
22
|
|
|
23
23
|
```bash
|
|
24
|
-
#
|
|
25
|
-
|
|
24
|
+
# Запускаем без установки
|
|
25
|
+
bunx @jakerdy/agentica init typescript/cli MyProject
|
|
26
26
|
|
|
27
|
-
#
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
# Открытие в VSCode
|
|
31
|
-
cd MyProject
|
|
32
|
-
code .
|
|
27
|
+
# Открываем в VSCode
|
|
28
|
+
cd MyProject && code .
|
|
33
29
|
```
|
|
34
30
|
После `init` Agentica автоматически:
|
|
35
31
|
- копирует в проект `.agentica/prompts`, `.agentica/templates` и `.agentica/skills`;
|
|
32
|
+
- создаёт директории спецификаций `.agentica/architecture`, `.agentica/changes`, `.agentica/features`, `.agentica/release`;
|
|
36
33
|
- обновляет `.vscode/settings.json`, добавляя пути в `chat.promptFilesLocations` и `chat.agentSkillsLocations`.
|
|
37
34
|
- добавит context7 в рекомендованные расширения, чтобы агенты сами могли искать документацию по библиотекам
|
|
38
35
|
|
|
@@ -47,6 +44,35 @@ code .
|
|
|
47
44
|
- Прочие важные детали
|
|
48
45
|
```
|
|
49
46
|
|
|
47
|
+
## CLI
|
|
48
|
+
|
|
49
|
+
Чтобы было проще интегрировать Agentica в ваш проект, был создан небольшой, но удобный CLI.
|
|
50
|
+
|
|
51
|
+
Agentica CLI поддерживает два формата запуска `init`:
|
|
52
|
+
- **Позиционный (основной):** `agentica init <stack> [targetPath]`
|
|
53
|
+
- **Через опции (совместимость):** `agentica init --stack <type> [--out <path>]`
|
|
54
|
+
|
|
55
|
+
### Основные команды
|
|
56
|
+
|
|
57
|
+
```bash
|
|
58
|
+
# Инициализация Agentica в текущей папке
|
|
59
|
+
agentica init typescript/cli
|
|
60
|
+
|
|
61
|
+
# Инициализация с созданием новой папки проекта
|
|
62
|
+
agentica init typescript/spa MyProject
|
|
63
|
+
|
|
64
|
+
# То же через опции (режим совместимости)
|
|
65
|
+
agentica init --stack typescript/spa --out MyProject
|
|
66
|
+
|
|
67
|
+
# Показать доступные шаблоны стеков
|
|
68
|
+
agentica stacks
|
|
69
|
+
|
|
70
|
+
# Справка по CLI
|
|
71
|
+
agentica --help
|
|
72
|
+
agentica init --help
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
|
|
50
76
|
## Мотивация
|
|
51
77
|
|
|
52
78
|
Agentica был создан в ходе мучительного поиска "идеального" инструмента для работы с агентными системами.
|
|
@@ -78,9 +104,9 @@ Agentica - это конструктор таких спек. Она запол
|
|
|
78
104
|
|
|
79
105
|
## Философия подхода
|
|
80
106
|
|
|
81
|
-
### 0. Вся ответственность за принятые решения лежит на
|
|
107
|
+
### 0. Вся ответственность за принятые решения лежит на вас
|
|
82
108
|
|
|
83
|
-
Прелесть агентов заключается в том, что они мультиплицируют
|
|
109
|
+
Прелесть агентов заключается в том, что они мультиплицируют ваши возможности по написанию кода в разы, а то и в десятки раз. Но не весь тот код, что написал агент, следует сразу лить в прод.
|
|
84
110
|
|
|
85
111
|
В идеале, вся та работа по "продумыванию" проекта должна быть сделана человеком. И только после того, как человек удостоверился в том что:
|
|
86
112
|
- Все структуры данных и интерфейсы правильные
|
|
@@ -134,8 +160,8 @@ Agentica строго разделяет уровни ответственнос
|
|
|
134
160
|
```text
|
|
135
161
|
.
|
|
136
162
|
├── .agentica/ # GLOBAL SCOPE (Конфигурация и общие знания)
|
|
137
|
-
│ ├── templates/ # Шаблоны (feature, arch, change)
|
|
138
|
-
│ ├── prompts/ # Промпты (init, create, implement...)
|
|
163
|
+
│ ├── templates/ # Шаблоны (feature, arch, change, release)
|
|
164
|
+
│ ├── prompts/ # Промпты (init, create, implement, commit, release...)
|
|
139
165
|
│ ├── skills/ # Skills для Copilot Agent (например frontend-design)
|
|
140
166
|
│ ├── product.md # Глобальный продукт
|
|
141
167
|
│ ├── structure.md # Структура репозитория
|
|
@@ -147,6 +173,7 @@ Agentica строго разделяет уровни ответственнос
|
|
|
147
173
|
│ │ │ ├── architecture/ # AR-XXXX (Архитектурные решения)
|
|
148
174
|
│ │ │ ├── changes/ # CH-XXXX (Изменения существующего)
|
|
149
175
|
│ │ │ ├── features/ # FT-XXXX (Новые фичи)
|
|
176
|
+
│ │ │ ├── release/ # REL-XXXX (Подготовка и выпуск релизов)
|
|
150
177
|
│ │ │ ├── product.md # Контекст пакета
|
|
151
178
|
│ │ │ ├── structure.md # Структура пакета
|
|
152
179
|
│ │ │ ├── tech.md # Стек пакета
|
|
@@ -163,18 +190,20 @@ Agentica строго разделяет уровни ответственнос
|
|
|
163
190
|
|
|
164
191
|
Все команды вызываются через `/agentica.<command>`. Аргументы опциональны - агент постарается вывести их из контекста, но явное указание надежнее.
|
|
165
192
|
|
|
166
|
-
| Команда | Аргументы
|
|
167
|
-
| :---------- |
|
|
168
|
-
| `init` | `--lang`,
|
|
169
|
-
| `architect` | `--name`
|
|
170
|
-
| `reverse` | `--name`
|
|
171
|
-
| `create` | `--name`
|
|
172
|
-
| `change` | `--name`
|
|
173
|
-
| `tasks` | `--id`
|
|
174
|
-
| `implement` | `--id`
|
|
175
|
-
| `validate` | `--id`
|
|
176
|
-
| `
|
|
177
|
-
| `
|
|
193
|
+
| Команда | Аргументы | Назначение |
|
|
194
|
+
| :---------- | :-------------- | :---------------------------------------------------- |
|
|
195
|
+
| `init` | `--lang`, | Инициализация и настройка проекта |
|
|
196
|
+
| `architect` | `--name` | Архитектурная спецификация (`AR-XXXX`) |
|
|
197
|
+
| `reverse` | `--name` | Reverse Engineering по существующему коду (`AR-XXXX`) |
|
|
198
|
+
| `create` | `--name` | Спецификация новой фичи (`FT-XXXX`) |
|
|
199
|
+
| `change` | `--name` | Спецификация изменений (`CH-XXXX`) |
|
|
200
|
+
| `tasks` | `--id` | Декомпозиция спеки на задачи |
|
|
201
|
+
| `implement` | `--id` | Написание кода по задачам |
|
|
202
|
+
| `validate` | `--id` | Семантическая и техническая приемка |
|
|
203
|
+
| `commit` | `--skip-checks` | Коммит с проверками безопасности |
|
|
204
|
+
| `release` | `--type` | Подготовка релиза (`REL-XXXX`) и черновика changelog |
|
|
205
|
+
| `readme` | `--id` | Генерация документации |
|
|
206
|
+
| `refactor` | --- | Улучшение кода без смены API |
|
|
178
207
|
|
|
179
208
|
---
|
|
180
209
|
|
|
@@ -193,8 +222,10 @@ Agentica строго разделяет уровни ответственнос
|
|
|
193
222
|
|
|
194
223
|
```text
|
|
195
224
|
/agentica.init --lang TypeScript
|
|
196
|
-
|
|
197
|
-
|
|
225
|
+
|
|
226
|
+
Проект посвящён разработке CLI-инструментов для управления задачами. Основные функции включают создание, обновление и удаление задач, а также интеграцию с календарём. Важно обеспечить поддержку плагинов и расширений в будущем.
|
|
227
|
+
|
|
228
|
+
Оснвной стек: TypeScript, Node.js, Commander.js для CLI
|
|
198
229
|
```
|
|
199
230
|
*Что происходит:* Агент создает структуру `.agentica/`, заполняет `tech.md` и `structure.md` под ваш запрос, готовит промпты.
|
|
200
231
|
|
|
@@ -254,38 +285,40 @@ Agentica строго разделяет уровни ответственнос
|
|
|
254
285
|
Восстанови карту модулей, просканируй entry-points.
|
|
255
286
|
Найди циклические зависимости и узкие места в текущей реализации.
|
|
256
287
|
```
|
|
257
|
-
*Агент просканирует кодовую базу и создаст описание системы "As-Is"
|
|
288
|
+
*Агент просканирует кодовую базу и создаст описание системы "As-Is" в отдельном `AR-XXXX` документе, подсветив зоны риска и архитектурный долг.*
|
|
258
289
|
|
|
259
290
|
### 6. Документация
|
|
291
|
+
|
|
292
|
+
Когда работа над фичей закончена, и нужно быстро сгенерировать понятную документацию:
|
|
293
|
+
|
|
260
294
|
```text
|
|
261
295
|
/agentica.readme --id FT-0012
|
|
262
|
-
Сделай короткую доку для разработчиков с
|
|
296
|
+
Сделай короткую доку для разработчиков с примерами и описанием архитектуры нового решения.
|
|
263
297
|
```
|
|
264
298
|
|
|
265
|
-
|
|
299
|
+
### 7. Коммит "по богатому"
|
|
266
300
|
|
|
267
|
-
|
|
301
|
+
Используйте, когда нужно автоматически собрать staged-изменения, проверить их на мусор/секреты и создать качественное сообщение коммита.
|
|
268
302
|
|
|
269
|
-
|
|
270
|
-
-
|
|
271
|
-
-
|
|
303
|
+
Или просто используйте его всегда, когда собираетесь коммитить. Это просто, довольно быстро, а плюсы огромныe:
|
|
304
|
+
- Детальные сообщения которые муторно и лениво писать руками
|
|
305
|
+
- Гарантия, что в коммит не попадет мусор или секреты
|
|
306
|
+
- На основе истории можно будет делать качественные changelog'и и релизы, а не "misc updates" и "fixes"
|
|
272
307
|
|
|
273
|
-
|
|
308
|
+
```text
|
|
309
|
+
/agentica.commit
|
|
310
|
+
Подготовь commit для текущих изменений.
|
|
311
|
+
```
|
|
312
|
+
*Агент добавит изменения в stage, предупредит о потенциальных артефактах (`.exe`, `.dll`, `.tgz` и т.п.), предложит обновить `.gitignore`, сформирует сообщение в формате `<change_type>: <Short Change Description>` + детальное описание и выполнит `git commit`.*
|
|
274
313
|
|
|
275
|
-
|
|
276
|
-
# Инициализация Agentica в текущей папке
|
|
277
|
-
agentica init typescript/cli
|
|
314
|
+
### 8. Подготовка релиза
|
|
278
315
|
|
|
279
|
-
|
|
280
|
-
agentica init typescript/spa MyProject
|
|
316
|
+
Используйте, когда нужно пройти предрелизный аудит, собрать changelog из коммитов и подготовить план публикации.
|
|
281
317
|
|
|
282
|
-
|
|
283
|
-
agentica
|
|
318
|
+
```text
|
|
319
|
+
/agentica.release --type minor
|
|
320
|
+
Собери релиз для текущего состояния main и подготовь команды публикации.
|
|
321
|
+
```
|
|
322
|
+
*Агент проверит ветку (`main/master`), рассчитает новую версию (patch/minor/major), соберёт черновик changelog с последнего тега, пройдёт предрелизный checklist и создаст `REL-XXXX` документ.*
|
|
284
323
|
|
|
285
|
-
# Показать доступные шаблоны стеков
|
|
286
|
-
agentica stacks
|
|
287
324
|
|
|
288
|
-
# Справка по CLI
|
|
289
|
-
agentica --help
|
|
290
|
-
agentica init --help
|
|
291
|
-
```
|
package/dist/cli.js
CHANGED
|
@@ -32,14 +32,14 @@ Expecting one of '${J.join("', '")}'`);let Z=`${q}Help`;return this.on(Z,($)=>{l
|
|
|
32
32
|
|
|
33
33
|
---
|
|
34
34
|
|
|
35
|
-
`,Tz="globals",jz="anti-spaghetti.md",Nz="use-agentica.md";function hq(q,z,J){let Z=E(z,".agentica"),$=E(Z,Vz),Q=E(Z,Rz);if(D($))Lz($,Q);let X=E(q,Tz),Y=`lang-${J}.md`,U=o(E(X,Y),"utf-8"),B=o(E(X,jz),"utf-8"),H=o(E(X,Nz),"utf-8"),G=[U,B,H].join(Pz);Mz($,G,"utf-8")}var __dirname="E:\\Dev\\2026-02-15 - Agentica\\src\\commands",Dz=".agentica",uq="prompts",gq="templates",mq="skills",Ez="stacks",Fz="status.md",dq=1,wz=["prompts","templates","architecture","changes","features"],Sz=["product.md","structure.md","tech.md"];async function lq(q){console.log(W.blue(`
|
|
35
|
+
`,Tz="globals",jz="anti-spaghetti.md",Nz="use-agentica.md";function hq(q,z,J){let Z=E(z,".agentica"),$=E(Z,Vz),Q=E(Z,Rz);if(D($))Lz($,Q);let X=E(q,Tz),Y=`lang-${J}.md`,U=o(E(X,Y),"utf-8"),B=o(E(X,jz),"utf-8"),H=o(E(X,Nz),"utf-8"),G=[U,B,H].join(Pz);Mz($,G,"utf-8")}var __dirname="E:\\Dev\\2026-02-15 - Agentica\\src\\commands",Dz=".agentica",uq="prompts",gq="templates",mq="skills",Ez="stacks",Fz="status.md",dq=1,wz=["prompts","templates","architecture","changes","features","release"],Sz=["product.md","structure.md","tech.md"];async function lq(q){console.log(W.blue(`
|
|
36
36
|
\uD83D\uDE80 Инициализация Agentica...
|
|
37
37
|
`));let z=Az(q.stack);if(!z)_z(q.stack);await new pq(q,z).execute()}class pq{options;stack;repoRoot;targetDir;stackDir;agenticaDir;constructor(q,z){this.options=q;this.stack=z;this.repoRoot=Oz(),this.targetDir=this.options.name?cq(process.cwd(),this.options.name):process.cwd(),this.stackDir=R(this.repoRoot,Ez,this.stack.lang,this.stack.type),this.agenticaDir=R(this.targetDir,Dz)}async execute(){this.ensureStackExists(),this.createProjectDirIfNeeded(),this.createAgenticaDirectories(),this.copyPrompts(),this.copyTemplates(),this.copySkills(),this.copyStackTemplateFiles(),this.createStatusFile(),this.composeAgentsFile(),this.updateVSCodeConfiguration(),this.printSuccessMessage()}ensureStackExists(){if(D(this.stackDir))return;console.error(W.red(`❌ Стек не найден: ${this.stack.lang}/${this.stack.type}`)),console.error(W.yellow(` Путь проверки: ${this.stackDir}`)),process.exit(dq)}createProjectDirIfNeeded(){if(!this.options.name)return;j(this.targetDir),console.log(W.green(`✓ Создана директория: ${this.options.name}`))}createAgenticaDirectories(){j(this.agenticaDir),console.log(W.green("✓ Создана .agentica/"));for(let q of wz)j(R(this.agenticaDir,q))}copyPrompts(){let q=R(this.repoRoot,uq),z=R(this.agenticaDir,uq);k(q,z),console.log(W.green("✓ Скопирована prompts/"))}copyTemplates(){let q=R(this.repoRoot,gq),z=R(this.agenticaDir,gq);k(q,z),console.log(W.green("✓ Скопирована templates/"))}copySkills(){let q=R(this.repoRoot,mq),z=R(this.agenticaDir,mq);k(q,z),console.log(W.green("✓ Скопирована skills/"))}copyStackTemplateFiles(){for(let q of Sz){let z=R(this.stackDir,q),J=R(this.agenticaDir,q);t(z,J)}console.log(W.green(`✓ Скопирован шаблон стека: ${this.stack.lang}/${this.stack.type}`))}createStatusFile(){let q=xz(this.stack),z=R(this.agenticaDir,Fz);Iz(z,q,"utf-8"),console.log(W.green("✓ Создан status.md"))}composeAgentsFile(){hq(this.repoRoot,this.targetDir,this.stack.lang),console.log(W.green("✓ Сформирован AGENTS.md"))}updateVSCodeConfiguration(){try{fq(this.targetDir),vq(this.targetDir),console.log(W.green("✓ Обновлён .vscode/settings.json")),console.log(W.green("✓ Обновлён .vscode/extensions.json"))}catch(q){console.warn(W.yellow(`⚠ Предупреждение: не удалось обновить настройки VSCode: ${q}`))}}printSuccessMessage(){if(console.log(W.green.bold(`
|
|
38
38
|
✨ Agentica успешно инициализирована!
|
|
39
|
-
`)),console.log(W.cyan("Следующие шаги:")),this.options.name)console.log(W.white(` 1. cd ${this.options.name}`));console.log(W.white(" 2. Открой проект в VSCode: code .")),console.log(W.white(` 3. Начни с промпта /agentica.init
|
|
39
|
+
`)),console.log(W.cyan("Следующие шаги:")),this.options.name)console.log(W.white(` 1. cd ${this.options.name}`));console.log(W.white(" 2. Открой проект в VSCode: code .")),console.log(W.white(` 3. Начни с промпта /agentica.init в чате Copilot:
|
|
40
40
|
- Опиши свой проект, и стек технологий (после команды)
|
|
41
41
|
- Agentica подстроится под твои нужды
|
|
42
|
-
- А
|
|
42
|
+
- А дальше можно запускать /agentica.create, /agentica.change, /agentica.commit или /agentica.release
|
|
43
43
|
- И обязательно прочитай и донастрой AGENTS.md
|
|
44
44
|
`))}}function _z(q){console.error(W.red(`❌ Неверный формат стека: ${q}`)),console.error(W.yellow(" Ожидаемый формат: <lang>/<type>")),console.error(W.yellow(" Примеры: typescript/cli, python/gui")),process.exit(dq)}function Az(q){let z=q.split("/");if(z.length!==2)return null;let[J,Z]=z;if(!J||!Z)return null;return{lang:J,type:Z}}function Oz(){return cq(__dirname,"../..")}function xz(q){return`# Статус Agentica
|
|
45
45
|
|
package/globals/use-agentica.md
CHANGED
|
@@ -13,8 +13,8 @@
|
|
|
13
13
|
**Корневой уровень** (`.agentica/` в корне проекта):
|
|
14
14
|
```
|
|
15
15
|
.agentica/
|
|
16
|
-
├── prompts/ # Воркфлоу агентов (init, create, implement, validate)
|
|
17
|
-
├── templates/ # Шаблоны спек (feature, change, architecture)
|
|
16
|
+
├── prompts/ # Воркфлоу агентов (init, create, tasks, implement, validate, commit, release)
|
|
17
|
+
├── templates/ # Шаблоны спек (feature, change, architecture, release)
|
|
18
18
|
├── product.md # Глобальное продуктовое видение
|
|
19
19
|
├── structure.md # Структура и организация репозитория
|
|
20
20
|
├── tech.md # Глобальный тех-стек и стандарты
|
|
@@ -27,6 +27,7 @@ packages/my-package/.agentica/
|
|
|
27
27
|
├── features/ # Спеки FT-XXXX (новая функциональность)
|
|
28
28
|
├── changes/ # Спеки CH-XXXX (изменения существующего кода)
|
|
29
29
|
├── architecture/ # Спеки AR-XXXX (архитектурные решения и паттерны)
|
|
30
|
+
├── release/ # Спеки REL-XXXX (подготовка и выпуск релизов)
|
|
30
31
|
├── product.md # Назначение и домен пакета
|
|
31
32
|
├── structure.md # Файловая структура пакета
|
|
32
33
|
├── tech.md # Стек и паттерны конкретного пакета
|
|
@@ -86,7 +87,7 @@ IDE автоматически предоставляет доступ к фак
|
|
|
86
87
|
- Консистентность > новизна
|
|
87
88
|
|
|
88
89
|
**4. Следуй процессу**
|
|
89
|
-
Каждый воркфлоу Agentica имеет определённые шаги (init → create → tasks → implement → validate). Если пользователь просит сделать что-то масштабное:
|
|
90
|
+
Каждый воркфлоу Agentica имеет определённые шаги (init → create/change → tasks → implement → validate → commit → release). Если пользователь просит сделать что-то масштабное:
|
|
90
91
|
- Проверь, существует ли связанная спека
|
|
91
92
|
- Если спеки нет - рекомендуй сначала использовать `/agentica.create`
|
|
92
93
|
- Не пиши большие фичи "фристайлом" без спеки
|
|
@@ -101,6 +102,8 @@ IDE автоматически предоставляет доступ к фак
|
|
|
101
102
|
2. Распланируй задачи: `/agentica.tasks --id FT-XXXX`
|
|
102
103
|
3. Реализуй: `/agentica.implement --id FT-XXXX`
|
|
103
104
|
4. Валидируй: `/agentica.validate --id FT-XXXX`
|
|
105
|
+
5. Подготовь коммит: `/agentica.commit`
|
|
106
|
+
6. Подготовь релиз: `/agentica.release --type patch|minor|major`
|
|
104
107
|
|
|
105
108
|
Это обеспечит:
|
|
106
109
|
- Правильное планирование архитектуры
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@jakerdy/agentica",
|
|
3
|
-
"version": "0.0.
|
|
3
|
+
"version": "0.0.4",
|
|
4
4
|
"description": "Spec-driven framework for agent coding with developer-first approach",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"ai",
|
|
@@ -39,14 +39,16 @@
|
|
|
39
39
|
],
|
|
40
40
|
"scripts": {
|
|
41
41
|
"build": "bun run build.ts",
|
|
42
|
-
"prepublishOnly": "bun run build"
|
|
42
|
+
"prepublishOnly": "bun run build",
|
|
43
|
+
"typecheck": "tsc --noEmit"
|
|
43
44
|
},
|
|
44
45
|
"engines": {
|
|
45
46
|
"node": ">=18.0.0"
|
|
46
47
|
},
|
|
47
48
|
"devDependencies": {
|
|
48
|
-
"
|
|
49
|
-
"@types/bun": "latest"
|
|
49
|
+
"@biomejs/biome": "^2.4.2",
|
|
50
|
+
"@types/bun": "latest",
|
|
51
|
+
"typescript": "^5"
|
|
50
52
|
},
|
|
51
53
|
"dependencies": {
|
|
52
54
|
"chalk": "^5.6.2",
|
|
@@ -0,0 +1,134 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: agentica.commit
|
|
3
|
+
description: Безопасная подготовка staged-изменений и создание семантического commit message
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## Ввод пользователя
|
|
7
|
+
|
|
8
|
+
```text
|
|
9
|
+
$ARGUMENTS
|
|
10
|
+
```
|
|
11
|
+
|
|
12
|
+
Ты **ОБЯЗАН** учесть ввод пользователя (аргументы и контекст) перед тем как продолжить.
|
|
13
|
+
|
|
14
|
+
## Цель и принцип работы
|
|
15
|
+
|
|
16
|
+
Твоя задача — подготовить и выполнить коммит в безопасном режиме:
|
|
17
|
+
1. Добавить изменения в stage.
|
|
18
|
+
2. Проверить, что в stage нет лишних файлов, секретов и бинарного мусора.
|
|
19
|
+
3. Сформировать корректный commit message.
|
|
20
|
+
4. Выполнить `git commit`.
|
|
21
|
+
|
|
22
|
+
Работай строго линейно: **Диагностика → Stage → Проверка содержимого stage → Генерация commit message → Commit → Отчёт**.
|
|
23
|
+
|
|
24
|
+
## Глобальные запреты (Safety Guards)
|
|
25
|
+
|
|
26
|
+
Останови выполнение и не коммить, если:
|
|
27
|
+
1. Текущая директория не является git-репозиторием.
|
|
28
|
+
2. После staging обнаружены потенциальные секреты, и пользователь не подтвердил продолжение.
|
|
29
|
+
3. В stage есть нежелательные бинарные/сборочные артефакты, и пользователь не подтвердил продолжение.
|
|
30
|
+
4. В stage нет изменений (пустой коммит не запрошен явно).
|
|
31
|
+
|
|
32
|
+
В случае остановки: объясни причину и покажи, как исправить ситуацию.
|
|
33
|
+
|
|
34
|
+
## Фаза 1: Диагностика git-контекста
|
|
35
|
+
|
|
36
|
+
1. Проверь git-контекст:
|
|
37
|
+
- `git rev-parse --is-inside-work-tree`
|
|
38
|
+
2. Собери текущее состояние:
|
|
39
|
+
- `git status --short`
|
|
40
|
+
|
|
41
|
+
## Фаза 2: Stage всех изменений
|
|
42
|
+
|
|
43
|
+
1. Добавь все изменения в stage:
|
|
44
|
+
- `git add -A`
|
|
45
|
+
2. Проверь staged-список:
|
|
46
|
+
- `git diff --cached --name-status`
|
|
47
|
+
|
|
48
|
+
## Фаза 3: Проверка stage на риски
|
|
49
|
+
|
|
50
|
+
Если пользователь указал ключ `--skip-checks`, пропусти эту фазу и перейди к генерации commit message.
|
|
51
|
+
|
|
52
|
+
### 3.1 Поиск мусорных/артефактных файлов
|
|
53
|
+
|
|
54
|
+
Проверь staged-файлы на признаки артефактов и мусора (например):
|
|
55
|
+
- `*.exe`, `*.dll`, `*.dylib`, `*.so`, `*.a`, `*.o`, `*.obj`
|
|
56
|
+
- `*.tgz`, `*.zip`, `*.tar`, `*.gz`, `*.7z`
|
|
57
|
+
- <другие типы не похожие на исходники>
|
|
58
|
+
- фалйы большого размера (например, >5MB), если это не типичные для проекта ассеты.
|
|
59
|
+
- build-output и временные директории (`dist/`, `build/`, `.cache/`, `coverage/`, и т.д.), если они не должны коммититься по правилам проекта.
|
|
60
|
+
|
|
61
|
+
Если найдено:
|
|
62
|
+
1. Покажи пользователю список подозрительных файлов.
|
|
63
|
+
2. Предупреди, что эти файлы выглядят как мусор/артефакты/temp.
|
|
64
|
+
3. Предложи обновить `.gitignore` и убрать лишнее из stage.
|
|
65
|
+
4. Через `ask_questions` попроси выбрать действие:
|
|
66
|
+
- убрать артефакты из stage и продолжить;
|
|
67
|
+
- убрать и обновить `.gitignore`, затем продолжить;
|
|
68
|
+
- продолжить как есть (только при явном подтверждении пользователя).
|
|
69
|
+
|
|
70
|
+
### 3.2 Поиск потенциальных секретов
|
|
71
|
+
|
|
72
|
+
Проверь staged-изменения на явные признаки секретов:
|
|
73
|
+
- API keys / tokens / private keys / passwords / connection strings.
|
|
74
|
+
- Паттерны вида `AKIA...`, `ghp_...`, `-----BEGIN PRIVATE KEY-----`, `password=`, `secret=`, `token=`.
|
|
75
|
+
|
|
76
|
+
Если найдено:
|
|
77
|
+
1. Покажи только безопасный контекст (без полного вывода секрета).
|
|
78
|
+
2. Останови авто-коммит.
|
|
79
|
+
3. Через `ask_questions` предложи:
|
|
80
|
+
- удалить/замаскировать секреты и продолжить;
|
|
81
|
+
- если это .env создать .env.example и обновить .gitignore;
|
|
82
|
+
- исключить файл из stage;
|
|
83
|
+
- отменить операцию.
|
|
84
|
+
|
|
85
|
+
### 3.3 Поиск неуместных фраз и матершины в коде
|
|
86
|
+
|
|
87
|
+
Иногда так бывает, что у разработчика здают нервы, и он пишет в коде нецензурные выражения. Это может быть проблемой, если такие изменения попадут в историю. Поэтому стоит проверять staged-изменения на наличие таких фраз и предупреждать пользователя, сразу предлагая более нейтральные формулировки.
|
|
88
|
+
|
|
89
|
+
По этому:
|
|
90
|
+
- Проверь изменения на матершину и прочие NSFW вещи в коментариях, именах переменных и прочих текстовых изменениях.
|
|
91
|
+
- Если это часть локализации или "ассетов" - ок, пропускаем.
|
|
92
|
+
|
|
93
|
+
## Фаза 4: Формирование commit message
|
|
94
|
+
|
|
95
|
+
Сформируй сообщение в формате:
|
|
96
|
+
|
|
97
|
+
```text
|
|
98
|
+
<change_type>: <Short Change Description>
|
|
99
|
+
|
|
100
|
+
Detailed semantic description of changes
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
Где:
|
|
104
|
+
- `<change_type>` — один из: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `build`, `ci`, `perf`, `revert`.
|
|
105
|
+
- `Short Change Description` — коротко, по сути, в одну строку.
|
|
106
|
+
- `Detailed semantic description` — 2+ строк с ключевыми изменениями (списоком, не файлы, а семантика), мотивацией и влиянием.
|
|
107
|
+
|
|
108
|
+
Правила качества commit message:
|
|
109
|
+
1. Заголовок до ~72 символов.
|
|
110
|
+
2. Без абстрактных формулировок вроде "misc updates".
|
|
111
|
+
3. Опираться только на реально staged изменения.
|
|
112
|
+
4. Семантические описания вместо конкретных файлов/строк.
|
|
113
|
+
4. Если staged содержит несколько несвязанных изменений — предложить пользователю разбить на несколько коммитов.
|
|
114
|
+
|
|
115
|
+
## Фаза 5: Выполнение commit
|
|
116
|
+
|
|
117
|
+
1. Выполни:
|
|
118
|
+
- `git commit -m "<title>" -m "<body>"`
|
|
119
|
+
2. Если commit не выполнен (hook/validation failed) — покажи ошибку и предложи шаги исправления.
|
|
120
|
+
|
|
121
|
+
## Фаза 6: Отчёт пользователю
|
|
122
|
+
|
|
123
|
+
Выдай краткий отчёт:
|
|
124
|
+
1. Что было добавлено в stage.
|
|
125
|
+
2. Были ли найдены мусорные файлы/секреты и как решено.
|
|
126
|
+
3. Итоговый commit message.
|
|
127
|
+
4. Результат `git commit` (хеш и краткая сводка файлов).
|
|
128
|
+
|
|
129
|
+
## Требования к качеству
|
|
130
|
+
|
|
131
|
+
1. Не выводи секреты в открытом виде.
|
|
132
|
+
2. Не коммить без проверки staged-содержимого.
|
|
133
|
+
3. Если есть сомнения в корректности набора изменений — спроси пользователя через `ask_questions` перед commit.
|
|
134
|
+
4. Всегда явно предупреждай о рисках загрязнения истории бинарными артефактами и предлагай обновить `.gitignore`.
|
package/prompts/init.prompt.md
CHANGED
|
@@ -19,7 +19,7 @@ $ARGUMENTS
|
|
|
19
19
|
### Глобальные запреты (Safety Guards)
|
|
20
20
|
|
|
21
21
|
Останови выполнение и не вноси изменения, если:
|
|
22
|
-
1. Запрос требует другого пайплайна (
|
|
22
|
+
1. Запрос требует другого пайплайна (tasks, implement, refactor, readme, commit, release), а не инициализации/настройки.
|
|
23
23
|
2. Пользователь просит изменить узкую реализацию, несвязанную с настройкой Agentica.
|
|
24
24
|
3. Входные данные противоречивы.
|
|
25
25
|
4. Проект **уже инициализирован** (есть `.agentica/` и ключевые файлы), и пользователь не выбрал явный режим обновления.
|
|
@@ -33,7 +33,7 @@ $ARGUMENTS
|
|
|
33
33
|
### Группы артефактов
|
|
34
34
|
1. **[Context]:** `product.md`, `structure.md`, `tech.md`, `status.md`. (Обязательны для любого активного скоупа).
|
|
35
35
|
2. **[Config]:** Директории `prompts/`, `templates/`. (Только в корне проекта/репозитория).
|
|
36
|
-
3. **[Specs]:** Директории `architecture/`, `changes/`, `features/`. (Только там, где лежит код/пакет).
|
|
36
|
+
3. **[Specs]:** Директории `architecture/`, `changes/`, `features/`, `release/`. (Только там, где лежит код/пакет).
|
|
37
37
|
|
|
38
38
|
### Матрица размещения
|
|
39
39
|
|
|
@@ -87,6 +87,7 @@ $ARGUMENTS
|
|
|
87
87
|
5. Обнови **[Config]** в root `.agentica/`:
|
|
88
88
|
- синхронизируй все файлы в `.agentica/prompts/` с новым набором инструментов;
|
|
89
89
|
- обязательно проверь `refactor.prompt.md` и `validate.prompt.md` на конкретные команды;
|
|
90
|
+
- обязательно адаптируй `release.prompt.md` под стек и реальные команды релизного пайплайна;
|
|
90
91
|
- выполни семантический поиск по запуску инструментов и regex-поиск упоминаний legacy-команд (`bun`, `tsc` и т.п.), затем замени их на актуальные.
|
|
91
92
|
6. Обнови шаблоны в `.agentica/templates/`, чтобы формулировки по сборке, тестам, линтингу и валидации соответствовали реальному техстеку.
|
|
92
93
|
7. Проверь консистентность: одинаковые команды и правила должны использоваться в `tech.md`, промптах и шаблонах без противоречий.
|
|
@@ -110,7 +111,7 @@ $ARGUMENTS
|
|
|
110
111
|
|
|
111
112
|
Перед выдачей ответа проверь:
|
|
112
113
|
1. Все файлы из групп **[Context]**, **[Config]**, **[Specs]** существуют на своих местах согласно матрице размещения.
|
|
113
|
-
2. В корне Monorepo **нет** папок `architecture`, `changes`, `features`.
|
|
114
|
+
2. В корне Monorepo **нет** папок `architecture`, `changes`, `features`, `release`.
|
|
114
115
|
3. В `status.md` записан актуальный статус.
|
|
115
116
|
4. Файлы `product/structure/tech` не противоречат друг другу.
|
|
116
117
|
|
|
@@ -0,0 +1,127 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: agentica.release
|
|
3
|
+
description: Подготовка релиза, сборка черновика changelog и предрелизный аудит
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## Ввод пользователя
|
|
7
|
+
|
|
8
|
+
```text
|
|
9
|
+
$ARGUMENTS
|
|
10
|
+
```
|
|
11
|
+
|
|
12
|
+
Ты **ОБЯЗАН** учесть ввод пользователя (аргументы и контекст) перед тем как продолжить.
|
|
13
|
+
|
|
14
|
+
## Цель и принцип работы
|
|
15
|
+
|
|
16
|
+
Твоя задача — подготовить релизный пакет в формате `REL-XXXX`:
|
|
17
|
+
1. Проверить готовность репозитория к релизу.
|
|
18
|
+
2. Вычислить новую версию и собрать черновик `Changelog`.
|
|
19
|
+
3. Сформировать документ релиза по шаблону.
|
|
20
|
+
4. Выдать отчёт о рисках и командах публикации.
|
|
21
|
+
|
|
22
|
+
Работай строго линейно: **Проверка ветки → Выбор версии → Сбор коммитов → Предрелизный аудит → Генерация REL-документа → Отчёт**.
|
|
23
|
+
|
|
24
|
+
## Глобальные запреты (Safety Guards)
|
|
25
|
+
|
|
26
|
+
Останови выполнение и не вноси изменения, если:
|
|
27
|
+
1. Текущая ветка не `main` и не `master`.
|
|
28
|
+
2. Невозможно определить предыдущий релиз (нет тегов и нет версии в манифестах).
|
|
29
|
+
3. Репозиторий не является git-репозиторием.
|
|
30
|
+
|
|
31
|
+
В случае остановки: объясни причину, покажи минимальные шаги для исправления и предложи перезапустить `agentica.release`.
|
|
32
|
+
|
|
33
|
+
## Топология и размещение файлов
|
|
34
|
+
|
|
35
|
+
Документ релиза хранится в:
|
|
36
|
+
- `.agentica/release/REL-XXXX - <Release Name>.md`
|
|
37
|
+
|
|
38
|
+
Шаблон релиза:
|
|
39
|
+
- `.agentica/templates/release/REL-0000 - Release Name.md`
|
|
40
|
+
|
|
41
|
+
## Фаза 1: Проверка git-контекста
|
|
42
|
+
|
|
43
|
+
1. Проверь, что репозиторий git и текущая ветка через `run_in_terminal`:
|
|
44
|
+
- `git rev-parse --is-inside-work-tree`
|
|
45
|
+
- `git branch --show-current`
|
|
46
|
+
2. Если ветка не `main`/`master` — **STOP**.
|
|
47
|
+
3. Найди предыдущую версию:
|
|
48
|
+
- сначала `git describe --tags --abbrev=0`
|
|
49
|
+
- если тега нет, попробуй получить текущую версию из манифестов (`package.json`, `pyproject.toml`, `Cargo.toml`, и т.д. — по стеку проекта).
|
|
50
|
+
|
|
51
|
+
## Фаза 2: Вычисление новой версии
|
|
52
|
+
|
|
53
|
+
1. Спроси пользователя через `ask_questions` тип увеличения версии:
|
|
54
|
+
- `patch`
|
|
55
|
+
- `minor`
|
|
56
|
+
- `major`
|
|
57
|
+
2. На основе предыдущей версии вычисли новую семантическую версию (`X.Y.Z`).
|
|
58
|
+
3. Определи новый release id:
|
|
59
|
+
- Найди существующие документы `REL-XXXX` в `.agentica/release/`.
|
|
60
|
+
- Новый ID = max + 1.
|
|
61
|
+
|
|
62
|
+
## Фаза 3: Сбор changelog по коммитам
|
|
63
|
+
|
|
64
|
+
1. Собери коммиты с последнего тега до `HEAD`:
|
|
65
|
+
- `git log <prev_tag>..HEAD --pretty=format:"%h|%s|%an|%ad" --date=short`
|
|
66
|
+
- если тега нет: используй разумный диапазон (например, все коммиты текущей ветки).
|
|
67
|
+
2. Сгруппируй коммиты в черновик changelog:
|
|
68
|
+
- Features
|
|
69
|
+
- Fixes
|
|
70
|
+
- Refactor/Chore
|
|
71
|
+
- Docs/Test/Build
|
|
72
|
+
3. Пройдись по каждому коммиту и убери шум:
|
|
73
|
+
- merge-коммиты
|
|
74
|
+
- технические коммиты без продуктовой ценности (оставляй в отдельном блоке при необходимости).
|
|
75
|
+
|
|
76
|
+
## Фаза 4: Предрелизный аудит
|
|
77
|
+
|
|
78
|
+
Проверь и явно зафиксируй статус каждого пункта:
|
|
79
|
+
|
|
80
|
+
1. Версии в манифестах пакетов совпадают с вычисленной версией.
|
|
81
|
+
2. Все изменения закоммичены (`git status --porcelain` пустой).
|
|
82
|
+
3. Код форматируется, линтится, компилируется и собирается (команды брать из `tech.md`, `README.md`, `package.json`/`pyproject.toml`).
|
|
83
|
+
4. Dry-run публикации работает (если применимо стеку):
|
|
84
|
+
- npm: `npm publish --dry-run`
|
|
85
|
+
- bun: `bun publish --dry-run`
|
|
86
|
+
- python: `python -m build` + `twine check dist/*` (или эквивалент)
|
|
87
|
+
5. Окружение для публикации настроено корректно:
|
|
88
|
+
- наличие токенов/credentials (без вывода секретов)
|
|
89
|
+
- корректный registry/repository endpoint
|
|
90
|
+
|
|
91
|
+
Если проверка неприменима к стеку — отмечай как `N/A` с коротким объяснением.
|
|
92
|
+
|
|
93
|
+
## Фаза 5: Генерация REL-документа
|
|
94
|
+
|
|
95
|
+
1. Создай новый файл по шаблону:
|
|
96
|
+
- `.agentica/release/REL-XXXX - <Release Name>.md`
|
|
97
|
+
2. Заполни:
|
|
98
|
+
- версию (`previous` → `next`)
|
|
99
|
+
- дату
|
|
100
|
+
- pre-release checklist
|
|
101
|
+
- changelog draft
|
|
102
|
+
- stack-oriented release plan
|
|
103
|
+
- блок рисков и блокеров
|
|
104
|
+
|
|
105
|
+
## Фаза 6: Отчёт пользователю
|
|
106
|
+
|
|
107
|
+
Выдай короткий отчёт:
|
|
108
|
+
1. Какая версия рассчитана (`from` → `to`).
|
|
109
|
+
2. Где создан REL-документ.
|
|
110
|
+
3. Какие проверки пройдены/провалены/неприменимы.
|
|
111
|
+
4. Точный список команд, которые пользователь должен выполнить для публикации релиза.
|
|
112
|
+
|
|
113
|
+
## Фаза 7: Помощь в публикации (по запросу)
|
|
114
|
+
|
|
115
|
+
Предложи пользователю помощь в публикации релиза. Если он согласится, выполни все необходимые действия перед публикацией:
|
|
116
|
+
1. Апнуть версии в манифестах.
|
|
117
|
+
2. Закоммитить изменения с сообщением `chore(release): prepare vX.Y.Z`.
|
|
118
|
+
3. Создать тег `vX.Y.Z` и отправить его в origin.
|
|
119
|
+
4. Обновить Badges в `README.md` (если есть).
|
|
120
|
+
5. Написать финальную команду для публикации релиза и дать краткие инструкции по её запуску.
|
|
121
|
+
|
|
122
|
+
## Требования к качеству
|
|
123
|
+
|
|
124
|
+
1. Версия должна быть semver-валидной и согласованной между документом и манифестами.
|
|
125
|
+
2. Changelog должен строиться только из реальных коммитов диапазона релиза.
|
|
126
|
+
3. Если есть блокеры, команды публикации всё равно показать, но пометить как «не запускать до устранения блокеров».
|
|
127
|
+
4. Никакие секреты не выводить в отчёт.
|
|
@@ -8,6 +8,7 @@
|
|
|
8
8
|
│ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
|
|
9
9
|
│ ├── features/ # Описания фич (требования, UX, acceptance)
|
|
10
10
|
│ ├── changes/ # Журнал изменений, миграции, заметки по релизам
|
|
11
|
+
│ ├── release/ # Релизные документы (REL-XXXX)
|
|
11
12
|
│ ├── architecture/ # Архитектурные решения (ADR), схемы, компромиссы
|
|
12
13
|
│ ├── product.md # Описание проекта с продуктовой точки зрения
|
|
13
14
|
│ ├── structure.md # Этот файл: структура репозитория
|
|
@@ -8,6 +8,7 @@
|
|
|
8
8
|
│ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
|
|
9
9
|
│ ├── features/ # Описания фич и UX сценариев
|
|
10
10
|
│ ├── changes/ # Журнал изменений и миграции
|
|
11
|
+
│ ├── release/ # Релизные документы (REL-XXXX)
|
|
11
12
|
│ ├── architecture/ # Архитектурные решения (ADR)
|
|
12
13
|
│ ├── product.md # Описание проекта с продуктовой точки зрения
|
|
13
14
|
│ ├── structure.md # Этот файл: структура репозитория
|
|
@@ -8,6 +8,7 @@
|
|
|
8
8
|
│ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
|
|
9
9
|
│ ├── features/ # Описания фич (контракты, примеры, UX)
|
|
10
10
|
│ ├── changes/ # Изменения, миграции, заметки по версиям
|
|
11
|
+
│ ├── release/ # Релизные документы (REL-XXXX)
|
|
11
12
|
│ ├── architecture/ # Архитектурные решения (ADR)
|
|
12
13
|
│ ├── product.md # Описание проекта с продуктовой точки зрения
|
|
13
14
|
│ ├── structure.md # Этот файл: структура репозитория
|
|
@@ -13,6 +13,7 @@
|
|
|
13
13
|
├── packages/ # Набор Python пакетов (каждый со своим `pyproject.toml`)
|
|
14
14
|
│ ├── package1/ # Пример пакета
|
|
15
15
|
│ │ ├── .agentica/ # Документы Agentica, относящиеся к этому пакету
|
|
16
|
+
│ │ │ ├── release/ # Релизные документы пакета (REL-XXXX)
|
|
16
17
|
│ │ ├── <package_name>/ # Исходный код пакета
|
|
17
18
|
│ │ ├── tests/ # Тесты пакета
|
|
18
19
|
│ │ └── pyproject.toml # Зависимости и конфигурация инструментов пакета
|
|
@@ -8,6 +8,7 @@
|
|
|
8
8
|
│ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
|
|
9
9
|
│ ├── features/ # Описания фич (команды, UX, контракты)
|
|
10
10
|
│ ├── changes/ # Журнал изменений (breaking changes, миграции)
|
|
11
|
+
│ ├── release/ # Релизные документы (REL-XXXX)
|
|
11
12
|
│ ├── architecture/ # Архитектурные решения (ADR)
|
|
12
13
|
│ ├── product.md # Описание CLI с продуктовой точки зрения
|
|
13
14
|
│ ├── structure.md # Этот файл: структура репозитория
|
|
@@ -8,6 +8,7 @@
|
|
|
8
8
|
│ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
|
|
9
9
|
│ ├── features/ # Описания фич (контракты API, примеры)
|
|
10
10
|
│ ├── changes/ # Изменения, миграции, заметки по версиям
|
|
11
|
+
│ ├── release/ # Релизные документы (REL-XXXX)
|
|
11
12
|
│ ├── architecture/ # Архитектурные решения (ADR)
|
|
12
13
|
│ ├── product.md # Описание библиотеки с продуктовой точки зрения
|
|
13
14
|
│ ├── structure.md # Этот файл: структура репозитория
|
|
@@ -13,6 +13,7 @@
|
|
|
13
13
|
├── packages/ # Пакеты монорепозитория
|
|
14
14
|
│ ├── package1/ # Пример пакета
|
|
15
15
|
│ │ ├── .agentica/ # Документы Agentica, относящиеся к пакету
|
|
16
|
+
│ │ │ ├── release/ # Релизные документы пакета (REL-XXXX)
|
|
16
17
|
│ │ ├── src/ # Исходный код пакета
|
|
17
18
|
│ │ ├── tests/ # Тесты пакета
|
|
18
19
|
│ │ └── ... # Прочие файлы пакета (конфиги, assets)
|
|
@@ -8,6 +8,7 @@
|
|
|
8
8
|
│ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
|
|
9
9
|
│ ├── features/ # Описания фич и контрактов API
|
|
10
10
|
│ ├── changes/ # Изменения и миграции
|
|
11
|
+
│ ├── release/ # Релизные документы (REL-XXXX)
|
|
11
12
|
│ ├── architecture/ # Архитектурные решения (ADR)
|
|
12
13
|
│ ├── product.md # Описание сервиса с продуктовой точки зрения
|
|
13
14
|
│ ├── structure.md # Этот файл: структура репозитория
|
|
@@ -8,6 +8,7 @@
|
|
|
8
8
|
│ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
|
|
9
9
|
│ ├── features/ # Описания UI/UX фич и сценариев
|
|
10
10
|
│ ├── changes/ # Изменения, миграции, заметки по релизам
|
|
11
|
+
│ ├── release/ # Релизные документы (REL-XXXX)
|
|
11
12
|
│ ├── architecture/ # Архитектурные решения (ADR)
|
|
12
13
|
│ ├── product.md # Описание SPA с продуктовой точки зрения
|
|
13
14
|
│ ├── structure.md # Этот файл: структура репозитория
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
# REL-0000 - Release Name
|
|
2
|
+
|
|
3
|
+
## Сводка релиза
|
|
4
|
+
|
|
5
|
+
- **Дата:** YYYY-MM-DD
|
|
6
|
+
- **Предыдущая версия:** vX.Y.Z
|
|
7
|
+
- **Новая версия:** vX.Y.Z
|
|
8
|
+
- **Тип релиза:** patch | minor | major
|
|
9
|
+
- **Тег:** vX.Y.Z
|
|
10
|
+
|
|
11
|
+
## Чеклист предрелизных работ
|
|
12
|
+
|
|
13
|
+
- [ ] Активная ветка: `main` или `master`
|
|
14
|
+
- [ ] Все изменения закоммичены (`git status` чистый)
|
|
15
|
+
- [ ] Версии в манифестах синхронизированы с тегом релиза
|
|
16
|
+
- [ ] Форматирование проходит успешно
|
|
17
|
+
- [ ] Линт проходит успешно
|
|
18
|
+
- [ ] Компиляция/типизация проходит успешно
|
|
19
|
+
- [ ] Сборка проходит успешно
|
|
20
|
+
- [ ] Dry-run публикации прошёл успешно (если применимо)
|
|
21
|
+
- [ ] Публикационное окружение и credentials проверены
|
|
22
|
+
|
|
23
|
+
## Черновик Changelog для текущей версии
|
|
24
|
+
|
|
25
|
+
### Features
|
|
26
|
+
|
|
27
|
+
- ...
|
|
28
|
+
|
|
29
|
+
### Fixes
|
|
30
|
+
|
|
31
|
+
- ...
|
|
32
|
+
|
|
33
|
+
### Refactor / Chore
|
|
34
|
+
|
|
35
|
+
- ...
|
|
36
|
+
|
|
37
|
+
### Docs / Tests / Build
|
|
38
|
+
|
|
39
|
+
- ...
|
|
40
|
+
|
|
41
|
+
### Breaking Changes (если есть)
|
|
42
|
+
|
|
43
|
+
- ...
|
|
44
|
+
|
|
45
|
+
## План действий (стеко-ориентированный)
|
|
46
|
+
|
|
47
|
+
### TypeScript / Node / Bun
|
|
48
|
+
|
|
49
|
+
1. Обновить версии в `package.json` (и package-манифестах, если monorepo).
|
|
50
|
+
2. Выполнить quality gate (`format`, `lint`, `typecheck`, `test`, `build`).
|
|
51
|
+
3. Проверить dry-run публикации (`npm publish --dry-run` или `bun publish --dry-run`).
|
|
52
|
+
4. Создать тег релиза и отправить его в origin.
|
|
53
|
+
5. Выполнить реальную публикацию в registry.
|
|
54
|
+
|
|
55
|
+
### Python
|
|
56
|
+
|
|
57
|
+
1. Обновить версию в `pyproject.toml` (и пакетах monorepo).
|
|
58
|
+
2. Выполнить quality gate (`format`, `lint`, `typecheck`, `test`).
|
|
59
|
+
3. Собрать артефакты (`python -m build`) и проверить (`twine check dist/*`).
|
|
60
|
+
4. Создать тег релиза и отправить его в origin.
|
|
61
|
+
5. Опубликовать пакет (`twine upload dist/*` или эквивалент).
|
|
62
|
+
|
|
63
|
+
### Другое / Custom
|
|
64
|
+
|
|
65
|
+
1. Зафиксировать команды из `tech.md` и `README.md`.
|
|
66
|
+
2. Проверить dry-run и каналы публикации, применимые к стеку.
|
|
67
|
+
3. Выполнить публикацию по внутреннему release pipeline.
|
|
68
|
+
|
|
69
|
+
## Блокеры и риски
|
|
70
|
+
|
|
71
|
+
- [ ] Блокер 1: ...
|
|
72
|
+
- [ ] Блокер 2: ...
|
|
73
|
+
|
|
74
|
+
## Команды для публикации (заполняется по результатам аудита)
|
|
75
|
+
|
|
76
|
+
```bash
|
|
77
|
+
# Пример (адаптируется под стек проекта)
|
|
78
|
+
# git tag vX.Y.Z
|
|
79
|
+
# git push origin vX.Y.Z
|
|
80
|
+
# npm publish
|
|
81
|
+
```
|