docs: add agent bootstrap and contract read router

This commit is contained in:
Mikhail Chusavitin
2026-04-02 13:48:36 +03:00
parent 688b87e98d
commit 1d89a4918e
22 changed files with 883 additions and 1284 deletions

View File

@@ -0,0 +1,78 @@
# Application Binary Pattern Notes
This file keeps examples and rollout snippets. The normative rules live in `contract.md`.
## Host Layout
Default application root:
```text
/appdata/<appname>/
```
Example:
```bash
scp bin/myservice user@host:/appdata/myservice/myservice
scp docker-compose.yml user@host:/appdata/myservice/docker-compose.yml
ssh user@host "mkdir -p /appdata/myservice"
ssh user@host "cd /appdata/myservice && docker compose up -d"
```
## Embedded Resources
Typical embedded assets:
- HTML templates
- static JS/CSS/icons
- `config.template.yaml`
- DB migrations
## Config Template Example
```yaml
# <appname> configuration
# Generated on first run. Edit as needed.
server:
port: 8080
database:
host: localhost
port: 5432
user: ""
password: ""
dbname: ""
```
## First-Run Behavior
```text
Start
-> config missing
-> create directory
-> write template
-> print config path
-> exit 0
```
Expected message:
```text
Config created: ~/.config/<appname>/config.yaml
Edit the file and restart the application.
```
## Build Examples
Without CGO:
```bash
CGO_ENABLED=0 go build -ldflags="-s -w" -o bin/<appname> ./cmd/<appname>
```
With CGO where required:
```bash
CGO_ENABLED=1 go build -ldflags="-s -w" -o bin/<appname> ./cmd/<appname>
```

View File

@@ -6,152 +6,19 @@ Version: 1.0
Правила сборки, упаковки ресурсов и первого запуска Go-приложений.
---
See `README.md` for deployment examples and a sample config template.
## Расположение на хосте
## Rules
> Это правило применяется когда ИИ самостоятельно разворачивает приложение или выполняет команды на build-машине (деплой, копирование файлов, запуск сервисов).
Бинарник приложения размещается в директории:
```
/appdata/<appname>/
```
где `<appname>` — имя приложения (строчными буквами, без пробелов).
Пример: приложение `myservice``/appdata/myservice/myservice`.
Все файлы, связанные с конкретным приложением (бинарник, вспомогательные скрипты запуска, `docker-compose.yml`), хранятся внутри этой директории. Конфиг и данные — по правилам секций ниже.
### Примеры внедрения
При деплое, копировании файлов или запуске сервисов ИИ **всегда по умолчанию** использует этот путь:
```bash
# Копирование бинарника
scp bin/myservice user@host:/appdata/myservice/myservice
# Копирование docker-compose
scp docker-compose.yml user@host:/appdata/myservice/docker-compose.yml
# Запуск на хосте
ssh user@host "cd /appdata/myservice && docker compose up -d"
```
```bash
# Создание директории если не существует
ssh user@host "mkdir -p /appdata/myservice"
```
Не предлагать альтернативные пути (`/opt/`, `/usr/local/bin/`, `~/`) — только `/appdata/<appname>/`.
---
## Бинарник
Бинарник самодостаточен — все ресурсы встроены через `//go:embed`:
- HTML-шаблоны
- Статика (JS, CSS, иконки)
- Шаблон конфиг-файла (`config.template.yaml`)
- Миграции БД
Никаких внешних папок рядом с бинарником не требуется для запуска.
---
## Конфиг-файл
Создаётся автоматически при первом запуске, если не существует.
### Расположение
| Режим приложения | Путь |
|---|---|
| Однопользовательское | `~/.config/<appname>/config.yaml` |
| Серверное / многопользовательское | `/etc/<appname>/config.yaml` или рядом с бинарником |
Приложение само определяет путь и создаёт директорию если её нет.
### Содержимое
Конфиг хранит:
- Настройки приложения (порт, язык, таймауты, feature flags)
- Параметры подключения к централизованной СУБД (host, port, user, password, dbname)
Конфиг **не хранит**:
- Данные пользователя
- Кеш или состояние
- Что-либо что относится к SQLite (см. ниже)
### Шаблон
Шаблон конфига встроен в бинарник. При создании файла шаблон копируется в целевой путь.
Шаблон содержит все ключи с комментариями и дефолтными значениями.
```yaml
# <appname> configuration
# Generated on first run. Edit as needed.
server:
port: 8080
database:
host: localhost
port: 5432
user: ""
password: ""
dbname: ""
# ... остальные настройки
```
---
## SQLite (однопользовательский режим)
Если приложение использует локальную SQLite:
- Файл хранится рядом с конфигом: `~/.config/<appname>/<appname>.db`
- Путь к файлу не выносится в конфиг — приложение вычисляет его из пути конфига
- SQLite **не хранит** параметры подключения к централизованной СУБД — только локальные данные приложения
---
## Первый запуск — алгоритм
```
Старт приложения
├── Конфиг существует? → Нет → создать директорию → скопировать шаблон → сообщить пользователю путь
│ → завершить с кодом 0
│ (пользователь заполняет конфиг)
└── Конфиг существует? → Да → валидировать → запустить приложение
```
При первом создании конфига приложение **не запускается** — выводит сообщение:
```
Config created: ~/.config/<appname>/config.yaml
Edit the file and restart the application.
```
---
## Сборка
Финальный бинарник собирается без CGO если это возможно (для SQLite — с CGO):
```
CGO_ENABLED=0 go build -ldflags="-s -w" -o bin/<appname> ./cmd/<appname>
```
С SQLite:
```
CGO_ENABLED=1 go build -ldflags="-s -w" -o bin/<appname> ./cmd/<appname>
```
Бинарник не зависит от рабочей директории запуска.
- When the agent deploys or runs commands on a host, the application lives in `/appdata/<appname>/`.
- Do not suggest alternate default install paths such as `/opt`, `/usr/local/bin`, or `~/`.
- The binary must be self-contained. Templates, static assets, config templates, and DB migrations are embedded with `//go:embed` or an equivalent application-owned mechanism.
- The application creates its config automatically on first run if it does not exist yet.
- Default config path:
- single-user mode: `~/.config/<appname>/config.yaml`
- server or multi-user mode: `/etc/<appname>/config.yaml` or next to the binary
- Config stores application settings and centralized DB credentials only. It must not store user data, cache/state, or SQLite path configuration.
- For local SQLite mode, the database file lives next to the config and its path is derived by the application, not configured separately.
- On first run with no config, the application must create the config, print its path, exit 0, and stop. It must not continue startup with a fresh placeholder config.
- The binary must not depend on the caller's working directory.
- Build with `CGO_ENABLED=0` when possible. Enable CGO only when the chosen storage/runtime actually requires it, such as SQLite drivers that need CGO.