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:

bashCopy code
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.

The skill is self-contained and needs no developer documentation or source export. Resolve references/ and scripts/ relative to this installed SKILL.md, not the project's working directory. src/cf/ is only an example export path, not a consumer project requirement.

Reference fallback

Replace ABSOLUTE_SKILL_MD with the file you opened (use forward slashes), and REFERENCE.md with the selected table entry. This reads independently of cwd:

bashCopy code
python -X utf8 -c "from pathlib import Path; p=Path('ABSOLUTE_SKILL_MD').parent/'references'/'REFERENCE.md'; print(p.read_text(encoding='utf-8'))"

Task routing

For an unmapped BSP task, start with fundamentals.md. It also lists intentionally uncovered subsystems. References are workflows, not just a searchable method catalog: use the complete scenario, not an isolated matching name.

Optional configuration-export verification

Replace SKILL_DIR with this installed skill directory, CF_EXPORT with the export root containing CommonModules/, and MODULE/METHOD with real names. The export is read-only and not bundled. Python UTF-8 mode keeps CLI output readable on Windows without changing global settings.

bashCopy code
# Signature, region, documentation, source path and line range.
python -X utf8 "SKILL_DIR/scripts/bsp_api.py" method METHOD --module MODULE --src "CF_EXPORT"

# One module's exported methods across all regions.
python -X utf8 "SKILL_DIR/scripts/bsp_api.py" module MODULE --src "CF_EXPORT"

# Modules exposing stable public API.
python -X utf8 "SKILL_DIR/scripts/bsp_api.py" modules --src "CF_EXPORT"

--module disambiguates same-named methods. --src is mandatory: no automatic export discovery; missing paths or CommonModules/ yield a nonzero exit code. module includes all regions; modules lists stable API modules only. The output marks hooks, internal and deprecated methods; retain these warnings.

A text search of subsystem XML can locate a common-module reference, but assigning Catalog/Document objects to a subsystem requires parsing its Item references, including nested subsystem XML, not a guessed grep match.