bsp

Using 1C:BSP 3.1.11 in application code

This router is ASCII-only so that its initial read is safe even with a legacy Windows stdout code page. The task references remain UTF-8 Russian, with exact BSL names, signatures, regions, parameters, examples and pitfalls.

Reading UTF-8 files on Windows

Use a native UTF-8 reader: rg -n . -- "PATH" reads a file; rg patterns and -A/-B/-C select a section. Replace PATH with the installed file's path; quote paths containing spaces. Alternatively, read with explicit Python UTF-8:

python -X utf8 -c "import sys; from pathlib import Path; sys.stdout.reconfigure(encoding='utf-8'); print(Path(sys.argv[1]).read_text(encoding='utf-8'))" "PATH"

Get-Content -Encoding UTF8 controls input decoding, not captured stdout. Avoid PowerShell content cmdlets and piping native readers through Select-String, Select-Object or Where-Object: they may re-encode stdout. Filter inside rg or Python instead. Apply UTF-8 reading to project files too; do not combine a safe skill read with an unsafe README read. Do not change global shell settings.

Workflow

Scope precedence: explicit BSP API review, including checking whether a method exists, requires the selected reference even when the recommendation uses platform APIs. Apply the version boundary below first. Standalone platform-only requests without BSP API review are outside this workflow; answer them directly. The presence of BSL files or a form element alone is not an integration task. A library-based migration/update write is an integration task even without an explicit BSP name or version; route it to update.md after the version check.

1. Check the requested BSP version. For a different version, explain that these 3.1.11 references cannot confirm its signatures and request matching documentation/export; this boundary check needs no API reference. For 3.1.11 or an unspecified version, select one primary reference from the task table. Add a second only for a genuinely cross-cutting task, such as printing in a background job.
2. Bind the installed root to the parent of the absolute SKILL.md file you successfully opened. Build the selected path as INSTALLED_ROOT/references/REFERENCE.md; each skill has its own root. Open that file before an integration/API answer. Locate the scenario using native rg -n headings/context, then check its rules, signature, example and pitfalls. The router and remembered knowledge are insufficient. If a search fails, run the reference fallback below using that same absolute SKILL.md path. A project file listing may omit hidden .agents/; it does not prove the installed reference is absent. A system skill's path is not the root of this project skill. Declare the reference unavailable only after the fallback fails; otherwise use its scenario.
3. If the user proposes a call or rule, check its original full Module.Method name and purpose. Identify mismatches explicitly. An API signature verified for 3.1.11 is not verification for another BSP version.
4. Prefer the stable public programmatic-interface region. Internal or deprecated APIs require an explicit warning and no public alternative. Show overridable-module hooks as implementations: BSP calls them; application code implements them, not a direct qualified module call. Exact Russian region and suffix names are documented in fundamentals.md.
5. If a configuration XML export containing CommonModules/ is available, additionally verify each recommended signature/region with bsp_api.py. Otherwise use the supplied reference and do not claim source verification.
6. Answer in the user's language: API, client/server execution context, minimal BSL example and important constraints. Check each full BSP call name and argument order against the reference or available export. Take application-specific object/handler names from the task or project; do not invent symmetric BSP methods. Discuss absent/internal/forbidden calls in prose or inline code, not a runnable fenced BSL example.