git:20260831.2d58ef8 to git:20260903.5031364

+ ---

+ 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`.