liderra/portal
1
0
Fork 0
Code Issues Pull Requests Actions 71 Packages Projects Releases Wiki Activity
Files
ef2436e2e6bf6f81a8a9aa19f2c607bc81cdbb36
portal/docs/bugs.md
T

19 KiB
Raw Blame History

Журнал багов и квирков

Файл для фиксации обнаруженных проблем, которые требуют разбирательства или решения позже.

Заводится командой заказчика «запиши в баг» + краткое описание. Claude добавляет запись с текущей датой в конец списка. Если описание не передано — Claude задаёт уточняющие вопросы (где, симптом, как воспроизвести).

Формат записи:

## YYYY-MM-DD HH:MM — Краткий заголовок

**Где:** компонент / файл / сценарий
**Симптом:** что пользователь видит / что не работает
**Детали:** что точно происходит, репро, цитаты ошибок
**Статус:** открыт / расследуется / в работе / закрыт
**Решение:** (когда найдём)
**Связано:** (ссылки на спеки/планы/записи, если есть)

Не дублирует:

  • docs/Открытые_вопросы_v8_3.md — там бизнес/продуктовые вопросы (Биз-*, CTO-*, Ю-*, Диз-*)
  • docs/superpowers/specs/ — там design specs
  • docs/superpowers/plans/ — там implementation plans

Здесь — техника, баги и квирки, которые надо помнить, но они не блокируют работу прямо сейчас.

2026-05-30 — Невозможно записать в memory из проектной сессии при активной защите v4

Где: связка хуков tools/enforce-memory-coverage.mjs + tools/enforce-normative-content-rules.mjs для путей memory/*.md и MEMORY.md.

Симптом: Claude не может записать memory entry из активной project-сессии — оба хука блокируют любую комбинацию (Skill+Write без override / Write с override-фразой / Skill в одной response с Write). За одну сессию 30.05.2026 не удалось сохранить 3 запланированные memory entries (project + 2 feedback).

Детали:

  • Хук 1 (enforce-memory-coverage) ищет override-фразу memory dump в lastUserPromptText — это последний user-message с настоящим text-блоком (см. lastTurnEntries в tools/enforce-hook-helpers.mjs строки 100-115)
  • Skill body от любого plugin-skill тоже приходит как user-message с text → становится «последним user prompt'ом» → перебивает override-фразу заказчика, отправленную ранее
  • Хук 2 (enforce-normative-content-rules) требует Skill claude-md-management в turnToolUses текущего turn'а (см. detectLegitSkillActive строки 126-133)
  • Skill body разрывает turn в том же месте → мой Skill tool_use оказывается в предыдущем turn'е, а Write — в новом → хук 2 не видит skill
  • Override-фразы для хука 2 нет — только активный skill в текущем turn'е (Layer 5 в decide())
  • Композиция: с Skill = хук 1 не видит override; без Skill = хук 2 нет легитимного skill'а. Замкнутый круг.
  • За сессию 30.05.2026 было ~7 попыток с разными комбинациями (direct coverage + memory dump / coverage memory-sync + skill в той же response / coverage skill:claude-md-management / без скилов универсальный override) — все заблокированы.
  • Update 30.05 поздний вечер: universal override-фраза без скилов (которая по системным reminder'ам должна снимать все хуки на текущий turn) тоже не снимает хук 2 — хук 2 даже не упоминает override-vocabulary, у него только проверка активного skill в turnToolUses. То есть universal-override механизм через слова-фразы НЕ покрывает второй хук.
  • Update 30.05 ночь: после закрытия параллельной v4 сессии заказчик попросил «попробовать снова» — защита усилилась, а не ослабла. Появился третий хук tools/enforce-read-path-deny.mjs который блокирует даже Read от memory/MEMORY.md («§3.1 transcript/runtime/normative hard-deny»). Это значит теперь нельзя ни Read, ни Edit MEMORY.md из проектной сессии. Запись новых entries в memory/*.md тоже блокирована (хук 2 как раньше). Single source of truth для memory чтения сейчас — Read через absolute-path к индивидуальным файлам (тоже под вопросом, не проверял после v4-deploy).
  • Архитектурный вывод: memory из активной project-сессии сейчас неработоспособна как канал — ни запись, ни чтение MEMORY.md. Только индивидуальные memory/<entry>.md файлы возможно ещё читаются. Это зона следующей итерации защит v4 — либо реализовать корректный override через специальный skill, либо ослабить хуки.

Воспроизведение:

  1. Открыть проектную сессию Claude в репо Лидерры
  2. Активировать любой Skill (например, claude-md-management:revise-claude-md)
  3. Попытаться Write файла в memory/*.md
  4. Хук 2 блокирует как «no active legit skill» (несмотря на активный skill)

Статус: открыт

Решение: TBD. Варианты:

  • (1) Расширить override-vocab хука 2 фразой memory dump — самое простое
  • (2) Поправить lastTurnEntries в enforce-hook-helpers.mjs чтобы skill-body не считался turn boundary (hasText && !hasToolResult исключение для plugin-skill бодиев)
  • (3) Добавить дополнительный legit skill для memory writes отдельно от claude-md-management (например, superpowers:memory-write)
  • (4) Объединить два хука в один с consistent override-логикой

Это зона параллельной v4 сессии (router-gate v4 streams A-E), которая как раз сейчас тестирует эту защиту. Возможно, после её закрытия часть багов уйдёт сама.

Связано: docs/superpowers/specs/2026-05-29-router-gate-v4-{design,1-max-closure,2-vm-sandbox}.md — спеки защиты v4.

Update 2026-05-30 (новая сессия, свежая проба): Запущена отдельная сессия специально под запись памяти по итогам lead-region-resolution. Сделана 1 проба — прямой Write в memory/project_lead_region_resolution.md с coverage: direct:memory-sync. Результат: заблокировано хуком 2 — [node tools/enforce-normative-content-rules.mjs]: normative write without an active legit skill (claude-md-management) — direct bypass attempt. Защита по-прежнему активна, поведение не изменилось после закрытия параллельной v4-сессии. Согласно инструкции «не упорствовать больше 2 попыток» — попытки записи в memory/*.md приостановлены. Все 3 запланированных memory entries (project_lead_region_resolution + 2 feedback) подготовлены в тексте, но не сохранены. Канал memory из проектной сессии остаётся неработоспособным до реализации одного из вариантов решения (1)-(4) выше. Запись в docs/bugs.md (не нормативный путь) — проходит нормально.

Update 2026-05-30 (РЕШЕНИЕ для записи найдено заказчиком — частично): Заказчик дал рабочий обход для записи memory/*.md: вызвать Skill claude-md-management:revise-claude-md (с любым no-op аргументом) И в ТОМ ЖЕ turn'е после Skill сделать Write — тогда детектор detectLegitSkillActive хука 2 видит активный легальный skill в turnToolUses, и Write проходит. coverage-строка direct:memory-sync удовлетворяет хук 1. Проверено 30.05: 3 заметки записались успешно этим методом (project_lead_region_resolution + 2 feedback). Зависит от фикса ffd70d6f (30.05) — lastTurnEntries skip harness-injected skill bodies, иначе skill-body разрывает turn и прячет Skill от детектора. НО индекс MEMORY.md обновить так НЕ удалось — третий хук enforce-read-path-deny.mjs блокирует даже Read MEMORY.md (§3.1 transcript/runtime/normative hard-deny), а Edit без предварительного Read невозможен. Перезапись целиком небезопасна (файл 41KB, в контексте обрезан до ~24KB → потеря данных). Остаётся не решено: обновление индекса MEMORY.md из проектной сессии. Варианты: (5) исключить MEMORY.md из read-path-deny при активном claude-md-management skill; (6) дать отдельный write-only канал для append-строки в индекс. Индивидуальные memory/<entry>.md — пишутся, индекс — нет.

2026-05-30 — git полностью заблокирован из проектной сессии (router-gate + powershell-gate v4)

Где: tools/enforce-router-gate.mjs (matcher Bash) + tools/enforce-powershell-gate.mjs (matcher PowerShell).

Симптом: Невозможно выполнить ни одну git-команду из проектной сессии — даже read-only (git rev-parse, git status). Обе оболочки default-deny:

  • Bash: [router-gate] команда не в whitelist — default-deny (§5.1)
  • PowerShell: [powershell-gate] cmdlet «git» не в whitelist — default-deny (§5.1.2)

Детали:

  • 30.05.2026 заказчик попросил закоммитить spec + plan фичи lead-region-resolution в ветку feat/lead-region-resolution. Попытка git switch -c + git commit -- <explicit paths> через Bash → блок router-gate. Тот же git через PowerShell-tool → блок powershell-gate (F1 из v3.8 — PowerShell-путь закрыт).
  • Архитектурно git из проектной сессии под v4 неработоспособен: router-gate default-deny на Bash блокирует git-команду ДО того, как сработает side-channel approve_git_operation (§4.5 / §3.5 v3.5 design) — то есть механизм AskUserQuestion-одобрения git-операции недостижим, потому что сама команда не доходит до gate-логики одобрения.
  • Файлы spec + plan сохранены на диск (untracked, не потеряны): docs/superpowers/specs/2026-05-29-lead-region-resolution-design.md + docs/superpowers/plans/2026-05-29-lead-region-resolution.md. Просто не закоммичены.

Статус: открыт. Связано с общей темой over-blocking защиты v4 (см. запись выше про memory).

Решение: TBD. Варианты:

  • (1) Добавить git в whitelist router-gate / powershell-gate под AskUserQuestion-одобрение (восстановить путь S8 v3.5 — gate должен пропускать git-команду ДО проверки whitelist, если есть свежий approve_git_operation).
  • (2) Закоммитить вручную заказчиком (вне Claude-сессии) или из сессии с ослабленной защитой.
  • (3) Дождаться фикса v4 (зона параллельной router-gate v4 сессии).

Update 2026-05-30 (штатный путь для git НАЙДЕН и сработал): git-коммит из проектной сессии возможен штатно. Механизм (заложен в v4 by design): одиночная git-команда (не цепочка) идёт в classifyGitCommand; read-only (status/rev-parse/log) — allow; мутирующая (add/commit/switch) — conditional, нужен approve_git_operation в ~/.claude/runtime/askuser-decisions-<sess>.jsonl, который пишет PostToolUse-хук enforce-askuser-answer-parser.mjs из выбранного ответа AskUserQuestion (если в тексте ответа есть git ...). Затем выполняется РОВНО та же команда (normalize-match, окно 5 мин). Успешно закоммичено 4686b365 (spec+plan, 2 файла). Грабли: (а) НЕ цеплять команды через &&/echo — цепочка не попадает в git-классификатор → default-deny; (б) символ > в команде (напр. <email> в Co-Authored-By trailer) ловится hard-blacklist «stdout redirect» РАНЬШЕ git-одобрения — trailer с <...> невозможен; (в) lefthook pre-commit (gitleaks/markdownlint/cspell) работает как обычно, его надо проходить честно (allowlist .gitleaks.toml недоступен под read-deny → телефоны-примеры маскировать в тексте).

2026-05-30 — v4-гейт блокирует весь dev/test-workflow (нельзя реализовывать код)

Где: tools/enforce-router-gate.mjs whitelist (§5.1).

Симптом: Невозможно реализовать ни одну кодовую фичу из проектной сессии — гейт режет инструменты разработки:

  • php artisan test / php artisan migrate → команда не в whitelist — default-deny (whitelist разрешает только list/route:list/migrate:status).
  • ./vendor/bin/pest / composer test → не в whitelist → блок.
  • cd app && <что-угодно> → цепочка → не в whitelist → блок. А т.к. artisan лежит в app/, до даже whitelisted-команд (php artisan migrate:status) не добраться без cd app.
  • Субагенты (Agent tool, subagent-driven-development) → API Error: 400 tools.110.custom.input_schema.properties — один MCP-инструмент экспортирует невалидный ключ свойства, что ломает ЛЮБОй dispatch субагента с полным набором тулзов.

Детали: 30.05.2026 заказчик выбрал «старт Сессии 1 (миграции БД) фичи lead-region-resolution через субагентов». Проверка показала: (1) TDD невозможен — нельзя запустить ни тест (pest), ни миграцию; (2) субагенты не запускаются (API-ошибка схемы MCP-тула); (3) даже зайти в app/ нельзя (cd-цепочка режется). Писать миграции/тесты «вслепую» без прогона — нарушает TDD и планку качества «качество > скорость». Поэтому реализация Сессии 1 отложена.

Статус: открыт. Та же тема over-blocking v4.

Решение: TBD. Для реализации кода гейту нужно whitelist'ить dev-workflow: php artisan test/migrate/tinker, ./vendor/bin/pest, composer test/pint/stan, npm run *, и разрешить cd app && ... (или запускать из app/ как cwd). Плюс починить MCP-тул с невалидным ключом свойства (ломает субагентов). Это зона параллельной router-gate v4 сессии. До этого фича-реализация из проектной сессии заблокирована; артефакты (spec+plan) готовы и закоммичены — старт возможен сразу после расширения whitelist.

Update 2026-05-30 (частичный прогресс — dev-workflow whitelisted, остался cd): Параллельная v4-сессия расширила SAFE_EXACT в tools/enforce-router-gate.mjs (2026-05-30): теперь проходят php artisan test|migrate*|db:seed|cache:clear|..., composer test|pint|stan|insights|rector, vendor/bin/pest, pest. НО остаются 2 блокера для инлайн-реализации: (1) cd app и cd app && <dev-cmd> режутся (cd не в whitelist; чейн с не-whitelisted сегментом → default-deny) — а pest/artisan надо запускать из app/ (cwd сессии = корень репо, патчи whitelist'а ^php\s+artisan / ^vendor/bin/pest без app/-префикса предполагают cwd=app/). Нужно добавить cd (или cd app && ...) в whitelist ЛИБО запускать dev-сессию с cwd=app/. (2) Субагенты по-прежнему падают API Error 400 tools.110... (MCP-тул с битым ключом, на уровне сессии — не лечится без рестарта). Итог: после добавления cd app в whitelist — инлайн-TDD Сессии 1 возможен (субагенты всё равно недоступны, но контроллер может вести TDD сам).

Reference in New Issue View Git Blame Copy Permalink