## Shared Test Docker Host

- Use SSH alias `test-docker` / `docker-test` for the shared test Docker host.
- Host: `docker-test.cin.su` (`192.168.200.61`)
- SSH user: `test`
- Preferred Docker endpoint when Docker CLI is available: `ssh://test-docker`
- Portainer: `http://docker-test.cin.su:9000/`, user `admin`
- Do not store the password in repositories or project files; use an SSH key for persistent access.

## GPU Docker Host

- This project works with local LLM models and uses GPU resources.
- Use `upo_test` as the default 1C test database `base_id` for adapter checks in this project.
- Use `docker-gpu.cin.su` as the deployment target for GPU workloads.
- Prefer GPU-capable Docker deployments on `docker-gpu.cin.su` when running or serving local models.
- For training/download containers on `docker-gpu`, sync the current repo into `Z:\LLM\model-chat-app` first. These containers should read code from the synced app directory, not directly from `Z:\codex\LLM`.
- Do not store credentials, tokens, model secrets, or host passwords in repositories or project files.

## Test-system security profile

- This project currently runs as an isolated test system; use the minimum security profile unless the user explicitly requests production hardening.
- Network-level access control is sufficient for test web interfaces. `ONEC_ADAPTER_SERVICE_TOKEN` is optional when `ONEC_ADAPTER_ALLOW_UNAUTHENTICATED_ADMIN=true` is explicitly set.
- Do not block test deployment only because a service token is absent when the explicit unauthenticated-admin flag is enabled.
- Even in the minimum profile, never commit credentials or passwords, never return stored passwords through APIs, and keep runtime credential files outside git.

## Architecture

- Use the `core + plugins` architecture.
- Put shared platform capabilities in `core`: model registry, inference, storage, training, evals, deployment, and monitoring.
- Put task-specific logic in `plugins`: text, translation, audio, video, and 1C.
- Design every plugin as a future standalone service: keep its API, pipelines, datasets, evals, and configuration inside the plugin folder.
- Keep model binaries and large datasets out of git. Store only manifests, model cards, metadata, scripts, and reproducible deployment configuration.
- For 1C, start with RAG and tool integrations before fine-tuning. Use LoRA or adapter-based fine-tuning when enough curated examples are collected.
- For 1C adapter work, treat object names as the primary selector. When solving tasks, start from names or public refs such as `РегистрСведений.Имя` or `InformationRegister.Name`; if the implementation needs GUIDs, SQL numbers, or internal codes, resolve them internally from the provided names instead of requiring callers to know storage identifiers.