docs: review document for #368

Issue: #368 User-Visible: no
docs: name the expected_rev requirement for external writers (#368 )
2026-09-29 11:18:48 +00:00 · 2026-08-29 09:36:29 +00:00 · 2026-08-29 12:29:33 +03:00
3007 changed files with 46372 additions and 367059 deletions
@@ -30,14 +30,20 @@ else
 fi

 status=0
-gate_status=0

-# Строки git читаются один раз: их нужно и локальному набору, и процессному гейту.
-refs=$(cat)
+# Локальный набор гейтов (#343). Выключен по умолчанию намеренно: 20-45 секунд на
+# каждый пуш, включая пуши одной строки документации, — цена, которую стоит
+# платить осознанно. Документация: docs/TESTING.md.
+if [ "${HP_PREPUSH_GATE:-}" = "1" ] && [ -f "$repo_root/scripts/pre-push-gate.mjs" ]; then
+  echo "pre-push-gate: HP_PREPUSH_GATE=1, прогоняю локальный набор" >&2
+  if ! node "$repo_root/scripts/pre-push-gate.mjs" >&2; then
+    status=1
+  fi
+fi

 while read -r local_ref local_sha remote_ref remote_sha; do
-  # An empty line (nothing on stdin) and deleting a remote branch push nothing to examine.
-  if [ -z "$local_sha" ] || [ "$local_sha" = "$zero" ]; then
+  # Deleting a remote branch pushes nothing to examine.
+  if [ "$local_sha" = "$zero" ]; then
    continue
  fi

@@ -65,25 +71,10 @@ while read -r local_ref local_sha remote_ref remote_sha; do
  if ! node "$gate" --range "${base}..${local_sha}" --target-ref "$remote_ref" $issues_flag >&2; then
    status=1
  fi
-done <<EOF
-$refs
-EOF
-
-# Локальный набор gate:small (#633, прежде opt-in #343) — после процессного
-# гейта: тот отвечает за секунды, а набор идёт минуты; прогоняются оба, чтобы
-# автор узнал обо всех провалах одним кругом. По умолчанию включён для
-# веток issue/* с исполняемым диффом; дифф только класса C/D (документы ревью,
-# changelog, бандл) и ветки вне issue/* его не запускают. Выключение — явное:
-# HP_PREPUSH_GATE=0; HP_PREPUSH_GATE=1 — прогнать для любой ветки. Документация:
-# docs/TESTING.md, docs/DEVELOPMENT.md «Локальный контур за 5 минут».
-if [ -f "$repo_root/scripts/pre-push-gate.mjs" ]; then
-  if ! printf '%s\n' "$refs" | node "$repo_root/scripts/pre-push-gate.mjs" --hook >&2; then
-    gate_status=1
-  fi
-fi
+done

 if [ "$status" -ne 0 ]; then
-  cat >&2 <<'MSG'
+  cat >&2 <<'EOF'

 Push остановлен: нарушен процесс (PROCESS.md §10.2).

@@ -93,12 +84,7 @@ Push остановлен: нарушен процесс (PROCESS.md §10.2).

 Обойти проверку можно через `git push --no-verify`, и тогда то же самое найдёт
 job `process-gate` в Validate — уже после того, как код окажется в dev.
-MSG
-fi
-
-if [ "$gate_status" -ne 0 ]; then
-  echo "Push остановлен: красный локальный набор gate:small (см. вывод выше)." >&2
-  exit 1
+EOF
 fi

 exit "$status"
@@ -1,357 +0,0 @@
-name: "Мутационный гейт · тело (#623)"
-
-# Реестр известных поломок (issue #85): каждый мутант ломает продуктовый код
-# известным способом, и объявленный тест ОБЯЗАН на этом покраснеть. Тест,
-# оставшийся зелёным на сломанном коде, ничего не защищает — он лишь выглядит
-# защитой, и это хуже его отсутствия.
-#
-# Прогон дорогой и проверяет не продукт, а тесты, поэтому он не входит ни в
-# Validate, ни в цикл разработки, ни в релизный гейт (#513, решение владельца
-# 09.09): каждую ночь по расписанию, отказ — issue с отчётом (#472).
-# Мутанты, задетые диффом, конвейер ревью и слияние гоняют отдельно на своём
-# кандидате (#510); кандидат беты, `full=true` и ночной Validate их не
-# запрашивают (#601) — ночью достаточно этого полного реестра.
-# Дешёвая половина — «якоря патчей живы, guard-файлы существуют» — идёт с
-# обычными юнитами: test/mutation-gate.test.mjs.
-#
-# #332: бандл собирается только мутантам с браузерным гвардом (guardNeedsBundle),
-# компиляция тестов в worktree стартует с тёплого test-build (инкрементальный
-# tsc), а реестр режется на четыре чересполосных шарда — полный прогон
-# укладывается в десятки минут вместо часов. Локальный дифф-режим:
-# node scripts/mutation-gate.mjs --changed origin/dev..HEAD
-#
-# #620: ночь по расписанию на дереве, уже доказанном зелёным полным прогоном
-# (тот же tree материала, тот же SHA workflow, маркер не старше недели), шарды не
-# гоняет — в сводке «reused from run N». Маркер пишет только зелёный агрегатор,
-# поэтому красный не переносится: следующая ночь гонит реестр заново и снова
-# заводит issue (#472). Ручной dispatch гонит полный реестр всегда. Решение —
-# чистая функция scripts/mutation-nightly-reuse.mjs.
-#
-# #623: «SHA workflow» — `job.workflow_sha`, SHA этого файла-тела. В вызываемом
-# workflow `github.workflow_sha` принадлежит вызывающему `mutation-gate.yml` из
-# main и не меняется вместе с телом, поэтому здесь он не используется.
-
-on:
-  # #623: тело вызывается тонким файлом `mutation-gate.yml` из ветки по умолчанию
-  # по ссылке `@dev`; триггеры, run-name и concurrency живут там.
-  workflow_call:
-    inputs:
-      ref:
-        description: "Git ref whose mutation guards must be proved"
-        required: false
-        type: string
-        default: dev
-
-permissions:
-  contents: read
-
-# Concurrency уровня workflow — у вызывающего `mutation-gate.yml` (#623).
-
-jobs:
-  # #549: moving ref разрешается ровно один раз. Все шарды ниже получают один
-  # commit/tree, а не самостоятельно читают dev в разное время.
-  material:
-    name: "Зафиксировать неизменяемый материал"
-    runs-on: ubuntu-24.04
-    timeout-minutes: 10
-    outputs:
-      sha: ${{ steps.identity.outputs.sha }}
-      tree: ${{ steps.identity.outputs.tree }}
-      ref: ${{ steps.identity.outputs.ref }}
-      reuse: ${{ steps.reuse.outputs.reuse }}
-      reused_run: ${{ steps.reuse.outputs.reused_run }}
-    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          ref: ${{ github.event_name == 'workflow_dispatch' && inputs.ref || 'dev' }}
-          fetch-depth: 0
-      - name: Зафиксировать commit и tree
-        id: identity
-        run: |
-          echo "sha=$(git rev-parse HEAD)" >> "$GITHUB_OUTPUT"
-          echo "tree=$(git rev-parse 'HEAD^{tree}')" >> "$GITHUB_OUTPUT"
-          echo "ref=${{ github.event_name == 'workflow_dispatch' && inputs.ref || 'dev' }}" >> "$GITHUB_OUTPUT"
-      # #620: самый свежий маркер зелёного прогона этого tree и этого workflow.
-      # Ключ уникален на прогон (кэш неизменяем), восстанавливается по префиксу —
-      # иначе перепроверка после недели не смогла бы освежить маркер.
-      - name: Маркер зелёного прогона этого дерева
-        if: github.event_name == 'schedule'
-        uses: actions/cache/restore@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6
-        with:
-          path: artifacts/mutation-green
-          key: mutation-green-v1-${{ steps.identity.outputs.tree }}-${{ job.workflow_sha }}-${{ github.run_id }}
-          restore-keys: |
-            mutation-green-v1-${{ steps.identity.outputs.tree }}-${{ job.workflow_sha }}-
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with:
-          node-version: 22
-      # Любой сбой решения — полный прогон: пропуск должен быть доказан, а не
-      # выведен из ошибки. Материал без скрипта (dispatch старого ref) — тоже.
-      - name: Нужен ли прогон
-        id: reuse
-        env:
-          EVENT_NAME: ${{ github.event_name }}
-          TREE: ${{ steps.identity.outputs.tree }}
-          WORKFLOW_SHA: ${{ job.workflow_sha }}
-          RUN_URL_BASE: ${{ github.server_url }}/${{ github.repository }}/actions/runs
-        run: |
-          decision="$RUNNER_TEMP/mutation-reuse.txt"
-          if [ -f scripts/mutation-nightly-reuse.mjs ] && node scripts/mutation-nightly-reuse.mjs --decide \
-               --event="$EVENT_NAME" --tree="$TREE" --workflow-sha="$WORKFLOW_SHA" \
-               --marker=artifacts/mutation-green/marker.json \
-               --summary="$GITHUB_STEP_SUMMARY" --run-url-base="$RUN_URL_BASE" > "$decision"; then
-            cat "$decision" >> "$GITHUB_OUTPUT"
-            if grep -qx 'reuse=true' "$decision"; then
-              echo "::notice::reused from run $(sed -n 's/^reused_run=//p' "$decision")"
-            fi
-          else
-            echo "::warning::решение о повторном использовании не получено — полный прогон"
-            echo "reuse=false" >> "$GITHUB_OUTPUT"
-          fi
-
-  mutants:
-    name: "Мутанты: каждый обязан красить тесты (шард ${{ matrix.shard }} из 6)"
-    needs: material
-    if: needs.material.outputs.reuse != 'true'
-    runs-on: ubuntu-24.04
-    strategy:
-      fail-fast: false
-      matrix:
-        shard: [1, 2, 3, 4, 5, 6]
-    # Шесть чересполосных шардов (#604): при четырёх шард нёс ~203 мутанта из
-    # 810 и рос с реестром — 42 мин 10.09, 57 мин 20.09, 61 мин 21.09, и шард
-    # 2/4 был снят по потолку без единого FAIL. Делитель тот же, что у
-    # `changed_mutants` в Validate; число шардов повторяется в `--shard=i/6`,
-    # `--shards=6` и имени job — тест `mutation-gate.test.mjs` держит их
-    # равными. Бандл собирают только браузерные гварды. Час — потолок против
-    # зависшего Chromium, а не бюджет шарда: шард, упёршийся в него, — сигнал
-    # снова делить, и отчёт (#472) называет такой шард прерванным, не «ok».
-    timeout-minutes: 60
-    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          ref: ${{ needs.material.outputs.sha }}
-          fetch-depth: 0
-
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with:
-          node-version: 22
-          cache: npm
-
-      - run: npm ci
-
-      - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7
-        with:
-          python-version: '3.14'
-
-      - name: Установить backend test dependencies
-        run: |
-          # Точные версии — в tests_backend/requirements.txt (#392): без них
-          # резолвер выбирает набор сам, и «зелёный backend» значит разное
-          # в разные дни.
-          pip install -r tests_backend/requirements.txt
-          pip list --format=columns | grep -Ei 'homeassistant|voluptuous|^pytest '
-
-      - name: Кэш браузеров Playwright
-        id: pw
-        uses: actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6
-        with:
-          path: ~/.cache/ms-playwright
-          key: playwright-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
-
-      - name: Установить Chromium
-        if: steps.pw.outputs.cache-hit != 'true'
-        run: npx playwright install --with-deps chromium
-
-      - name: Реестр применим к текущему коду
-        run: node scripts/mutation-gate.mjs --check
-
-      - name: Тёплый test-build для инкрементальной компиляции мутантов
-        run: npx tsc -p tsconfig.test.json && node scripts/fix-test-build.mjs
-
-      # Вывод шарда сохраняется артефактом (#472): строки
-      # `FAIL <id>: тест остался зелёным…` — единственное место, где названо,
-      # ЧТО сбежало. Без артефакта отказ безымянный. `PIPESTATUS` — чтобы
-      # `tee` не съел код выхода раннера.
-      - name: Каждый тест ловит свою поломку
-        id: gate
-        run: |
-          mkdir -p artifacts/mutation-shard-${{ matrix.shard }}
-          set -o pipefail
-          node scripts/mutation-gate.mjs --shard=${{ matrix.shard }}/6 2>&1 | tee artifacts/mutation-shard-${{ matrix.shard }}/mutation-shard-${{ matrix.shard }}.log
-      # Исход шага едет в evidence (#604): снятый по timeout-minutes шаг даёт
-      # `cancelled`, и агрегатор отвергает такой шард как неполный — лог без
-      # строк FAIL сам по себе зелёным не считается.
-      - name: Записать identity шарда
-        if: always()
-        run: |
-          node scripts/mutation-gate-report.mjs \
-            --write-evidence=artifacts/mutation-shard-${{ matrix.shard }}/evidence.json \
-            --sha=${{ needs.material.outputs.sha }} \
-            --tree=${{ needs.material.outputs.tree }} \
-            --workflow-sha=${{ job.workflow_sha }} \
-            --run-id=${{ github.run_id }} --run-attempt=${{ github.run_attempt }} \
-            --shard=${{ matrix.shard }} --shards=6 \
-            --outcome=${{ steps.gate.outcome }}
-      - name: Сохранить лог и identity шарда
-        if: always()
-        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
-        with:
-          name: mutation-shard-${{ matrix.shard }}-attempt-${{ github.run_attempt }}
-          path: artifacts/mutation-shard-${{ matrix.shard }}
-          if-no-files-found: warn
-          retention-days: 30
-
-  # Результат нельзя приписывать material, пока не доказаны все шесть шардов —
-  # каждый с identity и с дошедшим до конца прогоном (#549, #604).
-  # always() нужен при красном мутанте: лог красного шарда всё равно evidence.
-  evidence:
-    name: "Доказать единый material всех шардов"
-    needs: [material, mutants]
-    if: always() && needs.material.outputs.reuse != 'true'
-    runs-on: ubuntu-24.04
-    timeout-minutes: 10
-    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          # CLI отчётчика принадлежит зафиксированному material. В main лежит
-          # только workflow и может не быть dev-версии scripts/**.
-          ref: ${{ needs.material.outputs.sha }}
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with:
-          node-version: 22
-      - name: Забрать evidence всех попыток
-        uses: actions/download-artifact@37930b1c2abaa49bbe596cd826c3c89aef350131 # v7
-        with:
-          pattern: mutation-shard-*
-          path: artifacts/mutation-logs
-      - name: Проверить полноту и identity
-        run: |
-          node scripts/mutation-gate-report.mjs --verify-only \
-            --logs=artifacts/mutation-logs --shards=6 \
-            --sha=${{ needs.material.outputs.sha }} \
-            --tree=${{ needs.material.outputs.tree }} \
-            --workflow-sha=${{ job.workflow_sha }} \
-            --run-id=${{ github.run_id }} --run-attempt=${{ github.run_attempt }}
-
-  # #620: маркер пишется ТОЛЬКО после зелёного агрегатора — все шесть шардов
-  # доказаны на одном material. Красный или неполный прогон маркера не оставляет,
-  # и следующая ночь гонит реестр заново.
-  green_marker:
-    name: "Записать маркер зелёного прогона"
-    needs: [material, mutants, evidence]
-    if: needs.material.outputs.reuse != 'true' && needs.mutants.result == 'success' && needs.evidence.result == 'success'
-    runs-on: ubuntu-24.04
-    timeout-minutes: 10
-    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          ref: ${{ needs.material.outputs.sha }}
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with:
-          node-version: 22
-      - name: Маркер
-        run: |
-          node scripts/mutation-nightly-reuse.mjs \
-            --write-marker=artifacts/mutation-green/marker.json \
-            --tree=${{ needs.material.outputs.tree }} \
-            --sha=${{ needs.material.outputs.sha }} \
-            --workflow-sha=${{ job.workflow_sha }} \
-            --run-id=${{ github.run_id }} --run-attempt=${{ github.run_attempt }} \
-            --event=${{ github.event_name }}
-      - name: Сохранить маркер
-        uses: actions/cache/save@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6
-        with:
-          path: artifacts/mutation-green
-          key: mutation-green-v1-${{ needs.material.outputs.tree }}-${{ job.workflow_sha }}-${{ github.run_id }}
-
-  # Адресат у отказа (#472). Только по расписанию: ручной dispatch остаётся
-  # для отладки самого гейта, его результат смотрят в прогоне — issue на
-  # каждый такой отказ был бы шумом, который снова перестанут читать.
-  #
-  # Права job-уровня ЗАМЕНЯЮТ права workflow, а не дополняют (прецедент —
-  # validate.yml, job с actions: read): перечислены все три.
-  report:
-    name: "Отказ расписания: issue и Telegram"
-    needs: [material, mutants, evidence]
-    # #620: ночь, принявшая доказательство прошлого зелёного прогона, отказом не
-    # является — её шарды пропущены намеренно. Любой другой пропуск шардов
-    # (упал material) по-прежнему заводит issue.
-    if: always() && github.event_name == 'schedule' && needs.material.outputs.reuse != 'true' && (needs.mutants.result != 'success' || needs.evidence.result != 'success')
-    runs-on: ubuntu-24.04
-    timeout-minutes: 10
-    permissions:
-      contents: read
-      actions: read
-      issues: write
-    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          # Не перечитываем moving dev: код отчётчика берётся из уже
-          # зафиксированного material. В стабильном main dev-скриптов нет.
-          ref: ${{ needs.material.outputs.sha }}
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with:
-          node-version: 22
-      - name: Забрать логи шардов
-        continue-on-error: true
-        uses: actions/download-artifact@37930b1c2abaa49bbe596cd826c3c89aef350131 # v7
-        with:
-          pattern: mutation-shard-*
-          path: artifacts/mutation-logs
-      - name: Собрать отчёт
-        id: report
-        env:
-          RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
-        run: |
-          mkdir -p artifacts
-          node scripts/mutation-gate-report.mjs \
-            --require-evidence --logs=artifacts/mutation-logs --shards=6 \
-            --sha=${{ needs.material.outputs.sha }} \
-            --tree=${{ needs.material.outputs.tree }} \
-            --workflow-sha=${{ job.workflow_sha }} \
-            --run-id=${{ github.run_id }} --run-attempt=${{ github.run_attempt }} \
-            --run-url="$RUN_URL" --ref=${{ needs.material.outputs.ref }} \
-            --body-out=artifacts/mutation-report.md \
-            --telegram-out=artifacts/mutation-telegram.txt >> "$GITHUB_OUTPUT"
-      # Одно issue, а не одно на неделю: открытое с тем же маркером в заголовке
-      # получает комментарий, новое заводится только если открытого нет.
-      - name: Issue — создать или дописать
-        id: issue
-        env:
-          GH_TOKEN: ${{ github.token }}
-          REPO: ${{ github.repository }}
-          MARKER: ${{ steps.report.outputs.marker }}
-          TITLE: ${{ steps.report.outputs.title }}
-        run: |
-          existing=$(gh issue list --repo "$REPO" --state open --search "\"$MARKER\" in:title" \
-            --json number,title --jq '[.[] | select(.title | startswith(env.MARKER))][0].number // empty')
-          if [ -n "$existing" ]; then
-            gh issue comment "$existing" --repo "$REPO" --body-file artifacts/mutation-report.md
-            url="${{ github.server_url }}/$REPO/issues/$existing"
-          else
-            url=$(gh issue create --repo "$REPO" --title "$TITLE" \
-              --label infra --label process --label tests \
-              --body-file artifacts/mutation-report.md)
-          fi
-          echo "url=$url" >> "$GITHUB_OUTPUT"
-          echo "issue: $url"
-      # Тот же канал, что у релизов (announce.yml). Нет секретов — не отказ:
-      # issue уже заведено, а Telegram — второй адресат, не единственный.
-      - name: Telegram
-        if: always() && steps.issue.outcome == 'success'
-        env:
-          TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
-          CHAT: ${{ secrets.TELEGRAM_CHAT_ID }}
-          ISSUE_URL: ${{ steps.issue.outputs.url }}
-        run: |
-          if [ -z "$TOKEN" ] || [ -z "$CHAT" ]; then
-            echo "::warning::TELEGRAM_BOT_TOKEN/TELEGRAM_CHAT_ID не заданы — оповещение пропущено, issue заведено"
-            exit 0
-          fi
-          TEXT=$(sed "s|(issue)|$ISSUE_URL|" artifacts/mutation-telegram.txt)
-          curl -sS --fail-with-body -X POST \
-            "https://api.telegram.org/bot$TOKEN/sendMessage" \
-            --data-urlencode "chat_id=$CHAT" \
-            --data-urlencode "text=$TEXT" \
-            -d disable_web_page_preview=true
@@ -1,84 +0,0 @@
-# Ночной полный прогон (#479).
-#
-# Тяжёлые job Validate — смоки, golden, performance_smoke — на обычном пуше не
-# идут: они ни разу не ловили дефект в момент ревью и стоили ~6 минут
-# критического пути на каждую итерацию. Полный набор идёт на кандидате беты
-# (трейлер `Release:`), по кнопке и здесь — каждую ночь на голове `dev`.
-#
-# Почему не `schedule` прямо в validate.yml: расписание исполняется на ветке
-# по умолчанию (`main`), а проверять надо `dev`. Один dispatch с `--ref dev`
-# делает это без переписывания checkout во всех job. Reuse (#208) сохраняется:
-# при неизменённом дереве ночной прогон обойдётся маркерами.
-#
-# Красный ночной прогон — сигнал автору последних коммитов на dev, не гейт:
-# гейт беты по-прежнему требует зелёный Validate на точном SHA кандидата, и
-# там полный набор идёт заново.
-#
-# Сигнал обязан быть настоящим (#492 §7): до этой задачи job завершалась
-# успехом в момент постановки Validate в очередь, и красный полный прогон не
-# делал ночной workflow красным. Теперь job находит запущенный прогон и ждёт
-# его: успешный dispatch — не успешная проверка.
-name: "Ночной полный прогон dev · тело (#623)"
-
-on:
-  # #623: тело вызывается тонким файлом `nightly.yml` из ветки по умолчанию
-  # по ссылке `@dev`; триггеры, run-name и concurrency живут там.
-  workflow_call:
-
-permissions:
-  actions: write
-  contents: read
-
-jobs:
-  dispatch:
-    name: "Запустить Validate на dev с полным набором и дождаться результата"
-    runs-on: ubuntu-24.04
-    timeout-minutes: 90
-    steps:
-      # #658: при плане 02:30 UTC ночь фактически стартовала в 07:42–08:05 и
-      # кончалась в рабочее время владельца. Сдвиг старта больше часа — видимое
-      # предупреждение, а не молча съеденная ночь. `github.event.schedule` —
-      # строка cron вызывающего `nightly.yml`; NOW_EPOCH подставляет только тест.
-      - name: "Сдвиг старта ночи против расписания"
-        if: github.event_name == 'schedule'
-        env:
-          SCHEDULE: ${{ github.event.schedule }}
-        run: |
-          set -euo pipefail
-          read -r minute hour _ <<< "$SCHEDULE"
-          now=${NOW_EPOCH:-$(date -u +%s)}
-          planned=$(date -u -d "@$now" +%F)
-          planned=$(date -u -d "$planned $hour:$minute" +%s)
-          [ "$planned" -le "$now" ] || planned=$((planned - 86400))
-          lag=$(( (now - planned) / 60 ))
-          echo "- Старт по расписанию \`$SCHEDULE\` (UTC): сдвиг $lag мин" >> "$GITHUB_STEP_SUMMARY"
-          if [ "$lag" -gt 60 ]; then
-            echo "::warning::ночной прогон стартовал на $lag мин позже расписания ($SCHEDULE UTC) — очередь расписаний GitHub (#658)"
-          fi
-      - env:
-          GH_TOKEN: ${{ github.token }}
-          REPO: ${{ github.repository }}
-        run: |
-          set -euo pipefail
-          since=$(date -u +%FT%TZ)
-          gh workflow run validate.yml --repo "$REPO" --ref dev -f full=true
-          echo "Validate(dev, full=true) поставлен в очередь: $since"
-          # Найти именно этот прогон: workflow_dispatch на dev, созданный не
-          # раньше момента запуска. До трёх минут на появление в списке.
-          run_id=""
-          for _ in $(seq 1 18); do
-            sleep 10
-            run_id=$(gh run list --repo "$REPO" --workflow validate.yml --branch dev \
-              --event workflow_dispatch --json databaseId,createdAt --limit 5 \
-              --jq "[.[] | select(.createdAt >= \"$since\")] | sort_by(.createdAt) | last | .databaseId // empty")
-            [ -n "$run_id" ] && break
-          done
-          if [ -z "$run_id" ]; then
-            echo "::error::прогон Validate не появился за 3 минуты — dispatch не равен проверке"
-            exit 1
-          fi
-          url="${{ github.server_url }}/$REPO/actions/runs/$run_id"
-          echo "дочерний прогон: $url"
-          echo "- Validate(dev, full=true): $url" >> "$GITHUB_STEP_SUMMARY"
-          # Ждём завершения; красный дочерний прогон — красный ночной.
-          gh run watch "$run_id" --repo "$REPO" --exit-status --interval 30
@@ -1,59 +0,0 @@
-name: "Метрики процесса · тело (#623)"
-
-# #637: еженедельный замер вместо ощущений — lead time S→S7→S8, раунды ревью,
-# прогоны Validate по исходам, минуты конвейера в S4/S7. Только чтение: отчёт
-# идёт в step summary и артефакт; в issue и репозиторий ничего не пишется.
-# Цифры аудита 22.09 (1,57 раунда код-ревью, S7 ≈ 36 мин/раунд, 226 Validate
-# за неделю) были собраны руками за час — теперь они стоят один запуск.
-
-on:
-  # #623: тело вызывается тонким файлом `process-metrics.yml` из ветки по умолчанию
-  # по ссылке `@dev`; триггеры, run-name и concurrency живут там.
-  workflow_call:
-    inputs:
-      days:
-        description: "Окно в днях"
-        required: false
-        type: string
-        default: "7"
-
-permissions:
-  contents: read
-  actions: read
-  issues: read
-
-jobs:
-  metrics:
-    name: "Снимок недели: issue, раунды, прогоны"
-    runs-on: ubuntu-24.04
-    timeout-minutes: 15
-    steps:
-      # Код — из dev, как у reconcile: расписание читается из main, а исполняется
-      # версия, которую проверил CI.
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          ref: dev
-          fetch-depth: 1
-          persist-credentials: false
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with:
-          node-version: 22
-      - name: Собрать отчёт
-        env:
-          GH_TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
-          REPO: ${{ github.repository }}
-          DAYS: ${{ inputs.days || '7' }}
-        run: |
-          mkdir -p artifacts/process-metrics
-          node scripts/process-metrics.mjs --repo="$REPO" --days="$DAYS" \
-            --output=artifacts/process-metrics/report.md \
-            --json=artifacts/process-metrics/report.json > /dev/null
-          cat artifacts/process-metrics/report.md >> "$GITHUB_STEP_SUMMARY"
-      - name: Сохранить отчёт
-        if: always()
-        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4
-        with:
-          name: process-metrics-${{ github.run_id }}
-          path: artifacts/process-metrics
-          if-no-files-found: error
-          retention-days: 90
@@ -1,57 +0,0 @@
-name: "Сверка очереди ревью · тело (#623)"
-
-on:
-  # #623: тело вызывается тонким файлом `process-reconcile.yml` из ветки по умолчанию
-  # по ссылке `@dev`; триггеры, run-name и concurrency живут там.
-  workflow_call:
-    inputs:
-      apply:
-        description: "Повторно будить потерянные запросы и публиковать диагностику"
-        required: false
-        type: boolean
-        default: true
-
-permissions:
-  actions: read
-  contents: read
-  issues: read
-
-jobs:
-  reconcile:
-    name: "Один снимок S4/S7 без polling модели"
-    runs-on: ubuntu-24.04
-    timeout-minutes: 10
-    concurrency:
-      group: process-reconcile
-      cancel-in-progress: false
-    steps:
-      # Расписание читается из main, а исполняемый reconciler — из dev: так
-      # после штатного merge действует та же версия кода, которую проверил CI.
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          ref: dev
-          fetch-depth: 1
-          persist-credentials: false
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with:
-          node-version: 22
-      - name: Сопоставить labels, requests, runs и sealed evidence
-        env:
-          GH_TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
-          REPO: ${{ github.repository }}
-          APPLY: ${{ github.event_name == 'schedule' || inputs.apply == true }}
-        run: |
-          mkdir -p artifacts/process-reconcile
-          node scripts/process-reconcile.mjs \
-            --repo "$REPO" \
-            --apply="$APPLY" \
-            --max-actions=5 \
-            --output=artifacts/process-reconcile/summary.json
-      - name: Опубликовать компактный machine-readable итог
-        if: always()
-        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4
-        with:
-          name: process-reconcile-${{ github.run_id }}-${{ github.run_attempt }}
-          path: artifacts/process-reconcile/summary.json
-          if-no-files-found: error
-          retention-days: 14
@@ -1,60 +0,0 @@
-name: "Продолжение ревью после Validate · тело (#623)"
-
-# #636. Стадия `prepare` конвейера (process.yml) больше не ждёт Validate с
-# мутантами на материале внутри job — раннер спал ≈ 28 минут на раунд при
-# 10–12 минутах работы модели. Она диспатчит прогон, кладёт запечатанный
-# маркер `review-pending-…` и выходит. Этот workflow просыпается на завершение
-# любого Validate и, если раунд ждал именно этот прогон (маркер на материале,
-# метка S7 стоит, активного прогона конвейера нет), переставляет метку S7 —
-# новый прогон `prepare` находит завершённый dispatch и продолжает раунд.
-# Ничего не оценивает: зелёный/красный разбирает сам конвейер. Страховка на
-# потерянное событие — process-reconcile.yml с тем же маркером.
-#
-# Для события `workflow_run` GitHub берёт workflow только из ветки по
-# умолчанию (main). Там лежит тонкий `process-resume.yml`, который вызывает
-# этот файл по ссылке `@dev` (#623); сверка тонких копий — в preflight
-# validate.yml.
-
-on:
-  # #623: тело вызывается тонким файлом `process-resume.yml` из ветки по умолчанию
-  # по ссылке `@dev`; триггеры, run-name и concurrency живут там.
-  workflow_call:
-
-permissions:
-  contents: read
-  actions: read
-
-jobs:
-  resume:
-    name: "Разбудить раунд, ждавший этот Validate"
-    if: github.event.workflow_run.event == 'workflow_dispatch' && startsWith(github.event.workflow_run.head_branch, 'issue/')
-    runs-on: ubuntu-24.04
-    timeout-minutes: 10
-    concurrency:
-      group: process-resume-${{ github.event.workflow_run.head_branch }}
-      cancel-in-progress: false
-    steps:
-      # Код берётся из dev, как у reconcile: после штатного слияния действует
-      # версия, которую проверил CI, а не копия из main.
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          ref: dev
-          fetch-depth: 1
-          persist-credentials: false
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with:
-          node-version: 22
-      # Метка переставляется HP_PROCESS_TOKEN: событие от GITHUB_TOKEN не
-      # запустило бы process.yml (см. шапку process.yml, п. 1).
-      - name: Решить по маркеру ожидания и переставить S7
-        env:
-          GH_TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
-          REPO: ${{ github.repository }}
-          BRANCH: ${{ github.event.workflow_run.head_branch }}
-          SHA: ${{ github.event.workflow_run.head_sha }}
-          EVENT: ${{ github.event.workflow_run.event }}
-          STATUS: ${{ github.event.workflow_run.status }}
-        run: |
-          node scripts/process-resume.mjs \
-            --repo="$REPO" --branch="$BRANCH" --sha="$SHA" \
-            --event="$EVENT" --status="$STATUS" --apply=true | tee -a "$GITHUB_STEP_SUMMARY"
@@ -3,14 +3,9 @@ name: Анонс релиза
 # Stable releases are announced; prereleases are deliberately silent.
 # workflow_dispatch exists purely as a connectivity test button and therefore
 # remains allowed to send a test message.
-# #538: НЕТ триггера `release: published`. Три воркфлоу висели на одном событии
-# и бежали параллельно, а анонсу нечего было проверять — он выигрывал гонку
-# всегда. 12.09 v1.75.0 объявили в канале в ту же минуту, когда гейт ассетов
-# отказал: релиз остался без `houseplan-card.js`, E2E не выполнялся вовсе, а
-# подписчики получили сообщение. Анонс вызывается только после того, как работа
-# сделана: `release.yml` зовёт его после выкладки ассетов,
-# `publish-prerelease.yml` — после публикации беты.
 on:
+  release:
+    types: [published]
  workflow_dispatch: {}
  workflow_call:
    inputs:
@@ -42,13 +37,12 @@ permissions:
 jobs:
  telegram:
    name: Оповещение в Telegram (только стабильные)
-    if: ${{ github.event_name == 'workflow_dispatch' || (github.event_name == 'workflow_call' && inputs.prerelease == false) }}
-    runs-on: ubuntu-24.04
-    timeout-minutes: 10
+    if: ${{ github.event_name == 'workflow_dispatch' || (github.event_name == 'release' && github.event.release.prerelease == false) || (github.event_name == 'workflow_call' && inputs.prerelease == false) }}
+    runs-on: ubuntu-latest
    steps:
      - name: Check out release notes for a reusable call
        if: ${{ inputs.reusable == true }}
-        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+        uses: actions/checkout@v7
        with:
          ref: ${{ inputs.ref }}
      - name: Send to Telegram
@@ -60,20 +54,32 @@ jobs:
          INPUT_NAME: ${{ inputs.release_name }}
          INPUT_URL: ${{ inputs.url }}
          INPUT_PRE: ${{ inputs.prerelease }}
+          RELEASE_TAG: ${{ github.event.release.tag_name }}
+          RELEASE_NAME: ${{ github.event.release.name }}
+          RELEASE_URL: ${{ github.event.release.html_url }}
+          RELEASE_PRE: ${{ github.event.release.prerelease }}
+          # The body goes through env, never through shell interpolation —
+          # release notes are arbitrary text.
+          RELEASE_BODY: ${{ github.event.release.body }}
          EVENT: ${{ github.event_name }}
        run: |
          set -euo pipefail
          if [ "$EVENT" = "workflow_dispatch" ] && [ "$CALLED" != "true" ]; then
            TEXT="✅ Тест: оповещения о релизах houseplan-card подключены."
          else
-            # Единственный путь к сообщению о релизе — вызов из воркфлоу, который
-            # уже закончил работу (#538). Тело берётся из файла заметок ветки
-            # тега, а не из события: события здесь больше нет.
-            TAG=$INPUT_TAG
-            NAME=$INPUT_NAME
-            URL=$INPUT_URL
-            PRE=$INPUT_PRE
-            BODY=$(cat docs/RELEASE-NOTES.md)
+            if [ "$CALLED" = "true" ]; then
+              TAG=$INPUT_TAG
+              NAME=$INPUT_NAME
+              URL=$INPUT_URL
+              PRE=$INPUT_PRE
+              BODY=$(cat docs/RELEASE-NOTES.md)
+            else
+              TAG=$RELEASE_TAG
+              NAME=$RELEASE_NAME
+              URL=$RELEASE_URL
+              PRE=$RELEASE_PRE
+              BODY=$RELEASE_BODY
+            fi
            if [ "$PRE" = "true" ]; then
              echo "Prerelease Telegram announcement is disabled"
              exit 0
@@ -9,12 +9,6 @@
 # локально через `npm run docs:accept -- --reviewed --from=<распакованный>`.
 # Та же конструкция, что у golden-эталонов, и по той же причине: картинки
 # попадают в репозиторий через явное решение, а не через бота.
-#
-# Снимать здесь больше не обязанность, а удобство (#401). Приёмка проверяет не
-# место съёмки, а её воспроизводимость: каждый кадр, не объявленный изменённым,
-# должен совпасть с закоммиченным байт-в-байт. Эта джоба потому и удобна, что
-# среда у неё та же, в которой снят закоммиченный набор, — но принять получится
-# из любой, где кадры воспроизводятся, и не получится ни из одной, где нет.
 name: Скриншоты документации

 on:
@@ -31,13 +25,12 @@ permissions:
 jobs:
  capture:
    name: Съёмка и сверка скриншот-индекса
-    runs-on: ubuntu-24.04
-    timeout-minutes: 20
+    runs-on: ubuntu-latest
    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+      - uses: actions/checkout@v7
        with:
          ref: ${{ inputs.ref }}
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
+      - uses: actions/setup-node@v7
        with:
          node-version: 22
          cache: npm
@@ -46,7 +39,7 @@ jobs:
      # системные библиотеки Chromium уже в образе раннера.
      - name: Кэш браузеров Playwright
        id: pw
-        uses: actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6
+        uses: actions/cache@v6
        with:
          path: ~/.cache/ms-playwright
          key: playwright-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
@@ -78,40 +71,14 @@ jobs:
            "oxipng-${OXIPNG_VERSION}-x86_64-unknown-linux-gnu/oxipng"
          echo "$HOME/.local/bin" >> "$GITHUB_PATH"
          "$HOME/.local/bin/oxipng" --version
-      # Съёмка идёт дважды и сравнивается по хешам (#422). Прежний замер
-      # (`--stability`) отвечает на вопрос «плавает ли кадр от времени внутри
-      # страницы» и остаётся ниже; дефект #410 был по другой оси — обрезка
-      # плавала МЕЖДУ прогонами, и три снимка внутри одного процесса совпали бы
-      # всегда. Проверка, объявленная гарантией воспроизводимости, на
-      # собственном инциденте промолчала бы.
-      #
-      # Второй прогон заодно оставляет в `docs/images` кадры, которые и уедут в
-      # артефакт: сравнивать хеши и публиковать разные файлы было бы странно.
-      - name: "Съёмка воспроизводима между прогонами (#410, #422)"
-        run: node scripts/capture-determinism.mjs
+      - name: Capture
+        run: node demo/docs/capture.mjs
      # Вердикт до всякой приёмки. Само число изменившихся файлов ничего не
      # говорит: набор, снятый другим браузером, меняет их все, и это нормально
      # ровно один раз — при переходе на канонический прогон. Сравнивать надо
      # браузер: тот же Chromium и десять изменившихся картинок означают, что
      # изменился продукт (или что-то не так), другой Chromium — ожидаемую
      # разницу рендеринга.
-      # Хеши печатаются в лог, а не только уезжают в артефакт (#410): чтобы
-      # сравнить два прогона одного и того же SHA, нужен текст, который видно с
-      # экрана. Именно так измеряется недетерминированность съёмки — и её
-      # отсутствие после починки.
-      # Съёмка обязана быть воспроизводимой, и это проверяется, а не
-      # предполагается (#410): три снимка на сценарий в одном процессе, без
-      # правки состояния между ними, обязаны совпасть побайтово. Шаг падает,
-      # если кадр снова начнёт зависеть от времени.
-      #
-      # Шаг стоит ПОСЛЕ съёмки и до вердикта: публикацию артефакта он всё равно
-      # блокирует падением job'а, а снимать набор третий раз ради порядка строк
-      # в логе незачем.
-      - name: "Кадр не плавает внутри одного состояния (#410)"
-        run: node demo/docs/capture.mjs --stability=3
-      - name: Хеши кадров
-        run: |
-          for f in docs/images/*.png; do sha256sum "$f"; done
      - name: Вердикт
        run: |
          # Поле манифеста «до» — из закоммиченного состояния, «после» — из
@@ -146,7 +113,7 @@ jobs:
            echo "ВЕРДИКТ: ничего не изменилось, принимать нечего."
          fi
      - name: Upload candidate
-        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
+        uses: actions/upload-artifact@v7
        with:
          name: docs-screenshots
          path: |
@@ -1,12 +1,21 @@
 name: Мутационный гейт

-# Тонкий вызывающий файл (#623). Для этого события GitHub берёт workflow из
-# ветки по умолчанию (`main`), поэтому здесь только то, что обязано жить там:
-# триггеры, run-name, права и concurrency. Тело — `_mutation-gate.yml` по ссылке
-# `@dev`: правка конвейера — один коммит в `dev`, зеркало в `main` не нужно.
-# Этот файл меняется, только когда меняются сами триггеры или потолок прав;
-# тогда он зеркалится в `main`, и preflight `workflow_sync` (validate.yml)
-# держит копии равными.
+# Реестр известных поломок (issue #85): каждый мутант ломает продуктовый код
+# известным способом, и объявленный тест ОБЯЗАН на этом покраснеть. Тест,
+# оставшийся зелёным на сломанном коде, ничего не защищает — он лишь выглядит
+# защитой, и это хуже его отсутствия.
+#
+# Прогон дорогой, поэтому он не входит в Validate и не идёт на каждый push.
+# Его место — перед стабильным релизом (PROCESS.md §8) и раз в неделю по
+# расписанию, чтобы дрейф тестов не копился до релиза. Дешёвая половина —
+# «якоря патчей живы, guard-файлы существуют» — идёт с обычными юнитами:
+# test/mutation-gate.test.mjs.
+#
+# #332: бандл собирается только мутантам с браузерным гвардом (guardNeedsBundle),
+# компиляция тестов в worktree стартует с тёплого test-build (инкрементальный
+# tsc), а реестр режется на четыре чересполосных шарда — полный прогон
+# укладывается в десятки минут вместо часов. Локальный дифф-режим:
+# node scripts/mutation-gate.mjs --changed origin/dev..HEAD

 on:
  workflow_dispatch:
@@ -16,33 +25,63 @@ on:
        required: false
        default: dev
  schedule:
-    # Каждую ночь, 00:43 UTC (03:43 MSK) — после суток правок и до ночного
-    # полного Validate (nightly.yml, 02:17 UTC), чтобы не делить раннеры (#513).
-    # Минута не круглая: такие старты GitHub сдвигает меньше (#658).
-    - cron: '43 0 * * *'
+    # Понедельник, 05:20 UTC — до начала рабочего дня владельца.
+    - cron: '20 5 * * 1'

 permissions:
  contents: read

-# Группа зависит от события (#472). Прежде она была одна на всё, и ручной
-# запуск (отладка гейта) отменял идущий по расписанию — так 24.08 погиб
-# еженедельный прогон, а отменённый в списке выглядит «не красным». Поймать
-# отмену изнутри нельзя: вместе с прогоном отменяются и не начавшиеся job,
-# включая любой репортёр. Значит отмену надо не ловить, а не допускать.
 concurrency:
-  group: mutation-gate-${{ github.event_name }}
+  group: mutation-gate
  cancel-in-progress: true

 jobs:
-  # Потолок прав тела: объединение job-level прав `_mutation-gate.yml`. Вызываемый
-  # workflow может права только сузить, поэтому каждая его job по-прежнему
-  # получает свой прежний минимум (#556), а шире этого набора не получит никто.
-  dev:
-    permissions:
-      contents: read
-      actions: read
-      issues: write
-    uses: Matysh/houseplan-card/.github/workflows/_mutation-gate.yml@dev # #623: тело конвейера из dev
-    with:
-      ref: ${{ inputs.ref }}
-    secrets: inherit
+  mutants:
+    name: "Мутанты: каждый обязан красить тесты (шард ${{ matrix.shard }} из 4)"
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        shard: [1, 2, 3, 4]
+    # Шард ~64 мутантов × свой guard; бандл собирают только браузерные гварды.
+    # Час — потолок против зависшего Chromium.
+    timeout-minutes: 60
+    steps:
+      - uses: actions/checkout@v7
+        with:
+          ref: ${{ github.event_name == 'workflow_dispatch' && inputs.ref || 'dev' }}
+          fetch-depth: 0
+
+      - uses: actions/setup-node@v7
+        with:
+          node-version: 22
+          cache: npm
+
+      - run: npm ci
+
+      - uses: actions/setup-python@v7
+        with:
+          python-version: '3.13'
+
+      - name: Установить backend test dependencies
+        run: pip install pytest voluptuous pytest-homeassistant-custom-component home-assistant-frontend
+
+      - name: Кэш браузеров Playwright
+        id: pw
+        uses: actions/cache@v6
+        with:
+          path: ~/.cache/ms-playwright
+          key: playwright-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
+
+      - name: Установить Chromium
+        if: steps.pw.outputs.cache-hit != 'true'
+        run: npx playwright install --with-deps chromium
+
+      - name: Реестр применим к текущему коду
+        run: node scripts/mutation-gate.mjs --check
+
+      - name: Тёплый test-build для инкрементальной компиляции мутантов
+        run: npx tsc -p tsconfig.test.json && node scripts/fix-test-build.mjs
+
+      - name: Каждый тест ловит свою поломку
+        run: node scripts/mutation-gate.mjs --shard=${{ matrix.shard }}/4
@@ -1,31 +0,0 @@
-name: Ночной полный прогон dev
-
-# Тонкий вызывающий файл (#623). Для этого события GitHub берёт workflow из
-# ветки по умолчанию (`main`), поэтому здесь только то, что обязано жить там:
-# триггеры, run-name, права и concurrency. Тело — `_nightly.yml` по ссылке
-# `@dev`: правка конвейера — один коммит в `dev`, зеркало в `main` не нужно.
-# Этот файл меняется, только когда меняются сами триггеры или потолок прав;
-# тогда он зеркалится в `main`, и preflight `workflow_sync` (validate.yml)
-# держит копии равными.
-
-on:
-  # 02:17 UTC, не на круглой минуте: старты «ровно в час/полчаса» GitHub
-  # откладывает на часы (факт — 07:42–08:05 при плане 02:30, #658).
-  schedule:
-    - cron: '17 2 * * *'
-  workflow_dispatch: {}
-
-permissions:
-  actions: write
-  contents: read
-
-jobs:
-  # Потолок прав тела: объединение job-level прав `_nightly.yml`. Вызываемый
-  # workflow может права только сузить, поэтому каждая его job по-прежнему
-  # получает свой прежний минимум (#556), а шире этого набора не получит никто.
-  dev:
-    permissions:
-      actions: write
-      contents: read
-    uses: Matysh/houseplan-card/.github/workflows/_nightly.yml@dev # #623: тело конвейера из dev
-    secrets: inherit
@@ -6,12 +6,8 @@ on:
  push:
    branches:
      - main
-    paths-ignore:
-      - ".github/workflows/**"
-      - "docs/**"
  schedule:
-    # Минута не круглая (#658): доходит до main вместе со стабильным релизом.
-    - cron: "11 4 * * 1"
+    - cron: "0 4 * * 1"
  workflow_dispatch:
    inputs:
      comparison_ref:
@@ -31,8 +27,8 @@ jobs:
    name: Бенчмарки рендера и геометрии
    # Every profile keeps base and candidate sequential on one hosted runner.
    # Independent profile pairs run in parallel: cross-profile timing is never
-    # compared, while serialising all profile pairs cannot fit the job timeout.
-    runs-on: ubuntu-24.04
+    # compared, while serialising all five pairs cannot fit the job timeout.
+    runs-on: ubuntu-latest
    timeout-minutes: 60
    strategy:
      fail-fast: false
@@ -40,16 +36,12 @@ jobs:
        profile:
          - large-house
          - isometric
-          - isometric-stage3
          - plan-snap
-          - interaction
          - blend
          - overlay
-          - space-default
-          - space-glow
    steps:
      - name: Check out candidate
-        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+        uses: actions/checkout@v7
        with:
          path: candidate
          fetch-depth: 2
@@ -61,10 +53,6 @@ jobs:
          EVENT_NAME: ${{ github.event_name }}
          PUSH_BEFORE_SHA: ${{ github.event.before }}
          MANUAL_BASE: ${{ inputs.comparison_ref }}
-          # #587: кандидат стабильного релиза судится о предыдущий стабильный
-          # тег, а не о прошлую вершину main. Признак кандидата — трейлер
-          # `Release:` в сообщении head-коммита, поэтому оно едет в скрипт.
-          HEAD_MESSAGE: ${{ github.event.head_commit.message }}
        run: |
          set -euo pipefail
          if [ "$(git rev-parse --is-shallow-repository)" = "true" ]; then
@@ -72,17 +60,79 @@ jobs:
          else
            git fetch --force --tags --prune origin
          fi
-          # Решение целиком в скрипте: его отрицательные случаи проверяются
-          # фикстурами, а shell-развилку прогнать тестом нельзя (#556, #587).
-          node scripts/performance-baseline.mjs
+
+          if [ "$EVENT_NAME" = "workflow_dispatch" ] && [ -n "$MANUAL_BASE" ]; then
+            sha="$(git rev-parse "${MANUAL_BASE}^{commit}" 2>/dev/null || true)"
+            source="manual comparison ref $MANUAL_BASE"
+          elif [ "$EVENT_NAME" = "push" ] && [ -n "$PUSH_BEFORE_SHA" ] && ! printf '%s' "$PUSH_BEFORE_SHA" | grep -Eq '^0+$'; then
+            sha="$PUSH_BEFORE_SHA"
+            source="push before"
+          else
+            sha="$(git rev-parse HEAD^ 2>/dev/null || true)"
+            source="candidate parent"
+          fi
+          requested_sha="$sha"
+
+          usable=true
+          reason=""
+          if [ -z "$sha" ] || ! git cat-file -e "${sha}^{commit}" 2>/dev/null; then
+            usable=false
+            reason="commit is not present after fetching all remote refs"
+          elif [ "$source" = "push before" ] && ! git merge-base --is-ancestor "$sha" HEAD; then
+            usable=false
+            reason="commit is no longer an ancestor of the pushed revision"
+          fi
+
+          if [ "$usable" != true ]; then
+            parent_sha="$(git rev-parse HEAD^ 2>/dev/null || true)"
+            if [ -n "$parent_sha" ] && [ "$parent_sha" != "$(git rev-parse HEAD)" ]; then
+              sha="$parent_sha"
+              source="candidate parent (unusable requested-base fallback)"
+              echo "::warning::Comparison SHA ${requested_sha:-none} is unusable ($reason); using candidate parent $sha."
+              usable=true
+            fi
+          fi
+
+          if [ "$usable" != true ]; then
+            fallback_tag=""
+            fallback_sha=""
+            head_sha="$(git rev-parse HEAD)"
+            while IFS= read -r tag; do
+              case "$tag" in
+                v[0-9]*.[0-9]*.[0-9]*) ;;
+                *) continue ;;
+              esac
+              tag_sha="$(git rev-list -n 1 "$tag")"
+              if [ "$tag_sha" != "$head_sha" ]; then
+                fallback_tag="$tag"
+                fallback_sha="$tag_sha"
+                break
+              fi
+            done < <(git tag --merged HEAD --sort=-version:refname)
+            if [ -z "$fallback_sha" ]; then
+              echo "::error::No usable comparison commit or previous release tag is reachable from HEAD."
+              exit 1
+            fi
+            sha="$fallback_sha"
+            source="release tag $fallback_tag"
+            echo "::warning::Using $fallback_tag ($sha) as the comparison base."
+          fi
+
+          if ! git cat-file -e "${sha}:demo/bundle-freshness.mjs" 2>/dev/null; then
+            echo "::warning::Comparison $sha predates HP-PERF-01; using candidate parent HEAD^."
+            sha="$(git rev-parse HEAD^)"
+            source="candidate parent (HP-PERF-01 compatibility)"
+          fi
+          echo "sha=$sha" >> "$GITHUB_OUTPUT"
+          echo "Comparison base: $sha ($source)" >> "$GITHUB_STEP_SUMMARY"

      - name: Check out base SHA
-        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+        uses: actions/checkout@v7
        with:
          ref: ${{ steps.base.outputs.sha }}
          path: baseline

-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
+      - uses: actions/setup-node@v7
        with:
          node-version: 22
          cache: npm
@@ -96,7 +146,7 @@ jobs:
      # То же, что в validate.yml: кэш браузеров, apt не трогаем (#206).
      - name: Кэш браузеров Playwright
        id: pw
-        uses: actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6
+        uses: actions/cache@v6
        with:
          path: ~/.cache/ms-playwright
          key: playwright-${{ runner.os }}-${{ hashFiles('candidate/package-lock.json') }}
@@ -134,18 +184,10 @@ jobs:
              npm run benchmark:large-house-isometric -- --target-root=../baseline --samples=7 --warmups=1 --output=../artifacts/performance/isometric-baseline.json
              npm run benchmark:large-house-isometric -- --target-root=. --samples=7 --warmups=1 --output=../artifacts/performance/isometric-candidate.json
              ;;
-            isometric-stage3)
-              npm run benchmark:isometric-stage3-dense -- --allow-stage2-base --target-root=../baseline --samples=7 --warmups=1 --output=../artifacts/performance/isometric-stage3-baseline.json
-              npm run benchmark:isometric-stage3-dense -- --target-root=. --samples=7 --warmups=1 --output=../artifacts/performance/isometric-stage3-candidate.json
-              ;;
            plan-snap)
              npm run benchmark:large-house-plan-snap -- --target-root=../baseline --samples=7 --warmups=1 --output=../artifacts/performance/plan-snap-baseline.json
              npm run benchmark:large-house-plan-snap -- --target-root=. --samples=7 --warmups=1 --output=../artifacts/performance/plan-snap-candidate.json
              ;;
-            interaction)
-              npm run benchmark:large-house-interaction -- --target-root=../baseline --samples=7 --warmups=1 --output=../artifacts/performance/interaction-baseline.json
-              npm run benchmark:large-house-interaction -- --target-root=. --samples=7 --warmups=1 --output=../artifacts/performance/interaction-candidate.json
-              ;;
            blend)
              npm run benchmark:glow -- --profile=large-light-blend-v1 --target-root=../baseline --samples=7 --warmups=1 --output=../artifacts/performance/blend-baseline.json
              npm run benchmark:glow -- --profile=large-light-blend-v1 --target-root=. --samples=7 --warmups=1 --output=../artifacts/performance/blend-candidate.json
@@ -158,18 +200,6 @@ jobs:
                cp ../artifacts/performance/overlay-candidate.json ../artifacts/performance/overlay-baseline.json
              fi
              ;;
-            space-default)
-              npm run benchmark:glow -- --profile=large-space-card-default-v1 --target-root=../baseline --samples=7 --warmups=1 --output=../artifacts/performance/space-default-baseline.json
-              npm run benchmark:glow -- --profile=large-space-card-default-v1 --target-root=. --samples=7 --warmups=1 --output=../artifacts/performance/space-default-candidate.json
-              ;;
-            space-glow)
-              npm run benchmark:glow -- --profile=large-space-card-glow-v1 --target-root=../baseline --samples=7 --warmups=1 --output=../artifacts/performance/space-glow-baseline.json
-              npm run benchmark:glow -- --profile=large-space-card-glow-v1 --target-root=. --samples=7 --warmups=1 --output=../artifacts/performance/space-glow-candidate.json
-              if ! grep -q "light_pools" ../baseline/src/space-card.ts; then
-                echo "Base predates opt-in static Glow; bootstrap relative baseline, keep absolute gate"
-                cp ../artifacts/performance/space-glow-candidate.json ../artifacts/performance/space-glow-baseline.json
-              fi
-              ;;
            *)
              echo "::error::Unknown performance profile: $PROFILE"
              exit 1
@@ -186,34 +216,22 @@ jobs:
              npm run benchmark:compare -- --baseline=../artifacts/performance/baseline.json --candidate=../artifacts/performance/candidate.json --output=../artifacts/performance/comparison.json
              ;;
            isometric)
-              npm run benchmark:compare -- --budgets=demo/performance/budgets-large-house-isometric.json --baseline=../artifacts/performance/isometric-baseline.json --candidate=../artifacts/performance/isometric-candidate.json --baseline-sha="$(git -C ../baseline rev-parse HEAD)" --candidate-sha="$(git rev-parse HEAD)" --output=../artifacts/performance/isometric-comparison.json
-              ;;
-            isometric-stage3)
-              npm run benchmark:compare -- --budgets=demo/performance/budgets-isometric-stage3-dense.json --baseline=../artifacts/performance/isometric-stage3-baseline.json --candidate=../artifacts/performance/isometric-stage3-candidate.json --baseline-sha="$(git -C ../baseline rev-parse HEAD)" --candidate-sha="$(git rev-parse HEAD)" --output=../artifacts/performance/isometric-stage3-comparison.json
+              npm run benchmark:compare -- --budgets=demo/performance/budgets-large-house-isometric.json --baseline=../artifacts/performance/isometric-baseline.json --candidate=../artifacts/performance/isometric-candidate.json --output=../artifacts/performance/isometric-comparison.json
              ;;
            plan-snap)
              npm run benchmark:compare -- --budgets=demo/performance/budgets-large-house-plan-snap.json --baseline=../artifacts/performance/plan-snap-baseline.json --candidate=../artifacts/performance/plan-snap-candidate.json --output=../artifacts/performance/plan-snap-comparison.json
              ;;
-            interaction)
-              npm run benchmark:compare -- --budgets=demo/performance/budgets-large-house-interaction.json --baseline=../artifacts/performance/interaction-baseline.json --candidate=../artifacts/performance/interaction-candidate.json --output=../artifacts/performance/interaction-comparison.json
-              ;;
            blend)
              npm run benchmark:compare -- --budgets=demo/performance/budgets-large-light-blend.json --baseline=../artifacts/performance/blend-baseline.json --candidate=../artifacts/performance/blend-candidate.json --output=../artifacts/performance/blend-comparison.json
              ;;
            overlay)
              npm run benchmark:compare -- --budgets=demo/performance/budgets-large-house-glow-overlay.json --baseline=../artifacts/performance/overlay-baseline.json --candidate=../artifacts/performance/overlay-candidate.json --output=../artifacts/performance/overlay-comparison.json
              ;;
-            space-default)
-              npm run benchmark:compare -- --budgets=demo/performance/budgets-large-space-card-default.json --baseline=../artifacts/performance/space-default-baseline.json --candidate=../artifacts/performance/space-default-candidate.json --output=../artifacts/performance/space-default-comparison.json
-              ;;
-            space-glow)
-              npm run benchmark:compare -- --budgets=demo/performance/budgets-large-space-card-glow.json --baseline=../artifacts/performance/space-glow-baseline.json --candidate=../artifacts/performance/space-glow-candidate.json --output=../artifacts/performance/space-glow-comparison.json
-              ;;
          esac

      - name: Upload full performance report
        if: always()
-        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
+        uses: actions/upload-artifact@v7
        with:
          name: full-performance-${{ matrix.profile }}
          path: artifacts/performance
@@ -1,41 +0,0 @@
-name: Метрики процесса
-
-# Тонкий вызывающий файл (#623). Для этого события GitHub берёт workflow из
-# ветки по умолчанию (`main`), поэтому здесь только то, что обязано жить там:
-# триггеры, run-name, права и concurrency. Тело — `_process-metrics.yml` по ссылке
-# `@dev`: правка конвейера — один коммит в `dev`, зеркало в `main` не нужно.
-# Этот файл меняется, только когда меняются сами триггеры или потолок прав;
-# тогда он зеркалится в `main`, и preflight `workflow_sync` (validate.yml)
-# держит копии равными.
-
-on:
-  schedule:
-    # Понедельник 05:23 UTC — после ночных прогонов, до рабочего дня; минута
-    # не круглая, чтобы не стоять в очереди «ровных» расписаний (#658).
-    - cron: '23 5 * * 1'
-  workflow_dispatch:
-    inputs:
-      days:
-        description: "Окно в днях"
-        required: false
-        default: "7"
-        type: string
-
-permissions:
-  contents: read
-  actions: read
-  issues: read
-
-jobs:
-  # Потолок прав тела: объединение job-level прав `_process-metrics.yml`. Вызываемый
-  # workflow может права только сузить, поэтому каждая его job по-прежнему
-  # получает свой прежний минимум (#556), а шире этого набора не получит никто.
-  dev:
-    permissions:
-      contents: read
-      actions: read
-      issues: read
-    uses: Matysh/houseplan-card/.github/workflows/_process-metrics.yml@dev # #623: тело конвейера из dev
-    with:
-      days: ${{ inputs.days }}
-    secrets: inherit
@@ -1,40 +0,0 @@
-name: Сверка очереди ревью
-run-name: "reconcile process queue · ${{ github.event_name }}"
-
-# Тонкий вызывающий файл (#623). Для этого события GitHub берёт workflow из
-# ветки по умолчанию (`main`), поэтому здесь только то, что обязано жить там:
-# триггеры, run-name, права и concurrency. Тело — `_process-reconcile.yml` по ссылке
-# `@dev`: правка конвейера — один коммит в `dev`, зеркало в `main` не нужно.
-# Этот файл меняется, только когда меняются сами триггеры или потолок прав;
-# тогда он зеркалится в `main`, и preflight `workflow_sync` (validate.yml)
-# держит копии равными.
-
-on:
-  schedule:
-    - cron: '7,37 * * * *'
-  workflow_dispatch:
-    inputs:
-      apply:
-        description: "Повторно будить потерянные запросы и публиковать диагностику"
-        required: true
-        type: boolean
-        default: true
-
-permissions:
-  actions: read
-  contents: read
-  issues: read
-
-jobs:
-  # Потолок прав тела: объединение job-level прав `_process-reconcile.yml`. Вызываемый
-  # workflow может права только сузить, поэтому каждая его job по-прежнему
-  # получает свой прежний минимум (#556), а шире этого набора не получит никто.
-  dev:
-    permissions:
-      actions: read
-      contents: read
-      issues: read
-    uses: Matysh/houseplan-card/.github/workflows/_process-reconcile.yml@dev # #623: тело конвейера из dev
-    with:
-      apply: ${{ inputs.apply == true }}
-    secrets: inherit
@@ -1,33 +0,0 @@
-name: Продолжение ревью после Validate
-run-name: "resume · ${{ github.event.workflow_run.head_branch }} · ${{ github.event.workflow_run.conclusion }}"
-
-# Тонкий вызывающий файл (#623). Для этого события GitHub берёт workflow из
-# ветки по умолчанию (`main`), поэтому здесь только то, что обязано жить там:
-# триггеры, run-name, права и concurrency. Тело — `_process-resume.yml` по ссылке
-# `@dev`: правка конвейера — один коммит в `dev`, зеркало в `main` не нужно.
-# Этот файл меняется, только когда меняются сами триггеры или потолок прав;
-# тогда он зеркалится в `main`, и preflight `workflow_sync` (validate.yml)
-# держит копии равными.
-
-on:
-  workflow_run:
-    workflows: ["Проверка (CI)"]
-    types: [completed]
-
-permissions:
-  contents: read
-  actions: read
-
-jobs:
-  # Потолок прав тела: объединение job-level прав `_process-resume.yml`. Вызываемый
-  # workflow может права только сузить, поэтому каждая его job по-прежнему
-  # получает свой прежний минимум (#556), а шире этого набора не получит никто.
-  dev:
-    # Тот же фильтр, что у job `resume` тела: посторонние события не
-    # поднимают вызов, а прогон остаётся skipped, как до #623.
-    if: github.event.workflow_run.event == 'workflow_dispatch' && startsWith(github.event.workflow_run.head_branch, 'issue/')
-    permissions:
-      contents: read
-      actions: read
-    uses: Matysh/houseplan-card/.github/workflows/_process-resume.yml@dev # #623: тело конвейера из dev
-    secrets: inherit
@@ -1,31 +1,909 @@
 name: Ревью-конвейер
-run-name: "process #${{ github.event.issue.number }} · ${{ github.event.label.name }} · ${{ github.event.issue.title }}"

-# Тонкий вызывающий файл (#623). Для этого события GitHub берёт workflow из
-# ветки по умолчанию (`main`), поэтому здесь только то, что обязано жить там:
-# триггеры, run-name, права и concurrency. Тело — `_process.yml` по ссылке
-# `@dev`: правка конвейера — один коммит в `dev`, зеркало в `main` не нужно.
-# Этот файл меняется, только когда меняются сами триггеры или потолок прав;
-# тогда он зеркалится в `main`, и preflight `workflow_sync` (validate.yml)
-# держит копии равными.
+# Событийный конвейер процесса (PROCESS.md). Смена статусной метки — это
+# сообщение: она порождает событие, событие запускает следующий шаг.
+#
+# S4-spec-review -> ревью ТЗ    -> S5-ready | S3-spec
+# S7-code-review -> код-ревью   -> слияние в dev -> S8-merged | S6-in-progress
+#
+# Три вещи, без которых конвейер молча не работает:
+#
+# 1. Метки переставляются токеном HP_PROCESS_TOKEN, а не GITHUB_TOKEN. GitHub
+#    намеренно не запускает workflow от событий, вызванных GITHUB_TOKEN, чтобы
+#    не было циклов — цепочка оборвалась бы после первого шага.
+# 2. Этот файл обязан лежать в ветке по умолчанию (main). Для события `issues`
+#    GitHub берёт workflow только оттуда, независимо от того, что в dev.
+# 3. Многострочный текст внутри `run:` — только через heredoc. Строка с нулевым
+#    отступом обрывает блок YAML, и скрипт обрезается без ошибки парсера.
+#    Проверять не только YAML, но и каждый `run` через `bash -n`.

 on:
  issues:
    types: [labeled]

+concurrency:
+  # Два события по одному issue не должны запускать два прогона.
+  group: process-issue-${{ github.event.issue.number }}
+  cancel-in-progress: false
+
 permissions:
  contents: read
+  issues: write
+  # Обязательно: claude-code-action получает OIDC-токен для авторизации
+  # GitHub App. Без этого прогон падает с «Could not fetch an OIDC token».
+  id-token: write

 jobs:
-  # Потолок прав тела: объединение job-level прав `_process.yml`. Вызываемый
-  # workflow может права только сузить, поэтому каждая его job по-прежнему
-  # получает свой прежний минимум (#556), а шире этого набора не получит никто.
-  dev:
-    # Тот же фильтр, что у job `guard` тела: посторонние события не
-    # поднимают вызов, а прогон остаётся skipped, как до #623.
-    if: github.event.label.name == 'S4-spec-review' || github.event.label.name == 'S7-code-review'
-    permissions:
-      contents: read
-      issues: write
-    uses: Matysh/houseplan-card/.github/workflows/_process.yml@dev # #623: тело конвейера из dev
-    secrets: inherit
+  guard:
+    name: "Страж: ребейз на dev и предпосылки ревью"
+    runs-on: ubuntu-latest
+    outputs:
+      stage: ${{ steps.decide.outputs.stage }}
+      cycle: ${{ steps.decide.outputs.cycle }}
+      spent: ${{ steps.decide.outputs.spent }}
+      limit: ${{ steps.decide.outputs.limit }}
+    steps:
+      - id: decide
+        env:
+          GH_TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
+          LABEL: ${{ github.event.label.name }}
+          BLOCKED: ${{ contains(github.event.issue.labels.*.name, 'blocked') }}
+          EXHAUSTED: ${{ contains(github.event.issue.labels.*.name, 'review-4') }}
+          SMALL: ${{ contains(github.event.issue.labels.*.name, 'small') }}
+          TRIVIAL: ${{ contains(github.event.issue.labels.*.name, 'trivial') }}
+          NUM: ${{ github.event.issue.number }}
+        run: |
+          # Этап определяется первым: от него зависит, какие вердикты считать.
+          stage=""; marker=""
+          case "$LABEL" in
+            S4-spec-review) stage="spec"; marker="SPEC-REVIEW" ;;
+            S7-code-review) stage="code"; marker="CODE-REVIEW" ;;
+            *) echo "метка $LABEL конвейер не запускает" ;;
+          esac
+
+          # Лимит циклов: 4 обычный, 2 на лёгком и коротком треке (PROCESS.md §4).
+          limit=4
+          if [ "$SMALL" = "true" ] || [ "$TRIVIAL" = "true" ]; then limit=2; fi
+
+          # Считаются ДВЕ РАЗНЫЕ величины, и это не педантизм (#227).
+          #
+          # `attempt` — сколько раз ревью уже отработало на этом этапе. Он нужен
+          # только для имени документа и метки: два захода с одинаковым номером
+          # означают, что второй документ перезапишет первый и артефакт ревью
+          # исчезнет.
+          #
+          # `spent` — сколько циклов израсходовано из бюджета §4. Цикл — это
+          # «отправка на ревью → вердикт с блокирующими находками → возврат
+          # автору», поэтому бюджет тратят ТОЛЬКО жёлтые и красные вердикты.
+          # Зелёный ничего на правки не вернул и цикла не образует.
+          #
+          # Раньше обе роли исполнял один счётчик всех вердиктов, и конвейер
+          # наказывал за то, что предписывал сам: при неудавшемся слиянии он
+          # велит вернуть S7-code-review после ребейза, и этот заход добивал
+          # бюджет. На #225 (лёгкий трек, лимит 2) последовательность
+          # жёлтый → зелёный → ребейз дала review-4 на задаче с зелёным ревью и
+          # зелёным CI: работа встала, хотя после вердикта не было ни одной
+          # правки продуктового кода.
+          #
+          # Вердикты считаются ТОЛЬКО своего этапа: иначе вердикт по ТЗ съедал
+          # цикл из бюджета код-ревью (#89 получило r2/4). Этап опознаётся по
+          # имени документа в теле комментария; документа нет — вердикт не
+          # посчитается. Недосчёт даёт лишний заход, перерасчёт остановил бы
+          # работу досрочно: из двух ошибок выбрана обратимая.
+          attempt=1; spent=0; spent_list=""
+          if [ -n "$stage" ]; then
+            comments=$(gh issue view "$NUM" --repo "${{ github.repository }}" --json comments)
+            of_stage="[.comments[] | select(.body | test(\"Вердикт:\")) | select(.body | test(\"$marker\"))]"
+            # Блокирующим считается вердикт, у которого в строке вердикта стоит
+            # «жёлтый» или «красный». Регистр и окружение слова не важны.
+            blocking="$of_stage | map(select(.body | test(\"Вердикт:[^\\n]*(жёлт|красн)\"; \"i\")))"
+            attempt=$(( $(printf '%s' "$comments" | jq -r "$of_stage | length") + 1 ))
+            spent=$(printf '%s' "$comments" | jq -r "$blocking | length")
+            spent_list=$(printf '%s' "$comments" | jq -r "$blocking | map(\"- \" + .url) | join(\"\\n\")")
+          fi
+
+          # Отказ обязан быть виден в issue, а не только в логе прогона.
+          # Ревьюшная метка обещает работу; если конвейер её не начал и промолчал,
+          # задача стоит в этом статусе бесконечно и никто об этом не узнаёт.
+          # Так и вышло на #123: чужой issue довели до S4-spec-review, guard
+          # отказался за 9 секунд, и в issue не было ни слова.
+          #
+          # Пишем только когда пытались запустить ревью, то есть stage опознан.
+          # Иначе комментарий уходил бы на каждую смену любой метки.
+          refuse() {
+            echo "$1"
+            gh issue comment "$NUM" --repo "${{ github.repository }}" --body \
+              "Конвейер ревью не запущен: $2
+
+          Метка \`$LABEL\` обещает работу, которая не начнётся, поэтому статус лучше вернуть в предыдущий — иначе задача простоит здесь бесконечно. [Прогон](${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }})."
+            stage=""
+          }
+
+          # Автор issue здесь не проверяется (решение владельца 2026-08-13).
+          # Проверка стоит на входе в процесс, а не на каждом шаге: как только
+          # задача получила статусную метку, она в работе, и кто её завёл — не
+          # имеет значения. Само присвоение метки и есть явное подтверждение
+          # владельца, причём проверенное платформой: метки может ставить только
+          # тот, у кого есть право записи в репозиторий. Прежняя проверка здесь
+          # дублировала эту гарантию и заставляла переоформлять чужие отчёты
+          # своими issue — чистая работа впустую, как на #123.
+          if [ -z "$stage" ]; then
+            :
+          elif [ "$BLOCKED" = "true" ]; then
+            refuse "стоит blocked — конвейер не запускается" \
+              "на issue стоит \`blocked\` — задача ждёт внешнего решения. Снять метку, когда решение принято."
+          elif [ "$EXHAUSTED" = "true" ]; then
+            # Метку снимает владелец, а не конвейер: автоматика, отменяющая
+            # остановку работы, дороже ручного снятия. Но пересчёт печатается —
+            # метка могла остаться от прежнего правила, когда бюджет тратил и
+            # зелёный вердикт (#227).
+            stale=""
+            if [ "$spent" -lt "$limit" ]; then
+              stale=" Пересчёт по действующему правилу: блокирующих циклов $spent из $limit — метка могла остаться от прежнего правила, когда бюджет тратил любой вердикт. Снять её может владелец."
+            fi
+            refuse "стоит review-4 — решение за владельцем" \
+              "на issue стоит \`review-4\`: лимит циклов ревью исчерпан, дальше решает владелец — разделить задачу, отклонить или арбитраж (PROCESS.md §4).$stale"
+          elif [ "$spent" -ge "$limit" ]; then
+            echo "блокирующих циклов этапа $stage: $spent из $limit — лимит исчерпан"
+            gh issue edit "$NUM" --repo "${{ github.repository }}" --add-label review-4
+            # Перечень учтённого обязателен: иначе владельцу приходится читать
+            # всю ленту, чтобы понять, из чего сложился счёт.
+            gh issue comment "$NUM" --repo "${{ github.repository }}" --body \
+              "Лимит циклов ревью исчерпан: блокирующих циклов $spent из $limit на этапе \`$stage\` (заход $attempt). Следующего захода нет: решение владельца — разделить задачу, отклонить или арбитраж (PROCESS.md §4).
+
+          Учтены вердикты с блокирующими находками — зелёные бюджет не тратят:
+          $spent_list"
+            stage=""
+          else
+            echo "этап $stage, заход $attempt, блокирующих циклов $spent из $limit"
+          fi
+          echo "stage=$stage" >> "$GITHUB_OUTPUT"
+          echo "cycle=$attempt" >> "$GITHUB_OUTPUT"
+          echo "spent=$spent" >> "$GITHUB_OUTPUT"
+          echo "limit=$limit" >> "$GITHUB_OUTPUT"
+
+  review:
+    name: "Ревью (Claude): вердикт в issue"
+    needs: guard
+    if: needs.guard.outputs.stage != ''
+    runs-on: ubuntu-latest
+    # Время — единственный настоящий ограничитель зациклившегося прогона.
+    timeout-minutes: 45
+    steps:
+      - uses: actions/checkout@v7
+        with:
+          fetch-depth: 0
+          ref: dev
+          # Иначе в конфиге git остаётся креденшел GITHUB_TOKEN, и push с
+          # мёртвым PAT молча уходит от github-actions[bot] — 403 при
+          # contents: read. Отказ обязан быть громким и правильным.
+          persist-credentials: false
+
+      # Живость PAT проверяется ДО ревью. На #150 истёкший токен обнаружился
+      # только на публикации документа — после сорока минут работы ревьюера.
+      - name: Секрет HP_PROCESS_TOKEN жив
+        env:
+          GH_TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
+        run: |
+          if [ -z "$GH_TOKEN" ]; then
+            echo "::error::HP_PROCESS_TOKEN пуст — секрет удалён или недоступен"
+            exit 1
+          fi
+          if ! login=$(gh api user -q .login 2>/dev/null); then
+            echo "::error::HP_PROCESS_TOKEN не аутентифицируется — истёк или отозван. Обновить: Settings -> Secrets and variables -> Actions -> HP_PROCESS_TOKEN"
+            exit 1
+          fi
+          echo "токен жив, действует от: $login"
+
+      # Окружение готовит workflow, а не модель своими ходами. Раньше промпт
+      # велел ревьюеру самому выполнить `npm ci`: минуты уходили на установку без
+      # кэша, платились из бюджета 45 минут и из лимитов подписки, а ходы модели
+      # тратились на работу инфраструктуры. В validate.yml кэш стоит на всех
+      # тяжёлых job, здесь его не было.
+      - uses: actions/setup-node@v7
+        with:
+          node-version: 22
+          cache: npm
+
+      # Материал ревью живёт в ветке задачи: ТЗ в docs/specs/ и код коммитятся
+      # в issue/<NN>-slug. Если ветка запушена — переключаемся на неё, иначе
+      # ревьюер прочтёт dev и не найдёт того, что должен оценивать.
+      - name: Перейти на ветку задачи
+        id: branch
+        env:
+          NUM: ${{ github.event.issue.number }}
+        run: |
+          # Свежая по последнему коммиту, а не первая по алфавиту: на #150 рядом
+          # жили ветка ТЗ и ветка реализации, и head -1 выбрал устаревшую.
+          git fetch -q origin "+refs/heads/issue/${NUM}-*:refs/remotes/origin/issue/${NUM}-*" || true
+          branches=$(git for-each-ref --sort=-committerdate \
+            --format='%(refname:lstrip=3)' "refs/remotes/origin/issue/${NUM}-*")
+          branch=$(printf '%s\n' "$branches" | head -1)
+          if [ "$(printf '%s\n' "$branches" | grep -c .)" -gt 1 ]; then
+            echo "::warning::веток issue/${NUM}-* несколько ($(echo $branches | tr '\n' ' ')) — выбрана свежая по коммиту: $branch. Устаревшую следует удалить."
+          fi
+          if [ -n "$branch" ]; then
+            git checkout -q "origin/$branch"
+            echo "материал ревью: ветка $branch, $(git rev-parse --short HEAD)"
+            echo "name=$branch" >> "$GITHUB_OUTPUT"
+          else
+            echo "::warning::ветка issue/${NUM}-* не найдена на origin — ревью пойдёт по dev"
+            echo "МАТЕРИАЛ НЕ ЗАПУШЕН" >> "$GITHUB_STEP_SUMMARY"
+          fi
+
+      # Ревьюер обязан смотреть тот же код, который уедет в dev (#257). Раньше
+      # ревью шло по ветке как есть, а слияние делало ребейз — проверенный SHA и
+      # слитый SHA были разными коммитами. Пока расхождение с dev текстовое,
+      # ребейз упирается в конфликт и это видно; смысловое расхождение git
+      # склеивает молча, и в dev уезжает комбинация, которую никто не читал.
+      # Именно так пришёл регресс #234.
+      #
+      # Заодно снимается плата за конфликт: он обнаруживался ПОСЛЕ сорока минут
+      # ревью и потраченных лимитов подписки, хотя виден за пять секунд до них.
+      #
+      # Этап spec не затрагивается: ветку ТЗ в dev никто не сливает, и трогать
+      # чужую ветку без нужды — лишний риск.
+      - name: Привести ветку к dev
+        id: rebase
+        if: needs.guard.outputs.stage == 'code' && steps.branch.outputs.name != ''
+        env:
+          TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
+          BRANCH: ${{ steps.branch.outputs.name }}
+          # rebase, в отличие от commit, не принимает -c user.*: он запускает
+          # свои процессы и требует личность в окружении, иначе падает с
+          # «unable to auto-detect email address».
+          GIT_AUTHOR_NAME: claude[bot]
+          GIT_AUTHOR_EMAIL: 209825114+claude[bot]@users.noreply.github.com
+          GIT_COMMITTER_NAME: claude[bot]
+          GIT_COMMITTER_EMAIL: 209825114+claude[bot]@users.noreply.github.com
+        run: |
+          git fetch -q origin dev
+          if git merge-base --is-ancestor origin/dev HEAD; then
+            echo "ветка содержит весь dev — ребейз не нужен"
+            exit 0
+          fi
+          behind=$(git rev-list --count "HEAD..origin/dev")
+          before=$(git rev-parse "origin/$BRANCH")
+          echo "dev впереди на $behind коммит(ов) — привожу ветку"
+          if ! git rebase origin/dev; then
+            # Список снимается ДО abort: он же снимает состояние конфликта, и
+            # тогда автору достаётся «не ребейзится» без единого имени файла (#364).
+            files=$(git diff --name-only --diff-filter=U | sort -u | paste -sd'\n' -)
+            git rebase --abort || true
+            {
+              echo 'conflict=true'
+              echo 'conflicts<<EOF_FILES'
+              printf '%s\n' "${files:-(git не назвал файлы)}"
+              echo 'EOF_FILES'
+            } >> "$GITHUB_OUTPUT"
+            echo "::warning::ветка $BRANCH не ребейзится на dev без конфликта — ревью не запускается"
+            printf 'конфликтуют:\n%s\n' "${files:-(git не назвал файлы)}"
+            exit 0
+          fi
+          # --force-with-lease с явным ожидаемым значением обязателен: между
+          # fetch и push автор мог запушить коммит, и слепой --force потерял бы
+          # его молча. Расхождение lease — падение прогона, а не предупреждение:
+          # ревью пошло бы по коду, которого на ветке уже нет.
+          if ! git push -q --force-with-lease="refs/heads/$BRANCH:$before" \
+               "https://x-access-token:$TOKEN@github.com/${{ github.repository }}" \
+               "HEAD:refs/heads/$BRANCH"; then
+            echo "::error::ветка $BRANCH изменилась во время ребейза — прогон прерван, чтобы не потерять коммит автора"
+            exit 1
+          fi
+          # Локальная ссылка обновляется тоже: шаг слияния берёт origin/$BRANCH,
+          # и без этого он ребейзил бы заново уже приведённое.
+          git fetch -q origin "+refs/heads/$BRANCH:refs/remotes/origin/$BRANCH"
+          short_before=$(git rev-parse --short "$before")
+          short_after=$(git rev-parse --short HEAD)
+          echo "note=Ветка приведена к dev конвейером до ревью: поверх легло $behind коммит(ов) dev, $short_before -> $short_after. После ребейза это другой код (§7.2) — разбор полный, а не по дельте." >> "$GITHUB_OUTPUT"
+          echo "ветка $BRANCH приведена к dev: $short_before -> $short_after"
+
+      # Материал ревью — конкретный SHA (#312). Вердикт применим только к
+      # нему: если во время ревью в ветку прилетит коммит, шаг слияния обязан
+      # это заметить и отказаться, а не молча увезти в dev непроверенный код.
+      - name: Зафиксировать SHA материала ревью
+        id: material
+        if: steps.rebase.outputs.conflict != 'true'
+        run: |
+          echo "sha=$(git rev-parse HEAD)" >> "$GITHUB_OUTPUT"
+          echo "материал ревью: $(git rev-parse --short HEAD)"
+
+      # Конфликт возвращает задачу автору ДО ревью. Инвариант «после прогона
+      # метка меняется всегда» при этом держится: возврат в S6-in-progress —
+      # тоже смена метки, и автор не ждёт впустую.
+      - name: Конфликт с dev — вернуть автору без ревью
+        if: steps.rebase.outputs.conflict == 'true'
+        env:
+          GH_TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
+          NUM: ${{ github.event.issue.number }}
+          BRANCH: ${{ steps.branch.outputs.name }}
+          CONFLICTS: ${{ steps.rebase.outputs.conflicts }}
+        run: |
+          cat > /tmp/stale.md <<EOF
+          **Ревью не запускалось:** ветка \`$BRANCH\` не ребейзится на \`dev\` без конфликта. Код никто не читал, вердикта нет, цикл ревью не израсходован.
+
+          Конфликтуют:
+
+          \`\`\`
+          $CONFLICTS
+          \`\`\`
+
+          Проверка стоит до ревью намеренно: конфликт всё равно вернул бы задачу, но уже после сорока минут работы ревьюера и потраченных лимитов.
+
+          Задача переведена в \`S6-in-progress\`. Осталось:
+
+          1. \`git fetch origin\`, затем \`git rebase origin/dev\` в ветке задачи, разрешить конфликт;
+          2. запушить ветку;
+          3. вернуть метку \`S7-code-review\`.
+
+          [Прогон](${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}).
+          EOF
+          gh issue comment "$NUM" --repo "${{ github.repository }}" --body-file /tmp/stale.md
+          gh issue edit "$NUM" --repo "${{ github.repository }}" \
+            --add-label S6-in-progress --remove-label S7-code-review
+          echo "S7-code-review -> S6-in-progress (ревью не запускалось)"
+
+      # Ревьюер перегонял tsc, юниты и сборку заново в каждом раунде, хотя
+      # Validate на том же SHA уже зелёный (#343). Это не тщательность: бюджет
+      # ревью тратится на повторение CI вместо чтения кода.
+      #
+      # Доказательство здесь такое же строгое, как у reuse-маркеров (#208): не
+      # «недавно было зелено», а «completed success ровно на этом SHA». После
+      # ребейза SHA другой, прогона для него нет — и ревьюер честно гоняет сам.
+      - name: Зелёные гейты на этом SHA
+        id: validated
+        if: steps.rebase.outputs.conflict != 'true'
+        env:
+          GH_TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
+        run: |
+          sha=$(git rev-parse HEAD)
+          short=$(git rev-parse --short HEAD)
+          row=$(gh run list --repo "${{ github.repository }}" --workflow validate.yml \
+            --commit "$sha" --limit 5 \
+            --json status,conclusion,url \
+            --jq '[.[] | select(.status=="completed" and .conclusion=="success")][0] // empty')
+          {
+            echo 'note<<EOF_NOTE'
+            if [ -n "$row" ]; then
+              url=$(printf '%s' "$row" | node -e 'let s="";process.stdin.on("data",d=>s+=d).on("end",()=>process.stdout.write(JSON.parse(s).url||""))')
+              echo "**Дешёвые гейты на этом SHA уже подтверждены** (#343). Validate на \`$short\` завершился success: $url"
+              echo ""
+              echo "Значит \`npx tsc --noEmit\`, \`npm test\` и \`npm run build\` со сверкой копий бандла перегонять не нужно — сошлись на этом прогоне, назвав его ссылкой. Бюджет раунда тратится на чтение кода."
+              echo ""
+              echo "Что Validate НЕ покрывает и остаётся за тобой: смоки, выбранные по диффу; golden, если diff трогает рендер; инварианты модели на конкретной конфигурации; и любой гейт, который требуют AC задачи."
+            else
+              echo "**Зелёного Validate на этом SHA (\`$short\`) нет** — прогон не найден, не завершён либо не success. Дешёвые гейты прогоняешь сам и называешь результат."
+            fi
+            echo 'EOF_NOTE'
+          } >> "$GITHUB_OUTPUT"
+          if [ -n "$row" ]; then echo "Validate на $short: зелёный"; else echo "Validate на $short: зелёного нет"; fi
+
+      # Зависимости ставятся ПОСЛЕ переключения на ветку задачи: lockfile мог
+      # измениться именно в ней, и установка по копии из dev дала бы не то дерево.
+      - name: Установить зависимости
+        if: steps.rebase.outputs.conflict != 'true'
+        run: npm ci
+
+      # Браузер нужен не всякому ревью (см. правило выбора гейтов в промпте),
+      # но когда нужен — качать его заново дороже, чем держать в кэше.
+      - name: Кэш браузеров Playwright
+        id: pw
+        if: steps.rebase.outputs.conflict != 'true'
+        uses: actions/cache@v6
+        with:
+          path: ~/.cache/ms-playwright
+          key: playwright-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
+
+      - name: Установить Chromium
+        if: steps.rebase.outputs.conflict != 'true' && steps.pw.outputs.cache-hit != 'true'
+        # Без --with-deps: системные библиотеки Chromium предустановлены в
+        # образе ubuntu-latest, а apt при промахе кэша съедал минуты из бюджета
+        # ревью и подолгу перебирал недоступное azure-зеркало (#175). Если
+        # библиотека когда-нибудь пропадёт из образа, Chromium не запустится с
+        # внятной ошибкой — тогда флаг вернуть.
+        run: npx playwright install chromium
+
+      - name: Review
+        id: review
+        if: steps.rebase.outputs.conflict != 'true'
+        uses: anthropics/claude-code-action@v1
+        env:
+          # Вне рабочей копии: восстановление дерева ревьюером не должно
+          # уничтожать его собственный артефакт (#220).
+          REVIEW_DOC: ${{ runner.temp }}/review-document.md
+        with:
+          # Подписка, а не отдельный счёт API: токен выпускается через
+          # `claude setup-token` (Pro/Max). Действуют лимиты подписки.
+          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
+          prompt: |
+            Ты ревьюер проекта House Plan. Язык ответа — русский.
+
+            Issue: #${{ github.event.issue.number }}
+            Репозиторий: ${{ github.repository }}
+            Этап: ${{ needs.guard.outputs.stage }}
+              spec — ревью ТЗ (PROCESS.md §2.4)
+              code — код-ревью (PROCESS.md §2.7)
+            Заход: r${{ needs.guard.outputs.cycle }} · блокирующих циклов израсходовано ${{ needs.guard.outputs.spent }} из ${{ needs.guard.outputs.limit }}
+              Бюджет §4 тратят только жёлтые и красные вердикты: зелёный
+              ничего не вернул на правки и цикла не образует (#227).
+              Номер захода нужен для имени документа — два документа с
+              одинаковым номером затёрли бы друг друга.
+
+            ${{ steps.rebase.outputs.note }}
+
+            **Если цикл не первый — объём разбора по дельте, а не заново**
+            (PROCESS.md §2.9, issue #214). Раньше промпт был одинаковым для
+            всех раундов, и повторный цикл заново выводил продуктовую рамку и
+            перепроверял AC, которых правка не касалась: r2 по #150 стоил
+            полного прогона ради одной строки в тестовой фикстуре.
+
+            Порядок для r2 и дальше:
+              1. найди вердикт предыдущего раунда в комментариях issue и SHA,
+                 на котором он получен. SHA в вердикте не назван — это находка;
+              2. объяви дельту: `git diff <тот SHA>..HEAD` для кода, дифф файла
+                 ТЗ или тела issue для spec. Дельта — предмет этого раунда;
+              3. по каждой находке предыдущего раунда покажи, чем именно она
+                 закрыта: строка кода или текста, а не заявление автора;
+              4. заново проверяй только те AC, чьё доказательство дельта
+                 задевает. Остальные наследуй;
+              5. в документе обязателен раздел «Унаследовано из r<N-1>»: что
+                 принято без повторной проверки, со ссылкой на документ того
+                 раунда и SHA, на котором вывод получен. Без этого перечня
+                 сокращение — молчаливое доверие, а такой тихий успех уже
+                 дважды стоил дня (#171, #207).
+
+            Разбор остаётся ПОЛНЫМ, если дельта не локальна: ребейз на ушедший
+            вперёд dev (после ребейза это другой код, §7.2), смена контракта
+            поведения, задета новая подсистема, либо объём дельты сопоставим с
+            исходной задачей. Сомневаешься — разбирай полностью и скажи почему.
+
+            Сокращается объём РАЗБОРА, а не строгость: правка по замечанию
+            способна сломать AC, который предыдущий раунд признал выполненным —
+            так появилась регрессия #102. Поэтому граница не «только находки», а
+            «находки плюс всё, до чего дотягивается дельта».
+
+            Прочитай в этом порядке, прежде чем судить:
+              1. docs/SCOPE.md — зачем продукт существует и для кого. Он
+                 ограничитель: «features are built, improved and accepted only
+                 if they serve a job listed here». Первый вопрос к задаче —
+                 какую строку Core user jobs она закрывает.
+              2. AGENTS.md и PROCESS.md — процесс, классы изменений, трейлеры,
+                 лимит циклов, формат вердикта.
+              3. Тело issue #${{ github.event.issue.number }} и все комментарии.
+              4. Если меняется видимое поведение — docs/USER-GUIDE.ru.md:
+                 терминология интерфейса берётся оттуда, а не изобретается.
+              5. Канонический документ затронутой подсистемы: docs/SUN.md,
+                 LIGHT.md, CANVAS.md, WALL-THICKNESS.md, UX-MODES.md,
+                 CONFIG-COMPATIBILITY.md, TOUCH-SUPPORT.md.
+
+            Для этапа spec: если issue помечен small, ТЗ живёт в теле issue и
+            файла в docs/specs/ быть не должно. Иначе ТЗ — docs/specs/<NN>-*.md.
+            Проверь обязательные разделы §7.1, однозначность каждого AC и
+            указание способа доказательства. Отдельно проверь, что автор не
+            выдал догадку за решение: утверждение о поведении, которого нет ни
+            в одном документе и которое не помечено как предположение, —
+            замечание. Не бывает сложной задачи без единого открытого вопроса.
+
+            Владельцу задаются только продуктовые вопросы: что человек видит или
+            делает и каков объём видимых изменений в этом issue. Технический
+            вопрос, вынесенный владельцу, — тоже замечание: ты его снимаешь и
+            решаешь по существу в своём вердикте.
+
+            Для этапа code: материал — диапазон `git log --oneline origin/dev..HEAD`
+            и `git diff origin/dev...HEAD`. Ручного тестирования в цикле нет,
+            поэтому именно ты отвечаешь на вопрос «оно вообще работает».
+            По каждому AC: либо он доказан автотестом и ты убедился, что тест
+            умеет падать, либо разобран по коду с явной записью «проверено
+            чтением, не исполнением». «Verified» без названной команды и её
+            результата доказательством не является. Зависимости уже установлены
+            workflow, Chromium тоже — `npm ci` выполнять не нужно. Проверь
+            трейлеры Issue и User-Visible, при User-Visible: yes — правки в оба
+            changelog в том же коммите.
+
+            **Объём гейтов соразмерен задаче.** Прогонять весь набор на каждой
+            правке — не тщательность, а потеря времени: полные наборы это
+            предрелизный гейт (PROCESS.md §8), а не гейт ревью.
+
+            ${{ steps.validated.outputs.note }}
+
+            Если зелёного прогона на этом SHA нет — прогоняешь сам, они дешёвые,
+            и в повторном раунде тоже: код изменился, а стоят они минуты:
+              `npx tsc --noEmit`, `npm test`, `npm run build` со сверкой трёх
+              копий бандла. Плюс `node scripts/check-docs.mjs`, если diff трогает
+              `src/**`: отпечаток скриншотов документации считается по всему
+              `src/**`, поэтому любая правка фронтенда делает его устаревшим —
+              выбирать тут нечего. Пропуск этого шага в #230 и #234 оставил `dev`
+              с красным job `docs` до следующей задачи (#237).
+
+            Если diff трогает геометрию или ссылки на неё — рёбра комнат,
+            записи толщины, `layout`, `marker.space`, `open_spans` — обязательны
+            инварианты модели (#254): `npm test` уже гоняет их на всех моделях
+            проекта, а на конкретной конфигурации они проверяются командой
+            `npm run invariants -- --config <экспорт или ответ config/get>`.
+            Три вопроса, на которые они отвечают, и все три уже стоили
+            продукту дефектов: не исчезла ли запись толщины (#253), разрешима ли
+            каждая ссылка (#244, #252) и равен ли ключ записи толщины ключу
+            решёточного ребра (#258, #259). Последний сравнивает строки без
+            допусков: сдвиг ключа на один шаг решётки равен допуску первых двух,
+            поэтому они на нём промахиваются. Если задача меняет геометрию, а
+            инварианты в отчёте не названы — это непрогнанный гейт, а не мелочь.
+
+            По необходимости, и «необходимость» определяется diff'ом и AC:
+              - браузерные смоки `demo/smoke_*.mjs` — названные в AC плюс те,
+                что печатает `node scripts/smoke-select.mjs --base <base> --head <head>`.
+                Сколько их всего — считает `ls demo/smoke_*.mjs | wc -l`; вшитое
+                в этот текст число трижды расходилось с деревом, поэтому его
+                здесь больше нет. Прогон всех уместен только когда задача
+                действительно задевает всё. Выбирать по теме недостаточно: регресс #234 поймал
+                `smoke_wall_junctions`, который по названию про стыки стен, а не
+                про толщину отрезка. Инструмент печатает три вида ответа, и они
+                разные: «прямое совпадение» — смок называет изменённый символ,
+                «зарегистрированная связь» — смок проверяет следствие контракта,
+                не называя его, «НЕОПРЕДЕЛЁННОСТЬ» — связь не доказана, и это не
+                разрешение ничего не прогонять. Вывод инструмента прикладывается
+                к комментарию ревью вместе с решением по каждой строке: прогнал
+                либо не прогнал и почему. Слабые связи (одно распространённое
+                имя) — повод посмотреть, а не обязанность прогонять;
+              - `npm run golden:verify` — если diff может изменить видимый
+                результат: рендер, геометрия, стили, слои;
+              - `python -m pytest tests_backend -q` — если тронут
+                `custom_components/**/*.py`;
+              - performance-профили — если названы в AC либо тронуты
+                чувствительные к перфу пути.
+
+            **Одно число — один источник.** Если дифф добавляет или меняет
+            величину, видимую пользователю, назови в отчёте прямо: какое число
+            видно дважды (превью против записи, подпись против площади,
+            подсветка инструмента против сохранённого значения) и один ли у него
+            источник. Три дефекта подряд имели именно эту причину — #234, #233 и
+            способ, которым #234 обнаружили. Механическая часть закреплена
+            тестом `test/single-source-numbers.test.mjs`, смысловая — твоя.
+
+            Дисциплина «тест должен уметь падать» не отменяется, но применяется к
+            тем тестам, которые ты прогонял.
+
+            **В комментарии обязателен перечень: какие гейты прогнал, какие нет и
+            почему.** Это условие честности такого сужения: непрогнанный гейт
+            становится видимым решением, а не молчаливым пропуском. Раздел «чего
+            не проверял» в документе ревью — не формальность, а главный его
+            раздел на коротких задачах.
+
+            Ты НЕ правишь ни ТЗ, ни продуктовый код. Только оцениваешь.
+
+            Серьёзность: High блокирует; Medium В СКОУПЕ задачи чинится в ней
+            же — без High это жёлтый вердикт и возврат автору, отдельный issue
+            НЕ заводится (решение владельца 2026-08-19, #202: заведение и
+            обслуживание issue дороже правки на месте); Low либо правится,
+            либо снимается с записью. Жёлтый вердикт допустим и при полностью
+            выполненных AC, если изменение не решает заявленный сценарий или
+            ухудшает смежный. Продуктовое рассуждение расширяет вопросы, но не
+            отменяет AC и не даёт права менять скоуп.
+
+            Только Medium-находку ВНЕ скоупа задачи (попутный дефект соседнего
+            поведения, который в этой ветке чинить нельзя) заведи отдельным
+            issue со ссылкой на #${{ github.event.issue.number }} и метками:
+            тип, приоритет, S1-new. «Оставили в тексте ревью» закрытием не
+            считается и прямо запрещено §12.
+
+            Напиши полный документ ревью в файл, путь которого лежит в
+            переменной окружения REVIEW_DOC (абсолютный, ВНЕ репозитория).
+
+            Почему не в docs/reviews: документ там был некоммитнутым файлом того
+            же дерева, которое ты мутируешь, проверяя «умеет ли тест падать». На
+            #220 три раунда подряд документ исчезал — восстановление дерева
+            (`git checkout -- .`, `git clean -fd`) сносит собственный артефакт
+            ревью, потому что он untracked. В репозиторий его положит шаг
+            публикации, взяв из REVIEW_DOC; тебе трогать docs/reviews не нужно.
+
+            В самом репозитории не создавай файлов вообще: любые изменения в
+            рабочей копии будут отброшены. Имя документа в docs/reviews шаг
+            публикации соберёт сам — SPEC-REVIEW для этапа spec, CODE-REVIEW для
+            code, с номером issue и заходом.
+
+            Содержание документа: скоуп, как проверялось, находки с
+            воспроизведением, что проверено и корректно, чего не проверял. Для
+            r2 и дальше добавь два раздела: «Закрытие раунда r<N-1>» — таблица
+            «находка | чем закрыта | где это видно», и «Унаследовано из r<N-1>» —
+            что принято без повторной проверки, с документом и SHA.
+
+            Затем оставь в issue краткий комментарий: вердикт, ключевые находки
+            и ссылка на документ. Первой строкой — вердикт в формате §7.2:
+            `Вердикт: зелёный/жёлтый/красный · заход r${{ needs.guard.outputs.cycle }} · блокирующих циклов ${{ needs.guard.outputs.spent }}/${{ needs.guard.outputs.limit }} · High: N · Medium: N → в задаче | #…`
+            («→ #…» — только у Medium вне скоупа; находки в скоупе возвращаются автору жёлтым)
+
+            Затем верни JSON по схеме. Это последнее действие и оно обязательно:
+            без него метка не переставится и конвейер встанет.
+          claude_args: |
+            --max-turns 150
+            --allowedTools Read,Write,Grep,Glob,Bash,mcp__github__add_issue_comment,mcp__github__issue_write,mcp__github__issue_read
+            --json-schema '{"type":"object","properties":{"verdict":{"type":"string","enum":["green","yellow","red"]},"high":{"type":"integer"},"medium":{"type":"integer"},"summary":{"type":"string"}},"required":["verdict","high","medium","summary"]}'
+
+      # Ревьюер пишет только в docs/reviews/. Что именно попадёт в коммит,
+      # решает этот шаг, а не модель: всё остальное откатывается.
+      - name: Опубликовать документ ревью
+        if: steps.rebase.outputs.conflict != 'true'
+        env:
+          TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
+          BRANCH: ${{ steps.branch.outputs.name }}
+          NUM: ${{ github.event.issue.number }}
+          STAGE: ${{ needs.guard.outputs.stage }}
+          CYCLE: ${{ needs.guard.outputs.cycle }}
+          SOURCE: ${{ runner.temp }}/review-document.md
+        run: |
+          # Ветки задачи может не быть: у задач, размеченных до появления
+          # конвейера, ТЗ лежит прямо в dev. Раньше шаг в этом случае молча
+          # выходил с нулём, и разбор ревью терялся — оставался только вердикт
+          # комментарием. Это тот же тихий отказ: шаг сообщал об успехе тем, что
+          # ничего не сделал. Документ ложится туда же, где лежит само ТЗ.
+          target="${BRANCH:-dev}"
+          if [ -z "$BRANCH" ]; then
+            echo "::warning::ветки задачи нет — документ ревью ляжет в dev"
+          fi
+          marker=CODE-REVIEW
+          if [ "$STAGE" = "spec" ]; then marker=SPEC-REVIEW; fi
+          doc="docs/reviews/${marker}-${NUM}-r${CYCLE}.md"
+          # Документ спасается ПЕРВЫМ делом. Ревьюер мог написать его по старому
+          # пути прямо в рабочую копию, а дальше эта копия будет отброшена
+          # целиком — и вместе с ней пропал бы артефакт (#220).
+          if [ ! -f "$SOURCE" ] && [ -f "$doc" ]; then
+            cp "$doc" "$SOURCE"
+            echo "документ найден в рабочей копии и сохранён в $SOURCE"
+          fi
+          # Reset, а не checkout+clean, и вот почему (#365).
+          #
+          # 28.08 коммит bb2919f уехал в dev с тридцатью файлами вместо одного
+          # markdown: откатил отревьюженную реализацию #359, вернул старые чанки
+          # и держал dev откаченным три часа. Механизм воспроизведён:
+          # `git checkout -- .` восстанавливает рабочее дерево ИЗ ИНДЕКСА, а
+          # `git clean -fd` убирает неотслеживаемое — ни то, ни другое индекс не
+          # трогает. Ревьюер работает с Bash и в ходе проверки «умеет ли тест
+          # падать» вполне может сделать `git add`; всё, что осталось у него в
+          # индексе, прежняя уборка сохраняла, и следующий же `git commit`
+          # забирал это вместе с документом. Сообщение при этом невинное, и от
+          # рутины инцидент отличается только диффом.
+          #
+          # `reset --hard` снимает и индекс, и дерево разом. Терять нечего:
+          # документ приезжает извне репозитория, из RUNNER_TEMP.
+          git fetch -q origin "$target"
+          git reset -q --hard "origin/$target"
+          git clean -fdq -e node_modules >/dev/null 2>&1 || true
+          # Документ приезжает извне репозитория (#220). Три раунда подряд он
+          # терялся, пока лежал некоммитнутым файлом в том же дереве, которое
+          # ревьюер мутирует и затем восстанавливает: `git checkout -- .` плюс
+          # `git clean -fd` сносят собственный артефакт ревью, потому что он
+          # untracked. Теперь его место — RUNNER_TEMP, и уборка дерева ему не
+          # страшна.
+          if [ -f "$SOURCE" ]; then
+            mkdir -p docs/reviews
+            cp "$SOURCE" "$doc"
+            echo "документ взят из $SOURCE ($(wc -c < "$doc") байт)"
+          else
+            echo "::warning::$SOURCE не найден — документа для публикации нет"
+          fi
+          # Индексируется ровно один путь, а не каталог: `git add docs/reviews`
+          # забрал бы всё, что там окажется, а после reset там не должно быть
+          # ничего постороннего — но полагаться на «не должно» здесь нельзя.
+          git add -- "$doc" 2>/dev/null || true
+          if git diff --cached --quiet; then
+            # Пустая рабочая копия — ещё не провал: ревьюер иногда коммитит
+            # документ сам, своим app-токеном мимо этого шага (CODE-REVIEW-150-r1,
+            # коммиттер GitHub). Провал — когда файла нет и на ветке.
+            git fetch -q origin "$target"
+            if git cat-file -e "origin/$target:$doc" 2>/dev/null; then
+              echo "документ уже опубликован ревьюером: $doc"
+              exit 0
+            fi
+            # Ревью без артефакта запрещено (PROCESS.md §2.4/§10.4/§12). Раньше
+            # здесь стоял warning с exit 0: на #150 оба вердикта ревью ТЗ
+            # остались только комментариями, метки переставились, и пропажу
+            # заметило лишь следующее ревью — issue #171. Падение ДО шага с
+            # меткой сохраняет инвариант «метка не сменилась = прогон упал».
+            echo "::error::вердикт есть, а документа нет: ни $SOURCE, ни $doc в рабочей копии, ни $doc в $target — ревью без артефакта (#171, #220)"
+            exit 1
+          fi
+          # Первый рубеж: что вообще проиндексировано.
+          git diff --cached --name-only | node scripts/review-doc-guard.mjs
+          git -c user.name="claude[bot]" \
+              -c user.email="209825114+claude[bot]@users.noreply.github.com" \
+              commit -q -F - <<EOF
+          docs: review document for #$NUM
+
+          Issue: #$NUM
+          User-Visible: no
+          EOF
+          # Второй рубеж, и он главный: что пуш ДОБАВИТ в целевую ветку. Первый
+          # судит намерение шага, этот — результат, а расходились они именно
+          # тогда, когда база оказывалась не той.
+          git diff --name-only "origin/$target...HEAD" | node scripts/review-doc-guard.mjs
+          # Публикация в dev идёт из детачнутого состояния поверх ветки задачи
+          # либо dev, поэтому push нужен с явным перебазированием при гонке:
+          # dev мог уйти вперёд, пока шло ревью — оно длится до 45 минут.
+          if ! git push -q "https://x-access-token:$TOKEN@github.com/${{ github.repository }}" \
+               "HEAD:$target"; then
+            git fetch -q origin "$target"
+            if ! git -c user.name="claude[bot]" \
+                     -c user.email="209825114+claude[bot]@users.noreply.github.com" \
+                     rebase "origin/$target"; then
+              git rebase --abort || true
+              # Тоже вердикт без артефакта: раньше exit 0 переставил бы метку.
+              echo "::error::документ ревью не удалось опубликовать в $target: конфликт (#171)"
+              exit 1
+            fi
+            # После ребейза набор путей другой — проверяется заново. Форс здесь
+            # запрещён и не появляется: ветка двигается только вперёд.
+            git diff --name-only "origin/$target...HEAD" | node scripts/review-doc-guard.mjs
+            git push -q "https://x-access-token:$TOKEN@github.com/${{ github.repository }}" \
+              "HEAD:$target"
+          fi
+          # Постусловие: до ветки дошёл именно ожидаемый файл. Коммит с
+          # документом, названным не по формату, — тот же вердикт без
+          # артефакта, только дороже в обнаружении.
+          git fetch -q origin "$target"
+          if ! git cat-file -e "origin/$target:$doc" 2>/dev/null; then
+            echo "::error::коммит в $target опубликован, но ожидаемого $doc в нём нет — файл назван не по формату (#171)"
+            exit 1
+          fi
+          echo "документ опубликован в $target: $doc"
+
+      - name: Решение по вердикту
+        id: decide
+        if: steps.rebase.outputs.conflict != 'true'
+        env:
+          OUT: ${{ steps.review.outputs.structured_output }}
+          STAGE: ${{ needs.guard.outputs.stage }}
+        run: |
+          verdict=$(echo "$OUT" | jq -r '.verdict')
+          high=$(echo "$OUT" | jq -r '.high')
+          echo "вердикт: $verdict, High: $high"
+
+          # Вперёд двигает ТОЛЬКО зелёный. Жёлтый и красный возвращают
+          # автору: на прогоне #111 жёлтый означал, что AC описывает неверное
+          # изменение контракта — реализовать такое ТЗ значит сделать ошибку
+          # по инструкции. Оба считаются циклом.
+          if [ "$verdict" = "green" ] && [ "$high" -eq 0 ]; then
+            green=true
+            case "$STAGE" in
+              spec) from=S4-spec-review; to=S5-ready ;;
+              code) from=S7-code-review; to=S8-merged ;;
+            esac
+          else
+            green=false
+            case "$STAGE" in
+              spec) from=S4-spec-review; to=S3-spec ;;
+              code) from=S7-code-review; to=S6-in-progress ;;
+            esac
+          fi
+          echo "green=$green" >> "$GITHUB_OUTPUT"
+          echo "from=$from"   >> "$GITHUB_OUTPUT"
+          echo "to=$to"       >> "$GITHUB_OUTPUT"
+
+      # Ревью идёт десятки минут, а dev за это время двигается (28 августа —
+      # четыре раза за день). Вердикт при этом вынесен по дереву, которое уже не
+      # совпадает с вершиной линии, и слияние приведёт ветку к dev — то есть в
+      # dev уедет код, отличный от прочитанного (§7.2). Молчать об этом нельзя,
+      # но и шуметь на каждом прогоне ни к чему: строка появляется только когда
+      # dev действительно ушёл и вердикт зелёный, то есть слияние вот-вот
+      # случится (#364).
+      - name: dev ушёл вперёд, пока шло ревью
+        if: steps.rebase.outputs.conflict != 'true' && needs.guard.outputs.stage == 'code'
+        env:
+          GH_TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
+          NUM: ${{ github.event.issue.number }}
+          MATERIAL: ${{ steps.material.outputs.sha }}
+          GREEN: ${{ steps.decide.outputs.green }}
+        run: |
+          git fetch -q origin dev
+          moved=$(git rev-list --count "$MATERIAL..origin/dev")
+          echo "dev продвинулся на $moved коммит(ов) с момента фиксации материала"
+          echo "- dev продвинулся на **$moved** коммит(ов) во время ревью" >> "$GITHUB_STEP_SUMMARY"
+          if [ "$moved" -eq 0 ] || [ "$GREEN" != "true" ]; then exit 0; fi
+          short=$(git rev-parse --short "$MATERIAL")
+          gh issue comment "$NUM" --repo "${{ github.repository }}" --body \
+            "Пока шло ревью, \`dev\` продвинулся на $moved коммит(ов). Материал ревью — \`$short\`. Вердикт вынесен по дереву, которое уже не совпадает с вершиной линии: слияние приведёт ветку к dev, и это другой код (§7.2)."
+
+      # S8-merged утверждает, что код в dev. Значит слияние обязано произойти
+      # ДО метки, иначе она врёт в промежутке.
+      #
+      # При конфликте шаг НЕ падает и метку не оставляет на месте. Первая
+      # редакция делала именно так, и это оказалось тупиком: автор ждёт смену
+      # метки, метка не менялась, и он тридцать раз опрашивал впустую, чтобы
+      # затем отчитаться «лимит исчерпан» — при зелёном вердикте. Инвариант
+      # теперь жёстче: ПОСЛЕ ПРОГОНА РЕВЬЮ МЕТКА МЕНЯЕТСЯ ВСЕГДА.
+      - name: Слить ветку в dev
+        id: merge
+        if: needs.guard.outputs.stage == 'code' && steps.decide.outputs.green == 'true'
+        env:
+          TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
+          GH_TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
+          BRANCH: ${{ steps.branch.outputs.name }}
+          NUM: ${{ github.event.issue.number }}
+          MATERIAL_SHA: ${{ steps.material.outputs.sha }}
+        run: |
+          if [ -z "$BRANCH" ]; then
+            echo "::error::ветки задачи нет — сливать нечего"
+            echo "merged=false" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
+          git fetch -q origin dev "$BRANCH"
+          # #312: сливается только проверенный код. Допустимые вершины ветки:
+          # сам SHA материала либо он же плюс ровно один коммит публикации
+          # документа ревью (дифф только docs/reviews/). Любой другой коммит —
+          # ветка уехала после ревью, вердикт к ней не применим: возврат в
+          # S6-in-progress через merged=false, как при конфликте.
+          actual=$(git rev-parse "origin/$BRANCH")
+          reviewed="$MATERIAL_SHA"
+          fresh=false
+          if [ "$actual" = "$reviewed" ]; then
+            fresh=true
+          elif [ "$(git rev-parse "$actual^" 2>/dev/null)" = "$reviewed" ] \
+            && [ -z "$(git diff --name-only "$reviewed" "$actual" -- . ':!docs/reviews')" ]; then
+            fresh=true
+          fi
+          if [ "$fresh" != true ]; then
+            echo "merged=false" >> "$GITHUB_OUTPUT"
+            echo "::warning::ветка $BRANCH уехала после проверенного SHA $reviewed (сейчас $actual) — слияние отменено (#312)"
+            cat > /tmp/stale-verdict.md <<EOF
+          **Слияние отменено: ветка изменилась после проверенного материала (#312).**
+
+          Ревью выполнялось на \\`$(git rev-parse --short "$reviewed")\\`, а вершина ветки сейчас \\`$(git rev-parse --short "$actual")\\` — в ней есть коммиты, которых вердикт не покрывает. Зелёный вердикт остаётся в силе только для проверенного SHA.
+
+          Задача переведена в \\`S6-in-progress\\`. Дальше: убедиться, что вершина ветки — именно то, что должно ехать в dev, и вернуть метку \\`S7-code-review\\` — новый заход ревью проверит актуальный код.
+          EOF
+            gh issue comment "$NUM" --repo "${{ github.repository }}" --body-file /tmp/stale-verdict.md
+            exit 0
+          fi
+          git checkout -q -B merge-into-dev "$actual"
+          if ! git -c user.name="claude[bot]" \
+                   -c user.email="209825114+claude[bot]@users.noreply.github.com" \
+                   rebase origin/dev; then
+            git rebase --abort || true
+            echo "merged=false" >> "$GITHUB_OUTPUT"
+            echo "::warning::ветка $BRANCH не сливается в dev без конфликта"
+            cat > /tmp/conflict.md <<EOF
+          **Код-ревью зелёное — вердикт выше в силе, переделывать работу не нужно.** Не удалось только слияние: ветка \`$BRANCH\` конфликтует с \`dev\`.
+
+          Задача переведена в \`S6-in-progress\`, потому что работа вернулась к автору. Осталась не правка кода, а ребейз:
+
+          1. \`git fetch origin\`, затем \`git rebase origin/dev\` в ветке задачи, разрешить конфликт;
+          2. запушить ветку;
+          3. вернуть метку \`S7-code-review\`.
+
+          Повторный прогон ревью — не формальность: после ребейза на новый \`dev\` это другой код, и принимать его без проверки нельзя. Цикл считается по этапу, лимит на код-ревью тратится отдельно от ревью ТЗ.
+          EOF
+            gh issue comment "$NUM" --repo "${{ github.repository }}" --body-file /tmp/conflict.md
+            exit 0
+          fi
+          git push -q "https://x-access-token:$TOKEN@github.com/${{ github.repository }}" HEAD:dev
+          echo "merged=true" >> "$GITHUB_OUTPUT"
+          echo "слито в dev: $(git rev-parse --short HEAD)"
+
+      - name: Переставить метку
+        if: steps.rebase.outputs.conflict != 'true'
+        env:
+          # Именно PAT: с GITHUB_TOKEN следующий шаг конвейера не запустится.
+          GH_TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
+          NUM: ${{ github.event.issue.number }}
+          FROM: ${{ steps.decide.outputs.from }}
+          # Зелёное код-ревью без слияния ведёт не в S8-merged, а обратно к
+          # автору: метка утверждала бы, что код в dev, а его там нет.
+          TO: ${{ (needs.guard.outputs.stage == 'code' && steps.decide.outputs.green == 'true' && steps.merge.outputs.merged != 'true') && 'S6-in-progress' || steps.decide.outputs.to }}
+        run: |
+          gh issue edit "$NUM" --repo "${{ github.repository }}" \
+            --add-label "$TO" --remove-label "$FROM"
+          echo "$FROM -> $TO"
+
+      - name: Позвать владельца, если ревью упало
+        if: failure()
+        env:
+          GH_TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
+          RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
+        run: |
+          # Тело через heredoc, а не многострочный --body: строка с нулевым
+          # отступом обрывает блок YAML и оставляет незакрытую кавычку.
+          cat > /tmp/failure.md <<EOF
+          Автоматическое ревью не отработало: [прогон]($RUN_URL). Статусная метка не менялась, задача осталась на месте.
+
+          Если вердикт выше всё же опубликован — сбой произошёл после него. Перестановку метки в этом случае выполняет чат обслуживания или владелец, но не автор задачи: автор не толкует вердикт о своей же работе.
+          EOF
+          gh issue comment "${{ github.event.issue.number }}" \
+            --repo "${{ github.repository }}" --body-file /tmp/failure.md
@@ -12,7 +12,6 @@ on:
 permissions:
  contents: write
  actions: read
-  issues: read

 concurrency:
  group: publish-prerelease-${{ inputs.tag }}
@@ -21,20 +20,18 @@ concurrency:
 jobs:
  gate:
    name: "Гейт: зелёная Проверка и релизный контракт"
-    runs-on: ubuntu-24.04
-    # Больше ожидания зелёного Validate в release-gate.mjs (до 60 мин) (#658).
-    timeout-minutes: 75
+    runs-on: ubuntu-latest
    outputs:
      sha: ${{ steps.candidate.outputs.sha }}
      tag: ${{ steps.candidate.outputs.tag }}
    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+      - uses: actions/checkout@v7
        with:
          ref: ${{ github.sha }}
          fetch-depth: 0
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
+      - uses: actions/setup-node@v7
        with: { node-version: 22 }
-      - name: Pin the dev candidate or the existing annotated tag
+      - name: Pin the current dev candidate
        id: candidate
        env:
          TAG: ${{ inputs.tag }}
@@ -45,105 +42,42 @@ jobs:
            echo "::error::Prereleases must be dispatched from the dev branch, got $REF_NAME"
            exit 1
          }
-          DISPATCHED_SHA=$(git rev-parse HEAD)
-          git fetch --force origin dev --tags
-          REMOTE=$(git ls-remote --tags origin "refs/tags/$TAG" "refs/tags/$TAG^{}")
-          if [ -n "$REMOTE" ]; then
-            SHA=$(printf '%s\n' "$REMOTE" | awk -v ref="refs/tags/$TAG^{}" '$2 == ref {print $1}')
-            test -n "$SHA" || {
-              echo "::error::Existing remote tag $TAG is not annotated"
-              exit 1
-            }
-          else
-            SHA=$DISPATCHED_SHA
-            test "$(git rev-parse origin/dev)" = "$SHA" || {
-              echo "::error::The dispatched SHA is no longer the origin/dev tip"
-              exit 1
-            }
-          fi
-          git checkout --detach "$SHA"
+          SHA=$(git rev-parse HEAD)
+          git fetch origin dev
+          test "$(git rev-parse origin/dev)" = "$SHA" || {
+            echo "::error::The dispatched SHA is no longer the origin/dev tip"
+            exit 1
+          }
          echo "sha=$SHA" >> "$GITHUB_OUTPUT"
          echo "tag=$TAG" >> "$GITHUB_OUTPUT"
      - name: Verify version, changelogs and bilingual release notes
        env:
          TAG: ${{ inputs.tag }}
        run: node scripts/release-contract.mjs "$TAG" --repo="$GITHUB_REPOSITORY"
-      # #479: тяжёлые job Validate идут только на коммите с трейлером `Release:`.
-      # Зелёный Validate без трейлера означал бы прогон без смоков и golden —
-      # класс тихого пропуска #171/#207, поэтому трейлер проверяется здесь явно.
-      - name: Require the Release trailer on the candidate commit
-        env:
-          SHA: ${{ steps.candidate.outputs.sha }}
-        run: |
-          set -euo pipefail
-          git log -1 --format=%B "$SHA" > /tmp/head-message.txt
-          if ! grep -Eq '^Release:[[:space:]]*v?[0-9]+\.[0-9]+\.[0-9]+' /tmp/head-message.txt; then
-            echo "::error::Candidate $SHA has no Release: trailer — Validate ran without the heavy gates (#479)"
-            exit 1
-          fi
-      # #479: свежесть скриншотов на обычном пуше — предупреждение; на
-      # кандидате она обязана быть доказана строгим режимом.
-      - name: Documentation screenshots are fresh for the candidate
-        run: node scripts/check-docs.mjs --screenshots=strict
      - name: Require green Validate for this exact SHA
        env:
          GH_TOKEN: ${{ github.token }}
          REPO: ${{ github.repository }}
          SHA: ${{ steps.candidate.outputs.sha }}
        run: node scripts/release-gate.mjs "$SHA"
-      - name: Bind issue membership to the exact candidate
-        env:
-          GH_TOKEN: ${{ github.token }}
-          TAG: ${{ steps.candidate.outputs.tag }}
-          SHA: ${{ steps.candidate.outputs.sha }}
-        run: |
-          set -euo pipefail
-          mkdir -p release-membership
-          if gh release view "$TAG" --repo "$GITHUB_REPOSITORY" >/dev/null 2>&1; then
-            gh release download "$TAG" --repo "$GITHUB_REPOSITORY" \
-              --dir release-membership --pattern RELEASE-MEMBERSHIP.json --clobber || true
-          fi
-          if [ -s release-membership/RELEASE-MEMBERSHIP.json ]; then
-            node scripts/release-membership.mjs verify --tag="$TAG" --candidate="$SHA" \
-              --input=release-membership/RELEASE-MEMBERSHIP.json
-          else
-            ISSUES=$(gh issue list --repo "$GITHUB_REPOSITORY" --state open \
-              --label S8-merged --limit 1000 --json number --jq 'map(.number)|join(",")')
-            node scripts/release-membership.mjs create --tag="$TAG" --candidate="$SHA" \
-              --issues="$ISSUES" --allow-unmatched \
-              --output=release-membership/RELEASE-MEMBERSHIP.json
-          fi
-      - name: Preserve candidate membership for publication
-        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
-        with:
-          name: release-membership
-          path: release-membership/RELEASE-MEMBERSHIP.json
-          if-no-files-found: error
-          retention-days: 7

  publish:
    name: Публикация тега и релиза
    needs: gate
-    runs-on: ubuntu-24.04
-    timeout-minutes: 20
+    runs-on: ubuntu-latest
    outputs:
      url: ${{ steps.verify.outputs.url }}
      newly_published: ${{ steps.release.outputs.newly_published }}
    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+      - uses: actions/checkout@v7
        with:
          ref: ${{ needs.gate.outputs.sha }}
          fetch-depth: 0
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
+      - uses: actions/setup-node@v7
        with: { node-version: 22 }
-      - uses: actions/download-artifact@37930b1c2abaa49bbe596cd826c3c89aef350131 # v7
-        with:
-          name: release-membership
-          path: release-assets
      - name: Build and verify both release assets before publication
        env:
          TAG: ${{ needs.gate.outputs.tag }}
-          SHA: ${{ needs.gate.outputs.sha }}
        run: |
          set -euo pipefail
          npm ci
@@ -152,20 +86,11 @@ jobs:
          npm run bundle:budget
          VERSION=${TAG#v}
          grep -RFq "$VERSION" dist
-          # #540: тот же способ, что у release.yml и release-prerelease.mjs —
-          # архив закоммиченного дерева точного коммита, детерминированный.
-          git -c core.autocrlf=false archive --format=zip --output=houseplan.zip \
-            "$SHA:custom_components/houseplan"
+          (cd custom_components/houseplan && zip -qr ../../houseplan.zip .)
          node scripts/verify-houseplan-zip.mjs houseplan.zip \
            custom_components/houseplan/frontend "$VERSION"
          test -s dist/houseplan-card.js
-          test -s dist/houseplan-panel.js
          test -s houseplan.zip
-          mkdir -p release-assets
-          cp dist/houseplan-card.js houseplan.zip release-assets/
-          node scripts/release-membership.mjs verify --tag="$TAG" --candidate="$SHA" \
-            --input=release-assets/RELEASE-MEMBERSHIP.json
-          node scripts/release-assets.mjs sums release-assets --include-membership
      - name: Create or verify the annotated tag
        env:
          TAG: ${{ needs.gate.outputs.tag }}
@@ -204,22 +129,7 @@ jobs:
          fi
          WAS_DRAFT=$(gh release view "$TAG" --repo "$GITHUB_REPOSITORY" --json isDraft --jq .isDraft)
          echo "newly_published=$WAS_DRAFT" >> "$GITHUB_OUTPUT"
-          if [ "$WAS_DRAFT" = "false" ]; then
-            mkdir -p existing-public
-            if gh release download "$TAG" --repo "$GITHUB_REPOSITORY" --dir existing-public \
-                --pattern houseplan-card.js --pattern houseplan.zip \
-                --pattern RELEASE-MEMBERSHIP.json --pattern SHA256SUMS --clobber \
-              && diff -u release-assets/SHA256SUMS existing-public/SHA256SUMS \
-              && node scripts/release-assets.mjs check existing-public release-assets/SHA256SUMS \
-              && node scripts/release-membership.mjs verify --tag="$TAG" --candidate="${{ needs.gate.outputs.sha }}" \
-                --input=existing-public/RELEASE-MEMBERSHIP.json; then
-              echo "release is already public and byte-identical; publication skipped"
-              exit 0
-            fi
-            echo "existing public assets need recovery; verified files will be uploaded again"
-          fi
-          gh release upload "$TAG" release-assets/houseplan-card.js release-assets/houseplan.zip \
-            release-assets/RELEASE-MEMBERSHIP.json release-assets/SHA256SUMS \
+          gh release upload "$TAG" dist/houseplan-card.js houseplan.zip \
            --repo "$GITHUB_REPOSITORY" --clobber
          RELEASE_JSON=$(gh release view "$TAG" --repo "$GITHUB_REPOSITORY" \
            --json tagName,isDraft,isPrerelease,assets,url)
@@ -228,7 +138,7 @@ jobs:
          const release = JSON.parse(process.env.RELEASE_JSON);
          if (release.tagName !== process.env.TAG) throw new Error('release tag mismatch');
          const assets = new Map(release.assets.map((asset) => [asset.name, asset]));
-          for (const name of ['houseplan-card.js', 'houseplan.zip', 'RELEASE-MEMBERSHIP.json', 'SHA256SUMS']) {
+          for (const name of ['houseplan-card.js', 'houseplan.zip']) {
            if (!(Number(assets.get(name)?.size) > 0)) throw new Error(`${name} is missing or empty`);
          }
          NODE
@@ -250,26 +160,17 @@ jobs:
          if (release.tagName !== process.env.TAG || release.isDraft || !release.isPrerelease)
            throw new Error('release is not a public prerelease for the requested tag');
          const assets = new Map(release.assets.map((asset) => [asset.name, asset]));
-          for (const name of ['houseplan-card.js', 'houseplan.zip', 'RELEASE-MEMBERSHIP.json', 'SHA256SUMS']) {
+          for (const name of ['houseplan-card.js', 'houseplan.zip']) {
            if (!(Number(assets.get(name)?.size) > 0)) throw new Error(`${name} is missing or empty`);
          }
          NODE
-          # #540: публичные байты — ровно те, что собраны и проверены выше.
-          mkdir -p public
-          gh release download "$TAG" --repo "$GITHUB_REPOSITORY" --dir public \
-            --pattern houseplan-card.js --pattern houseplan.zip \
-            --pattern RELEASE-MEMBERSHIP.json --pattern SHA256SUMS --clobber
-          diff -u release-assets/SHA256SUMS public/SHA256SUMS
-          node scripts/release-assets.mjs check public release-assets/SHA256SUMS
-          node scripts/release-membership.mjs verify --tag="$TAG" --candidate="$SHA" \
-            --input=public/RELEASE-MEMBERSHIP.json
          test "$(git rev-list -n 1 "$TAG")" = "$SHA"
          URL=$(node -p "JSON.parse(process.env.RELEASE_JSON).url")
          echo "url=$URL" >> "$GITHUB_OUTPUT"
-          printf '### Published %s\n\n- exact SHA: `%s`\n- [GitHub prerelease](%s)\n\n```\n%s```\n' \
-            "$TAG" "$SHA" "$URL" "$(cat public/SHA256SUMS)" >> "$GITHUB_STEP_SUMMARY"
+          printf '### Published %s\n\n- exact SHA: `%s`\n- [GitHub prerelease](%s)\n- assets: `houseplan-card.js`, `houseplan.zip`\n' \
+            "$TAG" "$SHA" "$URL" >> "$GITHUB_STEP_SUMMARY"
      - name: Verify HACS prerelease discovery order
-        uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9
+        uses: actions/github-script@v9
        env:
          EXPECTED_TAG: ${{ needs.gate.outputs.tag }}
        with:
@@ -287,32 +188,26 @@ jobs:
              );
            }

-  # #547: bookkeeping is driven by the immutable candidate manifest, not by the
-  # mutable S8 queue. It also runs on a verified retry of an already-public beta.
+  # PROCESS.md 10.2 item 10: closing issues and stripping status labels happens
+  # because a beta was published, not because someone remembered to do it. The
+  # manual step was skipped twice, and both times it broke the invariant that a
+  # closed issue carries no status label — the one thing `verify` relies on.
+  #
+  # A manual step after a successful release is the worst kind: by the time it is
+  # due, the work already looks finished, which is exactly why it gets forgotten.
  close-merged:
    name: Закрытие вошедших issue
    needs: [gate, publish]
-    runs-on: ubuntu-24.04
-    timeout-minutes: 15
+    if: ${{ needs.publish.outputs.newly_published == 'true' }}
+    runs-on: ubuntu-latest
    permissions:
      contents: read
-      actions: read
      # Deliberately the stock token, not a PAT: events caused by GITHUB_TOKEN do
      # not start workflows, so removing the label cannot wake the review
      # pipeline. A PAT here would build a cascade out of a bookkeeping step.
      issues: write
    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          ref: ${{ needs.gate.outputs.sha }}
-          fetch-depth: 0
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with: { node-version: 22 }
-      - uses: actions/download-artifact@37930b1c2abaa49bbe596cd826c3c89aef350131 # v7
-        with:
-          name: release-membership
-          path: release-membership
-      - name: Finish only the issues proven in the candidate manifest
+      - name: Close the S8-merged queue and strip status labels
        env:
          GH_TOKEN: ${{ github.token }}
          REPO: ${{ github.repository }}
@@ -320,9 +215,33 @@ jobs:
          URL: ${{ needs.publish.outputs.url }}
        run: |
          set -euo pipefail
-          node scripts/release-bookkeeping.mjs --repo="$REPO" --tag="$TAG" \
-            --candidate="${{ needs.gate.outputs.sha }}" --url="$URL" \
-            --membership=release-membership/RELEASE-MEMBERSHIP.json
+          # Only the owner's issues take part in the process; issues filed by
+          # anyone else never carry status labels and are not ours to close.
+          numbers=$(gh issue list --repo "$REPO" --state open --label S8-merged \
+            --author Matysh --limit 100 --json number --jq '.[].number')
+          if [ -z "$numbers" ]; then
+            echo "the S8-merged queue is empty, nothing to close"
+          else
+            for n in $numbers; do
+              gh issue comment "$n" --repo "$REPO" \
+                --body "Выпущено в \`$TAG\` · [релиз]($URL)"
+              # Label first, then close. If the run dies between the two steps an
+              # open issue without a status is visible and fixable in the flow;
+              # the reverse order would recreate the exact breakage this job is
+              # here to prevent.
+              gh issue edit "$n" --repo "$REPO" --remove-label S8-merged
+              gh issue close "$n" --repo "$REPO" --reason completed
+              echo "closed #$n"
+            done
+          fi
+          # Targeted at the defect that actually recurs, not at the invariant in
+          # general: no closed issue may still carry S8-merged.
+          leftover=$(gh issue list --repo "$REPO" --state closed --label S8-merged \
+            --limit 100 --json number --jq 'length')
+          test "$leftover" = "0" || {
+            echo "::error::$leftover closed issues still carry S8-merged"
+            exit 1
+          }

  announce:
    name: Комментарий о публикации
@@ -1,335 +0,0 @@
-name: "Релиз: независимое ревью линии"
-run-name: "Release review ${{ inputs.tag }}"
-
-# #638, PROCESS.md §11.5: перед стабильным релизом — одно независимое ревью
-# поверхностей, изменённых всей линией бет, «с нуля»: без ТЗ и документов
-# раундов, по SCOPE и USER-GUIDE. Инкрементальное ревью судит дифф задачи
-# против её ТЗ; четыре дефекта линии 1.77 (#607, #608, #611, #619) не входили
-# ни в один AC и нашлись только так.
-#
-# Решение владельца 2026-09-25: ревью НЕ блокирует выпуск. `release.yml`
-# запускает этот workflow параллельно гейтам из job, от которого не зависит ни
-# один job выпуска; документ — рекомендация, в работу его берёт владелец.
-#
-# Только `workflow_dispatch`: GitHub исполняет файл с той ветки, на которой
-# запущен прогон (`release.yml` зовёт `--ref dev`), поэтому зеркало в `main`
-# не нужно, а правка — один коммит в `dev`.
-#
-# Три job, как у конвейера (#551, #556): детерминированная подготовка,
-# недоверенная модель без единого права на запись, детерминированная
-# публикация документа в `dev`.
-on:
-  workflow_dispatch:
-    inputs:
-      tag:
-        description: "Stable release tag, for example v1.78.0"
-        required: true
-        type: string
-      candidate:
-        description: "Exact candidate SHA; empty = the commit of the tag"
-        required: false
-        type: string
-        default: ""
-      force:
-        description: "Review again even when the document already exists in dev"
-        required: false
-        type: boolean
-        default: false
-
-permissions:
-  contents: read
-
-concurrency:
-  group: release-review-${{ inputs.tag }}
-  cancel-in-progress: false
-
-jobs:
-  prepare:
-    name: "Ревью релиза: вход линии"
-    runs-on: ubuntu-24.04
-    timeout-minutes: 10
-    permissions:
-      contents: read
-    outputs:
-      proceed: ${{ steps.line.outputs.proceed }}
-      candidate: ${{ steps.line.outputs.candidate }}
-      base: ${{ steps.line.outputs.base }}
-      doc: ${{ steps.line.outputs.doc }}
-      issues: ${{ steps.line.outputs.issues }}
-    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          fetch-depth: 0
-          ref: dev
-          persist-credentials: false
-
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with:
-          node-version: 22
-
-      - name: Кандидат, база и issue линии
-        id: line
-        env:
-          TAG: ${{ inputs.tag }}
-          CANDIDATE: ${{ inputs.candidate }}
-          FORCE: ${{ inputs.force }}
-          RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
-        run: |
-          doc=$(node scripts/release-review.mjs doc --tag="$TAG")
-          git fetch -q --tags origin
-          if [ -z "$CANDIDATE" ]; then
-            CANDIDATE=$(git rev-parse --verify -q "refs/tags/$TAG^{commit}") || {
-              echo "::error::тега $TAG нет, а кандидат не передан"; exit 1; }
-          fi
-          git cat-file -e "$CANDIDATE^{commit}"
-          CANDIDATE=$(git rev-parse "$CANDIDATE^{commit}")
-          # Повтор на тот же тег не тратит модель: документ уже есть (§11.5).
-          if [ "$FORCE" != "true" ] && git cat-file -e "origin/dev:$doc" 2>/dev/null; then
-            echo "::notice::$doc уже есть в dev — повторное ревью не запускается (force=true, чтобы переснять)"
-            echo "proceed=false" >> "$GITHUB_OUTPUT"
-            exit 0
-          fi
-          out="$RUNNER_TEMP/release-review-input"
-          node scripts/release-review.mjs prepare --tag="$TAG" --candidate="$CANDIDATE" \
-            --out="$out" --run-url="$RUN_URL" | tee -a "$GITHUB_OUTPUT"
-          echo "candidate=$CANDIDATE" >> "$GITHUB_OUTPUT"
-          echo "proceed=true" >> "$GITHUB_OUTPUT"
-          (cd "$out" && sha256sum brief.md line-membership.json > manifest.sha256)
-          cat "$out/brief.md" >> "$GITHUB_STEP_SUMMARY"
-
-      - name: Передать вход модели
-        if: steps.line.outputs.proceed == 'true'
-        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4
-        with:
-          name: release-review-input-${{ github.run_id }}-${{ github.run_attempt }}
-          path: ${{ runner.temp }}/release-review-input
-          if-no-files-found: error
-          retention-days: 3
-
-  model_review:
-    name: "Ревью релиза: работа модели"
-    needs: prepare
-    if: needs.prepare.outputs.proceed == 'true'
-    runs-on: ubuntu-24.04
-    timeout-minutes: 60
-    # Недоверенная стадия. Прав на запись нет никаких: ни в репозиторий, ни в
-    # issue. Документ публикует `publish`; находки в issue превращает владелец.
-    # `github_token` у шага Review обязателен (#556): без него action меняет
-    # OIDC на собственный App-токен с правом записи.
-    permissions:
-      contents: read
-    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          fetch-depth: 0
-          ref: ${{ needs.prepare.outputs.candidate }}
-          persist-credentials: false
-
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with:
-          node-version: 22
-          cache: npm
-
-      - name: Получить вход линии
-        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4
-        with:
-          name: release-review-input-${{ github.run_id }}-${{ github.run_attempt }}
-          path: ${{ runner.temp }}/release-review-input
-
-      - name: Проверить вход и кандидата
-        env:
-          CANDIDATE: ${{ needs.prepare.outputs.candidate }}
-        run: |
-          (cd "$RUNNER_TEMP/release-review-input" && sha256sum -c manifest.sha256)
-          test "$(git rev-parse HEAD)" = "$CANDIDATE"
-
-      - name: Установить зависимости
-        run: npm ci
-
-      - name: Кэш браузеров Playwright
-        id: pw
-        uses: actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6
-        with:
-          path: ~/.cache/ms-playwright
-          key: playwright-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
-
-      - name: Установить Chromium
-        if: steps.pw.outputs.cache-hit != 'true'
-        run: npx playwright install chromium
-
-      # Тот же обход, что у конвейера (_process.yml, anthropics issue 1817).
-      - name: Установить Claude Code детерминированно
-        id: claude_bin
-        run: |
-          src=$(ls "$RUNNER_WORKSPACE"/../_actions/anthropics/claude-code-*/v1/src/entrypoints/run.ts 2>/dev/null | head -1)
-          ver=$(grep -oE 'claudeCodeVersion = "[0-9]+\.[0-9]+\.[0-9]+"' "$src" 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' || true)
-          ver="${ver:-2.1.265}"
-          base=https://downloads.claude.ai/claude-code-releases
-          bin="$HOME/.local/bin/claude"
-          mkdir -p "$(dirname "$bin")"
-          curl -fsSL --retry 3 "$base/$ver/linux-x64/claude" -o "$bin"
-          sum=$(curl -fsSL --retry 3 "$base/$ver/manifest.json" | jq -r '.platforms["linux-x64"].checksum')
-          echo "$sum  $bin" | sha256sum -c -
-          chmod +x "$bin"
-          "$bin" --version
-          echo "path=$bin" >> "$GITHUB_OUTPUT"
-
-      - name: Review
-        id: review
-        uses: anthropics/claude-code-action@9cdae7f0d995e3ba7c33f226087fdf82a59cd520 # v1
-        env:
-          REVIEW_DOC: ${{ runner.temp }}/release-review.md
-          REVIEW_INPUT: ${{ runner.temp }}/release-review-input
-        with:
-          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
-          github_token: ${{ secrets.GITHUB_TOKEN }}
-          path_to_claude_code_executable: ${{ steps.claude_bin.outputs.path }}
-          prompt: |
-            Ты независимый ревьюер релиза House Plan. Язык ответа — русский.
-
-            Релиз: ${{ inputs.tag }} · кандидат ${{ needs.prepare.outputs.candidate }}
-            (рабочая копия уже на нём) · база линии: ${{ needs.prepare.outputs.base || 'нет' }}.
-            Вход линии — файл $REVIEW_INPUT/brief.md (issue линии, доказанные
-            трейлерами, и изменённые продуктовые файлы) и
-            $REVIEW_INPUT/line-membership.json.
-
-            Правила этого ревью — docs/process/REVIEWER.md, раздел «Независимое
-            ревью линии», канон — PROCESS.md §11.5. Прочитай их первыми.
-
-            Главное, что нельзя пропустить:
-            - Ты судишь ПОВЕРХНОСТИ, изменённые линией, против ПОЛЬЗОВАТЕЛЯ, а
-              не дифф против ТЗ. Не читай ТЗ задач (раздел «## ТЗ» в issue,
-              docs/specs/**) и документы раундов (docs/reviews/**): независимость
-              и есть смысл шага. Основа суждения — docs/SCOPE.md (персоны и
-              работы) и docs/USER-GUIDE.ru.md (что обещано пользователю).
-            - Проверяй исполнением, а не чтением: собери бандл
-              (`npm run bundle:sync`), открой затронутые поверхности в браузере
-              (стенд `demo/`, смоки `demo/smoke_*.mjs`), вводи текст
-              посимвольно, закрывай диалоги настоящим Escape и крестиком. Где
-              есть диалоги HA — пиннутая фикстура `ha-dialog` (#505,
-              demo/helpers/README-ha-dialog.md,
-              `node demo/verify_ha_dialog_discard_recovery.mjs`).
-            - Для каждой поверхности: обычный сценарий и самый рискованный
-              соседний, шесть классов риска (async, данные/права, геометрия,
-              визуал, объём/perf, host/input) — PROCESS.md §2.6.
-            - Ты ничего не правишь и не публикуешь: ни код, ни issue, ни
-              комментарии. Права на запись у тебя нет. Любые изменения рабочей
-              копии будут отброшены — после проверок восстанови её сам
-              (`git checkout -- . && git clean -fd`), если что-то менял.
-
-            Находки: High / Medium / Low, у каждой — поверхность, воспроизведение
-            (команда или шаги), что увидит пользователь, какая персона задета.
-            Выпуск это ревью не останавливает: документ — рекомендация владельцу.
-
-            Напиши полный документ в файл по пути из переменной REVIEW_DOC
-            (абсолютный, вне репозитория). Разделы: что входило в линию,
-            поверхности и как каждая проверялась (команда → результат),
-            находки, что проверено и корректно, чего не проверял и почему.
-            Первой строкой после заголовка — `Итог: High N · Medium N · Low N`.
-
-            Затем верни JSON по схеме — последнее обязательное действие.
-          claude_args: |
-            --max-turns 200
-            --allowedTools Read,Write,Grep,Glob,Bash
-            --json-schema '{"type":"object","properties":{"high":{"type":"integer"},"medium":{"type":"integer"},"low":{"type":"integer"},"summary":{"type":"string"}},"required":["high","medium","low","summary"]}'
-
-      - name: Запечатать результат модели
-        env:
-          SOURCE: ${{ runner.temp }}/release-review.md
-          OUT: ${{ steps.review.outputs.structured_output }}
-        run: |
-          test -s "$SOURCE" || { echo "::error::модель не оставила документ ревью"; exit 1; }
-          dir="$RUNNER_TEMP/release-review-result"
-          mkdir -p "$dir"
-          printf '%s' "$OUT" > "$dir/result.json"
-          jq -e '(.high|type=="number") and (.medium|type=="number") and (.low|type=="number") and (.summary|type=="string")' \
-            "$dir/result.json" >/dev/null
-          cp "$SOURCE" "$dir/release-review.md"
-          (cd "$dir" && sha256sum release-review.md result.json > manifest.sha256)
-
-      - name: Передать результат публикации
-        uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4
-        with:
-          name: release-review-result-${{ github.run_id }}-${{ github.run_attempt }}
-          path: ${{ runner.temp }}/release-review-result
-          if-no-files-found: error
-          retention-days: 3
-
-  publish:
-    name: "Ревью релиза: документ в dev"
-    needs: [prepare, model_review]
-    runs-on: ubuntu-24.04
-    timeout-minutes: 10
-    permissions:
-      contents: read
-    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          fetch-depth: 0
-          ref: dev
-          persist-credentials: false
-
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with:
-          node-version: 22
-
-      - name: Получить результат модели
-        uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4
-        with:
-          name: release-review-result-${{ github.run_id }}-${{ github.run_attempt }}
-          path: ${{ runner.temp }}/release-review-result
-
-      # Модель пишет только текст документа. Путь, машинный блок, индекс и
-      # коммит решает этот шаг; всё остальное в рабочей копии не существует.
-      - name: Опубликовать документ
-        env:
-          TOKEN: ${{ secrets.HP_PROCESS_TOKEN }}
-          TAG: ${{ inputs.tag }}
-          DOC: ${{ needs.prepare.outputs.doc }}
-          CANDIDATE: ${{ needs.prepare.outputs.candidate }}
-          BASE: ${{ needs.prepare.outputs.base }}
-          ISSUES: ${{ needs.prepare.outputs.issues }}
-          RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
-        run: |
-          dir="$RUNNER_TEMP/release-review-result"
-          (cd "$dir" && sha256sum -c manifest.sha256)
-          test "$DOC" = "$(node scripts/release-review.mjs doc --tag="$TAG")"
-          counts=$(jq -r '"High \(.high) · Medium \(.medium) · Low \(.low)"' "$dir/result.json")
-          for attempt in 1 2 3; do
-            git fetch -q origin dev
-            git reset -q --hard origin/dev
-            git clean -fdq
-            mkdir -p docs/reviews
-            {
-              cat "$dir/release-review.md"
-              printf '\n\n<!-- hp-release-review-anchors -->\n### Материал ревью\n\n```\n'
-              printf 'tag %s\ncandidate %s\nbase %s\nissues %s\nrun %s\n' \
-                "$TAG" "$CANDIDATE" "${BASE:-—}" "${ISSUES:-—}" "$RUN_URL"
-              printf '```\n'
-            } > "$DOC"
-            node scripts/reviews-index.mjs --dir=docs/reviews --strict
-            git add -- "$DOC" docs/reviews/INDEX.md
-            git diff --cached --name-only | node scripts/review-doc-guard.mjs
-            git -c user.name="claude[bot]" \
-                -c user.email="209825114+claude[bot]@users.noreply.github.com" \
-                commit -q -F - <<MSG
-          docs: release review for $TAG
-
-          Независимое ревью линии перед стабильным релизом (PROCESS.md §11.5).
-          Итог: $counts. Выпуск не блокирует; решение по находкам — за владельцем.
-
-          Issue: #638
-          User-Visible: no
-          MSG
-            git diff --name-only "origin/dev...HEAD" | node scripts/review-doc-guard.mjs
-            if git push -q "https://x-access-token:$TOKEN@github.com/${{ github.repository }}" HEAD:dev; then
-              echo "### Независимое ревью $TAG" >> "$GITHUB_STEP_SUMMARY"
-              echo "Итог: $counts — \`$DOC\` в dev. Выпуск не блокируется." >> "$GITHUB_STEP_SUMMARY"
-              echo "::notice::$DOC опубликован: $counts"
-              exit 0
-            fi
-            echo "::warning::dev ушёл вперёд — попытка $attempt из 3, документ собирается заново"
-            sleep $((attempt * 10))
-          done
-          echo "::error::документ ревью не опубликован в dev за три попытки"
-          exit 1
@@ -0,0 +1,41 @@
+name: HACS-zip к релизу
+# hacs.json declares zip_release + filename=houseplan.zip, so every release
+# (prereleases included) must carry the asset — HACS installs from it and
+# GitHub's public download counter becomes a free per-version install metric
+# (owner request, 2026-08-08). Like announce.yml, the workflow file lives at
+# the TAGGED commit: betas cut from dev pick it up as soon as this file is on
+# dev, stable tags once it reaches main.
+# workflow_dispatch lets us attach the zip to an EXISTING release (needed
+# once for the latest stable after the hacs.json change reaches main).
+on:
+  release:
+    types: [published]
+  workflow_dispatch:
+    inputs:
+      tag:
+        description: "Existing release tag to attach the zip to"
+        required: true
+permissions:
+  contents: write
+jobs:
+  zip:
+    name: Собрать houseplan.zip и приложить к релизу
+    runs-on: ubuntu-latest
+    steps:
+      - name: Resolve tag
+        id: tag
+        env:
+          EVENT_TAG: ${{ github.event.release.tag_name }}
+          INPUT_TAG: ${{ github.event.inputs.tag }}
+        run: echo "tag=${EVENT_TAG:-$INPUT_TAG}" >> "$GITHUB_OUTPUT"
+      - uses: actions/checkout@v7
+        with:
+          ref: ${{ steps.tag.outputs.tag }}
+      - name: Build houseplan.zip (contents of custom_components/houseplan at zip root)
+        run: cd custom_components/houseplan && zip -qr ../../houseplan.zip .
+      - name: Sanity check
+        run: node scripts/verify-houseplan-zip.mjs houseplan.zip custom_components/houseplan/frontend
+      - name: Upload asset
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: gh release upload "${{ steps.tag.outputs.tag }}" houseplan.zip --clobber --repo "$GITHUB_REPOSITORY"
@@ -1,492 +1,90 @@
-name: "Релиз: проверка, сборка и публикация ассетов"
-run-name: "Release ${{ inputs.tag || github.event.release.tag_name }}"
-
-# #540: единственный путь, по которому установочные ассеты стабильного релиза
-# (`houseplan.zip` для HACS и `houseplan-card.js` для ручной установки) попадают
-# наружу. До этого публикаторов было четыре, и `release-zip.yml` выкладывал ZIP
-# в ту же секунду, когда релиз становился публичным, — до Validate, Full
-# Performance и E2E. Порядок теперь один: закрепить SHA → релиз в черновике →
-# гейты на этом SHA → одна сборка и `SHA256SUMS` → загрузка в черновик →
-# публикация → сверка публичных байтов с паспортом → анонс.
-#
-# Два входа, один порядок:
-#   • `workflow_dispatch(tag)` — штатный выпуск и ремонт. Тега ещё нет — он
-#     ставится на вершину ветки, с которой запущен workflow (main для
-#     стабильного, dev для беты). Тег есть — берётся его коммит.
-#   • `release: published` — человек опубликовал стабильный релиз руками.
-#     Fail-closed: релиз немедленно возвращается в черновик и проходит тот же
-#     путь; снаружи ничего установочного не остаётся, пока идут проверки.
-#     Беты это событие пропускают — у них свой staged-путь
-#     (`publish-prerelease.yml`, `release-prerelease.mjs`).
-#
-# Ремонт публичного релиза (dispatch на существующий тег): недостающие ассеты
-# догружаются только при зелёных гейтах; присутствующий ассет с другим хешем —
-# отказ без правок, публичные байты не подменяются молча.
-#
-# Событие `release` исполняет workflow с коммита тега: новая редакция файла
-# действует для стабильных тегов только после того, как она есть на main.
+name: "Релиз: ассеты после зелёной проверки"
 on:
  release:
    types: [published]
-  workflow_dispatch:
-    inputs:
-      tag:
-        description: "Exact release tag, for example v1.75.1; created on the dispatched branch tip when missing"
-        required: true
-        type: string
-
 permissions:
  contents: write
  actions: read
-
-concurrency:
-  group: release-${{ inputs.tag || github.event.release.tag_name }}
-  cancel-in-progress: false
-
 jobs:
-  candidate:
-    name: "Кандидат: точный SHA, режим и черновик"
-    # Публикация беты руками — не наш случай: у бет свой staged-путь.
-    if: ${{ github.event_name == 'workflow_dispatch' || !github.event.release.prerelease }}
-    runs-on: ubuntu-24.04
-    timeout-minutes: 10
-    outputs:
-      sha: ${{ steps.resolve.outputs.sha }}
-      tag: ${{ steps.resolve.outputs.tag }}
-      version: ${{ steps.resolve.outputs.version }}
-      prerelease: ${{ steps.resolve.outputs.prerelease }}
-      mode: ${{ steps.release.outputs.mode }}
-    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          fetch-depth: 0
-      - name: Resolve the tag to its exact commit
-        id: resolve
-        env:
-          EVENT: ${{ github.event_name }}
-          TAG: ${{ inputs.tag || github.event.release.tag_name }}
-        run: |
-          set -euo pipefail
-          [[ "$TAG" =~ ^v[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z.]+)?$ ]] || {
-            echo "::error::$TAG is not a release tag (vX.Y.Z or vX.Y.Z-pre)"
-            exit 1
-          }
-          VERSION=${TAG#v}
-          case "$TAG" in *-*) PRERELEASE=true ;; *) PRERELEASE=false ;; esac
-          if git ls-remote --exit-code --tags origin "refs/tags/$TAG" >/dev/null; then
-            git fetch --force origin "refs/tags/$TAG:refs/tags/$TAG"
-            # Peeled commit both for annotated and lightweight tags (a release
-            # form makes lightweight ones). Neither target_commitish nor the
-            # event SHA is trusted: the former may be a branch name.
-            SHA=$(git rev-list -n 1 "refs/tags/$TAG")
-            echo "tag $TAG exists → $SHA"
-          else
-            test "$EVENT" = "workflow_dispatch" || {
-              echo "::error::release event for a tag that does not exist: $TAG"
-              exit 1
-            }
-            SHA=$(git rev-parse HEAD)
-            echo "tag $TAG is new → dispatched branch tip $SHA"
-          fi
-          if [ "$PRERELEASE" = "false" ]; then
-            git fetch origin main
-            git merge-base --is-ancestor "$SHA" origin/main || {
-              echo "::error::stable candidate $SHA is not on main"
-              exit 1
-            }
-          else
-            git fetch origin dev
-            git merge-base --is-ancestor "$SHA" origin/dev || {
-              echo "::error::prerelease candidate $SHA is not on dev"
-              exit 1
-            }
-          fi
-          {
-            echo "sha=$SHA"
-            echo "tag=$TAG"
-            echo "version=$VERSION"
-            echo "prerelease=$PRERELEASE"
-          } >> "$GITHUB_OUTPUT"
-      - name: Take the release off the public surface until it is verified
-        id: release
-        env:
-          GH_TOKEN: ${{ github.token }}
-          EVENT: ${{ github.event_name }}
-          TAG: ${{ steps.resolve.outputs.tag }}
-        run: |
-          set -euo pipefail
-          if ! gh release view "$TAG" --repo "$GITHUB_REPOSITORY" --json isDraft --jq .isDraft > /tmp/is-draft 2>/dev/null; then
-            echo "mode=fresh" >> "$GITHUB_OUTPUT"
-            echo "no release for $TAG yet: it will be created as a draft after the gates"
-          elif [ "$(cat /tmp/is-draft)" = "true" ]; then
-            echo "mode=staged" >> "$GITHUB_OUTPUT"
-            echo "release $TAG is a draft: staging into it"
-          elif [ "$EVENT" = "release" ]; then
-            # Published by hand: nothing here has been verified. Back to draft
-            # first, gates second — the order is the whole point (#540).
-            gh release edit "$TAG" --repo "$GITHUB_REPOSITORY" --draft
-            echo "mode=event" >> "$GITHUB_OUTPUT"
-            echo "::notice::$TAG was published by hand and is a draft again until the gates pass"
-          else
-            echo "mode=repair" >> "$GITHUB_OUTPUT"
-            echo "release $TAG is public: repair mode — only missing assets may be added"
-          fi
-
-  independent-review:
-    name: "Независимое ревью линии (не блокирует выпуск)"
-    # #638, PROCESS.md §11.5. Решение владельца 2026-09-25: ревью идёт
-    # параллельно гейтам и выпуск не ждёт и не останавливает. Поэтому этот job
-    # только ставит в очередь `release-review.yml` на `dev` и ни один job
-    # выпуска от него не зависит (`needs` на него запрещён тестом
-    # release-workflow); его отказ — предупреждение, а не красный релиз.
-    # Беты пропускаются: ревью линии — перед стабильным.
-    needs: candidate
-    if: ${{ needs.candidate.outputs.prerelease != 'true' }}
-    continue-on-error: true
-    runs-on: ubuntu-24.04
-    timeout-minutes: 5
-    permissions:
-      actions: write
-    steps:
-      - name: Поставить в очередь ревью линии
-        env:
-          GH_TOKEN: ${{ github.token }}
-          TAG: ${{ needs.candidate.outputs.tag }}
-          SHA: ${{ needs.candidate.outputs.sha }}
-        run: |
-          if gh workflow run release-review.yml --repo "${{ github.repository }}" --ref dev \
-               -f tag="$TAG" -f candidate="$SHA"; then
-            echo "Независимое ревью $TAG поставлено в очередь: release-review.yml на dev" >> "$GITHUB_STEP_SUMMARY"
-          else
-            echo "::warning::ревью линии $TAG не запущено — выпуск продолжается; запустить руками: gh workflow run release-review.yml --ref dev -f tag=$TAG -f candidate=$SHA"
-            exit 1
-          fi
-
+  # AUD-159B7-02: publishing a GitHub Release used to BE the gate — this
+  # workflow only built and uploaded, so an asset shipped while both Validate
+  # runs for the very same commit were red. The asset now waits for a green
+  # Validate of the EXACT commit the tag points at, and is withheld otherwise.
+  #
+  # Needs a push with a token that has the `workflow` scope (the ordinary
+  # Personal Access Token used for `git push` refuses workflow file updates).
  gate:
-    name: "Гейт: контракт, Validate, Full Performance и E2E на точном SHA"
-    needs: candidate
-    runs-on: ubuntu-24.04
-    # Больше суммы собственных ожиданий job: Validate и Full Performance ждутся
-    # до 60 мин каждый (release-gate.mjs), E2E — до 45 (e2e-gate.mjs): 165 < 180 (#658).
-    timeout-minutes: 180
+    name: "Гейт: зелёная Проверка точного SHA тега"
+    runs-on: ubuntu-latest
    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+      - uses: actions/checkout@v7
        with:
-          ref: ${{ needs.candidate.outputs.sha }}
+          ref: ${{ github.event.release.tag_name }}
          fetch-depth: 0
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
+      - uses: actions/setup-node@v7
        with: { node-version: 22 }
-      # #479: тяжёлые job Validate идут только на коммите с трейлером `Release:`;
-      # без него зелёный Validate — прогон без смоков и golden. Трейлер обязан
-      # называть ровно этот тег: кандидат сам объявляет, чем он выпускается.
-      - name: Require the Release trailer naming this exact tag
-        env:
-          SHA: ${{ needs.candidate.outputs.sha }}
-          TAG: ${{ needs.candidate.outputs.tag }}
-        run: |
-          set -euo pipefail
-          git log -1 --format=%B "$SHA" > /tmp/head-message.txt
-          if ! grep -Eq '^Release:[[:space:]]*v?[0-9]+\.[0-9]+\.[0-9]+' /tmp/head-message.txt; then
-            echo "::error::$SHA has no Release: trailer — Validate ran without the heavy gates (#479)"
-            exit 1
-          fi
-          if ! grep -Fxq "Release: $TAG" /tmp/head-message.txt; then
-            echo "::error::$SHA declares $(grep -E '^Release:' /tmp/head-message.txt | head -1), not $TAG"
-            exit 1
-          fi
-      - name: Verify version, changelogs and bilingual release notes
-        env:
-          TAG: ${{ needs.candidate.outputs.tag }}
-          PRERELEASE: ${{ needs.candidate.outputs.prerelease }}
-        run: |
-          set -euo pipefail
-          if [ "$PRERELEASE" = "true" ]; then
-            node scripts/release-contract.mjs "$TAG" --repo="$GITHUB_REPOSITORY"
-          else
-            node scripts/release-contract.mjs "$TAG" --repo="$GITHUB_REPOSITORY" --stable
-          fi
      - name: Require a green Validate for this exact commit
        env:
          GH_TOKEN: ${{ github.token }}
          REPO: ${{ github.repository }}
-          SHA: ${{ needs.candidate.outputs.sha }}
-        run: node scripts/release-gate.mjs "$SHA"
+          TAG: ${{ github.event.release.tag_name }}
+        run: |
+          set -euo pipefail
+          # HEAD is the peeled commit even when TAG is annotated. Do not trust
+          # target_commitish (it may be a branch name) or an event-context SHA.
+          SHA=$(git rev-parse HEAD)
+          echo "release tag: $TAG; exact commit: $SHA"
+          node scripts/release-gate.mjs "$SHA"
      - name: Require full performance for a stable release
-        if: ${{ needs.candidate.outputs.prerelease != 'true' }}
+        if: ${{ !github.event.release.prerelease }}
        env:
          GH_TOKEN: ${{ github.token }}
          REPO: ${{ github.repository }}
-          SHA: ${{ needs.candidate.outputs.sha }}
-        run: node scripts/release-gate.mjs "$SHA" --workflow=performance.yml --label="Полные бенчмарки производительности"
-      # #514/#540: единственная проверка на настоящем Home Assistant. Раньше
-      # houseplan-e2e ставил `houseplan.zip` из публичного релиза — то есть
-      # релиз должен был быть публичным ДО проверки. Теперь он ставит дерево
-      # `custom_components/houseplan` коммита-кандидата (tarball codeload),
-      # а ZIP строится `git archive` из того же дерева: тождество «что
-      # тестировали = что публикуем» — хеш дерева, он печатается на сборке.
-      # Cross-repository dispatch needs a token with Actions: write on
-      # houseplan-e2e; HP_PROCESS_TOKEN (classic, repo scope) has it,
-      # E2E_DISPATCH_TOKEN is the fallback for a fine-grained token.
-      - name: Require green E2E on a real Home Assistant for a stable release
-        if: ${{ needs.candidate.outputs.prerelease != 'true' }}
-        env:
-          GH_TOKEN: ${{ secrets.E2E_DISPATCH_TOKEN || secrets.HP_PROCESS_TOKEN }}
-          SHA: ${{ needs.candidate.outputs.sha }}
-          TAG: ${{ needs.candidate.outputs.tag }}
-        run: node scripts/e2e-gate.mjs --ref="$SHA" --tag="$TAG"
-
-  stage:
-    name: "Сборка: ассеты, SHA256SUMS и загрузка в черновик"
-    needs: [candidate, gate]
-    runs-on: ubuntu-24.04
-    timeout-minutes: 30
-    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          ref: ${{ needs.candidate.outputs.sha }}
-          fetch-depth: 0
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with: { node-version: 22 }
-      - name: Build once and verify both installable assets
-        id: build
-        env:
-          SHA: ${{ needs.candidate.outputs.sha }}
-          VERSION: ${{ needs.candidate.outputs.version }}
        run: |
          set -euo pipefail
-          npm ci
-          npm run build
-          node scripts/bundle-tree.mjs dist custom_components/houseplan/frontend
-          npm run bundle:budget
-          grep -RFq "$VERSION" dist
-          test -s dist/houseplan-card.js
-          test -s dist/houseplan-panel.js
-          # The ZIP is the committed integration tree of the exact commit —
-          # the same tree E2E installed from the codeload tarball. `git archive`
-          # is deterministic for a commit, so a repair rebuilds identical bytes.
-          git -c core.autocrlf=false archive --format=zip --output=houseplan.zip \
-            "$SHA:custom_components/houseplan"
-          node scripts/verify-houseplan-zip.mjs houseplan.zip \
-            custom_components/houseplan/frontend "$VERSION"
-          mkdir -p release-assets
-          cp dist/houseplan-card.js houseplan.zip release-assets/
-          node scripts/release-assets.mjs sums release-assets
-          TREE=$(git rev-parse "$SHA:custom_components/houseplan")
-          echo "tree=$TREE" >> "$GITHUB_OUTPUT"
-          printf '### Staged assets for %s\n\n- exact commit: `%s`\n- `custom_components/houseplan` tree (what E2E installed): `%s`\n\n```\n%s```\n' \
-            "$VERSION" "$SHA" "$TREE" "$(cat release-assets/SHA256SUMS)" >> "$GITHUB_STEP_SUMMARY"
+          SHA=$(git rev-parse HEAD)
+          node scripts/release-gate.mjs "$SHA" --workflow=performance.yml --label="Полные бенчмарки производительности"
+  build:
+    name: Сборка бандла и загрузка ассетов
+    needs: gate
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+        with:
+          ref: ${{ github.event.release.tag_name }}
+      - uses: actions/setup-node@v7
+        with: { node-version: 22 }
+      - run: npm ci && npm run build
      - name: Verify compositor frame continuity for a stable release
-        if: ${{ needs.candidate.outputs.prerelease != 'true' }}
+        if: ${{ !github.event.release.prerelease }}
        run: |
          npx playwright install --with-deps chromium
          node scripts/bundle-sync.mjs
          npm run continuity:screencast
      - name: Upload failed continuity frames
-        if: ${{ failure() && needs.candidate.outputs.prerelease != 'true' }}
-        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
+        if: ${{ failure() && !github.event.release.prerelease }}
+        uses: actions/upload-artifact@v7
        with:
          name: continuity-screencast
          path: artifacts/continuity-screencast
-      - name: Keep the passport for the publication step
-        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
+      - name: Verify the complete committed frontend tree
+        run: node scripts/bundle-tree.mjs dist custom_components/houseplan/frontend
+      - name: Attach card to release
+        uses: softprops/action-gh-release@v3
        with:
-          name: release-assets-${{ needs.candidate.outputs.tag }}
-          path: release-assets/SHA256SUMS
-          if-no-files-found: error
-      # Also for a draft made in the release form: its tag may not exist yet,
-      # and publishing such a draft would let GitHub tag target_commitish —
-      # not necessarily the verified commit. The tag is pinned here, first.
-      - name: Create or verify the tag at the exact commit
-        env:
-          TAG: ${{ needs.candidate.outputs.tag }}
-          SHA: ${{ needs.candidate.outputs.sha }}
-        run: |
-          set -euo pipefail
-          REMOTE=$(git ls-remote --tags origin "refs/tags/$TAG" "refs/tags/$TAG^{}")
-          if [ -n "$REMOTE" ]; then
-            PEELED=$(printf '%s\n' "$REMOTE" | awk -v ref="refs/tags/$TAG^{}" '$2 == ref {print $1}')
-            test -n "$PEELED" || PEELED=$(printf '%s\n' "$REMOTE" | awk -v ref="refs/tags/$TAG" '$2 == ref {print $1}')
-            test "$PEELED" = "$SHA" || {
-              echo "::error::Existing tag $TAG points to $PEELED, expected $SHA"
-              exit 1
-            }
-          else
-            git config user.name "github-actions[bot]"
-            git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
-            git tag -a "$TAG" "$SHA" -m "$TAG"
-            git push origin "$TAG"
-          fi
-      - name: Stage the verified assets into the release
-        env:
-          GH_TOKEN: ${{ github.token }}
-          TAG: ${{ needs.candidate.outputs.tag }}
-          MODE: ${{ needs.candidate.outputs.mode }}
-          PRERELEASE: ${{ needs.candidate.outputs.prerelease }}
-        run: |
-          set -euo pipefail
-          if [ "$MODE" = "fresh" ]; then
-            FLAG="--prerelease=false"
-            if [ "$PRERELEASE" = "true" ]; then FLAG="--prerelease"; fi
-            gh release create "$TAG" --repo "$GITHUB_REPOSITORY" --verify-tag --draft "$FLAG" \
-              --title "$TAG" --notes-file docs/RELEASE-NOTES.md
-          fi
-          if [ "$MODE" = "repair" ]; then
-            # Public release: what is already outside must be the bytes we just
-            # rebuilt; anything else is a finding, not a --clobber. Only missing
-            # assets are added, and only now — after the gates.
-            mkdir -p public
-            for name in $(gh release view "$TAG" --repo "$GITHUB_REPOSITORY" --json assets --jq '.assets[].name'); do
-              case "$name" in
-                houseplan-card.js|houseplan.zip|SHA256SUMS)
-                  gh release download "$TAG" --repo "$GITHUB_REPOSITORY" --dir public --pattern "$name" --clobber ;;
-              esac
-            done
-            if [ -f public/SHA256SUMS ]; then
-              diff -u public/SHA256SUMS release-assets/SHA256SUMS || {
-                echo "::error::public SHA256SUMS of $TAG differ from the rebuilt assets"
-                exit 1
-              }
-            fi
-            node scripts/release-assets.mjs check public release-assets/SHA256SUMS --allow-missing
-            missing=""
-            for name in houseplan-card.js houseplan.zip SHA256SUMS; do
-              [ -f "public/$name" ] || missing="$missing release-assets/$name"
-            done
-            if [ -z "$missing" ]; then
-              echo "nothing to repair: every asset of $TAG is present and matches"
-            else
-              echo "adding missing assets:$missing"
-              # shellcheck disable=SC2086
-              gh release upload "$TAG" $missing --repo "$GITHUB_REPOSITORY"
-            fi
-          else
-            # Draft: whatever a hand-made publication put here was never
-            # verified, so the verified bytes replace it.
-            gh release upload "$TAG" release-assets/houseplan-card.js release-assets/houseplan.zip \
-              release-assets/SHA256SUMS --repo "$GITHUB_REPOSITORY" --clobber
-          fi
-          RELEASE_JSON=$(gh release view "$TAG" --repo "$GITHUB_REPOSITORY" --json tagName,isDraft,assets)
-          export RELEASE_JSON TAG
-          node <<'NODE'
-          const release = JSON.parse(process.env.RELEASE_JSON);
-          if (release.tagName !== process.env.TAG) throw new Error('release tag mismatch');
-          const assets = new Map(release.assets.map((asset) => [asset.name, asset]));
-          for (const name of ['houseplan-card.js', 'houseplan.zip', 'SHA256SUMS']) {
-            if (!(Number(assets.get(name)?.size) > 0)) throw new Error(`${name} is missing or empty`);
-          }
-          NODE
-
-  publish:
-    name: "Публикация и сверка публичных байтов"
-    needs: [candidate, gate, stage]
-    runs-on: ubuntu-24.04
-    timeout-minutes: 15
-    outputs:
-      url: ${{ steps.verify.outputs.url }}
-      name: ${{ steps.verify.outputs.name }}
-      newly_published: ${{ steps.flip.outputs.newly_published }}
-    steps:
-      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          ref: ${{ needs.candidate.outputs.sha }}
-          fetch-depth: 0
-      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
-        with: { node-version: 22 }
-      - uses: actions/download-artifact@37930b1c2abaa49bbe596cd826c3c89aef350131 # v7
-        with:
-          name: release-assets-${{ needs.candidate.outputs.tag }}
-          path: passport
-      - name: Publish the verified draft
-        id: flip
-        env:
-          GH_TOKEN: ${{ github.token }}
-          TAG: ${{ needs.candidate.outputs.tag }}
-          MODE: ${{ needs.candidate.outputs.mode }}
-          PRERELEASE: ${{ needs.candidate.outputs.prerelease }}
-        run: |
-          set -euo pipefail
-          if [ "$MODE" = "repair" ]; then
-            echo "newly_published=false" >> "$GITHUB_OUTPUT"
-            echo "repair of a public release: nothing to publish"
-            exit 0
-          fi
-          FLAG="--prerelease=false"
-          if [ "$PRERELEASE" = "true" ]; then FLAG="--prerelease"; fi
-          gh release edit "$TAG" --repo "$GITHUB_REPOSITORY" --draft=false "$FLAG" \
-            --title "$TAG" --notes-file docs/RELEASE-NOTES.md
-          echo "newly_published=true" >> "$GITHUB_OUTPUT"
-      - name: Verify the public release against the passport
-        id: verify
-        env:
-          GH_TOKEN: ${{ github.token }}
-          TAG: ${{ needs.candidate.outputs.tag }}
-          SHA: ${{ needs.candidate.outputs.sha }}
-          PRERELEASE: ${{ needs.candidate.outputs.prerelease }}
-        run: |
-          set -euo pipefail
-          RELEASE_JSON=$(gh release view "$TAG" --repo "$GITHUB_REPOSITORY" \
-            --json tagName,name,isDraft,isPrerelease,assets,url)
-          export RELEASE_JSON TAG PRERELEASE
-          node <<'NODE'
-          const release = JSON.parse(process.env.RELEASE_JSON);
-          if (release.tagName !== process.env.TAG || release.isDraft) throw new Error('release is not public for the requested tag');
-          if (String(release.isPrerelease) !== process.env.PRERELEASE) throw new Error('release prerelease flag does not match the tag');
-          const assets = new Map(release.assets.map((asset) => [asset.name, asset]));
-          for (const name of ['houseplan-card.js', 'houseplan.zip', 'SHA256SUMS']) {
-            if (!(Number(assets.get(name)?.size) > 0)) throw new Error(`${name} is missing or empty`);
-          }
-          NODE
-          # The bytes anyone downloads now are the bytes the gates saw.
-          mkdir -p public
-          gh release download "$TAG" --repo "$GITHUB_REPOSITORY" --dir public \
-            --pattern houseplan-card.js --pattern houseplan.zip --pattern SHA256SUMS --clobber
-          diff -u passport/SHA256SUMS public/SHA256SUMS
-          node scripts/release-assets.mjs check public passport/SHA256SUMS
-          git fetch --force origin "refs/tags/$TAG:refs/tags/$TAG"
-          test "$(git rev-list -n 1 "refs/tags/$TAG")" = "$SHA"
-          URL=$(node -p "JSON.parse(process.env.RELEASE_JSON).url")
-          NAME=$(node -p "JSON.parse(process.env.RELEASE_JSON).name || process.env.TAG")
-          {
-            echo "url=$URL"
-            echo "name=$NAME"
-          } >> "$GITHUB_OUTPUT"
-          printf '### Published %s\n\n- exact SHA: `%s`\n- [GitHub release](%s)\n\n```\n%s```\n' \
-            "$TAG" "$SHA" "$URL" "$(cat public/SHA256SUMS)" >> "$GITHUB_STEP_SUMMARY"
-
-  announce:
-    # #538: анонс — последнее звено, а не параллельное. Пока он висел на самом
-    # событии `release: published`, он обгонял гейт: 12.09 v1.75.0 объявили в
-    # канале в ту же минуту, когда проверка отказала выкладывать ассеты.
-    # `needs: publish` означает, что молчание — это тоже ответ: красный гейт или
-    # несостоявшаяся выкладка сообщения не рождают. Ремонт не анонсируется.
-    name: Оповещение о релизе после выкладки
-    needs: [candidate, publish]
-    if: ${{ needs.publish.outputs.newly_published == 'true' }}
-    uses: ./.github/workflows/announce.yml
-    with:
-      reusable: true
-      tag: ${{ needs.candidate.outputs.tag }}
-      release_name: ${{ needs.publish.outputs.name }}
-      url: ${{ needs.publish.outputs.url }}
-      prerelease: ${{ needs.candidate.outputs.prerelease == 'true' }}
-      ref: ${{ needs.candidate.outputs.tag }}
-    secrets: inherit
-
+          files: dist/houseplan-card.js
  hacs-discovery:
    name: HACS-видимость пре-релиза (порядок бет)
    # HACS 2.0.x takes the first prerelease in GitHub's response instead of
    # sorting SemVer. A valid asset can therefore be invisible to beta users
    # (beta.10 appeared after beta.9). Keep the release asset, but
    # make that distribution failure impossible to miss in the release run.
-    if: ${{ needs.candidate.outputs.prerelease == 'true' }}
-    needs: [candidate, publish]
-    runs-on: ubuntu-24.04
-    timeout-minutes: 10
+    if: ${{ github.event.release.prerelease }}
+    needs: build
+    runs-on: ubuntu-latest
    steps:
      - name: Verify the published tag is the prerelease HACS will discover
-        uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9
-        env:
-          EXPECTED_TAG: ${{ needs.candidate.outputs.tag }}
+        uses: actions/github-script@v9
        with:
          script: |
            const releases = await github.paginate(github.rest.repos.listReleases, {
@@ -495,7 +93,7 @@ jobs:
              per_page: 100,
            });
            const first = releases.find((r) => r.prerelease && !r.draft);
-            const expected = process.env.EXPECTED_TAG;
+            const expected = context.payload.release.tag_name;
            if (first?.tag_name !== expected) {
              core.setFailed(
                `HACS prerelease discovery is stale: GitHub returns ${first?.tag_name ?? 'none'} before ${expected}. ` +
@@ -1,6 +1,4 @@
-# Без слэша: с ним шаблон не покрывает СИМВОЛИЧЕСКУЮ ССЫЛКУ с этим именем,
-# и `git add -A` в чужом worktree затягивает её в коммит (#520, прежде #429).
-node_modules
+node_modules/
 tsout/
 test-build/
 *.log
@@ -14,6 +12,5 @@ artifacts/
 # она только росла — 364 версии по 1.16 МБ за семь недель (#255). Обязательных
 # копий две: `dist/` (артефакт сборки) и `custom_components/` (её ставит HACS).
 demo/srv/assets/houseplan-card.js
-demo/srv/assets/houseplan-panel.js
 demo/srv/assets/houseplan-assets.json
 demo/srv/assets/houseplan-assets/
@@ -1 +0,0 @@
-22
@@ -1 +0,0 @@
-3.14
@@ -4,49 +4,73 @@ House Plan is one HACS package with two parts plus a demo harness:

 - **Lovelace card** (`src/`, TypeScript + Lit) — the primary product, bundled to
  the entry, manifest and hashed chunks under `dist/`.
- **Storage integration** (`custom_components/houseplan/`, Python) — the Home
-  Assistant backend.
- **Demo harness** (`demo/`) — a Playwright page (`demo/srv/demo.html`) that
-  renders the card against a fake `hass` for screenshots and the `smoke_*.mjs`
-  suite. The home is fully synthetic. Launcher `demo/serve.mjs`; golden scenes
-  `demo/golden/`, performance `demo/performance/`, guard suite `demo/guard/`,
-  live stand seed `demo/stand/` — each with its own README.
-
-This file is the map and the few rules every session needs before its first
-command. `PROCESS.md` is the only complete canon and wins any disagreement;
-the sections below link to it instead of retelling it.
+- **Storage integration** (`custom_components/houseplan/`, Python) — the Home Assistant backend.
+- **Demo harness** (`demo/`) — a self-contained Playwright page (`demo/srv/demo.html`) that renders the card against a fake `hass`, used for screenshots and the `smoke_*.mjs` end-to-end suite.

 ## Read this first

 **`docs/SCOPE.md` before anything else.** It was fixed with the owner and states
 its own authority: features are built, improved and accepted **only** if they
-serve a job listed there. Its central consequence: **View mode is the product
-for two of the three personas.** Editors are admin-only tools and must never
-leak interactions into View. For work that changes visible behaviour, also read
-`docs/USER-GUIDE.ru.md` — interface wording comes from there and is not invented.
+serve a job listed there. It carries the mission, the three personas, the core
+user jobs and the out-of-scope list.

-**Reading order by role** (#634). `node scripts/entry-cost.mjs` measures each
-route and `test/entry-cost.test.mjs` keeps this list equal to its routes:
+Its central consequence: **View mode is the product for two of the three
+personas.** Editors are admin-only tools and must never leak interactions into
+View.

- author (analysis, spec, implementation, infrastructure): `docs/SCOPE.md` →
-  `AGENTS.md` → `docs/process/AUTHOR.md` → `docs/STATUS.md`;
- reviewer (spec or code): `docs/SCOPE.md` → `AGENTS.md` →
-  `docs/process/REVIEWER.md`, then the issue body and its comments;
- changing the pipeline, the gates or the process itself: `docs/SCOPE.md` →
-  `AGENTS.md` → `PROCESS.md` → `docs/STATUS.md`.
+For work that changes visible behaviour, also read `docs/USER-GUIDE.ru.md` —
+interface wording comes from there and is not invented, or the UI starts speaking
+developer.

-The two digests quote and link `PROCESS.md` section by section; open the linked
-section whenever a digest line governs your current step. For non-trivial
-changes add `docs/ARCHITECTURE.md` plus the canonical document of the subsystem
-you touch (one list, the same one the reviewer prompt in `_process.yml` reads):
-`SUN.md`, `LIGHT.md`, `CANVAS.md`, `WALL-THICKNESS.md`, `UX-MODES.md`,
-`CONFIG-COMPATIBILITY.md`, `TOUCH-SUPPORT.md`, `ISOMETRIC.md`, `VACUUM.md`,
-`DECOR-EDITOR.md`, `DEVICE-PRESENTATION.md`, `FILTERING.md`, `STAIRS.md`,
-`RADAR.md`, `PDF-EXPORT.md`, `STYLING-HOOKS.md`.
+Then `PROCESS.md` (the full process), `docs/STATUS.md` (where the release line
+is), and for non-trivial changes `docs/ARCHITECTURE.md` plus the canonical
+document of the subsystem you touch: `SUN.md`, `LIGHT.md`, `CANVAS.md`,
+`WALL-THICKNESS.md`, `UX-MODES.md`, `CONFIG-COMPATIBILITY.md`,
+`TOUCH-SUPPORT.md`.

-Where the rest lives: commands — `package.json` scripts, `CONTRIBUTING.md`,
-`docs/DEVELOPMENT.md` (toolchain, build, release — its Release section is the
-only home of release mechanics); tests and gates — `docs/TESTING.md`.
+Standard commands live in `package.json` scripts, `CONTRIBUTING.md` and
+`docs/DEVELOPMENT.md`.
+
+## Canonical backlog and status
+
+[GitHub Issues](https://github.com/Matysh/houseplan-card/issues) are the canonical
+task records: problem, scope, acceptance criteria and discussion.
+
+**Status lives in labels:** `S1-new`, `S2-analysis`, `S3-spec`, `S4-spec-review`,
+`S5-ready`, `S6-in-progress`, `S7-code-review`, `S8-merged`, plus `blocked` on top
+of a status and `rejected` on a closed issue. Exactly one `S*` label per open
+issue. Labels are the whole of it: GitHub Projects is no longer used.
+
+**The light track is the default, not a shortcut** (owner's decision 2026-08-27,
+issue #338). `small` — the spec lives in the issue body and its review is a
+comment. Analysis names the `small` criterion the task *fails* when it takes the
+full track; "ordinary track" without a named criterion is not a justification.
+The threshold itself did not move — only which side carries the proof. The full
+track stays what it was for geometry, config migrations and public contracts,
+where a criterion is broken plainly and saying which one is easy.
+
+`trivial` — the short track: no spec stage at all, `S2-analysis` straight to
+`S5-ready`, with the AC written into the issue body first. `trivial` requires a bug confined to one surface with no new UX
+contract, no migration, no i18n, no perf or touch impact, at most three checkable
+AC, **and expected behaviour already on record** — nothing left to decide. Code
+review is never skipped on either track; it is what stands in for testing.
+`PROCESS.md` §5 and §5.1 hold the criteria.
+
+An issue filed by an outsider is worked exactly like one of the owner's own, once
+the owner has decided to take it. The check sits **at the entrance**, not on every
+step: while an issue carries no status label it is outside the process and the
+invariants do not apply to it; once a label is on, the task is in flight and **who
+filed it stops mattering**.
+
+Applying that first label *is* the owner's explicit decision, and the platform
+already guarantees it — only someone with write access can label. The earlier rule
+made outside reports be refiled as the owner's own issues, which turned out to be
+work for nothing: on #123 the spec was already written by the time the guard
+refused.
+
+Specs, audits and ADRs may live under `docs/`, but must link to their issue and
+must not become a parallel task list. When repository documentation disagrees with
+Issues, the issue wins.

 ## Rule #1

@@ -63,100 +87,142 @@ The label must be one of `S5-ready`, `S6-in-progress`, `S7-code-review`. Anythin
 else — refuse and say why. "Issue #83 is in `S2-analysis`, code is off limits.
 Start with the spec?" is the correct answer, not a smaller patch.

-GitHub Issues are the canonical task records and the **labels** are the status
-(`PROCESS.md` §9); when repository documentation disagrees with an issue, the
-issue wins. Change classes (`PROCESS.md` §1): **A** product (`src/**`,
-integration Python, manifests, i18n), **B** gates and tooling (tests, `demo/**`,
-`scripts/**`, `.github/**`, build and package configuration), **C**
-documentation, **D** generated (bundle, golden baselines) — D beats A where paths
-overlap. The committed bundle changes only in a commit with a `Release:` trailer
-(#657); an ordinary task restores it with `npm run bundle:clean` before
-committing.
+## Change classes

-**Tracks** (`PROCESS.md` §5, §5.1): `small` is the default — the spec lives in the
-issue body and its review is a comment; taking the full track means naming the
-`small` criterion the task fails. `trivial` skips the spec stage for a bug whose
-expected behaviour is already on record. An **infrastructure** task — not a single
-class A file — skips analysis and spec and enters at `S7-code-review`
-(`PROCESS.md` §1). Code review is never skipped on any track: it checks scope,
-risks and the evidence from executed tests, but does not replace executing them.
+| Class | Paths | Issue required |
+|---|---|---|
+| **A — product** | `src/**`, `custom_components/houseplan/**/*.py`, `manifest.json`, `hacs.json`, i18n, `custom_components/**/translations/**` | yes |
+| **B — gates and tooling** | `test/**`, `tests_backend/**`, `demo/**`, `scripts/**`, `.github/workflows/**`, `rollup.config.mjs`, `tsconfig*.json` | yes; may reuse the issue it covers |
+| **C — documentation** | `docs/**`, `README*`, `CHANGELOG*`, `AGENTS.md` | not if it is part of its issue's DoD |
+| **D — generated** | `dist/**`, `custom_components/houseplan/frontend/**`, `demo/golden/baselines/**` | never changes on its own. The stand copy `demo/srv/assets/**` is no longer committed (#255): build the complete tree with `npm run bundle:sync` |

-## Specs
+The table above is a summary; `PROCESS.md` §1 is the authority and now covers the
+configuration files this one omits — `package.json`, `package-lock.json`,
+`pytest.ini`, `.gitignore`, `.gitattributes`, `.githooks/**` and the rest of
+`.github/**` are class B. Where paths overlap, **D beats A**: the built bundle
+lives inside `custom_components/houseplan/frontend/` and would otherwise read as
+product source.

-The spec lives in the **issue body**, under a `## ТЗ` heading (owner decision
-2026-09-10, #517); `docs/specs/` is an archive of specs written before that date
-and takes no new files. Required sections and the rule for questions are
-`PROCESS.md` §7.1: only **product** ambiguity goes to the owner — what a person
-sees or does, and how much user-visible change belongs in this issue — in one
-batched comment with a proposed default for each question and `blocked` on top of
-`S3-spec`. Everything a user cannot observe is yours to decide and record.
+## Commits

-## Commits and branches
+Hooks install themselves: `package.json` runs `"prepare": "node
+scripts/install-hooks.mjs"`, so `npm ci` sets `core.hooksPath` in every fresh
+clone. Verify with `git config core.hooksPath` — expect `.githooks`.

-Hooks install themselves on `npm ci` (`prepare` → `scripts/install-hooks.mjs`);
-`git config core.hooksPath` must print `.githooks`. Every non-merge commit
-carries **terminal** trailers:
+Every non-merge commit carries **terminal** trailers:

 ```text
 Issue: #123
 User-Visible: yes
 ```

-One `Issue:` line per issue. `User-Visible: yes` requires edits to **both**
-`docs/CHANGELOG.md` and `docs/CHANGELOG.ru.md` in the same commit. A commit
-touching `demo/golden/baselines/**` also needs `Release:` plus exactly one of
-`Baseline-Reviewed: <GitHub run URL>` or `Baseline-Reviewed-Local: sha256:<WSL
-attestation>` (`PROCESS.md` §10.1). Never invent a review link and never rewrite
-published history to satisfy trailers.
+One `Issue:` line per issue if a commit closes several. `User-Visible: no` for
+tests, refactors, tooling and documentation that does not change the product.
+`User-Visible: yes` requires edits to **both** changelogs — `docs/CHANGELOG.md`
+and `docs/CHANGELOG.ru.md` — in the same commit.

-Branch `issue/<NN>-slug`; direct commits to `dev`, no PR (owner's decision); a
-violation is fixed with a follow-up commit, never a force-push.
+A commit touching `demo/golden/baselines/**` additionally requires:

- **Push after every task, not before a beta** — while work sits unpushed there
-  is nothing to review.
- **Standing permission: push `issue/<NN>-slug` without asking.** The reviewer
-  runs in CI and reads only the remote; a task branch publishes nothing to users.
-  Push the material **before** applying the review label.
- **Do not merge into `dev` by hand.** On a green review the pipeline rebases,
-  pushes and only then sets `S8-merged`. A conflicting rebase returns the task to
-  `S6-in-progress` with the verdict intact; `node scripts/rebase-on-dev.mjs`
-  resolves conflicts in generated files only (`PROCESS.md` §2.10), then push and
-  re-apply `S7-code-review`.
- Everything else needs the owner's explicit command: pushing `main`, tags,
-  publishing betas and releases, closing issues.
+```text
+Release: v1.62.0-beta.9
+Baseline-Reviewed: https://github.com/Matysh/houseplan-card/actions/runs/<run-id>
+```
+
+Never invent a review link and never rewrite published history to satisfy
+trailers. `.githooks/commit-msg` and the `provenance` CI job both run
+`scripts/validate-commit-provenance.mjs`.
+
+Branch: `issue/<NN>-slug`. Direct commits to `dev`, no PR — the owner's decision;
+CI checks after the fact, and a violation is fixed with a follow-up commit, never
+a force-push.
+
+**Push after every task, not before a beta.** While work sits unpushed there is
+nothing to review, and reviewing twenty tasks at once is not review. `dev` may hold
+unreviewed code while a task is in flight; what matters is its state when the
+reviewer says it is accepted.
+
+**Standing permission: push `issue/<NN>-slug` without asking.** The reviewer runs
+in CI and can only read what is on the remote — an unpushed spec or commit means
+the review either stalls or judges the wrong tree. Pushing a task branch publishes
+nothing to users and does not touch the integration branch, so it needs no command.
+
+**Do not merge into `dev` by hand.** On a green code review the pipeline rebases
+the task branch onto `dev`, pushes it, and only then sets `S8-merged` — the label
+asserts the code is in `dev`, so the merge has to happen first or the label lies
+in between.
+
+If the rebase conflicts the pipeline says so in the issue and sends the task back
+to `S6-in-progress`. The verdict still stands: nothing needs reviewing again, the
+remaining work is the rebase. Resolve it, push the branch, re-apply
+`S7-code-review`. The second review run is not a formality — after a rebase onto a
+moved `dev` this is different code, and accepting it unchecked is how regressions
+arrive. Cycles are counted per stage, so a code review spends its own budget.
+
+Everything else still requires the owner's explicit command: pushing `main`,
+creating tags, publishing betas and releases, closing issues.

 ## Working trees (#115)

 One checkout, one `HEAD`: two agents sharing a directory inherit each other's
-branch. `houseplan-card-src/houseplan-card` is the author's tree — task branches
-live there, and unfamiliar local changes belong to the author or the owner,
-never reset or clean them away. `houseplan-card-src/hp-dev` is the owner's
-worktree, permanently on `dev`. The reviewer owns no tree: it runs in CI on a
-fresh checkout. A worktree works only on the machine that created it — its
-`.git` file records an absolute path in that machine's format.
+branch, and twice in one hour a commit landed on someone else's task branch that
+way. The layout is therefore fixed:

-## Handoff and the verdict
+- **`houseplan-card-src/houseplan-card`** — the author's tree. Task branches live
+  here; nobody else commits in it. Unfamiliar local changes belong to the author
+  or the owner — never reset or clean them away.
+- **`houseplan-card-src/hp-dev`** — the owner's worktree, permanently on `dev`. For owner-side operations that must not disturb the
+  author's tree: pushing `dev`, restoring a hook's executable bit, emergencies.
+- **The reviewer and the infrastructure agent own no local tree.** The reviewer
+  runs in CI on a fresh checkout. The infrastructure agent reads via `git show`
+  and publishes through the GitHub API; it makes no local commits at all, so it
+  needs no `HEAD` of its own. Its scratch worktrees live outside the repo and are
+  pruned after use.

-Start a task from its packet: `node scripts/task-packet.mjs --issue NN` (status,
-track, what the status permits, the branch against `dev`, the previous verdict
-and the unwitnessed AC; it writes nothing). The local gate is
-`npm run gate:small` (`docs/TESTING.md` › Локальный набор перед пушем); run the
-smokes named in the AC before `S7-code-review`. **"Verified" without a named
-command and its result is not evidence.** Comment formats — claim, handoff,
-verdict — are `PROCESS.md` §7.2.
+A worktree is only usable on the machine that created it: the `.git` file records
+an absolute path in that machine's format. One created from a Linux sandbox is
+dead on Windows and vice versa — create worktrees on the machine that will use
+them, which for `hp-dev` means the owner's.

-**One handoff, one push** (`PROCESS.md` §10.4). Run
-`node scripts/process-gate.mjs --issues` before pushing; after
-`S7-code-review` do not push to the branch until the verdict or the return
-arrives — a push on top of a running review cancels it.
+## Two-agent workflow

-**Having applied `S4-spec-review` or `S7-code-review`, wait for the result
-instead of ending the session.** The label starts the pipeline by itself. Poll
-with `node scripts/wait-verdict.mjs --issue NN [--sha <tip>]` (#496): it watches
-the label and the pipeline's comments every 90 s, at most 110 times, prints only
-on a change and exits 0 on a new label, 3 on an event that needs a hand, 4 on
-timeout. Watch the **label**, not the comment. Do not wait while `blocked` is
-set.
+**Codex** writes analysis, specs and all product code. **Claude** reviews specs and
+code and owns infrastructure and distribution. The owner rules on disputes, closes
+issues and commands releases.
+
+Author and reviewer are different models, which is what "a fresh session without
+implementation context" means in practice. The reviewer never edits product code;
+the author never grades their own work.
+
+**Infrastructure-only work runs outside this flow.** CI, scripts, labels, demo
+stands, the landing page and distribution are Claude's alone, and running them
+through spec-writing and review buys nothing: the spec would restate what is
+already unambiguous, and author and reviewer would be the same role. So no spec
+file, no spec review, no code review, no walk through `S1`…`S8`.
+
+The test for "infrastructure only" is mechanical: **not a single class A file** —
+nothing under `src/**`, no `custom_components/**/*.py`, no manifests, no i18n. A
+task that touches class A even once is not infrastructure and takes the full flow;
+there is no such thing as "mostly infrastructure". The strictness is deliberate:
+a loose reading would turn this into the route by which product changes skip
+review.
+
+What stays mandatory either way: an issue exists, both trailers are on every
+commit, `typecheck`, `test` and `build` are green, and any non-obvious decision is
+written down in the code or the issue rather than kept in someone's head.
+
+**Review starts by itself.** Applying `S4-spec-review` or `S7-code-review` fires the
+pipeline, which reviews without anyone asking and takes ten to forty-five minutes.
+
+**Having applied one of those labels, wait for the result instead of ending the
+session.** Reporting "handed over for review" stops a conveyor that could have kept
+moving on its own. An agent has no clock — it exists only during its own turn — so
+waiting means polling: every 90 seconds, at most 30 times. A single long sleep hits
+the command timeout. Watch the **label**, not the comment: the label is the state,
+the comment only explains it. Do not wait at all while `blocked` is set — the task
+is waiting on the owner, not on the reviewer. On exhausting the attempts, stop and
+tell the owner: a failed run leaves the label where it was, forever.
+
+What the new label means:

 | Now reads | What happened | What you do |
 |---|---|---|
@@ -167,21 +233,206 @@ set.
 | `review-4` | the cycle limit is spent | stop, the owner decides |

 **After a review run the label always changes.** If it did not, the run itself
-failed rather than the work — say so to the owner instead of polling on. The
-bounded queue reconciler (#555) re-wakes a review whose event was lost; it is a
-safety net, not permission to stop waiting for the review you started.
+failed rather than the work — say so to the owner instead of polling on.

-A failed pre-release gate (golden, full smokes, performance, HA harness) does not
-send the issue back to review: fix, re-run what failed, record the exact command
-and result in the issue (`PROCESS.md` §11.4 — and its limits).
+**A failed pre-release gate does not send the issue back to review.** The
+implementation loop runs only typecheck, unit and build; golden, browser smokes,
+performance and the full HA harness run before a beta, which is after the code
+review has passed and the issue sits in `S8-merged`. Some defects cannot surface
+any earlier.
+
+Fix it, re-run what failed, and a green run is enough for the release to continue.
+The issue stays in `S8-merged`. Record the **exact command and its result** in the
+issue — "verified" without a command proves nothing. Trailers as usual, and
+`User-Visible: yes` still means both changelogs in the same commit.
+
+The exception covers repairing the defect the gate named, not carrying on
+development under the name of a repair. It goes through the normal flow — a new
+issue, or back to `S6-in-progress` — if the fix changes a behaviour contract, gives
+the user something new, reaches a subsystem the task never touched, or is
+comparable in size to the task itself. And editing the gate so it stops failing is
+concealment, not repair; the exception is a defect proven to be **in the fixture**,
+as on #89, where the sun sat at azimuth 180° and the only window faced north, so no
+ray was ever built.
+
+Baselines are still accepted only via `npm run golden:accept -- --reviewed` on a
+complete Linux CI artefact. "So the gate goes green" is not a reason.
+
+The exchange happens in **issue comments** — there is no local message bus. Verdict
+format:
+
+```text
+Verdict: green/yellow/red · cycle r<N>/4 · High: N · Medium: N → in-task | #… · Document: …
+```
+
+High blocks. A Medium finding INSIDE the task's scope is fixed within the task:
+with no High findings the verdict is yellow, the author fixes it and the fix
+passes another review cycle — no separate issue (owner's decision 2026-08-19,
+#202: filing and servicing an issue costs far more than fixing in place). Only
+a Medium finding OUTSIDE the scope becomes its own issue — foreign scope is
+never patched from this branch. Low is fixed or waived with a note
+in the review document. A yellow verdict is legitimate even when every acceptance
+criterion passes, if the change does not solve the stated scenario or degrades a
+neighbouring one.
+
+**Four review cycles** (two on the light track). The counter lives in the document
+name, `-r1`…`-r4`; the fourth adds the `review-4` label. There is no fifth attempt:
+the owner splits the task, rejects it, or arbitrates.
+
+On the light track (`small`: complexity ≤3, one surface, no config migration, no
+new UX contract, no perf or touch impact — all at once) the spec lives in the issue
+body and the spec review is a comment. Code review is never skipped. This track is
+the default: taking the full one means naming the criterion above that the task
+does not meet.
+
+## Specs
+
+`docs/specs/<NN>-<slug>.md`, linked to its issue in both directions. Required
+sections are in `PROCESS.md` §7.1, plus two product ones: which persona meets this,
+on which surface, at what moment; and what the person sees before and after, in one
+sentence without implementation terms.
+
+**Ambiguity is asked, not guessed — but only product ambiguity.** A guess written as
+fact is the worst kind of defect: it passes review because it looks like a decision.
+
+The owner answers exactly two kinds of question: **what a person sees or does**, and
+**how much user-visible change belongs in this issue**. Behaviour in a boundary case,
+which persona wins when two conflict, what counts as acceptable degradation, whether
+a neighbouring behaviour is in scope here or becomes its own issue.
+
+Everything a user cannot observe is yours to settle: where state is stored, which
+module carries the guard, naming, file layout, test strategy, migration mechanics,
+development policy. Decide it, record it in an explicit "assumed, change freely"
+block, and let the reviewer challenge it. A technical disagreement between author and
+reviewer is settled by the verdict, not by the owner; it reaches him only when the
+cycle limit is exhausted.
+
+Split a mixed question instead of escalating all of it. "Where does this state live"
+is technical. "Does it survive a page reload and follow the plan across screens" is
+product. Ask the second, decide the first.
+
+Ask in one batched issue comment, each question carrying a proposed default, and put
+`blocked` on top of `S3-spec` while waiting. A question with a default costs the
+owner seconds; one without costs him minutes.
+
+## Gates
+
+```
+npm run typecheck
+npm test
+npm run build
+npm run inventory        # the only correct way to get test counts
+```
+
+Never copy test counts into documents by hand; they go stale in days.
+
+After building, keep the complete manifest-driven bundle trees in sync — CI
+verifies every listed file byte-for-byte:
+
+```
+npm run bundle:sync   # dist → custom_components + demo/srv/assets (#255)
+npm run bundle:budget # initial View graph <= 256000 B gzip (#337)
+```
+
+During the implementation cycle the fast gates always run. Since 2026-08-14 the
+owner's machine also carries Playwright with Chromium (Windows) and a full WSL
+environment, which changes one thing (#151): **before moving an issue to
+`S7-code-review`, run the smokes named in its AC locally** — `node
+demo/smoke_<name>.mjs`. A red smoke that reaches the review costs a cycle; run
+locally it costs a minute. Precedent: on #89 a fixture error lived through a
+whole review round that a local run would have caught immediately.
+
+The full smoke set, `golden` and `performance_smoke` still belong to the
+pre-beta run — which is then mandatory and complete. WSL runs of the full HA
+harness (`~/houseplan-card`, venv) and `golden:verify` are advisory; **the canon
+does not move**: the beta gate is CI at the exact SHA, and baselines are accepted
+only via `npm run golden:accept -- --reviewed` on a complete Linux CI artefact.
+
+**Backend.** A full Home Assistant harness cannot run on native Windows at all:
+Home Assistant imports the Unix-only `fcntl` module. Its canon is Linux CI or WSL.
+Locally only the pure subset runs; `python -m pytest tests_backend/ -q` without
+Home Assistant **silently skips** `test_ha_*.py` (`conftest.py` ignores them when
+`homeassistant` is not importable), so a green result proves nothing. Say so in the
+report instead of claiming the backend was verified. Cloud agents have the harness
+at `.venv-backend/bin/python`.
+
+**Running the app / smoke suite**: build a fresh bundle and copy it into the demo
+assets first, then run `node demo/smoke_*.mjs`. No real Home Assistant server is
+required: `demo/srv/demo.html` stubs `hass`, registries and `callService`.
+
+**Golden images**: `npm run golden:capture` and `npm run golden:verify` refuse a
+stale demo bundle. Build and copy first, then review `artifacts/golden/actual/` and
+`diff/`. Update baselines only with `npm run golden:accept -- --reviewed`, using the
+complete Linux CI artifact; never accept a partial scenario or images merely to make
+CI green. See `demo/golden/README.md`.
+
+**Freshness contract**: the embedded fingerprint covers `src/` plus Rollup,
+TypeScript and package-lock build inputs. Every browser check must verify it
+before trusting a result — benchmarks, golden runs and documentation captures
+call `assertFreshDemoBundle` themselves, and smokes get it from `launch()` in
+`demo/serve.mjs` (#236). A missing or mismatched fingerprint is a hard failure,
+not a warning; `HP_ALLOW_STALE_BUNDLE=1` skips the check for debugging and says
+so out loud. A smoke against a stale bundle does not fail cleanly: part of its
+assertions go red and part stay green, which reads as a logic defect.
+
+**CI is pinned to an exact SHA.** The release gate accepts only a `completed
+success` run for the candidate's SHA, not "the last green one"; a new push cancels
+an unfinished Validate for the same branch. Gate jobs, matching the actual
+`validate.yml` (#191): `docs`, `provenance`, `process-gate`, `hacs`, `hassfest`,
+`frontend`, `smoke`, `golden`, `performance_smoke`, `backend`. The `changes` job
+is a service path-filter, not a gate. `docs` is a real blocker: it checks the
+screenshots `sourceFingerprint` against current `src/**`, which is exactly what
+went red after the #113 merge.
+
+**"Verified" without a named command and its result is not evidence.**

 ## Environments

-The owner's Windows machine: `.\scripts\windows-toolchain.ps1 setup|check` owns
-the pinned Node and Python; WSL works from an ext4 clone with
-`bash scripts/wsl-setup.sh --verify` (`docs/DEVELOPMENT.md` › Local Windows
-workstation). `npm run toolchain:check` compares any machine with the pins CI
-uses. The full Home Assistant harness cannot run on native Windows; without an
-importable `homeassistant` pytest does not collect `test_ha_*.py` at all, so a
-green pure run proves nothing about the harness (`docs/TESTING.md`). Cloud
-agents have the harness at `.venv-backend/bin/python`.
+**Local Windows checkout** is the day-to-day environment: Node 22 as in CI, Python
+3.13 in a venv, `gh` authenticated. `.venv-backend` does **not** exist there — it is
+provisioned only by cloud agent startup scripts, which also run `npm ci` and install
+Playwright Chromium.
+
+Known environment-sensitive smoke: `demo/smoke_opening_measure.mjs` fails two
+sub-checks (`place_dialog_x_magnetised`, `place_committed_x_center`) under the pinned
+Chromium — a `1e-6`-tolerance magnet-snap on the opening-*placement* path. It
+reproduces against the pristine committed bundle, so treat it as
+pre-existing/pixel-precision, not a regression you introduced.
+
+## Labs flags
+
+`src/labs.ts` is the single registry and resolver for hidden presentation
+experiments. Activate a live flag through `?hp-labs=<id>` or the shared hash
+grammar, remove it with `-<id>`, and use `off` to clear the set. Do not add a
+YAML/config switch for a Labs-only experiment. A new entry needs a unique
+lowercase id, issue, numeric-core `since`, numeric-core `expires`, summary and
+unit/browser coverage. Invalid or duplicate registry entries fail closed.
+
+Expiry is exclusive and ignores prerelease suffixes: an entry expiring at
+`1.65.0` is unavailable in `1.65.0-beta.1`. Before that cycle, either remove the
+experiment or graduate it through its own reviewed issue; never extend expiry as
+an incidental change. Labs may alter presentation only and must not gate data,
+migrations, stores, HA actions or network calls. Current renderer details are in
+`docs/ISOMETRIC.md`.
+
+Demo harness render quirk: the fake `hass` in `demo.html` is set once, so opening the
+page directly in a browser renders the floor plan but **device icons only appear
+after a re-render** (an F5 refresh, or nudging `card.hass = {...card.hass}`). The
+smoke launcher `demo/serve.mjs` already does this nudge; a plain browser session does
+not. This is a harness limitation, not a card bug.
+
+## Promotion rule
+
+Every new feature or material behaviour change must be published as a beta/RC
+before it can enter a stable release, even when its local audit is clean. The
+stable release commit is promotion-only: version fields, generated bundle
+snapshots and changelog/release metadata. Do not add feature source code in
+that commit. An explicit owner-requested emergency hotfix is the only exception
+and must be called out in the release handoff.
+
+A `Release vX.Y.Z-beta.N candidate` commit is **not** promotion-only: it carries
+the work itself and follows the ordinary rules, trailers included.
+
+Issues are closed in a batch when a beta ships, not when implementation ends: that
+way a bug found in the beta returns to the same task, and the beta announcement can
+list what went in. Status labels are stripped as the issues close.
@@ -38,17 +38,6 @@ an eager import. Extend the runtime, manifest, file/key/placeholder parity and
 regional-locale tests together; never bypass the registry by importing a locale
 directly in a component.

-Administrator-only copy lives in three lazy namespace dictionaries —
-`src/i18n/settings/`, `src/i18n/support/` and `src/i18n/topology/` (#627). Their
-English file is static (the synchronous fallback); every other language is one
-lazy chunk per namespace × language: a two-line loader module
-`src/i18n/<namespace>/<namespace>-<code>.ts`, one `import()` with a
-content-hashed retry token in `src/i18n/<namespace>.ts`, and one entry in
-`NAMESPACE_LOCALE_CHUNKS` in `scripts/bundle-manifest.mjs`. The lazy surfaces
-(onboarding, editor runtime, Zigbee overlay) wait for their dictionaries before
-painting; never import a non-English namespace JSON statically — the budget
-gate and `test/i18n-lazy-namespaces.test.mjs` refuse it.
-
 The current `subst()` helper does not implement plural rules. Phrase strings so
 their grammar does not depend on the numeric value (for example, use a neutral
 label followed by `{n}` rather than an English singular/plural pair).
@@ -58,19 +47,6 @@ set; maintain the existing English and Russian documentation according to the
 project's normal rules. Right-to-left layout is a separate product project,
 because the plan canvas and editors cannot be mirrored by translations alone.

-## Documentation screenshots
-
-The images under `docs/images/` are produced only from synthetic data by the
-`Docs screenshots` workflow (`demo/docs/capture.mjs` on the pinned Chromium)
-and accepted locally with `npm run docs:accept -- --reviewed --from=<unpacked
-artifact>`; when a change cannot move a pixel, `npm run docs:accept --
--identical` re-captures locally, compares decoded pixels and refreshes only the
-source fingerprint. Scenario version, source fingerprint and every image hash
-are recorded in the [screenshot index](docs/images/screenshots.json), and
-`node scripts/check-docs.mjs` reports a stale fingerprint: a warning on an
-ordinary push, an error on a beta candidate (a commit with a `Release:`
-trailer). The full rule is in `PROCESS.md` §8.
-
 ## Where to ask

 Not sure whether something is a bug, or just want to discuss an idea before
@@ -101,25 +77,25 @@ npm install                # also installs .githooks through the prepare script

 ### Why `--filter=blob:none` (#345)

-A blobless clone keeps every commit and tag, so ranges, `merge-base` and
-`git diff` across history work exactly as in a full clone; only historical *file
-contents* are fetched on demand. Most of the pack is exactly such content that
-almost nobody reads again — documentation screenshots re-captured with the UI and
-the committed bundle rewritten by every release candidate — so a blobless clone
-is several times smaller. To see the numbers for your own clone, compare
-`git count-objects -vH` in a blobless and in a full one.
+A full clone is **215 MB of `.git`**; a blobless one is **26 MB** — measured, not
+estimated. Both carry all 1611 commits and all 182 tags, so ranges, `merge-base`
+and `git diff` across history work identically; `git diff origin/dev~3..origin/dev`
+in a blobless clone takes about a second and grows `.git` by one megabyte.
+
+The difference is that historical *file contents* are fetched only if something
+actually asks for them. That matters here because 32% of the pack is documentation
+screenshots — ten PNGs re-captured 196 times — and another sizeable share is the
+committed bundle, one 1.16 MB file per product change. Almost nobody ever reads an
+old revision of either.

 Drop the flag if you work offline with history, or need `git log -p` over the whole
 tree repeatedly. Do **not** replace it with `--depth=1`: a shallow clone is about
 the same size but has no `merge-base`, so the process gate, `smoke-select` and
 every `origin/dev..HEAD` range stop working.

-The HA-harness backend tests (`tests_backend/test_ha_*.py`) need the
-repository-pinned Python (`.python-version`) and
-`pytest-homeassistant-custom-component home-assistant-frontend`; their canon is
-Linux CI or WSL (`bash scripts/wsl-setup.sh --verify`). Without an importable
-`homeassistant` they are not collected at all — not skipped — and pytest prints
-`HA harness NOT collected: …` (#630).
+The HA-harness backend tests (`tests_backend/test_ha_*.py`) need Python ≥3.13 and
+`pytest-homeassistant-custom-component home-assistant-frontend`; CI runs them on
+every push — locally they are skipped when `homeassistant` is not importable.

 ## Ground rules

@@ -127,10 +103,8 @@ Linux CI or WSL (`bash scripts/wsl-setup.sh --verify`). Without an importable
  `docs/STATUS.md` for state changes; `docs/DEVELOPMENT.md` for new gotchas.
 - Every UI string goes through `src/i18n/<lang>.json`; follow the
  [Translations](#translations) flow for registry and backend parity.
- The committed bundle changes only in a release candidate: `npm run
-  bundle:release` in a commit with a `Release:` trailer (#657). An ordinary task
-  restores it with `npm run bundle:clean` before committing — the `commit-msg`
-  hook refuses a bundle change otherwise.
+- The built card must be committed in sync: `cp dist/houseplan-card.js
+  custom_components/houseplan/frontend/` (CI compares them byte-for-byte).
 - Tap actions have a security model (locks/alarms never toggle from the plan) —
  see `resolveToggleIntent` in `src/device-toggle.ts`; don't weaken it.
 - Every commit follows the issue and trailer contract in `PROCESS.md`.
@@ -140,5 +114,6 @@ Linux CI or WSL (`bash scripts/wsl-setup.sh --verify`). Without an importable
 ## Architecture

 Start with `docs/ARCHITECTURE.md` (data model, WS API, coordinate system) and
-`docs/STATUS.md` (current state). Release mechanics live in one place:
-`docs/DEVELOPMENT.md` › Release.
+`docs/STATUS.md` (current state). Release: bump the version in `package.json`,
+`manifest.json`, `const.py`, `CARD_VERSION`, tag `vX.Y.Z`, publish a GitHub release —
+the workflow attaches the card bundle.
@@ -1,36 +1,21 @@
 # Процесс работы над House Plan

-> **Статус документа: канон** (редакция 2026-08-13, ролевое уточнение
-> 2026-09-13). Решения владельца, на
+> **Статус документа: канон** (редакция 2026-08-13). Решения владельца, на
 > которых он стоит: прямые коммиты в `dev` **без PR** · канон статуса — **метки**,
-> имена английские · лёгкий трек **включён** · автор и ревьюер — независимые
-> агенты/сессии · любой агент может взять любую роль · инфраструктурные задачи
-> входят в общий флоу сразу на `S7-code-review`.
+> имена английские · лёгкий трек **включён** · автор и ревьюер — разные модели ·
+> инфраструктурные задачи идут **вне** флоу.
 >
 > **Область действия:** обязателен для владельца и для любого агента. Читается
 > сразу после `docs/SCOPE.md` и `AGENTS.md`, до `docs/STATUS.md`. Живёт в
 > репозитории: до августа 2026 канон лежал только в папке владельца, и свежий клон
 > его не содержал вовсе.
 >
-> **Ролевые конспекты** (#634): `docs/process/AUTHOR.md` и
-> `docs/process/REVIEWER.md` — выжимки этого файла со ссылками на его разделы.
-> Автор и ревьюер входят через них (порядок чтения по роли — `AGENTS.md`) и
-> открывают раздел канона, когда пункт конспекта касается текущего шага.
-> Правил конспекты не добавляют; при расхождении побеждает этот файл. Ссылки и
-> ключевые формулировки конспектов сверяет `test/process-digests.test.mjs`,
-> поэтому правка формулировки здесь правит и конспект тем же коммитом.
->
 > **Приоритет источников.** Канонический бэклог — GitHub Issues; статус живёт в
 > метках и больше нигде: Project v2 не используется. При расхождении
-> документации с GitHub побеждает GitHub. Этот файл — единственный полный канон
-> процесса в репозитории; `AGENTS.md` — его короткое обязательное резюме, а
-> внешний `CODEX-RUNBOOK.md` — только маршрутизатор к канону и историческим
-> инструкциям. Текущие версии, состояние конкретных issue, runtime pins и списки
-> jobs не копируются в производную прозу: они читаются из своих исполняемых
-> источников.
-> При расхождении этого документа с `.github/workflows/*.yml` и `scripts/*`
-> побеждает **фактическая автоматизация**: она исполняется, а описание — нет.
-> Расхождение при этом не игнорируется, а заводится issue с меткой `process`.
+> документации с GitHub побеждает GitHub. При расхождении этого документа с
+> `.github/workflows/*.yml` и `scripts/*` побеждает **фактическая автоматизация**:
+> она исполняется, а описание — нет. Расхождение при этом не игнорируется, а
+> заводится issue с меткой `process`.
 >
 > При расхождении процесса и привычки побеждает процесс.

@@ -50,7 +35,7 @@
 | **A. Продукт** | `src/**`, `custom_components/houseplan/**/*.py`, `manifest.json`, `hacs.json`, `src/i18n/*.json`, `custom_components/**/translations/*` | **Да, обязательно.** Только из «Готово к разработке» или дальше |
 | **B. Гейты и инструменты** | `test/**`, `tests_backend/**`, `demo/**`, `scripts/**`, весь `.github/**`, `.githooks/**`, `rollup.config.mjs`, `tsconfig*.json`, `package.json`, `package-lock.json`, `pytest.ini`, `.gitignore`, `.gitattributes` | **Да.** Может использовать issue того изменения, которое покрывает; самостоятельная работа над гейтом получает свой issue (тип `tech-debt`) |
 | **C. Документация** | `docs/**`, `README*`, `CHANGELOG*`, `AGENTS.md`, `CONTRIBUTING.md`, `PROCESS*.md`, `LICENSE`, `(CODE\|SPEC)-REVIEW-*.md` | Документирование A/B в том же коммите — часть DoD своего issue. Самостоятельная работа над документацией — свой issue |
-| **D. Сгенерированное** | `dist/**`, `custom_components/houseplan/frontend/**`, `demo/golden/baselines/**` (копия стенда `demo/srv/assets/houseplan-card.js` с #255 не коммитится вовсе) | Никогда не меняется само по себе. Коммит **только** класса D допустим лишь как релизный промоушен или как принятие эталонов с доказательством ревью. **Бандл** (`dist/**`, `custom_components/houseplan/frontend/**`) с #657 меняет только коммит с трейлером `Release:` — кандидат беты или релиза (`npm run bundle:release`); в обычной задаче закоммиченный бандл законно отстаёт от исходников, сборка в коммит не идёт (`npm run bundle:clean`). Судит `validate-commit-provenance.mjs` — хук `commit-msg` и история в CI |
+| **D. Сгенерированное** | `dist/**`, `custom_components/houseplan/frontend/**`, `demo/golden/baselines/**` (копия стенда `demo/srv/assets/houseplan-card.js` с #255 не коммитится вовсе) | Никогда не меняется само по себе. Коммит **только** класса D допустим лишь как релизный промоушен или как принятие эталонов с доказательством ревью |

 Практический смысл таблицы: «я только поправил тест» и «я только пересобрал
 бандл» перестают быть лазейками.
@@ -59,20 +44,13 @@
 лежит внутри `custom_components/houseplan/frontend/`, и без этого правила он
 считался бы продуктовым исходником.

-**Инфраструктурная задача использует ускоренный вход в общий флоу** (решение
-владельца 2026-09-13, issue #562). Признак механический: **ни одного файла класса
-A**. Любой агент может сразу реализовать её по issue и в ветке
-`issue/<NN>-<slug>`, без аналитики, ТЗ, ревью ТЗ и статусов `S1`…`S6`. Когда
-материал готов, локальные гейты зелёные и ветка запушена, исполнитель ставит
-`S7-code-review`. Дальше действует тот же контроллер, что для продуктового кода:
-зелёное ревью сливает проверенный материал в `dev` и ставит `S8-merged`, а
-замечания или неудавшееся слияние возвращают задачу в `S6-in-progress`; после
-исправлений она снова идёт в `S7-code-review`.
-
-Отсутствие ТЗ не означает отсутствие проверки. Для инфраструктуры обязательны
-issue, терминальные трейлеры, соразмерные изменению зелёные гейты, хендофф с
-доказательствами и независимое код-ревью. Модель или имя агента процессом не
-предписываются.
+**Инфраструктурная задача идёт вне флоу** (решение владельца 2026-08-13,
+issue #118). Признак механический: **ни одного файла класса A**. Такая задача
+делается без ТЗ, ревью ТЗ, код-ревью и без прохода по статусам — флоу построен
+для изменений, у которых есть персона и видимое поведение, а в инфраструктуре ТЗ
+пересказывало бы очевидное, и автор с ревьюером оказались бы одной ролью.
+Проверкой служат гейты и CI. Обязательным остаётся issue, трейлеры и зелёные
+`typecheck`, `test`, `build`.

 Задача, задевающая класс A хотя бы одним файлом, инфраструктурной **не
 является** и идёт полным флоу. «В основном инфраструктурная» не бывает: иначе
@@ -83,8 +61,7 @@ issue, терминальные трейлеры, соразмерные изм

 ## 2. Жизненный цикл

-Восемь рабочих статусов и два служебных. Полный маршрут ниже относится к
-продуктовым задачам. Фазы тестирования в цикле сознательно
+Восемь рабочих статусов и два служебных. Фазы тестирования в цикле сознательно
 **нет**: найденные позже дефекты заводятся отдельными issue и проходят цикл
 заново. Issue закрывается после выпуска беты.

@@ -95,7 +72,6 @@ S1-new → S2-analysis → S3-spec → S4-spec-review ⟲ → S5-ready →
 служебные:  blocked (поверх статуса)   rejected (закрыт)
 ⟲ — возврат на правки, не более 4 циклов (§4), на лёгком и коротком треке 2
 короткий трек (`trivial`, §5.1) идёт S2-analysis → S5-ready, минуя S3 и S4
-инфраструктурный трек (§1): без S → S7-code-review ⟲ S6-in-progress → S8-merged
 ```

 Переходы `S4-spec-review` и `S7-code-review` выполняются **автоматически**: метка
@@ -146,12 +122,9 @@ S1-new → S2-analysis → S3-spec → S4-spec-review ⟲ → S5-ready →
 ### 2.3 ТЗ в работе — написание ТЗ

 - **Кто:** автор ТЗ, назначает себя. Статус означает «занято».
- **Артефакт:** **тело issue**, раздел `## ТЗ` (решение владельца 2026-09-10,
-  #517). Файл в `docs/specs/` не создаётся ни на одном треке: каталог — архив
-  ТЗ до этой даты, и задачи, у которых файл уже есть, доживают по старой схеме.
-  Доказуемость («вердикт вынесен на этом тексте») держит конвейер: в блок якорей
-  документа ревью пишется `sha256` нормализованного тела, и правка ТЗ после
-  зелёного ревью ТЗ приходит ревьюеру кода находкой, а не тишиной.
+- **Артефакт:** `docs/specs/<NN>-<slug>.md`, где `NN` — **номер issue**.
+  Многоэтапная задача: `<NN>-<slug>-stage<N>.md`.
+- **Лёгкий трек:** ТЗ пишется в теле issue, файл не создаётся (§5).
 - **Выход:** полная первая редакция по §7.

 ### 2.4 ТЗ на ревью
@@ -182,8 +155,8 @@ S1-new → S2-analysis → S3-spec → S4-spec-review ⟲ → S5-ready →
 - миграция и compatibility-поля решены по `docs/CONFIG-COMPATIBILITY.md`;
 - влияние на производительность и бюджеты названо (или явно «нет»);
 - влияние на touch по `docs/TOUCH-SUPPORT.md` (View и киоск — блокирующие);
- release-артефакты названы: changelog RU+EN, документация, golden/скриншоты,
-  performance/security — либо явное «нет»;
+- release-артефакты по правилу `docs/specs/README.md` (changelog RU+EN,
+  документация, golden/скриншоты, performance/security);
 - **откат**: как выключить или вернуть назад (флаг Labs, обратная миграция);
 - открытых продуктовых вопросов нет; риски перечислены.

@@ -202,22 +175,12 @@ S1-new → S2-analysis → S3-spec → S4-spec-review ⟲ → S5-ready →
  `unit`/`backend`/`smoke`/`golden`, получает свою проверку здесь же.
  «Тестирование вне жизненного цикла» означает отсутствие фазы ручного
  тестирования, а не отсутствие тестов.
- **Приёмка проверяет результат для человека, а не строки реализации.** Для
-  изменённой поверхности автор выбирает обычный сценарий и самый рискованный
-  применимый соседний случай; у каждого должен быть наблюдаемый oracle — что
-  пользователь видит, может сделать или что система отказывается делать. При
-  выборе случаев коротко пройти шесть классов риска: async (порядок, отмена,
-  устаревший ответ); данные и права (пусто, нет связи, несколько источников,
-  отказ); геометрия (границы, стыки, трансформации); визуал (промежуточный кадр,
-  тема, zoom/DPR); объём данных и performance; host/input (HA, кэш, mouse/touch/
-  keyboard). Неприменимое так и отмечается; проверка имени метода или строки
-  исходника пользовательским oracle не считается.
 - **Скоуп не расширяется.** Найденное по пути становится новым issue в «Новое».
  Если находка блокирует — текущий issue уходит в «Заблокировано» со ссылкой.
  Попутных правок «раз уж я здесь» не бывает.
- **Документация — в том же коммите,** что и поведение: changelog RU+EN для
-  пользовательского, `STATUS.md` для состояния, `DEVELOPMENT.md` для новых
-  грабель, `ARCHITECTURE.md` для дизайна.
+- **Документация — в том же коммите,** что и поведение (действующая политика
+  `docs/STATUS.md`): changelog RU+EN для пользовательского, `STATUS.md` для
+  состояния, `DEVELOPMENT.md` для новых грабель, `ARCHITECTURE.md` для дизайна.
 - **Выход:** локальный гейт зелёный (§8), хендофф-комментарий (§7.2).

 ### 2.7 Код-ревью
@@ -226,85 +189,19 @@ S1-new → S2-analysis → S3-spec → S4-spec-review ⟲ → S5-ready →
 - **Артефакт:** `docs/reviews/CODE-REVIEW-<tag|NN>-r<N>.md` в действующем
  формате: скоуп, как проверялось (таблица гейтов с результатами), находки
  High/Medium/Low с воспроизведением, что проверено и корректно, чего не проверял.
- **Ревьюер отвечает за полноту доказательств AC, а не заменяет их исполнение.**
-  Каждый AC либо доказан автотестом — и ревьюер убедился, что **тест умеет
-  падать**, — либо разобран по коду с явной записью «проверено чтением, не
-  исполнением». Чтение кода выявляет риски, но не доказывает наблюдаемый
-  пользовательский результат; если соразмерный исполнимый oracle возможен, его
-  отсутствие — находка. Ревьюер отдельно сверяет применимые классы риска из
-  §2.6 и не выдаёт запуск гейта за проверку сценария, которого в гейте нет.
- **Защитный AC доказывается таблицей «чем краснеет» (#435).** Для каждого AC,
-  заявляющего защиту — валидация, гард, лимит, отказ, инвариант, — в документе
-  ревью обязательна строка из трёх столбцов: **AC · чем доказан** (точная
-  команда или имя теста) **· чем краснеет** — мутация, снятая защита или
-  отрицательная проба, с результатом прогона. Пустой третий столбец — находка
-  Medium, а не примечание.
-
-  «Тест умеет падать» без названной мутации и её вывода доказательством не
-  является. Аудит v1.71.0-beta.1 нашёл пять контрактов #51 и #423, где тест
-  оставался зелёным на снятой защите; все пять прошли код-ревью как доказанные,
-  а два теста были записаны в закрытие coverage-ratchet под именами, обещавшими
-  то, чего они не проверяли (#430).
-
-  Мутант в `scripts/mutation-gate.mjs` обязателен, когда защита живёт в
-  продуктовом коде и проверяется дорогим гейтом (смок, бэкенд, golden): там
-  ревьюер не воспроизведёт отрицательный прогон второй раз. Для чистых юнитов
-  достаточно прогона со снятой защитой, приведённого в документе.
-
-  Новый мутант с browser-smoke guard допустим только когда инвариант нельзя
-  доказать без браузера: `because` обязан назвать конкретную зависимость от
-  DOM/CSS paint, измеренной геометрии, trusted pointer/lifecycle или browser
-  wall-time, а id — попасть в размеченный реестр
-  `docs/testing-notes/mutation-browser-guards.md`. `mutation-gate --check`
-  показывает число browser guards против лимита 200, краснеет при росте выше
-  лимита и предупреждает о любом id без browser-обоснования; ревьюер проверяет
-  не только наличие строки, но и невозможность более дешёвого `node --test`.
-
-  Считаются **защитные AC без названного свидетеля**, а не мутанты на
-  подсистему: у #421 мутанты были, и дыра всё равно проехала. «Сколько мутантов
-  принесла задача» остаётся признаком — у #423 их ноль, и именно у #423 нашёлся
-  тест, спрашивавший регулярку, находит ли она подстроку, которую сам же и
-  вырезал.
-
-  Правило не распространяется на AC, не заявляющие защиту (расположение, текст,
-  формат вывода): там свидетель — обычное сравнение ожидаемого с фактическим, и
-  третий столбец превратился бы в ритуал. И не отменяет «проверено чтением»:
-  тогда во втором столбце стоит «чтением», а не имя теста, и читатель ревью
-  видит разницу.
+- **Ревьюер отвечает за AC.** Раз ручного тестирования в цикле нет, именно ревью
+  кода отвечает на вопрос «оно вообще работает»: каждый AC либо доказан
+  автотестом — и ревьюер убедился, что **тест умеет падать**, — либо разобран по
+  коду с явной записью «проверено чтением, не исполнением».
 - **High блокируют.** Medium **в скоупе задачи** чинится в текущем issue:
  без High это жёлтый вердикт и возврат автору, фикс проходит повторный цикл.
-  Medium **вне скоупа** — отдельный issue (#202). Жёлтый вердикт законен и
-  тогда, когда все AC выполнены, если изменение не решает заявленный сценарий
-  или ухудшает соседний.
+  Medium **вне скоупа** — отдельный issue (#202).
 - **Вердикт привязан к SHA (#312).** Все числа и факты отчёта сверяются с
  `git rev-parse HEAD` непосредственно перед подведением итогов, а не с SHA,
  зафиксированным в начале разбора: во время ревью в ветку может прилететь
  fix-up. Серверный стопор — шаг слияния конвейера сверяет вершину ветки с
  SHA материала ревью (допустим только собственный doc-коммит публикации
  поверх) и при расхождении отменяет слияние с возвратом в `S6-in-progress`.
- **Контракты по монолиту — исполнением, не regex по тексту (#624).**
-  Новое утверждение о `src/houseplan-card.ts` или
-  `src/houseplan-editor-runtime.ts` доказывается экспортом функции и её
-  вызовом в `test-build`, а не поиском строки в исходнике: текстовый якорь
-  краснеет на переносе метода без единой регрессии, и это делает вынос дороже,
-  чем оставить монолит как есть. Список тестов, читающих монолит как текст,
-  заморожен (`FROZEN_TEXT_ANCHOR_TESTS` в `test/monolith-text-anchors.test.mjs`)
-  и может только уменьшаться; новое имя в нём — находка ревью, а не запись в
-  список. Связность монолита измеряется шестью числами
-  (`scripts/monolith-metrics.mjs`: делегаты, члены порта, `host.`, приватные
-  члены порта и харнесса, байты `dist/`), база — `scripts/monolith-baseline.json`;
-  гейт `npm run lint:unused` (в `gate:small` и Validate после сборки) красит
-  рост любого из них и любой мёртвый код по `noUnusedLocals` вне порта и
-  харнесса. Снижение фиксируется тем же коммитом
-  (`node scripts/unused-locals-gate.mjs --update`); рост — только с записью в
-  issue задачи и правкой базы в том же коммите.
- **Смок входит в сценарий через публичную поверхность (#629).** DOM с
-  контрактными хуками, события HA и фикстуры, тестовый фасад `window.__hpTest`
-  (`docs/TESTING.md`, «Тестовый фасад и приватное состояние»). Приватное поле
-  карточки — только для чтения в ассертах. Новая запись в него без
-  `// private-ok: <конкретная причина>` — находка ревью, даже если гейт
-  `no-new-private-writes` её не увидел (мутация через вызов, запись через
-  псевдоним).
 - **Выход:** очередь на пре-релиз либо возврат в «В разработке», не более
  4 циклов (§4). Второй и последующие циклы разбираются по дельте (§2.10).

@@ -340,85 +237,22 @@ S1-new → S2-analysis → S3-spec → S4-spec-review ⟲ → S5-ready →

 Порядок:

-1. найти вердикт предыдущего раунда и **материал, на котором он получен**.
-   Материал объявлен блоком «Материал раунда» в конце документа предыдущего
-   раунда: конвейер дописывает туда SHA ветки, **дерево** материала и **блоб**
-   каждого ТЗ вместе с командами поиска (issue #416). Блок машинный — править
-   его руками не нужно и не следует;
+1. найти вердикт предыдущего раунда и **SHA, на котором он получен**; SHA в
+   вердикте не назван — это находка;
 2. объявить дельту: `git diff <тот SHA>..HEAD` для кода, дифф файла ТЗ либо тела
-   issue для этапа ТЗ.
-
-   **Если SHA не резолвится — это не находка, а обычное дело.** Ветку задачи
-   между раундами перебазируют, сквошат или удаляют, и SHA умирает: по корпусу
-   ревью таких объявлений 98 из 804. Материал в этом случае берётся по якорям,
-   которые ребейз не меняет, потому что адресуются содержимым:
-
-   ```
-   git log --all --format='%H %T' | grep <дерево>
-   git log --all --find-object=<блоб> -- <путь к ТЗ>
-   ```
-
-   Находкой остаётся другое: **SHA, мёртвый уже в момент публикации отчёта** —
-   он означает, что значение сняли до `amend` или `rebase` и не сверили перед
-   выводом, как требует §2.7 («Вердикт привязан к SHA»). Это отличие не
-   теоретическое: на #403 оба источника, автор и ревьюер, независимо назвали один
-   и тот же осиротевший SHA, и следующий раунд восстанавливал коммит по
-   содержимому диффа руками (issue #413). Конвейер теперь такую публикацию останавливает сам;
+   issue для этапа ТЗ;
 3. по каждой находке предыдущего раунда показать, **чем именно она закрыта** —
   строкой кода или текста, а не заявлением автора;
 4. заново проверять только те AC, чьё доказательство дельта задевает;
 5. **раздел «Унаследовано из r<N−1>»** обязателен: что принято без повторной
-   проверки, со ссылкой на документ того раунда и его материал. Без перечня
-   сокращение превращается в молчаливое доверие.
+   проверки, со ссылкой на документ того раунда и SHA. Без перечня сокращение
+   превращается в молчаливое доверие.

-**Индекс документов ревью** — `docs/reviews/INDEX.md` (#635): одна строка на
-документ — issue, этап, раунд, вердикт, число High/Medium, заголовки находок,
-файлы из находок (искать по имени файла: `grep form-kit docs/reviews/INDEX.md`).
-Файл генерируется `node scripts/reviews-index.mjs` и пересобирается **только
-коммитами, идущими в `dev`** (#657, решение 1б): слиянием кандидата —
-после ребейза, а если `dev` не двигался, то поверх материала перед
-fast-forward (`--commit-if-stale`, коммит класса C) — и публикацией документа ревью ТЗ
-прямо в `dev`. В ветке задачи индекс не пересобирается — ни при приведении к
-dev, ни при публикации документа код-ревью: иначе две параллельные задачи
-конфликтуют на нём по построению. Руками не правится. Конфликт ребейза, в котором **все** пути —
-`INDEX.md`, отказом не считается (#643): `scripts/rebase-generated.mjs`
-пересобирает индекс по каталогу на остановке и продолжает ребейз — так делают
-приведение к dev, слияние кандидата и авторский `rebase-on-dev.mjs`; индекс
-вместе с любым другим путём — прежний отказ с перечнем файлов. Шаг Validate
-«индекс ревью совпадает с каталогом» красит push в `dev`, где `INDEX.md`
-расходится с каталогом (на issue-ветках не судится: их переписывает конвейер).
-Правка `docs/reviews/`
-руками — перенос в `legacy/`, удаление — сопровождается
-`node scripts/reviews-index.mjs` в том же коммите. Прежде чем брать
-задачу по подсистеме, стоит прочитать её строки в индексе: что находили и чем
-закрывали — там, а не в тысяче файлов. Уроки, пережившие свою задачу,
-собираются в `docs/LESSONS.md` с датой и ссылкой на источник.
-
-**Хранение документов** (решение владельца 23.09, #635): в `docs/reviews/`
-лежат все раунды всех задач текущей линии — предыдущие раунды нужны ссылкам
-«Унаследовано из r<N−1>» и якорям материала. При стабильном релизе документы
-задач, вошедших в него, переносятся в `legacy/reviews/<vX.Y.Z>/` одним
-коммитом класса C; индекс пересобирается и перечисляет только живые. Перенос —
-часть чеклиста стабильного релиза, не отдельная задача, и делает его
-`node scripts/reviews-archive.mjs --through=vX.Y.Z` (без `--apply` — только
-план, #682). Членство — трейлеры `Issue: #NN` в диапазоне линии, как у
-манифеста беты и ревью линии (§11.5); метка не доказательство. Уточнения:
-задача с трейлером и после тега остаётся в `docs/reviews/` целиком — её раунды
-ещё продолжаются; задача с трейлерами в двух выпущенных линиях уезжает целиком
-в последнюю; закрытая без выпуска (как #522) уезжает с линией, где лёг её
-документ — коммит документа несёт трейлер; `RELEASE-REVIEW-vX.Y.Z.md` уходит в
-каталог своего тега, поэтому перенос делается после публикации ревью линии.
-Относительные ссылки в перенесённых документах и в соседях, которые на них
-ссылаются, инструмент переписывает сам; `--check-links` печатает оставшиеся
-битые.
-Перенос идёт при пустой очереди `S7-code-review`: ребейз чужой ветки иначе
-упрётся в перемещённый каталог.
-
-Дешёвые гейты (`typecheck`, `test`, `build` с проверкой целостности сборки, `bundle-policy --verify`) гоняются в
+Дешёвые гейты (`typecheck`, `test`, `build` со сверкой копий бандла) гоняются в
 каждом раунде: код изменился, а стоят они минуты. Тяжёлые — по дельте (§10.2).

 **Разбор остаётся полным**, если дельта не локальна: ребейз на ушедший вперёд
-`dev` (после ребейза это другой код, §10.4), смена контракта поведения, задета
+`dev` (после ребейза это другой код, §7.2), смена контракта поведения, задета
 новая подсистема, либо объём дельты сопоставим с исходной задачей.

 Сокращается объём **разбора, а не строгость**: правка по замечанию способна
@@ -461,14 +295,9 @@ dev, ни при публикации документа код-ревью: ин
 11. **Документация — в том же коммите, что поведение.** Отдельным «допишу потом»
    коммитом документация не бывает.
 12. **Сгенерированное не коммитится само по себе.** Только релизный промоушен или
-    принятие эталонов с доказательством ревью: URL Linux CI run либо хеш
-    аттестованного WSL-артефакта.
+    принятие эталонов со ссылкой на прогон CI.
 13. **Golden-эталоны принимаются только** `npm run golden:accept -- --reviewed` по
-    полному Linux-артефакту: либо GitHub CI, либо `npm run golden:wsl:capture` в
-    WSL/ext4 с clean опубликованным SHA и машинно-проверяемым паспортом. Второй
-    путь убирает только первый ожидаемо красный CI-прогон; полный GitHub Validate
-    на точном SHA коммита с эталонами остаётся обязательным. Принятие ради
-    зелёного CI — нарушение процесса.
+    полному Linux-артефакту. Принятие ради зелёного CI — нарушение процесса.
 14. **Issue закрывается после выпуска беты** с зелёным CI на точном SHA. Не
    раньше, не «по факту наличия кода», не исполнителем.
 15. **Закрытый issue не переоткрывается.** Новый дефект — новый issue со ссылкой.
@@ -550,20 +379,19 @@ dev, ни при публикации документа код-ревью: ин

 **Что упрощается:**

- ТЗ короче: проблема · контракт · AC1…ACn с доказательством · откат
-  (в теле issue, как и на полном треке с 2026-09-10);
+- ТЗ пишется **в теле issue** по шаблону: проблема · контракт · AC1…ACn с
+  доказательством · откат. Файл в `docs/specs/` не создаётся;
 - ревью ТЗ — комментарий второго агента, отдельный документ не нужен;
 - лимит ревью ТЗ — 2 цикла.

 **Что не упрощается:** issue, оценка, статусы, трейлеры коммитов, changelog,
-**код-ревью и его документ**, закрытие после беты. Код-ревью не пропускается:
-оно проверяет скоуп, риски и качество доказательств, но не заменяет исполнение
-тестов. Единственное исключение из повторного ревью — починка упавшего
-предрелизного гейта, §11.4.
+**код-ревью и его документ**, закрытие после беты. Код-ревью не пропускается
+никогда — именно оно в этом процессе заменяет тестирование. Единственное
+исключение — починка упавшего предрелизного гейта, §11.4.

 Если по ходу выясняется, что критерий нарушен (появилась миграция, задело второй
 модуль) — метка `small` снимается, issue возвращается в `S3-spec` и получает
-полное ТЗ в теле issue по §7.1. Это не провал, это ранняя диагностика.
+нормальный файл ТЗ. Это не провал, это ранняя диагностика.

 ### 5.1 Короткий трек (метка `trivial`)

@@ -611,7 +439,7 @@ dev, ни при публикации документа код-ревью: ин
 | Роль | Делает | Не имеет права |
 |---|---|---|
 | Аналитик | разбор, оценки, поверхности | окончательно ставить приоритет |
-| Автор ТЗ | раздел `## ТЗ` в теле issue | ревьюить своё ТЗ |
+| Автор ТЗ | `docs/specs/NN-*.md` или ТЗ в issue | ревьюить своё ТЗ |
 | Ревьюер ТЗ | `docs/reviews/SPEC-REVIEW-NN-rN.md` | править ТЗ вместо автора |
 | Разработчик | код, автотесты, документация, changelog | ревьюить свой код, принимать golden |
 | Ревьюер кода | `docs/reviews/CODE-REVIEW-*-rN.md`, проверка AC | править продуктовый код |
@@ -621,18 +449,19 @@ dev, ни при публикации документа код-ревью: ин
 **Правило разделения:** ревьюер работает состязательно. Ему передаётся тег или
 диапазон коммитов и ТЗ — не рассказ автора о том, как всё хорошо.

-**Роли не закреплены за моделями или именами агентов** (решение владельца
-2026-09-13, issue #562). Codex, Claude или любой другой доступный агент может быть
-аналитиком, автором ТЗ, разработчиком, автором инфраструктурной задачи или
-релиз-инженером по прямой команде владельца.
+**Роли закреплены за исполнителями** (решение владельца 2026-08-12):

-Разделение относится к артефакту: **автор и ревьюер — разные агенты/сессии**.
-Модель может совпадать, но ревьюер начинает без контекста реализации и не ставит
-вердикт собственной работе. Ревью ТЗ и код-ревью также идут в независимых
-сессиях: ревьюер кода не должен приходить с контекстом обсуждения ТЗ.
+| Исполнитель | Роли |
+|---|---|
+| **Codex** | аналитик, автор ТЗ, разработчик, релиз-инженер по команде владельца |
+| **Claude** | ревьюер ТЗ, ревьюер кода, вся инфраструктура и дистрибуция |
+| **Владелец** | приоритет, скоуп, арбитраж, закрытие issue, команда на выпуск |

-Владелец сохраняет исключительные решения о приоритете, ценности, продуктовом
-скоупе, отклонении, арбитраже, закрытии issue и команде на выпуск.
+Автор и ревьюер — **разные модели**, и это сильнее требования «другая сессия»:
+одна модель, читая свой же артефакт заново, повторяет свои же слепые пятна.
+
+Ревью ТЗ и код-ревью держатся в **разных сессиях** Claude: ревьюер кода не должен
+приходить с контекстом того, как обсуждали ТЗ.

 ---

@@ -642,7 +471,7 @@ dev, ни при публикации документа код-ревью: ин

 ```
 issue #NN
-  ↔ ТЗ            тело issue, раздел `## ТЗ`         (хеш тела — в якорях ревью)
+  ↔ ТЗ            docs/specs/NN-slug.md              (или тело issue при `small`)
  ↔ ревью ТЗ      docs/reviews/SPEC-REVIEW-NN-rN.md  (или комментарий при `small`)
  ↔ ветка         issue/NN-slug
  ↔ коммиты       трейлеры  Issue: #NN · User-Visible: yes|no
@@ -713,6 +542,17 @@ issue #NN
 прогон показал, почему это неверно: жёлтый там означал, что AC описывает неверное
 изменение контракта — реализовать такое ТЗ значило бы сделать ошибку по инструкции.

+### 7.3 Расхождения с текущим состоянием, которые надо закрыть
+
+1. **Статус ТЗ дублирует статус issue.** `docs/specs/README.md` держит колонку
+   «Статус ТЗ» со своим словарём («черновик решения», «в реализации»,
+   «реализовано»). Два источника статуса уже расходятся. Колонку убрать, оставить
+   таблицу «issue ↔ ТЗ».
+2. **Ревью до релиза 1.62 живут вне репозитория.** Документы `CODE-REVIEW-*.md` и
+   `SPEC-REVIEW-*.md` за прежний период лежат в папке владельца, и переносить их
+   задним числом смысла нет: они описывают код, которого уже нет. Новые документы
+   ревью кладёт в `docs/reviews/` сам конвейер, в ветку задачи.
+
 ---

 ## 8. Гейты
@@ -723,26 +563,21 @@ issue #NN
 ```
 npx tsc --noEmit
 npm test
-npm run build && node scripts/bundle-policy.mjs --verify HEAD
-              # сборка цела; копии сверяются только на кандидате (#657).
-              # Копия стенда — `npm run bundle:sync` (#255); перед коммитом `npm run bundle:clean`
+npm run build && cmp dist/houseplan-card.js custom_components/houseplan/frontend/houseplan-card.js \
+              # копия стенда собирается `npm run bundle:sync`, в репозитории её нет (#255)
 node scripts/smoke-select.mjs --base origin/dev --head HEAD   # какие смоки относятся к диффу
 node demo/smoke_<целевые>.mjs
 node scripts/no-new-any.mjs --base origin/dev --head HEAD     # новый код не добавляет any
 npm run golden:verify                 # если менялся визуал
 node scripts/check-docs.mjs           # если менялся src/**
 node scripts/model-invariants.mjs --config <экспорт>   # если правилась геометрия или ссылки
-python -m pytest tests_backend -q     # py3.14 как в CI (npm run toolchain:check), если менялся бэкенд
-npx tsc -p tsconfig.junction-parity.json && node scripts/fix-test-build.mjs \
-  && python tests_backend/junction_parity.py --build-dir=test-build/junction-parity
-                                      # если менялось одно из зеркал junction limits
+python -m pytest tests_backend -q     # py3.13, если менялся бэкенд
 ```

-**Новый код не добавляет `any`** (#342). Явного `any` в `src/**` — сотни
-вхождений (`node scripts/no-new-any.mjs --total`); перетипизировать это одним
-заходом — месяц риска ради нуля пользовательской ценности, поэтому долг
-снимается при плановом извлечении подсистем (#425, прежний #34), а не разовой
-заменой. Гейт `scripts/no-new-any.mjs` судит
+**Новый код не добавляет `any`** (#342). В `src/**` уже 1034 вхождения явного
+`any` в 49 файлах; перетипизировать это одним заходом — месяц риска ради нуля
+пользовательской ценности, поэтому долг снимается при плановом извлечении
+подсистем (#34), а не разовой заменой. Гейт `scripts/no-new-any.mjs` судит
 **только добавленные строки**: существующий долг на нетронутой строке законен,
 правка строки со старым `any` — новая ответственность. Исключение объявляется на
 той же строке, `// any-ok: <конкретная причина>`; голый маркер и причины вида
@@ -750,7 +585,7 @@ npx tsc -p tsconfig.junction-parity.json && node scripts/fix-test-build.mjs \
 комментарии, строке или идентификаторе ложных срабатываний не даёт.

 **Объём гейтов на код-ревью соразмерен задаче** (issue #127). Всегда:
-`typecheck`, `npm test`, `npm run build` с `bundle-policy --verify` (копии сверяются на кандидате, #657), а при
+`typecheck`, `npm test`, `npm run build` со сверкой трёх копий бандла, а при
 любом diff'е по `src/**` — ещё и `node scripts/check-docs.mjs`. По
 необходимости, определяемой diff'ом и AC: браузерные смоки (сколько их —
 считает `ls demo/smoke_*.mjs | wc -l`, вшитое число здесь трижды отставало от
@@ -769,31 +604,13 @@ npx tsc -p tsconfig.junction-parity.json && node scripts/fix-test-build.mjs \
 дерева, не тем капчуром, не называет свой Chromium или неполон; коммит делает
 человек.

-Когда правка `src/**` кадров не меняет — а это большинство правок — CI-цикл не
-нужен (#512): `npm run docs:accept -- --identical` снимает кадры локально,
-декодирует оба набора в Chromium и при нуле отличающихся пикселей во всех
-кадрах обновляет только отпечаток исходников в `screenshots.json`; байты
-закоммиченных PNG, их sha, браузер и упаковщик съёмки остаются прежними. Хотя бы
-один отличающийся пиксель — отказ с перечнем кадров и штатный путь через артефакт.
-
 `check-docs` стоит в обязательной части не по важности, а по механике: отпечаток
 скриншотов документации считается по всему `src/**`, поэтому **любая** правка
 фронтенда делает его устаревшим. Выборка «по diff и AC» здесь не работает — diff
 всегда попадает, и решать нечего. Цена пропуска измерена: скриншоты не
 пересняли в #230 и #234, и `dev` стоял с красным job `docs`, пока это не нашли
-при следующей задаче (#237). Пересъёмка — по двум абзацам выше, коммит
-вместе с задачей.
-
-**Перф-смок в Validate зависит от диффа** (#473). Два glow-профиля
-гоняются всегда; при правке `src/iso-*` добавляется `large-house-isometric-v1`,
-при правке `src/live-*`, `src/render-*`, `houseplan-render-lifecycle.ts`,
-`houseplan-card.ts` — `large-house-interaction-v1`, оба по три образца против
-абсолютных потолков `hardMaxMs` полных профилей (`budgets-*-smoke.json`).
-Это гейт на «в разы», а не «на проценты»: регрессия #160 (первый кадр 9 870 мс
-против потолка 3 500) ловится ещё в ревью, а не предрелизным гейтом под тегом.
-Классификацию делает `scripts/classify-changes.mjs`, набор профилей входит в
-ключ переиспользования `performance_smoke`. Ревьюер по-прежнему принимает
-зелёный Validate на SHA как подтверждение дешёвых гейтов — смок его часть.
+при следующей задаче (#237). Пересъёмка — `npm run build && node
+demo/docs/capture.mjs`, коммит вместе с задачей.

 Условие честности такого сужения: ревьюер обязан перечислить, какие гейты прогнал,
 какие нет и почему. Непрогнанный гейт становится видимым решением, а не молчаливым
@@ -817,11 +634,7 @@ npx tsc -p tsconfig.junction-parity.json && node scripts/fix-test-build.mjs \
 достаточен для продолжения релиза, повторное код-ревью не требуется — §11.4.

 **Гейт стабильного релиза:** полный локальный прогон плюс Validate и Full
-Performance зелёные на точном SHA, плюс зелёный E2E на реальном Home Assistant:
-`release.yml` сам запускает `e2e.yml` в `houseplan-e2e` на SHA кандидата и ждёт
-его зелёного (#514, #540); установочные ассеты публикуются только после всех
-гейтов и только этим workflow — релиз, опубликованный руками, возвращается в
-черновик до их прохождения (#540); статусов issue не касается.
+Performance зелёные на точном SHA; статусов issue не касается.

 ---

@@ -855,22 +668,18 @@ Performance зелёные на точном SHA, плюс зелёный E2E н
 Тематические метки (`polish`, `infra`, `tests`, `docs`, `security`, `vacuum`)
 ортогональны процессу.

-Инварианты: продуктовая задача в процессе несёт **ровно одну `S*`-метку**.
-Инфраструктурная задача может не иметь `S*` во время первоначальной реализации;
-с первого `S7-code-review` на неё действует тот же инвариант ровно одной метки.
-Закрытый issue статусных меток не несёт; `blocked` не заменяет статус, а дополняет
-его.
+Инварианты: **ровно одна `S*`-метка** на открытом issue; закрытый issue статусных
+меток не несёт; `blocked` не заменяет статус, а дополняет его.

 **Чужой issue берётся в работу так же, как свой — после явного решения
 владельца** (решение владельца 2026-08-13, уточнено в тот же день). Репозиторий
 публичный, отчёты заводят и посторонние; проверка стоит **на входе**, а не на
 каждом шаге.

-Для продуктовой задачи входом служит присвоение первой статусной метки. Для
-инфраструктурной — явное назначение владельцем; до готовности к первому
-код-ревью она может оставаться без `S*`. Как только продуктовая задача вошла в
-полный маршрут либо инфраструктурная получила `S7-code-review`, **кто её завёл,
-дальше не имеет значения** — статусы, ревью и лимиты работают одинаково.
+Входом служит присвоение первой статусной метки: пока меток нет, issue вне
+процесса и инварианты на него не распространяются. Как только метка стоит, задача
+в работе, и **кто её завёл, дальше не имеет значения** — статусы, ревью и лимиты
+работают одинаково.

 Присвоение метки и есть то самое явное решение, причём проверенное платформой:
 метки может ставить только тот, у кого есть право записи в репозиторий. Прежняя
@@ -903,10 +712,7 @@ Performance зелёные на точном SHA, плюс зелёный E2E н

 - **`commit-msg`** — есть, работает. Отклоняет коммит без терминального
  `Issue: #NN`, требует ровно один `User-Visible: yes|no`, а для коммитов,
-  трогающих `demo/golden/baselines/**`, — `Release:` плюс ровно один источник:
-  `Baseline-Reviewed: <URL GitHub run>` либо
-  `Baseline-Reviewed-Local: sha256:<хеш аттестации>`. Локальный хеш обязан
-  совпадать с `localAttestation.sha256` в принятом индексе.
+  трогающих `demo/golden/baselines/**`, — `Release:` плюс `Baseline-Reviewed:`.
  Реализация — `scripts/validate-commit-provenance.mjs`, тот же скрипт вызывается
  job `provenance` в `validate.yml`.
 - **`pre-push`** — есть, работает. Прогоняет `scripts/process-gate.mjs` по каждому
@@ -945,15 +751,12 @@ Performance зелёные на точном SHA, плюс зелёный E2E н

 1. трейлер `Issue: #NN` у каждого коммита класса A/B, допускается несколько;
 2. имя ветки `issue/NN-slug` соответствует трейлерам;
-3. у класса A есть ТЗ: раздел `## ТЗ` или хотя бы один `AC1` в теле issue —
-   либо архивный `docs/specs/NN-*.md` у задачи до 2026-09-10. Офлайн тела нет,
-   и проверка молчит; с `--issues` — предупреждение (настоящий рубеж — ревью ТЗ).
-   Добавление нового файла в `docs/specs/**` тоже предупреждение: каталог
-   заморожен (#517);
+3. для класса A существует `docs/specs/NN-*.md` — **или** issue помечен `small`.
+   Офлайн это предупреждение: лёгкий трек держит ТЗ в теле issue, и без чтения
+   меток «ТЗ в issue» неотличимо от «ТЗ не написано». С `--issues` — отказ;
 4. `User-Visible: yes` → правки в обоих changelog в том же коммите;
-5. коммит только класса D невалиден без `Release: vX.Y.Z`,
-   `Baseline-Reviewed: <ссылка на прогон CI>` либо
-   `Baseline-Reviewed-Local: sha256:<хеш аттестации>`;
+5. коммит только класса D невалиден без `Release: vX.Y.Z` либо
+   `Baseline-Reviewed: <ссылка на прогон CI>`;
 6. релизный коммит не содержит изменений в `src/` и `custom_components/**/*.py`;
 7. документов ревью на один issue не больше четырёх (`-r1`…`-r4`).

@@ -986,17 +789,10 @@ post-beta коммит остаётся в проверке и по закрыт
 Не реализовано и остаётся долгом:

 9. `npm run release:prerelease -- --issues=…` не проверяет, есть ли у issue
-   зелёный вердикт код-ревью.
-
-Закрытие вошедших issue автоматизировано (#120, #547). При старте беты текущая
-очередь S8 служит только списком кандидатов: `RELEASE-MEMBERSHIP.json` оставляет
-из неё лишь номера с доказанным `Issue: #NN` в Git-диапазоне зафиксированного
-SHA. Manifest публикуется и входит в `SHA256SUMS`; свежая очередь S8 после
-публикации не перечитывается. Общий для workflow и локальной команды bookkeeping
-идемпотентно добавляет один маркированный release-комментарий, снимает все
-статусные метки и закрывает issue. Поэтому повтор после сбоя продолжает manifest,
-даже если метка уже снята или release уже public; автор issue на membership не
-влияет.
+   зелёный вердикт код-ревью;
+10. закрытие issue и снятие статусных меток при публикации беты делаются руками —
+    `node process-labels/apply.mjs cleanup --apply`, а не `publish-prerelease.yml`.
+    Пропуск этого шага уже ломал инвариант «закрытый issue без статусной метки».

 ### 10.3 Страховка и разбор

@@ -1015,7 +811,7 @@ SHA. Manifest публикуется и входит в `SHA256SUMS`; свежа

 ### 10.4 Событийный конвейер: метка как триггер

-`.github/workflows/process.yml` (тело — `_process.yml`, #623), issue #114. Смена статусной метки — не запись в
+`.github/workflows/process.yml`, issue #114. Смена статусной метки — не запись в
 журнал, а **сообщение**: она порождает событие, событие запускает следующий шаг.

 ```
@@ -1023,113 +819,30 @@ S4-spec-review → ревью ТЗ  → S5-ready  либо возврат в S3-
 S7-code-review → код-ревью → слияние в dev → S8-merged либо возврат в S6-in-progress
 ```

-Текущая техническая реализация независимого ревьюера —
-`anthropics/claude-code-action`; это деталь автоматизации, а не закрепление роли
-или вида задач за Claude. Ревьюер читает `docs/SCOPE.md`, `AGENTS.md`,
-конспект `docs/process/REVIEWER.md` с разделами этого документа по его ссылкам
-(#634) и тело issue, публикует разбор комментарием, заводит issue на
-Medium-находки вне скоупа задачи (#202), кладёт документ в `docs/reviews/` ветки
-задачи и возвращает вердикт структурированным JSON. **Метку переставляет отдельная
-детерминированная стадия по вердикту, а не модель.**
+Ревьюер — `anthropics/claude-code-action`. Он читает `docs/SCOPE.md`, `AGENTS.md`,
+этот документ и тело issue, публикует разбор комментарием, заводит issue на Medium-находки
+вне скоупа задачи (#202), кладёт документ в `docs/reviews/` ветки задачи и возвращает вердикт
+структурированным JSON. **Метку переставляет отдельный детерминированный шаг по
+вердикту, а не модель.**

 Четыре вещи, без которых конвейер молча не работает:

 1. метки переставляет **PAT**, а не `GITHUB_TOKEN`: GitHub намеренно не порождает
   события от `GITHUB_TOKEN`, чтобы не было циклов, и цепочка обрывалась бы после
   первого шага без ошибок в логах;
-2. для события `issues` GitHub берёт workflow только из **ветки по умолчанию**
-   (`main`), независимо от содержимого `dev`. Поэтому в `main` лежит тонкий
-   `process.yml` — триггер, run-name, потолок прав, — а тело `_process.yml` он
-   вызывает по ссылке `@dev` (#623). Правило ниже, «Workflow из ветки по
-   умолчанию», — общее для всех таких файлов;
+2. `process.yml` обязан лежать в **ветке по умолчанию**: для события `issues`
+   GitHub берёт workflow только оттуда, независимо от содержимого `dev`;
 3. слияние в `dev` происходит **до** простановки `S8-merged`, иначе метка врёт в
   промежутке — она утверждает, что код в `dev`;
 4. многострочный текст внутри `run:` — только через heredoc: строка с нулевым
   отступом обрывает блок YAML, и скрипт обрезается без ошибки парсера.

-**Workflow из ветки по умолчанию: тонкий файл и тело из `dev`** (#623). Для
-событий `issues`, `schedule` и `workflow_run` GitHub исполняет workflow из
-`main`. Таких файлов шесть: `process.yml`, `process-resume.yml`,
-`process-reconcile.yml`, `mutation-gate.yml`, `nightly.yml`,
-`process-metrics.yml`. Каждый — тонкий вызывающий: триггеры, run-name,
-права, concurrency и одна job `uses:
-Matysh/houseplan-card/.github/workflows/_<имя>.yml@dev` с `secrets: inherit`.
-Тело `_<имя>.yml` читается из `dev` в момент запуска, поэтому **правка
-конвейера — один коммит в `dev`**, зеркало в `main` и возврат `main` в `dev`
-перед промоушеном не нужны. Потолок прав вызывающей job равен объединению
-прав job тела: вызываемый workflow права только сужает, и каждая job тела
-получает прежний минимум (#556). Тонкий файл меняется, только когда меняются
-триггеры, входы ручного запуска или потолок прав; тогда он зеркалится в
-`main`, и preflight `workflow_sync` в `validate.yml` держит копии равными —
-сверяются ровно эти шесть файлов, список держит
-`test/default-branch-workflows.test.mjs`. `performance.yml` в список не входит:
-по расписанию он судит `main` собственным телом из `main`.
-
-**Ревью не начинается на красном коде** (#510). После фиксации материала конвейер
-запускает Validate с мутантами по диффу на этом SHA (`scripts/validate-gate.mjs`:
-`workflow_dispatch validate.yml -f mutants=true`). **Ждёт его не раннер, а событие**
-(#636): подготовка убеждается, что dispatch встал на материал, кладёт запечатанный
-маркер ожидания `review-pending-…` и завершается; по завершении Validate
-`process-resume.yml` (`workflow_run`) переставляет метку `S7-code-review`, и новый
-прогон конвейера находит завершённый dispatch сразу. Страховка на потерянное
-событие — `process-reconcile.yml`: успешный прогон подготовки с маркером и уже
-завершённым Validate он будит повторной меткой, без маркера — как прежде, только
-диагностика. Будить без маркера нельзя: это второй вызов модели. Красный или
-пропавший прогон возвращает задачу в `S6-in-progress` с комментарием и ссылкой —
-код никто не читал, цикл ревью не израсходован. Мутанты по диффу вообще бегут
-только по явному запросу: на кандидате ревью, кандидате слияния (#492) — оба
-диспатчат Validate с `mutants=true` — и на PR, где Validate единственный сигнал;
-обычный push обходится дешёвыми гейтами (~3 минуты). За 08–09.09 мутанты на
-каждом промежуточном пуше стоили 48 из 56 часов job-минут Validate и в основном
-отменялись следующим пушем. **Кандидат беты (`Release:`), `full=true` и ночь
-мутантов не запрашивают** (#601, решение владельца 20.09): мутационный гейт
-проверяет тесты, а не продукт (#513), к бете каждая задача прогнана им дважды —
-на ревью и на слитом после ребейза кандидате, — а ночью идёт полный реестр
-(`mutation-gate.yml`, 00:43 UTC). Релизный гейт (#541) требует полного Validate,
-но не mutant-jobs; для ревью и слияния шесть исполненных mutant-jobs остаются
-обязательными.
-
-Ожидание gates, работа модели и публикация/интеграция — три независимых jobs
-(#551) с отдельными бюджетами 55, 45 и 55 минут. Поэтому долгий Validate не
-съедает время модели (с #636 — и не занимает раннер: до этого подготовка спала
-≈ 28 минут на раунд при 10–12 минутах работы модели), а ожидание кандидата после
-зелёного вердикта не обрывает готовый review. Между jobs передаётся запечатанный artifact: run/attempt, issue,
-этап, раунд, branch, SHA/tree материала, якоря ТЗ и результат Validate. Получатель
-сверяет полный набор файлов, SHA-256 и все поля с outputs предыдущей стадии;
-неполный, чужой или устаревший результат fail-closed не публикуется и не разрешает
-merge. Timeout/cancel/failure называет конкретную стадию и оставляет метку на месте;
-если модель не запускалась, цикл ревью не расходуется. Длительности всех трёх
-стадий печатаются отдельной таблицей в summary прогона.
-
-Каждый раунд ревью платит только за то, что в нём изменилось (#518). Свидетель
-судится по **области своего якоря** — строкам патча плюс сорок строк с каждой
-стороны (`ANCHOR_RADIUS_LINES`): и в отпечатке журнала (#481), и в отборе по
-диффу, который читает ханки `git diff --unified=0`. Сторона гарда осталась
-файловой: у гарда якоря нет. Неоднозначный якорь и непрочитанные ханки дают
-прежний широкий ответ — незнание не доказательство. Приближение того же класса,
-что и сам отбор по диффу; нижняя граница — ночной полный гейт (#513). Шард
-считает свой план до установки окружения и при пустом плане не платит за
-npm ci, Python и Chromium, оставаясь исполненной job: доказательство гейта
-требует успешной job, а не пропущенной.
-
-**Один хендофф — один пуш.** Перед пушем — локальный `node scripts/process-gate.mjs
--issues` при доступном `gh` (хук без `gh` статус issue не проверяет и молчит);
-после `S7-code-review` в ветку не пушить, пока не пришёл вердикт или возврат: пуш
-поверх идущего ревью отменяет его и стоит 10–20 минут раннера, а после фиксации
-материала — ещё и слияние (#312). `S7` ставится один раз на заход, не после
-каждого фикса CI: красный Validate конвейер вернёт сам.
-
 **Автор обязан дождаться вердикта, а не заканчивать сессию.** Ревью идёт от десяти
 минут до сорока пяти. Отчёт «передал на ревью» останавливает конвейер там, где он
 мог идти сам: вердикт придёт, а подхватить его будет некому. У агента нет часов —
 он существует только в момент своего хода, поэтому ожидание это опрос: раз в 90
-секунд, не более 110 попыток (запас на три независимых бюджета #551) —
-`node scripts/wait-verdict.mjs --issue NN` делает его
-детерминированно и говорит только при смене состояния (#496). Смотреть на метку, а
-не на комментарий: метка и есть состояние. Комментарии конвейера до последнего
-применения `S4`/`S7` считаются историческим baseline, а уже опубликованный исход
-текущего раунда доставляется сразу при первом опросе (#546). При `blocked` не
-ждать — задача ждёт владельца.
+секунд, не более 30 попыток. Смотреть на метку, а не на комментарий: метка и есть
+состояние. При `blocked` не ждать — задача ждёт владельца.

 **После прогона ревью метка меняется всегда.** Инвариант появился не сразу: первая
 редакция при конфликте слияния оставляла метку на месте, и это оказалось тупиком —
@@ -1148,7 +861,7 @@ npm ci, Python и Chromium, оставаясь исполненной job: до
 - ветка уже содержит весь `dev` — ничего;
 - отстала и ребейзится чисто — ребейз, `push --force-with-lease`, ревью по
  приведённому состоянию. Факт ребейза передаётся в промпт, чтобы сработало
-  правило §2.10 о полном разборе вместо дельты;
+  правило §7.2 о полном разборе вместо дельты;
 - конфликт — возврат в `S6-in-progress` **до** запуска ревью. Цикл при этом не
  расходуется: код никто не читал, вердикта нет.

@@ -1160,29 +873,6 @@ npm ci, Python и Chromium, оставаясь исполненной job: до
 ветки и пушем автор мог запушить коммит, и слепой `--force` потерял бы его молча.
 Расхождение lease — падение прогона, а не предупреждение.

-**В `dev` уезжает точный кандидат, и только проверенный** (#492,
-`scripts/merge-candidate.mjs`). Ревью длится десятки минут, `dev` за это время
-двигается; ребейз после вердикта даёт дерево, которого никто не видел, — а чистый
-ребейз ничего не доказывает: соседняя правка в `dev` меняет поведение без единого
-конфликта. Шаг слияния поэтому:
-
- сверяет вершину ветки с материалом ревью (#312) — иначе `S6-in-progress`;
- если `dev` не двигался — push с `--force-with-lease` на текущую вершину;
- если двигался — ребейз (конфликт — `S6-in-progress`, как раньше), сравнение
-  patch-id проверенного и получившегося диффа (различие — `S7-code-review`: вердикт
-  к другому диффу не применим, §2.10), публикация кандидата в ветку задачи, запуск
-  Validate с мутантами на ней (#510) и ожидание зелёного dispatch-прогона **на этом
-  SHA** — push-прогон мутантов не несёт — и только затем push в `dev` с lease на ту
-  вершину, поверх которой кандидат собран. Отклонённый lease — `dev` двинулся снова
-  — новая попытка; после третьей — `S6-in-progress` с комментарием;
- красный Validate на кандидате или прогон, не появившийся за три минуты, —
-  `S6-in-progress` с ссылкой; `S8-merged` ставится только после push.
-
-Проверка кандидата — обычный Validate ветки: лёгкий набор плюс диффозависимые
-гейты. Тяжёлые гейты остаются за кандидатом релиза (#479): слияние не превращает
-каждое движение `dev` в двадцатиминутный прогон, а проверяет ровно то, что
-проверил бы пуш той же дельты.
-
 Поэтому зелёное код-ревью с неудавшимся слиянием ведёт не в `S8-merged`, а в
 `S6-in-progress`: работа действительно вернулась к автору, только осталась не
 правка кода, а ребейз. Вердикт при этом в силе, переделывать нечего. После ребейза
@@ -1192,37 +882,6 @@ npm ci, Python и Chromium, оставаясь исполненной job: до
 Если метка не сменилась, значит упал сам прогон, а не работа: смотреть логи и
 сообщать владельцу, а не продолжать опрос.

-**Очередь S4/S7 сверяется отдельным bounded controller (#555).** Workflow
-`process-reconcile.yml` раз в полчаса делает один снимок открытых задач и
-завершается — активного polling одинакового состояния и вызова модели на каждый
-тик нет. Он сопоставляет последнюю постановку `S4`/`S7` с run по номеру задачи и
-этапу; если стадия успела подготовить материал, дополнительно проверяет
-запечатанные run/attempt, SHA/tree, список блобов ТЗ и номер раунда. Текущий
-`blocked`, `review-4` или снятая review-метка всегда сильнее старого события.
-
-Автоматически и не более одного раза повторно применяется только сама review-метка после доказанно
-потерянного события либо transient-исхода до получения запечатанного результата
-(`cancelled`, `timed_out`, `stale`, `startup_failure`, `skipped`). Это не применяет
-вердикт и не расходует цикл: обычный конвейер заново читает актуальные labels и
-материал. Здоровый running run не трогается. Failure guard, неизвестная связь,
-чужой material/stage/attempt, success без смены метки и сбой после появления
-`review-result`, а также потеря повторного события получают один дедуплицированный диагностический комментарий и
-эскалацию человеку — второй вызов модели или S8 по догадке запрещены. Перед любой
-записью controller перечитывает состояние; итог каждого прохода публикуется как
-`houseplan-process-reconcile/v1` artifact.
-
-**Конвейер — идемпотентный контроллер, а событие лишь будит его** (#499). Guard
-читает метки issue текущими, а не из снимка события: прогон мог простоять в очереди,
-пока владелец снял метку — отозванный запрос не исполняется, и комментария об этом
-нет. Конвейер запускают только `S4-spec-review` и `S7-code-review`; остальные метки
-не создают ни одной job и не входят в concurrency-группу issue — прежде любая
-посторонняя метка вытесняла ожидающий запуск ревью. Зелёный вердикт применяется
-повторно **без вызова модели**, если последний документ этапа несёт записанный
-конвейером вердикт `green` с High 0 и дерево материала не изменилось ни в одном
-файле вне `docs/reviews/**` (сравнивает `git diff` по содержимому). Ребейз, правка
-теста, фикстуры или ТЗ дают отличие дерева и полный разбор — правило §2.10 не
-ослабляется, оно просто не касается дерева, которое уже читали.
-
 Цикл считается **по этапу**: вердикт по ТЗ не расходует бюджет код-ревью. Раньше
 считались все вердикты подряд, и первое код-ревью #89 получило `r2/4`.

@@ -1241,7 +900,7 @@ npm ci, Python и Chromium, оставаясь исполненной job: до
 - issue создан в **той же сессии до коммита**, метка `hotfix`;
 - ТЗ «как сделано» + раздел «почему нельзя было ждать»;
 - в течение 24 часов задача ретроспективно проходит код-ревью;
- аварийность названа явно в релизном хендоффе.
+- аварийность названа явно в релизном хендоффе (действующее правило `AGENTS.md`).

 ### 11.3 Гигиена репозитория

@@ -1273,9 +932,7 @@ Golden, браузерные смоки, performance и полный HA-харн
 - трейлеры на коммите как обычно, `Issue: #NN` того же issue;
 - при `User-Visible: yes` — правки в оба changelog в том же коммите;
 - эталоны golden принимаются только через `npm run golden:accept -- --reviewed`
-  на полном Linux-артефакте GitHub CI либо полном аттестованном WSL-артефакте;
-  после локальной приёмки полный GitHub Validate на точном финальном SHA всё
-  равно обязателен. «Чтобы гейт позеленел» основанием не является.
+  на полном артефакте Linux CI. «Чтобы гейт позеленел» основанием не является.

 **Границы, за которыми исключение не действует.** Оно про починку названного
 гейтом дефекта, а не про продолжение разработки под видом починки. Правка идёт
@@ -1298,68 +955,6 @@ Golden, браузерные смоки, performance и полный HA-харн
 Это исключение из правила «код-ревью не пропускается никогда» (§5, §7.1) —
 единственное, и относится только к окну между `S8-merged` и выпуском.

-### 11.5 Независимое ревью линии перед стабильным релизом
-
-Решение владельца 2026-09-25, issue #638.
-
-**Зачем.** Инкрементальное ревью судит дифф задачи против её ТЗ, а не
-поверхность против пользователя. Пять раундов по эпику #591 не нашли того, что
-нашли четыре независимых ревью перед аудитом 22.09: невидимый после крестика HA
-диалог (#607), кламп по символу (#608), маршруты робота при импорте (#611),
-детерминированный отказ релизного гейта (#619). Ни ветка `ha-dialog`, ни
-посимвольный ввод не входили ни в один AC.
-
-**Шаг.** Перед каждым стабильным релизом — одно ревью поверхностей, изменённых
-всей линией бет, «с нуля»:
-
- **вход** — issue линии, доказанные трейлерами `Issue: #NN` в диапазоне
-  «прошлый стабильный тег..кандидат» (тот же построитель и та же схема, что
-  `RELEASE-MEMBERSHIP.json` беты, #547; метка S8 доказательством не является),
-  и изменённые продуктовые файлы. Собирает их
-  `scripts/release-review.mjs prepare`;
- **без ТЗ и без документов раундов**: основа суждения — `docs/SCOPE.md` и
-  `docs/USER-GUIDE.ru.md`. Проверка исполнением: бандл, стенд и смоки, пиннутая
-  фикстура `ha-dialog` (#505) там, где есть диалоги, посимвольный ввод,
-  настоящие Escape и крестик; для каждой поверхности — обычный сценарий и самый
-  рискованный соседний (§2.6, шесть классов риска);
- **выход** — `docs/reviews/RELEASE-REVIEW-vX.Y.Z.md` в `dev`, находки
-  High/Medium/Low с воспроизведением.
-
-**Исполнитель** — модель в CI, `.github/workflows/release-review.yml`: три job
-(вход, модель, публикация), модель без единого права на запись, документ, его
-машинный блок, индекс и коммит — детерминированный шаг. Независимость
-обеспечена построением: сессия свежая, ТЗ и раунды ей не даются.
-
-**Выпуск не блокирует.** `release.yml` ставит ревью в очередь job
-`independent-review` сразу после закрепления SHA кандидата — параллельно
-гейтам; ни один job выпуска от него не зависит, его отказ — предупреждение.
-Документ — рекомендация: владелец берёт находки в работу (issue в очередь
-следующей беты) либо оставляет без действий. Автоматически находки в issue
-не превращаются.
-
-Повторный запуск на тот же тег модель не тратит, если документ уже в `dev`
-(`force=true` — переснять). Ручной запуск:
-`gh workflow run release-review.yml --ref dev -f tag=vX.Y.Z [-f candidate=<sha>]`.
-Беты шаг пропускают. Первый прогон — линия v1.78.0.
-
-### 11.6 Повторные Validate на одном SHA перед релизом
-
-Решение владельца 2026-09-26, issue #656.
-
-Релизный гейт рассматривает прогоны одного SHA от нового к старому. Отменённый
-прогон и proof, который не соответствует запрошенной политике (например,
-лёгкий вместо полного), вердиктом не являются: гейт проходит мимо них к
-следующему совместимому proof. **Среди совместимых полных прогонов решает
-новейший.** Поэтому поздний полный `failed`, `missing` или `pending` блокирует
-более ранний зелёный proof; новый полный зелёный прогон может обновить старый
-красный.
-
-Это fail-closed правило. Content-addressed proof доказывает, что конкретный
-прогон относится к кандидату, но не даёт старому зелёному прогону права скрыть
-более позднюю проверку той же политики, которая нашла отказ. Чтобы продолжить
-выпуск после такого отказа, исправляют причину и получают новый совместимый
-полный зелёный прогон на том же финальном SHA либо на новом SHA кандидата.
-
 ---

 ## 12. Запрещено
@@ -1383,3 +978,64 @@ Golden, браузерные смоки, performance и полный HA-харн

 **Нарушение процесса — тоже issue** (метка `process`): если правило удалось
 нарушить незаметно, виновата проверка.
+
+---
+
+## 13. Внедрение
+
+Состояние на 2026-08-13.
+
+1. ✅ **Метки созданы, бэклог размечен.** У всех открытых issue владельца ровно
+   одна `S*`-метка, инварианты чистые.
+2. ⏳ **Колонку «Статус ТЗ» из `docs/specs/README.md` убрать** — не сделано, §7.3
+   п.1. Перенос старых документов ревью в `docs/reviews/` отменён: они описывают
+   код, которого уже нет.
+3. ✅ **Гейт написан** — `scripts/process-gate.mjs` плюс job в `validate.yml`,
+   issue #105. Прошёл **вне** флоу как инфраструктурная задача (§1, issue #118), а
+   не через ТЗ и ревью, как предполагала прежняя редакция этого пункта.
+4. ✅ **Долг ревью списан решением владельца.** Беты `beta.2`…`beta.10` сделаны по
+   прежнему процессу и не пересматриваются. Точка отсчёта — релиз 1.62.0; отсчёт
+   начинается с первой беты следующей линии.
+5. ⏳ Завести issue на находку «смок `visual_continuity` не умеет падать» — это
+   ровно тот класс дефектов, который в процессе без ручного тестирования стоит
+   дороже всего.
+6. ✅ `BACKLOG-2026-08-11.md` — разовый отчёт, решения живут в issue.
+7. ✅ `AGENTS.md` переписан целиком, шире блока §14.
+8. ✅ **Канон перенесён в репозиторий** (issue #112). До этого полный процесс жил
+   только в папке владельца, а в репозитории лежал файл на 51 строку про трейлеры
+   коммитов — из свежего клона канон не был виден вообще.
+9. ✅ **`pre-push` написан** (§10.1, issue #121). Блокирующая проверка на клиенте
+   есть; обойти её можно только `--no-verify`, и тогда то же найдёт CI.
+
+---
+
+## 14. Блок для AGENTS.md
+
+```markdown
+## Процесс: код только через issue
+
+Изменение продуктового кода без issue запрещено. Код меняется только из статуса
+«Готово к разработке» или дальше. Полные правила, критерии статусов и гейты —
+`docs/PROCESS.md`, читать до начала работы.
+
+Жизненный цикл (статус = метка issue): `S1-new` → `S2-analysis` → `S3-spec` →
+`S4-spec-review` → `S5-ready` → `S6-in-progress` → `S7-code-review` → `S8-merged`
+→ закрытие пачкой при выпуске беты. Оба ревью возвращают на правки не более 4
+циклов; пятый заход — разбор у владельца (разделить / отклонить / арбитраж).
+
+Ревью запускается **само** от меток `S4-spec-review` и `S7-code-review` и идёт до
+45 минут. Поставив такую метку, автор не заканчивает работу, а ждёт смены метки
+опросом и продолжает по тому, чем она стала.
+
+- ветка `issue/<NN>-<slug>`, коммиты с трейлерами `Issue: #NN` и `User-Visible: yes|no`;
+- работаем прямыми коммитами в `dev`, без PR: блокирующий гейт — локальный
+  `pre-push` (ставится автоматически через `npm ci`), CI — страховка. Force-push
+  в `dev` запрещён;
+- автор ≠ ревьюер, ни для ТЗ, ни для кода;
+- фазы ручного тестирования нет: автотесты пишутся в реализации, AC проверяет
+  код-ревью, найденные позже дефекты — новые issue типа «баг»;
+- мелкие задачи (метка `small`, сложность ≤3): ТЗ в теле issue, ревью ТЗ
+  комментарием, код-ревью — как обычно;
+- найденное вне скоупа — новый issue, а не попутная правка;
+- issue закрывает релиз-менеджер после выпуска беты, не исполнитель.
+```
@@ -12,9 +12,8 @@

 ## Your whole home at a glance

-House Plan turns Home Assistant into a live map of your home. Open the dedicated
-**House Plan** item in the Home Assistant sidebar, upload a plan or draw rooms,
-bind them to Home Assistant areas, and
+House Plan turns Home Assistant into a live map of your home. Upload a plan or
+draw rooms directly on the dashboard, bind them to Home Assistant areas, and
 the area's devices appear automatically. You can immediately see where a light
 is on, a door is open, a room is too cold, Zigbee signal is weak, or a leak
 sensor has fired.
@@ -42,9 +41,6 @@ sync across screens.
  show temperature, humidity, light state and average LQI.
 - **Light and environment.** Room fills, lamp Glow, wall shadows, a day-cycle
  backdrop and sunlight through windows.
- **Flat or 2.5D.** One switch in General settings › Display shows the plan
-  with depth everywhere: raised device tiles with soft floor shadows and a soft
-  wash of sunlight; decor and wall colours stay as you set them.
 - **Doors, windows, gates and vacuums.** Openings follow real contacts and locks;
  a robot can show its position, dock and travelled path.
 - **Several floors and screens.** Space tabs, swipe navigation, local viewport,
@@ -58,11 +54,11 @@ sync across screens.

 ## Your first working room

-1. Install the integration and open **House Plan** in the Home Assistant sidebar.
+1. Install the integration and add the card to a dashboard.
 2. Create the first **space**: upload SVG/PNG/JPG/WebP, reuse an uploaded image,
   or choose no image and draw the plan by hand.
-3. In Plan, select **Walls** and draw one continuous chain around the room: when
-   it closes an area, the room dialog opens.
+3. In Plan, select **Room outline**, place vertices, and click the first point to
+   close the outline.
 4. Name the room and bind it to a Home Assistant area. Use “No area” for a room
   that has no devices.
 5. Open Device: devices from the bound area are already placed; drag their
@@ -98,47 +94,17 @@ House Plan is in the HACS default catalog — no custom repository needed.
 2. Restart Home Assistant.
 3. Open **Settings → Devices & services → Add integration → House Plan**.

-The sidebar page and optional dashboard cards are registered automatically.
-After installing or updating House Plan,
-restart Home Assistant and fully reload the page: `Ctrl+F5` on Windows/Linux or
-`Cmd+Shift+R` on macOS.
-
-#### Storage mode (Home Assistant default)
-
-No YAML is normally needed. If automatic registration did not make the card
-available, open **Settings → Dashboards → menu ⋮ → Resources → Add
-resource**, enter `/houseplan_files/houseplan-card.js`, and select **JavaScript
-module**.
-
-#### YAML resources mode (Home Assistant 2026.2+)
-
-To manage resources in `configuration.yaml` independently of the dashboard
-mode, use:
+The card is registered automatically. If you manage Lovelace resources
+manually, use the URL served by the integration:

 ```yaml
-lovelace:
-  resource_mode: yaml
-  resources:
-    - url: /houseplan_files/houseplan-card.js
-      type: module
+resources:
+  - url: /houseplan_files/houseplan-card.js
+    type: module
 ```

-#### Legacy Home Assistant 2024.6–2026.1
-
-Only for a full-YAML dashboard that is already managed in YAML, use:
-
-```yaml
-lovelace:
-  mode: yaml
-  resources:
-    - url: /houseplan_files/houseplan-card.js
-      type: module
-```
-
-`mode: yaml` changes the dashboard itself to YAML mode. Do not switch a storage
-dashboard to legacy YAML just for House Plan; use the Storage mode instructions
-above instead. Do not use the on-disk path inside `custom_components`; Home
-Assistant does not serve that path as a JavaScript module.
+Do not use the on-disk path inside `custom_components`; Home Assistant does not
+serve that path as a JavaScript module.

 ### Manual installation

@@ -147,23 +113,9 @@ Copy the complete `custom_components/houseplan` release folder to
 integration. Do not copy only `houseplan-card.js`: the card also uses an
 internal manifest and content-hashed modules from the same release.

-### Open House Plan
+### Add the card

-After the integration is added, open **House Plan** in the Home Assistant
-sidebar. This full-page view is the primary entry point and needs no dashboard
-or YAML setup. It remembers the last space but always returns from another HA
-page in View rather than reopening an editor. Users without editing permission
-see the same live plan without editor controls.
-
-If the sidebar entry cannot be registered, the integration and existing
-dashboard cards continue to work; check **Settings → System → Repairs → System
-information → House Plan** after restarting and hard-refreshing HA.
-
-### Optional dashboard card
-
-Add the card only when House Plan must be embedded in a dashboard. In a Sections
-view it requests full width by default, while a manual size chosen in HA remains
-authoritative. Add it in the UI or as:
+Create a dashboard view (Panel works best) and add the card in the UI or as:

 ```yaml
 type: custom:houseplan-card
@@ -186,11 +138,8 @@ concurrent clients, but avoid editing the same object in two browsers at once.
 - [Full user guide](docs/USER-GUIDE.md)
 - [Mouse/touch/keyboard matrix](docs/USER-GUIDE.md#6-navigation-zoom-and-input)
 - [Plan tools](docs/USER-GUIDE.md#plan-tools-at-a-glance)
- [Stairs and floor links](docs/STAIRS.md)
 - [Background editor](docs/DECOR-EDITOR.md)
 - [Robot vacuums](docs/VACUUM.md)
- [Presence radars](docs/RADAR.md)
- [PDF export](docs/PDF-EXPORT.md)
 - [Touch support](docs/TOUCH-SUPPORT.md)

 <!-- docs-section: support -->
@@ -203,4 +152,9 @@ concurrent clients, but avoid editing the same object in two browsers at once.
  Include the version, browser, logs and reproduction steps; private entity IDs
  may be replaced with fictional ones.

+Documentation screenshots are produced by the reproducible
+`npm run build && node demo/docs/capture.mjs` command using synthetic data only. Scenario version,
+source fingerprint and every image hash are recorded in the
+[screenshot index](docs/images/screenshots.json).
+
 License: [MIT](LICENSE).
@@ -12,9 +12,8 @@

 ## Дом целиком — одним взглядом

-House Plan превращает Home Assistant в живую карту дома. Откройте отдельный
-пункт **House Plan** в боковом меню Home Assistant, загрузите изображение плана
-или нарисуйте комнаты, свяжите их с зонами Home
+House Plan превращает Home Assistant в живую карту дома. Загрузите изображение
+плана или нарисуйте комнаты прямо на дашборде, свяжите их с зонами Home
 Assistant — и устройства появятся на плане автоматически. Сразу видно, где
 горит свет, открыта дверь, слишком холодно, слабый Zigbee-сигнал или сработал
 датчик протечки.
@@ -43,9 +42,6 @@ Assistant — и устройства появятся на плане авто
  а карточки комнат показывают температуру, влажность, свет и средний LQI.
 - **Свет и окружение.** Заливки комнат, Glow от ламп, тени от стен, дневной фон и
  солнечные лучи из окон.
- **Плоский план или 2.5D.** Один переключатель в «Общие настройки ›
-  Отображение › Объёмный вид плана (2.5D)» показывает план с глубиной везде: приподнятые плитки устройств с мягкими
-  тенями и мягкая засветка солнцем; декор и цвета стен остаются вашими.
 - **Двери, окна, ворота и пылесосы.** Проёмы отражают реальные датчики и замки;
  робот показывает позицию, базу и пройденный путь.
 - **Несколько этажей и экранов.** Вкладки пространств, жесты переключения,
@@ -59,12 +55,11 @@ Assistant — и устройства появятся на плане авто

 ## Первая рабочая комната

-1. Установите интеграцию и откройте **House Plan** в боковом меню Home Assistant.
-2. Создайте первое **пространство**: загрузите SVG/PNG/JPG/WebP, возьмите уже
-   загруженное изображение либо выберите вариант без изображения, чтобы
-   нарисовать план вручную.
-3. В редакторе «План» выберите **Стены** и нарисуйте непрерывную цепочку по
-   периметру комнаты: когда она замкнёт область, откроется диалог комнаты.
+1. Установите интеграцию и добавьте карточку на дашборд.
+2. Создайте первое **пространство**: загрузите SVG/PNG/JPG/WebP либо выберите
+   вариант без изображения, чтобы нарисовать план вручную.
+3. В редакторе «План» выберите **Контур комнаты**, поставьте вершины и замкните
+   контур нажатием на первую точку.
 4. Назовите комнату и свяжите её с зоной Home Assistant. Для помещения без
   устройств выберите «Без зоны».
 5. Откройте «Устройства»: устройства связанной зоны уже размещены автоматически;
@@ -103,47 +98,17 @@ House Plan входит в основной каталог HACS — пользо
 2. Перезапустите Home Assistant.
 3. Откройте **Настройки → Устройства и службы → Добавить интеграцию → House Plan**.

-Страница в боковом меню и дополнительные карточки для дашборда регистрируются
-автоматически. После установки или обновления
-House Plan перезапустите Home Assistant и полностью перезагрузите
-страницу: `Ctrl+F5` в Windows/Linux или `Cmd+Shift+R` в macOS.
-
-#### Режим Storage (по умолчанию в Home Assistant)
-
-Обычно YAML не нужен. Если авторегистрация не сделала карточку доступной,
-откройте **Настройки → Панели управления → меню ⋮ → Ресурсы → Добавить
-ресурс**, укажите `/houseplan_files/houseplan-card.js` и выберите тип
-**JavaScript-модуль**.
-
-#### YAML-ресурсы в Home Assistant 2026.2+
-
-Чтобы управлять ресурсами в `configuration.yaml` независимо от режима
-самой панели, используйте:
+Карточка регистрируется автоматически. Если ресурсы Lovelace управляются вручную,
+добавьте именно URL, который публикует интеграция:

 ```yaml
-lovelace:
-  resource_mode: yaml
-  resources:
-    - url: /houseplan_files/houseplan-card.js
-      type: module
+resources:
+  - url: /houseplan_files/houseplan-card.js
+    type: module
 ```

-#### Home Assistant 2024.6–2026.1: устаревший режим
-
-Только для панели, которая уже полностью управляется через YAML:
-
-```yaml
-lovelace:
-  mode: yaml
-  resources:
-    - url: /houseplan_files/houseplan-card.js
-      type: module
-```
-
-`mode: yaml` переводит в YAML-режим саму панель. Не переключайте
-storage-панель в устаревший YAML только ради House Plan; используйте
-инструкцию для Storage выше. Не используйте путь к файлу внутри
-`custom_components`: Home Assistant не публикует его как JavaScript-модуль.
+Не используйте путь к файлу внутри `custom_components`: Home Assistant не
+публикует его как JavaScript-модуль.

 ### Вручную

@@ -152,23 +117,9 @@ storage-панель в устаревший YAML только ради House Pl
 House Plan. Одного `houseplan-card.js` недостаточно: карточке также нужны
 внутренний манифест и хешированные модули из того же релиза.

-### Открытие House Plan
+### Добавление карточки

-После добавления интеграции откройте **House Plan** в боковом меню Home
-Assistant. Это основной полноэкранный способ работы: отдельный дашборд и YAML
-не нужны. Запоминается последнее пространство, но после перехода на другую
-страницу HA панель всегда возвращается в режим просмотра, а не в редактор.
-Пользователь без права редактирования видит тот же живой план без редакторов.
-
-Если пункт бокового меню зарегистрировать не удалось, интеграция и уже
-добавленные карточки на дашбордах продолжают работать. После перезапуска и
-жёсткого обновления HA проверьте состояние House Plan в системной информации.
-
-### Необязательная карточка для дашборда
-
-Добавляйте карточку, только если план нужно встроить в дашборд. В представлении
-Sections она по умолчанию занимает всю ширину; вручную выбранный в HA размер
-остаётся главным. Добавьте карточку через UI либо:
+Создайте представление дашборда (лучше Panel) и добавьте карточку через UI либо:

 ```yaml
 type: custom:houseplan-card
@@ -192,11 +143,8 @@ default_floor: ground
 - [Полное руководство пользователя](docs/USER-GUIDE.ru.md)
 - [Матрица mouse/touch/keyboard](docs/USER-GUIDE.ru.md#6-навигация-масштаб-и-жесты)
 - [Инструменты плана](docs/USER-GUIDE.ru.md#инструменты-плана-в-короткой-таблице)
- [Лестницы и переходы между этажами](docs/STAIRS.md)
 - [Редактор подложки](docs/DECOR-EDITOR.md)
 - [Роботы-пылесосы](docs/VACUUM.md)
- [Радары присутствия](docs/RADAR.md)
- [Экспорт в PDF](docs/PDF-EXPORT.md)
 - [Поддержка touch](docs/TOUCH-SUPPORT.md)

 <!-- docs-section: support -->
@@ -209,4 +157,9 @@ default_floor: ground
  обновление страницы (`Ctrl+F5`). Приложите версию, браузер, логи и шаги
  воспроизведения; приватные entity ID можно заменить вымышленными.

+Скриншоты в документации получены воспроизводимой командой
+`npm run build && node demo/docs/capture.mjs` только на синтетических данных. Версия сценариев,
+fingerprint исходников и хеш каждого изображения находятся в
+[индексе снимков](docs/images/screenshots.json).
+
 Лицензия: [MIT](LICENSE).
@@ -1,59 +0,0 @@
-# Third-party notices
-
-## VMware Clarity Assets - `compass-line.svg`
-
-Source: <https://github.com/vmware-archive/clarity-assets/blob/bf6bdd0dd3f247f1a320d44d13fecdeda18c071c/icons/travel/compass-line.svg>
-
-Copyright (c) 2018 VMware, Inc.
-
-The MIT license (the "License") set forth below applies to all parts of the
-clarity-assets project. You may not use this file except in compliance with the
-License.
-
-MIT License
-
-Permission is hereby granted, free of charge, to any person obtaining a copy of
-this software and associated documentation files (the "Software"), to deal in
-the Software without restriction, including without limitation the rights to
-use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
-the Software, and to permit persons to whom the Software is furnished to do so,
-subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
-
-## Tabler Icons — summary panel outline icons
-
-Source: https://github.com/tabler/tabler-icons
-The settings, sidebar-right, eye, eye-off, plus and chevron paths were provided
-in the designer reference for #505 and are distributed as inline SVG paths.
-
-MIT License
-
-Copyright (c) 2020-2026 Paweł Kuna
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
-THE SOFTWARE.
@@ -1,201 +0,0 @@
-                                 Apache License
-                           Version 2.0, January 2004
-                        http://www.apache.org/licenses/
-
-   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
-
-   1. Definitions.
-
-      "License" shall mean the terms and conditions for use, reproduction,
-      and distribution as defined by Sections 1 through 9 of this document.
-
-      "Licensor" shall mean the copyright owner or entity authorized by
-      the copyright owner that is granting the License.
-
-      "Legal Entity" shall mean the union of the acting entity and all
-      other entities that control, are controlled by, or are under common
-      control with that entity. For the purposes of this definition,
-      "control" means (i) the power, direct or indirect, to cause the
-      direction or management of such entity, whether by contract or
-      otherwise, or (ii) ownership of fifty percent (50%) or more of the
-      outstanding shares, or (iii) beneficial ownership of such entity.
-
-      "You" (or "Your") shall mean an individual or Legal Entity
-      exercising permissions granted by this License.
-
-      "Source" form shall mean the preferred form for making modifications,
-      including but not limited to software source code, documentation
-      source, and configuration files.
-
-      "Object" form shall mean any form resulting from mechanical
-      transformation or translation of a Source form, including but
-      not limited to compiled object code, generated documentation,
-      and conversions to other media types.
-
-      "Work" shall mean the work of authorship, whether in Source or
-      Object form, made available under the License, as indicated by a
-      copyright notice that is included in or attached to the work
-      (an example is provided in the Appendix below).
-
-      "Derivative Works" shall mean any work, whether in Source or Object
-      form, that is based on (or derived from) the Work and for which the
-      editorial revisions, annotations, elaborations, or other modifications
-      represent, as a whole, an original work of authorship. For the purposes
-      of this License, Derivative Works shall not include works that remain
-      separable from, or merely link (or bind by name) to the interfaces of,
-      the Work and Derivative Works thereof.
-
-      "Contribution" shall mean any work of authorship, including
-      the original version of the Work and any modifications or additions
-      to that Work or Derivative Works thereof, that is intentionally
-      submitted to Licensor for inclusion in the Work by the copyright owner
-      or by an individual or Legal Entity authorized to submit on behalf of
-      the copyright owner. For the purposes of this definition, "submitted"
-      means any form of electronic, verbal, or written communication sent
-      to the Licensor or its representatives, including but not limited to
-      communication on electronic mailing lists, source code control systems,
-      and issue tracking systems that are managed by, or on behalf of, the
-      Licensor for the purpose of discussing and improving the Work, but
-      excluding communication that is conspicuously marked or otherwise
-      designated in writing by the copyright owner as "Not a Contribution."
-
-      "Contributor" shall mean Licensor and any individual or Legal Entity
-      on behalf of whom a Contribution has been received by Licensor and
-      subsequently incorporated within the Work.
-
-   2. Grant of Copyright License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      copyright license to reproduce, prepare Derivative Works of,
-      publicly display, publicly perform, sublicense, and distribute the
-      Work and such Derivative Works in Source or Object form.
-
-   3. Grant of Patent License. Subject to the terms and conditions of
-      this License, each Contributor hereby grants to You a perpetual,
-      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
-      (except as stated in this section) patent license to make, have made,
-      use, offer to sell, sell, import, and otherwise transfer the Work,
-      where such license applies only to those patent claims licensable
-      by such Contributor that are necessarily infringed by their
-      Contribution(s) alone or by combination of their Contribution(s)
-      with the Work to which such Contribution(s) was submitted. If You
-      institute patent litigation against any entity (including a
-      cross-claim or counterclaim in a lawsuit) alleging that the Work
-      or a Contribution incorporated within the Work constitutes direct
-      or contributory patent infringement, then any patent licenses
-      granted to You under this License for that Work shall terminate
-      as of the date such litigation is filed.
-
-   4. Redistribution. You may reproduce and distribute copies of the
-      Work or Derivative Works thereof in any medium, with or without
-      modifications, and in Source or Object form, provided that You
-      meet the following conditions:
-
-      (a) You must give any other recipients of the Work or
-          Derivative Works a copy of this License; and
-
-      (b) You must cause any modified files to carry prominent notices
-          stating that You changed the files; and
-
-      (c) You must retain, in the Source form of any Derivative Works
-          that You distribute, all copyright, patent, trademark, and
-          attribution notices from the Source form of the Work,
-          excluding those notices that do not pertain to any part of
-          the Derivative Works; and
-
-      (d) If the Work includes a "NOTICE" text file as part of its
-          distribution, then any Derivative Works that You distribute must
-          include a readable copy of the attribution notices contained
-          within such NOTICE file, excluding those notices that do not
-          pertain to any part of the Derivative Works, in at least one
-          of the following places: within a NOTICE text file distributed
-          as part of the Derivative Works; within the Source form or
-          documentation, if provided along with the Derivative Works; or,
-          within a display generated by the Derivative Works, if and
-          wherever such third-party notices normally appear. The contents
-          of the NOTICE file are for informational purposes only and
-          do not modify the License. You may add Your own attribution
-          notices within Derivative Works that You distribute, alongside
-          or as an addendum to the NOTICE text from the Work, provided
-          that such additional attribution notices cannot be construed
-          as modifying the License.
-
-      You may add Your own copyright statement to Your modifications and
-      may provide additional or different license terms and conditions
-      for use, reproduction, or distribution of Your modifications, or
-      for any such Derivative Works as a whole, provided Your use,
-      reproduction, and distribution of the Work otherwise complies with
-      the conditions stated in this License.
-
-   5. Submission of Contributions. Unless You explicitly state otherwise,
-      any Contribution intentionally submitted for inclusion in the Work
-      by You to the Licensor shall be under the terms and conditions of
-      this License, without any additional terms or conditions.
-      Notwithstanding the above, nothing herein shall supersede or modify
-      the terms of any separate license agreement you may have executed
-      with Licensor regarding such Contributions.
-
-   6. Trademarks. This License does not grant permission to use the trade
-      names, trademarks, service marks, or product names of the Licensor,
-      except as required for reasonable and customary use in describing the
-      origin of the Work and reproducing the content of the NOTICE file.
-
-   7. Disclaimer of Warranty. Unless required by applicable law or
-      agreed to in writing, Licensor provides the Work (and each
-      Contributor provides its Contributions) on an "AS IS" BASIS,
-      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-      implied, including, without limitation, any warranties or conditions
-      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
-      PARTICULAR PURPOSE. You are solely responsible for determining the
-      appropriateness of using or redistributing the Work and assume any
-      risks associated with Your exercise of permissions under this License.
-
-   8. Limitation of Liability. In no event and under no legal theory,
-      whether in tort (including negligence), contract, or otherwise,
-      unless required by applicable law (such as deliberate and grossly
-      negligent acts) or agreed to in writing, shall any Contributor be
-      liable to You for damages, including any direct, indirect, special,
-      incidental, or consequential damages of any character arising as a
-      result of this License or out of the use or inability to use the
-      Work (including but not limited to damages for loss of goodwill,
-      work stoppage, computer failure or malfunction, or any and all
-      other commercial damages or losses), even if such Contributor
-      has been advised of the possibility of such damages.
-
-   9. Accepting Warranty or Additional Liability. While redistributing
-      the Work or Derivative Works thereof, You may choose to offer,
-      and charge a fee for, acceptance of support, warranty, indemnity,
-      or other liability obligations and/or rights consistent with this
-      License. However, in accepting such obligations, You may act only
-      on Your own behalf and on Your sole responsibility, not on behalf
-      of any other Contributor, and only if You agree to indemnify,
-      defend, and hold each Contributor harmless for any liability
-      incurred by, or claims asserted against, such Contributor by reason
-      of your accepting any such warranty or additional liability.
-
-   END OF TERMS AND CONDITIONS
-
-   APPENDIX: How to apply the Apache License to your work.
-
-      To apply the Apache License to your work, attach the following
-      boilerplate notice, with the fields enclosed by brackets "[]"
-      replaced with your own identifying information. (Don't include
-      the brackets!)  The text should be enclosed in the appropriate
-      comment syntax for the file format. We also recommend that a
-      file or class name and description of purpose be included on the
-      same "printed page" as the copyright notice for easier
-      identification within third-party archives.
-
-   Copyright [yyyy] [name of copyright owner]
-
-   Licensed under the Apache License, Version 2.0 (the "License");
-   you may not use this file except in compliance with the License.
-   You may obtain a copy of the License at
-
-       http://www.apache.org/licenses/LICENSE-2.0
-
-   Unless required by applicable law or agreed to in writing, software
-   distributed under the License is distributed on an "AS IS" BASIS,
-   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-   See the License for the specific language governing permissions and
-   limitations under the License.
@@ -1,6 +1,6 @@
 MIT License

-Copyright (c) 2026 JB (justbusiness)
+Copyright (c) 2026 Sergey Matyunin (Matysh)

 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
@@ -0,0 +1,28 @@
+# House Plan furniture pack 0.3.0
+
+Canonical source artwork for the built-in House Plan furniture library.
+
+- `svg/menu/`: 33 front-view category illustrations used only by the lazy
+  editor bundle.
+- `svg/plan/`: 44 top-view drawings used on the plan.
+- `pack.json`: stable ids, category links, default dimensions and names. The
+  filename deliberately avoids the `*manifest.json` suffix reserved by HACS.
+
+The original author, Sergey Matyunin (`Matysh`), granted House Plan permission
+to use, modify and distribute all 77 SVG files under the repository MIT
+License without separate UI attribution in
+[issue #159](https://github.com/Matysh/houseplan-card/issues/159#issuecomment-5454085168).
+
+The reviewed source archive is `houseplan-furniture-custom-0.3.0.zip`, attached
+to [issue #159](https://github.com/Matysh/houseplan-card/issues/159#issuecomment-5449707137),
+with SHA-256
+`9E969016EE3B4B4E3DB776FEC53C8B387B91368B118EB5E39911483DEF1B0953`.
+
+The editable source is linked from `pack.json`. Generated TypeScript must
+not be edited by hand; run `npm run furniture:generate` after changing this
+directory.
+
+Note (#369): the source archive referenced by the SHA-256 above may still
+carry the earlier romanisation of the author's name; the authoritative
+spelling is Sergey Matyunin (Сергей Матюнин), fixed 2026-08-29 by the
+owner's decision in issue #369. The archive bytes are unchanged.
@@ -2,7 +2,7 @@
  "schema_version": 1,
  "view_schema": 2,
  "pack_id": "houseplan",
-  "pack_version": "0.4.0",
+  "pack_version": "0.3.0",
  "title_ru": "Набор мебели: меню и план",
  "title_en": "Furniture pack: menu and plan",
  "author": "Sergey Matyunin (Matysh)",
@@ -253,11 +253,11 @@
      "back": "top",
      "file": "svg/plan/coffee_table.svg",
      "menu_icon": "coffee_table",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Типовой размер; свободно стоящий предмет."
    },
    {
      "id": "coffee_table_round",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Журнальный стол, круглый",
      "name_en": "Round coffee table",
      "group": "furniture",
@@ -266,11 +266,11 @@
      "back": "top",
      "file": "svg/plan/coffee_table_round.svg",
      "menu_icon": "coffee_table",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Круглый свободно стоящий предмет."
    },
    {
      "id": "coffee_table_oval",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Журнальный стол, овальный",
      "name_en": "Oval coffee table",
      "group": "furniture",
@@ -279,11 +279,11 @@
      "back": "top",
      "file": "svg/plan/coffee_table_oval.svg",
      "menu_icon": "coffee_table",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Свободно стоящий предмет."
    },
    {
      "id": "coffee_table_rounded",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Журнальный стол, скруглённый",
      "name_en": "Rounded coffee table",
      "group": "furniture",
@@ -292,7 +292,7 @@
      "back": "top",
      "file": "svg/plan/coffee_table_rounded.svg",
      "menu_icon": "coffee_table",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Прямоугольная форма со скруглёнными углами."
    },
    {
      "id": "table_dining",
@@ -305,7 +305,7 @@
      "back": "top",
      "file": "svg/plan/table_dining.svg",
      "menu_icon": "dining_table",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Типовой стол на 4–6 мест."
    },
    {
      "id": "table_round",
@@ -318,11 +318,11 @@
      "back": "top",
      "file": "svg/plan/table_round.svg",
      "menu_icon": "dining_table",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Круглый стол на 4 места."
    },
    {
      "id": "table_dining_oval",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Обеденный стол, овальный",
      "name_en": "Oval dining table",
      "group": "furniture",
@@ -331,11 +331,11 @@
      "back": "top",
      "file": "svg/plan/table_dining_oval.svg",
      "menu_icon": "dining_table",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Овальный стол на 6 мест."
    },
    {
      "id": "table_dining_rounded",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Обеденный стол, скруглённый",
      "name_en": "Rounded dining table",
      "group": "furniture",
@@ -344,7 +344,7 @@
      "back": "top",
      "file": "svg/plan/table_dining_rounded.svg",
      "menu_icon": "dining_table",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Прямоугольная форма со скруглёнными углами."
    },
    {
      "id": "desk",
@@ -357,11 +357,11 @@
      "back": "top",
      "file": "svg/plan/desk.svg",
      "menu_icon": "work_table",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "BACK — длинная сторона у стены."
    },
    {
      "id": "desk_corner",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Рабочий стол, угловой",
      "name_en": "Corner desk",
      "group": "furniture",
@@ -370,7 +370,7 @@
      "back": "top",
      "file": "svg/plan/desk_corner.svg",
      "menu_icon": "work_table",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Угловой стол; основная задняя сторона направлена вверх."
    },
    {
      "id": "chair",
@@ -383,11 +383,11 @@
      "back": "top",
      "file": "svg/plan/chair.svg",
      "menu_icon": "chair",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Спинка находится сверху."
    },
    {
      "id": "chair_bar",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Барный стул",
      "name_en": "Bar stool",
      "group": "furniture",
@@ -396,7 +396,7 @@
      "back": "top",
      "file": "svg/plan/chair_bar.svg",
      "menu_icon": "chair",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Спинка находится сверху."
    },
    {
      "id": "armchair",
@@ -409,11 +409,11 @@
      "back": "top",
      "file": "svg/plan/armchair.svg",
      "menu_icon": "armchair",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Спинка находится сверху."
    },
    {
      "id": "armchair_office",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Кресло офисное",
      "name_en": "Office chair",
      "group": "furniture",
@@ -422,7 +422,7 @@
      "back": "top",
      "file": "svg/plan/armchair_office.svg",
      "menu_icon": "armchair",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Спинка находится сверху."
    },
    {
      "id": "sofa",
@@ -435,11 +435,11 @@
      "back": "top",
      "file": "svg/plan/sofa.svg",
      "menu_icon": "sofa",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Спинка находится сверху."
    },
    {
      "id": "sofa_three_seat",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Диван трёхместный",
      "name_en": "Three-seat sofa",
      "group": "furniture",
@@ -448,11 +448,11 @@
      "back": "top",
      "file": "svg/plan/sofa_three_seat.svg",
      "menu_icon": "sofa",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Спинка находится сверху."
    },
    {
      "id": "sofa_corner_right",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Угловой диван, правый",
      "name_en": "Right sectional sofa",
      "group": "furniture",
@@ -461,7 +461,7 @@
      "back": "top",
      "file": "svg/plan/sofa_corner_right.svg",
      "menu_icon": "sofa",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Шезлонг справа при взгляде сверху; спинка сверху."
    },
    {
      "id": "bed_single",
@@ -474,7 +474,7 @@
      "back": "top",
      "file": "svg/plan/bed_single.svg",
      "menu_icon": "bed",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Узкая кровать с одной подушкой; изголовье сверху."
    },
    {
      "id": "bed_double",
@@ -487,7 +487,7 @@
      "back": "top",
      "file": "svg/plan/bed_double.svg",
      "menu_icon": "bed",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Широкая кровать с двумя подушками; изголовье сверху."
    },
    {
      "id": "nightstand",
@@ -500,11 +500,11 @@
      "back": "top",
      "file": "svg/plan/nightstand.svg",
      "menu_icon": "nightstand",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя сторона сверху."
    },
    {
      "id": "cabinet_tv",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Тумба под телевизор",
      "name_en": "TV cabinet",
      "group": "furniture",
@@ -513,11 +513,11 @@
      "back": "top",
      "file": "svg/plan/cabinet_tv.svg",
      "menu_icon": "nightstand",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя длинная сторона сверху."
    },
    {
      "id": "cabinet_shoe",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Тумба для обуви",
      "name_en": "Shoe cabinet",
      "group": "furniture",
@@ -526,11 +526,11 @@
      "back": "top",
      "file": "svg/plan/cabinet_shoe.svg",
      "menu_icon": "nightstand",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя сторона сверху."
    },
    {
      "id": "cabinet_sink",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Тумба под раковину",
      "name_en": "Sink cabinet",
      "group": "furniture",
@@ -539,7 +539,7 @@
      "back": "top",
      "file": "svg/plan/cabinet_sink.svg",
      "menu_icon": "nightstand",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя сторона сверху."
    },
    {
      "id": "bookshelf",
@@ -552,11 +552,11 @@
      "back": "top",
      "file": "svg/plan/bookshelf.svg",
      "menu_icon": "wardrobe",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя длинная сторона сверху."
    },
    {
      "id": "wall_unit",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Шкаф-стенка",
      "name_en": "Wall unit",
      "group": "furniture",
@@ -565,7 +565,7 @@
      "back": "top",
      "file": "svg/plan/wall_unit.svg",
      "menu_icon": "wardrobe",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя длинная сторона сверху."
    },
    {
      "id": "wardrobe",
@@ -578,11 +578,11 @@
      "back": "top",
      "file": "svg/plan/wardrobe.svg",
      "menu_icon": "wardrobe",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя длинная сторона сверху."
    },
    {
      "id": "kitchen_floor",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Кухонный напольный модуль",
      "name_en": "Kitchen floor module",
      "group": "furniture",
@@ -591,11 +591,11 @@
      "back": "top",
      "file": "svg/plan/kitchen_floor.svg",
      "menu_icon": "kitchen_cabinet",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя сторона сверху."
    },
    {
      "id": "kitchen_floor_corner",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Кухонный напольный угловой модуль",
      "name_en": "Kitchen floor corner module",
      "group": "furniture",
@@ -604,11 +604,11 @@
      "back": "top",
      "file": "svg/plan/kitchen_floor_corner.svg",
      "menu_icon": "kitchen_cabinet",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Угловой модуль; основной BACK сверху."
    },
    {
      "id": "kitchen_wall",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Кухонный навесной модуль",
      "name_en": "Kitchen wall module",
      "group": "furniture",
@@ -617,11 +617,11 @@
      "back": "top",
      "file": "svg/plan/kitchen_wall.svg",
      "menu_icon": "kitchen_cabinet",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя сторона сверху."
    },
    {
      "id": "kitchen_wall_corner",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Кухонный навесной угловой модуль",
      "name_en": "Kitchen wall corner module",
      "group": "furniture",
@@ -630,11 +630,11 @@
      "back": "top",
      "file": "svg/plan/kitchen_wall_corner.svg",
      "menu_icon": "kitchen_cabinet",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Угловой модуль; основной BACK сверху."
    },
    {
      "id": "shelf_floor",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Стеллаж напольный",
      "name_en": "Floor shelving unit",
      "group": "furniture",
@@ -643,11 +643,11 @@
      "back": "top",
      "file": "svg/plan/shelf_floor.svg",
      "menu_icon": "shelving",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя длинная сторона сверху."
    },
    {
      "id": "shelf_wall",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Полка настенная",
      "name_en": "Wall shelf",
      "group": "furniture",
@@ -656,11 +656,11 @@
      "back": "top",
      "file": "svg/plan/shelf_wall.svg",
      "menu_icon": "shelving",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя длинная сторона сверху."
    },
    {
      "id": "cooktop_two",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Варочная панель, 2 конфорки",
      "name_en": "Two-burner cooktop",
      "group": "appliance",
@@ -669,7 +669,7 @@
      "back": "top",
      "file": "svg/plan/cooktop_two.svg",
      "menu_icon": "cooktop",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Панель ориентирована управляющей стороной вниз."
    },
    {
      "id": "stove",
@@ -682,7 +682,7 @@
      "back": "top",
      "file": "svg/plan/stove.svg",
      "menu_icon": "cooktop",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Панель ориентирована управляющей стороной вниз."
    },
    {
      "id": "tv",
@@ -695,11 +695,11 @@
      "back": "top",
      "file": "svg/plan/tv.svg",
      "menu_icon": "tv",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя сторона экрана сверху."
    },
    {
      "id": "tv_wall",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Телевизор на кронштейне",
      "name_en": "Wall-mounted TV",
      "group": "appliance",
@@ -708,7 +708,7 @@
      "back": "top",
      "file": "svg/plan/tv_wall.svg",
      "menu_icon": "tv",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Сторона крепления к стене сверху."
    },
    {
      "id": "toilet",
@@ -721,11 +721,11 @@
      "back": "top",
      "file": "svg/plan/toilet.svg",
      "menu_icon": "toilet",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Сторона подключения к стене сверху."
    },
    {
      "id": "toilet_built_in",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Унитаз встроенный",
      "name_en": "Built-in toilet",
      "group": "sanitary",
@@ -734,7 +734,7 @@
      "back": "top",
      "file": "svg/plan/toilet_built_in.svg",
      "menu_icon": "toilet",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Инсталляция находится сверху."
    },
    {
      "id": "bathtub",
@@ -747,11 +747,11 @@
      "back": "top",
      "file": "svg/plan/bathtub.svg",
      "menu_icon": "bathtub",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Длинная задняя сторона сверху."
    },
    {
      "id": "bathtub_corner",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Ванна угловая",
      "name_en": "Corner bathtub",
      "group": "sanitary",
@@ -760,7 +760,7 @@
      "back": "top",
      "file": "svg/plan/bathtub_corner.svg",
      "menu_icon": "bathtub",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Угловая ванна; основной BACK сверху."
    },
    {
      "id": "bidet",
@@ -773,11 +773,11 @@
      "back": "top",
      "file": "svg/plan/bidet.svg",
      "menu_icon": "bidet",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Сторона подключения к стене сверху."
    },
    {
      "id": "bidet_built_in",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Биде встроенное",
      "name_en": "Built-in bidet",
      "group": "sanitary",
@@ -786,7 +786,7 @@
      "back": "top",
      "file": "svg/plan/bidet_built_in.svg",
      "menu_icon": "bidet",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Инсталляция находится сверху."
    },
    {
      "id": "kitchen_sink",
@@ -799,11 +799,11 @@
      "back": "top",
      "file": "svg/plan/kitchen_sink.svg",
      "menu_icon": "kitchen_sink",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
+      "notes": "Задняя сторона столешницы сверху."
    },
    {
      "id": "kitchen_sink_double",
-      "operation": "replace",
+      "operation": "add",
      "name_ru": "Кухонная мойка двойная",
      "name_en": "Double kitchen sink",
      "group": "sanitary",
@@ -812,215 +812,7 @@
      "back": "top",
      "file": "svg/plan/kitchen_sink_double.svg",
      "menu_icon": "kitchen_sink",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "fridge",
-      "operation": "replace",
-      "name_ru": "Холодильник",
-      "name_en": "Refrigerator",
-      "group": "appliance",
-      "width_cm": 60,
-      "depth_cm": 65,
-      "back": "top",
-      "file": "svg/plan/fridge.svg",
-      "menu_icon": "fridge",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "dishwasher",
-      "operation": "replace",
-      "name_ru": "Посудомоечная машина",
-      "name_en": "Dishwasher",
-      "group": "appliance",
-      "width_cm": 60,
-      "depth_cm": 60,
-      "back": "top",
-      "file": "svg/plan/dishwasher.svg",
-      "menu_icon": "dishwasher",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "washer",
-      "operation": "replace",
-      "name_ru": "Стиральная машина",
-      "name_en": "Washing machine",
-      "group": "appliance",
-      "width_cm": 60,
-      "depth_cm": 60,
-      "back": "top",
-      "file": "svg/plan/washer.svg",
-      "menu_icon": "washer",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "dryer",
-      "operation": "replace",
-      "name_ru": "Сушильная машина",
-      "name_en": "Dryer",
-      "group": "appliance",
-      "width_cm": 60,
-      "depth_cm": 60,
-      "back": "top",
-      "file": "svg/plan/dryer.svg",
-      "menu_icon": "dryer",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "ac",
-      "operation": "replace",
-      "name_ru": "Кондиционер",
-      "name_en": "Air conditioner",
-      "group": "appliance",
-      "width_cm": 90,
-      "depth_cm": 25,
-      "back": "top",
-      "file": "svg/plan/ac.svg",
-      "menu_icon": "air_conditioner",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "water_heater",
-      "operation": "replace",
-      "name_ru": "Бойлер",
-      "name_en": "Water heater",
-      "group": "appliance",
-      "width_cm": 45,
-      "depth_cm": 45,
-      "back": "top",
-      "file": "svg/plan/water_heater.svg",
-      "menu_icon": "boiler",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "shower",
-      "operation": "replace",
-      "name_ru": "Душ",
-      "name_en": "Shower",
-      "group": "sanitary",
-      "width_cm": 90,
-      "depth_cm": 90,
-      "back": "top",
-      "file": "svg/plan/shower.svg",
-      "menu_icon": "shower",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "sink",
-      "operation": "replace",
-      "name_ru": "Раковина",
-      "name_en": "Sink",
-      "group": "sanitary",
-      "width_cm": 60,
-      "depth_cm": 45,
-      "back": "top",
-      "file": "svg/plan/sink.svg",
-      "menu_icon": "sink",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "stairs",
-      "operation": "replace",
-      "name_ru": "Лестница",
-      "name_en": "Stairs",
-      "group": "other",
-      "width_cm": 100,
-      "depth_cm": 280,
-      "back": "top",
-      "file": "svg/plan/stairs.svg",
-      "menu_icon": "stairs",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "fireplace",
-      "operation": "replace",
-      "name_ru": "Камин",
-      "name_en": "Fireplace",
-      "group": "other",
-      "width_cm": 120,
-      "depth_cm": 40,
-      "back": "top",
-      "file": "svg/plan/fireplace.svg",
-      "menu_icon": "fireplace",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "plant",
-      "operation": "replace",
-      "name_ru": "Растение",
-      "name_en": "Plant",
-      "group": "other",
-      "width_cm": 40,
-      "depth_cm": 40,
-      "back": "top",
-      "file": "svg/plan/plant.svg",
-      "menu_icon": "plant",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "rug",
-      "operation": "replace",
-      "name_ru": "Ковёр",
-      "name_en": "Rug",
-      "group": "other",
-      "width_cm": 200,
-      "depth_cm": 140,
-      "back": "top",
-      "file": "svg/plan/rug.svg",
-      "menu_icon": "rug",
-      "notes": "Существующий публичный ID House Plan; меняются только рисунок и default-размер нового размещения."
-    },
-    {
-      "id": "computer",
-      "operation": "add",
-      "name_ru": "Компьютер",
-      "name_en": "Computer",
-      "group": "appliance",
-      "width_cm": 120,
-      "depth_cm": 60,
-      "back": "top",
-      "file": "svg/plan/computer.svg",
-      "menu_icon": "computer",
-      "notes": "Новый ID для расширения встроенной библиотеки House Plan."
-    },
-    {
-      "id": "hood",
-      "operation": "add",
-      "name_ru": "Вытяжка",
-      "name_en": "Range hood",
-      "group": "appliance",
-      "width_cm": 60,
-      "depth_cm": 50,
-      "back": "top",
-      "file": "svg/plan/hood.svg",
-      "menu_icon": "hood",
-      "notes": "Новый ID для расширения встроенной библиотеки House Plan."
-    },
-    {
-      "id": "oven",
-      "operation": "add",
-      "name_ru": "Духовка",
-      "name_en": "Oven",
-      "group": "appliance",
-      "width_cm": 60,
-      "depth_cm": 60,
-      "back": "top",
-      "file": "svg/plan/oven.svg",
-      "menu_icon": "oven",
-      "notes": "Новый ID для расширения встроенной библиотеки House Plan."
-    },
-    {
-      "id": "cactus",
-      "operation": "add",
-      "name_ru": "Кактус",
-      "name_en": "Cactus",
-      "group": "other",
-      "width_cm": 70,
-      "depth_cm": 120,
-      "back": "top",
-      "file": "svg/plan/cactus.svg",
-      "menu_icon": "plant",
-      "notes": "Новый ID для расширения встроенной библиотеки House Plan."
+      "notes": "Задняя сторона столешницы сверху."
    }
  ]
 }
@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M20.5 39h69a2.5 2.5 0 0 1 2.5 2.5V69a2.5 2.5 0 0 1-2.5 2.5h-69A2.5 2.5 0 0 1 18 69V41.5a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M25 63a2.5 2.5 0 0 1 2.5-2.5h55A2.5 2.5 0 0 1 85 63v8.5H25z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M25 63a2.5 2.5 0 0 1 2.5-2.5h55A2.5 2.5 0 0 1 85 63v3.5H25z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <path d="M42.5 29h25a10 10 0 0 1 10 10v26.5a10 10 0 0 1-10 10h-25a10 10 0 0 1-10-10V39a10 10 0 0 1 10-10" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  <path d="M77.5 48.5a6 6 0 0 1 2 11.657V71.5a4 4 0 0 1-4 4H34a4 4 0 0 1-4-4V60.157A6.001 6.001 0 0 1 32 48.5a6 6 0 0 1 5.419 3.424A4 4 0 0 1 38 54v7h33.5v-6.5q0-.107.005-.213A6 6 0 0 1 77.5 48.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  <path d="M42.75 57h24.5A4.75 4.75 0 0 1 72 61.75a4.75 4.75 0 0 1-4.75 4.75h-24.5A4.75 4.75 0 0 1 38 61.75 4.75 4.75 0 0 1 42.75 57M36.5 75.5h8l-1.674 5.441A1.5 1.5 0 0 1 41.392 82H38a1.5 1.5 0 0 1-1.5-1.5zm36 0h-8l1.674 5.441A1.5 1.5 0 0 0 67.608 82H71a1.5 1.5 0 0 0 1.5-1.5z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M28 75h8l-1.674 5.441a1.5 1.5 0 0 1-1.434 1.059H29.5A1.5 1.5 0 0 1 28 80zm53 0h-8l1.674 5.441a1.5 1.5 0 0 0 1.434 1.059H79.5A1.5 1.5 0 0 0 81 80zM19.5 46.5H90a2.5 2.5 0 0 1 2.5 2.5 2.5 2.5 0 0 1-2.5 2.5H19.5A2.5 2.5 0 0 1 17 49a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M19.5 51.5H90L86.633 68a10 10 0 0 1-9.798 8h-44.17a10 10 0 0 1-9.798-8zM30 36v-2a5 5 0 1 0-10 0v12.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M16 75.5h8l-1.674 5.441A1.5 1.5 0 0 1 20.892 82H17.5a1.5 1.5 0 0 1-1.5-1.5zm78.5 0h-8l1.674 5.441A1.5 1.5 0 0 0 89.608 82H93a1.5 1.5 0 0 0 1.5-1.5zM25 29h60.5a2.5 2.5 0 0 1 2.5 2.5V68a2.5 2.5 0 0 1-2.5 2.5H25a2.5 2.5 0 0 1-2.5-2.5V31.5A2.5 2.5 0 0 1 25 29" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M16 59.5c0-5.523 4.477-10 10-10h58.5c5.523 0 10 4.477 10 10v6H16zm-1 6h80.5a1 1 0 0 1 1 1v8a1 1 0 0 1-1 1H15a1 1 0 0 1-1-1v-8a1 1 0 0 1 1-1m15.5-20a5 5 0 0 1 5-5h11a5 5 0 0 1 5 5v4h-21zm28.5 0a5 5 0 0 1 5-5h11a5 5 0 0 1 5 5v4H59z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <path d="M36 57.5c0 5.523 4.477 10 10 10h18.5c5.523 0 10-4.477 10-10V53H36zm8.5 22a1 1 0 0 0 1 1H65a1 1 0 0 0 1-1v-12H44.5zm-8.5-32a1 1 0 0 1 1-1h36.5a1 1 0 0 1 1 1V53H36zM50.5 41a1 1 0 0 1 1-1H59a1 1 0 0 1 1 1v5.5h-9.5zM53 30a1 1 0 0 1 1-1h2.5a1 1 0 0 1 1 1v10H53zm-4 6a1 1 0 0 1-1-1v-2.5a1 1 0 0 1 1-1h4V36z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M46.5 81.5h5V86a1 1 0 0 1-1 1h-3a1 1 0 0 1-1-1zm12.5 0h5V86a1 1 0 0 1-1 1h-3a1 1 0 0 1-1-1zM44 23h22.5a8 8 0 0 1 8 8v42.5a8 8 0 0 1-8 8H44a8 8 0 0 1-8-8V31a8 8 0 0 1 8-8" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M36 31a8 8 0 0 1 8-8h22.5a8 8 0 0 1 8 8v42H36z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M48.5 42.5a7 7 0 1 0 14 0 7 7 0 1 0-14 0m6.5 0 3.5-3.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M40.5 39.5C40.5 32.596 46.096 27 53 27h4c6.904 0 12.5 5.596 12.5 12.5v13a5 5 0 0 1-5 5h-19a5 5 0 0 1-5-5z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M41.25 54h27.5A3.25 3.25 0 0 1 72 57.25a3.25 3.25 0 0 1-3.25 3.25h-27.5A3.25 3.25 0 0 1 38 57.25 3.25 3.25 0 0 1 41.25 54m28.25 6.5H64l1.88 21.63a1.5 1.5 0 0 0 1.495 1.37H68a1.5 1.5 0 0 0 1.5-1.5zm-29 0H46l-1.88 21.63a1.5 1.5 0 0 1-1.495 1.37H42a1.5 1.5 0 0 1-1.5-1.5z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M25 51h5.238l-1.534 15.646A1.5 1.5 0 0 1 27.211 68H26.5a1.5 1.5 0 0 1-1.5-1.5zm60.238 0H80l1.534 15.646A1.5 1.5 0 0 0 83.027 68h.711a1.5 1.5 0 0 0 1.5-1.5z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M24.34 43.485A2.5 2.5 0 0 1 26.625 42h56.75a2.5 2.5 0 0 1 2.285 1.485l2.715 6.109A1 1 0 0 1 87.461 51H22.54a1 1 0 0 1-.914-1.406z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M87.5 51h-66v3a1 1 0 0 0 1 1h64a1 1 0 0 0 1-1z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <path d="M24.5 38h40a2.5 2.5 0 0 1 2.5 2.5v22a2.5 2.5 0 0 1-2.5 2.5h-40a2.5 2.5 0 0 1-2.5-2.5v-22a2.5 2.5 0 0 1 2.5-2.5m50 0h11a2.5 2.5 0 0 1 2.5 2.5v29a2.5 2.5 0 0 1-2.5 2.5h-11a2.5 2.5 0 0 1-2.5-2.5v-29a2.5 2.5 0 0 1 2.5-2.5M43 65h5v7h-5zm-6 7h16m23-12h8m-8-17h8" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  <path d="M35 56V46h5m-5 7h5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  <path d="M39.5 53a3.5 3.5 0 1 0 0-7m15.036 8.536a5 5 0 1 1 0-7.071" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M27.5 29h55a2.5 2.5 0 0 1 2.5 2.5v47a2.5 2.5 0 0 1-2.5 2.5h-55a2.5 2.5 0 0 1-2.5-2.5v-47a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M33.5 66.5a8 8 0 1 0 16 0 8 8 0 1 0-16 0m26.5-23a8 8 0 1 0 16 0 8 8 0 1 0-16 0m3 23a5 5 0 1 0 10 0 5 5 0 1 0-10 0m-29.5-23a8 8 0 1 0 16 0 8 8 0 1 0-16 0" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M83.5 43H78l6.742 30.82A1.5 1.5 0 0 0 86.207 75h.54a1.5 1.5 0 0 0 1.482-1.732zm-56 0H33l-6.742 30.82A1.5 1.5 0 0 1 24.793 75h-.54a1.5 1.5 0 0 1-1.482-1.732zm-2.62-7.406A2.5 2.5 0 0 1 27.21 34h56.58a2.5 2.5 0 0 1 2.33 1.594l2.35 6.044A1 1 0 0 1 87.538 43H23.462a1 1 0 0 1-.932-1.362z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M88.5 43h-66v3a1 1 0 0 0 1 1h64a1 1 0 0 0 1-1z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M31.5 25h47a2.5 2.5 0 0 1 2.5 2.5v55a2.5 2.5 0 0 1-2.5 2.5h-47a2.5 2.5 0 0 1-2.5-2.5v-55a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M31.5 37.5h47A2.5 2.5 0 0 1 81 40v36a2.5 2.5 0 0 1-2.5 2.5h-47A2.5 2.5 0 0 1 29 76V40a2.5 2.5 0 0 1 2.5-2.5M43 42h24m-1.5-11a2 2 0 1 0 4 0 2 2 0 1 0-4 0m7.5 0a2 2 0 1 0 4 0 2 2 0 1 0-4 0m-37.25 0h9.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,9 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M31.5 25h47a2.5 2.5 0 0 1 2.5 2.5v55a2.5 2.5 0 0 1-2.5 2.5h-47a2.5 2.5 0 0 1-2.5-2.5v-55a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M31.5 37.5h47A2.5 2.5 0 0 1 81 40v42.5a2.5 2.5 0 0 1-2.5 2.5h-47a2.5 2.5 0 0 1-2.5-2.5V40a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M38 60.5a17 17 0 1 0 34 0 17 17 0 1 0-34 0" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M43.5 60.5a11.5 11.5 0 1 0 23 0 11.5 11.5 0 1 0-23 0m22-29.5a2 2 0 1 0 4 0 2 2 0 1 0-4 0m7.5 0a2 2 0 1 0 4 0 2 2 0 1 0-4 0m-37.25 0h9.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M55.994 55.5s-1.329 1.81-1.479 3.143c-.198 1.761 1.599 2.554 1.48 4.321-.1 1.479-1.48 3.536-1.48 3.536m5.979-11s-1.329 1.81-1.479 3.143c-.198 1.761 1.599 2.554 1.48 4.321-.1 1.479-1.48 3.536-1.48 3.536m-8.519-11s-.886 1.81-.986 3.143c-.132 1.761 1.066 2.554.986 4.321-.067 1.479-.986 3.536-.986 3.536" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="m60.752 62.03-5.379-2.312 11.066-25.75a1.5 1.5 0 0 1 1.97-.786l2.624 1.127a1.5 1.5 0 0 1 .786 1.97zm-18.648-4.512-4.353 1.189-4.474-16.382a1.5 1.5 0 0 1 1.052-1.842l1.459-.398a1.5 1.5 0 0 1 1.842 1.052z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M41.297 38.173a2.215 2.215 0 0 1 0 4.43H29.781a2.215 2.215 0 0 1 0-4.43zm33.219 38.091a2.657 2.657 0 1 1 0 5.315H28.453a2.657 2.657 0 1 1 0-5.315zm8.641-51.366a1.795 1.795 0 0 1 .68 2.41l-3.03 5.59a5 5 0 0 1-4.396 2.618H65.657a1.772 1.772 0 1 1 0-3.544h9.61a3 3 0 0 0 2.598-1.5l2.84-4.917a1.795 1.795 0 0 1 2.452-.657M29.339 65.787c0-6.699 6.457-11.503 12.873-9.579l24.291 7.288a10 10 0 0 1 7.127 9.578v3.19H29.339zm0 15.852h7.086l-1.394 3.486a1.5 1.5 0 0 1-1.393.943h-2.8a1.5 1.5 0 0 1-1.5-1.5zm44.291 0h-7.087l1.395 3.486a1.5 1.5 0 0 0 1.392.943h2.8a1.5 1.5 0 0 0 1.5-1.5z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M35.54 66.077a4.872 4.872 0 1 0 9.743 0 4.872 4.872 0 1 0-9.744 0" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M26.672 34.425h55.99v39.47h-55.99Z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M23 74.894a1 1 0 0 1 1-1h61.334a1 1 0 0 1 1 1v5.802a1 1 0 0 1-1 1H24a1 1 0 0 1-1-1zM23 29a1 1 0 0 1 1-1h61.334a1 1 0 0 1 1 1v4.425a1 1 0 0 1-1 1H24a1 1 0 0 1-1-1zm15.145 21.44a5 5 0 0 1 5-5h23.043a5 5 0 0 1 5 5v23.454H38.145z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M44.57 65.633a2.754 2.754 0 0 1 2.754-2.753H62.01v5.507H47.324a2.754 2.754 0 0 1-2.754-2.754m20.194 5.507a2.754 2.754 0 0 0-2.754-2.753H47.324v5.507H62.01a2.754 2.754 0 0 0 2.754-2.754" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M44.57 71.14a2.754 2.754 0 1 0 5.508 0 2.754 2.754 0 1 0-5.508 0m14.688-5.507a2.754 2.754 0 1 0 5.507 0 2.754 2.754 0 1 0-5.507 0" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M35.5 18H75a2.5 2.5 0 0 1 2.5 2.5v64A2.5 2.5 0 0 1 75 87H35.5a2.5 2.5 0 0 1-2.5-2.5v-64a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M33 46.5h44.5v38A2.5 2.5 0 0 1 75 87H35.5a2.5 2.5 0 0 1-2.5-2.5zm2.5 44a1 1 0 0 0 1 1h37a1 1 0 0 0 1-1V87h-39zm3-49.5v-9.5m0 30.5v-9.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <path d="M44.308 57h21.384L83 69H27zM44 37.5a2.5 2.5 0 0 1 2.5-2.5h17a2.5 2.5 0 0 1 2.5 2.5V57H44zM80.5 74h-51a2.5 2.5 0 0 1-2.5-2.5V70a1 1 0 0 1 1-1h54a1 1 0 0 1 1 1v1.5a2.5 2.5 0 0 1-2.5 2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <path d="M38 88a1 1 0 0 0 1 1h32a1 1 0 0 0 1-1v-3H38zm17-68h16.5a2.5 2.5 0 0 1 2.5 2.5v17a2.5 2.5 0 0 1-2.5 2.5H55zm-19 2.5a2.5 2.5 0 0 1 2.5-2.5H55v22H38.5a2.5 2.5 0 0 1-2.5-2.5zM59 33v5m-8-5v5m4 47h16.5a2.5 2.5 0 0 0 2.5-2.5v-17a2.5 2.5 0 0 0-2.5-2.5H55zm-19-2.5a2.5 2.5 0 0 0 2.5 2.5H55V63H38.5a2.5 2.5 0 0 0-2.5 2.5zM67 67h-5m-14 0h-5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M21.5 84h68a2.5 2.5 0 0 0 2.5-2.5v-35a2.5 2.5 0 0 0-2.5-2.5h-68a2.5 2.5 0 0 0-2.5 2.5v35a2.5 2.5 0 0 0 2.5 2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M26 78h26.5a1 1 0 0 0 1-1V51a1 1 0 0 0-1-1H26a1 1 0 0 0-1 1v26a1 1 0 0 0 1 1m23-24v5m9.5 19H85a1 1 0 0 0 1-1V51a1 1 0 0 0-1-1H58.5a1 1 0 0 0-1 1v26a1 1 0 0 0 1 1m-6-39.5a1 1 0 0 0-1-1H44a1 1 0 0 0-1 1V44h9.5zM58 33v-2a5 5 0 1 0-10 0v6.5M62 54v5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M76.5 73.5h-8l1.674 5.441A1.5 1.5 0 0 0 71.608 80H75a1.5 1.5 0 0 0 1.5-1.5zm-42.5 0h8l-1.674 5.441A1.5 1.5 0 0 1 38.892 80H35.5a1.5 1.5 0 0 1-1.5-1.5z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M34.5 30.5h41A2.5 2.5 0 0 1 78 33v40.5a2.5 2.5 0 0 1-2.5 2.5h-41a2.5 2.5 0 0 1-2.5-2.5V33a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M32 39.5h46v18H32Zm18.5 9H60M50.5 66H60" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M31.5 25h47a2.5 2.5 0 0 1 2.5 2.5v55a2.5 2.5 0 0 1-2.5 2.5h-47a2.5 2.5 0 0 1-2.5-2.5v-55a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M31.5 37.5h47A2.5 2.5 0 0 1 81 40v36a2.5 2.5 0 0 1-2.5 2.5h-47A2.5 2.5 0 0 1 29 76V40a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M40.5 47h29a2.5 2.5 0 0 1 2.5 2.5v20a2.5 2.5 0 0 1-2.5 2.5h-29a2.5 2.5 0 0 1-2.5-2.5v-20a2.5 2.5 0 0 1 2.5-2.5m25-16a2 2 0 1 0 4 0 2 2 0 1 0-4 0m7.5 0a2 2 0 1 0 4 0 2 2 0 1 0-4 0m-37.25 0h9.5M43 42h24" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M45.952 75.849a2.5 2.5 0 0 0 2.485 2.231H63.43a2.5 2.5 0 0 0 2.485-2.231l1.571-14.532H44.381zM60.236 44.78C58.423 36.174 66.805 29.605 77 31.87c0 8.155-8.609 16.763-16.763 12.912m-9.761 5.147c1.517-8.665-7.085-14.943-17.195-12.33.28 8.15 9.178 16.458 17.195 12.33" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M55.706 55.88v-2.944m0 0c1.133-5.89 7.09-10.956 12.912-15.404M55.706 52.936c-4.938-4.146-7.982-6.16-14.044-9.061m1.453 12.005h25.636a1 1 0 0 1 1 1v3.437a1 1 0 0 1-1 1H43.115a1 1 0 0 1-1-1v-3.436a1 1 0 0 1 1-1" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M90.27 33.874h-5.622m-59.028 0H20m70.27 5.152h-5.622m-59.028 0H20m70.27 5.154h-5.622m-59.028 0H20m70.27 5.152h-5.622m-59.028 0H20m70.27 5.153h-5.622m-59.028 0H20m70.27 5.153h-5.622m-59.028 0H20m70.27 5.153h-5.622m-59.028 0H20m70.27 5.153h-5.622m-59.028 0H20m70.27 5.153h-5.622m-59.028 0H20M28.12 32h54.025a2.5 2.5 0 0 1 2.5 2.5v40.439a2.5 2.5 0 0 1-2.5 2.5H28.12a2.5 2.5 0 0 1-2.5-2.5V34.5a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M25.62 34.5a2.5 2.5 0 0 1 2.5-2.5h1.717v45.439H28.12a2.5 2.5 0 0 1-2.5-2.5zm59.026 0a2.5 2.5 0 0 0-2.5-2.5H80.43v45.439h1.716a2.5 2.5 0 0 0 2.5-2.5zM37.8 54.485l17.801-8.432 17.801 8.432-17.8 8.432z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M28 58.5h53V39H28Z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M64 58.5h5V47a1 1 0 0 0-1-1h-3a1 1 0 0 0-1 1zM52.5 39h-5V27.5a1 1 0 0 1 1-1h3a1 1 0 0 1 1 1zm-12 0h-5V27.5a1 1 0 0 1 1-1h3a1 1 0 0 1 1 1zm-5 29.5V71a1 1 0 0 1 1 1H49a1 1 0 0 1 1-1v-2.5a1 1 0 0 1-1-1H36.5a1 1 0 0 1-1 1m33.5-10h7v-14a1 1 0 0 0-1-1h-5a1 1 0 0 0-1 1zM47.5 39h-7V25a1 1 0 0 1 1-1h5a1 1 0 0 1 1 1zm-12 34v4a1 1 0 0 1 1 1h14a1 1 0 0 1 1-1v-4a1 1 0 0 1-1-1h-14a1 1 0 0 1-1 1M28 78h53v7H28Z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M28 89.5V23a2.5 2.5 0 0 1 2.5-2.5h48A2.5 2.5 0 0 1 81 23v66.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M31 84h49a1 1 0 0 1 1 1v3a1 1 0 0 1-1 1H31a1 1 0 0 1-1-1v-3a1 1 0 0 1 1-1m31.5-47.6v-4.686a11.7 11.7 0 0 0-3.441-8.283A11.77 11.77 0 0 0 50.75 20a11.77 11.77 0 0 0-8.309 3.431A11.7 11.7 0 0 0 39 31.714V84" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M72 39.25a10.25 10.25 0 1 0-20.5 0zm-17.25 5v2.5m7.25-2.5v2.5m7.25-2.5v2.5m-14.5 3.75V53M62 50.5V53m7.25-2.5V53m-14.5 3.75v2.5m7.25-2.5v2.5m7.25-2.5v2.5M54.75 63v2.5M62 63v2.5m7.25-2.5v2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <path d="M30 57c0 5.523 4.477 10 10 10h29.5c5.523 0 10-4.477 10-10v-6.5A2.5 2.5 0 0 0 77 48H32.5a2.5 2.5 0 0 0-2.5 2.5zm14 22a1 1 0 0 0 1 1h19.5a1 1 0 0 0 1-1V67H44zm6-36.5a1 1 0 0 1 1-1h7.5a1 1 0 0 1 1 1V48H50zM45 37v-2a5 5 0 1 1 10 0v6.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,5 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <path d="M59.5 29h24a5 5 0 0 1 5 5v32a5 5 0 0 1-5 5h-24a5 5 0 0 1-5-5V34a5 5 0 0 1 5-5m-34 0h24a5 5 0 0 1 5 5v32a5 5 0 0 1-5 5h-24a5 5 0 0 1-5-5V34a5 5 0 0 1 5-5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  <path d="M18.5 44a5 5 0 0 1 5 5v12H86V49a5 5 0 0 1 5-5h.5a5 5 0 0 1 5 5v21.5a5 5 0 0 1-5 5H18a5 5 0 0 1-5-5V49a5 5 0 0 1 5-5z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  <path d="M25.25 57h24.5a4.75 4.75 0 0 1 4.75 4.75 4.75 4.75 0 0 1-4.75 4.75h-24.5a4.75 4.75 0 0 1-4.75-4.75A4.75 4.75 0 0 1 25.25 57m34 0h24.5a4.75 4.75 0 0 1 4.75 4.75 4.75 4.75 0 0 1-4.75 4.75h-24.5a4.75 4.75 0 0 1-4.75-4.75A4.75 4.75 0 0 1 59.25 57M18.5 75.5h8l-1.674 5.441A1.5 1.5 0 0 1 23.392 82H20a1.5 1.5 0 0 1-1.5-1.5zm72 0h-8l1.674 5.441A1.5 1.5 0 0 0 85.608 82H89a1.5 1.5 0 0 0 1.5-1.5z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,9 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M73.47 46.365v-17.62m-10.571 25.55V36.674M52.326 61.783V45.484M42.193 69.273v-15.86M28.979 77.761a1 1 0 0 1 1-1h53.624v6.489a1 1 0 0 1-1 1H29.98a1 1 0 0 1-1-1z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M26.777 57.497a1 1 0 0 1 1-1h2.846a1 1 0 0 1 1 1V83.25a1 1 0 0 1-1 1h-2.846a1 1 0 0 1-1-1z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="m73.113 28.633-41.492 32.93v-4.405l39.9-32.007a.7.7 0 0 1 .428-.151h3.724a1.762 1.762 0 1 1 0 3.524h-2.248a.5.5 0 0 0-.312.109M25.895 53.414a3.084 3.084 0 1 0 6.167 0 3.084 3.084 0 1 0-6.167 0m14.978 16.859a1 1 0 0 1 1-1h41.73v7.488h-42.73zm10.131-7.489a1 1 0 0 1 1-1h31.598v7.488H51.004z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M61.576 55.294a1 1 0 0 1 1-1h21.026v7.49H61.576z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M72.15 47.806a1 1 0 0 1 1-1h9.454a1 1 0 0 1 1 1v6.489H72.15z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <path d="M32 26.5a2.5 2.5 0 0 1 2.5-2.5H45a2.5 2.5 0 0 1 2.5 2.5V57H32zM47.5 52h29a2.5 2.5 0 0 1 2.5 2.5V57H47.5zm17.037 20.102C73.95 70.288 79 62.01 79 57H32c.5 7.5 8.072 7 7 11l-2.342 16.862a1 1 0 0 0 .99 1.138H66.72a1 1 0 0 0 .97-1.243z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M23.5 31H86a2.5 2.5 0 0 1 2.5 2.5v34A2.5 2.5 0 0 1 86 70H23.5a2.5 2.5 0 0 1-2.5-2.5v-34a2.5 2.5 0 0 1 2.5-2.5M50 70h9.5v8H50Zm-10 8h30M42.5 45.5h5m5 0h-5m0 0v9.75" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="m56.75 45.5 5 10 5-10" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <path d="M28 23a2.5 2.5 0 0 1 2.5-2.5h24V85h-24a2.5 2.5 0 0 1-2.5-2.5zm2 65.5a1 1 0 0 0 1 1h47a1 1 0 0 0 1-1V85H30zM81 23a2.5 2.5 0 0 0-2.5-2.5h-24V85h24a2.5 2.5 0 0 0 2.5-2.5zM50.5 48v9.5m8-9.5v9.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,8 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M31.5 25h47a2.5 2.5 0 0 1 2.5 2.5v55a2.5 2.5 0 0 1-2.5 2.5h-47a2.5 2.5 0 0 1-2.5-2.5v-55a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M31.5 37.5h47A2.5 2.5 0 0 1 81 40v42.5a2.5 2.5 0 0 1-2.5 2.5h-47a2.5 2.5 0 0 1-2.5-2.5V40a2.5 2.5 0 0 1 2.5-2.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M38 60.5a17 17 0 1 0 34 0 17 17 0 1 0-34 0" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M43.5 60.5a11.5 11.5 0 1 0 23 0 11.5 11.5 0 1 0-23 0m22-29.5a2 2 0 1 0 4 0 2 2 0 1 0-4 0m7.5 0a2 2 0 1 0 4 0 2 2 0 1 0-4 0m-37.25 0h9.5" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 110 110">
+  <g>
+    <path d="M88.5 47h-20v14h20zm-12 4h4m7.984-8h-66v4h66zm-66 4h4v26.5a1.5 1.5 0 0 1-1.5 1.5h-1a1.5 1.5 0 0 1-1.5-1.5z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M24.866 35.597A2.5 2.5 0 0 1 27.197 34h56.577a2.5 2.5 0 0 1 2.33 1.594l2.35 6.044a1 1 0 0 1-.93 1.362H23.46a1 1 0 0 1-.933-1.361zM88.5 61h-20v12.5A1.5 1.5 0 0 0 70 75h17a1.5 1.5 0 0 0 1.5-1.5zm-12 4h4" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 90 90">
+  <path d="M75.702 13.011q.012-.225.012-.453c0-4.843-3.917-8.768-8.748-8.768H23.034c-4.83 0-8.747 3.925-8.747 8.768q0 .228.011.453M77.132 72.09q.59.091 1.206.092c4.348 0 7.873-3.533 7.873-7.892V20.45c0-4.359-3.525-7.892-7.873-7.892-.924 0-1.812.16-2.636.453a7.89 7.89 0 0 0-5.237 7.438v.148m0 0a8.7 8.7 0 0 1-3.499.73H23.034a8.7 8.7 0 0 1-3.499-.73m50.93 0V64.29a7.89 7.89 0 0 0 6.667 7.8M14.298 13.01a7.89 7.89 0 0 1 5.237 7.438v.148m0 0V64.29a7.89 7.89 0 0 1-6.666 7.8q-.59.091-1.206.092c-4.348 0-7.873-3.533-7.873-7.892V20.45c0-4.359 3.525-7.892 7.873-7.892.924 0 1.811.16 2.635.453M77.132 72.09c-1.585 8.05-8.667 14.12-17.164 14.12H30.032c-8.496 0-15.578-6.07-17.163-14.12" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 65 65">
+  <path d="M56.968 18.845q0-.368-.05-.72M49.051 13.8H15.95a5.04 5.04 0 0 1-5.038-5.043 5.04 5.04 0 0 1 5.038-5.043h33.103a5.04 5.04 0 0 1 5.038 5.043 5.04 5.04 0 0 1-5.038 5.043m-33.103 0h-2.88a5.04 5.04 0 0 0-4.986 4.323M49.052 13.8h2.879a5.04 5.04 0 0 1 4.986 4.324m.051 24.826a4.32 4.32 0 0 0 4.318-4.323v-16.18a4.32 4.32 0 0 0-4.369-4.322m.051 24.826a4.32 4.32 0 0 1-4.318-4.323V22.447a4.32 4.32 0 0 1 4.267-4.322m-11.84 37.24h4.695c.736 0 1.446-.111 2.115-.317a7.21 7.21 0 0 0 5.081-6.889v-5.208M8.084 18.124h-.051a4.32 4.32 0 0 0-4.318 4.323v16.18a4.32 4.32 0 0 0 4.318 4.324 4.32 4.32 0 0 0 4.317-4.323V22.447a4.32 4.32 0 0 0-4.266-4.323m11.935 37.24h-4.79a7.2 7.2 0 0 1-2.04-.294 7.21 7.21 0 0 1-5.156-6.91v-5.21m37.045 12.414 5.177 5.183c.969.97 2.534.987 3.524.038a2.526 2.526 0 0 0 .038-3.605l-1.93-1.932m-6.81.316H20.02m-6.83-.294-1.909 1.91c-.998 1-.98 2.627.038 3.605.99.949 2.555.932 3.524-.038l5.177-5.183" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 170 75">
+  <g>
+    <path d="M3.885 6c0-1.243 1.068-2.25 2.386-2.25h157.458c1.318 0 2.386 1.007 2.386 2.25v63c0 1.243-1.068 2.25-2.386 2.25H6.27c-1.318 0-2.386-1.007-2.386-2.25z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M13.428 37.5c0-13.669 11.75-24.75 26.243-24.75h90.658c14.493 0 26.243 11.081 26.243 24.75s-11.75 24.75-26.243 24.75H39.67c-14.493 0-26.243-11.081-26.243-24.75" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M31.56 37.5c0 2.237-1.923 4.05-4.295 4.05s-4.294-1.813-4.294-4.05 1.923-4.05 4.294-4.05c2.372 0 4.295 1.813 4.295 4.05" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 140 140">
+  <g>
+    <path d="M3.862 6.224a2.36 2.36 0 0 1 2.362-2.362H133.97c1.197 0 2.168.97 2.168 2.168 0 71.857-58.251 130.108-130.108 130.108a2.17 2.17 0 0 1-2.168-2.168z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M13.31 32.207c0-10.437 8.46-18.897 18.897-18.897h87.628a2.13 2.13 0 0 1 2.13 2.13c0 58.833-47.692 106.526-106.524 106.526a2.13 2.13 0 0 1-2.13-2.131z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M32.207 27.483a4.724 4.724 0 1 1-9.449 0 4.724 4.724 0 0 1 9.449 0" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 160 200">
+  <path d="M3.879 14.073c0 5.618 4.516 10.172 10.088 10.172h132.065c5.571 0 10.088-4.554 10.088-10.172m-81.165 47.16V46.438c0-5.107-4.106-9.247-9.171-9.247H45.607c-5.065 0-9.17 4.14-9.17 9.247v14.795m89.877 0V46.438c0-5.107-4.107-9.247-9.172-9.247H96.966c-5.065 0-9.171 4.14-9.171 9.247v14.795m-83.916 0H156.12m0 22.192H3.88m9.17 112.673h133.9c5.065 0 9.171-4.14 9.171-9.247V13.15c0-5.107-4.106-9.247-9.171-9.247H13.05c-5.064 0-9.17 4.14-9.17 9.247v173.7c0 5.107 4.106 9.247 9.17 9.247" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 90 200">
+  <path d="M3.79 14.024c0 5.59 4.318 10.122 9.645 10.122h63.13c5.328 0 9.646-4.532 9.646-10.122m-22.797 46.93V46.23c0-5.082-3.926-9.201-8.769-9.201h-19.29c-4.842 0-8.768 4.12-8.768 9.201v14.723m-22.797 0h82.42m0 22.085H3.79m8.768 113.06h64.885c4.842 0 8.768-4.12 8.768-9.202V13.104c0-5.082-3.926-9.202-8.768-9.202H12.558c-4.843 0-8.768 4.12-8.768 9.202v173.792c0 5.082 3.925 9.202 8.768 9.202" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 40 60">
+  <path d="M22.466 3.692v10.085c0 1.21-.92 2.192-2.055 2.192h-.822c-1.136 0-2.056-.981-2.056-2.192V3.692m4.933 8.77h2.878c1.135 0 2.056-.982 2.056-2.193v-.877c0-1.21-.92-2.192-2.056-2.192h-2.878m-4.933 5.262h-2.878c-1.135 0-2.055-.982-2.055-2.193v-.877c0-1.21.92-2.192 2.055-2.192h2.878M5.611 3.692h28.777c1.136 0 2.056.981 2.056 2.192v33.45c0 9.374-7.125 16.973-15.914 16.973h-1.06c-8.79 0-15.915-7.599-15.915-16.972V5.885c0-1.212.92-2.193 2.056-2.193m4.11 15.785h20.556c1.136 0 2.056.981 2.056 2.192v17.807c0 6.874-5.225 12.447-11.67 12.447h-1.327c-6.445 0-11.67-5.573-11.67-12.447V21.67c0-1.21.92-2.192 2.056-2.192m13.567 7.892c0 1.937-1.472 3.508-3.288 3.508-1.817 0-3.29-1.57-3.29-3.508s1.473-3.507 3.29-3.507 3.288 1.57 3.288 3.507" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 40 50">
+  <path d="M17.318 12.182h-8.06c-.88 0-1.592.74-1.592 1.654v16.126c0 6.698 5.225 12.129 11.67 12.129h1.327c6.445 0 11.67-5.43 11.67-12.13V13.837c0-.914-.713-1.654-1.591-1.654H22.68m-.215-8.545v9.827c0 1.18-.92 2.136-2.055 2.136h-.822c-1.136 0-2.056-.956-2.056-2.136V3.637m10.689 8.545V3.637m-16.445 0v8.545M5.611 3.637h28.777c1.136 0 2.056.956 2.056 2.136v24.051c0 9.135-7.125 16.54-15.914 16.54h-1.06c-8.79 0-15.915-7.405-15.915-16.54V5.773c0-1.18.92-2.136 2.056-2.136M23.289 23.29c0 1.888-1.473 3.418-3.29 3.418s-3.288-1.53-3.288-3.418 1.472-3.418 3.289-3.418c1.816 0 3.288 1.53 3.288 3.418" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 35">
+  <path d="M57.12 20.488H45.473c-.514 0-1.008.124-1.372.345s-.568.52-.568.832m4.076-8.236h5.434M6.119 3.5h87.762c1.276 0 2.31.895 2.31 2v24c0 1.105-1.034 2-2.31 2H6.12c-1.275 0-2.31-.895-2.31-2v-24c0-1.105 1.035-2 2.31-2m51 6.4v14.118H45.474a2.04 2.04 0 0 1-1.372-.517 1.7 1.7 0 0 1-.568-1.248V11.665c0-.468.204-.917.568-1.248a2.04 2.04 0 0 1 1.372-.517z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 80 35">
+  <path d="m39.722 16.231 1.505-1.596m1.134 3.15 1.53-1.738M6.03 31.5h67.94c1.251 0 2.265-.895 2.265-2v-24c0-1.105-1.014-2-2.264-2H6.03c-1.251 0-2.265.895-2.265 2v24c0 1.105 1.014 2 2.265 2m41.966-14.305L46.92 17.1a3.4 3.4 0 0 1-1.813-.706l-4.583-3.62c-1.264-1-3.277-.326-3.475 1.161-.185 1.39-1.983 2.1-3.28 1.299l-1.532-.947c-.968-.513-2.2.103-2.2 1.1v3.463c0 1.559 1.43 2.823 3.196 2.823h14.51c1.404 0 2.542-1.005 2.542-2.245 0-1.153-.99-2.118-2.289-2.233" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 80 50">
+  <g>
+    <path d="M3.765 5.773c0-1.18 1.014-2.136 2.265-2.136h67.94c1.251 0 2.265.956 2.265 2.136v38.454c0 1.18-1.014 2.137-2.264 2.137H6.03c-1.251 0-2.265-.957-2.265-2.137z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M36.088 32.135c2.525 1.88 6.205 1.88 8.73 0s3.167-5.101 1.52-7.637l-5.879-8.043-5.893 8.043c-1.644 2.536-1.003 5.755 1.522 7.637" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 140 45">
+  <path d="M56.772 17.88h5.315m0 0h5.315m-5.315 0v9.214m9.832-9.214 5.315 9.45 5.314-9.45M6.224 41.4h127.552c1.305 0 2.362-.94 2.362-2.1V5.7c0-1.16-1.057-2.1-2.362-2.1H6.224c-1.305 0-2.362.94-2.362 2.1v33.6c0 1.16 1.057 2.1 2.362 2.1" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 50 50">
+  <path d="M39.452 12.433H10.548a4.398 4.398 0 1 1 0-8.796h28.904a4.398 4.398 0 0 1 0 8.796m-28.904 0H8.035a4.4 4.4 0 0 0-4.398 4.399V40.08a6.283 6.283 0 0 0 6.283 6.284h30.16a6.283 6.283 0 0 0 6.284-6.284V16.832c0-2.43-1.97-4.399-4.399-4.399h-2.513" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 45 48">
+  <path d="M38.579 17.168c1.326 2.526 1.947 6.015 1.947 9.071 0 10.018-8.07 18.139-18.025 18.139S4.475 36.257 4.475 26.239c0-3.056.586-6.552 1.912-9.078m32.192.007a3.59 3.59 0 0 1-3.333-.976m3.333.976a3.6 3.6 0 0 0 1.765-.976m-33.827.996-.13-.027a3.6 3.6 0 0 1-1.731-.969m30.59 0a18 18 0 0 0-5.848-3.932 17.93 17.93 0 0 0-13.796 0 18 18 0 0 0-5.848 3.932 3.59 3.59 0 0 1-3.237.996m28.729-.996a3.59 3.59 0 0 0 5.098 0m-33.827.996a3.6 3.6 0 0 1-1.861-.996 3.644 3.644 0 0 1 0-5.13 25.2 25.2 0 0 1 8.187-5.505A25.1 25.1 0 0 1 22.5 3.623a25.1 25.1 0 0 1 9.657 1.934 25.2 25.2 0 0 1 8.187 5.505 3.644 3.644 0 0 1 0 5.13" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 120 60">
+  <g>
+    <path d="M3.84 5.884c0-1.21 1.048-2.192 2.34-2.192h107.64c1.293 0 2.34.981 2.34 2.192v48.23c0 1.212-1.047 2.193-2.34 2.193H6.18c-1.292 0-2.34-.981-2.34-2.192z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M103.056 15.093V9.83a.936.877 0 0 1 .936-.877h5.616a.936.877 0 0 1 .936.877v5.262a.936.877 0 0 1-.936.877h-5.616a.936.877 0 0 1-.936-.877m0 35.078v-5.262a.936.877 0 0 1 .936-.877h5.616a.936.877 0 0 1 .936.877v5.262a.936.877 0 0 1-.936.877h-5.616a.936.877 0 0 1-.936-.877m-93.6-35.077V9.83a.936.877 0 0 1 .936-.877h5.616a.936.877 0 0 1 .936.877v5.262a.936.877 0 0 1-.936.877h-5.616a.936.877 0 0 1-.936-.877m0 35.078v-5.262a.936.877 0 0 1 .936-.877h5.616a.936.877 0 0 1 .936.877v5.262a.936.877 0 0 1-.936.877h-5.616a.936.877 0 0 1-.936-.877" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 120 60">
+  <g>
+    <path d="M3.84 30c0-14.53 12.572-26.308 28.08-26.308h56.16c15.509 0 28.08 11.778 28.08 26.308s-12.571 26.307-28.08 26.307H31.92C16.412 56.307 3.84 44.53 3.84 30" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M80.592 15.093V9.83a.936.877 0 0 1 .936-.877h5.616a.936.877 0 0 1 .936.877v5.262a.936.877 0 0 1-.936.877h-5.616a.936.877 0 0 1-.936-.877m0 35.077v-5.262a.936.877 0 0 1 .936-.877h5.616a.936.877 0 0 1 .936.877v5.262a.936.877 0 0 1-.936.877h-5.616a.936.877 0 0 1-.936-.877M31.92 15.093V9.83a.936.877 0 0 1 .936-.877h5.616a.936.877 0 0 1 .936.877v5.262a.936.877 0 0 1-.936.876h-5.616a.936.877 0 0 1-.936-.876m0 35.077v-5.262a.936.877 0 0 1 .936-.877h5.616a.936.877 0 0 1 .936.877v5.262a.936.877 0 0 1-.936.876h-5.616a.936.877 0 0 1-.936-.876" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 80 80">
+  <g>
+    <path d="M3.765 40a36.235 36.235 0 1 0 72.47 0 36.235 36.235 0 1 0-72.47 0" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="m56.26 26.96-3.843-3.843a.906.906 0 0 1 0-1.28l3.843-3.844a.906.906 0 0 1 1.281 0l3.844 3.843a.906.906 0 0 1 0 1.281l-3.844 3.844a.906.906 0 0 1-1.28 0m-.001 34.66-3.843-3.843a.906.906 0 0 1 0-1.281l3.843-3.844a.906.906 0 0 1 1.281 0l3.843 3.844a.906.906 0 0 1 0 1.28l-3.843 3.844a.906.906 0 0 1-1.281 0m-34.423-34.66-3.843-3.843a.906.906 0 0 1 0-1.281l3.843-3.844a.906.906 0 0 1 1.281 0l3.844 3.844a.906.906 0 0 1 0 1.28l-3.844 3.844a.906.906 0 0 1-1.28 0m-.001 34.66-3.843-3.843a.906.906 0 0 1 0-1.281l3.843-3.843a.906.906 0 0 1 1.281 0l3.844 3.843a.906.906 0 0 1 0 1.281l-3.844 3.843a.906.906 0 0 1-1.28 0" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 120 60">
+  <g>
+    <path d="M3.84 12.461c0-4.843 4.19-8.77 9.36-8.77h93.6c5.17 0 9.36 3.927 9.36 8.77v35.077c0 4.843-4.19 8.77-9.36 8.77H13.2c-5.17 0-9.36-3.927-9.36-8.77z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M103.056 15.093V9.83a.936.877 0 0 1 .936-.877h5.616a.936.877 0 0 1 .936.877v5.262a.936.877 0 0 1-.936.877h-5.616a.936.877 0 0 1-.936-.877m0 35.078v-5.262a.936.877 0 0 1 .936-.877h5.616a.936.877 0 0 1 .936.877v5.262a.936.877 0 0 1-.936.877h-5.616a.936.877 0 0 1-.936-.877m-93.6-35.077V9.83a.936.877 0 0 1 .936-.877h5.616a.936.877 0 0 1 .936.877v5.262a.936.877 0 0 1-.936.877h-5.616a.936.877 0 0 1-.936-.877m0 35.078v-5.262a.936.877 0 0 1 .936-.877h5.616a.936.877 0 0 1 .936.877v5.262a.936.877 0 0 1-.936.877h-5.616a.936.877 0 0 1-.936-.877" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 30 50">
+  <path d="M15 30.982v-1.71m3.086 5.128h1.542M15 39.527v-1.709M10.372 34.4h1.542M5.84 46.364h18.322c1.331 0 2.41-1.196 2.41-2.67V6.306c0-1.475-1.079-2.67-2.41-2.67H5.839c-1.331 0-2.41 1.195-2.41 2.67v37.386c0 1.475 1.079 2.67 2.41 2.67m14.56-29.91c0 3.304-2.417 5.982-5.4 5.982-2.981 0-5.4-2.678-5.4-5.981s2.419-5.982 5.4-5.982c2.983 0 5.4 2.678 5.4 5.982M18.858 34.4c0 2.36-1.727 4.273-3.857 4.273s-3.857-1.913-3.857-4.273S12.87 30.127 15 30.127s3.857 1.913 3.857 4.273" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 140 70">
+  <g>
+    <path d="M3.862 5.967c0-1.234 1.057-2.234 2.362-2.234h127.552c1.305 0 2.362 1 2.362 2.234v58.066c0 1.234-1.057 2.233-2.362 2.233H6.224c-1.305 0-2.362-1-2.362-2.233z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M9.531 15.346v-5.36a.945.893 0 0 1 .945-.893h5.67a.945.893 0 0 1 .944.893v5.36a.945.893 0 0 1-.945.894h-5.669a.945.893 0 0 1-.945-.894m113.379.001v-5.36a.945.893 0 0 1 .945-.894h5.67a.945.893 0 0 1 .944.894v5.36a.945.893 0 0 1-.945.893h-5.669a.945.893 0 0 1-.945-.893M9.53 60.013v-5.36a.945.893 0 0 1 .946-.893h5.669a.945.893 0 0 1 .945.893v5.36a.945.893 0 0 1-.945.894h-5.67a.945.893 0 0 1-.944-.894m113.38.001v-5.36a.945.893 0 0 1 .945-.894h5.669a.945.893 0 0 1 .945.894v5.36a.945.893 0 0 1-.945.893h-5.67a.945.893 0 0 1-.944-.893m-97.318-2.681h88.814" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,6 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 160 160">
+  <g>
+    <path d="M156.12 66.202a2.38 2.38 0 0 1-2.379 2.38H94.272c-13.138 0-23.788 10.65-23.788 23.787v61.372a2.38 2.38 0 0 1-2.379 2.38H6.257a2.38 2.38 0 0 1-2.378-2.38V6.257A2.38 2.38 0 0 1 6.257 3.88h147.484a2.38 2.38 0 0 1 2.38 2.378z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M9.588 16.249v-5.71a.95.95 0 0 1 .951-.95h5.71a.95.95 0 0 1 .95.95v5.71a.95.95 0 0 1-.95.951h-5.71a.95.95 0 0 1-.951-.951m133.212.001v-5.71a.95.95 0 0 1 .951-.951h5.71a.95.95 0 0 1 .95.951v5.71a.95.95 0 0 1-.95.951h-5.71a.95.95 0 0 1-.951-.951m0 45.672v-5.71a.95.95 0 0 1 .952-.951h5.709a.95.95 0 0 1 .951.951v5.71a.95.95 0 0 1-.951.951h-5.71a.95.95 0 0 1-.95-.951M9.587 149.46v-5.708a.95.95 0 0 1 .952-.952h5.709a.95.95 0 0 1 .951.952v5.709a.95.95 0 0 1-.951.951h-5.71a.95.95 0 0 1-.951-.951m47.576 0v-5.709a.95.95 0 0 1 .952-.951h5.709a.95.95 0 0 1 .951.951v5.71a.95.95 0 0 1-.951.95h-5.71a.95.95 0 0 1-.951-.95m51.382-90.396H95.569a34.6 34.6 0 0 0-34.6 34.6v12.976" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 60 60">
+  <path d="M3.692 5.884c0-1.21.981-2.192 2.192-2.192h48.23c1.212 0 2.193.981 2.193 2.192v48.23a2.19 2.19 0 0 1-2.192 2.193H5.885a2.19 2.19 0 0 1-2.193-2.192z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 90 90">
+  <path d="M45.944 41.767a2.29 2.29 0 0 0 2.29 2.29H83.92a2.29 2.29 0 0 1 2.29 2.29V83.92a2.29 2.29 0 0 1-2.29 2.29H6.08a2.29 2.29 0 0 1-2.29-2.29V6.08a2.29 2.29 0 0 1 2.29-2.29h37.576a2.29 2.29 0 0 1 2.29 2.29z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 60 50">
+  <path d="M38.188 8.7h10.598c1.211 0 2.193.956 2.193 2.136v28.2c0 1.18-.982 2.136-2.193 2.136H11.08c-1.21 0-2.192-.956-2.192-2.136v-28.2c0-1.18.981-2.136 2.192-2.136h10.599m10.885-5.128V15.11c0 1.18-.981 2.136-2.192 2.136h-.877c-1.21 0-2.192-.957-2.192-2.136V3.572m5.261 7.691h3.07c1.21 0 2.192-.956 2.192-2.136v-.855c0-1.18-.982-2.136-2.192-2.136h-3.07m-5.261 5.127h-3.07c-1.21 0-2.192-.956-2.192-2.136v-.855c0-1.18.982-2.136 2.193-2.136h3.069M5.817 46.299h48.231c1.21 0 2.192-.956 2.192-2.136V5.709c0-1.18-.981-2.137-2.192-2.137H5.818c-1.211 0-2.193.957-2.193 2.137v38.454c0 1.18.982 2.136 2.192 2.136M33.44 25.79c0 1.888-1.57 3.418-3.507 3.418s-3.508-1.53-3.508-3.418c0-1.887 1.57-3.418 3.508-3.418s3.507 1.53 3.507 3.418" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 90 50">
+  <path d="M53.173 12.182c-.468 0-.847.354-.847.79s.38.79.847.79zm21.979 1.58c.467 0 .846-.353.846-.79 0-.436-.379-.79-.846-.79zM6.01 3.572v.79h77.842v-1.58H6.01zM86.14 5.71h-.847v38.454h1.694V5.709zM83.85 46.3v-.79H6.01v1.58h77.842zM3.72 44.163h.847V5.709H2.873v38.454zm2.29 2.136v-.79c-.797 0-1.443-.603-1.443-1.346H2.873c0 1.616 1.404 2.926 3.137 2.926zm80.131-2.136h-.847c0 .743-.646 1.346-1.442 1.346v1.58c1.732 0 3.136-1.31 3.136-2.926zm-2.29-40.59v.79c.797 0 1.443.602 1.443 1.346h1.694c0-1.617-1.404-2.927-3.136-2.927zm-77.841 0v-.79c-1.733 0-3.137 1.31-3.137 2.926h1.694c0-.744.646-1.347 1.443-1.347zm5.494 37.599v.79h28.39v-1.58h-28.39zm30.68-2.136h.846v-28.2h-1.694v28.2zm-32.97-28.2h-.846v28.2h1.694v-28.2zM39.895 8.7v-.79h-5.669v1.58h5.669zm-22.721 0v-.79h-5.669v1.58h5.669zm-7.958 2.136h.847c0-.744.645-1.346 1.442-1.346V7.91c-1.732 0-3.136 1.31-3.136 2.926zm32.968 0h.847c0-1.616-1.404-2.927-3.136-2.927v1.58c.797 0 1.442.603 1.442 1.347zm-2.29 30.336v.79c1.733 0 3.137-1.31 3.137-2.926h-1.694c0 .743-.645 1.346-1.442 1.346zm-28.389 0v-.79c-.797 0-1.442-.603-1.442-1.346H8.368c0 1.616 1.404 2.926 3.136 2.926zm13.737-23.927v.79h.916v-1.58h-.916zm3.205-2.136h.847V3.572H27.6V15.11zM22.952 3.572h-.847V15.11h1.693V3.572zm3.205 13.673v.79c1.732 0 3.136-1.31 3.136-2.926H27.6c0 .743-.646 1.346-1.443 1.346zm-.916 0v-.79c-.797 0-1.443-.603-1.443-1.346h-1.693c0 1.616 1.404 2.926 3.136 2.926zm3.205-5.982v.79h3.206v-1.58h-3.206zm5.495-2.136h.847v-.855h-1.694v.855zm-2.29-2.991v-.79h-3.205v1.58h3.206zm2.29 2.136h.847c0-1.616-1.404-2.926-3.136-2.926v1.58c.796 0 1.442.603 1.442 1.346zm-2.29 2.991v.79c1.733 0 3.137-1.31 3.137-2.926h-1.694c0 .743-.646 1.346-1.442 1.346zm-11.905 0v.79h3.206v-1.58h-3.206zm3.206-5.127v-.79h-3.206v1.58h3.206zm-5.495 2.136h-.847v.855h1.694v-.855zm2.29-2.136v-.79c-1.733 0-3.137 1.31-3.137 2.926h1.694c0-.743.646-1.346 1.442-1.346zm0 5.127v-.79c-.797 0-1.443-.603-1.443-1.346H16.61c0 1.616 1.404 2.926 3.136 2.926zm9.615 14.527h-.847c0 1.452-1.26 2.628-2.816 2.628v1.58c2.49 0 4.51-1.884 4.51-4.208zM25.7 29.208v-.79c-1.555 0-2.816-1.176-2.816-2.628H21.19c0 2.324 2.02 4.209 4.51 4.209zm-3.663-3.418h.847c0-1.451 1.26-2.628 2.816-2.628v-1.58c-2.49 0-4.51 1.884-4.51 4.208zm3.663-3.418v.79c1.555 0 2.816 1.177 2.816 2.628h1.694c0-2.324-2.02-4.208-4.51-4.208zm24.268 18.8v.79h28.39v-1.58h-28.39zm30.68-2.136h.846v-28.2H79.8v28.2zM78.356 8.7v-.79h-28.39v1.58h28.39zm-30.68 2.136h-.846v28.2h1.694v-28.2zm2.29-2.136v-.79c-1.732 0-3.136 1.31-3.136 2.926h1.694c0-.744.646-1.346 1.442-1.346zm30.68 2.136h.846c0-1.616-1.404-2.927-3.136-2.927v1.58c.797 0 1.443.603 1.443 1.347zm-2.29 30.336v.79c1.732 0 3.136-1.31 3.136-2.926H79.8c0 .743-.646 1.346-1.443 1.346zm-28.39 0v-.79c-.796 0-1.442-.603-1.442-1.346H46.83c0 1.616 1.404 2.926 3.136 2.926zm3.206-28.2v.79h21.979v-1.58h-21.98z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 60 35">
+  <path d="m4.444 31.033 50.75-27.007m-50.752-.06 50.75 27.008M5.884 31.5h48.23c1.212 0 2.193-.895 2.193-2v-24c0-1.105-.981-2-2.192-2H5.885c-1.212 0-2.193.895-2.193 2v24c0 1.105.981 2 2.192 2" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 60 60">
+  <path d="M3.772 29.59 29.88 4.383M4.57 55.43 55.43 30M4.175 4.383l26.701 23.863m-27.184.877L55.43 55.43M28.41 3.692H5.884c-1.21 0-2.192.981-2.192 2.192v48.23c0 1.212.981 2.193 2.192 2.193h48.23a2.19 2.19 0 0 0 2.193-2.192V31.589c0-1.21-.981-2.192-2.192-2.192h-21.32a2.19 2.19 0 0 1-2.193-2.192V5.885a2.19 2.19 0 0 0-2.192-2.193" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 50 40">
+  <path d="M5.773 3.555h38.454a2.136 2.056 0 0 1 2.137 2.056v28.777a2.136 2.056 0 0 1-2.137 2.056H5.773a2.136 2.056 0 0 1-2.136-2.056V5.611a2.136 2.056 0 0 1 2.136-2.056" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,7 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 35">
+  <g>
+    <path d="M6.12 31.5h87.76a2.31 2 0 0 0 2.31-2v-24a2.31 2 0 0 0-2.31-2H6.12a2.31 2 0 0 0-2.31 2v24a2.31 2 0 0 0 2.31 2" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M9.089 25.933c-.494.112-.776.546-.63.97s.664.675 1.157.564l-.263-.767zM90.912 9.067c.493-.112.775-.546.63-.97s-.664-.675-1.158-.564l.264.767zM11.875 26.956c.493-.112.775-.546.63-.97s-.664-.676-1.158-.564l.264.767zm3.988-2.556c-.493.112-.775.546-.63.969s.664.676 1.158.564l-.264-.766zm5.045.511c.493-.112.775-.545.63-.969s-.664-.676-1.158-.564l.264.766zm3.988-2.555c-.493.111-.775.545-.63.968.146.424.664.677 1.158.565l-.264-.767zm5.044.51c.494-.111.776-.545.63-.968-.145-.424-.664-.676-1.157-.565l.263.767zm3.99-2.555c-.495.112-.777.546-.63.97.145.423.663.675 1.157.563l-.264-.766zm5.043.511c.494-.112.776-.545.63-.969s-.664-.676-1.158-.564l.264.767zm3.989-2.555c-.494.111-.776.545-.63.969s.664.676 1.157.564l-.263-.767zm5.044.51c.494-.11.776-.545.63-.968-.146-.424-.664-.676-1.158-.565l.264.767zm3.989-2.555c-.494.112-.776.546-.63.97.145.423.664.675 1.157.564l-.264-.767zm5.044.511c.493-.111.775-.545.63-.969s-.664-.676-1.158-.564l.264.767zm3.988-2.555c-.493.112-.775.545-.63.969s.664.676 1.158.564l-.264-.767zm5.045.51c.493-.11.775-.545.63-.968-.146-.424-.664-.676-1.158-.564l.264.766zm3.988-2.555c-.493.112-.775.546-.63.97s.664.675 1.158.564l-.264-.767zm5.044.511c.494-.111.776-.545.63-.968-.145-.424-.664-.677-1.157-.565l.264.767zm3.99-2.555c-.494.112-.777.545-.63.969.145.423.663.676 1.157.564l-.264-.766zm5.043.511c.494-.112.776-.546.63-.969s-.664-.676-1.157-.564l.263.766zm3.989-2.556c-.494.112-.776.546-.63.97s.664.676 1.158.564l-.264-.767zM9.353 26.7l.263.767 2.259-.511-.264-.767-.264-.767-2.258.511zm6.774-1.533.264.766 4.517-1.022-.264-.767-.264-.766-4.517 1.022zm9.033-2.045.264.767 4.516-1.022-.264-.767-.263-.767-4.517 1.023zm9.033-2.044.264.766 4.516-1.022-.264-.766-.264-.767-4.516 1.022zm9.033-2.045.263.767 4.517-1.022-.264-.767-.264-.767-4.516 1.023zm9.032-2.044.264.767 4.517-1.023-.264-.766-.264-.767-4.516 1.022zm9.033-2.045.264.767 4.517-1.022-.264-.767-.264-.766-4.517 1.022zm9.033-2.044.264.767 4.516-1.023-.263-.766-.264-.767-4.517 1.022zm9.033-2.044.264.766 4.516-1.022-.264-.767-.263-.766-4.517 1.022zM88.39 8.81l.264.767 2.258-.511-.264-.767-.264-.767-2.258.511z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+    <path d="M9.089 9.067c-.494-.112-.776-.546-.63-.97s.664-.675 1.157-.564l-.263.767zm81.823 16.866c.493.112.775.546.63.97s-.664.675-1.158.564l.264-.767zM11.875 8.044c.493.112.775.546.63.97s-.664.676-1.158.564l.264-.767zm3.988 2.556c-.493-.112-.775-.546-.63-.969s.664-.676 1.158-.564l-.264.766zm5.045-.511c.493.112.775.545.63.969s-.664.676-1.158.564l.264-.766zm3.988 2.555c-.493-.111-.775-.545-.63-.968.146-.424.664-.677 1.158-.565l-.264.767zm5.044-.51c.494.111.776.545.63.968-.145.424-.664.676-1.157.565l.263-.767zm3.99 2.555c-.495-.112-.777-.546-.63-.97.145-.423.663-.675 1.157-.563l-.264.766zm5.043-.511c.494.112.776.545.63.969s-.664.676-1.158.564l.264-.767zm3.989 2.555c-.494-.111-.776-.545-.63-.969s.664-.676 1.157-.564l-.263.767zm5.044-.51c.494.11.776.545.63.968-.146.424-.664.676-1.158.565l.264-.767zm3.989 2.555c-.494-.112-.776-.546-.63-.97.145-.423.664-.675 1.157-.564l-.264.767zm5.044-.511c.493.111.775.545.63.969s-.664.676-1.158.564l.264-.767zm3.988 2.555c-.493-.112-.775-.545-.63-.969s.664-.676 1.158-.564l-.264.767zm5.045-.51c.493.11.775.545.63.968-.146.424-.664.676-1.158.564l.264-.766zm3.988 2.555c-.493-.112-.775-.546-.63-.97s.664-.675 1.158-.564l-.264.767zm5.044-.511c.494.111.776.545.63.968-.145.424-.664.677-1.157.565l.264-.767zm3.99 2.555c-.494-.112-.777-.545-.63-.969.145-.423.663-.676 1.157-.564l-.264.766zm5.043-.511c.494.112.776.546.63.969s-.664.676-1.157.564l.263-.766zm3.989 2.556c-.494-.112-.776-.546-.63-.97s.664-.676 1.158-.564l-.264.767zM9.353 8.3l.263-.767 2.259.511-.264.767-.264.767-2.258-.511zm6.774 1.533.264-.766 4.517 1.022-.264.767-.264.766-4.517-1.022zm9.033 2.045.264-.767 4.516 1.022-.264.767-.263.767-4.517-1.023zm9.033 2.044.264-.766 4.516 1.022-.264.766-.264.767-4.516-1.022zm9.033 2.045.263-.767 4.517 1.022-.264.767-.264.767-4.516-1.023zm9.032 2.044.264-.767 4.517 1.023-.264.766-.264.767-4.516-1.022zm9.033 2.045.264-.767 4.517 1.022-.264.767-.264.766-4.517-1.022zm9.033 2.044.264-.767 4.516 1.023-.263.766-.264.767-4.517-1.022zm9.033 2.044.264-.766 4.516 1.022-.264.767-.263.766-4.517-1.022zm9.033 2.045.264-.767 2.258.511-.264.767-.264.767-2.258-.511z" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+  </g>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 25">
+  <path d="M18.36 3.15v2.567c0 1.012-1.034 1.833-2.31 1.833h-.924c-1.275 0-2.309-.82-2.309-1.833V3.15m73.905 0v2.567c0 1.012-1.034 1.833-2.31 1.833h-.924c-1.275 0-2.31-.82-2.31-1.833V3.15m-75.29 0H93.65c1.276 0 2.31.82 2.31 1.833V19.65c0 1.012-1.034 1.833-2.31 1.833H5.888c-1.275 0-2.31-.82-2.31-1.833V4.983c0-1.012 1.035-1.833 2.31-1.833" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 180 90">
+  <path d="M90 19.365v57.111m0-57.11V7.683m0 11.681c0 2.151-1.836 3.894-4.1 3.894H30.544a10.7 10.7 0 0 1-4.136-.825M90 19.365c0 2.151 1.836 3.894 4.1 3.894h55.356c1.472 0 2.871-.294 4.137-.825M90 76.476c0 5.376-4.59 9.735-10.25 9.735H30.543c-5.266 0-9.605-3.772-10.185-8.625M90 76.476c0 5.376 4.59 9.735 10.25 9.735h49.206c5.266 0 9.605-3.772 10.185-8.625M90 7.684c0-2.15-1.837-3.894-4.101-3.894H30.544c-5.661 0-10.25 4.358-10.25 9.735q0 .416.036.825M90 7.684c0-2.15 1.836-3.894 4.1-3.894h55.356c5.661 0 10.25 4.358 10.25 9.735q0 .416-.036.825m0 0a10.7 10.7 0 0 1 4.137-.825h2.05c5.662 0 10.252 4.358 10.252 9.734v45.43c0 5.376-4.59 9.734-10.251 9.734h-2.05c-1.484 0-2.894-.3-4.167-.837m0 0c-3.585-1.517-6.084-4.93-6.084-8.898V23.26q0-.417.036-.825c.32-3.622 2.728-6.68 6.077-8.084m-139.34 0c3.35 1.404 5.758 4.462 6.078 8.084q.036.408.036.825v45.43c0 3.967-2.5 7.38-6.085 8.897a10.7 10.7 0 0 1-4.166.837h-2.05c-5.662 0-10.251-4.358-10.251-9.735V23.26c0-5.376 4.59-9.734 10.25-9.734h2.05c1.473 0 2.872.294 4.138.825" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
@@ -0,0 +1,3 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 260 170">
+  <path d="M93.673 20.687V83.69m0-63.004v-12.6m0 12.6c0 2.32-1.913 4.2-4.273 4.2H31.704a10.8 10.8 0 0 1-4.311-.89m66.28-3.31c0 2.32 1.914 4.2 4.274 4.2h64.106c2.36 0 4.274-1.88 4.274-4.2M93.673 83.692c0 5.8-4.783 10.501-10.684 10.501H31.704c-5.489 0-10.011-4.068-10.616-9.304m72.585-1.197c0 5.8 4.784 10.501 10.684 10.501h51.286c5.9 0 10.684-4.701 10.684-10.5m0-63.005V83.69m0-63.004v-12.6m0 12.6c0 2.32 1.914 4.2 4.273 4.2h57.696c1.534 0 2.993-.317 4.312-.89m-66.28 59.695v71.923c0 5.799 4.782 10.5 10.684 10.5h51.284c5.49 0 10.012-4.068 10.616-9.304V84.888M93.673 8.086c0-2.32-1.913-4.2-4.273-4.2H31.704c-5.9 0-10.684 4.7-10.684 10.5q0 .45.038.89m72.615-7.19c0-2.32 1.914-4.2 4.274-4.2h64.106c2.36 0 4.274 1.88 4.274 4.2m0 0c0-2.32 1.914-4.2 4.273-4.2h57.696c5.9 0 10.685 4.7 10.685 10.5 0 .293.024.587 0 .874m-.07 69.628c1.327.58 2.797.904 4.344.904h2.136c5.901 0 10.684-4.702 10.684-10.501V24.887c0-5.8-4.783-10.5-10.684-10.5h-2.136c-5.596 0-10.187 4.227-10.647 9.61q-.038.44-.038.89V75.29c0 4.28 2.605 7.961 6.342 9.597M21.059 15.276a10.8 10.8 0 0 0-4.312-.89H14.61c-5.9 0-10.684 4.701-10.684 10.5v50.405c0 5.8 4.783 10.5 10.684 10.5h2.137c1.546 0 3.016-.322 4.342-.903 3.737-1.636 6.342-5.317 6.342-9.597V24.887q0-.45-.037-.89c-.334-3.907-2.844-7.206-6.335-8.72" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
+</svg>
--- a/Show More
+++ b/Show More