---
name: 1c-code-index
description: Use for bounded read-only 1C source discovery, structure, references, call graphs, and impact analysis through the profile-selected code-index.
---

# 1C code-index

Use the selected directory's profile, its exact alias and authorized repository.
Apply the knowledge gate and [source separation](../1c-routing/SKILL.md).
An indexed fact is not a live fact or normative requirement; a mechanism found
in knowledge does not prove its presence or contract in the selected index.
When readiness is unknown/invalidated, confirm alias-to-real-path correspondence,
freshness and the required index layer. Each profile root's daemon serves its
configurations; sessions of the same root share the daemon but not result history.
Directory/profile/revision changes invalidate affected evidence. Do not stop the
daemon when switching tasks or disconnecting: it may serve another session.
Distinguish indexed-revision facts from the current working copy. A narrow query
to the assigned EDT is allowed for an already known symbol, contract, metadata or
specific dependency when a missing live fact is needed. It does not restore an
unavailable index or authorize general EDT discovery, repository traversal or
lifting a dependent block. Unaffected indexed facts retain their applicability
limits; conflicts refresh only related evidence.
An API card's verification date and knowledge Git revision do not confirm current
source. For applicability, consider working branch/revision, significant uncommitted
changes, actual library/platform version and execution context.
Resolve only significant discrepancies through the authorized authority; without
this, do not promote a card or old indexed fact to confirmation of the current contract.

Choose capabilities from the installed MCP's live descriptions and schemas;
reuse them until reconnect, binding change or a change notification. Do not pin
a version, source repository URL, tool catalogue or allowlist in the skill.
Ordinary queries do not require a full capability audit. Do not emulate an
unavailable capability.

First formulate the question and choose the most compact sufficient response.
For functionality purpose, start with semantic search; for a known object/symbol,
use targeted structured reads. For large modules/procedures, obtain a map or
skeleton before needed bodies or ranges. Start graphs at depth 1; a path between
known points is preferable to a large tree. Specialized object, impact, posting,
form, permissions or DCS overviews replace repeated XML reads and general SQL.
Detailed selection and completeness rules:
[analysis and response budget](references/analysis.md) — read for complex analysis,
ambiguous results or missing specialized routes.

By default request up to 10–20 matches, brief fields and only the needed section;
specify exact file/object/direction immediately. An incomplete page, omitted
section, suppression of previously delivered rows and an empty result have
different meanings. Account for completeness markers and continuation hints;
do not raise the overall budget or read all pages merely to traverse them.
One unresolved fact justifies one targeted expansion.
Reuse sufficient evidence; do not duplicate it in EDT. The index is not a writer,
live truth, platform reference or primary diagnostics. Unavailability, staleness,
errors and incompleteness block only dependent conclusions, not independent
answers using a ready layer.

## Reuse-gate

The unit of review is a new technical operation by purpose, even in two BSL lines:
for example, a default value, user message, object filling, path resolution or
project validation. `Если`, assignment, local loops and reuse of a confirmed
mechanism do not themselves require search. The check does not mean a network
request for every statement or already known API.

Choose sufficient depth:

| Mode | Basis | Action |
| --- | --- | --- |
| Known mechanism | Contract already confirmed for the applicable context and not invalidated | Use evidence without searching again |
| Quick clarification | Mechanism new to the task, low risk, one narrow fact missing | One grouped semantic search and verification of the missing fact |
| In-depth verification | Shared API, supplier distribution, permissions, data, transactions, client/server or substantial effects | Confirm contract, consumers and consequences in the current context |

For a new mechanism, use explicitly selected knowledge when enabled; verify
platform APIs through $1c-platform-docs without duplicate knowledge search,
and indexed/current facts under [authority roles](../1c-routing/SKILL.md).
A known mechanism does not cancel mandatory source readiness: no new search does
not remove the knowledge gate, including the entire KORA workflow.
First account for mandatory project APIs/settings from current instructions.
A direct library call does not replace a project wrapper without checking its
contract, owner and whether the solution is allowed; a discovered contradiction
requires resolution within authorized scope rather than silent bypass.
If no mandatory contract exists, choose by applicability and risk without forcing
unsuitable legacy use. `recommendation: avoid` prohibits proposing the candidate
for a new call; compatibility, unacceptable effects or the cost of changing shared
legacy may justify a local solution. Record the specific reason for new code.

Before a new semantic operation, express its purpose in 1–3 semantic terms.
When index search is needed, search the current alias; include dependencies only
on evidence, not directory proximity. Platform/BSP reference follows $1c-platform-docs.

By default, examine at most five relevant candidates through targeted reads.
Check purpose, parameters, return contract, client/server context, export/access
and ownership. Compare applicable platform, library and project versions, call
restrictions and substantial effects: permissions, transactions, data writes,
events and lifecycle. A similar name or API status `confirmed` outside its
confirmed scope does not prove suitability.
For ambiguity use depth-1 references/callers. One unresolved fact permits one
justified expansion; exceeding five candidates needs a specific
ambiguity/coverage/conflict reason. Stop at a suitable solution; do not keep
surveying alternatives for their own sake.

Compare applicable reuse, narrow local adaptation and new implementation by
contract, substantial effects, maintenance risk and sufficient complexity.
Adaptation preserves the candidate's contract and authorized scope. A nonexported
method does not immediately justify duplication: assess ownership and possible
solutions within your scope. Changing another owner's/shared API is a separate
change with consumers, an owner and necessary authorization; do not automatically
expand the current task with it.
New logic requires no suitable candidate, an established mismatch in contract,
context, ownership or coverage, or substantial risk/disproportionate adaptation
complexity. Empty search proves absence only within ready, complete documented
coverage. A candidate in another component does not expand permission to modify it.

Stop searching when facts suffice for a choice within authorized scope; traversing
remaining pages and alternatives for completeness is unnecessary. Retain the brief
decision, applicable options examined and substantial limits: selected
collections/alias, branch/revision, partial/truncation and unchecked conditions.
Do not present a gap as proven absence of a mechanism; when a mandatory fact is
missing, stop the dependent conclusion under $1c-routing.
An index/live EDT conflict invalidates indexed evidence until freshness is
restored; conflicting mandatory authorities block dependent work.
Do not replace a missing index with repeated general discovery through EDT or shell.