chore(release): 0.1.0

chore: configure releases and develop workflow
docs: simplify system documentation
2026-09-14 07:12:03 +03:00 · 2026-09-14 07:10:19 +03:00 · 2026-09-14 05:51:29 +03:00 · 2026-09-13 17:08:11 +00:00 · 2026-09-13 19:58:30 +03:00
41 changed files with 4076 additions and 2452 deletions
@@ -0,0 +1,6 @@
+{
+  "main": "2567a755569e6ef6ba12063b62f202fe52884ce7",
+  "frontend": "0244acf429c525b23117f165bbe52ef5403eefd3",
+  "backend": "660b250ecd05e38784690b9a9adb381764c0ca7c",
+  "specs": "9e227a563dda67620f0ad78228aa8a4c18bf35a0"
+}
@@ -0,0 +1,26 @@
+name: Conventional commits
+
+on:
+  pull_request:
+    types: [opened, synchronize, reopened, edited]
+
+jobs:
+  commits:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: https://github.com/actions/checkout@v4
+        with:
+          ref: ${{ github.event.pull_request.head.sha }}
+          fetch-depth: 0
+      - uses: https://github.com/actions/setup-node@v4
+        with:
+          node-version-file: .nvmrc
+      - run: npm ci --ignore-scripts
+      - name: Check PR title and commits
+        env:
+          PR_TITLE: ${{ github.event.pull_request.title }}
+          BASE_SHA: ${{ github.event.pull_request.base.sha }}
+          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
+        run: |
+          printf '%s\n' "$PR_TITLE" | npm run commitlint -- --strict
+          npm run commitlint -- --strict --from "$BASE_SHA" --to "$HEAD_SHA"
@@ -0,0 +1,31 @@
+name: Docs security
+
+on:
+  push:
+    branches:
+      - '**'
+  pull_request:
+  schedule:
+    - cron: '17 5 * * *'
+
+jobs:
+  security:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: https://github.com/actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - name: Record checked revision
+        run: git rev-parse HEAD
+      - name: Scan history with Gitleaks 8.30.1
+        run: |
+          curl --fail --location --silent --show-error https://github.com/gitleaks/gitleaks/releases/download/v8.30.1/gitleaks_8.30.1_linux_x64.tar.gz -o /tmp/gitleaks.tar.gz
+          echo '551f6fc83ea457d62a0d98237cbad105af8d557003051f41f3e7ca7b3f2470eb  /tmp/gitleaks.tar.gz' | sha256sum --check
+          mkdir -p /tmp/gitleaks-bin
+          tar -xzf /tmp/gitleaks.tar.gz -C /tmp/gitleaks-bin gitleaks
+          /tmp/gitleaks-bin/gitleaks git --log-opts=--all --redact=100 --no-banner
+      - uses: https://github.com/actions/setup-node@v4
+        with:
+          node-version-file: .nvmrc
+      - name: Audit runtime and development dependencies
+        run: npm audit --include=dev --audit-level=low
@@ -0,0 +1,46 @@
+name: Docs verify
+
+on:
+  push:
+    branches: ['**']
+  pull_request:
+
+jobs:
+  verify:
+    runs-on: ubuntu-latest
+    defaults:
+      run:
+        working-directory: workspace/docs
+    steps:
+      - uses: https://github.com/actions/checkout@v4
+        with:
+          path: workspace/docs
+      - name: Checkout compatible peer revisions
+        env:
+          SOURCE_BRANCH: ${{ github.head_ref || github.ref_name }}
+          TARGET_BRANCH: ${{ github.base_ref || github.ref_name }}
+        run: |
+          set -eu
+          for repo in main frontend backend specs; do
+            ref=develop
+            case "$SOURCE_BRANCH:$TARGET_BRANCH" in
+              release/*:*|*:main)
+                ref=$(jq -er --arg repo "$repo" '.[$repo]' .ci/refs.json)
+                printf '%s\n' "$ref" | grep -Eq '^[0-9a-f]{40}$'
+                ;;
+            esac
+            target="../$repo"
+            if [ "$repo" = main ]; then target=..; fi
+            git init "$target"
+            git -C "$target" remote add origin "https://git.personal.ksv741.ru/WealthLedger/$repo.git"
+            git -C "$target" fetch --depth 1 origin "$ref"
+            git -C "$target" checkout --detach FETCH_HEAD
+            git -C "$target" rev-parse HEAD
+          done
+          git rev-parse HEAD
+      - uses: https://github.com/actions/setup-node@v4
+        with:
+          node-version-file: workspace/docs/.nvmrc
+      - run: npm ci
+      - name: Check Markdown and relative links
+        run: npm run verify
@@ -2,12 +2,19 @@
  "config": {
    "MD013": false
  },
-  "customRules": ["markdownlint-rule-relative-links"],
+  "customRules": [
+    "markdownlint-rule-relative-links"
+  ],
  "overrides": [
    {
-      // Historical evidence records keep original source paths, outside the standalone book.
-      "filter": ["development/completion-evidence.md", "development/audit-remediation.md"],
-      "config": { "relative-links": false },
+      "filter": [
+        "CHANGELOG.md"
+      ],
+      "config": {
+        "MD024": {
+          "siblings_only": true
+        }
+      },
      "combine": "merge"
    }
  ]
@@ -0,0 +1,106 @@
+{
+  "git": {
+    "requireBranch": "release/*",
+    "requireCleanWorkingDir": true,
+    "requireUpstream": false,
+    "requireCommits": true,
+    "commitMessage": "chore(release): ${version}",
+    "tagName": "v${version}",
+    "tag": false,
+    "push": false
+  },
+  "npm": {
+    "publish": false
+  },
+  "github": {
+    "release": false
+  },
+  "gitlab": {
+    "release": false
+  },
+  "hooks": {
+    "after:git:init": "node scripts/check-release.cjs"
+  },
+  "plugins": {
+    "@release-it/conventional-changelog": {
+      "infile": "CHANGELOG.md",
+      "preset": {
+        "name": "conventionalcommits",
+        "types": [
+          {
+            "type": "chore",
+            "scope": "release",
+            "effect": "hidden"
+          },
+          {
+            "type": "feat",
+            "section": "Features",
+            "effect": "bump"
+          },
+          {
+            "type": "fix",
+            "section": "Bug Fixes",
+            "effect": "bump"
+          },
+          {
+            "type": "perf",
+            "section": "Performance",
+            "effect": "bump"
+          },
+          {
+            "type": "docs",
+            "section": "Documentation",
+            "effect": "bump"
+          },
+          {
+            "type": "spec",
+            "section": "Specifications",
+            "effect": "bump"
+          },
+          {
+            "type": "refactor",
+            "section": "Refactoring",
+            "effect": "bump"
+          },
+          {
+            "type": "build",
+            "section": "Build",
+            "effect": "bump"
+          },
+          {
+            "type": "ci",
+            "section": "CI",
+            "effect": "bump"
+          },
+          {
+            "type": "test",
+            "section": "Tests",
+            "effect": "bump"
+          },
+          {
+            "type": "style",
+            "section": "Styles",
+            "effect": "bump"
+          },
+          {
+            "type": "chore",
+            "section": "Maintenance",
+            "effect": "bump"
+          },
+          {
+            "type": "revert",
+            "section": "Reverts",
+            "effect": "bump"
+          }
+        ]
+      },
+      "context": {
+        "host": "https://git.personal.ksv741.ru",
+        "owner": "WealthLedger",
+        "repository": "docs",
+        "linkReferences": true,
+        "commit": "commit"
+      }
+    }
+  }
+}
@@ -7,7 +7,7 @@
 Проверь существенные факты адресно по спецификациям, ADR и реализации с учётом
 веток и незакоммиченных изменений. Расхождение обозначь, не выбирая источник
 победителем автоматически. Перенос сохраняет полезное содержание и входящие
-ссылки; существующие исторические свидетельства остаются неизменными.
+ссылки. Docs описывает текущее устройство системы; история поставок остаётся в Git.
 Отчёты аудитов и исследований в docs не размещаются. Подтверждённые решения
 из исследований оформляются в ADR, системные знания — в тематических страницах.

@@ -15,3 +15,10 @@
 [доступные проверки](CONTRIBUTING.md#проверки), включая новые файлы.
 Сохрани границы задачи и чужие изменения. Успех Markdown-проверки не заменяет
 смысловую сверку и не доказывает рендер диаграмм.
+
+## Ветки и релизы
+
+Работа — в отдельной ветке от `develop`, затем PR в `develop`; в `main` напрямую
+не пушить. Release/hotfix и синхронизация веток — по [root README](../README.md#релизы-и-ветки).
+Commits и заголовки PR — Conventional Commits; для спецификаций допустим `spec:`.
+Перед подготовкой релиза прочитай root README; версии вручную не повышать.
@@ -0,0 +1,123 @@
+# Changelog
+
+## 0.1.0 (2026-09-14)
+
+### Features
+
+* add authorization ([6ca175b](https://git.personal.ksv741.ru/WealthLedger/docs/commit/6ca175b541a9f03e08448bef7593e560e928a15c))
+* add brocker account list ([ebf34e0](https://git.personal.ksv741.ru/WealthLedger/docs/commit/ebf34e01ca8c8dab533bb76aff3d5b03177383f8))
+* add logging ([016b624](https://git.personal.ksv741.ru/WealthLedger/docs/commit/016b624185d24a4e5ff07d4d164f2a3942b12358))
+* add operations list ([d825126](https://git.personal.ksv741.ru/WealthLedger/docs/commit/d8251269207b6f163889f04637862d9126cd89ca))
+* add portfolio ([4ffc374](https://git.personal.ksv741.ru/WealthLedger/docs/commit/4ffc374bd8ae4cca5a05ac806bf8d9a423d1153f))
+* add tbank tokens ([026b531](https://git.personal.ksv741.ru/WealthLedger/docs/commit/026b5318af0d1d2b8e4622fc82cc454c23222bd8))
+* add агегку events ([c513c47](https://git.personal.ksv741.ru/WealthLedger/docs/commit/c513c478404c6d00475ad093f70fce54aa30d1c2))
+
+### Documentation
+
+* activate frontend quality guardrails remediation ([fa5db07](https://git.personal.ksv741.ru/WealthLedger/docs/commit/fa5db0722915dd21fff49dbf49b8ddfc42eb4733))
+* activate token-efficient agent workflow ([42fd894](https://git.personal.ksv741.ru/WealthLedger/docs/commit/42fd8940dcd2fcfba5ed7f34d6265f289b049659))
+* add account income analytics ([cc3b5b0](https://git.personal.ksv741.ru/WealthLedger/docs/commit/cc3b5b0ae5b0e9507e2267c47fb55ea969f2765b))
+* add audit remediation registry ([793d201](https://git.personal.ksv741.ru/WealthLedger/docs/commit/793d2012a39e0b204d1dc768c386e60cb987b05a))
+* add baseline design ([e610c83](https://git.personal.ksv741.ru/WealthLedger/docs/commit/e610c83366045e5e8dab71ea5edbe7796bb78364))
+* add completion evidence for extend-instrument-logo-to-bonds ([c68c978](https://git.personal.ksv741.ru/WealthLedger/docs/commit/c68c978c91d3fc821b8a31a9e52c7406a7121bb6))
+* add old audit file ([5bf5c4e](https://git.personal.ksv741.ru/WealthLedger/docs/commit/5bf5c4e774f3dae8610a8ea9cba1204b1f3532ae))
+* **ai:** adopt task-driven scoped context ([b7a56b1](https://git.personal.ksv741.ru/WealthLedger/docs/commit/b7a56b1eb53bae0a00e18be4ed4209df70fc193b))
+* align investment domain terminology ([68d975b](https://git.personal.ksv741.ru/WealthLedger/docs/commit/68d975befda90c198a0287bb8d43ac5d6e386eb5))
+* **brokerage-account-ledger:** describe explicit filters ([820cf55](https://git.personal.ksv741.ru/WealthLedger/docs/commit/820cf5510318e0868eba46a6ff0b556053cb9806))
+* **brokerage-account-ledger:** describe operation type label and no category duplication ([2abb591](https://git.personal.ksv741.ru/WealthLedger/docs/commit/2abb5912b2db23d4984ca3b99578310596d66555))
+* **cards:** describe compact expense summaries ([d3a9e91](https://git.personal.ksv741.ru/WealthLedger/docs/commit/d3a9e91d475414f92b01f53848b58bd20263a56b))
+* **cards:** describe date range filtering ([a86d1eb](https://git.personal.ksv741.ru/WealthLedger/docs/commit/a86d1eb0a3d34992e650075c9f94cec1bda252e8))
+* clarify domain and agent authority ([0c53c50](https://git.personal.ksv741.ru/WealthLedger/docs/commit/0c53c50c624c9ab8d9c812c60a7cab56661fcbbd))
+* close SQLite migration and e2e blocker ([c74c573](https://git.personal.ksv741.ru/WealthLedger/docs/commit/c74c57373329e4accc46dbc13fdbe57ebf7ea3fd))
+* describe all-accounts behavior ([0e8c8c8](https://git.personal.ksv741.ru/WealthLedger/docs/commit/0e8c8c803f8ce8b49cdb7cbf2d5d1b0018736ee9))
+* describe bank operation icons and date format ([1f65b91](https://git.personal.ksv741.ru/WealthLedger/docs/commit/1f65b91a16a3ab90de17a493d011a8cf3fdc3c1c))
+* describe bond pages and rating sources ([35711a5](https://git.personal.ksv741.ru/WealthLedger/docs/commit/35711a52ec79d05887b39adb5a64b52578b4da21))
+* describe brokerage account summaries ([76d4de4](https://git.personal.ksv741.ru/WealthLedger/docs/commit/76d4de4428e5f902d82782ade745487d015994a1))
+* describe compact portfolio totals ([2985def](https://git.personal.ksv741.ru/WealthLedger/docs/commit/2985def574f1c22f9c41f6755b802342fafb30cd))
+* describe direct local token adaptation ([b0e747f](https://git.personal.ksv741.ru/WealthLedger/docs/commit/b0e747fdee2f726f18a4222f4bfc249c8f6d845b))
+* describe improved ledger event rows ([d39a9d3](https://git.personal.ksv741.ru/WealthLedger/docs/commit/d39a9d3df08d068b0c5fba97cfb7bb0d5755f329))
+* describe manual bank card accounting ([c0dfb80](https://git.personal.ksv741.ru/WealthLedger/docs/commit/c0dfb8061721bfd48d16e2a978348be4bec38c50))
+* describe polished stock cards ([0c59ce7](https://git.personal.ksv741.ru/WealthLedger/docs/commit/0c59ce788690ba6d17f33e0b57e122dd67e74904))
+* describe portable design token contract ([436251e](https://git.personal.ksv741.ru/WealthLedger/docs/commit/436251e83e07fe9726a1576dd081d5bd41655ff9))
+* describe shared design system and catalog blocks ([30683b8](https://git.personal.ksv741.ru/WealthLedger/docs/commit/30683b8b73cdad838feac6c1cac255aea3783ae4))
+* describe simplified income page ([7166ee5](https://git.personal.ksv741.ru/WealthLedger/docs/commit/7166ee51d181b04f3892ff6757a56b578ee9df64))
+* describe stock pages and portfolio navigation ([ead965a](https://git.personal.ksv741.ru/WealthLedger/docs/commit/ead965a67402789245c267a4c32b52176d3df7a2))
+* describe year-over-year income comparison ([2c98989](https://git.personal.ksv741.ru/WealthLedger/docs/commit/2c98989f5eeafd9baca8dab2659619473b78702d))
+* document auth and client refresh resilience ([b91280c](https://git.personal.ksv741.ru/WealthLedger/docs/commit/b91280cbaace4d0ed6d66186c62465abeeda6032))
+* document frontend audit remediation delivery ([55d35c7](https://git.personal.ksv741.ru/WealthLedger/docs/commit/55d35c7f789478230c683a79e5c80563c75487b6))
+* document instrument logos in portfolio ([30e5699](https://git.personal.ksv741.ru/WealthLedger/docs/commit/30e56997f9bbceee09ea87b218a6042ab17112f0))
+* document local verification workflow ([293df9c](https://git.personal.ksv741.ru/WealthLedger/docs/commit/293df9c59dfb8788e2c7e044c8855146b3c5d03e))
+* document OpenSpec authority lifecycle ([0bc8d1c](https://git.personal.ksv741.ru/WealthLedger/docs/commit/0bc8d1c9aed984cc16b6efd1dab76e2a7a9ca307))
+* document skeleton loading states ([95fa815](https://git.personal.ksv741.ru/WealthLedger/docs/commit/95fa8153286d549f7a58229bd92ef327b75b7e58))
+* document T-Bank cache generation boundary ([3d2bc1e](https://git.personal.ksv741.ru/WealthLedger/docs/commit/3d2bc1eac4add7cc3316c97d4d02a78fe91620d5))
+* establish architecture records ([2a09ef7](https://git.personal.ksv741.ru/WealthLedger/docs/commit/2a09ef74bb25feca65efdace61c2686199f614a5))
+* **events:** describe date range filtering ([aa9afc1](https://git.personal.ksv741.ru/WealthLedger/docs/commit/aa9afc15e46888c4d6cabbe8e17ff87e383f5731))
+* explain server-side portfolio metadata recovery ([05bfe8d](https://git.personal.ksv741.ru/WealthLedger/docs/commit/05bfe8df1cb0fde9b97d2075d9f571198295fea1))
+* link remediation evidence commit ([9752234](https://git.personal.ksv741.ru/WealthLedger/docs/commit/9752234f23c8dd400667ba354b0ed1eec248db99))
+* make project documentation self-contained ([3a99af1](https://git.personal.ksv741.ru/WealthLedger/docs/commit/3a99af1a6e49836ae6ea2378dd2e4037092d08fc))
+* mark frontend audit remediation active ([ba15e52](https://git.personal.ksv741.ru/WealthLedger/docs/commit/ba15e529b44b39f819c3666ad4787f2f566d1da4))
+* **portfolio-view:** update as-built for bond parity ([2e9e403](https://git.personal.ksv741.ru/WealthLedger/docs/commit/2e9e403db207c5fc4a21827b118407a51c7a70cc))
+* **portfolio:** describe asset allocation ([174bab3](https://git.personal.ksv741.ru/WealthLedger/docs/commit/174bab3566be2d302b51a8a86e10b11271f9835f))
+* **portfolio:** document ticker display ([7f4d0b2](https://git.personal.ksv741.ru/WealthLedger/docs/commit/7f4d0b255eb4ef5a73139bfd499eb88118105a6d))
+* publish token workflow pilot result ([21ccad3](https://git.personal.ksv741.ru/WealthLedger/docs/commit/21ccad3639714bcc364af329ea884eda57259aab))
+* record account-ledger-explicit-filters evidence ([2bc56db](https://git.personal.ksv741.ru/WealthLedger/docs/commit/2bc56db68076b243dccaa36ef850e4b28823e2fc))
+* record add-instrument-logos completion evidence ([d2a98f3](https://git.personal.ksv741.ru/WealthLedger/docs/commit/d2a98f31577cdd0730efa6fad73e132572e017f2))
+* record AI governance audit ([1944f2f](https://git.personal.ksv741.ru/WealthLedger/docs/commit/1944f2fc970db2bdc292981e01b1aca549f9ac52))
+* record api contract resilience remediation ([b623805](https://git.personal.ksv741.ru/WealthLedger/docs/commit/b623805cbe9cd8c57cfc83a35b6c8af3018fea1e))
+* record auth and cache concurrency policy ([8568e7b](https://git.personal.ksv741.ru/WealthLedger/docs/commit/8568e7b317a3c96c1e4ca2cbabce41d57a11181e))
+* record auth cache remediation evidence ([6c37e58](https://git.personal.ksv741.ru/WealthLedger/docs/commit/6c37e58fbe670ef79ec774280171bc8b28d88737))
+* record backend refactor and close P1-12 ([b940d39](https://git.personal.ksv741.ru/WealthLedger/docs/commit/b940d39946baae78ab14a10b9f71ef15153e9604))
+* record backend strict typing completion ([f4cefd5](https://git.personal.ksv741.ru/WealthLedger/docs/commit/f4cefd5c401d009e1d3332e76f30913c97a480b7))
+* record dependency hygiene remediation evidence ([60a1c33](https://git.personal.ksv741.ru/WealthLedger/docs/commit/60a1c33003bd35f7ff71e8c4b8f30d6a6f511e12))
+* record documentation remediation evidence ([b91dfe6](https://git.personal.ksv741.ru/WealthLedger/docs/commit/b91dfe66e0d8c55c9000687895dfc2954f4d1c44))
+* record domain money contract evidence ([4dbff85](https://git.personal.ksv741.ru/WealthLedger/docs/commit/4dbff85654656473dfa0b68f69b7841ac27d8efe))
+* record frontend audit remediation evidence ([8721e93](https://git.personal.ksv741.ru/WealthLedger/docs/commit/8721e93849f72413ca065f9e738948f0ca10132e))
+* record frontend auth query gating evidence ([68f1d8f](https://git.personal.ksv741.ru/WealthLedger/docs/commit/68f1d8f398e6606fb2a0db694c452ba235a29434))
+* record frontend quality guardrails evidence ([eb69300](https://git.personal.ksv741.ru/WealthLedger/docs/commit/eb69300ebed41bc19e78909195387dce4e2c0ec7))
+* record frontend remediation completion ([4cc8565](https://git.personal.ksv741.ru/WealthLedger/docs/commit/4cc856552498821f0dbaaa192b0fcc9a45d7b097))
+* record frontend remediation evidence ([ef2bf97](https://git.personal.ksv741.ru/WealthLedger/docs/commit/ef2bf977bf6fd55580c878b0b3aec3e37a3d944e))
+* record frontend view model boundary evidence ([373c18a](https://git.personal.ksv741.ru/WealthLedger/docs/commit/373c18a2f170f6ae2df1bda0b294b37e4c31d18f))
+* record governance completion evidence ([1a214dd](https://git.personal.ksv741.ru/WealthLedger/docs/commit/1a214dd7649cc34ff86ec1483e68d099b69ff2e7))
+* record improved ledger row evidence ([35c5302](https://git.personal.ksv741.ru/WealthLedger/docs/commit/35c5302e78545170ded1f9aa9109e3faa0ebea2a))
+* record income analytics completion evidence ([09f5f9e](https://git.personal.ksv741.ru/WealthLedger/docs/commit/09f5f9e4f9ac8709e1fa66b24e485deecf5f0655))
+* record ledger entry type label evidence ([d749bf5](https://git.personal.ksv741.ru/WealthLedger/docs/commit/d749bf5b2829b3127d6b8f6129edd262db37348f))
+* record local verification remediation evidence ([82159e3](https://git.personal.ksv741.ru/WealthLedger/docs/commit/82159e3b073ff0b4b5a0ceb5033a623b9d39f2e2))
+* record Mantine breadcrumbs evidence ([5fd5e79](https://git.personal.ksv741.ru/WealthLedger/docs/commit/5fd5e79590986ecc9787fd26b548ec8bd5b08fc3))
+* record OpenSpec lifecycle remediation ([9bb76e3](https://git.personal.ksv741.ru/WealthLedger/docs/commit/9bb76e35f9496e9414b678d325f6995bf413f144))
+* record OpenSpec resilience evidence ([79727de](https://git.personal.ksv741.ru/WealthLedger/docs/commit/79727de9ffe61f36fbaca866e2993bde6243eace))
+* record P1-11 SQLite verification ([66721ee](https://git.personal.ksv741.ru/WealthLedger/docs/commit/66721eee6295f1c432aaeb8631cfd3b0234d11d6))
+* record React component style evidence ([6812fde](https://git.personal.ksv741.ru/WealthLedger/docs/commit/6812fdeae36faf93e682d1ec089bd2e839ea6fdc))
+* record SDD audit remediation ([72c3a8a](https://git.personal.ksv741.ru/WealthLedger/docs/commit/72c3a8a6683b95f7e734044fdabe568668097c33))
+* record SDD remediation evidence ([5233726](https://git.personal.ksv741.ru/WealthLedger/docs/commit/5233726855b9f3a8f1b8e0f64991e17f9e8be299))
+* record second OpenSpec schema review ([d80e2e3](https://git.personal.ksv741.ru/WealthLedger/docs/commit/d80e2e32b2ebadcd93a53105e1ac337fe2c1f4f6))
+* record session workflow evidence ([9f8280c](https://git.personal.ksv741.ru/WealthLedger/docs/commit/9f8280c567e6e3e659c899980e916805cdf46968))
+* record stock card polish evidence ([6006400](https://git.personal.ksv741.ru/WealthLedger/docs/commit/60064003ede0afb99c1fa299b813c0be5f889ad7))
+* record T-Bank cache boundary evidence ([598dfb2](https://git.personal.ksv741.ru/WealthLedger/docs/commit/598dfb2bdb2c0d5da41495f01edbea83f6e5c0d3))
+* record verification simplification evidence ([1f030af](https://git.personal.ksv741.ru/WealthLedger/docs/commit/1f030af2df32cb392e272ce90f6fb0138a9d13b4))
+* refresh project onboarding entrypoints ([88c0cd3](https://git.personal.ksv741.ru/WealthLedger/docs/commit/88c0cd3281f1b409779f0ec9365692291c651ffa))
+* remove misplaced baseline design ([34577dc](https://git.personal.ksv741.ru/WealthLedger/docs/commit/34577dc7956f90f73c50ba067ff8ecc7e751853c))
+* remove useless ([adc369b](https://git.personal.ksv741.ru/WealthLedger/docs/commit/adc369be79d1b4b4aad36168a8d32deab6568932))
+* reorganize system knowledge by domain ([f20c3f4](https://git.personal.ksv741.ru/WealthLedger/docs/commit/f20c3f47bcacc4e65444c602c261c80691cab66f))
+* simplify OpenSpec agent entrypoints ([eb0a96e](https://git.personal.ksv741.ru/WealthLedger/docs/commit/eb0a96e27c072e53f5c01db5a810502c104e8e6c))
+* simplify system documentation ([9b19a5c](https://git.personal.ksv741.ru/WealthLedger/docs/commit/9b19a5cf4df5116c5f603f7189751d37ae9f0ffd))
+* simplify verification workflow ([4af0a9c](https://git.personal.ksv741.ru/WealthLedger/docs/commit/4af0a9c05590d7d47135fc708719bf83d5dd3fb9))
+* trust supplied OpenAPI snapshot ([2ef3759](https://git.personal.ksv741.ru/WealthLedger/docs/commit/2ef375919b84d9367791e9b22d761e506a5da930))
+* update income analytics period constraints ([28a01a4](https://git.personal.ksv741.ru/WealthLedger/docs/commit/28a01a449acd907a93b6f45c86cd40543237395b))
+* update portfolio view feature ([c628535](https://git.personal.ksv741.ru/WealthLedger/docs/commit/c6285352b11907b3542ba8fc502608828a834fa3))
+
+### Refactoring
+
+* little structure refactor ([1383949](https://git.personal.ksv741.ru/WealthLedger/docs/commit/1383949dc4c295d1b4e89abc372b780442ad91b7))
+* refactor foundation ([5d5497a](https://git.personal.ksv741.ru/WealthLedger/docs/commit/5d5497a4e4fc52cd03326080ba082c6dec369ce5))
+* refactor future event list ([680fc03](https://git.personal.ksv741.ru/WealthLedger/docs/commit/680fc03bec7ff5fdbac7c81c6daf8e5dc119abb5))
+
+### CI
+
+* verify docs and secure dependency updates [#1](https://git.personal.ksv741.ru/WealthLedger/docs/issues/1) [#5](https://git.personal.ksv741.ru/WealthLedger/docs/issues/5) [#6](https://git.personal.ksv741.ru/WealthLedger/docs/issues/6) ([c0a8cdb](https://git.personal.ksv741.ru/WealthLedger/docs/commit/c0a8cdb683953e515757071c288bfdf9e7b4b40a))
+
+### Maintenance
+
+* configure releases and develop workflow ([261f1ca](https://git.personal.ksv741.ru/WealthLedger/docs/commit/261f1ca6d15a894de470b94f2f0ad6fce3ae7917))
+* **deps:** update node.js to v24.21.0 ([67f152d](https://git.personal.ksv741.ru/WealthLedger/docs/commit/67f152d3654b15c8d51b5bde95ac4e9e0e6fb253))
+* document and adopt Node 24 LTS ([7bc8792](https://git.personal.ksv741.ru/WealthLedger/docs/commit/7bc8792b9853768734066c31a323b70886d73a23))
+* save pending changes ([14dd879](https://git.personal.ksv741.ru/WealthLedger/docs/commit/14dd8790996b3461da8b1e3ec9a49d9526100047))
@@ -16,10 +16,14 @@ Docs даёт самостоятельное понимание продукта
 | Размещение кода, conventions, команды разработки и проверки | Локальные инструкции frontend/backend |
 | Выбор репозитория и типа знания | Корневой [AGENTS](../AGENTS.md) |

+История аудитов и проверок остаётся в Git, Issues и PR. `CHANGELOG.md`
+генерируется release-it из commits; вручную дублировать его на тематических страницах не нужно.
+Процесс разработки и инструкции агентов принадлежат локальным инструкциям
+репозиториев. ADR фиксируют решения самой системы, а не организацию работы.
+
 Основные спецификации описывают и согласованное текущее поведение.
 Различие specs и docs не является разделением на будущее и настоящее.
 Docs объясняет смысл контракта, не вводя независимо редактируемые требования.
-OpenSpec применяется по явному запросу согласно [принятому процессу](development/openspec-authority-and-lifecycle.md).

 ## Потребность читателя и структура

@@ -152,8 +156,6 @@ npm run verify
 При изменениях соседних репозиториев выполни там `git diff --check` и проверь
 затронутые ссылки. Markdown-only правки не требуют тестов всего приложения.

-Точный scope исключений задан существующими `package.json` и конфигурацией lint:
-исторические свидетельства не обязаны разрешать прежние адреса.
 Правило relative-links не проверяет внешние URL и HTML-ссылки. Mermaid-рендер
 в gate не входит; используй доступный локальный рендерер без отправки материалов
 наружу, установки стека или добавления новых валидаторов. Публикационного
@@ -163,3 +165,26 @@ npm run verify
 разработчик от вопроса к объяснению и требованию; агент от типа задачи к нужным
 ограничениям, ADR и репозиторию. Отчёт различает синтаксис, ссылки, рендер,
 смысловую сверку и оставшиеся ограничения.
+
+### CI и обновления зависимостей
+
+`.gitea/workflows/verify.yml` запускает этот gate на push и PR с Node
+из `.nvmrc` и установкой через `npm ci`. Checkout docs размещается внутри
+workspace из `WealthLedger/main`, рядом с frontend, backend и specs. Соседние
+репозитории для разработки берутся из `develop`; для `main`, PR в `main`
+и `release/*` — из полных SHA в `.ci/refs.json`. SHA всех пяти участников
+сохраняются в логе.
+Ошибка checkout, Markdown или относительной ссылки завершает job с FAIL.
+Это проверка ссылок на выбранные revisions, без Mermaid-render и semantic review.
+
+`security.yml` при push, PR и ежедневно проверяет всю Git-историю через
+Gitleaks 8.30.1 с redacted-выводом и все npm dependencies через
+`npm audit --include=dev --audit-level=low`. Override `smol-toml` исправляет
+DoS в TOML parser markdownlint-cli2; его можно удалить, когда родительский
+пакет примет исправленную версию.
+
+Renovate объединяет minor/patch updates; major требует согласования в
+Dependency Dashboard, automerge не включён. Required checks включаются
+отдельно в Gitea; workflow сам по себе не запрещает merge.
+
+Версии и ветки: [процесс релиза](../README.md#релизы-и-ветки).
@@ -44,15 +44,9 @@ WealthLedger помогает частному инвестору понимат
 | Разобраться в системе | [Архитектура](architecture/README.md), нужная область выше, [внешние интеграции](integrations/README.md) |
 | Найти точные сведения | [Глоссарий](glossary.md), [показатели портфеля](domains/portfolio/data-reference.md), [HTTP API](architecture/http-api.md) |
 | Разобрать расхождение в суммах | [Диагностика портфеля](domains/portfolio/how-to/investigate-discrepancy.md) |
-| Проверить условия локальной работы | [Окружение и восстановление](development/local-workspace.md) |
 | Понять ошибку или старые данные | [Состояния интерфейса](architecture/cross-cutting/ui-resilience.md), [свежесть данных](architecture/cross-cutting/data-freshness.md) |
-| Найти визуальные роли и примеры | [Дизайн-система](development/design-system.md), [UI-каталог](development/ui-catalog.md) |
+| Понять визуальные роли и состояния | [Визуальные принципы](design/overview.md) |
 | Узнать причину архитектурного решения | [Журнал ADR](adr/README.md) |
-| Изменить или проверить систему | [Сопровождение](development/README.md), затем инструкции нужного репозитория |
-
-Практический tutorial первого инвестиционного сценария пока не подготовлен:
-он требует подключения брокера. Маршрут первого знакомства выше — чтение, не учебный запуск.
-UI-каталог содержит безопасные вымышленные примеры и поясняет границы их использования.

 ## Границы знаний

@@ -68,8 +62,8 @@ UI-каталог содержит безопасные вымышленные
 реализованную функцию; расхождение кода и требования требует разбора.
 Итоги исследований входят в ADR, когда принято значимое решение, и в тематические
 страницы, когда уточняют знания о системе. Исходные исследовательские отчёты
-в docs не хранятся. [Исторические свидетельства](development/README.md#исторические-свидетельства)
-сохраняют результаты своего времени и не заменяют текущее описание системы.
+в docs не хранятся. История изменений остаётся в Git; документация описывает
+текущее устройство системы и причины архитектурных решений.

 Правила изменения текста, диаграмм, ссылок и проверки docs-impact находятся
 в [CONTRIBUTING](CONTRIBUTING.md).
@@ -1,55 +0,0 @@
---
-status: accepted
---
-
-# Native OpenSpec SDD и минимальная local orchestration
-
-## Статус: историческое решение
-
-[ADR 012](012-task-driven-development-with-scoped-context.md) отменяет обязательный
-SDD lifecycle. Native OpenSpec остаётся optional инструментом; repo gates сохраняются.
-
-### Прежняя частичная замена
-
-[ADR 011](011-native-openspec-lifecycle-with-repository-gates.md) заменяет части
-этого решения о schema v3, custom verifiers и dispatcher. Выбор native OpenSpec,
-независимых repository gates и исходное rationale сохраняются. Ниже оставлено
-историческое описание прежней реализации; текущие принципы работы описаны
-в ADR 012. Version contract этим уточнением не меняется.
-
-## Исторический контекст и решение
-
-На момент решения WealthLedger использовал проектную schema `wealth-ledger-sdd` version 3 с
-последовательностью `Proposal → Delta Specs → Design → Tasks → Apply`, один exact
-OpenSpec CLI contract и проверки без изменения проверяемых материалов. Это
-сохраняло единый источник правил жизненного цикла в хранилище спецификаций, выражало approval
-boundaries нативными extension points и не вводит второй workflow engine или
-monorepo control plane для четырёх независимых Git-репозиториев.
-
-## Рассмотренные варианты
-
- Встроенная `spec-driven` schema отклонена: она не выражает обязательный переход Specs перед Design и не задаёт Delivery Map или проектные роли артефактов.
- Отдельный workflow engine или custom generator отклонён: он создал бы конкурирующий формат и lifecycle authority.
- Nx, Turborepo, Bazel, Make или just отклонены для текущего масштаба: workspace не имеет общего dependency graph, build cache или CI, а репозитории уже владеют canonical gates.
- Versioned source tree, patch-only, programmatic generator и symlink для root
-  agent entrypoints отклонены для текущего масштаба: они добавляют отдельный
-  projection lifecycle поверх уже достаточных schema, docs и scripts.
-
-## Исторические последствия
-
-OpenSpec CLI закреплён exact version contract; новая stable release не включает
-auto-upgrade, а смена contract является отдельным SDD change со staged
-проверками совместимости. Локальная точка входа оставалась навигацией,
-а обязательные ограничения проверялись отдельно. Planning
-verifier до approval проверяет только детерминированную структуру: capability
-set, Delivery Map, rollback, task area и Requirement coverage. Он различает
-artifact-validation, неверный invocation и failure окружения, чтобы agent не
-переписывал planning artifact из-за сломанного вызова или prerequisite.
-
-Dispatcher знает четыре workspace area, но не реализует build или test logic:
-он делегирует repo-owned commands. Approval identity остаётся человеческим
-workflow constraint, потому что schema моделирует порядок артефактов, но не
-личность утвердившего. Semantic review по-прежнему не заменяется structural
-checks.
-
-Решение пересматривается, если OpenSpec перестанет поддерживать нужный artifact graph, появится обязательный общий CI/build graph или стоимость последовательной локальной orchestration станет существенной. В этих случаях новый ADR сравнивает native evolution с внешним engine либо monorepo platform.
@@ -1,58 +0,0 @@
---
-status: superseded
---
-
-# Native OpenSpec lifecycle и repository gates
-
-Обязательность описанной ниже процедуры заменена
-[ADR 012](012-task-driven-development-with-scoped-context.md). Текст сохраняет
-историческое решение; current policy — прямая работа по задаче.
-
-## Контекст
-
-[ADR 010](010-native-openspec-sdd-and-local-orchestration.md) сохраняет rationale
-выбора native OpenSpec и независимых repository gates. Его описание schema v3,
-custom authority/planning verifiers и dispatcher относится к прежней реализации.
-На момент решения проектная schema `wealth-ledger-sdd`
-имела version 5 и граф `Proposal → Delta Specs → Design → Tasks → Apply`.
-Порядок работы определялся средствами OpenSpec и общими правилами проекта;
-дополнительные точки входа служили навигацией по единой процедуре.
-
-Версия OpenSpec CLI была зафиксирована как `1.10.0`.
-Версия schema и CLI contract — разные сведения. Фиксация версии
-не доказывает запуск прежних проверок; это решение не меняет CLI pin,
-version contract, schema или требования к tooling.
-
-## Решение
-
-Частично заменить ADR 010 в части прежней schema version и orchestration.
-Единым хранилищем согласования оставался `wealth-ledger-specs`.
-Процедура разделяла следующие ответственности:
-
- Согласование ролей, подтверждений, объёма поставки и обязательных проверок.
- Планирование и применение изменений, структурную проверку и смысловое согласование требований.
- Выбор и повторную сверку исходных знаний, восстановление контекста и повторное использование свидетельств.
-
-Native OpenSpec получает structure и contextFiles текущего artifact или Apply.
-Каждое изменяемое приложение владело своей проверкой качества. Выполнение
-процедуры не зависит от custom verifier, dispatcher, skill или session adapter;
-optional entrypoints остаются navigation, без второго workflow engine.
-
-## Последствия
-
-Люди и автоматизированные инструменты следовали единой процедуре, а каждый
-репозиторий отвечал за собственные проверки. ADR фиксировал причину этого
-разделения ответственности. Исходные альтернативы и rationale остаются
-в ADR 010; historical archives, audits и evidence сохраняют описание своего времени.
-
-Structural success не подтверждает решение Change Owner, semantic compliance
-или независимый PASS. Approval bindings, полный применимый context/Design
-package, независимая Validation и отдельная Finalization сохраняются.
-Замена orchestration не ослабляет gates и не разрешает изменение незатронутых
-main-spec requirements о tooling.
-
-Текущие принципы сопровождения описаны в
-[engineering governance](../development/engineering-governance.md), роль
-сохранённых требований — в [OpenSpec](../development/openspec-authority-and-lifecycle.md).
-Эти материалы отражают последующее упрощение процесса, а не восстанавливают
-обязательность исторической процедуры.
@@ -1,33 +0,0 @@
-# 012. Прямая разработка с контекстом по задаче
-
-**Status:** Accepted; supersedes обязательный lifecycle из ADR 010/011.
-
-## Context
-
-Обязательная цепочка OpenSpec artifacts не обеспечила соответствие исходному
-намерению: суженный change мог пройти все проверки, оставив backend и основные
-рекомендации исследований вне реализации. Владелец проекта выбрал прямую
-разработку без обязательного OpenSpec/SDD.
-
-## Decision
-
-Задача пользователя определяет результат. Рабочий контекст выбирается по
-предмету изменения: локальные правила разработки отделены от проектных фактов,
-а тематические источники объясняют соответствующую область. Общие принципы
-и согласование контракта не дублируются в независимых описаниях.
-
-[Engineering governance](../development/engineering-governance.md) и
-[context discipline](../development/agent-token-efficiency.md) описывают текущую
-работу. Repo gates, trust-boundary checks, migration safety и semantic review
-сохраняются. OpenSpec используется только по явному запросу; history сохраняется.
-
-## Consequences
-
-Обычная задача не требует planning artifacts, role handoffs, approval fingerprints
-и archive. Сложные public/security/data решения уточняются по существу до опасной
-операции. Правильность routing проверяется на задачах и counterexamples; качество
-агента оценивается по наблюдаемым outcomes, а не по числу файлов или checkboxes.
-
-Рекомендации исследований адаптируются к принятой архитектуре и существующим
-проверкам WealthLedger. Backend остаётся источником OpenAPI. Новые сервисы,
-общая инфраструктура и проверки не вводятся только ради организации контекста.
@@ -15,11 +15,6 @@
 Это давало частичное покрытие одного агентства без покупки доступа,
 но не рейтинг любой российской облигации и не стабильный контракт API.

-Основания выбора сохранены из исследования, а применение решения подтверждено
-backend-коммитом `235c179` (`feat: add bond details, yields and credit ratings`).
-Исходное исследование содержало также рекомендации; эта запись фиксирует
-выбранный подход, не объявляя все рекомендации реализованными.
-
 ## Решение

 Использовать публичный [реестр выпусков НКР](https://ratings.ru/ratings/issues/)
@@ -1,39 +1,27 @@
 # 014. Актуальная OpenAPI-схема как вход frontend

-**Статус:** принято 2026-09-13; docs, specs и frontend-инструкции приведены
-к решению. Настройка remote issues и branch protection выполняется отдельно.
+**Статус:** принято 2026-09-13.

 ## Контекст

-Frontend и backend — независимые репозитории. Знание путей и команд backend
-в frontend связывает их внутреннее устройство. Для текущего процесса разработки
-владелец проекта принимает актуальность переданной OpenAPI-схемы как допущение;
-проверка пары revisions и дополнительное сравнение схем не требуются.
+Frontend и backend — независимые репозитории. Зависимость frontend от путей
+и команд backend связывала бы их внутреннее устройство. Предоставленная
+OpenAPI-схема служит границей между владельцем API и его потребителем.

 ## Решение

-Backend остаётся источником HTTP-контракта согласно [ADR 002](002-nest-generated-openapi-contract.md).
+Backend остаётся источником HTTP-контракта согласно
+[ADR 002](002-nest-generated-openapi-contract.md).
 Frontend принимает предоставленную OpenAPI-схему как актуальную и генерирует
-из неё типы локально. Его команды не читают файлы соседнего backend checkout
-и не запускают backend-скрипты. Подготовка и доставка схемы находятся вне frontend.
-
-Не требуется фиксировать пару SHA frontend/backend или сравнивать frontend-схему
-с runtime OpenAPI backend. Локальная проверка соответствия generated types
-входной схеме сохраняется: она не проверяет актуальность схемы относительно backend.
-Обычные CI checks по-прежнему должны проверять текущий commit изменения.
+из неё типы локально, без доступа к соседнему backend checkout.
+Подготовка и доставка схемы находятся вне frontend.

 ## Последствия

-Задача frontend #3 ограничивается локальной генерацией из предоставленной схемы;
-экспорт backend не становится обязанностью frontend. Из frontend #2 исключается
-требование проверки явно выбранной пары revisions. Требования безопасности
-frontend #4 этим решением не меняются.
+Frontend зависит от публичного контракта, а не от внутреннего устройства
+backend. Соответствие типов входной схеме не гарантирует её актуальность:
+рассинхронизацию предоставленной схемы и работающего API frontend не выявляет
+сравнением схем. Актуальность входа остаётся принятым допущением.
+OpenAPI endpoint не является runtime-зависимостью SPA.

-Рассинхронизацию предоставленной схемы и backend отдельный gate не обнаруживает:
-её отсутствие принято как допущение. Тесты HTTP-поведения, валидации и авторизации
-остаются нужны.
-
-Решение заменяет прежнее требование сравнения runtime OpenAPI с frontend
-snapshot в [OpenAPI contract flow](../development/runtime-openapi-verification.md)
-и [спецификации генерации API](../../specs/openspec/specs/api-contract-generation/spec.md).
-Связанные remote issues и настройки защиты ветки требуют отдельного обновления.
+Текущее взаимодействие описано в [HTTP API](../architecture/http-api.md).
@@ -17,8 +17,5 @@
 - [007 — React Query fetch policy](007-react-query-fetch-policy.md)
 - [008 — Pino backend logging](008-pino-backend-logging.md)
 - [009 — Concurrent refresh rotation policy](009-concurrent-refresh-rotation-policy.md)
- [010 — Native OpenSpec SDD и local orchestration](010-native-openspec-sdd-and-local-orchestration.md) — исторический; частично заменён ADR 011, обязательность SDD отменена ADR 012.
- [011 — Native OpenSpec lifecycle и repository gates](011-native-openspec-lifecycle-with-repository-gates.md) — заменён ADR 012 в части обязательного lifecycle.
- [012 — Прямая разработка с контекстом по задаче](012-task-driven-development-with-scoped-context.md)
 - [013 — НКР как первый источник кредитных рейтингов облигаций](013-nkr-bond-credit-ratings.md)
 - [014 — Актуальная OpenAPI-схема как вход frontend](014-trusted-openapi-input.md)
@@ -15,7 +15,7 @@
 | Что считается кэшем и когда прежние данные теряют право на повторное использование? | [Свежесть данных](cross-cutting/data-freshness.md) |
 | Как обрабатываются ошибки и ожидание? | [HTTP API и ошибки](http-api.md), [состояния интерфейса](cross-cutting/ui-resilience.md) |
 | Как связать ошибку с обработкой запроса? | [Наблюдаемость](http-api.md#наблюдаемость) |
-| Как устроено подтверждённое локальное окружение? | [Container](containers.md#представление-container), [локальная диагностика](../development/local-workspace.md) |
+| Как устроено подтверждённое локальное окружение? | [Container](containers.md#представление-container), [качество и ограничения](containers.md#качество-и-ограничения) |
 | Что означают предметные термины? | [Глоссарий](../glossary.md) |

 Эта карта покрывает вопросы архитектуры там, где о них есть подтверждённое
@@ -104,6 +104,20 @@ credentials не являются сохраняемым представлен
 [модель свежести](cross-cutting/data-freshness.md) отделяет это от хранения
 учётных данных.

+## Сохранение и восстановление данных
+
+Резервная копия SQLite должна быть согласованной: для работающей базы
+используется SQLite backup API с учётом WAL. Несогласованное копирование
+файлов базы и WAL не сохраняет целостный снимок. Восстановление проверяется
+на отдельной копии. Ключ шифрования подключения хранится отдельно от базы;
+его потеря делает сохранённый T-Bank token нечитаемым.
+
+Откат приложения требует совместимости предыдущей версии с сохранённой
+схемой. Расширенная банковскими таблицами схема сохраняет пользователей,
+сессии и подключения. Возврат старого backup поверх новой истории удалил бы
+введённые банковские операции; откат приложения не равнозначен откату данных.
+Совместимость произвольных будущих версий этим не гарантируется.
+
 ## Стратегия решения и её основания

 Локальная база и Prisma дают типизированный доступ к локальному состоянию
@@ -137,8 +151,10 @@ access token и вращаемый refresh token. [Политика query-кэш
 и [HTTP API](http-api.md#error-contract).

 Подтверждённая топология — локальная SPA и локальный API с файлом SQLite.
-Origin браузера, адрес API и cookie policy должны быть согласованы; условия
-и диагностика описаны в [локальном окружении](../development/local-workspace.md).
+Origin браузера, адрес API и cookie policy должны быть согласованы.
+`localhost` и `127.0.0.1` задают разные browser-границы для cookie и CORS.
+Локальный HTTP поддерживается в development-режиме backend; в остальных
+режимах refresh-cookie имеет Secure flag и требует защищённого соединения.
 Наличие локального запуска не задаёт production-топологию или гарантии SLA.

 Кэши и лимитер T-Bank действуют на экземпляр backend. Ротация ключа шифрования
@@ -4,8 +4,10 @@

 Backend генерирует OpenAPI из собственного публичного API. Frontend использует
 предоставленный OpenAPI snapshot как актуальный вход и локально генерирует
-типизированный клиент. Направление описано в
-[OpenAPI contract flow](../development/runtime-openapi-verification.md).
+типизированный клиент. Backend владеет контрактом, а подготовка и доставка
+схемы находятся вне frontend. Это разделение принято в
+[ADR 002](../adr/002-nest-generated-openapi-contract.md) и
+[ADR 014](../adr/014-trusted-openapi-input.md).
 API имеет prefix `/api/v1`; Swagger публикуется для локальной разработки по
 environment policy, а не используется frontend в runtime.

@@ -54,15 +56,6 @@ T-Bank token failure и временная недоступность имеют
 [Connection API](../integrations/tbank.md#состояние-и-ошибки). Raw upstream/Prisma errors
 и secrets не передаются frontend.

-## Граница доказательства
-
-OpenAPI snapshot задаёт frontend transport types, но сам по себе не доказывает
-результат каждого запроса. Безопасная обработка неожиданной ошибки проверяется
-отдельно. Валидация, доступ, статусы и cookie требуют проверки полного
-HTTP-потока; атомарность хранения — проверки с изолированной реальной базой.
-Известное ограничение сквозных проверок описано в
-[проверке backend](../development/verification.md).
-
 ## Наблюдаемость

 Backend пишет структурированные JSON-события в stdout через Pino. Обработка
@@ -0,0 +1,4 @@
+module.exports = {
+  extends: ["@commitlint/config-conventional"],
+  rules: { "type-enum": [2, "always", ["feat", "fix", "perf", "docs", "spec", "refactor", "build", "ci", "test", "style", "chore", "revert"]] },
+};
@@ -0,0 +1,47 @@
+# Визуальные принципы WealthLedger
+
+Интерфейс использует общую визуальную основу на Mantine: цветовые роли,
+типографику, интервалы, радиусы, тени и адаптивные размеры.
+Поддерживается светлая схема; тёмная тема не заявлена.
+
+## Семантические роли
+
+| Роль | Цветовая основа | Применение |
+| --- | --- | --- |
+| canvas | gray.2 | Фон приложения |
+| surface | white | Поверхности и формы |
+| subtle | gray.0 | Приглушённая поверхность |
+| text | dark.7 | Основной текст |
+| muted | gray.6 | Вторичный текст |
+| border | gray.3 | Граница поверхности |
+| primary | blue filled | Основное действие и активная навигация |
+| info | blue.6 | Информация |
+| positive | green.6 | Положительный результат с текстом или знаком |
+| negative | red.6 | Ошибка или отрицательный результат с текстом или знаком |
+| warning | yellow.6 | Предупреждение; не мелкий текст на белом |
+
+Цвет не заменяет подпись или знак. Палитра не гарантирует доступный контраст
+произвольного сочетания текста и фона. Дополнительные grape/orange и отдельные
+оформления карточек сохраняют предметный смысл соответствующего экрана;
+они не образуют универсальную финансовую классификацию всей системы.
+
+## Состояния и действия
+
+Основное, вторичное и вспомогательное действия различаются по визуальному
+приоритету. Выполнение действия и его недоступность — разные состояния.
+Пустой результат и ошибка содержат заголовок, пояснение и действие, когда
+оно предусмотрено сценарием. Ошибка объявляется вспомогательным технологиям,
+а кнопка имеет доступное название.
+
+Первая загрузка показывает структуру ожидаемого содержимого, без вымышленных
+сумм; область обозначается как занятая, декоративные фигуры не получают фокус.
+Фоновое обновление сохраняет доступные данные с локальным индикатором.
+Подробные правила — в [состояниях интерфейса](../architecture/cross-cutting/ui-resilience.md).
+
+Финансовые значения сохраняют валюту, знак и различие между нулём и
+неизвестной суммой. Предметные представления раскрыты в
+[портфеле](../domains/portfolio/overview.md), [операциях](../domains/operations/overview.md)
+и [банковских картах](../domains/cards/overview.md).
+
+Согласованная общая основа описана в
+[спецификации дизайн-системы](../../specs/openspec/specs/frontend-design-system/spec.md).
@@ -1,21 +0,0 @@
-# Сопровождение системы
-
-Здесь описаны локальное окружение, согласованность компонентов, границы
-проверки и поддержание проектных знаний. Команды разработки и coding conventions
-принадлежат [frontend](../../frontend/AGENTS.md) и [backend](../../backend/AGENTS.md).
-
- [Локальное окружение](local-workspace.md) — предпосылки работы, первый пользовательский сценарий и диагностика.
- [Проверки системы](verification.md) — что доказывают проверки интерфейса, API и хранения данных, известные ограничения.
- [HTTP contract](runtime-openapi-verification.md) — направление генерации OpenAPI и локальная проверка snapshot/types.
- [Дизайн-система](design-system.md) / [UI-каталог](ui-catalog.md) — визуальные роли, реальные состояния и ограничения примеров.
- [Принципы изменений](engineering-governance.md) — связность системы, риск и доказательства результата.
- [Ведение документации](../CONTRIBUTING.md) — самостоятельные объяснения и их обновление вместе с системой.
- [Контекст знаний](agent-token-efficiency.md) / [проверочные вопросы](agent-context-evals.md) — поиск ответа и обнаружение пробелов документации.
- [OpenSpec](openspec-authority-and-lifecycle.md) — роль сохранённых требований и статус прежнего процесса.
-
-## Исторические свидетельства
-
-[Remediation registry](audit-remediation.md) и [Completion Evidence](completion-evidence.md)
-сохраняют статусы, исходные адреса и результаты прежних проверок.
-Эти материалы не входят в самостоятельное описание текущей системы; их внутренние ссылки
-могут требовать архивного окружения и не являются условием чтения документации.
@@ -1,36 +0,0 @@
-# Проверка полноты проектных знаний
-
-Эти вопросы помогают оценить, объясняет ли документация систему без доступа
-к исходникам. Для каждого вопроса важны правильный ответ, существенное
-ограничение и отсутствие ошибочного вывода из похожего сценария.
-
-## Cases
-
-| Вопрос | Объяснение | Существенная граница |
-| --- | --- | --- |
-| Кто подтверждает доступ к брокерскому счёту? | [Обзор](../overview.md#как-связаны-представления) | Сессия подтверждает пользователя, но идентификатор счёта не доказывает доступ |
-| Как меняются финансовые данные при замене token? | [Подключение](../integrations/tbank.md#граница-финансового-кэша) | Данные прежнего поколения не становятся сохранённым снимком нового подключения |
-| Что происходит при конкурентном refresh? | [Authentication](../domains/authentication/overview.md), [ADR 009](../adr/009-concurrent-refresh-rotation-policy.md) | Один победитель; заменённый token не отзывает его сессию сам по себе |
-| Как восстанавливается интерфейс после ошибки обновления? | [UI resilience](../architecture/cross-cutting/ui-resilience.md) | Фоновая ошибка отличается от первой загрузки и смены пользователя |
-| Чем будущая выплата отличается от дохода? | [События](../domains/income/upcoming-events.md), [доходы](../domains/income/overview.md) | Прогноз не подтверждает личное зачисление |
-| Можно ли складывать разные валюты или заменить неизвестное нулём? | [Money](../glossary.md#money) | Точность, валюта и отсутствие значения сохраняются отдельно |
-| Откуда рейтинг и доходность облигации? | [Bond detail](../domains/instruments/bonds.md) | Рейтинг эмитента не заменяет рейтинг выпуска; рыночная доходность не равна личному результату |
-| Доказывает ли OpenAPI правильность ошибки запроса? | [HTTP API](../architecture/http-api.md#error-contract) | Равенство схем не доказывает полный HTTP-поток |
-| Что гарантирует проверка хранения данных? | [Backend](verification.md#api-и-хранение-данных) | Проверка с подставными ответами не доказывает атомарность реальной базы |
-| Как ограничиваются обращения к внешнему сервису? | [T-Bank](../integrations/tbank.md#конфигурация-и-ограничения) | Повторы, очередь и лимит ограничены; TLS остаётся включённым |
-| Защищает ли фильтрация логов любое сообщение? | [ADR 008](../adr/008-pino-backend-logging.md) | Секрет в свободном тексте требует отдельной проверки |
-| Есть ли восстановление пароля по письму? | [Ограничения auth](../domains/authentication/overview.md#ограничения) | Пример будущего сценария не является поставленной возможностью |
-
-## Что измерять
-
-Полезное объяснение позволяет найти ответ, назвать ограничение и связать его
-с другими сценариями. Оцениваются неверные выводы о доступе, деньгах, полноте
-данных и источниках, а также число уточнений до правильного понимания.
-Время поиска и объём чтения имеют смысл только вместе с точностью ответа.
-
-## Изменение правил
-
-Если знание есть, но его трудно найти, уточняется навигация. Если документ
-найден, но не объясняет различие понятий или ограничение, уточняется объяснение.
-При конфликте источников сохраняется отметка о ручном решении; догадка не
-подменяет установленный факт.
@@ -1,42 +0,0 @@
-# Контекст знаний о системе
-
-Цель навигации — дать читателю знания, необходимые для конкретного вопроса,
-без предварительного чтения всей документации. Самостоятельное объяснение
-связывает понятия, сценарии и ограничения, а не воспроизводит устройство кода.
-
-## Routing context
-
-[Тематическая карта](../README.md#предметные-области) направляет к нужному предмету:
-аутентификация связана с безопасностью и сессиями, денежный показатель —
-с его происхождением и валютой, ошибка интерфейса — с восстановлением данных.
-Вопрос о внешнем виде не требует автоматически изучать хранение данных.
-При обнаружении новой существенной границы расширяется и нужный контекст.
-
-## Источники и конфликты
-
-Публичный HTTP-контракт описывается OpenAPI backend; документация объясняет
-систему, ADR сохраняют причины решений, исследования предлагают варианты.
-Существующее поведение не отменяет согласованное требование, а рекомендация
-из исследования не становится принятым решением автоматически.
-
-При расхождении возможны устаревшее объяснение, дефект реализации или
-незавершённое изменение. Неустановленный смысл, особенно в безопасности,
-данных и публичном контракте, явно отмечается для ручного решения.
-Карта ответственности за знания — [ведение документации](../CONTRIBUTING.md).
-
-## Recovery и handoff
-
-Продолжение работы опирается на ожидаемый результат, выполненные изменения,
-оставшиеся вопросы, результаты проверок и ограничения. Дублирование требований
-в нескольких независимых пересказах создаёт риск расхождения. Исторические
-проверки сохраняют своё значение только для того состояния системы, в котором
-они выполнялись; секреты не являются допустимым содержимым свидетельств.
-
-## Проверка эффективности
-
-[Проверочные вопросы](agent-context-evals.md) показывают, можно ли получить
-правильную модель системы и отличить близкие понятия. Качество оценивается по
-верности ответа, найденным ограничениям и необходимости дополнительных уточнений.
-Число документов, их краткость или успешная проверка Markdown сами по себе
-не доказывают полезность знания. Сравнение результатов требует одинаковых
-вопросов и сопоставимых условий.
@@ -1,579 +0,0 @@
-# Audit remediation registry
-
-## Назначение
-
-Это единый versioned реестр текущего состояния remediation для findings из всех [технических audit snapshots](../audits/README.md). Каждый аудит — неизменяемый source of facts; этот документ хранит только текущий статус, путь продолжения и evidence последующих решений, не копируя полный текст finding.
-
-## Правила работы
-
- Каждая audit-derived запись имеет один статус: `planned`, `active`, `done`, `deferred` или `accepted`.
- Каждое уникальное external claim дополнительно имеет независимый triage
-  disposition: `confirmed`, `already-covered`, `rejected` или `deferred`.
-  Повтор одного underlying claim в нескольких reports получает один Audit ID со
-  ссылкой на каждый source. Disposition не является remediation status:
-  `confirmed` ещё может быть active, а `rejected` — accepted как проверенное
-  решение ничего не внедрять.
- Одновременно допускается не более одного `active` remediation change. Пока он существует, продолжается только он. При наличии `planned` ровно одна запись отмечается следующей рекомендуемой задачей, но она не запускается параллельно active change.
- Новая запись `done` требует даты и ссылки на фактически выполненную работу и её проверки (например, commit/PR или существующее evidence). OpenSpec archive не является обязательным; не создавайте отдельные artifacts только ради статуса.
- `deferred` и `accepted` требуют даты, rationale и review trigger либо ссылки на явное решение владельца.
- При смене статуса обновляется только этот реестр; versioned audit snapshot не редактируется.
-
-Текущая проверка результата определена в
-[engineering governance](engineering-governance.md#проверка-результата).
-Исторические записи
-ниже, прежние ссылки на `completion-evidence.md` в docs и датированные audit
-snapshots сохраняются без переноса или переписывания задним числом.
-
-Датированные dispositions ниже описывают проверки и решения своего времени;
-они не восстанавливают прежние SDD prerequisites. Live ссылки ведут к текущим
-owners, а историческое evidence сохраняется по исходным адресам.
-
-## Текущее состояние workflow
-
- Bootstrap change: [`2026-08-23-establish-audit-remediation-workflow`](../../specs/openspec/changes/archive/2026-08-23-establish-audit-remediation-workflow/) — `archived`; это process foundation и не закрывает ни одного Audit ID.
- Последний завершённый audit remediation change: [`2026-09-06-complete-frontend-audit-remediation`](../../specs/openspec/changes/archive/2026-09-06-complete-frontend-audit-remediation/) — `archived`; FE26-02–FE26-18 закрыты, FE26-01 сохраняет прежнее evidence.
- Единственный active change: отсутствует.
-
-## Текущая задача
-
-Frontend audit remediation завершена; [Completion Evidence][FE26-E] содержит
-archive, delivery commits, verification и независимый verdict. Следующий
-remediation change создаётся после выбора владельцем продолжения.
-
-## Следующая рекомендуемая задача
-
-`assess-auth-platform-options` для AUD24-02. Change применит Solution Assessment
-к существующей реализации и зрелым auth platforms, включая Better Auth, и не
-предрешает миграцию.
-
-## Реестр findings
-
-### Frontend audits: август 2026
-
-Источник: [три неизменяемых snapshots](../audits/2026-08-frontend-repository-audits/README.md).
-`G` — общий audit от 31 августа, `A28` — audit от 28 августа,
-`S` — structural audit от 31 августа. Все 22 source findings сопоставлены
-18 underlying claims ниже; одинаковые F IDs без source prefix неоднозначны.
-
-Дата сопоставления и закрытия FE26-02–FE26-18: 06.09.2026.
-[Completion Evidence][FE26-E] содержит общий archive path, delivery commits
-всех четырёх областей, точные commands/results и независимый PASS.
-`already-covered` обозначает прежнюю реализацию, подтверждённую текущей
-проверкой, без фиктивной повторной implementation task.
-Реализация прежних исправлений находится во frontend `c97f62b` и backend
-`55b100d`; эти идентификаторы не доказывают исторические approvals или gates.
-
-| Audit ID | Нормализованный claim | Sources | Disposition | Remediation status | Evidence / текущее состояние |
-| --- | --- | --- | --- | --- | --- |
-| FE26-01 | Общая граница финансового кэша при смене T-Bank connection. | [FE-A28] F1; [FE-S] F-01 | already-covered | done | 01.09.2026; [archive](../../specs/openspec/changes/archive/2026-09-01-harden-tbank-connection-cache-boundary/), delivery commits, gates и independent review — [существующее Completion Evidence](completion-evidence.md#2026-09-01-harden-tbank-connection-cache-boundary). |
-| FE26-02 | Проверять соответствие generated types OpenAPI snapshot. | [FE-A28] F2; [FE-G] F-01 | already-covered | done | 06.09.2026; [FE26-E]. [check-openapi](../../frontend/scripts/check-openapi.mjs) включён в [verify](../../frontend/package.json); snapshot/types проверяются offline. Pre-commit состав честно описан в conventions. |
-| FE26-03 | Events должен соблюдать принятую VM/view границу. | [FE-A28] F3 | confirmed | done | 06.09.2026; [FE26-E]. [Events VM](../../frontend/src/pages/account-events/ui/AccountEventsPage.vm.ts) владеет route/query/state/retry; [container](../../frontend/src/pages/account-events/ui/AccountEventsPage.tsx) использует прежние views. Остальные named pages уже разделены; см. FE26-13. |
-| FE26-04 | Покрыть успешный public login journey. | [FE-G] F-02 | already-covered | done | 06.09.2026; [FE26-E]. [AppRoutes tests](../../frontend/src/app/routes/AppRoutes.test.tsx): форма, нормализованные credentials, реальный AuthProvider/MSW и protected landing. |
-| FE26-05 | Безопасно отклонять невозможные календарные даты. | [FE-G] F-03 | already-covered | done | 06.09.2026; [FE26-E]. [Income VM](../../frontend/src/pages/account-income/ui/AccountIncomePage.vm.ts) проверяет finite date до ISO conversion; [regression tests](../../frontend/src/pages/account-income/ui/AccountIncomePage.test.tsx) покрывают invalid date и leap year. |
-| FE26-06 | Включить type-only dependencies в public API guardrail. | [FE-G] F-04 | already-covered | done | 06.09.2026; [FE26-E]. [dependency-cruiser](../../frontend/dependency-cruiser.cjs) включает tsPreCompilationDeps; [shared API](../../frontend/src/shared/api/index.ts) экспортирует paths. |
-| FE26-07 | Дать общим display/API primitives нейтральных владельцев. | [FE-G] F-05; [FE-S] F-07 | already-covered | done | 06.09.2026; [FE26-E]. [shared display](../../frontend/src/shared/lib/display.ts) владеет Money/date/logo; [apiErrorCode](../../frontend/src/shared/api/problem-details.ts) объединяет transport extraction. S F-07 расширяет тот же ownership claim API helper; повторной реализации нет. |
-| FE26-08 | Синхронизировать entrypoint docs с фактическими gates. | [FE-G] F-06 | already-covered | done | 06.09.2026; [FE26-E]. [Frontend README](../../frontend/README.md), [conventions](../../frontend/.ai/conventions/frontend-ui.md) и [workflow](frontend-workflow.md) описывают существующие команды, не обещая удалённые runtime/hygiene checks. |
-| FE26-09 | Убрать механическое обязательное дробление каждого component. | [FE-G] F-07 | already-covered | done | 06.09.2026; [FE26-E]. [UI pattern](../../frontend/.ai/conventions/frontend-ui.md) сохраняет semantic ownership и допускает tightly-coupled renderers; это guidance, а не line-count gate. Конкретное разделение крупных modules учтено отдельно FE26-13. |
-| FE26-10 | Объединить protected query policy и endpoint query identity ownership. | [FE-G] F-08; [FE-S] F-05 | already-covered | done | 06.09.2026; [FE26-E]. [App defaults](../../frontend/src/app/ui/App.tsx), [T-Bank VM](../../frontend/src/features/tbank-connection/ui/TbankConnectionSection.vm.ts) и entity-owned options operations/portfolio; status использует общий authenticated query seam. |
-| FE26-11 | Централизовать test cleanup и auth reset. | [FE-S] F-02 | already-covered | done | 06.09.2026; [FE26-E]. [Test setup](../../frontend/src/test/setup.ts): RTL cleanup, auth reset, MSW handler reset в общем afterEach. |
-| FE26-12 | Убрать повтор server identity из Income view/model. | [FE-S] F-03 | confirmed | done | 06.09.2026; [FE26-E]. [Backend income service](../../backend/src/modules/investments/income/income-analytics.service.ts) передаёт instrumentKey; [Income VM](../../frontend/src/pages/account-income/ui/AccountIncomePage.vm.ts) проверяет и группирует готовую связь, не вычисляя identity. |
-| FE26-13 | Выделить самостоятельные ответственности семи крупных TSX modules. | [FE-S] F-04 | already-covered | done | 06.09.2026; [FE26-E]. Income/Events/Accounts/Account state views, [route fallback](../../frontend/src/app/routes/RouteFallback.tsx), [guards](../../frontend/src/app/routes/RouteGuards.tsx), breadcrumbs и T-Bank loaded section выделены во frontend `c97f62b`. |
-| FE26-14 | Устранить повтор test client policy и нестабильный cache lifetime. | [FE-S] F-06 | confirmed | done | 06.09.2026; [FE26-E]. [Test query factory](../../frontend/src/test/query.tsx) используется оставшимися auth/T-Bank harnesses; [auth test](../../frontend/src/features/auth/model/auth.test.tsx) проверяет сохранение client и seeded cache при rerender. |
-| FE26-15 | Перенести компонентные стили из global CSS к владельцам. | [FE-S] F-08 | already-covered | done | 06.09.2026; [FE26-E]. [Global styles](../../frontend/src/shared/theme/styles.css) содержат базовые правила; AppShell, breadcrumbs и auth используют CSS Modules, StateView — Mantine props. |
-| FE26-16 | Исправить source connectedAt contract вместо String coercion. | [FE-S] F-09 | already-covered | done | 06.09.2026; [FE26-E]. [Backend DTO](../../backend/src/modules/investments/tbank-connection/tbank-connection.dto.ts) задаёт nullable date-time string; [frontend consumer](../../frontend/src/features/tbank-connection/ui/TbankConnectionSectionLoaded.tsx) не скрывает неверный transport type через String. |
-| FE26-17 | Перенести auth validation и payment invariants из JSX к model owners. | [FE-S] F-10 | already-covered | done | 06.09.2026; [FE26-E]. [Auth validation](../../frontend/src/features/auth/model/validation.ts), [ledger display](../../frontend/src/entities/broker-operation/model/display.ts) владеют соответствующими правилами. |
-| FE26-18 | Удалить redundant position modes и test-only proxy exports. | [FE-S] F-11 | already-covered | done | 06.09.2026; [FE26-E]. [PositionCard](../../frontend/src/pages/account/ui/components/PositionCard.view.tsx) выводит mode из kind; [StateView](../../frontend/src/shared/ui/StateView.tsx) не экспортирует Mantine Button; page barrels сохраняют product surface. |
-
-[FE26-E]: completion-evidence.md#2026-09-06-complete-frontend-audit-remediation
-[FE-G]: ../audits/2026-08-frontend-repository-audits/frontend-repository-audit.md
-[FE-A28]: ../audits/2026-08-frontend-repository-audits/frontend-repository-audit-2026-08-28.md
-[FE-S]: ../audits/2026-08-frontend-repository-audits/frontend-structural-maintainability-audit.md
-
-### Повторный multi-source review WealthLedger SDD v2 26.08.2026
-
-Шесть исходных reports находятся в [immutable snapshot set](../audits/2026-08-26-wealth-ledger-sdd-v2-review/README.md).
-Сокращения: [D2] — DeepSeek, [G2] — Gemini, [Gr2] — Grok, [K2] — Kimi,
-[Q2] — Qwen, [Z2] — Z.AI. Оценки и предложенные patches не принимаются без
-сопоставления с воспроизводимым project invariant.
-
-| Audit ID | Нормализованный claim | Sources | Disposition | Remediation status | Evidence, rationale или review trigger |
-| --- | --- | --- | --- | --- | --- |
-| SDD26R2-01 | Сократить и визуально приоритизировать instructions, сохранив самодостаточные critical rules и единый основной язык. | [D2], [Gr2], [Z2] | confirmed | done | 2026-08-26; [archive](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-agent-resilience/); specs `8462a3ba75d6dda491b9221699357c58d8f8e3cc`, `779a1e1305f8c209a4f98fae7f87718e48d61b37`; docs `d80e2e32b2ebadcd93a53105e1ac337fe2c1f4f6`; commands/results: [Completion Evidence](completion-evidence.md#2026-08-26-harden-openspec-sdd-agent-resilience). |
-| SDD26R2-02 | Delta Spec template не должен предрешать `ADDED` и должен показывать все допустимые operations без активных пустых sections. | [K2] | confirmed | done | 2026-08-26; тот же [archive](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-agent-resilience/), delivery commits и [Completion Evidence](completion-evidence.md#2026-08-26-harden-openspec-sdd-agent-resilience). |
-| SDD26R2-03 | Planning verifier должен отличать defect артефакта от неверного invocation и failure окружения. | [Z2], [Q2] | confirmed | done | 2026-08-26; тот же [archive](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-agent-resilience/), delivery commits и [Completion Evidence](completion-evidence.md#2026-08-26-harden-openspec-sdd-agent-resilience). Retry counter отклонён владельцем как лишнее состояние. |
-| SDD26R2-04 | Apply должен читать точные native `contextFiles` и локальные правила affected repositories. | [K2] | confirmed | done | 2026-08-26; тот же [archive](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-agent-resilience/), delivery commits и [Completion Evidence](completion-evidence.md#2026-08-26-harden-openspec-sdd-agent-resilience); отдельный context mapping не введён. |
-| SDD26R2-05 | `N/A` rationale должно объяснять техническую необходимость, но его смысл нельзя надёжно валидировать простым text heuristic. | [Q2] | confirmed | done | 2026-08-26; тот же [archive](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-agent-resilience/), delivery commits и [Completion Evidence](completion-evidence.md#2026-08-26-harden-openspec-sdd-agent-resilience); semantic sufficiency оставлена owner/reviewer. |
-| SDD26R2-06 | Граница mechanical Apply fix должна явно исключать Requirement, Scenario, architecture и Verification changes. | [Q2], [Z2] | confirmed | done | 2026-08-26; тот же [archive](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-agent-resilience/), delivery commits и [Completion Evidence](completion-evidence.md#2026-08-26-harden-openspec-sdd-agent-resilience). |
-| SDD26R2-07 | Exact Requirement heading в `Covers` нужно копировать дословно и проверять детерминированно. | [Z2] | already-covered | accepted | 2026-08-26; SDD26-12 уже требует exact heading, а planning verifier отклоняет неизвестную reference и uncovered Requirement. Review trigger: удаление или ослабление exact-reference check. |
-| SDD26R2-08 | Добавить `Target Repositories` в Proposal или расширить owner area произвольными repository paths. | [G2], [Gr2] | rejected | accepted | 2026-08-26; Proposal сохраняет intent без implementation topology; фиксированная Delivery Map отражает фактические четыре repos. Пересмотреть только при добавлении новой delivery area в workspace. |
-| SDD26R2-09 | Хранить machine-readable approval markers внутри versioned artifacts. | [Gr2], [K2] | rejected | accepted | 2026-08-26; approval identity принадлежит разговору с Change Owner. Marker дублировал бы external state и мог бы ложно выглядеть действующим после upstream change. Review trigger: воспроизводимый случай ложного approval после потери conversation state. |
-| SDD26R2-10 | Добавить отдельные verify/archive/DoD artifacts или phase. | [Gr2], [K2] | already-covered | accepted | 2026-08-26; SDD26-11 уже закрыт dispatcher, semantic verification, independent review, hard archive blockers и post-archive Completion Evidence без второго workflow artifact. Review trigger: доказанный terminal gap, который эти gates не выражают. |
-| SDD26R2-11 | Ослабить последовательность Specs → Design для exploratory feasibility. | [Gr2] | rejected | accepted | 2026-08-26; production change сохраняет утверждённый behavior до architecture. Throwaway feasibility work допустима вне Apply, но не становится versioned parallel plan. Review trigger: повторяемый change, где безопасная feasibility work блокируется текущим graph. |
-| SDD26R2-12 | Вынести Solution Assessment в отдельный artifact. | [Gr2] | rejected | accepted | 2026-08-26; conditional section остаётся в Design, где сравнение вариантов непосредственно обосновывает architecture; отдельный artifact усложнил бы graph без нового invariant. Review trigger: появление independently reusable assessment с отдельным approval owner. |
-| SDD26R2-13 | Требовать отдельную workspace-task для semantic review каждого change. | [Gr2] | already-covered | accepted | 2026-08-26; terminal semantic verification и independent read-only review обязательны; workspace task создаётся в Tasks для orchestration, когда она нужна delivery plan. Review trigger: semantic review, пропущенный из-за отсутствия task-level representation. |
-| SDD26R2-14 | Добавить Success Metrics в Proposal. | [Gr2] | rejected | accepted | 2026-08-26; observable acceptance принадлежит Requirements и Scenarios. Универсальные metrics в intent artifact создавали бы неподтверждённые цели без измеримого project need. Review trigger: утверждённая product metric, которую нельзя выразить Requirements/Scenarios. |
-| SDD26R2-15 | Вести schema changelog рядом с version field. | [Gr2] | rejected | accepted | 2026-08-26; versioned Git history, OpenSpec change и archive уже фиксируют rationale и diff. Второй changelog не добавляет authority. Review trigger: наблюдаемая невозможность восстановить schema migration из canonical history. |
-| SDD26R2-16 | Добавить CI/CD validation. | [D2] | deferred | deferred | 2026-08-26; текущий contract сознательно использует canonical local gates под Node 22. Review trigger: появление project CI. |
-| SDD26R2-17 | Добавить dependencies между changes, sizing задач и commit convention. | [K2] | already-covered | accepted | 2026-08-26; dependencies остаются deferred в SDD26-15 до реального conflict; sizing отклонён в SDD26-16, commit convention — в SDD26-19. Review triggers наследуются из этих записей; повторный report не даёт нового evidence. |
-| SDD26R2-18 | Exact schema version и criteria Solution Assessment отсутствуют или недостаточны. | [D2] | already-covered | accepted | 2026-08-26; `.cli-version`, schema version, controlled upgrade contract и explicit assessment trigger areas уже закреплены schema/governance. Review trigger: assessment, для которого текущие trigger areas не дают однозначного решения. |
-
-[D2]: ../audits/2026-08-26-wealth-ledger-sdd-v2-review/deepseek-audit.md
-[G2]: ../audits/2026-08-26-wealth-ledger-sdd-v2-review/gemini-audit.md
-[Gr2]: ../audits/2026-08-26-wealth-ledger-sdd-v2-review/grok-audit.md
-[K2]: ../audits/2026-08-26-wealth-ledger-sdd-v2-review/kimi-audit.md
-[Q2]: ../audits/2026-08-26-wealth-ledger-sdd-v2-review/qwen-audit.md
-[Z2]: ../audits/2026-08-26-wealth-ledger-sdd-v2-review/zai-audit.md
-
-### Multi-source assessment WealthLedger SDD 26.08.2026
-
-Raw external reports и checksums находятся в
-[immutable snapshot set](../audits/2026-08-26-wealth-ledger-sdd/README.md).
-Сокращения источников: [D] — DeepSeek, [G] — Gemini, [K] — Kimi, [Q] — Qwen,
-[Z] — Z.AI. Ни одна внешняя рекомендация сама по себе не является project
-authority.
-
-| Audit ID | Нормализованный claim | Sources | Disposition | Remediation status | Evidence, rationale или review trigger |
-| --- | --- | --- | --- | --- | --- |
-| SDD26-01 | Снизить instruction bloat и устранить конкурирующих владельцев общих правил. | [D], [G], [Q], [Z] | confirmed | done | 2026-08-26; [`2026-08-26-harden-openspec-sdd-quality`](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-quality/): schema v2 владеет semantics, templates — shape, config — только facts/language, scripts — hard invariants; отдельный `_rules.md` не вводится. |
-| SDD26-02 | Проверять planning format машинно до approval и автоматически исправлять технические ошибки. | [D], [Z] | confirmed | done | 2026-08-26; stage-aware non-mutating verifier, controlled-invalid fixtures и format-only retry path поставлены в [`2026-08-26-harden-openspec-sdd-quality`](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-quality/). |
-| SDD26-03 | Каждая task должна иметь однозначную delivery area; multi-repo implementation нужно разделять. | [D], [G], [Z] | confirmed | done | 2026-08-26; schema v2 использует `[frontend\|backend\|specs\|docs\|workspace]`; planning verifier отклоняет owner из `N/A` area. |
-| SDD26-04 | Добавить `Target Repositories` уже в Proposal. | [G] | rejected | accepted | 2026-08-26; Proposal остаётся owner-readable intent без implementation topology. Полный scope repositories определяется позже через обязательную Design Delivery Map. |
-| SDD26-05 | Явно координировать порядок и совместимость multi-repository delivery. | [D], [G] | already-covered | accepted | 2026-08-26; Delivery Map, Contract Gate Decision, Migration Plan и workspace dispatcher уже задают owners, порядок, совместимость API и canonical gates. |
-| SDD26-06 | Формализовать trigger для Solution Assessment. | [D] | already-covered | accepted | 2026-08-26; [engineering governance](engineering-governance.md#dependencies) и schema перечисляют auth, security, storage, integrations, observability, caching, concurrency и shared tooling. |
-| SDD26-07 | Не допускать Design/Apply по неутверждённым artifacts. | [D], [K], [Z] | already-covered | accepted | 2026-08-26; human approval хранится в разговоре, one-artifact entrypoints останавливаются, downstream approvals каскадно инвалидируются. Фиктивный `approval.md` или status field не создаётся. |
-| SDD26-08 | Разрешить partial/diff `MODIFIED` вместо полного requirement block. | [D] | rejected | accepted | 2026-08-26; native OpenSpec archive semantics требуют полного `MODIFIED`; собственный merge format создал бы второй transformation engine и риск потери scenarios. |
-| SDD26-09 | Дать компактные примеры сложных delta operations. | [D], [K] | confirmed | done | 2026-08-26; schema v2 добавляет `MODIFIED`, `REMOVED` и `RENAMED` examples, сохраняя minimal ADDED-first template. |
-| SDD26-10 | Генерировать в `spec.md` placeholders всех delta sections. | [K] | rejected | accepted | 2026-08-26; пустые sections повышают шум и риск неверной операции. Complex forms принадлежат instructions/examples, а template остаётся минимальным. |
-| SDD26-11 | Явно определить DoD, verification и archive после Apply. | [D], [K], [Q] | already-covered | accepted | 2026-08-26; [engineering governance](engineering-governance.md#проверка-результата), workspace dispatcher, semantic verification, independent review и hard archive blockers уже образуют terminal protocol. Completion Evidence создаётся после факта, не в Tasks. |
-| SDD26-12 | Связать каждую task с точными Delta Requirements и отклонять uncovered requirements. | [D], [K] | confirmed | done | 2026-08-26; schema v2 использует native identity `capability path — exact Requirement heading`; planning verifier проверяет ссылки и полное покрытие без собственного ID namespace. |
-| SDD26-13 | Добавить Fast Track или сокращённую вторую schema для мелких fixes. | [G] | rejected | accepted | 2026-08-26; один lifecycle сохраняет предсказуемые approvals и archive blockers. Пропорциональность обеспечивают `skip_specs`, conditional assessment/rollback и узкие tasks. |
-| SDD26-14 | Ограничивать agent context через tool-specific `.aiignore` и список repos из Proposal. | [G] | rejected | accepted | 2026-08-26; это не portable OpenSpec invariant. Context ограничивается Delivery Map, task owner и targeted reads; dependencies/build outputs уже исключаются локальными tool/repository rules. Пересмотреть при наблюдаемом context exhaustion. |
-| SDD26-15 | Ввести общий `blocked_by`/`blocks` graph между changes. | [K] | deferred | deferred | Review trigger: первый реальный случай двух одновременно необходимых changes с доказанной ordering dependency, которую нельзя выразить текущим single-active-remediation rule. |
-| SDD26-16 | Добавить priority и sizing в Tasks. | [K] | rejected | accepted | 2026-08-26; Tasks уже dependency-ordered и ограничены одной рабочей сессией. Оценочные points не защищают observable invariant и создают неподтверждённую точность. |
-| SDD26-17 | Для труднообратимых changes нужен проверяемый rollback contract. | [K] | confirmed | done | 2026-08-26; Design template и planning verifier требуют trigger/actions/data safety/verification для risk cases либо конкретный `N/A` reason. |
-| SDD26-18 | Добавить отдельный multi-repo context mapping file. | [K] | already-covered | accepted | 2026-08-26; native `openspec instructions ... --json` уже возвращает `planningHome`, `contextFiles`, `artifactPaths` и config context. Второй context map дублировал бы CLI state. |
-| SDD26-19 | Зафиксировать commit-message convention в schema. | [K] | rejected | accepted | 2026-08-26; commit style не меняет artifact correctness и принадлежит repository delivery policy только при появлении отдельного проверяемого требования. |
-| SDD26-20 | Сделать enterprise sections условными, чтобы снизить overhead. | [Q] | already-covered | accepted | 2026-08-26; Solution Assessment уже conditional, rollback допускает содержательный `N/A`; Delivery Map и Contract Gate Decision остаются обязательными, потому что защищают multi-repo scope. |
-| SDD26-21 | Добавить явный feedback loop из Design/Apply в ранний затронутый artifact. | [Q] | confirmed | done | 2026-08-26; schema v2 и agent entrypoints маршрутизируют intent→Proposal, behavior→Specs, architecture/rollback→Design, decomposition→Tasks и инвалидируют downstream approvals. |
-| SDD26-22 | Создавать `blocker.md` и `revision-request.md` при каждом blocker/revision. | [Q] | rejected | accepted | 2026-08-26; новые workflow artifacts не поддерживаются native schema и быстро устаревают. Наблюдаемое основание сообщается Change Owner в разговоре; durable artifact добавится только при реальном повторяемом trigger. |
-| SDD26-23 | Требовать regression test для любой изменённой логики и happy-path test для любой новой. | [Q] | already-covered | accepted | 2026-08-26; [risk-based testing](engineering-governance.md#risk-based-testing) требует tests для существенных рисков и regressions, но осознанно отклоняет универсальные малоценные tests ради каждого logic/file change. |
-| SDD26-24 | Добавлять Completion Summary в конец Tasks. | [Q] | rejected | accepted | 2026-08-26; Tasks содержат только planned work. Observed results и commits появляются после выполнения в verification/archive evidence, иначе checklist смешивает план и факты. |
-| SDD26-25 | Требовать точный текстовый `STOP_PROTOCOL` после каждого artifact. | [Z] | rejected | accepted | 2026-08-26; обязательная остановка и явный approval уже enforced entrypoints. Фиксация одной строки ответа хрупка и не усиливает identity или semantic approval. |
-| SDD26-26 | Сократить explanation `planningHome.root` до короткого imperative. | [Z] | rejected | accepted | 2026-08-26; пояснение предотвращает ошибочное вычисление path при store-backed и local modes OpenSpec 1.10. После удаления duplicate config rules instruction source остаётся приемлемым; пересмотреть при измеренном context regression. |
-| SDD26-27 | Добавить дополнительные contract gates вроде `internal-proto`. | [G] | deferred | deferred | Review trigger: появление второго реального межсервисного committed contract, для которого `runtime-openapi` и repository gates недостаточны. До этого generic gate будет speculative. |
-| SDD26-28 | Root project-owned agent projection должна восстанавливаться из versioned authority. | local triage | confirmed | done | 2026-08-26; superseded by follow-up cleanup: root `.opencode` остаётся local non-authority entrypoint без versioned projection source; hard constraints остаются в schema, docs и authority verifier. |
-| SDD26-29 | Exact OpenSpec version должна быть единым compatibility contract, а не вечным literal в scripts/fixtures. | local triage | confirmed | done | 2026-08-26; `.cli-version` остаётся единственным current contract; markers/verifiers выводят expected value из него, новая stable не включает auto-upgrade. |
-| SDD26-30 | Raw multi-source evidence и triage должны быть versioned раздельно. | local triage | confirmed | done | 2026-08-26; пять reports сохранены byte-for-byte в [snapshot set](../audits/2026-08-26-wealth-ledger-sdd/README.md); live registry хранит dispositions и statuses отдельно. |
-
-[D]: ../audits/2026-08-26-wealth-ledger-sdd/deepseek-result.md
-[G]: ../audits/2026-08-26-wealth-ledger-sdd/gemini-result.md
-[K]: ../audits/2026-08-26-wealth-ledger-sdd/kimi-result.md
-[Q]: ../audits/2026-08-26-wealth-ledger-sdd/qwen-result.md
-[Z]: ../audits/2026-08-26-wealth-ledger-sdd/zai-result.md
-
-### Аудит 13.08.2026
-
-| Audit ID | Текущий статус | Связь и следующее действие | Terminal evidence или trigger |
-| --- | --- | --- | --- |
-| A-01 | done | См. WL-P2-03. | CAS rotation и regression test, 2026-08-23. |
-| A-02 | accepted | Ограниченная revocation model закреплена в ADR 006; access token живёт 15 минут. | Пересмотреть, если продукт потребует немедленный отзыв access token. |
-| A-03 | deferred | Production transport исключён из local MVP scope. | Пересмотреть перед hosted deployment или reverse-proxy contract. |
-| A-04 | done | `docs/features/tbank-connection.md` описывает поставленные Accounts, Portfolio, Ledger и Future Events. | Current-state docs проверены 2026-08-24. |
-| A-05 | done | См. WL-P1-03 и WL-P1-04. | Canonical root и hard archive lifecycle, 2026-08-23. |
-| A-06 | done | См. WL-P2-10. | Architecture/development onboarding и link review, 2026-08-24. |
-| A-07 | done | См. WL-P2-02. | P2002 mapping и concurrent registration regression, 2026-08-23. |
-| A-08 | planned | Объединить validation payload review с `tighten-backend-request-feedback`. | Готово к выбору после active change. |
-| A-09 | planned | Operations cache закрыт WL-P2-01; отдельно оценить session retention/index. | Создать scoped change после решения приоритета. |
-| A-10 | deferred | Текущая operational mitigation описана в T-Bank feature doc. | Пересмотреть при наблюдаемой потере metadata или новом large-portfolio SLA. |
-| A-11 | done | Исправлено и подтверждено самим snapshot 13.08.2026. | Transport tests и единый Bearer owner. |
-| A-12 | done | Исправлено в snapshot; дополнительно защищено WL-P3-03. | Dependency boundary fixture passed, 2026-08-24. |
-| A-13 | deferred | Frontend behavior закрыт; backend e2e зависит от WL-P2-05. | Тот же stable Prisma trigger, что у WL-P2-05. |
-| A-14 | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/). | 2026-08-24; canonical SDD governance, local guardrails and completion evidence protocol verified. |
-| A-15 | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/). | 2026-08-24; current-state ADR/spec contradictions fixed and strict specs passed. |
-| A-16 | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/). | 2026-08-24; layered AGENTS and onboarding verified. |
-| A-17 | deferred | Совпадает с accessibility scope WL-P3-04. | Пересмотреть при включении accessibility/second locale в MVP scope. |
-| A-18 | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/). | 2026-08-24; main spec H1 normalized and strict validation passed. |
-
-### Аудит 24.08.2026
-
-| Audit ID | Цель | Статус | Связанный change | Следующее действие / evidence |
-| --- | --- | --- | --- | --- |
-| AUD24-01 | Ввести risk-based testing без тестов ради файла или coverage. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; risk-based testing policy and gates recorded. |
-| AUD24-02 | Оценивать mature solutions и ретроспективно проверить auth platform. | planned | `assess-auth-platform-options` | Готово к созданию change; миграция не предрешена. |
-| AUD24-03 | Закрепить строгий artifact graph и роли OpenSpec. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; one-artifact approvals, cascade reapproval and artifact roles verified. |
-| AUD24-04 | Синхронизировать agent projection и hard archive blockers. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; project entrypoints and authority verifier reject bypass cases. |
-| AUD24-05 | Добавить canonical repo gates и workspace dispatcher. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; workspace dispatcher ran all affected gates and runtime OpenAPI. |
-| AUD24-06 | Ввести docs-as-code gate и authoritative process policy. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; docs `npm run verify` passed and engineering governance is durable docs. |
-| AUD24-07 | Сделать AGENTS компактными routing/enforcement layers. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; root and repository AGENTS layers verified. |
-| AUD24-08 | Охватить одним registry все audit snapshots и исправить stale status. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; registry covers all 53 audit IDs with one snapshot source each. |
-| AUD24-09 | Исправить current-state ADR/spec contradictions. | done | [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/) | 2026-08-24; ADR/spec contradictions fixed without editing audit snapshots. |
-
-### P1
-
-| Audit ID | Цель | Репозитории | Статус | Связанный change | Следующее действие | Terminal evidence |
-| --- | --- | --- | --- | --- | --- | --- |
-| WL-P1-01 | Один владелец React Query cache identity. | frontend | done | [`2026-08-23-stabilize-frontend-query-and-strict-contracts`](../../specs/openspec/changes/archive/2026-08-23-stabilize-frontend-query-and-strict-contracts/) | — | 2026-08-23; frontend `1250581`, specs `b8a3f96`; `npm run verify` — passed (16 files, 48 tests). |
-| WL-P1-02 | Сделать strict TypeScript исполняемым gate и устранить 16 ошибок. | frontend | done | [`2026-08-23-stabilize-frontend-query-and-strict-contracts`](../../specs/openspec/changes/archive/2026-08-23-stabilize-frontend-query-and-strict-contracts/) | — | 2026-08-23; frontend `1250581`, specs `b8a3f96`; strict typecheck and full `npm run verify` passed. |
-| WL-P1-03 | Установить единственный canonical OpenSpec root. | specs | done | [`2026-08-23-harden-openspec-authority-and-lifecycle`](../../specs/openspec/changes/archive/2026-08-23-harden-openspec-authority-and-lifecycle/) | — | 2026-08-23; frontend `d870d53`, backend `fee4f8c`, specs `51344d4`, docs `0bc8d1c`; authority verifier и 15 strict specs passed. |
-| WL-P1-04 | Сделать archive lifecycle доказательством завершённости. | specs, docs | done | [`2026-08-23-harden-openspec-authority-and-lifecycle`](../../specs/openspec/changes/archive/2026-08-23-harden-openspec-authority-and-lifecycle/) | — | 2026-08-23; frontend `d870d53`, backend `fee4f8c`, specs `51344d4`, docs `0bc8d1c`; hard archive gate и independent review passed. |
-| WL-P1-05 | Разделить non-mutating lint check и auto-fix backend. | backend | done | [`2026-08-23-make-local-verification-agent-safe`](../../specs/openspec/changes/archive/2026-08-23-make-local-verification-agent-safe/) | — | 2026-08-23; backend `71d57d6`, specs `72444db`, docs `293df9c`; `npm run lint`, app/test typecheck и 17 suites / 51 tests — passed. |
-
-### P2
-
-| Audit ID | Цель | Репозитории | Статус | Связанный change | Следующее действие | Terminal evidence |
-| --- | --- | --- | --- | --- | --- | --- |
-| WL-P2-01 | Ограничить размер и eviction operations cache. | backend, specs, docs | done | [`2026-08-23-harden-auth-and-cache-concurrency`](../../specs/openspec/changes/archive/2026-08-23-harden-auth-and-cache-concurrency/) | — | 2026-08-23; backend `c77b3cf`, specs `6e20cdf`, docs `8568e7b`; Node 22 lint, app/test typecheck и 56 unit tests passed. |
-| WL-P2-02 | Вернуть предсказуемый 409 при конкурентной регистрации. | backend, specs, docs | done | [`2026-08-23-harden-auth-and-cache-concurrency`](../../specs/openspec/changes/archive/2026-08-23-harden-auth-and-cache-concurrency/) | — | 2026-08-23; backend `c77b3cf`, specs `6e20cdf`, docs `8568e7b`; P2002 mapping and barrier regression test passed. |
-| WL-P2-03 | Сделать refresh rotation атомарной. | backend, specs, docs | done | [`2026-08-23-harden-auth-and-cache-concurrency`](../../specs/openspec/changes/archive/2026-08-23-harden-auth-and-cache-concurrency/) | — | 2026-08-23; backend `c77b3cf`, specs `6e20cdf`, docs `8568e7b`; CAS one-winner regression test passed. |
-| WL-P2-04 | Синхронизировать runtime, OpenAPI и auth success statuses. | backend, frontend | done | [`2026-08-24-align-api-contract-and-client-resilience`](../../specs/openspec/changes/archive/2026-08-24-align-api-contract-and-client-resilience/) | — | 2026-08-24; backend `9bd3400`, frontend `6d892da`, specs `800450d`, docs `b91280c`; metadata regression, frontend OpenAPI check и runtime/snapshot SHA совпали. |
-| WL-P2-05 | Восстановить runnable backend e2e gate. | backend | done | — | — | 2026-09-13; унаследованный RUST_LOG изолирован в Prisma config, 3 последовательных и 2 параллельных полных e2e passed. [Результаты](#2026-09-13--wl-p2-05-воспроизводимый-sqlite-e2e). |
-| WL-P2-06 | Добавить проходящий app/test TypeScript gate backend. | backend | done | [`2026-08-23-make-local-verification-agent-safe`](../../specs/openspec/changes/archive/2026-08-23-make-local-verification-agent-safe/) | — | 2026-08-23; backend `71d57d6`, specs `72444db`, docs `293df9c`; `npm run typecheck:app` и `npm run typecheck:test` — passed. [2026-09-13: включён strict по P1-10](#2026-09-13--wl-p2-06-strict-typescript). |
-| WL-P2-07 | Сохранять cached data во время background refetch. | frontend | done | [`2026-08-24-align-api-contract-and-client-resilience`](../../specs/openspec/changes/archive/2026-08-24-align-api-contract-and-client-resilience/) | — | 2026-08-24; frontend `6d892da`, specs `800450d`, docs `b91280c`; observable Accounts/Portfolio refetch tests и `npm run verify` — passed (17 files, 55 tests). |
-| WL-P2-08 | Нормализовать cold-start refresh failure. | frontend | done | [`2026-08-24-align-api-contract-and-client-resilience`](../../specs/openspec/changes/archive/2026-08-24-align-api-contract-and-client-resilience/) | — | 2026-08-24; frontend `6d892da`, specs `800450d`, docs `b91280c`; cold-start и protected-401 transport-failure tests passed. |
-| WL-P2-09 | Проверять backend runtime OpenAPI против frontend snapshot. | backend, frontend | done | [`2026-08-23-make-local-verification-agent-safe`](../../specs/openspec/changes/archive/2026-08-23-make-local-verification-agent-safe/) | — | 2026-08-23; frontend `7a3048c`, backend `71d57d6`, specs `72444db`, docs `293df9c`; runtime и snapshot SHA-256 совпали, frontend `npm run openapi:check` — passed. |
-| WL-P2-10 | Актуализировать onboarding и постоянную документацию. | docs, frontend, backend, specs | done | [`2026-08-24-refresh-project-documentation-and-agent-entrypoints`](../../specs/openspec/changes/archive/2026-08-24-refresh-project-documentation-and-agent-entrypoints/) | — | 2026-08-24; frontend `be80ef2`, backend `fec542a`, specs `9f68ae5`, docs `88c0cd3`; OpenSpec/authority, link-path review и independent review passed. |
-| WL-P2-11 | Зафиксировать одинаковый local bootstrap frontend/backend. | frontend, backend, docs | done | [`2026-08-23-make-local-verification-agent-safe`](../../specs/openspec/changes/archive/2026-08-23-make-local-verification-agent-safe/) | — | 2026-08-23; frontend `7a3048c`, backend `71d57d6`, specs `72444db`, docs `293df9c`; Node 22 policy и `npm ci` guidance зафиксированы. |
-| WL-P2-12 | Проверить применимость high dependency advisories. | frontend, backend, specs, docs | done | [`2026-08-24-address-dependency-advisories-and-repo-hygiene`](../../specs/openspec/changes/archive/2026-08-24-address-dependency-advisories-and-repo-hygiene/) | — | 2026-08-24; frontend `826936c`, backend `6052565`, specs `8897bd9`, docs `60a1c33`; React Router обновлён, Prisma tooling risk принят с review trigger. |
-| WL-P2-13 | Дать одному agent workflow единый local verify interface. | frontend, backend, specs, docs | deferred | — | Вернуться после восстановления WL-P2-05 тем же Prisma trigger; затем выбрать минимальный общий interface. | 2026-08-23; полный общий verdict не может быть достоверно зелёным, пока обязательный backend e2e migration gate блокируется Prisma 7.9.1. |
-
-### P3
-
-| Audit ID | Цель | Репозитории | Статус | Связанный change | Следующее действие | Terminal evidence |
-| --- | --- | --- | --- | --- | --- | --- |
-| WL-P3-01 | Сделать unknown request fields явной ошибкой или документированной policy. | backend | planned | `tighten-backend-request-feedback` (ещё не создан) | Выбрать validation policy. | — |
-| WL-P3-02 | Устранить shared i18n import cycle. | frontend | done | [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) | — | 2026-08-24; frontend `1fc269a`, specs `2029519`, docs `fa5db07`; Node 22 `npm run verify` — passed. |
-| WL-P3-03 | Восстановить FSD public API boundary. | frontend | done | [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) | — | 2026-08-24; frontend `1fc269a`, specs `2029519`, docs `fa5db07`; dependency fixture gate — passed. |
-| WL-P3-04 | Исправить базовые language/loading accessibility semantics. | frontend | deferred | — | Пересмотреть при включении accessibility в MVP scope. | 2026-08-24; текущий local MVP scope не включает accessibility remediation. |
-| WL-P3-05 | Ввести пропорциональный bundle regression budget. | frontend | done | [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) | — | 2026-08-24; frontend `1fc269a`, specs `2029519`, docs `fa5db07`; initial JS payload 509,165 B ≤ 512,000 B. |
-| WL-P3-06 | Добавить coverage ratchet только как regression signal. | frontend | done | [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/) | — | 2026-08-24; frontend `1fc269a`, specs `2029519`, docs `fa5db07`; coverage 82.57/76.08/77.35/83.48% — passed. |
-| WL-P3-07 | Защитить рабочий `.env` от случайного commit. | frontend, specs, docs | done | [`2026-08-24-address-dependency-advisories-and-repo-hygiene`](../../specs/openspec/changes/archive/2026-08-24-address-dependency-advisories-and-repo-hygiene/) | — | 2026-08-24; frontend `826936c`, specs `8897bd9`, docs `60a1c33`; hygiene check passed. |
-| WL-P3-08 | Исключить runtime SQLite DB из Git. | backend, specs, docs | done | [`2026-08-24-address-dependency-advisories-and-repo-hygiene`](../../specs/openspec/changes/archive/2026-08-24-address-dependency-advisories-and-repo-hygiene/) | — | 2026-08-24; backend `6052565`, specs `8897bd9`, docs `60a1c33`; hygiene check passed. |
-
-### 2026-09-13 — WL-P2-11: переход на Node 24 LTS
-
-Продолжение bootstrap policy из WL-P2-11, части 14.backend/frontend/docs
-[рабочего TODO](../../todo/wealthledger-engineering-improvements.md).
-Node 24.21.0 / npm 11.19.0 выбран по [официальному каталогу релизов](https://nodejs.org/dist/index.json)
-и [расписанию поддержки](https://github.com/nodejs/Release#release-schedule):
-ветка Krypton LTS поддерживается до 30.04.2028.
-
-`.nvmrc` frontend/backend/docs фиксируют 24.21.0, engines — 24.x.
-Backend `@types/node` обновлён до 24.13.3; runtime dependencies не обновлялись.
-Npm дополнил backend lockfile платформенными optional dependencies существующего
-resolver. Для npm 11.19 явно разрешены install scripts сборочных зависимостей
-с pin версий. Инструкция переустановки и отката — в
-[локальном окружении](local-workspace.md#версия-node).
-Specs продолжает наследовать frontend runtime; самостоятельный bootstrap CLI
-из части 14.specs и CI остаются отдельными незавершёнными задачами.
-
-Проверки относятся к frontend `53c852b`, backend `ce24a84`, docs `c74c573`,
-specs `834f2d1` с текущим diff перехода Node:
-
- `npm ci` в frontend/backend/docs — PASS; backend native modules установлены
-  под Node 24, `npm run build` с генерацией Prisma client — PASS.
- Frontend `npm run verify` — PASS: 46 files, 268 tests, coverage, OpenAPI drift,
-  TypeScript, Biome, Knip, dependency boundaries, приложение и Storybook.
-  Прогон одновременно с установкой backend упирался в UI timeout; отдельный
-  повтор полного gate прошёл без изменения тестов или их таймаутов.
- Backend `npm run verify` — PASS: 35 suites, 257 tests, lint, оба typecheck и build.
- Backend `npm run test:e2e` — PASS: 8 suites, 98 tests; новая SQLite и штатные
-  migrations для каждой suite, включая runtime OpenAPI. Для HTTP-портов нужен
-  запуск вне sandbox. Рабочая БД не использовалась.
- Docs `npm run verify` — PASS: 54 Markdown-файла, 0 issues;
-  `git diff --check` во всех четырёх repos — PASS.
- OpenSpec CLI 1.10.0, существующая установка, исполненная Node 24.21.0:
-  `schema validate wealth-ledger-sdd --verbose` и
-  `validate --specs --strict --store wealth-ledger-specs` — PASS, 25 specs.
-
-## История registry
-
-Terminal evidence добавляется сюда только после завершения соответствующего change.
-
-### 2026-09-13 — WL-P2-05: воспроизводимый SQLite e2e
-
-Закрыты TODO 03 и 03.docs, повторно проверен SQLite scope 11. Backend
-`8637ad2` с текущим diff, Node 22.21.0 / Prisma 7.9.1. Schema, migrations,
-зависимости и HTTP-контракт не менялись.
-
- До исправления fresh migration: `RUST_LOG=warn` и `error` — exit 1 с пустым
-  `Schema engine error`; переменная отсутствует или равна `info` — exit 0.
-  В исходном окружении было `RUST_LOG=warn`. Это воспроизведённая зависимость
-  запуска от окружения, а не доказательство внутреннего дефекта Rust engine.
- Prisma config исключает унаследованный `RUST_LOG` после dotenv. Общий runner
-  даёт каждому suite свою DB и один URL для migration/Jest, отклоняет прямой
-  Jest без изоляции и очищает каталог после ошибки или сигнала.
- `npm run verify` — PASS: zero-warning lint, app/test types, 35 suites /
-  257 unit tests, Prisma generation и build.
- Docs `npm run verify` — PASS: Markdown, ссылки/якоря и `git diff --check`.
- `npm run test:e2e` — PASS: 8 suites / 98 tests, включая runtime OpenAPI.
- `node test/sqlite-regression.cjs` — PASS: три последовательных и два
-  параллельных полных e2e (каждый 98 tests, всего 40 разных DB); внешний
-  вымышленный файл неизменён. Недоступный schema engine возвращает exit 1;
-  SIGINT/SIGTERM — 130/143. Все 43 созданных DB-каталога удалены.
- `npm run test:durability -- /tmp/p111-baseline` — PASS: отдельная baseline
-  сборка `8ec172f48eefa2237dc0c16919fbb2e726b39a65`, additive migration,
-  сохранение User/Session/TbankConnection, банковской истории и защиты повторов,
-  restart, откат приложения и backup/restore. `RUST_LOG=info` удалён из runner;
-  для старого baseline унаследованная переменная также исключается.
- HTTP/durability проверены вне sandbox после воспроизведения запрета локальных
-  портов `EPERM`. Это ограничение среды, не failing migration. Пользовательская
-  DB и `.env` не использовались как цель записи.
-
-Логи этой проверки: `/tmp/wl-sqlite-verify.log`, `/tmp/wl-sqlite-e2e-1.log`,
-`/tmp/wl-sqlite-regression.log`, `/tmp/wl-sqlite-durability.log`.
-Подробные regression logs сохранены в системном temp-каталоге
-`wealthledger-sqlite-regression-pSyuoe`, durability —
-`wealthledger-bank-durability-V0u1NA`. Эти локальные временные логи могут быть
-удалены системой; воспроизводимые команды и
-[матрица рисков](../../backend/README.md#реальная-sqlite-и-сохранность-данных)
-остаются в backend. Исторические evidence ниже сохранены без переписывания.
-
-### 2026-09-13 — P1-12: backend responsibilities
-
-Статус: `done`. Backend commit `8ba0053`.
-
-BankCards разделён на services карт, операций и категорий, сценарий сводки и
-конкретный repository. Общая transaction/retry boundary, ownership, idempotency,
-optimistic concurrency и ограничения возвратов сохранены. Stock/bond services
-разделены по каталогу, рынку и доходам; связные operations и T-Bank client
-сохранены. Business modules отделены от integrations; сложные modules используют
-слои ответственности, компактные остаются плоскими.
-
- `npm run verify` — passed: lint, app/test typecheck, 35 suites / 257 tests, build.
- Восемь существующих HTTP/e2e suites выполнены временным runner
-  `/tmp/wl-modular-http.cjs`: отдельная SQLite DB на suite, migrations с
-  `RUST_LOG=info`, configured HTTP, 118 tests passed. OpenAPI совпадает с frontend
-  snapshot. Общий e2e blocker и статус задачи 03 этим не закрываются.
- Финальный перенос 47 файлов проверен сравнением 142 исходников/tests:
-  различий кроме относительных путей и форматирования нет.
- Formatter, docs `npm run verify`, lint backend conventions и `git diff --check`
-  прошли. Новые dependencies и architecture tests не добавлены.
-
-### 2026-09-13 — P1-11: реальная SQLite
-
-P1-11 поставлена в backend commit `7fde3ec`. Дополнено доказательство
-WL-P2-03; статус общего e2e WL-P2-05 не меняется. Команды и матрица рисков —
-[backend README](../../backend/README.md#реальная-sqlite-и-сохранность-данных).
-
- `npm run test:sqlite` — два последовательных успешных запуска после фиксации
-  loopback-listener: 8 auth и 21 карточный HTTP/SQLite test. Каждый suite получает
-  собственную временную DB; Prisma не мокируется. Барьер перед CAS гарантирует,
-  что оба refresh прочитали прежний hash; победившая сессия переживает replay.
- Существующие карточные tests покрывают owner links, idempotency/tombstones,
-  версии, конкурентные refund/archive/write, rollback source lock, атомарный
-  перевод, точные суммы и FK/unique constraints. Новая тестовая платформа не нужна.
- `npm run test:durability -- /tmp/p111-baseline` — PASS: migration, restart,
-  previous-app rollback, backup/restore и чтение сохранённой финансовой истории.
-  Baseline экспортирован из `8ec172f48eefa2237dc0c16919fbb2e726b39a65` и собран
-  отдельно. Его lockfile совпадает с текущим; при этой проверке переиспользованы
-  установленные node_modules. README также описывает независимый `npm ci`.
-  Runner проверяет наличие build и неизменённый префикс migration history.
- Node 22.21.0: `npm run verify` — PASS (35 suites, 257 unit tests, zero-warning
-  lint, оба typecheck, Prisma generate и build).
- Первые HTTP-запуски с автоматическим открытием/закрытием сервера Supertest
-  дали плавающий 404. Suites теперь держат один loopback-listener до `app.close()`;
-  повторные проверки прошли. Sandbox требует разрешения на локальный порт.
- Миграции выполнены с `RUST_LOG=info`. Это подтверждение выбранных DB-сценариев,
-  не снятие прежнего ограничения общего `test:e2e` и не выполнение задачи 03.
-
-### 2026-09-13 — WL-P2-06: strict TypeScript
-
-Поставка backend: commit `346a6f0` (`refactor: enforce strict backend typing`).
-
-По продолжению P1-10 в [общем tsconfig](../../backend/tsconfig.json) включён
-`strict: true` без отключения отдельных strict-проверок;
-`noFallthroughCasesInSwitch` сохранён отдельно. Убраны избыточные настройки,
-которые теперь включает `strict`.
-
-После замечания владельца вариант с definite-assignment `!` заменён:
-в 14 файлах 315 полей DTO объявлены через `declare`. Заполнение входных DTO
-принадлежит Nest/class-transformer, ответные DTO описывают возвращаемые объекты.
-`declare` не генерирует поля со значением `undefined` и не подменяет проверку
-входных данных. Optional/nullable-типы, декораторы и валидация сохранены.
-В [TbankClient](../../backend/src/integrations/tbank/tbank.client.ts)
-`getOpenAccounts` и `getDividends` задают тип результата на `call<Response>`,
-как соседние RPC; тип параметра `.then` выводится из этого результата.
-
-В [ESLint](../../backend/eslint.config.mjs) включён
-`@typescript-eslint/no-non-null-assertion: error`. Он не охватывает `field!: Type`,
-поэтому `no-restricted-syntax` отдельно запрещает definite-assignment `!`
-в свойствах и переменных. Устранены также 51 прежний non-null assertion и
-четыре definite-assignment assertions в тестах: используются сужение типов,
-локальные значения, типизированные результаты фильтрации и runtime assertions
-в тестах. Транзакции, проверки доступа, cache generation и денежная точность
-сохранены; отсутствующая категория в сводке приводит к явной внутренней ошибке.
-
-Проверено на Node 22.21.0, backend `3cf883e` с указанными изменениями:
-
- `npm run verify` — passed: lint без warnings, strict app/test typechecks,
-  35 Jest suites / 257 tests, Prisma generation и production build.
- `DATABASE_URL=file:/tmp/wealthledger-declared-dto-openapi-20260913.db npm run test:openapi-contract`
-  — passed, 1 test; frontend snapshot не менялся.
- TypeScript Compiler API подтвердил все strict options в app/test/build/dev
-  configs. Каждый config отклоняет шесть примеров: неинициализированное поле,
-  несовместимый callback, `null` вместо строки, implicit `any`/`this`, доступ
-  к `unknown` в `catch` (TS2564, TS2345, TS2322, TS7006, TS2683, TS18046).
- Проверка ESLint через `lintText` подтверждает ошибки для `value!`, `field!`
-  и `let value!`; декларация DTO без `!` разрешена.
- Новые тесты ValidationPipe проходят до и после замены деклараций:
-  обязательные credentials, нормализация email, вложенные money DTO и
-  обязательный version с optional-полями `PartialType`. Дополнены проверки
-  инструментов без UID; отдельный тест проверяет имя категории и ошибку
-  при нарушенной ссылке в банковской сводке.
- `NODE_ENV=development NODE_OPTIONS=--experimental-vm-modules npx jest --config test/jest-e2e.json --runInBand bank-cards.e2e-spec.ts`
-  с новой `DATABASE_URL=file:/tmp/bank-cards-*/test.db` — passed, 21 tests,
-  включая реальные миграции, валидацию HTTP, права владельца, возвраты,
-  транзакции и перезапуск. Runner использует `RUST_LOG=info` для миграций.
-  Первый прогон дал 19 passed / 2 timeout в сценариях возвратов и потребовал
-  остановки оставшегося Jest-процесса. Повтор на новой базе прошёл 21/21;
-  исходный `3cf883e` в отдельной копии с теми же dependencies также прошёл
-  21/21. Это не доказательство стабильности общего e2e gate.
- Полный `strict` проходит; 317 diagnostics из предыдущей оценки устранены.
-  Общий DB/e2e gate и ограничение WL-P2-05 остаются отдельной задачей.
-
-### 2026-09-13 — WL-P2-06: backend TypeScript
-
-Выполнен пункт P1-10 списка инженерных улучшений от 13.09.2026
-как продолжение существующего TypeScript gate. В [общем tsconfig](../../backend/tsconfig.json)
-включены `noImplicitAny`, `strictBindCallApply`, `noFallthroughCasesInSwitch`;
-app/test typechecks, production и dev build наследуют эти настройки.
-Исходный код, зависимости, unsafe-checks и публичный API не менялись.
-
-Проверено на Node 22.21.0, backend `3cf883e` с указанным изменением tsconfig:
-
- `npm run verify` до и после изменения — passed: zero-warning ESLint,
-  оба TypeScript gate, 33 Jest suites / 253 tests, Prisma generation и build.
- Проверка через TypeScript Compiler API с виртуальным ошибочным файлом для
-  каждого из четырёх configs — passed: implicit-any параметр даёт TS7006,
-  неверные аргументы `call`/`apply`/`bind` — TS2345/TS2322, проваливание `switch`
-  — TS7029. Контроль с выключенными тремя flags принимает тот же файл.
- `DATABASE_URL=file:/tmp/wealthledger-p1-10-openapi-20260913.db npm run test:openapi-contract`
-  — passed, 1 test; runtime OpenAPI совпал с frontend snapshot.
- `npx tsc --project tsconfig.typecheck.test.json --incremental false --strict --noImplicitAny --strictBindCallApply --noFallthroughCasesInSwitch --pretty false`
-  — оценка полного `strict`: 317 diagnostics, из них 315 TS2564 для полей DTO
-  и две TS2345 в `TbankClient.getOpenAccounts` / `getDividends` из-за callback
-  для `Promise<unknown>`. Полный `strict` пока не включён; это отдельный этап.
- Общий DB/e2e gate не запускался; WL-P2-05 сохраняет прежний статус.
-
-### 2026-08-26 — SDD26-01–SDD26-03, SDD26-09, SDD26-12, SDD26-17, SDD26-21, SDD26-28–SDD26-30: done
-
-Change синхронизирован в canonical specs и архивирован в [`2026-08-26-harden-openspec-sdd-quality`](../../specs/openspec/changes/archive/2026-08-26-harden-openspec-sdd-quality/).
-
- Delivery Map: frontend `N/A`, backend `N/A`, specs affected, docs affected; runtime OpenAPI contract gate `N/A`, потому что application runtime API и generated client не менялись.
- Затронутые Git-репозитории: specs `a8b2c4eed988f7e1a7b3d6b7188bbe6791f00e2a` (`feat: harden OpenSpec SDD workflow`), docs delivery `72c3a8a6683b95f7e734044fdabe568668097c33` (`docs: record SDD audit remediation`); terminal evidence фиксируется следующим docs commit.
- Pre-archive `bash specs/scripts/verify-workspace-change.sh harden-openspec-sdd-quality` под Node 22.21.0 — passed: Delivery Map verified frontend/backend `N/A`, specs/docs affected, runtime-openapi `N/A`; OpenSpec CLI 1.10.0 verified; planning coverage 9/9; schema valid; change valid; main specs 20/20; authority verified; docs `npm run verify` passed with 36 Markdown files and 0 issues.
- Controlled fixture suites: `bash specs/scripts/verify-agent-projection.test.sh` — passed at delivery time; follow-up cleanup later removed the projection layer. `bash specs/scripts/verify-openspec-authority.test.sh` — passed with expected controlled-negative failures.
- Archive: `openspec archive harden-openspec-sdd-quality -y --store wealth-ledger-specs` — updated `audit-remediation-workflow`, `engineering-change-governance`, `multi-repository-delivery` and `openspec-authority-and-lifecycle`; archived as `2026-08-26-harden-openspec-sdd-quality`.
- Post-archive verification: `openspec validate --specs --strict --store wealth-ledger-specs` — 20 passed, 0 failed; `bash specs/scripts/verify-openspec-authority.sh` — passed; `openspec schema validate wealth-ledger-sdd --verbose` — passed; `PATH=/Users/ksv741/.nvm/versions/node/v22.21.0/bin:$PATH npm run verify` in `docs` — passed.
- Semantic verification: Proposal, all 9 Delta Spec requirements, 28 scenarios, Design and 18/18 tasks matched implementation. Independent read-only review found no Critical or Important findings.
-
-### 2026-08-24 — AUD24-01, AUD24-03–AUD24-09, A-14–A-16, A-18: done
-
-Change синхронизирован в canonical specs и архивирован в [`2026-08-24-harden-agent-sdd-governance`](../../specs/openspec/changes/archive/2026-08-24-harden-agent-sdd-governance/).
-
- Delivery Map: frontend affected, backend affected, specs affected, docs affected; runtime OpenAPI contract gate required because frontend/backend contract verification pipelines changed. Workspace root `.opencode` projection and root `AGENTS.md` were updated locally; the workspace root is not a Git repository.
- Затронутые Git-репозитории: frontend `11be786943024699a4eccf91a8d1ad32a6d29e5f` (`chore: codify frontend local verification`), backend `2772d53647132e6119e411c6d18234db4301e541` (`chore: codify backend local verification`), specs `0006aea56207ad2192c678ced562feabf1a21c45` (`chore: harden SDD governance workflow`), docs delivery `1944f2fc970db2bdc292981e01b1aca549f9ac52` (`docs: record AI governance audit`); terminal evidence фиксируется следующим docs commit.
- `bash specs/scripts/verify-workspace-change.sh harden-agent-sdd-governance` под Node 22.21.0 — passed: Delivery Map verified for all four areas, OpenSpec CLI 1.10.0 verified, schema valid, change valid before archive, main specs 18/18 before sync, authority verified, frontend `npm run verify` passed (17 test files / 56 tests, coverage 82.57% statements / 76.08% branches / 77.35% functions / 83.48% lines, production build, initial JS 509,165 B), backend `npm run verify` passed (19 suites / 59 tests, build), docs `npm run verify` passed (34 Markdown files, 0 issues), runtime OpenAPI SHA-256 matched snapshot `96744da5f307b37ee3d9233b3259043425f65e49bcc60f78b46c585a78251db4`.
- После sync/archive `openspec validate --specs --strict --store wealth-ledger-specs` — 20 passed, 0 failed; `git diff --check` в frontend, backend, specs и docs — exit 0 before delivery commits.
- Semantic verification: Proposal, all 19 Delta Spec requirements, Design and 25/25 tasks matched implementation. Independent read-only re-review after fixes: Spec review 19/19, 0 Critical, 0 Important, 0 Minor semantic findings; Standards review final — no findings.
-
-### 2026-08-24 — WL-P3-02, WL-P3-03, WL-P3-05, WL-P3-06: done
-
-Change синхронизирован в canonical specs и архивирован в [`2026-08-24-tighten-frontend-quality-guardrails`](../../specs/openspec/changes/archive/2026-08-24-tighten-frontend-quality-guardrails/).
-
- Затронутые Git-репозитории: frontend `1fc269a` (`feat: enforce frontend quality guardrails`), specs `2029519` (`docs(specs): archive frontend quality guardrails`), docs `fa5db07` (`docs: activate frontend quality guardrails remediation`); terminal evidence фиксируется следующим docs commit.
- Frontend под Node 22.21.0: `npm run verify` — passed: OpenAPI and hygiene checks, strict TypeScript, Biome, 17 test files / 56 tests, coverage all committed `src` 82.57% statements / 76.08% branches / 77.35% functions / 83.48% lines, Knip, dependency gate с четырьмя fixtures, production build и bundle gate. Initial JavaScript payload — 509,165 B при budget 512,000 B; committed lazy baselines включают все dynamic route boundaries, включая `ProtectedLayout`.
- `openspec validate tighten-frontend-quality-guardrails --type change --strict --store wealth-ledger-specs` — passed до archive; после sync/archive `openspec validate --specs --strict --store wealth-ledger-specs` — 18 passed, 0 failed; `bash specs/scripts/verify-openspec-authority.sh` и `git diff --check` по затронутым repositories — passed.
- `opsx-verify` не установлен как shell executable; выполнена эквивалентная процедура из `.opencode/skills/openspec-verify-change/SKILL.md`: completeness 21/21 tasks, 3 requirements / 7 scenarios, correctness и coherence — без blocking findings. Independent read-only review нашёл три Important guardrail gaps; после fixes re-review — без Critical или Important findings.
- WL-P3-04 остаётся `planned` по явному решению owner: application accessibility semantics не входят в текущий MVP scope. Следующая единственная recommended задача — `tighten-backend-request-feedback` для WL-P3-01.
-
-### 2026-08-24 — WL-P2-12, WL-P3-07, WL-P3-08: done
-
-Change синхронизирован в canonical specs и архивирован в [`2026-08-24-address-dependency-advisories-and-repo-hygiene`](../../specs/openspec/changes/archive/2026-08-24-address-dependency-advisories-and-repo-hygiene/).
-
- Затронутые Git-репозитории: frontend `826936c` (`fix: harden frontend dependency and env hygiene`), backend `6052565` (`fix: harden backend runtime artifact hygiene`), specs `8897bd9` (`docs(specs): archive dependency hygiene remediation`), docs `60a1c33` (`docs: record dependency hygiene remediation evidence`).
- Frontend под Node 22: `npm run verify` — passed: OpenAPI check, hygiene check, strict TypeScript check, Biome, 17 test files / 55 tests, coverage, Knip, dependency check и production build. `npm audit --omit=dev` — 0 vulnerabilities; прямой `react-router` обновлён с 7.9.6 до 7.18.2 для GHSA-2w69-qvjg-hvjx.
- Backend под Node 22: `npm run hygiene:check`, `npm run lint`, `npm run typecheck:app`, `npm run typecheck:test` и `npm test -- --runInBand` — passed (19 suites, 59 tests). Runtime `dev.db` удалён из Git; intentional textual fixtures остаются versionable. `npm audit --omit=dev` всё ещё показывает три high по Prisma CLI path `prisma -> @prisma/config -> deepmerge-ts` для GHSA-ggr8-5vv4-36mx: public runtime path не найден, риск принят как tooling-only. Review trigger: совместимый stable Prisma release должен устранить `deepmerge-ts < 8.0.0`, либо появится доказуемый runtime call path.
- `npm run test:e2e` остаётся deferred по WL-P2-05: `prisma migrate deploy` на чистой temporary SQLite DB завершается пустым `Schema engine error` до Jest. Это не менялось данным change.
- `bash specs/scripts/verify-openspec-authority.sh` — passed; `openspec validate --specs --strict --store wealth-ledger-specs` — 17 passed, 0 failed; `git diff --check` по четырём репозиториям — passed. Эквивалентная `opsx-verify` процедура подтвердила 13/13 tasks, correctness и coherence. Независимый read-only review после исправлений — без Critical, Important или Minor findings.
-
-### 2026-08-24 — WL-P2-10: done
-
-Change синхронизирован в canonical specs и архивирован в [`2026-08-24-refresh-project-documentation-and-agent-entrypoints`](../../specs/openspec/changes/archive/2026-08-24-refresh-project-documentation-and-agent-entrypoints/).
-
- Затронутые Git-репозитории: frontend `be80ef2` (`docs: refresh frontend onboarding`), backend `fec542a` (`docs: refresh backend onboarding`), specs `9f68ae5` (`fix(specs): remove archived change duplicate` после archive commit `5b7bc0f`), docs `88c0cd3` (`docs: refresh project onboarding entrypoints`).
- `npm run verify` в frontend под Node 22 — passed: OpenAPI check, strict TypeScript check, Biome, 17 test files / 55 tests, coverage, Knip, dependency check и production build.
- Read-only link/path review — passed: 14 Markdown entrypoints без missing local links; `MVP.md` и `CONTEXT.md` удалены, а historical audit/archive references намеренно сохранены.
- `openspec validate --all --strict --store wealth-ledger-specs` — 16 passed, 0 failed; `bash specs/scripts/verify-openspec-authority.sh` — passed; `git diff --check` по затронутым путям — passed.
- Independent read-only standards/spec review выявил только Finder metadata и две неполные README links; metadata удалены, ссылки добавлены, re-review — passed. Эквивалентная `opsx-verify` процедура подтвердила completeness 16/16, correctness и coherence без blocking findings.
-
-### 2026-08-24 — WL-P2-04, WL-P2-07, WL-P2-08: done
-
-Change синхронизирован в canonical specs и архивирован в [`2026-08-24-align-api-contract-and-client-resilience`](../../specs/openspec/changes/archive/2026-08-24-align-api-contract-and-client-resilience/).
-
- Затронутые Git-репозитории: frontend `6d892da` (`fix: preserve cached data during refresh failures`), backend `9bd3400` (`fix: align auth success status contract`), specs `800450d` (`docs(specs): archive api contract resilience remediation`), docs `b91280c` (`docs: document auth and client refresh resilience`).
- Frontend под Node 22: `npm run verify` — passed: OpenAPI check, strict TypeScript check, Biome, 17 test files / 55 tests, coverage, Knip, dependency check и production build.
- Backend под Node 22: `npm run lint`, `npm run typecheck:app`, `npm run typecheck:test` и `npm test -- --runInBand` — passed (19 suites, 59 tests). `test:e2e` не запускался: WL-P2-05 остаётся deferred из-за Prisma migration gate.
- `bash specs/scripts/verify-runtime-openapi.sh` — passed: runtime и snapshot SHA-256 `96744da5f307b37ee3d9233b3259043425f65e49bcc60f78b46c585a78251db4` совпали. `openspec validate --specs --strict --store wealth-ledger-specs` — 16 passed, 0 failed; authority verifier и `git diff --check` — passed.
- `opsx-verify` выполнен эквивалентной процедурой из `.opencode/skills/openspec-verify-change/SKILL.md`: completeness 16/16 tasks, correctness и coherence — без blocking findings. Независимый read-only review не нашёл Critical, Important или Minor issues.
-
-### 2026-08-23 — WL-P2-01, WL-P2-02, WL-P2-03: done
-
-Change синхронизирован в main specs и архивирован в [`specs/openspec/changes/archive/2026-08-23-harden-auth-and-cache-concurrency`](../../specs/openspec/changes/archive/2026-08-23-harden-auth-and-cache-concurrency/).
-
- Затронутые Git-репозитории: backend `c77b3cf` (`fix: harden auth and cache concurrency`), specs `6e20cdf` (`docs(specs): archive auth and cache remediation`), docs `8568e7b` (`docs: record auth and cache concurrency policy`).
- Backend под Node 22: `npm run lint`, `npm run typecheck:app`, `npm run typecheck:test` и `npm test -- --runInBand` — passed (18 suites, 56 tests). `test:e2e` не запускался: WL-P2-05 остаётся deferred из-за Prisma migration gate.
- `openspec validate harden-auth-and-cache-concurrency --type change --strict --store wealth-ledger-specs` — passed до archive; после sync `openspec validate --specs --strict --store wealth-ledger-specs` — 15 passed, 0 failed; authority verifier и `git diff --check` — passed.
- `opsx-verify` не установлен как shell executable; выполнена эквивалентная процедура из `.opencode/skills/openspec-verify-change/SKILL.md`: completeness 12/12 tasks, correctness и coherence — без blocking findings. Independent read-only review не нашёл Critical/Important findings.
-
-### 2026-08-23 — WL-P1-05, WL-P2-06, WL-P2-09, WL-P2-11: done
-
-Change архивирован в [`specs/openspec/changes/archive/2026-08-23-make-local-verification-agent-safe`](../../specs/openspec/changes/archive/2026-08-23-make-local-verification-agent-safe/).
-
- Затронутые Git-репозитории: frontend `7a3048c` (`docs: document runtime OpenAPI verification`), backend `71d57d6` (`fix: make backend local verification safe`), specs `72444db` (`docs(specs): archive local verification remediation`), docs `293df9c` (`docs: document local verification workflow`).
- Backend под Node 22: `npm run lint`, `npm run typecheck:app`, `npm run typecheck:test` и `npm test -- --runInBand` — passed (17 suites, 51 tests).
- `npm run openapi:check` в frontend — passed; `bash specs/scripts/verify-runtime-openapi.sh` — runtime и snapshot SHA-256 совпали.
- `openspec validate make-local-verification-agent-safe --type change --strict --store wealth-ledger-specs` перед archive — passed; после sync `openspec validate --specs --strict --store wealth-ledger-specs` — 15 passed, 0 failed; authority verifier, `git diff --check` и independent read-only review — passed/no findings.
-
-### 2026-08-23 — WL-P2-05, WL-P2-13: deferred
-
-Под Node 22 `prisma migrate deploy` 7.9.1 несколько раз завершается пустым
-`Schema engine error` на новых SQLite DB до запуска Jest; при включении engine
-diagnostics результат меняется. `npm view prisma version` вернул ту же
-published stable версию 7.9.1. Поэтому не вводится параллельный migration runner
-и не создаётся общий workspace verdict с ложным зелёным статусом. Review trigger
-для обоих findings: следующая stable Prisma должна трижды подряд применить
-существующие migrations к чистой SQLite DB на Node 22.
-
-### 2026-08-23 — WL-P1-03, WL-P1-04: `harden-openspec-authority-and-lifecycle`
-
-Статус: `done`. Change синхронизирован в main specs и архивирован в [`specs/openspec/changes/archive/2026-08-23-harden-openspec-authority-and-lifecycle`](../../specs/openspec/changes/archive/2026-08-23-harden-openspec-authority-and-lifecycle/).
-
- Затронутые Git-репозитории: frontend `d870d53` (`docs: define canonical OpenSpec store`); backend `fee4f8c` (`docs: define canonical OpenSpec store`); specs `51344d4` (`docs(specs): harden OpenSpec authority lifecycle`); docs `0bc8d1c` (`docs: document OpenSpec authority lifecycle`).
- `bash specs/scripts/verify-openspec-authority.test.sh` — passed: positive fixture, второй OpenSpec root, implicit/conditional store selection, parenthesized invocation, archive override и framework planning location корректно отклоняются; `references/**` исключён.
- `bash specs/scripts/verify-openspec-authority.sh` из workspace root и всех четырёх независимых repositories — `OpenSpec authority verified: wealth-ledger-specs at specs/openspec`.
- `openspec validate harden-openspec-authority-and-lifecycle --type change --strict --store wealth-ledger-specs` — passed перед archive; `openspec validate --specs --strict --store wealth-ledger-specs` — 15 passed, 0 failed после sync/archive.
- `git diff --check` в frontend, backend, specs и docs — exit 0 перед commits; независимый read-only review scope — Critical/Important findings отсутствуют.
-
-### 2026-08-23 — WL-P1-01, WL-P1-02: `stabilize-frontend-query-and-strict-contracts`
-
-Статус: `done`. OpenSpec change синхронизирован в main specs и архивирован в [`specs/openspec/changes/archive/2026-08-23-stabilize-frontend-query-and-strict-contracts`](../../specs/openspec/changes/archive/2026-08-23-stabilize-frontend-query-and-strict-contracts/).
-
- Затронутые Git-репозитории: frontend commit `1250581` (`fix: stabilize frontend query cache contracts`); specs commit `b8a3f96` (`docs(specs): archive frontend query remediation`).
- `npm run verify` в `frontend` — passed: OpenAPI check, strict TypeScript check, Biome, 16 test files / 48 tests, coverage, Knip, dependency check и production build.
- `openspec validate stabilize-frontend-query-and-strict-contracts --type change --store wealth-ledger-specs` — `Change 'stabilize-frontend-query-and-strict-contracts' is valid` перед archive.
- `openspec validate --specs --store wealth-ledger-specs` — 14 specs passed, 0 failed перед archive.
- `git diff --check` для staged OpenSpec archive/sync changes — exit 0.
- Archive выполнен по явному разрешению владельца с одной незакрытой только административной задачей 4.2: она требует archive path и поэтому не могла быть закрыта до archive. Сразу после archive задача отмечена `[x]`; WL-P1-04 теперь `active` в `harden-openspec-authority-and-lifecycle`, чтобы убрать эту циклическую зависимость из будущего процесса.
-
-### 2026-08-23 — bootstrap verification: `establish-audit-remediation-workflow`
-
-Этот process change не закрывает Audit ID. Перед archive выполнены следующие read-only checks:
-
- `cmp -s audit-20-08-2026.md docs/audits/audit-20-08-2026.md` — exit 0; versioned snapshot byte-for-byte совпадает с исходной локальной копией.
- `openspec validate establish-audit-remediation-workflow --type change --store wealth-ledger-specs` — `Change ... is valid`.
- Структурная проверка registry — 26 records, 26 `planned`, 0 `active`, 0 `done`, одна «Следующая задача»; все четыре agent pointers и оба registry links разрешаются.
- `git diff --check` в frontend, backend, specs и docs — exit 0.
- Независимый read-only review registry-to-audit mapping, OpenSpec links, instruction discoverability и scope diff — `findings: none`.
- `opsx-verify` доступен как OpenCode command, но не установлен как shell executable в этой среде; выполнена эквивалентная процедура из `.opencode/skills/openspec-verify-change/SKILL.md` с теми же dimensions completeness, correctness и coherence.
- Change синхронизирован в main specs и архивирован в [`specs/openspec/changes/archive/2026-08-23-establish-audit-remediation-workflow`](../../specs/openspec/changes/archive/2026-08-23-establish-audit-remediation-workflow/).
@@ -1,88 +0,0 @@
-# Дизайн-система WealthLedger
-
-Приложение и UI-каталог используют одну визуальную основу: цветовые роли,
-типографику, интервалы, радиусы, тени и адаптивные размеры. Общая тема основана
-на Mantine; её значения не дублируются отдельно в каталоге.
-Поддерживается светлая схема, тёмная тема не заявлена.
-
-## Тема и токены
-
-Опубликованная система включает восемь палитр по десять оттенков: blue, gray,
-dark, red, green, yellow, grape и orange; базовые white/black, оттенки
-по умолчанию и семантические роли. Общая гарнитура применяется и к заголовкам,
-стандартный радиус — средний. Настройки являются доверенной локальной частью
-приложения; загрузка внешних или пользовательских токенов не предусмотрена.
-
-| Роль | Цветовая основа | Применение |
-| --- | --- | --- |
-| canvas | gray.2 | Фон приложения |
-| surface | white | Поверхности и формы |
-| subtle | gray.0 | Приглушённая поверхность |
-| text | dark.7 | Основной текст |
-| muted | gray.6 | Вторичный текст |
-| border | gray.3 | Граница поверхности |
-| primary | blue filled | Основное действие и активная навигация |
-| info | blue.6 | Информация |
-| positive | green.6 | Положительный результат с текстом или знаком |
-| negative | red.6 | Ошибка или отрицательный результат с текстом или знаком |
-| warning | yellow.6 | Предупреждение; не мелкий текст на белом |
-
-Цвет не заменяет подпись или знак. Палитра не гарантирует доступный контраст
-произвольного сочетания текста и фона. Дополнительные grape/orange и отдельные
-оформления карточек сохраняют предметный смысл соответствующего экрана;
-они не образуют универсальную финансовую классификацию всей системы.
-
-Общие шкалы основаны на принятых значениях приложения и Mantine 9.5.1.
-Обновление библиотеки не заменяет их автоматически. Масштабируемые размеры,
-тени и адаптивные границы требуют сохранения единиц и визуальной проверки.
-Отдельные градиенты, тени и размеры экранов остаются локальными визуальными
-решениями; переход всех существующих значений в общую шкалу не завершён.
-
-Точные значения определены в [токенах приложения](../../frontend/src/shared/theme/tokens.json),
-согласованное поведение — в [спецификации дизайн-системы](../../specs/openspec/specs/frontend-design-system/spec.md).
-Эта страница объясняет их смысл, не вводя отдельную систему значений.
-
-## Переносимый JSON
-
-Опубликованные токены представлены в собственном формате WealthLedger,
-версия 1. Это данные без исполняемого кода и зависимостей от runtime приложения.
-Совместимость с DTCG или импортом конкретного инструмента не заявлена.
-
-| Данные | Представление |
-| --- | --- |
-| Цвета | Hex, палитры оттенков 0–9 и именованные базовые цвета |
-| Семантические роли | Ссылка на цвет и оттенок, описание; отсутствие оттенка палитры означает основной оттенок светлой схемы |
-| Типографика | Наборы шрифтов, размеры в px, числовые веса и безразмерная высота строки |
-| Интервалы и радиусы | Именованные шкалы xs–xl в px и выбранный радиус по умолчанию |
-| Тени | Упорядоченные слои: смещения, размытие и растяжение в px, базовый цвет и непрозрачность |
-| Адаптивные границы | Именованные размеры xs–xl в em, независимые от масштаба интерфейса |
-
-Перенос в другую систему требует сопоставления единиц, шрифтов, слоёв теней
-и семантических ссылок. Само чтение JSON не обеспечивает такой совместимости.
-Несовместимое изменение формата требует новой версии; внешняя интеграция,
-генератор артефактов и публикация пакета пока не реализованы.
-
-## Общие компоненты
-
-| Представление | Поведение и ограничения |
-| --- | --- |
-| Пустой результат или ошибка | Заголовок, пояснение и необязательное действие; ошибка объявляется вспомогательным технологиям, кнопка имеет доступное название |
-| Загрузка | Доступная область состояния занятости с пояснением и декоративными фигурами без фокуса; структура отражает ожидаемый экран |
-| Действия | Основной, вторичный и вспомогательный варианты; состояния выполнения и недоступности |
-
-Общие представления не получают финансовые данные и не управляют
-аутентификацией. Состояние выполнения действия отличается от загрузки всей
-страницы. При фоновом обновлении доступные данные сохраняются с локальным
-индикатором; правила восстановления описаны в
-[UI resilience](../architecture/cross-cutting/ui-resilience.md).
-
-Каркас с продуктовой навигацией не входит в заявленный общий набор.
-Предметные карточки и композиции представлены в [UI-каталоге](ui-catalog.md).
-
-## Границы доказательств
-
-Каталог использует вымышленные данные и локальные действия без входа,
-сохранённого пользовательского состояния и application API. Проверки отделяют
-его от исполнения продуктовых запросов. Вид, размеры, фокус и взаимодействия
-проверяются в браузере; каталог не доказывает восстановление реального API
-или прохождение инвестиционного сценария.
@@ -1,82 +0,0 @@
-# Принципы изменения и проверки системы
-
-Ожидаемый результат определяется задачей пользователя. Сопровождение сохраняет
-ответственность подсистем, безопасность, точность данных и проверяемость результата.
-OpenSpec остаётся [необязательным средством согласования](openspec-authority-and-lifecycle.md);
-исторические свидетельства не становятся обязательной процедурой новой задачи.
-
-## Выбор реализации
-
-Связное поведение принадлежит ответственной подсистеме. Существующая возможность
-используется повторно, если сохраняет нужный смысл и инварианты. Новая граница
-оправдана самостоятельной ответственностью, общей потребностью нескольких
-потребителей либо необходимостью отделить доступ и целостность данных.
-
-Простота оценивается по ясности всей системы и стоимости сопровождения,
-а не по размеру изменения. Предполагаемая будущая возможность сама по себе
-не оправдывает новую подсистему. Упрощение сохраняет валидацию, доступность,
-обработку ошибок и защиту от потери данных.
-
-## Dependencies
-
-При выборе внешней зависимости учитываются текущая потребность, совместимость,
-поддержка, безопасность и стоимость сопровождения. Использование принятой
-платформы может быть проще собственной реализации; зависимость ради одной
-воображаемой будущей возможности не является самостоятельной потребностью.
-Новый сервис или общая инфраструктура должны решать актуальную задачу.
-
-## Risk-based testing
-
-Изменения безопасности и приватности, денежных расчётов, целостности данных,
-миграций, конкурентного доступа, публичного контракта, критического сценария
-и подтверждённой регрессии требуют автоматической проверки соответствующего
-риска на наблюдаемой потребителем границе.
-
-Статические проверки не доказывают финансовую или функциональную корректность.
-Покрытие frontend служит ограничителем регрессий; для backend общего числового
-порога нет. Проверки поведения библиотеки или проценты сами по себе не заменяют
-проверку собственного инварианта системы.
-
-## Проверка результата
-
-Результат оценивается по исходной задаче: сохранены ли смысл данных и контракты,
-правильно ли разграничен доступ, учтены ли ошибки и доступность интерфейса.
-При изменении HTTP-контракта backend обновляет публичный OpenAPI, а frontend
-проверяет соответствие generated types полученному snapshot согласно
-[OpenAPI contract flow](runtime-openapi-verification.md). Общего CI сейчас нет.
-
-Успешная проверка применима к тому состоянию системы и тем предпосылкам,
-на которых выполнена. При их изменении старое свидетельство не доказывает
-новый результат. Автоматическое исправление материалов и проверка без их
-изменения — разные действия.
-
-[Влияние на документацию](../CONTRIBUTING.md#обновление-вместе-с-кодом) входит
-в оценку результата: описанные понятия, сценарии, решения и ограничения
-обновляются вместе с системой. Отсутствие влияния может быть обоснованным
-результатом. Отчёт о поставке различает выполненное, проверенное и остающиеся
-ограничения; количество формальных отметок не заменяет смысловую проверку.
-
-## Guardrails и local gates
-
-Автоматические проверки гарантируют только свойства, охваченные их областью.
-Смысловые требования — например, правильный владелец данных, авторизация,
-локализация и полезность выбранных проверок — требуют отдельной оценки.
-Предпочтение между равноценными вариантами отличается от обязательного
-инварианта. Новая автоматизация оправдана реальным риском или повторяющимся
-дефектом; её наличие само по себе не является целью.
-
-## UI-решения
-
-Ожидаемые экраны, состояния, взаимодействия и поведение на разных размерах
-экрана определяются пользовательским сценарием. [Каталог](ui-catalog.md)
-и [дизайн-система](design-system.md) показывают существующую визуальную основу.
-Неоднозначный вариант можно оценить по конкретному примеру до реализации.
-Успешная сборка каталога не доказывает доступность и визуальное соответствие.
-
-## Изменение опасного контракта
-
-Для публичного контракта, безопасности, данных, платежей и труднообратимого
-изменения существенная неопределённость разрешается до применения решения.
-Для миграции важны условия отката, сохранность уже созданных данных и проверка
-восстановления. Порядок разрешения конфликтов знаний описан в
-[контексте системы](agent-token-efficiency.md#источники-и-конфликты).
@@ -1,131 +0,0 @@
-# Локальное окружение и восстановление
-
-WealthLedger поставляется как локальное приложение: frontend работает
-в браузере, backend обслуживает API и обращается к SQLite и внешним источникам.
-Это описание предпосылок и ограничений работы, без привязки к устройству
-исходного кода. Описано локальное окружение; production-топология по нему
-не подтверждается.
-
-## Версия Node
-
-Все локальные проверки используют Node 24 LTS; `.nvmrc` в frontend, backend
-и docs фиксирует 24.21.0. Specs использует frontend `.nvmrc`.
-По [официальному расписанию Node](https://github.com/nodejs/Release#release-schedule)
-поддержка Node 24 завершается 30.04.2028.
-В каждом npm-репозитории выполните `nvm install`, `nvm use --silent` и `npm ci`;
-в backend затем `npm run build` для генерации Prisma client.
-Поставляемый npm 11.19 запускает dependency install scripts только по
-`allowScripts` в package.json; разрешения привязаны к версиям сборочных
-зависимостей и пересматриваются при их обновлении.
-После смены major обязательна переустановка native modules через `npm ci`.
-Для отката верните прежние runtime/package/lockfile-конфигурации, выберите Node 22
-и повторите `npm ci` и backend build. Сам переход Node не меняет схему или данные.
-
-## Подготовка backend
-
-Локальная серверная среда использует Node 24 и SQLite. Для работы нужны:
-
-| Параметр | Назначение и ограничение |
-| --- | --- |
-| Адрес локальной базы | Одинаковая база используется при подготовке схемы и работе приложения; относительный адрес зависит от рабочей директории процесса |
-| Разрешённый origin frontend | Определяет browser-источник, которому разрешён доступ к API с credentials |
-| Порт API | По умолчанию 3000 |
-| Секрет подписи сессий | Секрет не короче 32 символов; отличается от ключа шифрования подключения |
-| Ключ шифрования подключения | 32 байта в base64; требуется для чтения сохранённого T-Bank token |
-| Параметры интеграции | Адрес T-Bank, лимит запросов и при необходимости доверенный CA; [ограничения](../integrations/tbank.md#конфигурация-и-ограничения) |
-
-T-Bank token вводится пользователем через интерфейс после входа и не является
-общим параметром окружения. Существующая база и её ключ шифрования сохраняются
-при обновлении. До миграции необходима резервная копия; восстановление проверяется
-на отдельной копии. Потеря или замена ключа не является безвредным сбросом:
-прежнее подключение нельзя расшифровать новым ключом.
-
-После подготовки зависимостей и конфигурации примените штатные migrations:
-из backend после `nvm use --silent` выполните `npx prisma migrate deploy`.
-Для существующей базы сначала сохраните согласованный backup.
-На Node 22.21.0 / Prisma 7.9.1 обнаружена зависимость fresh migration от
-унаследованного `RUST_LOG=warn/error`. Backend Prisma config исключает эту
-переменную из процесса CLI; назначать `RUST_LOG=info` больше не требуется.
-Условия и доказательство — в
-[сквозной проверке](verification.md#известное-ограничение-сквозной-проверки).
-
-В development доступна [локальная Swagger UI](http://localhost:3000/api/docs)
-при стандартном порте API. Она показывает контракт, но не доказывает доступность
-T-Bank и не используется frontend как источник данных во время работы.
-
-## Подготовка frontend
-
-Стандартные адреса: API `http://localhost:3000`, frontend `http://localhost:5173`.
-Адрес API в клиенте должен совпадать с работающим сервером, а разрешённый origin
-backend — с origin браузера. Смена порта требует согласованного изменения
-адресов. Смесь `localhost` и `127.0.0.1` меняет границу browser cookie и CORS.
-
-Локальный HTTP предполагает development-режим backend: в других режимах
-refresh-cookie получает Secure flag и требует защищённого соединения.
-Поведение сессии описано в [Authentication](../domains/authentication/overview.md).
-
-## Первый сценарий
-
-1. Пользователь регистрируется или входит. Новый профиль получает сессию;
-   после перезагрузки приложение пытается её восстановить.
-2. В настройках пользователь сохраняет собственный T-Bank Invest token.
-   Успех означает проверенный доступ к брокеру и сохранённое подключение.
-3. В разделе «Счета» доступны отдельный и общий портфель. Отсутствие доступных
-   счетов является допустимым пустым результатом.
-4. «Доходы» показывают полученные выплаты, «События» — будущие.
-5. При выходе локальная сессия и её клиентский кэш очищаются.
-
-Без T-Bank token доступны регистрация, вход, состояние отсутствующего
-подключения и [ручной банковский учёт](../domains/cards/overview.md).
-Банковский сценарий не подтверждает доступность инвестиционных поставщиков.
-
-## Сохранение данных и откат
-
-Перед обновлением сохраняется согласованный SQLite backup; ключ шифрования
-T-Bank хранится отдельно. Для работающей базы используется SQLite backup API,
-который учитывает WAL. Несогласованное копирование файлов базы и WAL не является
-резервной копией. Восстановление сначала проверяется на отдельном файле.
-
-Банковская миграция добавляет таблицы, сохраняя User, Session и TbankConnection.
-При необходимости отката приложения сначала прекращаются новые записи и
-сохраняется актуальный снимок. Затем возвращается совместимая предыдущая версия
-backend при сохранении расширенной схемы. Старый backup не восстанавливается
-поверх новой истории: это удалило бы введённые банковские операции.
-
-Совместимость проверена с исходной версией backend
-`8ec172f48eefa2237dc0c16919fbb2e726b39a65`: она выполняла вход с расширенной
-схемой, а новая версия после возврата читала прежние карты и операции.
-Отдельно проверены перезапуск, служебные данные защиты повторов и приложение
-на восстановленной SQLite-копии. Это подтверждение конкретной пары версий,
-а не гарантия совместимости любого будущего изменения схемы.
-
-Проверка воспроизводится через
-[процессный сценарий](../../backend/test/bank-cards-durability.cjs)
-с каталогом отдельно собранного baseline: после активации backend `.nvmrc`
-выполнить `node test/bank-cards-durability.cjs <baseline-directory>`.
-Сценарий создаёт собственные временные базы и вымышленные данные. Migrations
-и HTTP/DB-ограничения описаны в [проверке системы](verification.md).
-
-## Если запуск или сценарий не работает
-
-| Симптом | Проверка и безопасное восстановление |
-| --- | --- |
-| Порт занят | Адрес действующего процесса или выбранный свободный порт должен совпадать с настройками клиента и разрешённым origin |
-| Ошибка CORS или сессия теряется после reload | Согласованность адресов, hostname и режима cookie проверяется на стороне browser и backend |
-| Ошибка подготовки базы | Сохранить версию среды и текст ошибки; использовать backend Prisma config, не удалять пользовательскую базу и не обходить migrations |
-| `TBANK_NOT_CONNECTED` | Подключение создаётся в настройках текущего пользователя |
-| `INVALID_TBANK_TOKEN` | После проверки token и прав у брокера подключение заменяется через настройки |
-| `TBANK_UNAVAILABLE`, TLS или rate limit | Проверяются сеть, лимиты и доверенный CA; проверка TLS сохраняется |
-| НКР/MOEX недоступен при работающих остальных секциях | Состояние источника и повторная попытка относятся к конкретной секции; недоступность не означает отсутствия рейтинга |
-| Подключение не читается после смены ключа | Восстанавливается прежний ключ из защищённой копии; если он утрачен, собственный token вводится заново через настройки |
-
-HTTP-запросы связываются с безопасными журналами через `X-Request-ID`.
-Пароли, cookies, Authorization и broker token не включаются в диагностический
-отчёт. Ограничения журналирования — [ADR 008](../adr/008-pino-backend-logging.md).
-
-## Проверка первого изменения
-
-Успешная сборка, запуск и прохождение сценария — разные доказательства.
-Границы [проверок системы](verification.md) и
-[OpenAPI contract flow](runtime-openapi-verification.md) рассматриваются отдельно.
-Завершённость результата учитывает фактические проверки и остающиеся ограничения.
@@ -1,31 +0,0 @@
-# OpenSpec: роль требований и история процесса
-
-Обязательный SDD lifecycle отменён для обычной разработки согласно
-[ADR 012](../adr/012-task-driven-development-with-scoped-context.md).
-Задача пользователя определяет ожидаемый результат; дополнительные planning
-artifacts и архивирование не являются условием её завершения.
-
-## Существующие материалы
-
-Основные спецификации сохраняют согласованное проверяемое поведение, включая
-текущее. OpenSpec changes содержат предложения, их дизайн и задачи, архив —
-историю согласования. Store `wealth-ledger-specs` находится в `specs/openspec/`:
-основные спецификации — `specs/`, изменения — `changes/` внутри Store.
-[Предметный индекс](../../specs/AI_INDEX.md) ведёт к конкретным requirements/scenarios.
-
-Существующее описание изменения относится только к своему объёму и не доказывает
-готовность возможности. Docs объясняет систему и последствия правил;
-при расхождении со спецификацией нужно установить причину, а не объявлять
-реализацию или текст автоматически верным.
-
-## Если OpenSpec запрошен явно
-
-OpenSpec остаётся необязательным средством согласования требований, дизайна
-и задач. Его собственная модель определяет состав и порядок артефактов;
-подтверждение человеком и смысловая проверка результата не выводятся из
-одного наличия файлов. Обновление требований и архивирование меняют историю,
-поэтому относятся к явно выбранной работе с этой историей.
-
-Причины прежнего процесса и его упрощения сохранены в
-[ADR 010](../adr/010-native-openspec-sdd-and-local-orchestration.md) и
-[ADR 011](../adr/011-native-openspec-lifecycle-with-repository-gates.md).
@@ -1,46 +0,0 @@
-# OpenAPI contract flow
-
-## Назначение
-
-Backend остаётся источником HTTP-контракта и формирует OpenAPI из публичного
-API. Frontend принимает предоставленный `openapi.json` как актуальный вход,
-хранит его snapshot и генерирует из него transport types локально. Причины
-выбора backend-generated контракта описаны в
-[ADR 002](../adr/002-nest-generated-openapi-contract.md), отказ от frontend
-проверки backend runtime-схемы — в [ADR 014](../adr/014-trusted-openapi-input.md).
-
-Frontend не проверяет, что переданный snapshot совпадает с текущим backend
-runtime OpenAPI, не фиксирует пару frontend/backend SHA и не зависит от пути к
-соседнему backend checkout. Подготовка и доставка актуального OpenAPI-документа
-находятся вне frontend.
-
-## Выбор и направление изменения
-
-Изменением контракта считается изменение маршрута, входного или выходного поля,
-статуса либо формы ошибки. Внутреннее изменение представления без изменения
-API не требует нового описания контракта.
-
-Направление согласования: публичный API backend → предоставленный OpenAPI →
-frontend snapshot → generated types. Две независимо редактируемые версии
-контракта создавали бы риск расхождения. Перед изменением, влияющим на
-совместимость, учитываются существующие потребители и сохранность данных.
-Семантика запросов и ошибок описана в [HTTP API](../architecture/http-api.md).
-
-## Границы и результат
-
-Frontend-команда генерации читает только committed snapshot и обновляет
-generated types. Frontend-проверка генерирует types из этого snapshot во
-временный каталог и сравнивает результат с committed generated artifact.
-Несовпадение означает, что snapshot и generated types в frontend расходятся.
-
-Эта проверка не доказывает актуальность snapshot относительно backend. Это
-принятое допущение, а не свойство frontend gate. Она также не доказывает
-фактическую работу валидации, авторизации, статусов, cookie и обработки ошибок:
-для этого нужны наблюдения полного HTTP-потока.
-
-## Граница runtime
-
-Работающий frontend использует сгенерированные types и обычные HTTP-запросы к
-API. Swagger или OpenAPI endpoint не являются runtime-зависимостью SPA.
-Полные HTTP-сценарии и хранение данных проверяются отдельными backend-gates;
-локальный frontend gate выполняется без backend.
@@ -1,77 +0,0 @@
-# UI-каталог Storybook
-
-Storybook 10.6.0 показывает реальные представления WealthLedger на общей
-визуальной основе приложения без входа и подключения backend.
-
-## Запуск и сборка
-
-Каталог работает как отдельная локальная витрина по адресу
-[localhost:6006](http://localhost:6006) либо как самостоятельная статическая
-сборка. Его примеры не входят в пользовательские маршруты приложения.
-Публикация отдельным сервисом не настроена.
-
-## Компоненты и работа с примерами
-
-Каталог включает 14 групп и 54 примера:
-
-| Группа | Что показывает |
-| --- | --- |
-| Основы дизайн-системы | Палитры, семантические роли, типографику, интервалы, радиусы, тени и адаптивные размеры |
-| Пустой результат и ошибки | Четыре варианта с действием и без |
-| Загрузка | Доступную область занятости с нейтральными фигурами |
-| Кнопки | Основное, вторичное и вспомогательное действие, выполнение и недоступность, работу с клавиатурой |
-| Список счетов | Несколько счетов и валют, недоступную и пустую сводку, неоценённые бумаги, длинные названия и суммы |
-| Карточка позиции | Акцию с положительным результатом, облигацию с отрицательным, прочий инструмент и отсутствие оценки |
-| Ближайшие события | Успешный, загружаемый, ошибочный и пустой результат; неизвестную сумму и длинное название |
-| Обновление портфеля | Сохранённые суммы при обновлении и ошибке, локальную повторную попытку |
-| Загрузка страницы счёта | Контур ожидаемых заголовка, сводки и строк |
-| Структура портфеля | Валюты и типы активов, только деньги, пустую и неполную оценку, неизвестные и отрицательные значения |
-| Сводка банковских карт | Компактные расходы по категориям, отрицательный месяц возврата, известные нули, загрузку, ошибку, сохранённые суммы и длинные точные итоги |
-| Внешний вид банковской карты | Цвета банков, маскированный номер, платёжные системы, отсутствующие реквизиты и длинные названия в архиве |
-| Иконки банковских операций | Пиктограммы категорий расходов, общую иконку нестандартной категории и пополнение |
-| Поля банковской карты | Независимую рублёвую карту и недоступные финансовые поля архива |
-
-Каталог не перечисляет все элементы библиотеки или приложения. Отсутствие
-представления в витрине не означает его отсутствия в продукте. Основы показывают
-опубликованные шкалы и смысл ролей; особые размеры и тени конкретных экранов
-не объявляются общими токенами. Границы описаны в [дизайн-системе](design-system.md).
-
-Canvas показывает выбранный пример. Docs поясняет назначение и ограничения,
-Controls меняет доступные свойства, Actions показывает локальные действия.
-Наборы вымышленных данных и доступные Controls определяются конкретным
-примером; подготовленные варианты перечислены в историях. Свойства можно сбросить, пример —
-смонтировать заново; изменение размера просмотра не сбрасывает выбранные значения.
-
-Витрина и приложение используют одну тему. Примеры показываются по-русски
-в светлой схеме. Ошибка сохраняет доступное объявление, загрузка — состояние
-занятости; декоративные фигуры не получают фокус.
-
-## Границы и сопровождение
-
-Все счета, позиции, события и суммы вымышлены. Каталог не читает сессии,
-cookies, секреты и реальные пользовательские данные. Вместо внешних логотипов
-показываются буквенные заглушки. Сама витрина может сохранять свои настройки;
-телеметрия отключена.
-
-Действия не обращаются к application API. Ссылки меняют только локальное
-состояние примера, не открывают продуктовую страницу назначения и не меняют
-адрес приложения. Повторная попытка демонстрирует локальное действие и не
-доказывает восстановление реального запроса.
-
-Сохранённые суммы иллюстрируют Client Cached Snapshot, но его жизненный цикл
-здесь не исполняется. В приложении первичная загрузка показывает контур
-ожидаемого содержимого, фоновое обновление сохраняет данные, а выполняемое
-действие имеет контекстный индикатор. Подробности —
-[состояния интерфейса](../architecture/cross-cutting/ui-resilience.md).
-
-Автоматические проверки frontend охватывают каталог и его изоляцию от
-продуктовых запросов. Примеры и их пояснения обновляются вместе с включёнными
-представлениями. Клавиатура, реальные размеры и визуальное соответствие
-проверяются в браузере; автоматической визуальной регрессии нет.
-
-## Использование в UI задаче
-
-Каталог помогает сравнить существующие состояния с ожидаемым пользовательским
-сценарием. Он дополняет [принципы UI-решений](engineering-governance.md#ui-решения)
-конкретными примерами, но успешная сборка не доказывает доступность,
-визуальное соответствие и работу настоящего API.
@@ -1,66 +0,0 @@
-# Что подтверждают проверки системы
-
-Успешная сборка, запуск, равенство схем и прохождение пользовательского
-сценария — разные доказательства. Выбор проверки зависит от наблюдаемого
-риска: денежных вычислений, доступа, целостности данных или состояния интерфейса.
-Общие основания описаны в [принципах сопровождения](engineering-governance.md#risk-based-testing).
-
-## Интерфейс
-
-Локальный gate frontend охватывает типы, статический анализ, автоматические
-сценарии, зависимости и сборки приложения и UI-каталога. Он выполняется
-без запущенного backend. Покрытие ограничивает регрессии, но не доказывает
-правильность финансового расчёта, доступность и полный пользовательский сценарий.
-
-[Каталог](ui-catalog.md) показывает существующие визуальные решения на
-вымышленных данных. Широкий и узкий экран, клавиатурная навигация,
-восстановление после ошибок и соответствие задаче проверяются в интерфейсе
-отдельно от сборки. Изолированная тестовая среда не воспроизводит все свойства
-браузера и живой интеграции.
-
-## API и хранение данных
-
-Локальный gate backend объединяет статический анализ, типы приложения и тестов,
-автоматические сценарии и сборку. Он не исправляет исходные файлы;
-автоматическое форматирование выполняется отдельно и не является доказательством.
-Диагностика покрытия доступна без общего числового порога.
-
-Frontend OpenAPI check подтверждает только соответствие generated types
-сохранённому snapshot. Актуальность snapshot относительно backend принимается
-как входное допущение. Валидация, cookie, авторизация счёта, статусы и ошибки
-требуют полного HTTP-потока; целостность и конкурентные изменения данных —
-проверки с изолированной реальной базой. Подставной ответ базы не доказывает её
-транзакционные свойства. Направление генерации описано в
-[OpenAPI contract flow](runtime-openapi-verification.md).
-
-### Известное ограничение сквозной проверки
-
-Прежний blocker WL-P2-05 снят в конфигурации Prisma: на Node 22.21.0 /
-Prisma 7.9.1 унаследованный `RUST_LOG=warn` или `error` воспроизводит пустой
-`Schema engine error`, а отсутствие переменной позволяет fresh migration.
-Backend Prisma config удаляет переменную в процессе CLI после загрузки `.env`;
-это не меняет application logging. Версии зависимостей и SQL history сохранены.
-
-`npm run test:e2e` применяет migrations и запускает каждую HTTP suite на отдельной
-временной DB. Один URL передаётся Prisma и Jest; прямой запуск Jest без runner
-отклоняется до DB-запросов. При ошибке и SIGINT/SIGTERM выполняется cleanup.
-`npm run test:sqlite` выбирает auth/cards; `test:durability` отдельно проверяет
-migration, restart, возврат предыдущего приложения и backup/restore.
-Команды и runnable regression — в
-[backend README](../../backend/README.md#реальная-sqlite-и-сохранность-данных),
-фактические результаты — в
-[registry](audit-remediation.md#2026-09-13--wl-p2-05-воспроизводимый-sqlite-e2e).
-
-Backend `verify` остаётся статическим/unit/build gate; полный HTTP/DB scope
-проверяется отдельным `test:e2e`. Успех этих команд не подтверждает доступность
-внешнего T-Bank. HTTP tests требуют локальных портов, которые sandbox может
-запрещать. Безопасное сохранение реальных данных — в
-[локальном окружении](local-workspace.md).
-
-## Где выполнять проверки
-
-Команды и конкретные тестовые правила поддерживаются в локальных инструкциях
-[frontend](../../frontend/AGENTS.md) и [backend](../../backend/AGENTS.md).
-Проверки этой документации — в [CONTRIBUTING](../CONTRIBUTING.md#проверки).
-Отчёт различает пройденную границу, оставшееся ограничение и проверяемое состояние;
-успех одного gate не распространяется автоматически на весь workspace.
@@ -72,11 +72,11 @@ sequenceDiagram
 ## HTTP-граница

 Endpoints, статусы и формы публичных ответов определяет backend OpenAPI;
-согласование производного клиента описано в
-[contract workflow](../../development/runtime-openapi-verification.md).
+граница производного клиента описана в
+[HTTP API](../../architecture/http-api.md#источник-контракта).
 Refresh-cookie ограничена auth API. Признак Secure зависит от режима
-окружения: локальный HTTP предполагает development mode, см.
-[локальное окружение](../../development/local-workspace.md).
+окружения: в development допускается локальный HTTP, в остальных режимах
+Secure-cookie требует защищённого соединения.

 HTTP-ошибка и транспортная ошибка refresh одинаково завершают начальное
 восстановление готовым неавторизованным состоянием. При refresh после
@@ -136,10 +136,10 @@ JavaScript Number. Отдельный ввод ограничен signed64: на
 а форма сохраняет черновик и позволяет получить актуальную запись.
 При ошибке сохранения неподтверждённые суммы не выдаются за новый баланс.

-[Безопасное восстановление](../../development/local-workspace.md#сохранение-данных-и-откат)
+[Безопасное восстановление](../../architecture/containers.md#сохранение-и-восстановление-данных)
 сохраняет новую финансовую историю и при откате приложения. Устройство хранения
 описано в [контейнерах](../../architecture/containers.md#хранимые-данные-и-границы-доступа).
-Согласованный контракт этой поставки находится в
+Согласованный контракт банковского учёта находится в
 [manual-bank-cards](../../../specs/openspec/changes/add-manual-bank-cards/specs/manual-bank-cards/spec.md).
 Автоматическая загрузка банковских данных, кредитные карты, другие валюты,
 бюджеты и общий баланс банковских денег с инвестициями в эту версию не входят.
@@ -94,23 +94,6 @@ Frontend проверяет принадлежность выплат по по
 операций остаются отдельными строками; повторные вхождения учитываются раздельно, а изменение источника логотипа
 позволяет заново показать изображение после буквенной заглушки.

-## Совместимость ответа
-
-При обновлении с версии без `instrumentKey` сначала обновляется backend:
-дополнительное поле совместимо с прежним
-frontend. Затем синхронизируются OpenAPI snapshot/generated types и обновляется
-клиент. При переключении клиент перезагружается, чтобы не переносить
-старые результаты в памяти и незавершённые запросы. Новый frontend требует новый
-backend; отсутствие ключа принадлежности не скрывается подстановкой прежней формулы.
-
-При регрессии сначала возвращается прежний frontend вместе с соответствующим
-snapshot/types и перезагружается клиент; затем при необходимости возвращается
-backend. Старый frontend может временно работать с новым ответом с добавленным полем.
-Календарные фильтры и отдельные карточки выплат используют тот же контракт и не требуют
-дополнительного обновления backend. Схема SQLite, учётные данные и сообщённые брокером
-операции не меняются: откат
-не удаляет данные, производные результаты запрашиваются заново.
-
 ## Будущие события и ограничения

 На странице дохода нет блоков «Динамика» и «Ближайший прогноз». Она не запрашивает
@@ -146,10 +146,12 @@ Backend хранит token в шифротексте AES-256-GCM с новым n
 metadata. При перегруженной очереди необязательные имена могут быть заменены
 идентификаторами; это не доказывает потерю самой позиции. Изменение локального
 лимита требует учёта разрешённой квоты T-Bank: оно не увеличивает квоту
-поставщика. Диагностика соединения описана в
-[локальном окружении](../development/local-workspace.md).
+поставщика.

-Ключ шифрования не ротируется автоматически. Лимитер и кэши принадлежат
+Ключ шифрования не ротируется автоматически. Новый ключ не расшифрует
+прежнее подключение: нужен исходный ключ либо повторный ввод собственного
+token через настройки. Правила [резервного копирования](../architecture/containers.md#сохранение-и-восстановление-данных)
+учитывают отдельное хранение ключа. Лимитер и кэши принадлежат
 одному экземпляру; изменения подключения не координируются между
 распределёнными экземплярами backend. Интеграция использует сохранённый
 protobuf-контракт T-Bank: обновление внешнего протокола и проверка
@@ -1,16 +1,29 @@
 {
  "name": "wealth-ledger-docs",
-  "version": "1.0.0",
+  "version": "0.1.0",
  "private": true,
  "engines": {
-    "node": "24.x"
+    "node": "24.21.0"
  },
  "scripts": {
    "lint": "markdownlint-cli2 \"**/*.md\" \"#node_modules\"",
-    "verify": "npm run lint && git diff --check"
+    "verify": "npm run lint && git diff --check",
+    "release:preview": "release-it --dry-run --ci",
+    "release:prepare": "release-it --ci",
+    "commitlint": "commitlint"
  },
  "devDependencies": {
+    "@commitlint/cli": "21.2.2",
+    "@commitlint/config-conventional": "21.2.2",
+    "@release-it/conventional-changelog": "12.0.0",
+    "conventional-changelog-conventionalcommits": "10.4.0",
    "markdownlint-cli2": "0.23.2",
-    "markdownlint-rule-relative-links": "5.1.2"
+    "markdownlint-rule-relative-links": "5.1.2",
+    "release-it": "21.0.2"
+  },
+  "overrides": {
+    "markdownlint-cli2@0.23.2": {
+      "smol-toml": "1.8.0"
+    }
  }
 }
@@ -1,3 +1,31 @@
 {
-  "$schema": "https://docs.renovatebot.com/renovate-schema.json"
+  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
+  "extends": [
+    "config:recommended",
+    ":semanticCommitTypeAll(chore)"
+  ],
+  "timezone": "Europe/Moscow",
+  "labels": [
+    "dependencies"
+  ],
+  "dependencyDashboard": true,
+  "rangeStrategy": "pin",
+  "packageRules": [
+    {
+      "matchUpdateTypes": [
+        "minor",
+        "patch"
+      ],
+      "groupName": "non-major dependencies"
+    },
+    {
+      "matchUpdateTypes": [
+        "major"
+      ],
+      "dependencyDashboardApproval": true
+    }
+  ],
+  "baseBranchPatterns": [
+    "develop"
+  ]
 }
@@ -0,0 +1,10 @@
+const assert = require("node:assert/strict");
+const { execFileSync } = require("node:child_process");
+const { version } = require("../package.json");
+const git = (...args) => execFileSync("git", args, { encoding: "utf8" }).trim();
+
+assert.equal(git("status", "--porcelain"), "", "Commit all changes before preparing a release");
+const tags = git("tag", "--merged", "HEAD", "--list", "v[0-9]*", "--sort=-version:refname")
+  .split("\n").filter(tag => /^v\d+\.\d+\.\d+$/.test(tag));
+assert.equal(version, tags[0]?.slice(1) ?? "0.0.0",
+  "Version is already prepared or release tags are missing. Fetch tags; finish the existing release before preparing another.");
Author	SHA1	Message	Date
ksv741	c557af4ea5	chore(release): 0.1.0 Conventional commits / commits (pull_request) Successful in 13s Details Docs security / security (pull_request) Successful in 7s Details Docs verify / verify (pull_request) Successful in 14s Details Docs security / security (push) Successful in 8s Details Docs verify / verify (push) Successful in 16s Details	2026-09-14 07:12:03 +03:00
ksv741	261f1ca6d1	chore: configure releases and develop workflow	2026-09-14 07:10:19 +03:00
ksv741	9b19a5cf4d	docs: simplify system documentation Docs security / security (push) Successful in 7s Details Docs verify / verify (push) Successful in 9s Details	2026-09-14 05:51:29 +03:00
renovate-bot	67f152d365	chore(deps): update node.js to v24.21.0 Docs security / security (push) Successful in 7s Details Docs verify / verify (push) Successful in 11s Details Docs security / security (pull_request) Successful in 7s Details	2026-09-13 17:08:11 +00:00
ksv741	c0a8cdb683	ci: verify docs and secure dependency updates #1 #5 #6 Docs security / security (pull_request) Successful in 8s Details Docs security / security (push) Successful in 7s Details Docs verify / verify (push) Successful in 12s Details	2026-09-13 19:58:30 +03:00