f44ca3afbaa12b034e665f2484f1124adbbc1e78
Task 4 of Plan 01-11 attempted A1-A4 wiring. Empirical run reveals an
architectural blocker that needs orchestrator-level decision.
Current state after this commit (SKIP_PROD_REBUILD=1 npx tsx tests/uat/harness.test.ts):
- A0 [PASS]: production bundle hook-leak grep gate (17ms)
- A1 [FAIL]: SW bootstrap → setIdleMode — popup state never transitions
to '' despite keepalive ping + 3s waitFor. chrome.action.getPopup({})
from the popup page consistently returns the manifest default
(chrome-extension://<id>/src/popup/index.html), not the '' that
setIdleMode's chrome.action.setPopup({popup:''}) should produce.
- A2 [FAIL]: toolbar onClicked — badge never transitions to "REC" after
page.triggerExtensionAction(extension); 8s timeout. Either the
toolbar action isn't reaching the SW listener, OR getDisplayMedia's
picker isn't resolving in headless mode (despite the auto-select flag).
- A3 [FAIL]: offscreen target never appears (correlates with A2 — no
recording started, no offscreen document spawned).
- A4 [PASS]: trivially passes (offscreen count is 0 → 0, both before
+ after the click). Not a true assertion of behavior; would also pass
if the whole extension were broken.
- A5-A13: stubbed RED per plan.
Architectural blocker (Rule 4 — needs orchestrator decision):
- Puppeteer 25.0.2 + Chrome 148 + headless cannot reliably keep the MV3
SW alive long enough OR expose its real chrome.* state to a popup
page query. The popup-bridge architecture (Task 3 commit dbd977c)
works for synchronous bridge queries (snapshot, fire-on-startup)
but does NOT reliably reflect chrome.action.setPopup / setBadgeText
state changes initiated by the SW.
Three plausible paths forward (need orchestrator pick):
Option A — Content-script bridge: inject a content script that
bridges chrome.* queries to a webpage's window.* RPC surface;
harness uses page.evaluate against the content script instead of
popup.evaluate. Pros: content scripts have stable lifetime tied to
the page they're injected into. Cons: content scripts have
DIFFERENT chrome.* surface (no chrome.action API surface — they
can't read getBadgeText / getPopup at all). Likely DOESN'T solve
the underlying problem.
Option B — Headful with Xvfb on CI: relax the headless requirement;
accept Xvfb dependency. Per Plan 01-11 RESEARCH §3, RESEARCH
claimed headless works on Chrome 148 — empirical refutation here.
Pros: SW lifetime is more stable in headful mode; setPopup
propagation is reliable. Cons: introduces Xvfb dep that RESEARCH
explicitly said wasn't needed; CI complication.
Option C — Shrink harness scope to bridge-able assertions: A0 (grep
gate), A8 (Bug A onStartup via bridge), A9 (icon sizes via popup
fetch), A10 (manifest via popup), A13 (zip shape — operator runs
SAVE_ARCHIVE manually + drops zip to a known path; harness reads
it). Skip A1-A7, A11, A12 (the ones that require live SW state
observation through chrome.action API). Pros: ships the
bug-A-coverage portion of the harness today; keeps Plan 01-09's
Task 5 operator-checkpoint partly automated. Cons: doesn't retire
operator entirely; Plan 01-09 stays open on operator-empirical
A1-A7.
Option D — Switch to WebDriver BiDi (the Puppeteer 25 alternative
backend): Puppeteer 25 supports BiDi via {protocol: 'webDriverBiDi'}.
BiDi may handle extension SW evaluation differently (different
isolation model). Speculative — no empirical evidence either way.
What landed cleanly:
- Tier-1 hook-leak grep gate (T-1-11-01) GREEN: dist/ has zero
__mokoshTest / simulateUserStop / getSegmentCount / setCurrentStream
/ setSegmentCountGetter / __mokoshTestQuery / __mokoshKeepalive
occurrences after npm run build.
- Two-bundle infrastructure (dist/ vs dist-test/) operational.
- Bridge handler in sw-hooks.ts works for snapshot + fire-on-startup
+ handler-types ops (verified by no-hang on keepalivePing call).
- Existing 89-test vitest baseline preserved (no regression from any
Wave 0/1/2/3 work).
Verification:
- npx tsc --noEmit (src/): exit 0
- npx tsc --noEmit -p tests/uat: exit 0
- npm run build: exit 0; dist/ hook-free
- SKIP_BUILD=1 npx vitest run: 89/89 GREEN
- SKIP_PROD_REBUILD=1 npx tsx tests/uat/harness.test.ts:
2/14 passed (A0 + A4-trivially), 12 FAIL — non-zero exit as expected.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
AI Call Recorder - Браузерное расширение для записи сессий операторов
Фаза 1 — Локальная запись + экспорт архива
Установка и запуск
Разработка
# Установка зависимостей
npm install
# Сборка для разработки с HMR
npm run dev
# Сборка для продакшена
npm run build
Установка расширения в Chrome
-
Соберите проект:
npm run build -
Откройте Chrome и перейдите по адресу:
chrome://extensions/ -
Включите "Режим разработчика" (Developer mode) в правом верхнем углу
-
Нажмите кнопку "Загрузить распакованное расширение" (Load unpacked)
-
Выберите папку
distв корне проекта -
Расширение установлено!
Использование
-
При первом открытии popup расширение запросит разрешение на запись экрана
-
Разрешение обязательно для работы расширения
-
Расширение автоматически начнет запись:
- Видео: последние 30 секунд (кольцевой буфер)
- DOM-события через rrweb: последние 10 минут
- Лог действий пользователя: последние 10 минут
-
Для сохранения отчета об ошибке:
- Нажмите на иконку расширения
- Нажмите кнопку "Сохранить отчёт об ошибке"
- Архив автоматически загрузится в папку "Загрузки"
Структура архива
Архив session_report_YYYY-MM-DD_HH-MM-SS.zip содержит:
session_report_2025-05-15_14-32-10.zip
├── video/
│ └── last_30sec.webm # склеенные чанки видеобуфера
├── rrweb/
│ └── session.json # массив DOM-событий rrweb
├── logs/
│ └── events.json # лог действий пользователя
├── screenshot.png # скриншот в момент сохранения
└── meta.json # метаданные сессии
Технический стек
- Тип расширения: Chrome Extension, Manifest V3
- Service Worker: Background script (Manifest V3)
- Захват экрана:
chrome.tabCaptureAPI - Захват DOM:
rrweb(npm: rrweb) - Лог событий: Content Script
- Упаковка архива:
JSZip(npm: jszip) - Сохранение файла:
chrome.downloadsAPI - Хранение буфера: In-memory (Service Worker + Content Script)
- Build: Vite + crxjs + TypeScript
Особенности
Маскирование чувствительных данных
- Пароли (
input[type=password]) маскируются автоматически в rrweb и логах - Поля с атрибутом
data-sensitive="true"также маскируются в rrweb
Записываемые события
Пользовательские события
- click — клик по любому элементу
- input — изменение значения поля (без паролей)
- navigation — переходы по страницам (popstate, hashchange, History API)
- js_error — JavaScript ошибки (window.onerror, unhandledrejection)
- network_error — сетевые ошибки (fetch/XHR с кодом ответа >= 400)
Кольцевой буфер
- Видео: 30 секунд, первый чанк (WebM заголовок) хранится всегда
- rrweb события: 10 минут, максимум 5000 событий
- Пользовательские события: 10 минут
Память
- Ожидаемое потребление: ~5-10 МБ в фоновом режиме
Критерии приёмки Фазы 1
- ✅ Расширение устанавливается в Chrome без ошибок
- ✅ Видеобуфер непрерывно работает на любой вкладке
- ✅ В буфере всегда есть не более 30 секунд видео
- ✅ rrweb пишет DOM-события без ошибок на типовых страницах
- ✅ Лог событий фиксирует клики, навигацию и сетевые ошибки
- ✅ При нажатии кнопки архив скачивается в "Загрузки" за < 5 секунд
- ✅ Архив открывается,
last_30sec.webmвоспроизводится в браузере - ✅ Пароли не попадают в лог и rrweb-снимки
- ✅ RAM-потребление расширения не превышает 50 МБ в фоне
Отладка
Console Logs
Расширение пишет подробные логи в консоль:
- Service Worker: Chrome DevTools → Extensions → Service Worker → Console
- Content Script: Chrome DevTools на любой странице → Console
- Popup: Правый клик по popup → Проверить
Структура проекта
ai-call-extension/
├── src/
│ ├── background/ # Service Worker
│ │ └── index.ts
│ ├── content/ # Content Script
│ │ └── index.ts
│ ├── popup/ # Popup UI
│ │ ├── index.html
│ │ ├── index.ts
│ │ └── style.css
│ └── shared/ # Общие типы и утилиты
│ ├── types.ts
│ └── logger.ts
├── icons/ # Иконки расширения
├── dist/ # Собранные файлы
├── manifest.json # Manifest расширения
├── vite.config.ts # Конфигурация Vite
├── tsconfig.json # Конфигурация TypeScript
└── package.json
Лицензия
MIT
Контакты
Для вопросов и предложений обращайтесь в support.
Description
Languages
TypeScript
91%
HTML
3.4%
CSS
2.8%
Shell
2%
JavaScript
0.8%