## 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.

## Project Git workflow

- The canonical remote for this project is `https://git.cin.su/m/llm.git`
  (`origin`), with `main` as the shared branch.
- Use HTTPS authentication through Git Credential Manager; never put a
  password or token into a repository file, remote URL, script, or commit.
- After a coherent change has been verified, create a focused commit and push
  it to `origin/main`. Do not commit unfinished work, unrelated user changes,
  generated large artifacts, or secrets.

## 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.
