project-vault git:20260903.5031364A

Immutable. This exact content is served forever at /api/v1/blob/68b4f92a891e9979.

---
name: project-vault
description: >-
  Maintains project state in a markdown vault (key decisions, open questions,
  risks, contradictions, dependencies) from meeting transcripts, structured notes,
  PDF documents, or owner chat updates. Governs working tracks as the mandatory
  container for all productive activity (research, analysis, synthesis). Use for
  updating project-vault after meetings, dialog briefings, decision records, and
  next-meeting agendas. Triggers: project state, transcripts, meeting notes,
  PDF documents, chat updates, risks, dependencies, contradictions, ADR-style
  decisions, track creation and lifecycle, inbox processing.
---

# Project Vault — Personal Project Storage

Check owner's name in AGENTS.md in repo's root.
Users: owner + AI assistant.

## Vault Core

Key artifacts, maintained up-to-date:
- `project-vault/decisions/` — atomic decision cards (DEC-NNNN-slug.md); `_index.md` not hand-maintained — use `grep`/`SocratiCode` for discovery
- `project-vault/open-questions/` — atomic open question cards (Q-NNNN.md); `_index.md` not hand-maintained — use `grep "status: open"` for active set
- `project-vault/risks/` — atomic risk cards (RISK-NNNN.md); `_index.md` not hand-maintained — use `grep`/`SocratiCode`
- `project-vault/contradictions/` — atomic contradiction cards (CON-NNNN.md); `_index.md` not hand-maintained — use `grep`/`SocratiCode`
- `project-vault/dependencies.md` — external blockers
- `project-vault/state/constraints.md` — regulatory and architectural constraints
- `project-vault/tracks/` — operational tracks (`TRK-NNNN.md`), generated summary `_index.md` (from `scripts/vault.py`); closed/retired tracks stay here with `status` in frontmatter
- `project-vault/work/` — dated work records (WRK-YYYY-MM-DD-hhmmss.md), generated summary `_index.md` (from `scripts/vault.py`), template: `work/_template.md`
- `project-vault/methods/` — reusable method descriptions (`U.MethodDescription`, A.3.2)

Auxiliary:
- `project-vault/sources/` — captured originals (`captures/`) and analysis digests (`digests/`)
- `project-vault/agenda-next.md` — next meeting agenda (on demand)

**Discovery replaces hand-maintained indexes.** For entity discovery, searching, and registry, use:
- **Semantic search:** `SocratiCode codebase_search` over `project-vault/` (or `requirements/` for requirements)
- **Precise search:** `grep` over entity directories (e.g., `grep "status: open" project-vault/open-questions/`, `grep "status: active" project-vault/risks/`)
- **File listing:** `Get-ChildItem` / `ls` for full ID listing
- **Track/work indexes:** auto-generated by `scripts/vault.py` (called after each WRK completion — Procedure W.2, track status change — Procedure T.2/T.3)

**ID allocation.** New entity IDs (DEC/Q/RISK/CON/TRK) come from the vault CLI — never from manually scanning a directory: `python scripts/vault.py next-id` (all types) or `python scripts/vault.py next-id CON`. IDs are monotonic and never reused; closing/retiring an entity does not free its number. Verify integrity with `python scripts/vault.py check` (no duplicate or mismatched IDs).

**CLI path.** Every `scripts/vault.py` reference in this skill points to `project-vault/scripts/vault.py` *inside the repository* — during init the script is copied from `<skill>/scripts/vault.py` to `<repo>/project-vault/scripts/vault.py`. Invoke from the repo root:

```bash
python project-vault/scripts/vault.py <command> [--path <abs-path-to-project-vault>]
```

`--path` is required when invoking from any directory other than the repo root (the script's fallback path resolution assumes it lives under `<repo>/project-vault/scripts/`).

## Inbox Procedure

**Inbox:** on request "process inbox" (and similar), process files from `inbox/` using `project-vault` skill procedures. After full processing — clear `inbox/`.

**External research** (independent Knowy research, narrativizations, articles, conference talks, tutorials) process via **Procedure R** — with two-way binding to any project entities that accept references (Q, RISK, CON, DEC, TRK).

**PDF pre-processing:** if `.pdf` files are found in the inbox — before substantive processing, convert each PDF to Markdown using the `pdf2md` skill (script `scripts/extract_pdfs.py` with parameters `--source <inbox_dir> --first N`). Use the resulting `.md` file (in `inbox/_markdown/`) as source material for further processing per the standard procedures (Procedure A, T.4). Do not analyze the original PDF directly — only via the converted Markdown. If the `pdf2md` skill is unavailable or the conversion fails — record this in the inbox processing result and notify the user.

## Procedure A — State Update from Source

### Input 1 — Meeting Transcript

1. Save the captured source to `project-vault/sources/captures/`.
2. Create `project-vault/sources/digests/YYYY-MM-DD_slug.md` using customized `project-vault/sources/_digest-template.md` or otherwise default template `templates/digest-meeting.md`.
3. **Q Registry in Context:** before filling, find active open questions: `grep -l "^status: open" project-vault/open-questions/*.md`. Read the resulting files to understand which questions are open and relevant to the current source.
4. Fill digest only with what is verifiable from the source: context, links to created atomic files (DEC, Q, RISK, CON), reconciliation against Q registry. Decision/question/risk wording — only in atomic files, never copied into digest.
5. For **key** decisions: create/update `project-vault/decisions/DEC-NNNN-slug.md` using customized `project-vault/decisions/_decision_template.md` or otherwise default template `templates/decision.md`; `accepted` only upon explicit approval in the source.
   - **Entry gate (применяй ДО создания DEC):** создавай DEC только если у высказывания есть (а) ограниченный *архитектурный* вопрос, (б) положительно выбранный ответ, меняющий целевую систему/дизайн с долгоживущим последствием, и (в) будущий архитектор сможет на него опереться. Если формулировка — про содержание рабочего документа, редакционный выбор, повтор уже зафиксированной позиции или резюме без выбора → записать как факт/сигнал в дайджест, а не создавать DEC.
   - Fill **all** sections of the DEC template. Do not invent facts absent from the source; if something is unknown / not discussed / not applicable — state that in one or two words («не обсуждалось» / «неизвестно» / «не применимо»).
   - Set `decision_type` (one of `adr` | `org` | `strategy` | `scope` | `process` | `procurement` | `product`); fill `characteristic` only for `decision_type: adr`.
   - If «Рассмотренные варианты» lists ≥2 options — fill «Сравнение вариантов» (criteria + result per option). If one option — «вариант один».
   - Always fill «Условия пересмотра» (revisit conditions); set `revisit_by` or note it is open-ended.
6. Execute common steps below.

**When input is insufficient:**
- If transcript lacks enough information to fill a digest meaningfully → create a minimal digest noting "insufficient data" and stop.
- If a decision is mentioned but not explicitly approved → set `status: proposed`, note in digest "not yet accepted — pending owner confirmation".
- If a contradiction is suspected but not clearly stated → create CON entry with `status: proposed` and note "requires clarification".

### Input 2 — Dialogue News (no new transcript)

1. Create `project-vault/sources/digests/YYYY-MM-DD_slug.md` using template `templates/digest-dialogue.md`.
2. For key decisions — create/update DEC-* with `sources` pointing to digest.
3. If signals to active Q-* exist — record reconciliation.
4. Execute common steps below.

**When input is insufficient:**
- If the user statement is opinion/preference rather than a verifiable decision → create a digest noting "opinion expressed, not a decision" and skip DEC creation.
- If the dialogue contradicts an existing `accepted` decision → create CON entry and flag the decision with `revisit_by`.

### Common Steps After Input 1 or 2

1. When creating/closing atomic entities — create the corresponding file (DEC, Q, RISK, CON); closed entities stay in place with `status` set in frontmatter (no `archive/` mirror).
2. Update `project-vault/dependencies.md` when new external blockers appear.
3. Update `project-vault/state/constraints.md` when new regulatory or architectural constraints appear.
4. **Track maintenance:** when a source (meeting, briefing, directive) introduces a new operational signal, changes the status of an existing track, or closes one:
   - **New signal** → create `project-vault/tracks/TRK-NNNN.md` with status `cue` (using `tracks/_template.md`); then regenerate `tracks/_index.md` via `python scripts/vault.py tracks`.
   - **Status change** → update the track file (`status` field in frontmatter and inline status fields). Status transitions follow the elaboration lifecycle: `cue` → `problem-framed` → `method-selected` → `work-planned` → `in-progress` → `performed` → `evaluated`. Side transitions: `blocked` (from any active status), `deferred` (from any active status), `retired` (terminal). After status change — regenerate `tracks/_index.md`.
   - **Track closed/retired** → set `status: retired` in the track file (stays in `tracks/`); then regenerate `tracks/_index.md`.
   - **Track unblocked** → restore previous active status; then regenerate `tracks/_index.md`.
   - Do NOT create a track for every DEC/RISK/Q — only for operational lines that represent distinct work streams with blockers. A track typically spans multiple related DEC/RISK/Q/CON entities.
5. **Assignments to repo owner:** if a source (transcript, meeting protocol) contains an explicit assignment to the owner of this repo (referred by name) — only one directly expressed, without guessing or reading in:
   - Read `project-vault/tracks/_index.md` and select the most suitable existing track by topical similarity.
   - Record the assignment as a new numbered-list item in the track's "Next moves" field. If the source specifies a deadline — add `(deadline YYYY-MM-DD)`; if the deadline has already passed relative to today — `(deadline YYYY-MM-DD, overdue)`.
   - If the track field is named "Next step" (singular) and it is already occupied — convert it to "Next moves" (plural, numbered list: first item — the previous step, second — the new assignment).
   - Do **not** create a new track for a personal assignment — always assign it to an existing one.
   - If no existing track fits the topic — record it in the digest and flag it for the owner to resolve.

## Procedure R — External Research (reference material)

**Scope:** material that is neither a meeting transcript nor dialogue news: independent research (Knowy), narrativization, article, conference talk, tutorial. The purpose of processing is for the material to be taken into account in decision-making, not left as an "orphan".

1. Save the capture to `project-vault/sources/captures/`.
2. Create a digest `project-vault/sources/digests/YYYY-MM-DD_slug.md` (source_kind: `independent_research` / `web_article` / `conference` / `research_article`).
3. Discover active entities by searching over the vault: use `grep` for exact-match over directories (e.g., `grep -l "^status: open" project-vault/open-questions/`, `grep -l "^status: active" project-vault/risks/`, `grep -l "^status: open" project-vault/contradictions/`) and `SocratiCode codebase_search` for semantic discovery of relevant DEC/Q/RISK/CON/TRK by topic. Determine which entities accept references and are relevant to the material's topic.
4. Fill the "Reconciliation" section in the digest with a signal strength for each affected entity (`strong` / `partial` / `weak` / `supporting` / `no_signal`).
5. **Propagate signals into the entity files themselves (mandatory, two-way link):** for each affected entity (Q, RISK, CON, DEC — any that has a `sources`/`source` field or a "Related entities" section), append the signal to its file. Listing IDs only in the digest's "Reconciliation" (one-way link) is **not sufficient**.
   - For a **DEC**: add the signal as a bullet in the body subsection «Внешние сигналы» (only the essence + source name, no file paths); add the source file (digest) to the `sources:` frontmatter list. Do not put file paths/links in the body.
   - For **Q / RISK / CON**: record the signal as a frontmatter field `signal_YYYY-MM-DD` or a body note "Signal YYYY-MM-DD" with a link to the digest.
6. **Bind the digest to at least one reference-bearing entity:** add the digest to a track's "Related entities" → "Sources"/"Artifacts", or to the `sources`/`source`/"Related entities" of a suitable Q/RISK/CON/DEC (by topical similarity).
7. Create atomic entities (DEC/Q/RISK/CON) only if the material introduces a **new** decision/risk/question/contradiction. Purely reference material does not require them.
8. If the material is truly outside the scope of all entities — explicitly write "not bound — outside the project scope" in the digest (a deliberate decision, not an omission).
9. On substantial contribution — verify integrity: ensure all created entities (DEC, Q, RISK, CON, TRK) are properly filed and linked. No separate index update needed — discovery is via `grep`/`SocratiCode`.

## Procedure T — Track-Bound Productive Work

**Scope:** any productive activity (research, analysis, synthesis, architecture elaboration, artifact writing) is performed only within a track. Small one-step requests ("find a file", "explain a concept", "fix a typo") do not require a track.

### T.1 — User Request Arrives

1. Determine whether the request is productive activity (research, analysis, synthesis, multi-step work) or a small one-step task.
2. If it is a small task — perform it without a track, report the result.
3. **If the request does not point to a specific track** (e.g., "let's continue", "let's keep going"):
   a. Get the top-5 tracks by last-modified time: `Get-ChildItem project-vault\tracks\TRK-*.md | Sort-Object LastWriteTime -Descending | Select-Object -First 5`.
   b. Additionally review **all active** tracks (not `performed`, not `evaluated`, not `retired`) for deadlines in "Next moves": single out those with a `(deadline YYYY-MM-DD)` date within 3 calendar days of today (including overdue ones — marked "overdue").
   c. Show the combined list: top-3 by freshness + tracks with an approaching deadline (marked "approaching deadline YYYY-MM-DD" or "overdue deadline YYYY-MM-DD"). Sort: first overdue, then nearest deadline, then fresh. Propose the most urgent. Wait for confirmation.
4. If it is productive activity with an explicit topic — find a suitable track using `SocratiCode codebase_search` (semantic match by topic) or `grep -l "<keyword>" project-vault/tracks/TRK-*.md`:
   - **Exactly one suitable** → report in chat: "Continuing track TRK-NNNN (title), current status — X. Transitioning to Y." Wait for confirmation.
   - **Several similar** → show all candidates with their statuses, propose the most suitable. Wait for confirmation.
   - **None suitable** → report: "Creating a new track for [request essence]." Wait for confirmation.
5. After confirmation — act on the track.

### T.2 — New Track Creation

1. A new track **always** starts with status `cue`.
2. Further advancement — strictly per FPF-core: `cue` → problem card formulation (C.22.2 ProblemCard@Context) → `problem-framed` → method selection (G.5/A.15) → `method-selected` → work plan (A.15.2) → `work-planned` → execution (A.15.1) → `performed` → result evaluation → `evaluated`.
3. At each transition: announce in chat the intent to move the track to the next status with a brief rationale (what exactly changed), wait for confirmation, then update the track. After any status change — regenerate `tracks/_index.md` via `python scripts/vault.py tracks`.
4. Track creation: file `TRK-NNNN.md` per template `tracks/_template.md`; after creation — regenerate `tracks/_index.md`.

### T.3 — Track Continuation

1. When continuing an existing track: report in chat the current status, the next status, and a brief rationale for the transition. Wait for confirmation.
2. After confirmation: update `status` in frontmatter and in the track's status fields. After any status change — regenerate `tracks/_index.md` via `python scripts/vault.py tracks`.
3. If work within the track creates new artifacts (`artifacts/`) — list them in the track's "Related entities" section.
4. If a substantive step that produced a result was performed — create a WRK file per Procedure W.2 and add a line to the track's "Completed moves".
5. If a blocker is discovered during work — move the track to `blocked`, record the blocker in the track's status fields. On unblocking — restore the previous active status.

### T.4 — Inbox Processing and Tracks

When processing the inbox:
- If the material contains research or valuable artifacts → file it into the relevant existing track or create a new one (per T.1–T.2).
- If the material contains a transcript/meeting protocol → process it per the existing Procedure A, update related entities (DEC, Q, RISK, CON). If the meeting affects an existing track — update its status/blockers/next moves.

## Procedure AR — Artifact Creation

**Scope:** any artifact (`artifacts/YYYY-MM-DD-slug.md`) is created bound to a track and recorded as a WRK.

### AR.1 — Track binding and plan check

1. Determine which track the artifact being created belongs to. Find the matching track via `SocratiCode codebase_search` (semantic match by artifact topic) or `grep -l "<keyword>" project-vault/tracks/TRK-*.md`.
2. Check whether the work of creating the artifact is in this track's "Next moves":
   - **There is an explicit item** → use it as `plan_item_ref` in the future WRK.
   - **No explicit item, but the topic matches** → before creating the artifact, add an item to the track's "Next moves", announce in chat.
   - **No track fits** → create a new track (Procedure T.2) with status `cue`, then add an item to "Next moves".
3. Report in chat: "Artifact [essence] belongs to track TRK-NNNN, plan item — [N or 'new item added']. Proceeding." Wait for confirmation.

### AR.2 — Collecting relevant materials

1. Read the track's ProblemCard@Context — the core of the problem.
2. Collect all relevant materials from the track: links to DEC, Q, RISK, CON, artifacts, WRK, digests — everything related to the topic of the artifact being created.
3. If necessary — read the atomic files of related entities (DEC, CON, Q, RISK) for full context.
4. If the artifact relies on FPF patterns — load the corresponding references from fpf-core.

### AR.3 — Preparing and writing the artifact

1. Create the file `artifacts/YYYY-MM-DD-slug.md`.
2. Follow guardrail 6: the artifact must be self-contained and alienable — readable without consulting other project entities. References to DEC-NNNN, Q-NNNN, etc. are prohibited; instead of an entity code, give a brief substantive description.
3. Follow the language rule: narration in Russian, English inclusions — only proper names, technology names, and terms without a stable Russian equivalent.

### AR.4 — Recording completed work (WRK)

1. After writing the artifact — immediately create a WRK file per Procedure W.2.
2. In `plan_item_ref`, specify the item from the track's "Next moves" identified at step AR.1.
3. In `output_refs`, specify the created artifact.
4. Update the track's "Completed moves". After writing the WRK — regenerate `work/_index.md` via `python scripts/vault.py work`.
5. If the artifact closes a PlanItem — **delete** the item from the track's "Next moves" (the completed item is already recorded by the WRK in "Completed moves"). Do not strike through `~~...~~` and do not mark `[x]`. If partial — leave it with a clarification.

## Procedure W — Work Record

**Scope:** every completed substantive step within a track is recorded as an atomic file `project-vault/work/WRK-YYYY-MM-DD-hhmmss.md`. A work record is `U.Work` (A.15.1): a dated occurrence of work. The record is a separate episteme denoting the occurrence.

### W.1 — When to create a WRK

Create a WRK file when:
- A substantive step was performed within a track that produced a new result (artifact, decision, analysis, structural change to project-vault).
- The result of the step must be traceable via discovery tools (`grep`, `SocratiCode`, generated `work/_index.md`).

**Do not create** a WRK for:
- Item 0 in "Next moves" (reconnaissance, freshness check).
- Small administrative actions without substantive work.
- Fixing obvious errors (typos, formatting).

### W.2 — Creating a WRK

1. Determine `hhmmss` — the current time (the moment the step is completed).
2. Create the file `project-vault/work/WRK-YYYY-MM-DD-hhmmss.md` per template `work/_template.md`.
3. Fill in the frontmatter:
   - `id`, `completed` (completion moment, `YYYY-MM-DD hh:mm:ss`), `performer`, `performed_under` (track).
   - `plan_item_ref` — the number of the item from the track's "Next moves" that was performed (optional for the thin form).
   - `enacted_method` — the FPF pattern applied (one or more, comma-separated).
   - `input_refs` — incoming entities: preceding WRKs, DEC, artifacts, source tracks (optional for the thin form).
   - `output_refs` — created/changed entities: artifacts, decisions, tracks, risks, questions, contradictions.
   - `status`: `performed` (completed), `partial` (partial), `probe` (reconnaissance), `rework-needed`.
4. Write the body: 1–3 paragraphs describing the completed work. Do not duplicate the content of the output artifact.
5. Add a line to the track's "Completed moves": `[[WRK-YYYY-MM-DD-hhmmss]] — FPF-pattern: brief essence`.
6. **Regenerate indexes** after writing the WRK: `python scripts/vault.py all`. This updates both `work/_index.md` and `tracks/_index.md` from frontmatter. Do NOT hand-edit these files.
7. If the step closes a PlanItem — **delete** the item from the track's "Next moves" (the completed item is recorded by the WRK in "Completed moves"), renumber the remaining items if necessary. Do not strike through `~~...~~` and do not mark `[x]`. If partial — leave it with a clarification.
8. If the step created new entities (DEC, RISK, Q, CON, TRK) — no separate index update needed; `grep`/`SocratiCode` will discover them. If it created a new track, regenerate `tracks/_index.md` via `python scripts/vault.py tracks`.

### W.3 — Resuming a track

When returning to a track, the reading order is:
1. ProblemCard@Context in the track body — problem side, context, scope cut.
2. "Next moves" — the remaining PlanItems.
3. "Completed moves" — the list of WRKs. If necessary — open the atomic file for details.
4. Item 0 in "Next moves" (if present) — resumption actions.

## Procedure E — Next Meeting Agenda

Update `project-vault/agenda-next.md` using template `templates/agenda.md`: top questions, blockers, contradictions, risks; slots from `project-vault/decisions/` (close `proposed`, return `deferred` with approaching `revisit_by`).

**When blocked:**
- If `agenda-next.md` does not exist yet → create from template.
- If there are no open questions/risks/contradictions → fill only the "0–5 Goal" slot and note "agenda empty — no open items."

## Guardrails

1. Any new claim — link to source (digest, capture).
2. No basis in source — do not mark as resolved.
3. Two incompatible formulations — atomic file in `contradictions/`.
4. Do not set decision status to `accepted` without explicit wording in `sources`.
5. **Reports are off-limits without request:** do not create or update `project-vault/reports/*` without explicit request.
5a. **Agenda is off-limits without request:** do not create or update `project-vault/agenda-next.md` without explicit request. When requested, fill using Procedure E.
6. **Artifacts must be self-contained and alienable** (`artifacts/`): every artifact must be readable and understandable without consulting any other project entity. References to internal project entities (DEC-NNNN, Q-NNNN, RISK-NNNN, CON-NNNN, INV-NN, FR-XXX-NN, etc.) are **prohibited**. Instead of an entity code, always provide a brief substantive description inline.
7. **Track discipline:** a track (`tracks/TRK-NNNN.md`) must have exactly one current status. Status is stored in both frontmatter (`status:`) and the inline table. When updating a track, update both. Do not delete tracks — retired tracks stay in `tracks/` with `status: retired`. A track must have at least one blocker.
8. **Track-bound work:** any productive activity (research, analysis, synthesis) must be performed within a track (Procedure T). Before acting, announce intent in chat, get user confirmation, then proceed. Do not skip statuses — always start at `cue` and advance step by step.
9. **Work records mandatory:** every completed productive step within a track that produces a new result must be recorded as a WRK file (`project-vault/work/WRK-YYYY-MM-DD-hhmmss.md`) per Procedure W. The track's "Completed moves" list must be updated accordingly. After each WRK — regenerate indexes via `python scripts/vault.py all`.
10. **One track — one ProblemCard@Context:** ProblemCard lives in the track body. If work discovers a new independent problem signal (different EntityOfConcern, different scope cut) — create a child track with its own ProblemCard, not a second ProblemCard in the same track.
11. **File name uniqueness:** file names must not repeat across different project-vault directories. For example, if `artifacts/YYYY-MM-DD_slug.md` is created, then a `sources/digests/YYYY-MM-DD_slug.md` with the same name must not be created — the digest or artifact gets a distinguishing name (via a different slug). The rule eliminates collisions in references (Obsidian, grep) and eases navigation. The only exceptions are the auto-generated `work/_index.md` and `tracks/_index.md` files.
12. **No orphan research materials (two-way binding of external research):** every external research digest must be bound two-way — its signals recorded in the files of the corresponding entities (Q, RISK, CON, DEC — any that accept `sources`/`source` or "Related entities"), and the digest added to "Related entities"/`sources` of at least one entity. If the material is outside the scope of all entities — explicitly mark "not bound — outside the project scope" in the digest. A one-way "Reconciliation" only in the digest counts as an incomplete processing.
13. **Decision-record discipline (DEC):**
    - **Change = revise, don't duplicate.** If a decision changes, revise the existing card: new state in «Решение», chronicle in «История пересмотров». Do not create a new card for the same decision.
    - **Supersession is two-way.** The superseding card fills `supersedes`; the absorbed card gets `status: superseded` and a `superseded_by` pointing to the successor.
    - **One topic — one card.** «Одна тема» = one bounded decision (E.9 DRR: «one bounded content decision»): one decision question → one selected answer → one scope → one revisit condition. Several decisions in one card are allowed only when they form one mutually dependent change set (E.9: «one mutually dependent change set» — they cannot be accepted/reverted separately). Different independent topics — different cards; do not merge unrelated topics just to reduce count.
    - **Consolidation only via revision/absorption.** Absorbed cards stay as `superseded` (history preserved), never deleted.
    - When contradictions/questions close — set `status` in frontmatter (no archive); they stay in place.
14. **DEC body text — only DEC- IDs allowed, other entity IDs not.** A DEC card's body may reference other decisions (DEC-) by their ID. It must NOT reference other vault entities (RISK-, Q-, CON-, TASK-, TRK-) by their ID — put them in the frontmatter `references` field instead; in the body write the essence (substantive description). Only web links (URLs) may appear in the body. When removing a non-DEC ID leaves a dangling fragment (e.g. `(поручение в )`, `(см. )`, `(закрытие )`), remove the whole parenthetical, not just the ID.
15. **DEC entry gate (не засоряй канон «мусорными» решениями):** перед созданием DEC применяй входной фильтр — это архитектурное решение? У него есть ограниченный архитектурный вопрос, выбранный ответ с последствием для системы и условие пересмотра (C.32.ADR: problem frame → decision outcome → consequences → confirmation/supersession)? Если это редакционное решение по содержанию рабочего документа, пересказ уже зафиксированной позиции, административная деталь или резюме без выбора — не создавай DEC, зафиксируй фактом/сигналом в дайджесте и пропиши двусторонний сигнал в соответствующую сущность. (Ср. E.9 «Cheap stop»: editorial cleanup без изменения семантики/обязательств/границ не открывает DRR.)

## After Changes

Briefly list modified and created files.

## Evolution

If the user is dissatisfied with a result or clarifies the process, offer to update this skill. When updating:
- If the trigger is wrong → fix the `description` in frontmatter.
- If a procedure is incomplete → add steps or failure paths in the relevant Procedure section.
- If a template is missing fields → update the template file in `templates/`.
- If the vault schema changed → update `references/architecture.md`.