# LOGPile - Инструкции для Claude Code

## Что это за проект

LOGPile - standalone Go-приложение для анализа BMC/IPMI диагностических архивов с веб-интерфейсом.
Приложение запускает локальный HTTP-сервер, парсит архив, автоматически выбирает подходящий parser по vendor и показывает результат в UI + экспортирует данные.

## Актуальная архитектура

- Язык: Go 1.22+
- HTTP: стандартный `net/http` + `http.ServeMux`
- UI: embedded (`//go:embed`) HTML/CSS/Vanilla JS
- Бинарник: один executable, без внешних зависимостей на runtime
- Порт по умолчанию: `8082` (а не 8080)

## Реальная структура репозитория

```
logpile/
├── cmd/logpile/main.go
├── internal/
│   ├── analyzer/
│   ├── exporter/
│   ├── models/
│   ├── parser/
│   │   └── vendors/
│   │       ├── generic/
│   │       ├── inspur/
│   │       ├── nvidia/
│   │       ├── nvidia_bug_report/
│   │       └── supermicro/
│   └── server/
├── web/
│   ├── static/
│   └── templates/
├── Makefile
└── go.mod
```

## CLI и запуск (актуально)

```bash
# Сборка
make build

# Запуск (авто-открытие браузера включено)
./bin/logpile

# Явный порт
./bin/logpile --port 8082

# Не открывать браузер автоматически
./bin/logpile --no-browser

# Версия
./bin/logpile --version
```

Важно: сейчас **нет** subcommand `serve`, запуск идёт напрямую через флаги.

## Основной runtime-flow

1. `main.go` регистрирует embedded web FS и запускает сервер.
2. `POST /api/upload` принимает архив и передаёт его в `parser.BMCParser`.
3. `DetectFormat()` выбирает parser с максимальным confidence.
4. Результат сохраняется в памяти (`Server.result`) и отдаётся через API.
5. UI строит вкладки: конфигурация, прошивки, сенсоры, серийники, события.

## Поддерживаемые parser modules

- `supermicro` - Supermicro parser
- `inspur` - Inspur/Kaytus parser
- `nvidia` - NVIDIA Field Diagnostics parser
- `nvidia_bug_report` - parser для `nvidia-bug-report.sh`
- `generic` - fallback parser

Реестр parser-ов: `internal/parser/registry.go`, подключение модулей: `internal/parser/vendors/vendors.go`.

## API (фактически в коде)

```
POST   /api/upload
GET    /api/status
GET    /api/parsers
GET    /api/events
GET    /api/sensors
GET    /api/config
GET    /api/serials
GET    /api/firmware
GET    /api/export/csv
GET    /api/export/json
GET    /api/export/txt
DELETE /api/clear
POST   /api/shutdown
```

## Форматы данных и экспорт

- `AnalysisResult` агрегирует: events, sensors, FRU, hardware.
- Экспорт реализован в `internal/exporter/exporter.go`:
  - CSV: серийные номера компонентов
  - JSON: полный `AnalysisResult`
  - TXT: человекочитаемый отчёт

## Важные текущие ограничения (чтобы не ошибаться в задачах)

- Upload через `/api/upload` использует `ParseFromReader()`, где сейчас поддержаны `.tar`, `.tar.gz`, `.tgz`.
- Код распаковки `.zip` есть, но в текущем upload-пути `zip` не обрабатывается.
- Флаг `--file` присутствует в CLI-конфиге, но preload в `Server.Run()` сейчас не выполняется.
- Данные хранятся только в памяти процесса; перезапуск очищает состояние.

## Практические рекомендации для доработок

- Если меняется parser-логика, обновляй `Version()` соответствующего parser-модуля.
- Новые vendor-парсеры регистрируй через import в `internal/parser/vendors/vendors.go`.
- Для API/контрактов проверяй согласованность `handlers.go` и `web/static/js/app.js`.
- Для UI-изменений не забывай, что ассеты embedded через `web/embed.go`.

## Приоритетные следующие шаги

1. Довести поддержку `zip` в upload path (`ParseFromReader`).
2. Реализовать preload из `--file`.
3. Добавить/актуализировать автотесты для parser и HTTP handlers.
4. Расширить vendor coverage (Dell/HPE/Lenovo) по реальным дампам.