llm/AGENTS.md

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.

upo_test mutation scope

• upo_test is an isolated test infobase. The user has authorized full read/write adapter checks there, including controlled SQL saved-state changes and rollback.
• This authorization does not turn an adapter-side marker into a native repository lock. When repository coordination is enabled, keep the configured request/confirmation scope and never claim automatic lock verification in the SQL-only adapter version.

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.