1c-change-package — manual implementation and review packages
The deliverable is a document, not an edit: the agent reads the current code, designs the change and hands over a package that a human applies in the Configurator (manual mode) or reviews (review mode). Nothing is written to the sources, the infobase or the repository. The idea is adapted from the bsl-change-review skill of AzeevAN/mcp-1c (Apache-2.0); the text and the evidence vocabulary are this ruleset's own.
When this is the deliverable
- Manual — the agent must not or cannot write the change itself: a vendor object «на замке» the user chose not to take off support or borrow into an extension (
content/skills/1c-metadata-manage/docs/support-manage.md); an ordinary / binary form (content/rules/forms.md— ordinary forms are not edited asForm.xml); an object locked in the configuration repository by another user (content/skills/1c-repository-manage/SKILL.md— never bypass the lock); the code is reachable only through MCP; or the user asked for instructions / code to copy. - Review — the user wants to see the change before it is applied: «покажи дифф», «покажи изменения», «сравни текущий и новый код», «сделай ревью изменения».
- The user named a mode — keep it. Both fit and the goal is unclear — ask one short question before reading a reference.
Read exactly one reference for the chosen mode: references/manual-implementation.md or references/review.md.
Common procedure
- Current source, verbatim. Read the exact current text of every procedure, block, form and property the change touches — a local file first, MCP (
1c-code-search,1c-meta-info,1c-form-inspect) when the sources are not local. Never reconstruct current code from memory or a summary. No exact text → that change isblocked — <reason>. - Fix the snapshot. Record for each source: configuration / extension (or
unverified), full address (object, module, procedure / form, element), where it was read (file path or MCP tool), platform version, and a fingerprint — the file hash or a hash of the exact text read (the same artifact fingerprintcontent/rules/verification-gates.md → Gate execution and evidence reuseuses). - Minimal change. Only what the task requires (
AGENTS.md → Development Procedure, step 3); an unfinished part is listed as unfinished, never presented as done. - Prove the API. Before writing
Переменная.Метод(), establish the variable's type from its creation, assignment or the returning function; then confirm<Тип>.<Метод>and its signature withdocinfo/bsl_scope_members(content/skills/1c-platform-help/SKILL.md). A method whose return value or failure matters is confirmed the same way. What cannot be confirmed isunverified, and code that depends on it isblocked— never a placeholder. - Gates on the proposed code. The new blocks have no file yet, so Gate 1 runs on the text (
syntaxcheck), followed by the rest of the chain at the active depth —content/rules/verification-gates.md, budgetcontent/rules/verification-policy.md. Generated XML goes throughverify_xml. A gate that could not run isnot run — <reason>. - Staleness check. Re-read every source right before delivery and compare the fingerprint: same → current; changed → the package is stale, redo it or mark it
blocked — source changed since <time>; cannot re-read →unverified. - Deliver. By default the whole package goes into the reply. Write a file only to a path the user gave: an explicit file path is used as is; for an explicit directory the file is
IMPLEMENTATION.md(manual) orchange-review.md(review). Never write to the project root, the current directory, the skill directory or a scratch folder on your own. If the write fails, return the package in the reply and say so. - Self-review. Re-read the package against the source as an independent reviewer: every «Найти» block is verbatim, every line order is real, no check is claimed that did not run.
Evidence vocabulary
The package reuses the ruleset's delivery vocabulary (content/rules/verification-delivery.md, content/rules/verification-gates.md); no second set of states:
| State | Meaning |
|---|---|
passed | the gate or check ran on the current state; name the tool and its result |
not run — <reason> | the check applies but did not run (tool not exposed, no dev / test base, out of budget) |
unverified | a fact the package relies on was not established — a property value not read, a type not proven, a match count not counted, a scenario not confirmed |
blocked — <reason> | a correct block cannot be written (missing code, missing contract, stale source); nothing is invented in its place |
Behaviour requires expected-vs-actual evidence from an authorized infobase check (Gate 3a) or UI confirmation under UI_TESTING (1c-tester, /deploy-and-test — content/rules/verification-delivery.md → Soft gates — run when applicable). Static gates and review alone do not prove runtime outcomes. Plan checks in the package; a scenario nobody confirmed is unverified, never «done». The usual evidence lines (Memory:, Template:, Docs:, …) follow the package when they apply; Metadata tooling: / Repository tooling: do not, because the package changes nothing.
Boundaries
- Reading files and calling read-only MCP tools gives no permission to change the configuration, the infobase, the repository or a container. Applying the package, compiling in the Configurator, updating an infobase and capturing / committing repository objects are separate actions with their own authorization.
- No secrets and no customer code in shared places.
- A package is never a way around a gate: a vendor lock, a repository lock or a refused tool stays in force, and the package says who applies the change and where.
