1c Bsl Code Generation

1C BSL Code Generation with Anti-Hallucination Validation

Introduction & When to Use

This skill provides mandatory procedures for generating 1C:Enterprise (BSL) code with strict validation to prevent hallucinations and ensure code correctness.

Trigger this skill when:

• Generating, editing, or validating 1C BSL code
• Working with 1C metadata objects (Справочники, Документы, Регистры, etc.)
• Using 1C platform API
• Writing 1C Query Language code
• Answering questions about 1C platform capabilities

Keywords for detection:

• 1с, bsl, 1c:enterprise, справочник, документ, регистр, язык запросов
• catalog, document, register, query language

Semantic triggers:

• Creating/editing/validating BSL code
• Working with 1C configuration metadata
• Implementing 1C business logic
• Writing procedures/functions in BSL

🚨 CRITICAL: Absolute Compliance Requirements

⚠️ THESE RULES ARE NON-NEGOTIABLE AND MUST BE FOLLOWED WITHOUT EXCEPTION ⚠️

Failure to follow these rules constitutes a CRITICAL ERROR and produces hallucinated, potentially broken code.

Core Anti-Hallucination Principles

MANDATORY RULES - NO EXCEPTIONS ALLOWED:

1. 🚫 NEVER ASSUME 1C API EXISTS

• PROHIBITION: Writing ANY platform API call without validation
• MANDATORY ACTION: ALWAYS call getMembers() BEFORE using any method/property
• CONSEQUENCE: Hallucinated methods that don't exist = broken code
• ENFORCEMENT: If API not validated → STOP and validate first

2. 🚫 NEVER ASSUME METADATA EXISTS

• PROHIBITION: Using metadata objects (Справочники., Документы., etc.) without verification
• MANDATORY ACTION: ALWAYS verify through search_metadata or search_metadata_by_description
• CONSEQUENCE: References to non-existent objects = runtime errors
• ENFORCEMENT: If metadata not verified → STOP and verify first

3. 🚫 NEVER WRITE CODE FROM SCRATCH IF PATTERN EXISTS

• PROHIBITION: Writing new implementations without searching for existing patterns
• MANDATORY ACTION: ALWAYS call search_code() FIRST before writing new code
• CONSEQUENCE: Duplicate code, missed best practices, inconsistent patterns
• ENFORCEMENT: If pattern search not performed → STOP and search first

4. ✅ ALWAYS VALIDATE BEFORE WRITE

• REQUIREMENT: Complete validation workflow BEFORE writing ANY .bsl file
• MANDATORY CHECKS: API validated + Metadata verified + Patterns searched
• CONSEQUENCE: Skip validation = high probability of errors
• ENFORCEMENT: Cannot proceed to file write without completed validation

5. ✅ ALWAYS LINT AFTER WRITE

• REQUIREMENT: Run read_lints() IMMEDIATELY after writing ANY .bsl file
• MANDATORY FIX: Fix ALL critical errors before proceeding
• CONSEQUENCE: Linter errors left unfixed = broken code in repository
• ENFORCEMENT: 0 critical errors required, max 3 fix attempts, then escalate to user

🔴 CRITICAL ENFORCEMENT POLICY

• These rules are NOT suggestions or recommendations
• These rules are ABSOLUTE REQUIREMENTS
• Agent MUST NOT skip any validation step
• Agent MUST NOT proceed if validation fails
• Agent MUST STOP and report if unable to validate

Violation examples that are STRICTLY FORBIDDEN:

❌ "I'll write the code quickly without checking API"
❌ "I assume this method exists based on similar patterns"
❌ "I'll skip search_code() because I know the pattern"
❌ "Linter check can be done later"
❌ "This is simple code, doesn't need validation"

Correct approach - MANDATORY statements:

✅ "BEFORE writing code, I MUST validate API via getMembers()"
✅ "BEFORE using metadata, I MUST verify via search_metadata()"
✅ "BEFORE implementing, I MUST search existing patterns via search_code()"
✅ "AFTER writing file, I MUST run read_lints() immediately"
✅ "IF validation fails, I MUST STOP and resolve before proceeding"

MCP Tools Reference

A. API Validation Tools (mcp_bsl-platform-context_*)

Usage strategy: Proactive validation BEFORE code generation + Reactive fixes AFTER linter errors

PROACTIVE Tools (use BEFORE writing code)

1. getMembers - Get ALL members of a type

• When: BEFORE generating code that uses platform types
• Purpose: Understand available methods/properties of a type
• Syntax: bsl-platform-context.getMembers(typeName: "TypeName")
• Example: getMembers("СправочникМенеджер") → list all catalog manager methods
• Use case: "I need to work with Справочник → check what methods are available"
• Critical: Call this FIRST to avoid hallucinating non-existent methods

Example call:

{
  "typeName": "СправочникОбъект"
}

Expected result: List of all methods and properties available for the type

2. getConstructors - Get constructors for a type

• When: Need detailed description of class constructor
• Purpose: Understand how to create instances of a type
• Syntax: bsl-platform-context.getConstructors(typeName: "TypeName")
• Example: getConstructors("ТаблицаЗначений") → how to create ValueTable
• Use case: Creating new objects, need to know constructor signatures

Example call:

{
  "typeName": "ТаблицаЗначений"
}

Expected result: List of available constructors with parameters

REACTIVE Tools (use AFTER linter errors)

3. search - Search API by description

• When: Linter reports unknown method/property AND need to find alternatives
• Purpose: Find correct method name when linter says current one doesn't exist
• Syntax: bsl-platform-context.search(query: "description", type: "method|property|type", limit: 10)
• Example: Linter error "Method 'НайтиПоКоду' not found" → search with query "find catalog by code"

Example call:

{
  "query": "find by code",
  "type": "method",
  "limit": 10
}

4. getMember - Get specific member details

• When: Linter reports error with specific method/property
• Purpose: Verify exact signature and parameters of a member
• Syntax: bsl-platform-context.getMember(typeName: "Type", memberName: "Member")
• Parameters: typeName, memberName
• Example: Linter error on Записать() → getMember("СправочникОбъект", "Записать")

Example call:

{
  "typeName": "СправочникОбъект",
  "memberName": "Записать"
}

5. info - Detailed information about API element

• When: Linter error AND need full documentation
• Purpose: Get complete documentation for troubleshooting
• Syntax: bsl-platform-context.info(name: "ElementName", type: "method|property|type")
• Parameters: name (exact name), type (method/property/type)
• Example: Complex linter error → info("НайтиПоСсылке", "method") for full docs

Example call:

{
  "name": "НайтиПоСсылке",
  "type": "method"
}

API Validation Workflow

BEFORE code generation (proactive):

1. Identify platform types used in task (СправочникМенеджер, ДокументОбъект, etc.)
2. For EACH type:
   ├─ Call getMembers(type) → get available methods/properties
   └─ If creating instances → call getConstructors(type)
3. Select correct methods from validated list
4. Write code using ONLY validated API

AFTER linter errors (reactive):

If linter reports API errors:
1. Identify error type:
   ├─ Unknown method/property → use search() to find correct name
   ├─ Wrong signature → use getMember() to verify parameters
   └─ Complex error → use info() for full documentation
2. Fix code with correct API
3. Re-run linter

B. Metadata Validation Tools (mcp_1c-metacode_*)

Priority order of tool usage:

1. search_code (PRIMARY) - ALWAYS search for existing patterns FIRST
2. search_metadata_by_description - when uncertain about metadata names
3. search_metadata - for structural queries and finding usage

1. search_code - Finding existing code patterns (PRIMARY TOOL)

• CRITICAL: Use FIRST before writing any new code
• Purpose: Find existing implementations, procedures, functions to reuse
• Query language: RUSSIAN only (критично!)
• Parameter is_ssl_api: true for БСП/SSL (standard subsystems library) code
• Operations:
  • find_routines_by_description - search by description
  • get_routine_body - get full procedure/function body

Template JSON format (mandatory):

{
  "op": "find_routines_by_description",
  "text": "запись справочника",
  "is_ssl_api": false,
  "limit": 50
}

Examples:

• "запись справочника" → find existing catalog write patterns
• "проведение документа" → find document posting patterns
• "формирование движений" → find register movement patterns
• "работа с файлами" with is_ssl_api: true → find SSL file handling routines

When to use:

• ALWAYS before writing new procedure/function
• When implementing common patterns (write, post, validate, etc.)
• When working with БСП/SSL functionality

2. search_metadata_by_description - Semantic metadata search

• When to use: Agent is UNCERTAIN about exact metadata object names
• Purpose: Find objects by business description/purpose
• Query: Natural language description in Russian
• Template JSON format (mandatory):

{
  "op": "search_metadata_by_description",
  "text": "справочники для хранения банковских счетов",
  "categories": ["Справочники"],
  "limit": 50
}

Examples:

• "справочники для хранения банковских счетов" → find bank account catalogs
• "документы поступления товаров" → find goods receipt documents
• "регистры с информацией о ценах" → find price information registers

Use case: When user mentions business entity but exact 1C object name is unknown

3. search_metadata - Structural queries

Purpose:

• Get object structure (attributes, tabular parts, etc.)
• Find objects that USE specific attribute/resource/dimension

Template JSON mode (MANDATORY!)

Key operations:

object_structure - Get full structure

{
  "op": "object_structure",
  "object": "Контрагенты"
}

Returns: attributes, tabular parts, resources, dimensions

list_attributes - Get object attributes

{
  "op": "list_attributes",
  "object": "Контрагенты",
  "limit": 500
}

list_tabular_attributes - Get tabular section attributes

{
  "op": "list_tabular_attributes",
  "object": "Счёт",
  "tabular": "Позиции",
  "limit": 500
}

find_objects_by_attribute - Find objects using specific attribute

{
  "op": "find_objects_by_attribute",
  "attr": "ИНН",
  "match": "contains",
  "limit": 500
}

find_objects_by_resource - Find objects using specific resource

{
  "op": "find_objects_by_resource",
  "resource": "Сумма",
  "match": "exact",
  "limit": 500
}

find_objects_by_dimension - Find objects using specific dimension

{
  "op": "find_objects_by_dimension",
  "dimension": "Контрагент",
  "match": "exact",
  "limit": 500
}

find_objects_using_object - Find where object is used as attribute/resource/dimension

{
  "op": "find_objects_using_object",
  "target": "Контрагенты",
  "match": "exact",
  "in_category": "Документы",
  "include_tabular": true,
  "limit": 500
}

find_usages_of_object - Find usage sites (full paths)

{
  "op": "find_usages_of_object",
  "target": "Контрагенты",
  "match": "exact",
  "limit": 500
}

Returns 1C-style paths like:

• "Справочники.Номенклатура.Реквизиты.Владелец"
• "Документы.Счёт.ТабличныеЧасти.Позиции.Реквизиты.Номенклатура"

Critical use case: "Find all documents that use Справочник.Контрагенты" → use find_objects_using_object

Metadata Validation Workflow

Step 1: Pattern Search (PRIMARY - do this FIRST!)
└─ Call search_code() with task description in RUSSIAN
   └─ If patterns found → use as foundation for implementation

Step 2: If uncertain about metadata names
└─ Call search_metadata_by_description() in RUSSIAN
   └─ Identify correct object names

Step 3: Structural validation
├─ Call search_metadata(op: "object_structure") → get full structure
└─ Validate that required attributes/tabular parts exist

Step 4: Find usage (if needed)
├─ find_objects_by_attribute() → "What uses this attribute?"
├─ find_objects_by_resource() → "What uses this resource?"
├─ find_objects_by_dimension() → "What uses this dimension?"
└─ find_objects_using_object() → "What references this object?"

Step 5: Write code based on validated patterns and metadata

C. Code Validation Tools

Error Severity Levels (for Cursor Linter)

CRITICAL:

• Definition: Errors that MUST be fixed before code can be considered complete
• Examples: Syntax errors, undefined variables, type mismatches, missing required methods
• Requirement: 0 critical errors MANDATORY for completion

WARNING:

• Definition: Issues that should be addressed but don't break functionality
• Examples: Unused variables, deprecated methods, code style violations
• Requirement: Review warnings, fix if reasonable, document if left unfixed

INFO:

• Definition: Informational messages and suggestions
• Examples: Code optimization hints, alternative approaches
• Requirement: Optional to address

For this skill: "0 critical errors" means zero CRITICAL-level errors. Warnings and info messages should be reviewed but don't block completion.

1. Cursor Linter (read_lints) - Primary validation

• When: AFTER writing EVERY file (PRIMARY CHECK - always run first)
• Purpose: Check for syntax and semantic errors via BSL Language Server
• Success criteria: 0 CRITICAL-level errors
• Process: If CRITICAL errors found → analyze → fix → write corrected file → re-run linter

Example call:

read_lints(["path/to/file.bsl"])

Auto-fix loop:

1. Write BSL file
2. Call read_lints([file_path])
3. Analyze results by severity:
   ├─ CRITICAL errors found:
   │  ├─ Analyze error messages
   │  ├─ Determine fixes
   │  ├─ Apply fixes to code
   │  ├─ Write corrected file
   │  └─ Repeat from step 2 (max 3 attempts)
   ├─ Only WARNING/INFO found:
   │  └─ Proceed to additional validation (acceptable state)
   └─ No issues:
      └─ Proceed to additional validation
4. If CRITICAL errors remain after 3 attempts → escalate to user

2. 1c-copilot-proxy.check_1c_code - Additional validation

• When: AFTER linter check passes (secondary check)
• Purpose: Additional syntax/logic validation through 1C AI assistant
• Parameters:
  • code (text of code to check)
  • check_type (default: "syntax", options: "syntax", "logic", "performance")
• Types of checks:
  • syntax - syntax errors (additional to linter)
  • logic - logical errors and potential bugs
  • performance - performance issues

Example call:

{
  "code": "Процедура ПередЗаписью(Отказ)\n  // code here\nКонецПроцедуры",
  "check_type": "syntax"
}

Mandatory Validation Workflow

BEFORE Writing Any BSL Code

Complete this workflow BEFORE file write - NO EXCEPTIONS:

┌─────────────────────────────────────────────────────────────┐
│ Step 1: Pattern Search (PRIMARY - MUST do FIRST!)          │
├─────────────────────────────────────────────────────────────┤
│ IF task involves common pattern:                            │
│   1. Call search_code() with description in RUSSIAN        │
│   2. Review found patterns                                  │
│   3. IF suitable pattern exists:                            │
│      └─ Use as foundation (modify as needed)               │
│   4. IF no pattern found:                                   │
│      └─ Proceed to Step 2 (create new implementation)      │
│                                                              │
│ COMMON PATTERNS (always search first):                      │
│  • Catalog write/read (запись/чтение справочника)          │
│  • Document posting (проведение документа)                  │
│  • Register movements (формирование движений)               │
│  • Data validation (проверка данных)                        │
│  • Query construction (построение запроса)                  │
│  • File operations (работа с файлами)                       │
│  • Report generation (формирование отчёта)                  │
│  • Exchange/integration (обмен данными)                     │
│  • Scheduled jobs (регламентные задания)                    │
│  • Form event handlers (обработчики событий форм)           │
│                                                              │
│ IF task NOT in common patterns list:                        │
│  └─ Still run search_code() with task description          │
│     (may find relevant reusable code)                       │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│ Step 2: API Validation (for EVERY platform API call)       │
├─────────────────────────────────────────────────────────────┤
│ FOR EACH platform API usage:                                │
│   1. Identify object type (СправочникМенеджер,             │
│      ДокументОбъект, etc.)                                  │
│   2. Call getMembers(type)                                  │
│   3. Verify method/property exists in returned list         │
│   4. IF creating instances:                                 │
│      └─ Call getConstructors(type)                         │
│   5. IF method/property NOT found:                          │
│      ├─ STOP code generation                               │
│      └─ Report to user with available alternatives         │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│ Step 3: Metadata Validation (for EVERY metadata usage)     │
├─────────────────────────────────────────────────────────────┤
│ FOR EACH metadata object (Справочники.*, Документы.*, etc.):│
│   1. IF exact name unknown:                                 │
│      └─ Call search_metadata_by_description() in RUSSIAN   │
│   2. Call search_metadata(op: "object_structure")          │
│   3. Verify required attributes/tabular parts exist         │
│   4. IF attribute/tabular part NOT found:                   │
│      ├─ STOP code generation                               │
│      └─ Report to user with actual structure               │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│ Step 4: Write Code (ONLY after validation complete)        │
├─────────────────────────────────────────────────────────────┤
│   1. Write file with validated code                         │
│   2. Use ONLY validated API                                 │
│   3. Use ONLY verified metadata                             │
│   4. Follow pattern if found in Step 1                      │
└─────────────────────────────────────────────────────────────┘

ENFORCEMENT: Agent MUST NOT write file until Steps 1-3 are complete. If validation fails → STOP and report to user.

AFTER Writing BSL File

Complete this workflow IMMEDIATELY after file write - NO EXCEPTIONS:

┌─────────────────────────────────────────────────────────────┐
│ Step 5: Linter Check (MANDATORY PRIMARY CHECK)             │
├─────────────────────────────────────────────────────────────┤
│   1. Call read_lints([file_path])                           │
│   2. IF critical errors found:                              │
│      ├─ Analyze error messages                             │
│      ├─ IF API error:                                       │
│      │  ├─ Call search() or getMember() or info()          │
│      │  └─ Find correct API                                 │
│      ├─ Apply fixes to code                                 │
│      ├─ Write corrected file                                │
│      └─ Repeat from step 1 (max 3 iterations)              │
│   3. IF errors remain after 3 attempts:                     │
│      ├─ STOP processing                                     │
│      └─ Escalate to user with error details                │
│   4. SUCCESS: 0 critical errors → proceed to Step 6         │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│ Step 6: Additional Validation (via 1C Copilot)             │
├─────────────────────────────────────────────────────────────┤
│   1. Read final file content                                │
│   2. Call 1c-copilot-proxy.check_1c_code(code, "syntax")     │
│   3. IF issues reported:                                    │
│      └─ Apply fixes and repeat Steps 5-6                   │
│   4. SUCCESS: No issues → proceed to Step 7                 │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│ Step 7: Report to User                                      │
├─────────────────────────────────────────────────────────────┤
│   Report: "✅ Code validated successfully via:             │
│   - search_code() [pattern search]                          │
│   - getMembers() [API validation]                           │
│   - search_metadata() [metadata validation]                 │
│   - read_lints() [linter check: 0 errors]                  │
│   - check_1c_code() [additional validation: OK]"           │
└─────────────────────────────────────────────────────────────┘

ENFORCEMENT: Agent MUST NOT consider task complete until all steps pass. Zero critical errors is MANDATORY requirement.

Special Cases & Advanced Validation

1C Query Language Validation

When writing 1C Query Language code:

1. Parse query text
2. Extract ALL object names (tables)
3. FOR EACH object name:
   └─ Call search_metadata(op: "object_structure", object: name)
4. Extract ALL field names
5. FOR EACH field:
   └─ Verify exists in object structure (from step 3)
6. IF any object/field NOT found:
   ├─ STOP code generation
   └─ Report missing elements to user
7. Write query with validated object and field names

Example:

Query: "ВЫБРАТЬ Контрагенты.Наименование, Контрагенты.ИНН ИЗ Справочник.Контрагенты"

Validation steps:
1. Extract object: "Контрагенты"
2. Call search_metadata(op: "object_structure", object: "Контрагенты")
3. Verify fields: "Наименование", "ИНН" exist in structure
4. IF all verified → write query

БСП/SSL (Standard Subsystems Library) Code

When working with standard subsystems:

1. ALWAYS set is_ssl_api: true in search_code()
2. Search for standard procedures BEFORE writing custom ones
3. Example: File operations → search "работа с файлами" with is_ssl_api: true
4. Prefer standard procedures over custom implementation

Example call:

{
  "op": "find_routines_by_description",
  "text": "работа с файлами",
  "is_ssl_api": true,
  "limit": 50
}

Query Strings in Code

When code contains query as string variable:

1. Extract query text from string
2. Parse query (identify SELECT, FROM, WHERE clauses)
3. Extract table and field names
4. Validate each name via search_metadata
5. IF validation fails:
   ├─ STOP
   └─ Report invalid names to user
6. Write code with validated query

Integration with Existing Rules

This skill complements existing project rules:

Integration Order

1. Skills Index Detection
   └─ Keywords detected → load 1C_BSL_SKILL

2. Apply Anti-Hallucination Rules (this skill)
   ├─ NEVER assume API/metadata
   ├─ ALWAYS validate before write
   └─ ALWAYS lint after write

3. Follow TDD Workflow (if AgentMode.rules.md exists)
   ├─ Write tests first
   ├─ Implement with validation
   └─ Run tests

4. Apply Project-Specific Rules (if project_bsl_rules.mdc exists)
   ├─ Add required comment blocks
   ├─ Update registry.md
   └─ Follow DSSL UT conventions

Rule Files Reference

• project_bsl_rules.mdc - Change commenting rules (DSSL UT specific)
• AgentMode.rules.md - TDD workflow and gate system
• PlanMode.rules.md - Planning and specifications
• 1C_BSL_SKILL.md (this file) - Anti-hallucination validation

Priority: Anti-hallucination rules (this skill) are MANDATORY and apply BEFORE any other rules.

Examples

Example 1: Creating Catalog Write Function

User request: "Create function to write Catalog.Контрагенты"

Agent workflow (MUST follow exactly):

Step 1: Pattern Search
✅ Call: search_code(op: "find_routines_by_description", 
                     text: "запись справочника контрагенты",
                     is_ssl_api: false, limit: 50)
   Result: Found 3 existing patterns
   Action: Review patterns, select most suitable as foundation

Step 2: Metadata Validation
✅ Call: search_metadata_by_description(text: "справочник контрагенты")
   Result: Found "Справочники.Контрагенты"
✅ Call: search_metadata(op: "object_structure", object: "Контрагенты")
   Result: Structure with attributes: Наименование, ИНН, КПП, etc.

Step 3: API Validation
✅ Call: getMembers("СправочникОбъект.Контрагенты")
   Result: Methods confirmed: Записать(), УстановитьСсылкуНового(), etc.

Step 4: Write Code
✅ Write function based on:
   - Found pattern (Step 1)
   - Validated metadata structure (Step 2)
   - Confirmed API methods (Step 3)

Step 5: Linter Check
✅ Call: read_lints(["path/to/file.bsl"])
   Result: 0 errors

Step 6: Additional Validation
✅ Call: check_1c_code(code, "syntax")
   Result: OK

Step 7: Report
✅ Report to user: "✅ Code validated via search_code(), search_metadata(),
   getMembers(), read_lints() (0 errors), check_1c_code() (OK)"

Example 2: Writing Query for Catalogs

User request: "Write query to get Контрагенты with ИНН"

Agent workflow (MUST follow exactly):

Step 1: Pattern Search (query patterns)
✅ Call: search_code(op: "find_routines_by_description",
                     text: "запрос справочника контрагенты",
                     is_ssl_api: false, limit: 50)
   Result: Found example query patterns

Step 2: Metadata Validation
✅ Call: search_metadata_by_description(text: "справочник контрагенты")
   Result: "Справочники.Контрагенты"
✅ Call: search_metadata(op: "list_attributes", object: "Контрагенты", limit: 500)
   Result: Attributes list including "ИНН"
   Action: Verify "ИНН" exists → ✅ Confirmed

Step 3: Write Query
✅ Write query with validated names:
   "ВЫБРАТЬ
   |  Контрагенты.Ссылка,
   |  Контрагенты.Наименование,
   |  Контрагенты.ИНН
   |ИЗ
   |  Справочник.Контрагенты КАК Контрагенты
   |ГДЕ
   |  Контрагенты.ИНН <> """

Step 4: Validation
✅ Call: read_lints() → 0 errors
✅ Call: check_1c_code() → OK

Step 5: Report
✅ Report successful validation

Example 3: Linter Error Recovery

Scenario: Linter reports error on unknown method

Agent workflow (MUST follow exactly):

Initial code written:
Процедура Записать()
  СправочникОбъект.СохранитьДанные(); // ❌ Method doesn't exist!
КонецПроцедуры

Step 1: Linter detects error
✅ Call: read_lints(["file.bsl"])
   Result: Error "Method 'СохранитьДанные' not found"

Step 2: Reactive API validation
✅ Call: search(query: "save catalog data", type: "method", limit: 10)
   Result: Suggests "Записать()"
✅ Call: getMember("СправочникОбъект", "Записать")
   Result: Confirmed signature: Записать()

Step 3: Fix code
✅ Replace: СохранитьДанные() → Записать()

Step 4: Re-validate
✅ Call: read_lints() → 0 errors

Step 5: Report
✅ "Error fixed using search() and getMember(). Code now validated."

Error Handling & Fallbacks

If API Not Found

1. Report to user: "Method X not found for type Y"
2. Call getMembers(Y) → show available alternatives
3. Ask user: "Available methods: [list]. Which should I use?"
4. Wait for user confirmation
5. Use confirmed method

Example:

Agent: "Method 'НайтиПоКоду' not found for 'СправочникМенеджер'.
       Available methods: НайтиПоНаименованию(), НайтиПоРеквизиту().
       Which method should I use for finding by code?"

If Metadata Not Found

1. Report to user: "Object X not found in configuration"
2. Call search_metadata_by_description() with similar terms
3. Show similar objects found
4. Ask user: "Did you mean: [list of similar]? Or provide exact name?"
5. Wait for user clarification
6. Use confirmed object name

Example:

Agent: "Object 'Контрагент' not found.
       Similar objects found:
       - Справочники.Контрагенты
       - Справочники.КонтрагентыПоставщики
       Which one did you mean?"

If Linter Finds Errors (Auto-Fix)

1. Display errors to user
2. Attempt automatic fix (max 3 attempts):
   ├─ Iteration 1: Use search()/getMember() for API errors
   ├─ Iteration 2: Re-validate metadata if object not found
   └─ Iteration 3: Try alternative approach from search_code()
3. IF fixed → report success
4. IF not fixed after 3 attempts:
   ├─ Show remaining errors to user
   ├─ Explain what was tried
   └─ Request user guidance

Example:

Agent: "Linter found 2 errors. Attempting auto-fix...
       Iteration 1: Fixed API call using getMember()
       Iteration 2: Fixed metadata reference using search_metadata()
       ✅ All errors resolved. Code validated."

If Validation Tools Fail

IF MCP tool returns error:
1. Log the error
2. Report to user: "Validation tool X failed: [error message]"
3. Explain impact: "Cannot validate Y without tool X"
4. Ask user: "Proceed without validation? (NOT recommended)"
5. IF user approves:
   └─ Add comment in code: "// WARNING: Not validated due to tool failure"
6. IF user declines:
   └─ STOP and wait for tool to be available

Agent Checklist

Before completing BSL code generation, verify ALL items:

Pre-Write Validation

• Pattern search performed via search_code() (if applicable)
• ALL platform API calls validated via getMembers() or getMember()
• ALL metadata objects verified via search_metadata() or search_metadata_by_description()
• Object structures validated (attributes, tabular parts confirmed to exist)
• Query object/field names validated (if writing queries)

Post-Write Validation

• File written with validated code
• read_lints() executed → 0 critical errors achieved
• 1c-copilot-proxy.check_1c_code() executed → OK
• All linter errors fixed (max 3 attempts used if needed)

Reporting

• User notified of successful validation
• List of validation tools used provided to user
• Any warnings or caveats communicated clearly

STOP Conditions (DO NOT PROCEED if any true)

• API validation failed and user has not provided guidance
• Metadata not found and user has not clarified
• Linter errors remain after 3 fix attempts
• Validation tool unavailable and user has not approved proceeding

Summary: The Absolute Rules

1. NEVER write code without validating API via getMembers()
2. NEVER use metadata without verifying via search_metadata()
3. ALWAYS search for existing patterns via search_code() first
4. ALWAYS run read_lints() immediately after writing file
5. ALWAYS achieve 0 critical linter errors before completion
6. STOP immediately if validation fails - escalate to user
7. REPORT all validation steps performed to user

These rules are ABSOLUTE. Violations produce hallucinated, broken code.

This skill ensures code quality and prevents hallucinations through systematic validation. Follow every step without exception.