1C設定構成MCPサーバー

複数の1C設定構成のメタデータ、プラットフォーム構文、クエリ言語に関するリファレンス — BSLでコードを書くエージェント向け。必要最小限の情報を提供する：人間の表現を正確なオブジェクト名に解決する、コード書き出し内の既存プロシージャの検索、そのシグネチャ、本文の限定ウィンドウ、呼び出し・メタデータ・フォームからの逆引き、必要な詳細レベルでのオブジェクト構造、その関連、特定設定構成のバージョンを考慮したプラットフォームメソッドの説明、クエリ言語の構文。

プロジェクトの実ソースに対するgrepの代わりにはならない：サーバーはアップロードされた設定構成のファイル書き出し内でのみプロシージャを検索し、未アップロードの編集は認識しない。ソースの境界はdocs/data-sources.mdに固定されている。

状態 — 2026-08-21時点

最終イメージのサイズは2026-08-21に確認済み：コマンド docker image ls mcp1c:latest --format '{{.Size}}'は357MBを出力した。 これはDocker CLIが表示するサイズ。コマンド docker image inspect mcp1c:latest --format '{{.Size}}'は内部フィールドの77950901バイトを返した； これは別のメトリクスであり、表示サイズの2回目の測定ではない。

設定構成に制限はない。 任意のものをロードできる — 標準（会計、給与、文書管理、小売）および業界特化型：書き出し処理はメタデータを走査するのであって、暗記しているわけではない。書き出されたものを解析する。

重要なのは、設定構成が動作するプラットフォームのバージョンである：それによって、get_syntaxが何を利用可能として表示し、何を後発として隠すかが決まる。8.3.5および8.3.23で検証済み — これは遭遇した範囲の境界であり、ヘルプは8.3.5、8.3.23、8.3.27の3バージョンから統合されている。書き出し処理はその際、8.3.5でコンパイルできる必要がある：下限はサーバーではなく、それによって決まる。

Related MCP server: 1C_MCP_SERVER_OWN

目次

1. 起動 — Docker、ダッシュボード、 関連グラフ、Dockerなし

2. エージェントの接続 — MCPの仕組み、 接続できない場合、トークン、クライアント設定： Claude Code、Codex CLI、 Cursor、VS Code、Qwen Code、 stdio

3. ツール — 呼び出し順序、 ソース、クエリ言語、 プラットフォームバージョン、 ヘルプの統合、 置換

4. データ管理 — ソース、 設定構成のファイル書き出し、 辞書と検索キー、 CLI、 測定ベンチ、 手動サーバー、 データの入手先

5. 仕組み — モジュール、 測定、テスト

6. セキュリティ — トークン、なしで公開されるもの

7. ドキュメント

8. ライセンス — Apache 2.0、「1С」社との関係

1. 起動

Docker（主な方法）

# 1. Положить исходные данные
mkdir -p data/bootstrap
cp ВыгрузкаКонфигурации.zip                     data/bootstrap/
cp /opt/1cv8/8.3.27.2130/shcntx_ru.hbk          data/bootstrap/

# 2. Поднять
docker compose up -d --build

# 3. Проверить
curl http://localhost:5001/health

{"status":"ok",
 "configurations_total":2,
 "syntax_loaded":true,
 "query_language_loaded":true,
 "configurations":["РозницаДляКазахстана","ОтраслеваяКонфигурация"],
 "syntax":["8.3.5.1570","8.3.23.1997","8.3.27"]}

プラットフォームヘルプとクエリ言語は異なるソースであり、異なるフィールドを持つ：syntax_loadedは前者のみに関係し、syntaxはロードされたヘルプのバージョンを列挙する。設定構成名とヘルプのバージョンは、読み取りチェックを通過したリクエストにのみ返される；トークンなしではstatus、カウンター、2つのフラグのみが残る。

data/bootstrap/にあるものはすべて起動時にインデックス化される：*.zip — 設定構成の書き出し、*.hbk — プラットフォームヘルプ。同じファイルは再解析されない：ハッシュで照合される。

慣習的にbootstrap/に置かれた設定構成のファイル書き出しは適さない — サーバーはアーカイブの構成（コードはあるが、マニフェストmanifest.json / manifest.xmlがない）でそれを認識し、解析を試みない：それはギガバイト単位であり、起動のたびに処理することはできない。エラーの代わりに、起動メッセージのリストにその名前と、そのようなファイルを置く場所のリマインダー — data/incoming/、下記の「設定構成のファイル書き出し」セクション — が表示される。

./dataディレクトリはコンテナに/dataとしてマウントされる。その中でサーバーはソース、インデックス、キャッシュ、registry.jsonを保持する；レジストリ内のパスは相対的であるため、ディレクトリは開発マシンとコンテナの間で移動できる。

data/は完全にgitの外 — これはボリュームであり、リポジトリの一部ではない。ディレクトリのコピーで移行される。したがって、クローン後はヘルプを自分で配置する必要がある：リポジトリはそれを含まず、含むこともできない。これは「1С」社のコンテンツである。

コード変更後は、コンテナを再作成する必要があり、再起動ではない：

docker compose up -d --build --force-recreate

restartは以前のイメージで以前のコンテナを起動するだけであり、変更は適用されない。

ポートについて。 サーバーは外部に5001で公開され、コンテナ内では8000で待ち受ける — docker-compose.ymlの5001:8000のポートフォワード。このファイル内のすべてのアドレスは外部、つまり5001である。他のサービスが使用中 — フォワードの左側を変更し、右側には触れない：EXPOSEとイメージのヘルスチェックがそれに依存している。

ダッシュボード

http://localhost:5001/ — 6ページ：

アップロード — 何が見えるか、いつ見えるか

アップロードは2段階で行われ、表示も異なる。

ファイル転送 — 「ソース」ページのバー：パーセント、容量、速度、残り時間の見積もり。これはブラウザが計算するものであり、気まぐれではない。 サーバーは転送の進行状況を見えない：await request.form()はボディが完全に到着したときにのみ制御を返し、タスクはその後で作成される。実ソケットで検証済み：40MBが8.1秒かかり、その間に2番目の接続からの32回の/sourcesポーリングは1つのタスクも確認できなかった。localhostでは違いはないが、リモートサーバーでは空の画面の数分間になる。

同時に500MBの制限は送信前にチェックされる：以前は超過ファイルが完全にアップロードされてから拒否されていた。

解析 — 同じページの「アップロード」テーブル：「受付中」→「解析中」→「完了」または理由付きの「エラー」。作業中はページが自動更新される（meta refresh、2秒ごと）。

バーにはJSが必要で、テーブルには不要。JSを無効にしてもフォームは通常どおり動作する：ファイルは送信され、タスクは作成され、状態はテーブルで確認できる — 転送中のバーがないだけである。

関連 — オブジェクトのグラフ

/graphはオブジェクトの近傍を描画する：種類による色、リンクの方向による矢印、ホバーによるエッジのラベル。ノードのクリックでその周囲のグラフを構築し、ドラッグで移動、ホイールでズーム。近傍の制限はページで選択（15…400）、切り詰めは数値で表示される — 「102件中30件を表示」。

「触ると何が壊れるか」に答える：オレンジ色のドキュメントに囲まれたレジスターは、誰がそれを動かしているかを即座に示す。

深さは常に1ステップ。 頻繁に使われるディレクトリから2ステップで千のオブジェクト、3ステップで設定構成の3分の1に達する；それ以上は、追加属性のようなほぼすべてをすべてに接続する共通メカニズムを経由する。関連数による閾値でそれらを切り捨てることはできない：そのようなノードは34の関連を持つが、意味のあるСправочник.Пользователиは323である。したがって、ノードを展開するのはヒューリスティックではなく人間である — どこへ行くべきでないかが見える。

エージェントにはそのようなツールは意図的に存在しない。 2ステップでグラフは数千オブジェクトにまで成長し、共通のメカニズムを単純なしきい値で切り分けることはできない。意味のあるノードは技術的なノードよりも多くのリンクを持つことがあるからだ。専用ツールは、出力制限の測定可能なルールと一緒にのみ戻される。正確な次のステップは、当面は人間がインタラクティブグラフ上で選択する。

ミスはブラウザから離れずに修正できる。リクエストページでは、各フレーズに「違う — エイリアスを作成」リンクがあり、フレーズがすでに入力された辞書へと導く。編集は即座に反映される — インデックスは再構築されず、再起動も不要だ。

読み取りはAPI_TOKENで保護され、書き込みはADMIN_TOKENで保護される。 API_TOKENが設定されていない間は、アドレスに到達できる誰でも読み取ることができる — 設定構造やカスタマイズも含めて。localhostでは許容できるが、ネットワーク上のサーバーでは許容できない。

トークンが分離されているのは、読み取りトークンが各MCPクライアントの設定に含まれ、それとともに漏洩するためだ。エージェントにソースを削除する権限があってはならない。管理者トークンは読み取りトークンとしても機能する — 2つのヘッダーを保持する必要はない。

// .mcp.json — как клиент передаёт токен
{"mcpServers": {"1c": {"type": "http", "url": "http://localhost:5001/mcp",
                       "headers": {"X-Api-Token": "..."}}}}

ASCIIのみ: HTTPヘッダーはlatin-1でエンコードされ、キリル文字は届かない。 /healthはヘルスチェック用に公開されたままだが、設定名はトークンによってのみ返される。

辞書のアップロード、削除、編集にはADMIN_TOKENが必要だ — /admin/reloadと同じもの。これがないと、これらのエンドポイントは「閉じられている」のではなく、存在しない。トークンはフォームに一度だけ入力され、ブラウザに送信されるのはトークンではなくセッションIDだ。

docker-compose.ymlの隣にある.envで設定される — すべての変数を含むテンプレートは.env.exampleにある:

cp .env.example .env
python3 -c "import secrets; print(secrets.token_urlsafe(32))"   # значение
docker compose up -d --force-recreate

結果内の名前はカードへのリンクだ: オブジェクトの場合、型、テーブル部分、動作を含む属性情報、プラットフォーム要素の場合、シグネチャ、パラメータ、利用可能性、登場バージョン。エージェントが受け取るのと同じテキストで、brief / fields / fullの切り替え付き。属性には独自のカードはない — リンクは所有者オブジェクトへと導く。

「リクエスト」ページは「サーバーがなぜこれを返したのか」という質問に答える: 各ヒットの横に理由が表示される — 完全一致、辞書からのエイリアス、クエリの全単語。これにより、ミスをどう修正するかがわかる — 同義語、エイリアス、または重みで。

ヘルプの解析には数秒かかる: ページはその後に応答するが、MCPクライアントは遅延しない — インデックス作成は別スレッドで行われる。

Dockerなし

リポジトリのコピーから — テストとCLIの実行方法と同じ:

python3 -m venv .venv && .venv/bin/pip install -r requirements.txt
PYTHONPATH=src .venv/bin/python -m mcp1c.server --host 0.0.0.0 --port 5001

またはパッケージとして — その場合PYTHONPATHは不要で、3つのコマンドが追加される:

pip install .

mcp1c-server --host 0.0.0.0 --port 5001   # = python -m mcp1c.server
mcp1c reg-list --data data                # = python -m mcp1c.cli
mcp1c-bench --help                        # = python -m mcp1c.bench

モジュール実行(python -m mcp1c.server)はこの場合でも機能する: コマンドは別名の同じエントリポイントだ。すべてのキーは「データ管理」セクションに記載されている。

2. エージェントの接続

サーバーは公式SDKの標準トランスポートでMCPプロトコルを実装しているため、任意のMCPクライアントに適合する。HTTPのラッパーは一切不要だ。

サポートされている両方のトランスポートは公式MCPクライアントで検証されている: initializeハンドシェイク、tools/list、tools/call、プロトコル2025-11-25。

廃止されたHTTP+SSEトランスポートはサポートされていない: --transport sseは、データの読み取りとサーバー起動の前に不正な値として拒否される。古いクライアントには、streamable-httpモードまたはstdioによるローカル起動が必要だ。

仕組み

何かが接続できない前に理解しておくと役立つ。アドレスは1つ — /mcp で、ツールごとのエンドポイントはない。どのツールが呼び出されるかは、パスではなくリクエスト本文に書かれている。

次に、2つの異なるメカニズムがあり、混同すべきではない:

接続時にクライアントはPOST initializeを送信する — サーバーは名前、バージョン、instructionsテキストで応答し、ヘッダーでmcp-session-idを返す。次にPOST tools/listがツールを一括で返す: 名前、説明、パラメータのJSONスキーマ。これらすべては、人間が最初の単語を入力する前にモデルのコンテキストに配置される。モデルは必要になったときに説明を取得しに行かない — すでに手元にある。

ここから、説明を編集する際に重要な結果が生じる: 説明は、モデルが1つもツールを呼び出さなくても、セッション全体を通じてウィンドウ内のスペースを占有する。

ロードされているものに関係なく、ツールは常に10個ある。 セットは変数ではなく契約だ: ツールは相互に関連しており、実稼働サーバーでは、設定、コード、プラットフォームヘルプ、クエリ言語のソースを独立してロードできる。tools/listとinstructionsの契約サイズは、レジストリの状態に依存しない。

ここから、事前に知っておくべき直接的な結果が生じる: ソースがロードされていなくても、そのツールのコストは支払うことになる。 プラットフォームヘルプがない場合、search_syntaxとget_syntaxはコンテキスト内にあり、「ヘルプは接続されていません」と答えるために1,185トークンかかる。設定が1つの場合のcompare_configurationsは、「最低2つ必要です」という回答のために262トークンかかる。これはツールを選択して除外するのではなく、ソースをロードすることで解決される: 動的セットは2026-08-19に試され、独立したソースが単一のセッション契約を維持する必要があるため、中止された。

したがって、説明は簡潔に書かれ、詳細はツール自体の出力に委ねられる: そのコストは必要なときにのみ支払われる。

GET /mcpは「間違ったPOST」ではなく、同じアドレス上の3番目のメソッドだ: これはサーバーからクライアントへのメッセージストリームを開き、すでに取得済みのmcp-session-idを必要とする。DELETE /mcpはセッションを閉じる。

クライアントが接続しない場合

ログの応答コード(docker logs -f mcp1c)が原因を示す:

実際の事例: Qwen Codeは、その設定にurlキーがあったため接続できなかった — Gemini CLIファミリー(Qwenはその形式を継承)では、これは古いSSEトランスポートを意味し、クライアントはGETから始めて400を受け取った。httpUrl — つまりstreamable-http — では、接続は即座に成功する。

トークン: クライアント設定に追加するもの

サーバーでAPI_TOKENが設定されている場合、各クライアントはヘッダーでそれを送信する義務がある。ヘッダーがないと/mcpは401で応答し、エージェントはツールをまったく見ることができない。

2つのヘッダーのどちらでも機能する — サーバーは両方を受け入れる:

X-Api-Token: <токен>
Authorization: Bearer <токен>

つまずく3つのこと:

• ASCIIのみ。 HTTPヘッダーはlatin-1でエンコードされ、キリル文字のトークンは届かない。生成方法: python3 -c "import secrets; print(secrets.token_urlsafe(32))"。

• クライアントにはAPI_TOKENを入れ、ADMIN_TOKENではない。 管理者トークンも受け入れられるが、クライアント設定はgitとバックアップに送られる: 漏洩した読み取りトークンは閲覧を可能にし、漏洩した管理者トークンはソースを削除する権限を与える。

• stdioはトークンをまったく必要としない。 そこではクライアントがプロセスを起動し、ネットワークは関与せず、チェックするものもない。クライアントがヘッダーを設定できない場合 — これが有効な回避策だ。

クライアントを設定する前に、サーバーがトークンを認識していることを確認する:

curl -s -o /dev/null -w '%{http_code}\n' -X POST \
  -H 'x-api-token: ВАШ_ТОКЕН' \
  -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}' \
  http://localhost:5001/mcp

200 — トークンが受け入れられた。401 — トークンが間違っているか、ヘッダーが届いていない。

シークレットをコミットしない方法

.mcp.jsonおよび類似のファイルは通常、リポジトリに置かれる。選択肢:

1. 変数置換 — クライアントがサポートしている場合(Claude Codeはサポート): "X-Api-Token": "${MCP1C_API_TOKEN}"、変数自体は~/.zshrcに。 gitに送られるのは変数名であり、値ではない。

2. ファイルをgitの管理外に出す: git rm --cached .mcp.json && echo ".mcp.json" >> .gitignore。

3. 設定をプロジェクトではなくクライアントのユーザー設定に置く — その場合、リポジトリはまったく関係ない。

Claude Code

プロジェクトルートの.mcp.jsonファイル:

{
  "mcpServers": {
    "1c": {
      "type": "http",
      "url": "http://localhost:5001/mcp",
      "headers": { "X-Api-Token": "${MCP1C_API_TOKEN}" }
    }
  }
}

headersブロックは、サーバーでAPI_TOKENが設定されている場合にのみ必要だ。値は環境変数から取得され、ファイルをリポジトリに保持できるようにする:

echo 'export MCP1C_API_TOKEN=ваш_токен' >> ~/.zshrc && source ~/.zshrc

またはコマンドで:

claude mcp add --transport http 1c http://localhost:5001/mcp \
  --header "X-Api-Token: $MCP1C_API_TOKEN"

Codex CLI

~/.codex/config.tomlまたはプロジェクト内の.codex/config.toml:

[mcp_servers.mcp1c]
url = "http://localhost:5001/mcp"

# Только если задан API_TOKEN. Имя ключа для заголовков у Codex менялось между
# версиями — сверьтесь со своей (`codex --help`, раздел MCP). Не подхватилось —
# используйте stdio, там токен не нужен вовсе.
[mcp_servers.mcp1c.http_headers]
X-Api-Token = "ваш_токен"

Cursor

.cursor/mcp.json:

{
  "mcpServers": {
    "1c": {
      "type": "streamable-http",
      "url": "http://localhost:5001/mcp",
      "headers": { "X-Api-Token": "ваш_токен" }
    }
  }
}

VS Code (Copilot)

.vscode/mcp.json — ここではキー名はservers:

{
  "servers": {
    "1c": {
      "type": "http",
      "url": "http://localhost:5001/mcp",
      "headers": { "X-Api-Token": "ваш_токен" }
    }
  }
}

Qwen Code

Gemini CLIの形式で、キーがトランスポートを選択する — これが唯一の注意点だ:

{
  "mcpServers": {
    "1c": {
      "httpUrl": "http://localhost:5001/mcp",
      "headers": { "X-Api-Token": "ваш_токен" }
    }
  }
}

httpUrl — streamable-http、これが該当する。この形式のurlは古いSSEトランスポートを意味する: クライアントはGET /mcpでハンドシェイクを開始し、400 Missing session IDを受け取って接続できない。

その他のクライアント

Windsurf、Antigravity、Cline、Roo Code、コンソールエージェント — 記述形式は同じだ: トランスポートタイプ、URL、そしてAPI_TOKENが設定されている場合はヘッダーブロック。違いはファイル名とトップレベルのキー(mcpServersまたはservers)のみ — 特定のクライアントのドキュメントを確認すること。

クライアントがヘッダーを設定できない場合 — 行き詰まりではない: stdioで接続する。そこではネットワークがないためトークンは不要だ。

stdioによるローカル起動

クライアントがサーバーを自分で起動する必要がある場合。ここではトークンは不要だ: プロセスはクライアントによって起動され、通信はプロセスのチャネルを通じて行われ、ネットワーク経由ではない — チェックするものも、防御すべき相手もいない。

{
  "mcpServers": {
    "1c": {
      "command": "python3",
      "args": ["-m", "mcp1c.server", "--transport", "stdio", "--data", "/путь/к/data"],
      "env": { "PYTHONPATH": "/путь/к/проекту/src" }
    }
  }
}

3. ツール

セットは固定されており、意図的に小さい: 各ツールは常にエージェントのコンテキストに存在する。新しいツールは、個別のユーザータスクのためにのみ追加され、内部インデックスごとには追加されない。

config は、複数の構成が読み込まれている場合に必須である。サーバーは 意図的にそれを黙って補完しない — そうしないとエージェントが他人のベースに基づいてコードを書き、 誰もそのことに気づかないからだ。

list_configurations は、メイン構成と各拡張のコードインデックスの実際の状態を表示する: 準備完了、ステージと進捗付きで構築中、エラー、またはコード未読み込み。準備完了の拡張については、4つのアノテーションによるオーバーラップ数、影響を受けるモジュール数と独自プロシージャ数、およびそのコードにアクセスするための準備済みパラメータ extension が出力される。不明または破損したバリアントを持つ準備完了コーパスは、「制限付きで準備完了」 状態と呼ばれる。3つのシェルはすべて、同一世代の正確な集計を受け取るが、それぞれのタスクに応じて表示する。list_configurations と reg-list は詳細な診断を保持する: カテゴリ、安定した順序での最初の20件の問題、残りの正確な数。アドレス指定不可能な候補については、物理名とローカルパスなしで、単に通し番号のみが出力される。/sources はアドレスのフィードの代わりに、数、パーセント、明示的な分母を持つ3つの照合可能なテーブルを表示する: モジュールとプロシージャ、フォーム構造、フォームモジュール。

各コーパスの完全なリストは、単一の最新ファイル data/logs/code-<sha256 source_id>.json にアトミックに格納される。メイン構成と各拡張は異なるログを持つ。再読み込みは自分のファイルのみを置き換え、ソースの削除はそれを削除する。破損している、世代が異なる、または現在のインデックスと内容的に乖離しているログは、最新として表示されず、準備完了のインデックスから再構築される。フォーム構造は、完全に読み取られたもの、部分的に読み取られたもの、未読み取りのものを別々に表示する。 schema v1 の契約と不変条件は以下に記載されている。警告は不完全な回答の上にあり、直接述べている: ゼロカウンターは隠れたデータがないことを証明しない。

コードカバレッジログ — schema v1

1つのファイルは、独立して削除可能な1つのソース <Конфигурация>:modules または <Конфигурация>:ext:<Расширение> に属する。ソース名はパスに含まれない: ファイルは完全な sha256 source_id にちなんで名付けられる。

{
  "schema_version": 1,
  "kind": "module_coverage",
  "source": {
    "id": "Отраслевая конфигурация:modules",
    "kind": "modules",
    "sha256": "...",
    "loaded_at": "2026-08-24T12:00:00+00:00",
    "selection_version": 4,
    "locator_generation": 3,
    "code_version": "1.0.0"
  },
  "identity": {
    "source_id": "Отраслевая конфигурация:modules",
    "source_sha256": "...",
    "generation": 3
  },
  "coverage": {
    "modules": {
      "total": 2,
      "source_available": 1,
      "empty": 0,
      "partial": 0,
      "unreadable": 0,
      "conflict": 0,
      "compiled_without_source": 1
    },
    "procedures": {"total": 1, "full": 1, "partial": 0},
    "form_structures": {
      "total": 1, "full": 0, "partial": 1, "unavailable": 0
    },
    "form_modules": {
      "total": 1, "read": 1, "empty": 0, "missing": 0, "unreadable": 0
    },
    "limitations": {
      "categories": {"compiled_without_source": 1, "unknown_marker": 1},
      "occurrences_total": 2,
      "problem_rows_total": 2,
      "unknown_markers": 1,
      "known_markers_incomplete": 0,
      "unsupported_addresses": 0,
      "broken_containers": 0,
      "unreadable_bodies": 0,
      "budget_exceeded": 0,
      "body_conflicts": 0,
      "compiled_without_source": 1
    }
  },
  "problems": [
    {
      "category": "unknown_marker",
      "address": "ОбщаяФорма.Пример",
      "ordinal": 0,
      "reason": "маркер form не поддержан",
      "marker": 99
    },
    {
      "category": "compiled_without_source",
      "address": "ОбщийМодуль.Пример",
      "ordinal": 0,
      "reason": "скомпилированный модуль без исходника",
      "marker": null
    }
  ]
}

カテゴリ modules、procedures、form_structures、form_modules は合計で自分の total と一致しなければならない。両方のフォームテーブルは1つの分母を持つ。problem_rows_total は完全な problems の長さに等しい。address は、正規アドレスを証明できない場合 null に等しく、その場合 ordinal は候補の決定論的な番号である。marker は、読み取られた form 構造のマーカー、または問題がそれに関連しない場合は null を格納する。identity はログを sha256 とロケーターカタログの世代に結び付ける。

ファイルには、絶対パス、生の例外、トレースバック、トークン、BSL 本体、生の form レコードは含まれない。カタログはシンボリックリンクを辿らずに開かれ、一時ファイルはその中に作成され、最終ファイルをアトミックに置き換える。書き込みの失敗はコーパスの準備完了を取り消さない。

get_object は detail に応じてコード情報を追加する: brief ではコードプロバイダーにアクセスせず、fields ではカウンター付きの1行を返し、full ではオブジェクトのモジュールとすべてのフォームを内容なしで列挙する。フォームは、独立した XML ディスクリプタ、Form.xml、Form.bin、フラットな .Form、または単一のフォームモジュールという、任意の証拠によって可視のままである。 インデックスが構築中、エラーで終了、または未読み込みの場合でも、オブジェクトのメタデータはコードの正直な状態とともに返される。get_related は、プロシージャが読み込まれた拡張によって実際にオーバーラップされている関連オブジェクトをマークする。拡張の独自プロシージャはそのようなマークを作成しない。fields と full では、オブジェクトカードはフォームに関連する理由を共通の制限なしに列挙するため、未読み取りのフォームが誤った「フォームなし」になることはない。プロシージャと関連のツールも、部分的な結果の上に警告を配置する。世代の変更は、カウンターと問題とともに応答全体を繰り返す。

search_procedures は2つのレベルを組み合わせる。名前の完全一致は、非エクスポートを含む任意のプロシージャを見つける。単語、語形変化、ヘッダーコメントによる検索は、エクスポートされたもののみで機能する。各レベルで limit は個別に設定され、1から50までの整数でなければならない。応答には、アドレス Модуль::Имя、ディスクからのシグネチャ、エクスポート性、行、確認済みの呼び出し箇所の数、および解決できなかった同名の箇所の個別カウンターが含まれる。拡張アノテーションのブールインデックスは中立的に呼ばれる: 元のプロシージャの完全なオーバーラップとして &После や &Перед を出すことはない。シグネチャと本体は RAM に格納されない。 階層的な .bsl、フラットな .txt、およびソースコンテナ Form.bin/.Form の module レコードは、同じレクサーを通過する。検索とその後のカードは、アドレスからパスを復元するのではなく、同じ世代のロケーターを使用する。

scope がない場合、検索はグローバルである。明示的な scope="Документ.ЧекККМ" はオブジェクトのすべてのモジュールを引き上げ、scope="ОбщийМодуль.ОбщегоНазначения" または別の正確なアドレスは1つのモジュールを引き上げる。残りの結果は下に残る。スコープは query から推測されない。extension は読み込まれた拡張を正確に1つ選択する。それがない場合、検索はメイン構成のみで行われる。

get_procedure は検索からの正確なアドレスを受け取る。:: のないモジュールアドレスは、本体なしの目次を返す。Модуль::Имя はシグネチャ、コンパイルコンテキスト、本体を返す。start_line は0から始まり、lines は1から200までの整数でなければならない。長い応答には、行をスキップせずに次のウィンドウへの準備済み呼び出しが含まれる。選択された拡張の場合、&После、&Перед、&Вместо はその本体を表示する。&ИзменениеИКонтроль はメイン構成の本体と、#Вставка/#Удаление の逐語的なブロックのみを表示する。他の読み込まれた拡張については、ツールは本体の上に警告するが、そのコードを応答に混ぜることはない。シグネチャと本体は1つの応答のためにディスクから読み取られ、RAM に残らない。 同じロケーターはキャッシュと再起動を生き延びる: 読み取り中にソースが置き換えられた場合、応答全体が新しい世代で繰り返され、2つの世代の部分が混ざることはない。

get_callers は正確なアドレス Модуль::Имя のみを受け取る。まず、確認済みの呼び出し箇所をモジュールごとにグループ化し、所有者プロシージャを命名する。次に、メタデータグラフからのイベントサブスクリプションとスケジュール済みジョブを表示し、その後に Form.xml からのフォーム要素とイベントを表示する。limit は1から50までの整数でなければならない。切り捨て後も、箇所とモジュールの正確な数が残る。ディスクリプタまたはコンテナレコード自体は、ハンドラーの不在を証明しない。位置セマンティクスが証明されていない場合、ツールは部分的なカバレッジを報告する。Form.xml のステータスは別途格納されるため、隣接するコンテナに欠陥があっても、正常な XML バインドは利用可能なままである。解決されたモジュールのない同名プロシージャの呼び出しは別途出力され、要求されたアドレスに帰属しない。2つのプロシージャが同じ物理行にある場合、所有者は推測されない。ツールはモジュールテキストを読み取らない。空の応答は、Выполнить、ОписаниеОповещения、ПодключитьОбработчикОжидания を介した文字列呼び出しがインデックス化されないことを思い出させる。

プロバイダーが知らないこと

• 単語による検索はエクスポートされたプロシージャのみで行われる。非エクスポートは正確な名前または既知のモジュールの目次を通じて見つけることができる。

• 名前が Выполнить、ОписаниеОповещения、ПодключитьОбработчикОжидания に文字列として渡される動的呼び出しはインデックス化されない。

• コンパイル済みの共通モジュールには利用可能なソースがない: アドレス自体は見えるが、その中のプロシージャ、呼び出し、シグネチャ、本体は見えない。

• コンテナ構造 Form.bin/.Form では、フラットなエクスポートを含め、括弧文法とルートマーカー 19、20、23、25、26、27 は証明されているが、位置フィールドの目的は証明されていない。したがって、そのようなフォームは部分的に読み取られたものとして見え、そこからの属性、要素、イベントは推測されない。完全な構成とバインドは引き続き Form.xml からのみ利用可能である。XML ディスクリプタは別途、UUID、名前、シノニム、フォームタイプを提供する。

• 正確なモジュールに解決されない同名の呼び出しは、要求されたプロシージャに帰属せず、別途表示される。

1つの名前が同時に2つのドメインに存在することがある: СтрНайти はプラットフォーム (8.3.6以降) とクエリ言語の両方にある。その場合、get_syntax はそれぞれの準備済みアドレスを持つ同名のものを列挙し、呼び出しを出力の文字列で繰り返すことができる:

get_syntax("СтрНайти")                    → Одноимённых элементов: 2
                                            - `Глобальный контекст.СтрНайти` — Метод, с 8.3.6
                                            - `Запрос.СтрНайти` — Функция запроса
get_syntax("Запрос.СтрНайти")             → карточка функции языка запросов

修飾子 Запрос. が必要なのは、クエリ言語の要素には所有者がないためだ。プラットフォームのもののように Объект.Член で名前を付けることはできない。

呼び出しの順序 — そしてそれを破ると失われるもの

list_configurations
├─ search_objects → get_object → get_related
├─ search_procedures → get_procedure → get_callers
└─ search_syntax → get_syntax

コードのチェーンでは、各ステップが前のステップにはない情報を追加する。search_procedures がない場合、正確なアドレスを事前に知っている必要があり、目的とスコープによる検索が失われる。get_procedure がない場合、シグネチャ、コンパイルコンテキスト、プロシージャ本体、拡張の正確なセマンティクスが表示されない。get_callers がない場合、編集の直接的な結果の検証がない: 確認済みの呼び出し箇所、メタデータのバインド、フォームイベント。

ステップ get_object はスキップできない。 検索は名前とカウンターのみを返す。コードが依存するすべてのものはオブジェクトカードに存在する:

• レジスタの種類と周期。 СрезПоследних は周期情報レジスタにのみ存在し、非周期のものは 603 中 566;

• 仮想テーブルフィールドの準備済み名前。 クエリではリソース Количество は КоличествоОстаток、КоличествоОборот、КоличествоПриход と呼ばれる — コンフィギュレーターではそのような名前はどこにも見えず、プラットフォームが生成する;

• サブコント限度、対応、グラフリソース — それらなしでは СубконтоДт1 のようなフィールドに名前を付けるものがない;

• 無制限長の文字列。 タイプに直接マークされている: Строка (неогр. — только через ПОДСТРОКА) 対 Строка(200)。そのようなフィールドはそのままクエリに置くことはできない — プラットフォームは比較もグループ化も並べ替えも許可しない。そのようなフィールドは実在の構成の文字列の23%から38%を占めるため、それらが出現するカード (20 522 中 2 474) では、フィールドリストの前に レシピ付きの但し書きが印刷される。

search_objects の直後に書かれたクエリは正しく見え、「フィールドが見つかりません」で落ちる。get_object からのみ得られるものの例:

## Таблицы запроса
- `РегистрНакопления.ТоварыНаСкладах.Остатки`
  измерения: Склад, Номенклатура, Характеристика
  ресурсы: КоличествоОстаток, РезервОстаток

もう1つの同じようなもの — そしてそれは2026-08-18の実在のミスによって発見された。エージェントは長さ制限のない文字列でクエリをグループ化した。データは正しく渡したが、違いは括弧内の数字の欠如によってのみ読み取れた:

> **Строки неограниченной длины** помечены `(неогр.)`. Платформа не даёт их
> сравнивать, группировать и упорядочивать и не пускает в РАЗЛИЧНЫЕ,
> ОБЪЕДИНИТЬ и агрегатные КОЛИЧЕСТВО, МИНИМУМ, МАКСИМУМ. Ограничивайте
> длину — одинаково в списке выборки и в группировке:
>
>     ПОДСТРОКА(КодСкидки, 1, 100) КАК КодСкидки
>
> Длину подбирайте по смыслу поля: 100 — не универсальное число.

## Реквизиты

- `КодСкидки` — Строка (неогр. — только через ПОДСТРОКА) // Код скидки
- `КодМаркировки` — Строка(200) // Код маркировки

レシピは注記にも、フィールド行そのものにもあり、これは冗長ではない。 初版は注記をカードの最後の段落に印刷していた。生きたエージェント 2026-08-18 が get_object を detail=fields で呼び出し、それを丸ごと取得した——それでも そのようなフィールドでグループ化した。注記はフィールド行より721トークン後ろにあり、決定は名前をコピーする場所で下される。同じ教訓はすでに ツールの説明に記録されていた:ルールは読まれる場所で機能し、丁寧に置かれた場所では機能しない。

各禁止事項は検証済み:集計関数はヘルプからの引用、残りの5つは 記録されたエラーテキスト付きの実データベースでの実行。ヘルプは 6つの集計関数のうち3つでのみ制限を知っており、グループ化、順序付け、РАЗЛИЧНЫЕ、ОБЪЕДИНИТЬ、比較については沈黙している——つまり 正直に読んだエージェントはこれを知ることができなかった。由来別の内訳は docs/data-sources.md の 「カード内の注記」セクション。

古い構成でプラットフォーム関数を呼び出す前に——get_syntax。 利用できないものはマークされ、置換レシピが記録されていればそこにも置かれている。

ソースは独立している

5つあり、それぞれ個別に接続される:

クエリ言語は別のソース

同じプラットフォームインストールディレクトリからの shquery_ru.hbk。127ページ: 52関数、67キーワード、8記事。通常のソースとしてロードされ、 プラットフォームヘルプと同じ検索インデックスに入る——別のツールで検索する 必要はなく、search_syntax が両方を見つける。

ファイル自体にバージョンはない——全129ページで検証済み:「8.3.x」と「バージョンから」の言及はゼロ。しかしクエリ言語は変化する:リリース 8.3.20 は25の関数を追加し、その中には СтрНайти、Лев、Прав、ВРег、НРег、 СтрЗаменить、Окр、Цел と全三角関数が含まれる。

バージョンを取得する場所がない:プラットフォームヘルプはクエリ言語関数をまったく説明していない (ПОДСТРОКА — 25 511要素でゼロ一致)。したがってバージョンは キュレーションされたテーブル query_versions.py が設定する——1С のリスト「リリース 8.3.20 以降にクエリ言語に追加された関数」による。残りの27関数には バージョンが割り当てられない:それらは常にあった。

その後は通常のフィルタが機能する:8.3.5 の構成はこれらの関数を見ず、 8.3.23 では見る。

テーブルはデータで検証される——異なるプラットフォームの2つのヘルプの比較による。古いものに なく新しいものにあるものは、それらの間に出現したものであり、それにはバージョンが 付いていなければならない:

python3 tools/lab/compare_query_help.py <старая.hbk> <новая.hbk>

2026-08-19 の実行、8.3.5.1570 対 現在:出現29、カバー29、誤検出 0。誤検出は最悪のエラー:すでに古いヘルプにあった要素が バージョンでマークされると、それが存在する構成から隠れてしまう。

インスタンスはサーバーごとに1つ:再ロードは以前のものを置き換える。

ページのテーブルは表示されるが、検索されない。 このヘルプではテーブルのセルが <TD> 内の段落でマークアップされており、個別の解析なしではカードが テーブルを値の列として印刷していた:「Товар / Количество / Номер / Сантехника / 104 / …」 20行以上連続で。現在はテーブルが個別のフィールドで解析され——127ページ中31ページに51テーブル——テキスト内の適切な場所に印刷される: 2つの例があるページは各結果をそれぞれの例の下に表示する。検索インデックスにはテーブルの内容は入らない。

このヘルプのテーブルは2つの異なる性質があり、異なる方法で解析される:

CSSクラスではなくマークアップで区別される:class=SimplyTable はすべてに付いているわけではない——7つの実際のテーブルはそれなし。特徴はジオメトリ:データテーブルでは すべての行が同じ幅であり、図では幅が不揃いで、1本の縦線からなるセルがある(これは描かれた線であり、値ではない)。

壊れたマークアップは明示的に名前が挙げられる。 閉じられていない <TABLE> のあるページは テーブルなしで解析されるが失われず、その名前はソースの警告に入る:ロード出力の行として(mcp1c.cli reg-add)と ダッシュボードの「ソース」ページの個別の行として。通常より貧弱なカードを黙って渡すことはできない:単にそれが存在しないヘルプと 区別がつかないからだ。

名前の半分はプラットフォームの名前と一致する(127中57)——ГОД、МЕСЯЦ、 ПРЕДСТАВЛЕНИЕ は両方にある。クエリに関する質問がプラットフォームメソッドに 逸れないように、「クエリ内」、「クエリテキスト内」、「選択内」のような言い回しは クエリ言語要素にソフトなブーストを与える。意図的にソフト:確信を持って 分離された場合、プラットフォーム要素が最初に残る——「クエリでパラメータを設定する方法」は Запрос.УстановитьПараметр についてかもしれない。

config パラメータは、複数の構成がロードされている場合必須。 デフォルトでは何も代入されない:黙った選択は、エージェントが他人の構成に基づいてコードを書き、 誰もそれに気づかないことにつながる。

応答はプラットフォームのバージョンに依存する

同じ呼び出し、2つの構成:

get_syntax("СтрШаблон", config="Розница")     → 8.3.23
# Метод: Глобальный контекст.СтрШаблон
с версии платформы 8.3.6
Доступность: ТонкийКлиент, ВебКлиент, Сервер, ТолстыйКлиент, …

get_syntax("СтрШаблон", config="Отраслевая")  → 8.3.5
# `Глобальный контекст.СтрШаблон` недоступен в этой конфигурации
Элемент существует, но появился в 8.3.6, а конфигурация работает на 8.3.5.1570.
Использовать нельзя — код не скомпилируется.

プラットフォーム 8.3.5 の場合、出力から6 539要素が削除され、8.3.23 の場合は874。警告ではなく フィルタリングによる:警告はエージェントが見落とすが、出力に存在しないメソッドは 見落とせない。

利用可能性フィールド(サーバー / シンクライアント / ウェブクライアント / モバイル)は必ず 読むこと:クライアントコンテキストからのサーバーメソッドの呼び出しはコンパイルされない。

複数バージョンのヘルプが1つのインデックスにマージされる

古い構成での1つの新しいヘルプは嘘をつく。8.3.5 で測定済み: サーバーは199要素を存在しないと宣言し、117を異なる シグネチャで返し(ЗаписьXML.ОткрытьФайл は 8.3.5 では2パラメータ、8.3.27 では 3)、410を異なる利用可能性で返す。これらはすべてコンパイルエラーであり、不正確さではない。

したがって、異なるバージョンのヘルプは並べて置かれ、since と until の境界を持つ1つのインデックスにマージされ、応答は特定の構成のバージョンに合わせて組み立てられる。ヘルプは、ロードされた構成のプラットフォームの数だけ必要——2つの極端な中間バージョンは置き換えられない。

コストは測定済みで小さい:3バージョンのマージで25 691キー、1つの場合は24 777、 つまり1パーセント未満。バージョンごとの個別コンテナも機能し、 緊急経路として残るが、主要経路としては数字で負けている——300–450 МБ と 各バージョンに独自のアドレス。

サーバーはどのヘルプが不足しているか、どれが余分かを自ら名指しする——list_configurations の出力で。

禁止の代わりに置換

「関数は存在しない」と言うのは答えの半分。残りの半分は何で置き換えるかであり、 ヘルプからは導出できない:廃止のマークは25千ページ中15ページにしかない。

したがって置換テーブル(replacements.py)があり、現在6件——8.3.6 で登場した文字列関数。 禁止の代わりに get_syntax がレシピを返す:

get_syntax("СтрРазделить", config="Отраслевая")   → 8.3.5
# `СтрРазделить` недоступна: появилась в 8.3.6

Замена: РазложитьСтрокуВМассивПодстрок(<Строка>, <Разделитель>)
Оговорка: разделитель у `СтрРазделить` — набор символов, каждый из которых
самостоятельный разделитель; у замены это одна строка целиком.

注記は必須。 置換はほぼ決して等価ではなく、似た関数を黙って 差し出すのは、何も提案しないより悪い。

テーブルは実例に基づいて補充され、盲目的ではない:誰も尋ねていない関数の回避策を 創作する意味はない。

4. データ管理

ソースを追加する

# в Docker
docker compose exec mcp1c python -m mcp1c.cli reg-add /data/bootstrap/Выгрузка.zip --data /data
docker compose exec mcp1c python -m mcp1c.cli reg-add /data/bootstrap/shcntx_ru.hbk --data /data

# без Docker
PYTHONPATH=src python3 -m mcp1c.cli reg-add Выгрузка.zip

より簡単:ファイルを data/bootstrap/ に置く——次の起動時に取得される。

構成のファイルへのアンロード

2番目の種類のソース——メタデータ(СтруктураКонфигурации_*.zip)ではなく、構成自体の ファイルへのアンロード:モジュールとフォームのコード。サーバーはプロシージャ、呼び出し、フォームの内部インデックスを構築してキャッシュする;search_procedures は 準備済みのセットで検索する。キャッシュミスの場合、インデックスはバックグラウンドで構築される:コードに依存しないツールは 応答を続け、コードツールはステージ X/4 と 現在のステージの実際に処理された N/M 要素を表示する。準備済みセットは 異なるバージョンの中間状態なしで全体として公開される。 startup が次のソースをまだ復元している間、バックグラウンドビルドは registry.json を上書きしない。startup が異常終了した場合、 ディスク上の以前の完全なスナップショットは全体として残る;部分的に復元された ソースリストはその上に保存されない。

4つのキャッシュ消費ファイルは安全なロケータ、カバレッジの集計、 残りの正確な数を持つ最初の20の匿名化された問題を保存する。モジュール本体、 プロシージャシグネチャ、フォームの生レコードはそこに入らない。ウォームスタート時には ソースの sha256、選択バージョン、ロケータ世代、各インデックスの内部不変条件、 および1つのカタログとの整合性がチェックされる。したがって 構造的または意味的に破損したセットは、部分的に古い応答のソースではなく、全体としてミスと見なされる。破損または読み取り専用のキャッシュは ソースを落とさない:サーバーはメモリ内でコールド再構築を実行し、新しいキャッシュを書き込めない場合でも完全な診断を公開する。公開されたコールド応答と ウォーム応答は、すべてのカウンタと理由カテゴリで一致する。 各フォームのローカル理由は制限付きリストとは別に保存される:これにより get_object は再起動後、選択したオブジェクトのすべてのフォーム問題を表示し、 共通の /sources を無制限の応答に変えることはない。Reader は256 МиБ を超えるキャッシュファイルを読み取らず、512 МиБ を超えるペイロードを解凍しない;いずれかの 制限の超過は marshal.loads までの通常のキャッシュミスであり、メモリを枯渇させようとする試みではない。

最終ライブ受入 selection v4 は2026-08-21に、4つの匿名化されたコードソース（3つの主要なアップロードと1つの拡張）に対して実行されました：

PYTHONPATH=src .venv/bin/python \
  tools/lab/measure_modules_acceptance.py --data data --timeout 120

スクリプトは名前とパスを含まない1つのJSONを出力します。ウォーム起動は3.676秒かかり、startup_problems_total = 0、プロセスのピークは856.2 MiBでした。カタログは8,650個の階層的な.bsl、Form.binからの828個のモジュール、1,523個のフラットな.txt、.Formからの1,079個のモジュール、およびソースなしの7個のコンパイル済みモジュールを証明しました。6,150個のフォームが検出されました：3,331個が完全に、1,330個が部分的に、1,489個が未読です。正確な制約カテゴリ：descriptor_only=671、invalid_syntax=1598、known_marker_semantics_incomplete=659、form_structure_missing=561、compiled_without_source=7。このコーパスには未知のマーカー、予算超過、破損したコンテナ、競合はありません。ここでのゼロは、まさにこれらのソースの測定結果であり、将来のあらゆる形式のサポートを約束するものではありません。

2026-08-21の3つのコードソースのコールドキャッシュでのバックグラウンド応答性の以前の測定：72.12秒で各パスの73回の秒間呼び出しが行われ、失敗はありませんでした。このタイマーは/healthの準備完了後に開始されますが、以下のコンテナ測定の125秒はコンテナ起動から全コードソースのreadyまでです。/healthは中央値5.76ms、最悪171.01msで応答しました。実際のsearch_objectsはそれぞれ8.11msと172.49msでした。コンテナはhealthyに達し、12個のキャッシュファイルすべてが公開されました。再現するには、index/cache/*.modules-*なしのdata/のコピーを別のコンテナにマウントし、以下を実行してください：

.venv/bin/python tools/lab/measure_background_responsiveness.py \
  http://127.0.0.1:5002 /путь/к/копии/data

最終イメージのメモリは、selection v4後に2026-08-21に再測定されました：4つのコードソースと16個のモジュールインデックスキャッシュファイル。消耗キャッシュのみを削除した後のコールド起動は111.216秒かかり、全16ファイルのdev、ino、サイズ、mtime_nsが不変のままの同じコンテナのウォーム再起動は11.495秒でした。

両方の回でコンテナはhealthyに達しました。restart_count = 0、oom_killed = false。2つの最終実行のそれぞれで、traceback、exception、critical、errorの各用語を含む行は正確に0行でした。cgroupの値にはカーネルのページキャッシュが含まれるため、プロセスのRSSやdocker statsの表示とは当然異なります。これはまさにこのコーパスのサイズの目安であり、mem_limitを割り当てる根拠ではありません。

スクリプトは、集計値のみを含む1つのJSONを出力します：所要時間、ソースとキャッシュの数、cgroupとPID 1のフィールド、docker stats、ヘルス、再起動、OOM、ログ用語カウンター。ソース名、ローカルパス、ログ行は出力されません。coldモードでは、最終イメージをビルドし、事前にコンテナを停止し、現在のソースの作業用名前関数で計算された正確なmodules-toc、modules-calls、modules-forms、modules-searchファイルのみを削除します。index/cacheディレクトリとターゲット自体はシンボリックリンクであってはなりません。余分なまたは混合された名前のセットは準備完了と見なされません。停止後、ディレクトリはO_NOFOLLOWで開かれ、そのdev/inoは最初に検証されたディレクトリと照合されます。ターゲットはdir_fdを介して列挙・検証され、同じディスクリプタを介して正確なベース名のみが削除されます：親をシンボリックリンクに置き換えても外部にはつながらず、ハードリンクは内部リンクを失うだけです。その後、スクリプトは--force-recreateを実行します。測定器自体は、ソース、解凍されたコード、registry.jsonを削除または置換しません。実行中のサーバーは、起動時およびバックグラウンドビルド中にregistry.jsonの状態を通常どおり原子的に更新します。測定はこれらのエントリを世代マーカーに考慮します。準備完了には、healthyだけでなく、変更されていないsha256、loaded_at、ソース自体のバインド、同じsha256のオーナー設定、ready状態、ソースごとの正確な4つのキャッシュセットが必要です。通常の再起動では、設定メタデータが再解析され、新しいランタイムloaded_atが取得されます。測定器はこの遷移のみを許可し、その後、新しい世代の2つの同一スナップショットを要求します。メモリ、docker stats、ログの読み取り後、最終チェックはレジストリを読み、次にキャッシュを読み、再度レジストリを読みます。両方のマーカーは準備完了世代と一致する必要があります。マーカーにはregistry.json自体のdev、ino、サイズ、mtime_nsも含まれるため、同じバイトの書き込みでも新しい世代と見なされます。warmモードは、停止前に各正確なキャッシュファイルのdev、ino、サイズ、mtime_nsを記憶します。docker stopの直後、docker startの前に、O_NOFOLLOWでディレクトリを再度開き、そのdev/inoと保持されたdir_fdを介したファイルスナップショット全体を照合します。同じスナップショットが準備完了時と最終チェックで要求されます。再ビルド、上書き、またはファイルの破損は結果全体を無効にします。--timeoutと--poll-intervalは有限の正の秒数です。単一のtimeout残りは各Dockerコマンドを制限します。

.venv/bin/python tools/lab/measure_container_memory.py --mode cold --data data \
  --timeout 300 --poll-interval 0.5
.venv/bin/python tools/lab/measure_container_memory.py --mode warm --data data \
  --timeout 300 --poll-interval 0.5

拡張アップロードは同じ場所、data/incoming/に置かれ、同じボタンで解析されます。 アップロードの種類はサーバー自身がアーカイブ内のConfiguration.xmlによって判断します。人間は引き続き拡張がアタッチされる設定のみを選択し、別のボタンや「これは拡張です」フィールドは選択しません。拡張は別のソース<設定名>:ext:<拡張名>（種類extension）として作成され、<設定名>:modulesではありません。拡張名は独自のアップロードのNameタグから取得され、人間が考案するものではありません。コードは独自のディレクトリdata/extensions/<設定名>/<拡張名>/に置かれます。data/modules/<設定名>/の隣ですが、その中ではありません。したがって、2番目のアップロードは最初のアップロードを消去しません。1つの設定に拡張はいくつでも存在できます。設定モジュールのアップロードは、以前と同様に正確に1つです。

拡張のアイデンティティは、そのアップロード内のNameタグであり、ファイル名やコンテンツ全体ではありません。 人間はアーカイブを自由に名前変更できます。名前は異なるがNameが同じ2つのファイルは、同じ1つのソースを再解析します。2回目の解析はコードとorigin（最後に解析されたファイルの名前）を更新するだけで、キーとディレクトリは変更されません。同じルールの裏返し：パスに不適切な文字を除去した後、2つの異なる拡張のNameが一致する場合（たとえば、Прайс/РозницаとПрайс:Розницаは同じディレクトリ名になります）、それらも1つのソースに統合されます。2回目の解析は最初のコードを上書きします。通常の名前（文字、数字、ハイフン、アンダースコア、ピリオド、スペース以外の文字がない場合）では、クレンジングは何も変更せず、そのような一致は発生しません。

認識は両側からの肯定的なルールであり、チェックの順序が重要です。 設定側に誤る方が危険です：モジュールブランチに入り、すでに解析された設定コード全体を削除することを意味します。したがって、最初に拡張の強い兆候（ObjectBelonging、ConfigurationExtensionPurpose）を確認します。1つでも見えた場合、どのCompatibilityModeでもモジュールブランチへの道はありません。以降は「拡張」（4つの条件すべてが一致：両方の強い兆候、非空のNamePrefix、CompatibilityModeの欠如）と拒否の間でのみ決定されます。そして、拡張の強い兆候がまったくない場合にのみ、CompatibilityModeが決定します：非空なら設定、空またはタグなしなら拒否。その他はすべて、ディスク上の何にも触れずに説明付きの拒否です：Configuration.xmlが見つからない（アーカイブのルートだけでなく、唯一のトップレベルディレクトリでも検索されます。zip -r archive.zip folderコマンドでアーカイブが作成されるためです。macOSのFinderアーカイブのサービス用__MACOSX/と.DS_Storeはこれに干渉しません）、読み取れない（壊れたCRC、中断されたレコード）、XMLとして解析できない、認識可能な構造を持たない、または宣言されたファイルサイズが非現実的に大きい。

配置場所。 data/incoming/に、ソースページのアップロードフォームではなく。フォームにはそのためのフィールドがないためです。ディレクトリはサーバーが起動時に作成するため、最初の起動から存在します。その後、「ソース」ページ（ADMIN_TOKENでログインした人のみ）に「受信アップロード」ブロックと「解析」ボタンが表示されます。

スキャンされるのはディレクトリ自体のみで、サブディレクトリは含まれません。 data/incoming/Розница/に置かれたアーカイブはサーバーには見えません。表示するものがないため、サーバーはそれについて何も言いません。

ファイルがコピーされている間、ボタンはありません。 1.5ギガバイトのcpは数分かかり、ファイルは最初の1秒からディレクトリに表示されます。5秒未満前に変更されたアーカイブの状態は「ファイルはまだコピー中」と表示され、sha256はまったく計算されません（どうせ古くなるため）、そのようなファイルの解析は説明付きで拒否されます。コピーの終了を待ってページを更新してください。

再解析はディレクトリ全体を完全に上書きします。ただし、成功した場合のみです。 更新されたアップロードのボタンには「再解析」と表示されます。data/modules/<設定名>/（または拡張ディレクトリ）の古いコンテンツは新しいものに完全に置き換えられます。そうしないと、新しいアップロードにないファイル（削除されたオブジェクト、名前変更されたモジュール）が永久に残り、2つのアップロードが混ざってしまうためです。解凍は隣の一時ディレクトリで行われ、以前の解析には影響しません。extractが途中で失敗した場合（モジュールの壊れたCRC、ディスク容量不足、権限）または0個のファイルを選択した場合、作業ディレクトリへの書き込みはまったく行われません。レジストリとディスクは乖離しません。置換はその場での削除ではなく、ローテーションです（「古いものを脇にリネーム → 新しいものをその場所にリネーム → 脇に置いたものを削除」）。新しいものを古いものの場所に移動できなかった場合、サーバーは古いものを元の場所に戻そうとします。それも失敗した場合（両方のリネームの失敗の性質は通常同じです。権限、同じbind-mount）、解析は明示的に拒否され、テキストで両方のパスを示します：以前の解析が物理的にどこにあるか、新しい空または部分的に解凍されたものがどこにあるか。手動でディレクトリを復元できるようにするためです。存在しないディレクトリに対して「解析済み」と黙って表示することはサーバーはしません。途中で中断されたプロセスの残骸（.tmp-*）は、同じ設定または拡張の次の解析の前に削除されます。保存された以前の解析のコピー（.old-*）は、そこまで進んだ場合、自動的には削除されません。その判断は人間に委ねられます。再解析はディレクトリの権限を変更しません。新しいディレクトリは以前の権限（またはディレクトリがまだ存在しない場合は通常の権限）を取得し、一時ディレクトリが作成される際の制限された権限ではありません。

同じソースの同時解析は順次実行されます。新しいリクエストは以前の世代を即座にキャンセルしますが、一時ディレクトリでの作業の完了を待ちます。したがって、1つの解析が別のアクティブな.tmp-*を削除することはできず、作業ディレクトリとキャッシュを取得するのは最後の世代のみです。キャンセルされたリクエストは明示的なエラーで終了します。待機中の古いリクエストは解凍をまったく開始しません。異なる設定と異なるソースキーを持つ拡張は互いに遅延させません。

「選別が古い」—ファイルではなくルールが変わる場合の状態。 解析済みの各ソースは、選別ルールのバージョン（内部 SELECTION_VERSION：アーカイブから何を取り、どこに置くか）を記憶している。ディスク上のコードが古いバージョンのルールで解析された場合、ソースは「解析済み」ではなく「選別が古い」と表示される。incoming/ のアーカイブは同じファイルで、sha256 も同じであるにもかかわらず。ボタンは更新されたアップロードと同じように「再解析」と表示される。ディスク上のコードは、現在のルールに従って新たに上書きされる。以前の解析自体は書き換えられない。選別ルールの変更は、ボタンを押した後にのみ人間が見ることができる。このフィールドが登場する前に解析されたソース（古い registry.json の selection_version のないレコード）も古いと見なされる。バージョンが不明であり、「確実に新しい」わけではないからだ。そうでなければ、人間は現在のルールを通過したことのないコードに対して「再解析」を決して見ることができないだろう。 現在のバージョン 4 は、フォームの XML 記述子と階層的な Ext/Form.bin を保存する。したがって、バージョン 3 のソースは必ず古いと表示され、明示的な再解析後にのみこれらのファイルを取得する。 選別バージョンはキャッシュのスタンプに含まれる。古いキャッシュは、同じ変更されていない ZIP であっても受け入れられない。ディレクトリを置き換える前に、サーバーは短いローテーションログを書き込む。異常終了後、次の起動は registry.json に基づいて、新しい世代を完了するか、以前のディレクトリを復元する。

macOS の Finder アーカイバのゴミはコードに入らない。 「オブジェクトを圧縮」コマンドで作成されたアーカイブには、各ファイルのリソースフォークのコピー（._Имя、元のファイルと同じサフィックス）を含むサービス用の __MACOSX/ が含まれる。選別は、どこにあっても ._ で始まる名前と同様に、これらをスキップする。

アーカイブのラッパーはディスク上のパスに再現されない。 zip -r архив.zip папка コマンドまたは Finder（「オブジェクトを圧縮」）でパッケージ化されたアーカイブ—アップロード全体が単一のトップレベルディレクトリ内にある—は、ディスクに展開する際にこのレベルを繰り返さない。コードは data/modules/<ИмяКонфигурации>/Catalogs/… として配置され、data/modules/<ИмяКонфигурации>/папка/Catalogs/… ではない。ラッパー認識ルールは、その中の Configuration.xml の検索と共通である（上記の「認識」の段落と同じ場所）。サービス用の __MACOSX/ とルートの .DS_Store はカウントされず、複数のトップレベルディレクトリはラッパーと見なされない。どれが「その」ディレクトリかを推測することはサーバーはしない。パスのサニタイズ（ルートの外側を指すメンバーの拒否）は、ラッパーの除去後に行われ、その代わりではない。

ソースの削除はコードも持ち去る。 ソース <ИмяКонфигурации>:modules の「削除」ボタンは data/modules/<ИмяКонфигурации>/ を削除し、拡張ソース <ИмяКонфигурации>:ext:<ИмяРасширения> の場合は、その独自のディレクトリ data/extensions/<ИмяКонфигурации>/<ИмяРасширения>/ のみを削除する。構成モジュールや同じ構成の他の拡張は影響を受けない。そうでなければ、数百メガバイトが不可視のまま占有されることになる。「ソースファイル」セクションには表示されず、そこには data/sources/ のみがある。

モジュールもフォームも見つからなかったアーカイブは拒否される。 メタデータ構造のアップロードも .zip であり、このチェックがなければ、ゼロファイルのソースを「解析済み」状態で作成してしまうだろう。これはこのページの「アップロード」フォームで提供される。

なぜブラウザ経由ではないのか。 アーカイブは 1 ギガバイト以上ある。典型的な小売販売構成 2.3.10.5 では 1 380 MB である。「ソース」のアップロードフォームはメタデータ用に数メガバイト単位で構築されており、そのようなファイルでは 3 つの理由で機能しない。アップロード制限が 500 MB。リクエストボディの受信バッファ、mkdtemp() の一時コピー、ボリューム自体へのコピーという 3 重コピーでピーク約 4 GB。そして、HTTP で 1 ギガバイト以上を転送する際に、中断後に再開する手段がない。ボリューム上のファイルは 3 つの制限すべてを回避する。通常の cp でコピーされ、サーバーはアーカイブをメンバーごとに読み取り、全体を一度も展開しない。

ディスクに残るもの。 アーカイブ全体ではなく、モジュール（階層アップロードの .bsl、フラットの .txt と正規のコンパイル済み CommonModules/<Имя>.Module または CommonModule.<Имя>.Module）とフォームのみ。階層の場合は XML 記述子、Form.xml、Form.bin、フラットの場合はコンテナ .Form 全体。Form.bin と .Form はコードプロバイダーのソースとして変更されずに保存される。派生 .bsl は受信時に作成されない。テキストレイアウト *.Template.txt はモジュールとして受け入れられない。コンテナは、フォームのバイナリレコードとともにそのまま保存される。通常のフォームのコードはその中の module レコードとして存在し、受信時にコンテナを解析することは、1C 形式の解析をここに持ち込むことを意味する。

解凍後、物理ツリーは正規アドレスと安全なロケータの不変カタログに一度だけ列挙される。目次、呼び出し、フォーム、検索はすべて同じスナップショットを取得する。通常の .bsl/.txt はファイルとして読み取られ、Form.bin/.Form のコードは元のコンテナの module レコードとして読み取られ、コンパイル済みの .Module は架空のボディのないアドレスのままである。共通の正規化後の同じアドレスの同一テキストは重複排除される。異なるテキストは黙って優先されることはなく、競合として除外される。

構成コードは data/modules/<ИмяКонфигурации>/ に配置され、拡張コードは独自のディレクトリ data/extensions/<ИмяКонфигурации>/<ИмяРасширения>/ に配置される。現在のカバレッジログは data/logs/ に配置される。3 つの種類すべてが .gitignore の **/modules/、**/extensions/、**/logs/ ルールで保護されている。測定 python3 tools/lab/measure_intake.py <архив>...、実行 2026-08-19：

同じファイルでの実際の受信実行—zip ディレクトリによる推定ではなく、intake.planned_size、intake.enough_space、intake.extract の実際の呼び出し、測定 python3 tools/lab/measure_intake_run.py <каталог для распаковки> <архив>...、実行 2026-08-19：1,4 GB のアーカイブの必要スペースの推定—0,15 秒（zip の中央ディレクトリのみが読み取られ、ボディはまったく触れない）、解凍—3,1 秒、プロセスのピーク RSS—111 MB。extract() が返したファイルとバイト数は、実際にディスクに配置されたものと等しい。スクリプトはこれを自分で検証する。

サーバーはソースを削除しない。 サーバーは data/incoming/ ディレクトリを削除することを禁止されている。ファイルは正常な解析後もその場に残る。同じアーカイブの再解析はそれを触らず、照合はページのキャッシュとの sha256 で行われる（リストを更新するたびにギガバイトのハッシュを計算することはできない）。

ソースは <ИмяКонфигурации>:modules キーで作成される、構成名ではない。メタデータと同じキーであり、アップロード時にレジストリからそれらを追い出してしまうだろう。どの構成がアップロードの所有者であるかは人間が決定する。レジストリにちょうど 1 つだけロードされている場合、選択は不要である。ページのボタンの横にフィールドはなく、解析は唯一のものを自動的に取得する。2 つ以上ロードされている場合、ボタンの横にロードされた名前のドロップダウンリストが表示される。選択したものにコードがバインドされる。フォームの名前はロードされたリストと照合される。不明な名前は解析開始前に説明付きで拒否される。アップロードのマニフェストによる自動バインド（人間の関与なし）はまだ実装されていない。モジュールソースのプラットフォームは、バインドされている構成から取得される。アップロード自体には正確なプラットフォームビルドのファイルは含まれず、互換モードのみであり、これは別の数値である。拡張の場合、構成の選択は同じように機能する（上記の「拡張アップロードは同じ場所に配置される」を参照）。アップロードの種類—モジュールか拡張か—は、サーバーが Configuration.xml によって自動的に区別し、そのための別のフィールドやボタンはページにない。

スペース不足—開始前の拒否。 構成とソースの種類を選択した後、レジストリは解凍前にボリュームの空きスペースを確認する。安全に選別されたファイルの量にインデックス予備を加えたものが必要である。15% を切り上げ、ただし 25 MB 以上。式は最初のアップロードと再解析で同じである。古いルートが占有していた量はすでに空きスペースの値から除外されており、再度追加することはできない。不足している場合、解析は開始されず、両方の数値をメガバイトで示した理由が「ソース」ページに残り、再起動後も持続する。レジストリの直接呼び出しも同じチェックを通過する。エラーまたはボリュームの満杯の場合、以前の解析はその場に残る。

コンパイル済みの *.Module は、概要とモジュールリストで ОбщийМодуль.<Имя> として表示されるが、プロシージャやボディはない。search_procedures、get_procedure、get_callers はこれを直接示し、空のインデックスをプロシージャが存在しない証拠として提供しない。

「解析」ボタンは ADMIN_TOKEN を必要とする—他の書き込みと同様に。トークンがない場合、このルートは存在しないのであり、「閉じられている」わけではない。

再起動せずに変更を適用する

実行中のサーバーはレジストリをメモリに保持しているため、reg-add の後はそれをプッシュする必要がある。再起動（docker compose restart mcp1c、約 2 秒）または管理ハンドル：

# включается переменной ADMIN_TOKEN; без неё маршрут отключён
ADMIN_TOKEN=секрет docker compose up -d
curl -X POST -H "x-admin-token: секрет" http://localhost:5001/admin/reload

辞書：言い方と名前の違い

検索の主な難しさは、人間の言葉と構成内の名前の間のギャップである。「Заказ клиента」—オブジェクトは ЗаказПокупателя と呼ばれる。辞書は data/dictionary.json にあり、イメージを再ビルドせずに編集できる。

2 つのメカニズムがあり、それらは異なる。

単語の同義語—すべての構成に共通：

python3 -m mcp1c.cli dict-synonyms клиент покупатель заказчик

オブジェクトのエイリアス—「私がこう言うとき、これらのオブジェクトを意味する」という直接的な指定であり、テキスト一致よりも重みが高い。典型的なフレーズ（「ファイル」、「商品」、「クライアント」、「従業員」、「タスク」）の 20 数個が組み込まれており、すぐに機能する。構成にオブジェクトがない場合、エイリアスは適用されない。独自のものは構成にバインドして追加される：

python3 -m mcp1c.cli dict-alias "справочник физлиц" \
    Справочник.ФизическиеЛица Справочник.Пользователи \
    --config РозницаДляКазахстана

«справочник физлиц»
    Справочник.ФизическиеЛица     псевдоним из словаря
    Справочник.Пользователи       псевдоним из словаря

オブジェクトの存在は追加時にチェックされる。タイプミスのエイリアスは役に立たない。内容を表示する：dict-show、削除：dict-alias «фраза» --remove。

変更はコンテナの再起動または POST /admin/reload で適用される—イメージを再ビルドする必要はない。リロードはイベントループの外で実行されるため、/health と MCP リクエストは復元中も引き続き処理される。

クエリ言語の検索キー—3 番目のメカニズムであり、コード（search_keys.py）でのみ編集でき、通常の変更チェックが行われる。ここでのギャップは別の性質のものである。人間は構造を別の言葉で呼ぶのではなく、タスクを説明する。「2 つの日付の間の日数」対 РАЗНОСТЬДАТ、「重複を削除」対 РАЗЛИЧНЫЕ—共通の単語はゼロであり、同義語は役に立たず、置き換えるものがない。

したがって、127 ページのうち 116 ページに、それらが尋ねられる表現が割り当てられ、検索インデックスに別のフィールドとして含まれる。ランタイムでは何も重くない。実際のセットでの結果：57,9% → 94,7% が最初の場所で、61,000 の自動クエリでリグレッションなし。

キーは私たちが作成したものであり、アップロードされたものではない。ここから 3 つの制限がある：

• git の別のレイヤーに存在し、解析された要素に付与されるわけではない。

• エージェントへの応答には含まれない—応答は引き続きヘルプからのみ構築され、キーは目的の記事にヒットするためだけに機能する。

• ページに ID でバインドされており、ヘルプが異なるページセットを提供する場合、不一致はロード時に通知され、黙って検索が低下することはない。

ルール全体は docs/data-sources.md の「ソースの上に生成されたレイヤー」セクションにある。

ロードされたものを確認する

docker compose exec mcp1c python -m mcp1c.cli reg-list --data /data

РозницаДляКазахстана  2.3.10.5  платформа 8.3.23.1997
  объектов 5637, связей 44034, загружено 2026-08-18T12:22:16+00:00
  метаданные : да
  синтаксис  : справка 8.3.27, новее конфигурации, скрыто 874
  модули     : не загружен
  язык запросов: подключён, 127 страниц

構成がまったくない場合もある。サーバーは、少なくとも 1 つのヘルプがロードされていれば動作する。search_syntax と get_syntax が応答し、config を指定する必要はない。この場合、reg-list は接続されたものを列挙し、0 を返す：

Конфигурации не загружены. Подключено:
  язык запросов, 127 страниц
Работают search_syntax и get_syntax, без фильтра по версии.

完全に空のレジストリでは——「何もロードされていません。」とリターンコード1。設定を必要とするコマンドは、同じ場所で何が不足しているか、それぞれが何によって取得されるかを示します。reg-listはコールドビルドを待ちません。メイン設定と各拡張機能について、/sourcesやlist_configurationsと同じ原子的状態——準備済みカウンター、ステージと進捗、エラーまたはコードの欠如——を表示します。

エージェントなしでのデバッグ——mcp1c.cli

CLIはMCPツールと同じレジストリと同じ関数にアクセスします。正しく応答するなら、問題はサーバーではなくクライアントの設定にあります。

コマンドは3つのグループに分かれます。レジストリによる——エージェントが見るものと同じ：

PYTHONPATH=src python3 -m mcp1c.cli reg-list  [--data data]
PYTHONPATH=src python3 -m mcp1c.cli reg-add   Выгрузка.zip     [--data data]
PYTHONPATH=src python3 -m mcp1c.cli reg-add   shcntx_ru.hbk    [--data data]
PYTHONPATH=src python3 -m mcp1c.cli reg-search "чек ккм"  --config РозницаДляКазахстана
PYTHONPATH=src python3 -m mcp1c.cli reg-search "разделить строку" --syntax --limit 5
PYTHONPATH=src python3 -m mcp1c.cli reg-search-procedures "провести документ" \
    --config Пример --scope Документ.Чек --limit 10
PYTHONPATH=src python3 -m mcp1c.cli reg-get-procedure \
    'Документ.Чек.МодульОбъекта::ОбработкаПроведения' \
    --config Пример --start-line 0 --lines 200
PYTHONPATH=src python3 -m mcp1c.cli reg-get-callers \
    'Документ.Чек.МодульОбъекта::ОбработкаПроведения' \
    --config Пример --limit 20

reg-searchは--syntaxなしではメタデータで検索し、ありではヘルプとクエリ言語で検索します。3つのコードコマンドは同名のMCPツールをミラーリングし、同じ応答を出力します：reg-search-procedures QUERYは--config、--extension、--scope、--limit（デフォルト10）を受け付けます；reg-get-procedure ADDRESSは--config、--extension、--start-line（0）と--lines（200）を；reg-get-callers ADDRESSは--config、--extensionと--limit（20）を。3つすべてで--dataのデフォルトはdataです。コールドの一回限りの起動時、これらのコマンドはバックグラウンドビルドを90秒以内で待ち、プロセスが結果と4つのキャッシュファイルの書き込みの前にdaemonスレッドを終了しないようにします。制限時間が足りない場合、コマンドは明示的なエラーを返します；サーバーはこの待機を使用せず、進捗を表示し続けます。

レジストリなしでファイル直接——サーバーに送られる前にエクスポートを確認する：

PYTHONPATH=src python3 -m mcp1c.cli info    Выгрузка.zip
PYTHONPATH=src python3 -m mcp1c.cli stats   Выгрузка.zip
PYTHONPATH=src python3 -m mcp1c.cli show    Выгрузка.zip Документ.ЧекККМ --detail full
PYTHONPATH=src python3 -m mcp1c.cli related Выгрузка.zip Документ.ЧекККМ --depth 2
PYTHONPATH=src python3 -m mcp1c.cli find    Выгрузка.zip реализация --limit 10

パスはZIPまたは解凍済みディレクトリで、形式はマニフェストによって決定されます。

検索辞書——同義語は共通、エイリアスは設定にバインド：

PYTHONPATH=src python3 -m mcp1c.cli dict-show                       # правила и их происхождение
PYTHONPATH=src python3 -m mcp1c.cli dict-show --all --config Розница...
PYTHONPATH=src python3 -m mcp1c.cli dict-synonyms чек ккм касса     # группа взаимозаменяемых слов
PYTHONPATH=src python3 -m mcp1c.cli dict-synonyms чек ккм --remove
PYTHONPATH=src python3 -m mcp1c.cli dict-alias "справочник физлиц" Справочник.ФизическиеЛица
PYTHONPATH=src python3 -m mcp1c.cli dict-alias "справочник физлиц" --remove

dict-showは各ルールの由来を示します——「検索がなぜそのように動作するか」の分析はここから始まります。

検索品質の測定——mcp1c.bench

数字なしの「良くなった」は意見に過ぎないため、別のスタンドです。

PYTHONPATH=src .venv/bin/python -m mcp1c.bench \
    --data data --config РозницаДляКазахстана \
    --auto --sets query-language,roznica-metadata,modules-procedures \
    --check-notes

各手動JSONにはschema_version: 1、明示的なdomain——syntax、metadataまたはprocedures——とcases配列が含まれます。ファイル名はインデックスを選択しません。procedureセットではexpectedはモジュール名なしのBSL bare名を保持します；ベンチは大文字小文字を無視して、選択されたコーパスのすべての正確なアドレスに名前を展開します。これにより、特定の実装の構造を公開せずに再現可能な表現を公開できます。オプションのexpected_miss: trueとzero-basedのexpected_rankは、--check-notes時に固定されたベースラインを機械的に照合します；これはpytestのしきい値ではありません。古いルートJSON配列とバージョンなしの古いベースラインは明示的に拒否されます：再作成する必要があります。--saveはまずレポートファイルを原子的に置き換え、その後で結果を出力します：書き込みエラーはディスクにもstdoutにも部分的なレポートを残しません。

P@1/P@3/P@5/P@10、MRR、「他ドメインが先頭」の割合、および最初の結果と2番目の結果の中央値の差を出力します。アサートのしきい値は意図的にありません：クエリセットはテストではなく、パーセンテージは辞書の編集ごとに壊れるでしょう。コード1は注記の不一致を意味します；コード2は、不適切なセット、曖昧な選択、または未準備のインデックスにより、測定全体が出力と保存の前にキャンセルされたことを意味します。プロシージャセットの実行中にコードが変更された場合、セット全体がインデックスの1世代で最初から繰り返されます。

2つの実行の比較は次のようになります（悪化が先頭）：

=== сравнение с прошлым прогоном ===
  - «как прибавить месяц к дате в запросе»: 1 -> промах
  - «как отсортировать результат запроса»: 1 -> 5
  + «в чем разница между внутренним и левым соединением»: 5 -> 4

セットはイメージに含まれません（.dockerignore内のtests/）——コンテナからではなく作業コピーから実行します。

手動でのサーバー——mcp1c.server

PYTHONPATH=src python3 -m mcp1c.server --data data          # streamable-http на :8000/mcp
PYTHONPATH=src python3 -m mcp1c.server --transport stdio    # локальному клиенту
PYTHONPATH=src python3 -m mcp1c.server --host 0.0.0.0 --port 5001

--transportに他の値はありません。廃止されたHTTP+SSEは完全に無効化されています：--transport sseフラグはデータの読み取りとサーバー起動の前に拒否されます。

ソースデータの由来

設定構造——exporter-1c/からの処理による。通常フォームと管理フォーム、XMLとJSON用の4つのモジュールバリアント；XMLバリアントは8.3.5と互換性があります。2つの処理は既にビルド済みでそのまま開けます：ВыгрузкаСтруктурыКонфигурации_ОбычнаяФорма_XML.epf（8.3.5以上）とВыгрузкаСтруктурыКонфигурации_УправляемаяФорма_XML_JSON.epf（8.3.6以上、形式はフォーム上で選択）。

プラットフォームヘルプ——1Cインストールディレクトリからのshcntx_ru.hbkファイル：

/opt/1cv8/<версия>/shcntx_ru.hbk
C:\Program Files\1cv8\<версия>\bin\shcntx_ru.hbk

名前は完全に一致する必要があります。 同じディレクトリには数百の.hbkファイルがあります——38種類の異なるヘルプ、それぞれ20以上の言語。目的のものに似ているもの：

サイズでは区別できません：shcntx_root.hbkは33MB、目的のものは39MB。接尾辞_ruは言語、_rootはテキストなしの共通部分。

ファイルが違う場合、サーバーはその理由を説明し、以前のヘルプをそのまま残します。

利用可能な最新プラットフォームからのヘルプ1つで十分です：各要素は登場バージョンを保持し、古い設定では余分なものはフィルタリングされます。パスにバージョンがない場合、データ自体から導出されます。

古いプラットフォームのヘルプも受け付けられます——それらは異なるマークアップ（pの代わりにdivのセクション）で、これは考慮されています。古い導入向けに別のサーバーを立てる場合に役立ちます：8.3.5のヘルプは18,936要素を提供し、СтрНайти、СтрРазделить、ЗаписьJSONを含みません——これらは8.3.5には存在しませんでした。しかし、そのようなヘルプは自身のバージョンを報告しません：「バージョン以降」のマークがないのは、当時はすべてが現在だったからです。したがって、バージョンはファイル名またはディレクトリ名から取得されます——8.3.5.1570.hbkとして、またはdata/hbk/8.3.5.1570/に配置してください。そうしないと、設定との照合は機能しません。

5. 仕組み

src/mcp1c/
  v8container.py     контейнер 1С — общий для .hbk, .cf, .epf
  syntax_parser.py   разбор справки платформы
  syntax_model.py    модель элемента справки, виды, границы версий
  syntax_merge.py    слияние справок разных версий в один индекс
  query_parser.py    разбор справки по языку запросов (shquery_ru.hbk)
  replacements.py    чем заменить функцию, которой нет в старой платформе
  virtual_tables.py  таблицы запроса регистров и имена их полей
  loader.py          чтение выгрузок, XML и JSON в одну модель
  model.py           модель конфигурации
  graph.py           граф связей
  graph_view.py      окрестность объекта для картинки на дашборде
  search.py          лексический поиск
  search_keys.py     формулировки, которыми спрашивают язык запросов
  synonyms.py        встроенный словарь: как говорят против того, как названо
  dictionary.py      локальный словарь поверх встроенного
  index_cache.py     кэш поисковых индексов, расходный
  modules_index.py   оглавление, вызовы и формы для get_callers
  store.py           чтение и запись разобранных справок
  render.py          markdown-карточки объектов и элементов
  intake.py          отбор и распаковка выгрузки в файлы, санитизация имён
  incoming.py        состояние data/incoming: кэш sha256, причина отказа
  registry.py        реестр источников, сопоставление версий
  tools.py           десять инструментов, без зависимости от MCP
  server.py          протокольный слой (единственная внешняя зависимость)
  dashboard.py       веб-интерфейс: реестр, запросы, словарь
  cli.py             отладочный CLI
  bench.py           стенд замеров качества поиска

2つの形式で1つのモデル。 XMLとJSONは同じスキーマの異なるシリアライゼーションです；ローダーは両方を同じ辞書に変換します。検証済み：両方のエクスポートは同じ30キーのセットを生成します。

グラフは1Cではなくローダーが構築します。 エッジは属性タイプ、ドキュメントの動作、入力根拠、所有者、サブスクリプションハンドラー、およびスケジュール済みジョブのメソッドから導出されます。ルールは再エクスポートなしで変更できます。

弱いエッジ。 ЗначениеДоступаのような属性は数百のタイプを列挙し、ほぼすべてをすべてに結び付けます。そのような接続は弱いとマークされ、デフォルトで非表示になります——そうしないと有用なものが埋もれます。

詳細レベル。 Документ.ЧекККМの完全な説明（50属性、17テーブルセクション）はコンテキスト全体を消費します。briefは数行、fieldsは構成、fullは接続付き。

外部データベースなし。 本番インデックスは単一プロセスに留まります：コンパクトなコード配列は別のネットワークホップなしで応答し、検索は0.18〜1.5msかかります。Elasticsearch、ベクターストア、グラフDBは、この規模では別プロセスとメンテナンスに見合いません。ベクター検索はさらにエンコーダーモデル（イメージに+185〜620MB）とクエリエンコーディングだけで16〜32msを必要とします。

実データで測定——2026-08-18

ワークサーバーにロードされているもの：

セットはランダムです——手元にあったものです。重要なのは設定自体ではなく、プラットフォームのばらつきです：8.3.5、8.3.23、8.3.27が1つのレジストリにあり、各設定は自身のプラットフォームに応答します。

さらにプラットフォームヘルプ——3バージョン（8.3.5、8.3.23、8.3.27）のマージされたインデックス、25,691要素、およびクエリ言語——別ソースとして127ページ。

モジュールインデックスの12のキャッシュファイルを持つ最終イメージのウォームスタート——2026-08-21に測定されたワークコーパスで19秒。コールドスタート時、ソースは解析され、インデックスが構築されてdata/index/cache/に配置され、解析済みヘルプはdata/index/syntax/に配置されます。その後はそこから起動します。

キャッシュは派生的で消耗品です：Pythonバージョン、パッケージコードのフィンガープリント、ソースのハッシュにバインドされています。何かが一致しない場合、インデックスは再構築されます。ディレクトリはいつでも削除でき、自動的に復元されます。キャッシュボリュームが読み取り専用の場合、古いファイルを削除できないことは、ソースの登録解除を中断しません。

registry.jsonのレコードの順序は重要ではありません：コードは自身の設定の後にのみ復元されます。そのレコードがない場合、起動中に削除または置換された場合、古いモジュールまたは拡張機能のレコードは所有者なしでは公開されません。

検索インデックスのポスティングはnumpy配列にあります；一時的な辞書の埋め込みはフリーズ直後に解放されます。サーバーの総RSSは、分離されたレイヤーの合計では得られません：コールドピークとウォーム状態のコンテナは、すべてのソースの起動後に別々に測定されます。

モジュールテキスト——コードツールが接続されています

設定のファイルへのエクスポート受け入れが実装されています——上記の「設定のファイルへのエクスポート」セクション：コードとフォームはディスクに配置され、ソースはレジストリに記録され、4つの内部インデックスが構築・キャッシュされます。search_proceduresは正確な名前とエクスポートプロシージャを単語で検索し、get_procedureはモジュールの目次または本文ウィンドウ付きのカードを返し、get_callersは本文を読まずに確認済みの呼び出し場所、メタデータバインディング、フォームハンドラーを結合します。

2026-08-21時点のメイン設定の現在の本番スナップショット：137,116プロシージャ、619,029呼び出し場所、3,194フォーム、89,528フォーム要素、24,202イベントバインディング行。

自身のエクスポートで名前やパスを出力せずに再現可能：

MODULES_ROOT=/путь/к/выгрузке
.venv/bin/python tools/lab/measure_modules_cache.py "$MODULES_ROOT"

測定ツールは、キー procedures、calls、forms、elements、event_rows を持つ JSONアグリゲートを出力します。最後のカウンターは、公開バインディングでのグループ化と重複削除前の <Event> の生の行です。

プロトタイプの履歴スナップショットは、2026-08-20に匿名化された階層エクスポートからファイルへ取得されました: 7,878モジュール、137,115プロシージャ、260MBのテキスト。以下に保存されているのは、まさにその数値であり、現在のアグリゲートではありません。

検索のレイテンシは1.2〜1.5msです。キャッシュ書き込みを含む4つのインデックスの完全なコールドビルドは約50秒です。

ファイルへのエクスポートは2種類あり、2つ目は別途測定されました — 8.3.5上の業界構成10.5.1.3: フラットなレイアウト、モジュールは .txt、通常フォームのコードはバイナリコンテナ .Form 内。2,603モジュール、33,555プロシージャ、解析1.1秒、全94MBの検索で中央値0.2ms。この形式にはフォーム構造は含まれず、一部の共通モジュールはコンパイル済みで提供されています — ソースはまったくありません。そのようなモジュールはアドレス ОбщийМодуль.<Имя> で表示されますが、内部のプロシージャや呼び出しは読み取れません。そのため、サマリー、検索、通常モジュールの目次、逆引き検索、重複情報は、結果の上に「アグリゲートは利用可能なソースのみに基づいており、不完全な可能性があります」と警告します。

測定スクリプトは tools/lab/ にあり、上記のすべての数値を再現します:

.venv/bin/python tools/lab/measure_modules_cache.py <каталог выгрузки в файлы>
.venv/bin/python tools/lab/measure_modules.py <каталог выгрузки в файлы>
.venv/bin/python tools/lab/measure_resident.py <каталог> <файл индекса> собрать
.venv/bin/python tools/lab/measure_search.py <файл индекса> экспортные
.venv/bin/python tools/lab/measure_forms.py <каталог>
.venv/bin/python tools/lab/measure_flat.py <каталог плоской выгрузки>
.venv/bin/python tools/lab/measure_container_memory.py --mode cold --data data \
  --timeout 300 --poll-interval 0.5
.venv/bin/python tools/lab/measure_container_memory.py --mode warm --data data \
  --timeout 300 --poll-interval 0.5

検索品質

ベンチマークで取得され、1つのコマンドで再現されます:

PYTHONPATH=src .venv/bin/python -m mcp1c.bench \
    --data data --config РозницаДляКазахстана \
    --auto --sets query-language,roznica-metadata,modules-procedures \
    --check-notes

表全体は2026-08-21に上記の正確なコマンドでread-onlyモード、--save なしで取得されました。コマンドはコード0で終了しました。3つの手動セットは実際の表現とミスから収集され、最後の2つはデータ自体から構築されます。プロシージャのランクは [ミス, ミス, 7] です。これは改善のためのベースラインであり、受け入れ基準ではありません。

プロシージャの行は個別に高速に再現されます:

PYTHONPATH=src .venv/bin/python -m mcp1c.bench \
    --data data --config РозницаДляКазахстана \
    --sets modules-procedures

「差」— 最初の結果が2番目からどれだけ離れているか、中央値。これは「確実にヒットしたか、それとも偶然か」という問いに答えます: クエリ言語の35%対ヘルプの91.7%は、これらの勝利が3倍弱く保持されており、ランキングの修正がP@1の1パーセントも動かさずにそれらを覆す可能性があることを意味します。

検索のレイテンシは、セットに応じてクエリあたり0.18〜1.4msです。

クエリセットはイメージに含まれません (tests/ は .dockerignore 内): コンテナからではなく、作業コピーから測定する必要があります。

テスト

.venv/bin/pip install -r requirements-dev.txt
.venv/bin/python -m pytest          # 1100 тестов (прогон 2026-08-21)

data/ の内容には依存しません: リポジトリにはプロプライエタリなエクスポートはなく、必要なものはすべて tests/conftest.py で合成的に構築されます。

検索品質はテストではチェックされません — ベンチマークで測定されます (mcp1c.bench、「測定」を参照)。パーセントのしきい値は辞書の編集ごとに壊れるため、ベンチマークは数値を出力し、決定は人間が行います。pytest は観察可能な動作をチェックします: 「インデックスが再構築されていない」、「結果が一致した」、「起動がクラッシュしなかった」。

6. セキュリティ

2つのトークン、両方とも環境変数で設定されます。トークンが設定されていない間は、対応するアクセスはアドレスに到達できるすべての人に開放されています。

「公開」と「無効」の違いは意図的です。トークンなしの読み取りは機能します — 自分のマシンでは便利で、脅威はありません。トークンなしの書き込みはまったく機能しません: 辞書の編集に1回失敗すると、共有サーバーに接続しているすべての人の検索が静かに壊れます。

トークンはヘッダーで渡されます — X-Api-Token または Authorization: Bearer <トークン> のいずれかです。管理者トークンは読み取りにも使用できます: そうでなければ、所有者はクライアントに2つのヘッダーを保持する必要があります。

トークンはラテン文字である必要があります。 HTTPヘッダーはlatin-1でエンコードされ、キリル文字のトークンは物理的にサーバーに到達しません: ブラウザのログインフォームでは機能しますが、クライアントのヘッダーでは機能しません。

チェックをバイパスする2つのパス: /health (コンテナのヘルスチェックがアクセスし、読み取り権限以上の情報は提供しません) と /login — そうでなければ、ログインフォームは、それが発行するまさにその認証の背後にあることになります。

トークンに関するものではない、さらに2つのルール:

• MCPエンドポイントは構成構造を完全に提供します。 自分のマシンの外に出す場合は常に API_TOKEN を設定してください。ネットワークアクセスだけでは不十分です。

• data/ ディレクトリ全体が .gitignore にあります — .hbk とエクスポート、および解析されたインデックスの両方。ヘルプインデックスは、1C社の同じコンテンツを解凍しただけのものです。かつてそれがそこに入り、20コミットの間放置されました。履歴は git filter-repo で書き換えられ、ルールは拡張子ではなくディレクトリに基づいて再定式化されました: チェックすべきは「これは .hbk か?」ではなく、「これは data/ にあるか?」です。

7. ドキュメント

6つの自己完結型の契約ドキュメントが公開されています: エクスポート形式、ソースの境界、クエリ言語とダッシュボードの構造、コードエクスポートの受け入れ、コードプロバイダー。公開ファイルからの各リンクは、リポジトリにも含まれる資料につながる必要があります。

外部DB、ベクトル、グラフDB、SSEトランスポート、遅延ロードは、現在のコーパスの測定によって却下されました。以前のコストを反証する新しい測定、または新しい実用的なシナリオを示す測定がある場合にのみ、それらに戻ることができます。

8. ライセンス

Apache License 2.0。NOTICE も読む価値があります — ライセンス自体が述べていない2つのことがあります:

• プロジェクトは独立して開発され、ООО「1С」とは提携していません。「1С」および「1С:Предприятие」はООО「1С」の商標であり、ライセンスはそれらの権利を付与しません (Apache 2.0、セクション6);

• リポジトリにはプラットフォームのヘルプも構成のエクスポートもありません — 元の形式でも、解析された形式でも。これは1C社のコンテンツであり、特定の導入のデータです。各自が自分の配布物から取得し、data/ に置きます。ライセンスはコードに適用され、そこにアップロードしたデータには適用されません。