What problem does it solve? 1C:Enterprise code often loses updates, deadlocks, or leaves transactions unpaired because reads that drive writes are not locked, exceptions are mistaken for rollbacks, and lock order is never stated. This Skill gives a concrete model and workflow for building correct transactions with managed locks and responsible reading. ## Core Features & Use Cases - Transaction shape enforcement: Ensures every НачатьТранзакцию has paired commit and rollback in the same method, with the correct Попытка/Исключение structure per standards АПК:325-332 and BSLLS:PairingBrokenTransaction. - Managed lock design: Classifies reads as responsible, names contended resources, sets exclusive or shared locks before reads, and keeps one lock order to prevent deadlocks. - Deadlock and lock-wait diagnosis: Builds a timeline from runtime evidence and identifies the contended resource before proposing changes, instead of blind retries or widened lock ranges. - Use Case: A posting handler throws "В этой транзакции уже происходили ошибки" under load. Use this Skill to locate the broken transaction boundaries with unica.code.outline, fix the exception block to call ОтменитьТранзакцию first, and verify with unica.code.diagnostics. ## Quick Start Ask the assistant to review a 1C module for transaction and locking correctness, for example: review this document posting procedure for responsible reads, managed locks, and deadlock risk.
