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.

1C SQL adapter deployment

• Deploy the production/external 1C REST SQL adapter and adapter-1c-mcp on docker.cin.su (192.168.200.85), where Codex connects to http://docker.cin.su:8021/mcp. test-docker (docker-test.cin.su, 192.168.200.61) is a separate staging host; do not substitute it for the external MCP endpoint unless the user explicitly requests staging. Do not deploy either service on docker-gpu.cin.su.
• The REST host port is configurable through ADAPTER_1C_HOST_PORT; use the same port in ONEC_ADAPTER_URL for MCP and agent services.
• The adapter SQL-base administration page is http://docker.cin.su:<ADAPTER_1C_HOST_PORT>/admin (default: http://docker.cin.su:8011/admin). Use it to add or update live base connections; do not commit their SQL credentials or generated runtime configuration.
• Before deployment, inspect the selected port and container names. Do not stop, remove, recreate, or otherwise alter unrelated running containers.
• Keep live SQL connection settings in a non-committed deployment .env or mounted runtime configuration file.

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.

1C adapter execution boundary

• Primary correctness rule: the adapter never invents 1C metadata, payload fields, SQL routes, containers, signatures, or object relationships. It decodes only structures evidenced in live 1C SQL storage and encodes only through the corresponding proven reverse codec.
• If decoding is incomplete, a route is ambiguous, or a reverse encoding has not been proven, return an explicit unresolved/unsupported/protocol_incomplete result. Never substitute a plausible-looking structure or write guessed bytes.
• Rule for every agent using the adapter: never invent database structure, 1C objects, modules, forms, fields, SQL joins, BSL fragments, or target files. Before proposing or applying a change, obtain the exact object/module/field and current text or payload from the live base through the adapter. Treat any absent, ambiguous, or unverified item as unknown; report it and stop that branch rather than filling it in from names, conventions, or prior experience.
• The deployed 1C adapter works only through SQL. Its reads, saved-state preparation, and permitted writes use SQL tables such as ConfigSave and ConfigCASSave.
• A human operates Configurator in the adapter's normal workflow. The adapter must not start, automate, emulate, or require Designer/Configurator; do not propose or implement a Designer bridge unless the user explicitly changes this rule.
• A successful SQL write proves only SQL readback. Never claim that a change is visible, accepted, saved, activated, or validated by Configurator unless the human separately confirms it.
• For SQL structures whose complete Configurator protocol is not proven (including __configinfo), return an explicit unsupported/protocol-incomplete result. Do not fabricate containers, signatures, or activation evidence.
• These limits apply to the adapter product, not to its development. While creating, diagnosing, or testing the adapter, Codex may use any necessary authorised tools and evidence sources, including Configurator observation, test infobases, SQL, files, logs, and external research. Do not transfer that development capability into the adapter's runtime contract without explicit user approval.

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.