# Follow-up Questions (q-002)

## Typos / Bugs in Types Definition

В типах есть ошибки, которые нужно исправить:

```golang
// Текущий код с ошибками:
type Project struct {
    Id uuid.UUID `json:"id"`
    Name string `json:"string"`  // ❌ должно быть json:"name"
}

const {  // ❌ должно быть const (
    ACTIVE State = 1
    INACTIVE State = -1
}

type Version struct {
    Ts int64 `json:"td"` // ❌ опечатка, должно быть json:"ts"
    // ...
}

type Envs struct {  // ❌ должно быть Env (singular), т.к. используется как []Env
    Name string `json:"name"`
    Path string `json"path"`  // ❌ пропущено двоеточие, json:"path"
}
```

**Подтверди исправления или укажи правильные значения.**

---

## Уточнения по командам

1. **`aevs project remove --id {uuid}` имеет комментарий `(or --remove)`:**
   - `--remove` не эквивалентен `--id`
   - Имелось в виду `-r` как короткий флаг для `remove`? Или это описка?

2. **`aevs project read` — нет флага для вывода конкретной версии:**
   - Сейчас показывает все версии проекта
   - Нужен ли флаг `--version {timestamp}` для просмотра конкретной версии?
   Answer: не нужен;
---

## Уточнения по sync

3. **"if version is inactive, server responds w/ latest version data":**
   - "Latest" означает:
     - (a) последнюю по timestamp **активную** версию?
     - (b) последнюю созданную версию (независимо от state)?
   Answer: (a)

4. **При sync создаётся новая версия — откуда берётся `version_name`?**
   - Автоматически (timestamp)?
   - Интерактивный prompt пользователю?
   - Из конфига?
   Answer: интерактивный промпт

5. **Version.Creator — откуда берётся значение?**
   - Из api_key?
   - Из git config user.name?
   - Интерактивный ввод?
   Answer: api_key подразумевает конкретного пользователя с набором пермишнов и username, так вот Version.Creator = username, на данный момент можно захардкодить `root` с пометкой // TODO

---

## Уточнение по "no active version"

6. **В q-001 ответ "provide some variants" не ясен.**
   Варианты поведения при sync, если нет активной версии:
   - (a) Создать новую версию из локальных файлов
   - (b) Показать ошибку "no active version found"
   - (c) Показать список всех версий и предложить выбрать
   
   **Какой вариант предпочтителен?**
   Answer: Если локальные файлы есть, то нужно сформировать новую версию с вопросом о её имени; если нет и локальных файлов окружения нужно вывести ошибку, что нет активных версий и локальных версий тоже. Ситуация кажется невозможной, т.к. версии можно сделать неактивными только в результате мерджа, при этом операция подразумевает создание новой активной версии;

---

## Server Interface

7. **Какой протокол для сервера?**
   - REST API (HTTP/JSON)?
   - gRPC?
   - Другое?
   Answer: рассмотри другие cli tool такого рода, например wrangler для cloudflare

8. **Нужно ли описать endpoints сервера для мока?**
   Например:
   ```
   GET    /projects
   POST   /projects
   DELETE /projects/{id}
   GET    /projects/{id}/versions
   POST   /projects/{id}/versions
   PATCH  /projects/{id}/versions/{ts}
   ```

   Answwer: нам нужен мок веб. сервера, но не сам вебсервер, нужно сделать для этого всё необходимое;
---

## parseLocals vs Config.environments

9. **Как соотносятся parseLocals и environments из конфига?**
   - parseLocals сканирует все `*.env.*` файлы в директории
   - Config.environments содержит маппинг `name → path`
   
   **Вопрос:** При sync используем только environments из конфига, или parseLocals тоже участвует? Если оба — как разрешаются конфликты имён?
   Answer: имена могут быть не уникальными, конфиг заполняется из parseLocals, для добавления новых locals в конфиг нужно сделать это явно, т.е. если конфиг существет, то мы больше не ищем файлы в директориях проекта

---

## Пояснение по "config inheritance"

10. **Что я имел в виду под "inherit from parent directories":**
    
    Пример структуры:
    ```
    ~/projects/
        aevs.yaml           ← глобальный конфиг (api_key)
        my-app/
            aevs.yaml       ← проектный конфиг (project, version, environments)
    ```
    
    При запуске `aevs sync` в `~/projects/my-app/`:
    - Читается `my-app/aevs.yaml`
    - Если `api_key` не указан, ищется в `../aevs.yaml`
    
    **Нужна ли такая иерархия? Или api_key всегда должен быть в проектном конфиге?**
    Answer: конфиг только один, путь до него либо указан флагом, либо он в директории из которой вызывается утилита, наследование не нужно