proposal, design (D-1…D-10), спеки osv-parsing (новая) и tabular-recognition-service (MODIFIED «Парсер — заменяемый интерфейс»), tasks (13 задач). Решение владельца 05.10.2026: подсрез 2a — только парсер ОСВ. Issue: RSHB/arm-tabular-parser#5 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012vJkmBGKKqMoEMzvsXG3y2
1.7 KiB
1.7 KiB
Spec Delta: tabular-recognition-service
MODIFIED Requirements
Requirement: Парсер — заменяемый интерфейс
Разбор файла SHALL выполняться через единый интерфейс «байты + тип файла → документы/метрики/ошибка», не знающий о
NATS и S3; воркер MUST NOT зависеть от конкретной реализации. Реализация по умолчанию (get_parser()) SHALL разбирать
ОСВ по спеке osv-parsing и писать файл результата с schema_version = "1.1"; листы с признаками ББ/ОФР SHALL
пропускаться с предупреждением до подсреза 2b. Каталог api/rules/ SHALL содержать словари ОСВ (osv_headers,
osv_groups, periods, data_types) и README.
Scenario: Подмена реализации в тесте
- WHEN в тесте воркеру передан парсер, возвращающий один
osvDocument - THEN файл результата с этим документом записан в S3, конверт имеет
status = doneиresult_s3на этот файл
Scenario: Реальная ОСВ через воркер
- WHEN в интеграционном тесте в S3 лежит
rb/2024-FY/ОСВ_66 за 2024.xlsи опубликован запросfile_type = XLS - THEN после ack публикуется конверт
doneсresult_schema_version = "1.1", файл результата проходит схему v1.1 и содержит одинosvDocumentсaccount_code_raw = "66"