Журнал проекта PKI

Журнал требований, решений, событий и изменений проекта по теме PKI. Ведёт Claude Code по поручению А.М. Новые записи дат добавляются сверху (ниже правил ведения).

Правила ведения:

  • одна запись в начало журнала = дата (заголовок ##)

  • в случае объёмных задач наименование подзаголовка ###

    • выделение № ответа на запрос (сквозной по проекту) тип + суть; типы: Требование / Решение / Событие / Изменение;

  • ссылаться на файлы артефактов, не дублировать их содержимое;

  • решения и требования записывать дословно или с пометкой «!ai переформулировано».

2026-10-01

Ответ № 08 — ответы А.Б. в OQ.md; новая Заявка (десять функций); сборка v05 ЧТЗ/ПМИ без обвязки

  • 08 Событие — по exchange/260928_Answers.md в work/OQ.md закрыты вопросы В02–В06, В08–В15, В19, В20 (ответы А.Б. — дословно; В10 и В13 шли без пометки (А.Б.) — подтверждены А.М. 2026-10-01). Остаются открытыми: В07, В16–В18.

  • 08 Изменение — вводный документ — новая Заявка exchange/заявка.md («Требования предъявляемые к результатам работ по Заявке на выполнение работ»; работы — «Создание реестра сертификатов ключей проверки электронной подписи на базе технологии распределённого реестра»). Прежняя заявка (десять элементов в трёх группах по видам работ) отменена. ЧТЗ и ПМИ адресуют десять функций п. 4 «Требования к функциям» (пункты 1–10), заголовки — слово-в-слово.

  • 08 Изменение — ПМИ ИБ исключён из состава выходных документов.

  • 08 Изменение — собрана версия 05 обоих документов полностью без обвязки (ни титула, ни содержания), только главы по функциям Заявки, пока текстом в md: work/ps01/ЧТЗ_РР_ОИОК_v05.md (713 строк: 10 глав с дословными заголовками, 46 подразделов, 20 сквозных таблиц; собрана tech-writer-агентом из черновиков 4.2.2/4.2.3/4.2.4) и work/ps01/ПМИ_РР_ОИОК_v05.md (118 строк: 10 проверок с дословными заголовками, 29 шагов — по 2–3 шага на функцию; формат: смысловой абзац → предварительные условия → таблица «№ | Шаг | Ожидаемый результат»). Заголовки обоих документов сверены посимвольно с Заявкой — 10/10.

  • 08 Событие — вопросы сборки ПМИ v05 на решение А.М. (в OQ.md: В21, В22): (1) в проверку 6 включён шаг аннулирования/отмены события аккредитации — без него «отменённое событие» в проверках 6 и 10 остаётся без порождающего действия; (2) изменение/дополнение сведений об УЦ (А.1.2) не покрыто ни одной из десяти проверок — можно добавить шаг в проверку 3; (3) негативные коды ERR-* осознанно не воспроизводятся (только позитивные сценарии).

2026-09-15

Ответ № 05 — черновики ЧТЗ 4.2.2/4.2.3 и ПМИ А.2/А.3 по реестрам сертификатов УКЭП/УНЭП

  • 05 Событие — по источникам r2+3_Certificates/3 Описание реестра_сертификатов.html (3,4 МБ; текст извлечён, конспектирован тремя docs-analyst-агентами по главам) и Диаграммы описания решения Реестры сертификатов.md подготовлены 4 черновика в work/r2+3_Certificates/: ЧТЗ_реестры_сертификатов_УКЭП_4.2.2_v01_draft.md, ЧТЗ_реестры_сертификатов_УНЭП_4.2.3_v01_draft.md, ПМИ_реестры_сертификатов_УКЭП_А.2_v01_draft.md, ПМИ_реестры_сертификатов_УНЭП_А.3_v01_draft.md.

  • 05 Изменение — ЧТЗ 4.2.2 (УКЭП): подразделы 4.2.2.1–4.2.2.5 — модели сведений приватного/публичного каналов (таблицы полей), процесс внесения (парсинг с лимитами, проверка существования и цепочки доверия через реестр аккредитации и сертификатов УЦ, криптопроверки, регистрация), предупреждения QCERT_*, ошибки ERR-0701…0728/0801…0805, статусная модель (события 0–3, причины, переходы), логическая отмена, фильтр, представления с учётом аккредитации издателя, идентификаторы (cert = validityNotBefore;hashTBS, _id).

  • 05 Изменение — ЧТЗ 4.2.3 (УНЭП): отличия от 4.2.2 подчёркнуты явно: каналы Госключ (issuer по CN), предупреждения UNQCERT_* с профилями ROOT_CA/SUB_CA/END_ENTITY, без проверки полномочий издателя по ОГРН и без проверки аккредитации, issuerOGRN может быть пустым; статусная модель — идентична 4.2.2.

  • 05 Изменение — ПМИ А.2: 12 проверок А.2.1–А.2.12 (создание записи, форматно-логический контроль, цепочка доверия и аккредитация, изменение статуса, логическая отмена, фильтр, наблюдение БГС, перенос в публичный канал, история/статус на дату/периоды — с аккредитацией); смысловые абзацы и места для уточнений — как в А.4.

  • 05 Изменение — ПМИ А.3: 12 проверок А.3.1–А.3.12, структура повторяет А.2, различия УНЭП указаны в каждой проверке (без аккредитации, goskey/unqual-эндпоинты, UNQCERT-предупреждения).

  • 05 Событие — замечания к источнику сведены в work/r2+3_Certificates/реестры_сертификатов_замечания.md: ownerType vs registration_json.owner_type (УНЭП), противоречие по аккредитации в алгоритмах УНЭП, разрядность _id (24/32 бита, сумма 80≠74), дубли номеров таблиц, опечатки, аннотации рецензента и пр. Заявка «Хронограф» (контракт № 071/25/125 от 27.12.2025) — источник номеров функций 4.2.2.1/5/7/11; номера пунктов заявки в черновиках — плейсхолдеры.

Ответ № 04 — Приложение А.5 (А.5.1 коллекция, А.5.2 формат отчёта), преамбула-переменные

  • 04 Изменение — структура ПМИ: коллекция Postman перенесена из «Приложения Б» в А.5.1 (новый раздел «А.5 Автоматизированное исполнение проверок»); формат отчёта — А.5.2 (файл А.М. ПМИ_РР_ОИОК_A52_отчёт.md перенумерован А.5.1.х→А.5.2.х и вставлен в md). Ссылки «см. [[ref:prilB]]» → «см. [[ref:a51]]» (18 шт.); приложения протокол/акт автоматически стали Б/В, текстовые ссылки обновлены. Преамбула А.5.1: предложение про status_before удалено; добавлен перечень переменных коллекции (host, mcc_port, iitaca_ogrn — стенд 45.131.40.89:8080, тестовый ОГРН 1027700067340; auth_token — заполняется перед прогоном; accreditationID — служебная).

  • 04 Изменение — А.5.2: в файл А.М. вставлены 18 записей вкладки Requests отчёта Bruno (декодирование base64 из r1/260915_bruno_report_АКК.html) в формате <details>: заголовок «путь — N/M Passed», таблицы REQUEST/RESPONSE INFORMATION, заголовки, тела (```json), ASSERTIONS (No Data), TESTS.

  • 04 Изменение — конвертер: (1) обработка <details>/<summary> (summary — полужирный абзац); (2) нумерация строк — только ПЕРВЫЙ код-блок (коллекция); для остальных — numId 0 (стиль RT_Code сам несёт нумерацию); (3) уровень нумерации приложений — по числу частей номера («А.5.2.1» → 4 уровня); (4) закладка a51 (А.5.1); (5) поиск страниц оглавления — ключ с АВТОБУКВОЙ приложения (не из текста md: «Приложение Б Форма протокола…» рендерится как Б, хотя в md — В) + keepLines (заголовки не разрываются страницами) + запасной поиск по тексту заголовка. Сборка v03: 91 стр., контроль зелёный, карточки без нумерации, оглавление сходится (протокол 89, акт 91).

Ответ № 03 — тип содержимого docx (untitled), глава Б.1, ЧТЗ 4.2.4 и ПМИ А.4 по ротации каналов

  • 03 Изменение — п.02.0: причина «untitled 1» — [Content_Types].xml объявлял /word/document.xml как «template.main+xml» (унаследовано от dotx): LO открывал файл как шаблон — безымянной копией. Исправлено: тип заменяется на «document.main+xml» при сборке + проверка в verify(). Сравнение с v02.docx подтвердило диагноз. v03.docx пересобран.

  • 03 Изменение — п.02.1: уточнение А.М. — нужна не аналитика, а глава ПМИ «Б.1 Формат отчёта по автоматизированному исполнению проверок» как она будет выглядеть внутри документа. Создан фрагмент work/ps01/ПМИ_РР_ОИОК_Б1_отчёт_draft.md (## Б.1, подразделы Б.1.1–Б.1.4; без аналитических комментариев).

  • 03 Изменение — п.02.2: нужна именно глава ЧТЗ 4.2.4. Создан фрагмент work/r4_serviceChainCode/ЧТЗ_ротация_каналов_4.2.4_v01_draft.md (4.2.4 + 4.2.4.1–4.2.4.5, таблицы 1–8). Убрана ссылка «источник — приложение к описанию решения» (ЧТЗ не ссылается на поздние документы — замечание А.М.); добавлено ограничение: ротация выполняется вручную. Полные черновики ЧТЗ/ПМИ удалены как устаревшие.

  • 03 Изменение — п.02.2 ПМИ: создан фрагмент work/r4_serviceChainCode/ПМИ_ротация_каналов_А.4_v01_draft.md — раздел А.4 с проверками А.4.1–А.4.14, без приложений Б/Б.1 (протокол — Приложение В, как в ПМИ РР ОИОК).

  • Требования зафиксированы в requirements.md: Т19 (флоу документов), Т20 (ротация вручную), Т21 (глава Б.1).

Ответ № 02 — целостность docx, вид ссылок, черновики по Bruno-отчёту и ротации каналов

  • 02 Изменение — п.0, целостность v03.docx: причина «untitled» и падений LO — нарушение порядка пакета OPC ([Content_Types].xml записывался не первой записью) и повреждённая структура поля оглавления (30 незакрытых w:p — LO молча отбрасывал). Исправлено: [Content_Types].xml — первой записью; все части пакета (core/app/styles/rels/Content_Types) проверены expat; стресс-контроль: 3 прогона LO→PDF без ошибок, 46 страниц. Номера страниц оглавления теперь сходятся итерационно (2 итерации) и совпадают с финальным PDF.

  • 02 Изменение — п.0, вид ссылок: «см. Приложение Б» и «поз. N» оформлены стилем Hyperlink (синие с подчёркиванием — как настоящие ссылки, без полей REF); в PDF 74 ссылки-аннотации. Неразрывные пробелы после «см./поз.» сохранены.

  • 02 Изменение — п.1: получен черновик главы «Формат отчёта по автоматизированному исполнению проверок» (docs-analyst по r1/260915_bruno_report_АКК.html) — передан А.М.; в документ не вставлялся.

  • 02 Событие — п.2: запущен docs-analyst по r4_serviceChainCode/Ротация каналов_260714.html — черновики ЧТЗ и ПМИ в md; идеи тестирования уточняются в диалоге.

  • 02 Изменение — п.2 (завершение): черновики сохранены: work/r4_serviceChainCode/ЧТЗ_ротация_каналов_v01_draft.md, ПМИ_ротация_каналов_v01_draft.md (14 проверок А.1.1–А.1.14, места для уточнений помечены), замечания — ротация_каналов_замечания.md (19 пунктов: отсутствие кодов ошибок и форматов запросов, расхождения типов активов и границы ротаций, RecordID, ключевая дата, схемы именования каналов и пр.).

Ответ № 01 — замечания по v03.docx и новые правила

  • 01 Изменение — п.1: метки ссылок «см. Приложение Б» и «поз. N» в финальной сборке присутствуют (18+18 гиперссылок с текстом); пустые поля («см. , поз. коллекции») были в промежуточной версии с полями REF \n — LO их не вычисляет и кэш отбрасывает, поэтому заменено гиперссылками-якорями.

  • 01 Изменение — п.2: оглавление возвращено к автозаполняемому: поле TOC \o "1-4" \h с кэшированными строками (номера страниц — вторым проходом LO→PDF). В Word видно сразу и обновляется F9; в LO поле показывается только после «Обновить указатель» (LO не показывает кэш импортированного автоуказателя — причина промежуточной смены подхода на статическое).

  • 01 Требование — п.3: столбцы таблиц сценариев «№ | Шаг | Ожидаемый результат» — 1 / 9 / 5,24 см. Попутно исправлен скрытый дефект: классификация шапки шла по уже размеченному XML, поэтому специальные ширины не применялись (таблицы шли равными долями). После правки: 10 таблиц сценариев — 567/5102/2971 dxa.

  • 01 Изменение — п.4: перед JSON-коллекцией Приложения Б добавлен абзац о переменной status_before (сохраняется ответ запроса «16 Статус на дату (действует)» — признак действия аккредитации для последующих проверок).

  • 01 Требование — п.5: ответы на наборы замечаний А.М. нумеруются сквозным номером по проекту (текущий ответ — 01).

  • 01 Изменение — п.6: правила ведения журнала обновлены А.М. — применяются с этой записи.

  • 01 Требование — п.7: значимые требования чата ведутся в /opt/pki/requirements.md (создан).

Событие — by-date на дату прекращения: стенд возвращает ERR-0602; ожидание запроса 17 исправлено

  • А.М. выполнил запрос 17 сценария (by-date?date='2025-04-15…') против стенда 45.131.40.89:8080: ответ — ошибка ERR-0602 «Нет действительных записей аккредитации до указанной даты» (chaincode response 500), а не признак «не действует».

  • Спецификация (r1, п. 9.4.2 «Получение сведений о статусе аккредитации УЦ на заданную дату»): метод должен возвращать {"Status": boolean}; код ERR-0602 в спецификации отсутствует (в т.ч. в Таблице 17 «Коды ошибок») — расхождение контракта и реализации стенда зафиксировано.

  • По сценарию на 2025-04-15 аккредитация прекращена (событие 2025-04-01) — «действительных записей» на эту дату нет; ошибка семантически согласуется со сценарием.

  • Исправлены: yml-сценарий (тест запроса 17: HTTP 500 + ERR-0602 в body.error), ПМИ v02+.md (А.1.7 шаг 2 и pm.test запроса 17 в Приложении Б). Историчность проверяется парой запросов: 16 (2025-06-01 → «действует») и 17 (2025-04-15 → ERR-0602: отмена события 2025-05-02 не переписала прошлое).

  • Примечание: URL в curl А.М. содержал двойное кодирование (%2527 вместо %27) — следствие encodeUrl: true в клиенте (Bruno); на результат не повлияло: дата распарсилась корректно (пришла доменная ошибка, а не ошибка формата даты).

  • Подтверждено прогоном А.М. на стенде: запрос 17 проходит (Post-Response Tests 2/2: HTTP 500 + ERR-0602).

  • Решение А.М.: запрос 17 перепрофилирован — «Все события истории аккредитации по ОГРН УЦ» (GET /ca/{ogrn}/accreditation); проверка по числу записей (5) и признаку isCanceled у отменённого события. Фактический ответ стенда — массив из 5 записей без обёртки «accreditations» (в спецификации 9.2.2 — обёртка).

  • Арифметика событий сходится на 5: создание (v1), приостановление (v2), возобновление (v3), прекращение (v4), аннулирование (v5, отменено). Отмена не создаёт новую версию: по сценариям п. 8.3 спецификации она выставляет isCanceled=True у последнего события (пример метода 8.3 с «version»: 6 вводит в заблуждение). Запросы 12 и 14 отклонены — событий не создают.

  • Наблюдения по выгрузке истории: у отменённого события accreditationReason перезаписан на «отмена …», updatedAt очищен (пустая строка), canceledAt = фактическое время обработки (2026-09-14T19:18:14Z), а не переданное в запросе 2025-05-02 — расхождение с описанием поля canceledAt метода 8.3.

  • Решение А.М.: запрос 16 проверяет признак «действует» на дату 2025-03-01 (дата возобновления) — подтверждено прогоном на стенде. В md вставлены смысловые абзацы перед таблицами А.1.1–А.1.10 с учётом фактической семантики (отменяется последнее событие цепочки — аннулирование; аккредитации возвращается статус «прекращена»).

  • Решение А.М.: обновлённый текст work/ps01/ПМИ_РР_ОИОК_v02+.md станет следующей версией документа — v03. Пересборка ODT — по отдельному указанию.

  • Решения А.М.: заголовок А.1.7 покрывает две функции («…получения статуса аккредитации на заданную дату и истории аккредитации»); запрос 18 — выборка по фильтру со статусом «2» (прекращена). Правки внесены в md (А.1.7: заголовок; А.1.8: шаг; Приложение Б: raw и path запроса 18 — status=2).

  • А.М. предложил попробовать formats/чтз&пми.dotx (Word-шаблон) — «может, будет послушнее». Эксперимент: из dotx собран минимальный DOCX (заголовки, приложения, маркеры, код, таблица, поле TOC). Результат через LO→PDF: нумерация применяется САМИМИ стилями (RT_Заголовок_1/2/3 → «1», «1.1», «1.1.1»; RT_Заголовок1_прил/3_прил → «Приложение А», «А.1.1»; RT_Code → «1., 2.»), без text:list/каркасов/continue-list. В dotx те же RT_*-стили, что в ott; нумерация — numId 11 (разделы), 12 (приложения), 13 (маркеры) в word/numbering.xml. Выходной формат — DOCX. Решение о переходе конвейера на dotx/DOCX — за А.М.

  • Решение А.М.: v03 собирается из dotx (выход DOCX). Написан work/ib/md2docx.py (генерация word/document.xml поверх dotx; нумерация — стилями + явные numPr/outlineLvl; таблицы — по образцу шаблона; «см./поз.» — гиперссылки-якоря с текстом, вычисленным при сборке; оглавление — статические абзацы с номерами страниц, заполняемыми вторым проходом LO→PDF). Собран /opt/pki/work/ps01/ПМИ_РР_ОИОК_v03.docx (47 стр.) + контрольный PDF. Проверки зелёные: XML валиден; закладки 22/22 (id уникальны); «Error!» нет; нумерация «1/1.1/А.1.7/Приложение Б–Г» корректна; «поз. 808/851/894» на месте; оглавление с номерами страниц.

  • Опытные находки конвейера docx: (1) поле REF \n LO не вычисляет и отбрасывает кэшированный результат — заменено гиперссылками-якорями; (2) поле TOC LO «съедает» кэш до обновления указателя — оглавление сделано статическим (перегенерируется при каждой пересборке); (3) голые w:t без обёртки w:r LO игнорирует.

2026-09-14

Событие — md2odt: исправлен continue-list; выпущен ПМИ_РР_ОИОК_v03.odt

  • Четвёртый дефект конвертера: после код-блока (список другого стиля) text:continue-numbering у форм приложений не срабатывает — LO перезапускает нумерацию («Форма протокола» шла как «Приложение А» вместо «В»). Подтверждено минимальным тестом; решение по образцу ott: text:continue-list на последний список того же стиля (все списки нумерации получают уникальные xml:id, конвертер отслеживает последний выданный список и его стиль; следующий код-блок тоже продолжает нумерацию строк через continue-list).

  • Решение А.М.: официальный v02 не пересобирать — выпустить следующую версию. Собран и проверен **/opt/pki/ПМИ\_РР\_ОИОК\_v03.odt** (текст v02.md без изменений, конвертер исправлен) + текстовая копия v03.txt. Контроль (PDF через LO): нумерация 1–7, 3.1–3.5, А.1–А.1.10, А.2–А.4, «Приложение Б/В/Г», «поз. N» — без дефектов; «Error: Reference source not found» нет; XML валиден; ссылки 19↔22 закладки.

  • Также пересобран work/ps01/ПМИ_РР_ОИОК_v02+.odt (переработанный tech-writer текст, та же проверка — без дефектов) — кандидат для следующей версии.

Событие — md2odt: 3 дефекта найдены; Регламент 2.0 проверен — ключевая предпосылка не подтвердилась

  • Сборка ODT из ПМИ_РР_ОИОК_v02+.md вскрыла 3 дефекта md2odt.py (правки 16:36–16:38 остались непроверенными — та сессия оборвалась по лимиту контекста): (1) heading(): дубликат уровня в стеке при sibling-заголовках (st.append(L) безусловно) → невалидный XML — исправлено; (2) при переоткрытии списка после таблицы заголовок уровня 2+ становился пунктом уровня 1 (А.1.1… отрисовывались как «Приложение Б…») — исправлено каркасом пустых пунктов уровней 1..L-1 по образцу ott; (3) убранный в 16:38 flush перед код-блоком возвращён: код-блок — список верхнего уровня (в ott: continue-list Numbering_20_123), иначе ссылки «поз. N» показывают «2.N».

  • Обнаружено: сданный /opt/pki/ПМИ_РР_ОИОК_v02.odt (собран до этих правок) отрисовывает проверки А.1.1+ как «Приложение Г…» — дефект нумерации в официальном файле.

  • Получен exchange/postanovka-konveyer-md-odt_04.md — Регламент 2.0 конвейера «Markdown → ODT» (А.М.: «можно пробовать»). Проверена ключевая предпосылка («не оборачивать заголовки в text:list — нумерация заложена в style:list-style-name самих стилей»): RT_Заголовок_1/2/_прил действительно несут style:list-style-name, но минимальный тест в LO показал: голые text:h без text:list не нумеруются. Рабочий путь — text:list (исправленный). Прочие пункты регламента согласуются с ott (единый стиль оглавления RT_Contents1-2-3-4; RT_Tab01.1–16; &#160;; закладки обёрткой текста); неточности регламента: table:template-name в ott есть (так сохраняет сам LO), RT_Заголовок_3 — без default-outline.

2026-09-08

Событие — пересинхронизация pki.db: эталоны ЧТЗ (95%) и ПМИ (90%) в базе

  • Разбор ПМИ завершён: +22 записи (1.19–1.23, 2.29–2.37, 3.11–3.12, 4.13–4.14, 5.16–5.19), +12 правил (46–57); итого RAG.md — 104 записи, 57 правил; отчёт work/corpus/pmi-epgu-analiz.md (трассировка А.1–А.33 ↔ ЧТЗ 4.2.x ↔ SCR# сходится 1:1).

  • pki.db пересинхронизирована: documents 6 (chtz-epgu 0.95, pmi-epgu 0.9), entries 104, rules 57, doc_chunks 704 (ЧТЗ 302, ПМИ 252); эмбеддинги 865/865 (порциями; у скрипта pki-db-embed.py добавлена устойчивость: повтор батча + по-одному).

  • Контрольные поиски (отчёт exchange/pki-db-kontrolnyj-otchet.md, дополнение 08.09): Т01 → ЧТЗ «КСКПЭП pp518–pp551» rank 0.385 (вес 0.95 работает); ПМИ-жанр → ПМИ доминирует; записи ПМИ определяются корректно (source_doc=pmi-epgu).

  • Зафиксирован косметический дефект RAG.md: пропуск заголовка «### 2.15» (не перенумеровывался — сохранить ссылки журнала/отчётов).

Событие — разбор ЧТЗ ЕПГУ завершён: RAG.md пополнена, отчёт готов

  • Агент docs-analyst (глубина=детальная) разобрал ЧТЗ ЕПГУ (текст ..._ЧТЗ_текст.txt, p1–p13497): +24 записи (1.11–1.18, 2.21–2.28, 3.9–3.10, 4.10–4.12, 5.13–5.15), +9 правил (37–45), 6 существующих записей дополнены цитатами ЧТЗ; итого RAG.md — 82 записи, 45 правил; раздел 0 дополнен источником (п. 3).

  • Отчёт work/corpus/chtz-epgu-analiz.md: композиция ЧТЗ с pNNN-якорями (в т. ч. таблица блоков 4.2.x → заявка SCR#), выводы «что перенимать для будущего ЧТЗ по PKI» (макет ЧТЗ, делегирование разделов в ТЗ, блок «заявка SCR# → триада → детализация», негативные границы, статусные рамки, готовую PKI-лексику блоков 4.2.14/4.2.19/4.2.20 — КСКПЭП, УЦ Казначейства России, МЧД, ДУЛ, метка времени) и «чего избегать»; замечания: отсутствуют ссылки на ГОСТ/НПА, процедурные сроки, критерии приёмки, матрицы статусов; особенности выгрузки (8208 табличных абзацев, утрата нумерации заголовков, обрыв Приложения А).

  • ПМИ-разбор запущен следом (в очереди был; RAG.md редактируется одним агентом за раз). После его завершения — пересинхронизация pki.db (documents: chtz-epgu 0.95, pmi-epgu 0.9; чанки обоих; переразбор RAG.md; эмбеддинги порциями).

2026-09-14

Событие — tech-writer переработал ПМИ_РР_ОИОК v02 с опорой на RAG-базу

  • Агентом tech-writer выполнен первый прогон: work/ps01/ПМИ_РР_ОИОК_v02.md → work/ps01/ПМИ_РР_ОИОК_v02+.md (структура сохранена дословно: заголовки, нумерация ИЭП-…/А.1.x, ERR-коды, маркеры [[ref:…]]; Приложение Б — JSON-коллекция побайтово, изменён только вводный абзац) + отчёт work/ps01/ПМИ_РР_ОИОК_v02_report.md.

  • Итог: 44 формулировки в 23 позициях (язык — по эталону ПМИ ЕПГУ и правилам RAG, привязки к entry/rule/doc-chunk с d — в отчёте); раскрыто 9 неясностей (в т. ч. снято противоречие «проверены на предыдущих этапах» ↔ п. 3.4, согласован объём «пп. 4.2.1–4.2.4 ЧТЗ» с таблицей 1, убрана мета-оговорка про IP-адрес); 5 позиций «требует уточнения» (пустые А.2–А.4 до наполнения ЧТЗ, «Содержание», глоссарий УКЭП/УНЭП, реквизиты, таблица результатов Приложения В).

  • Проверка выполнена: заголовки идентичны, diff — 80 строк (40 пар), JSON-блок совпадает.

2026-09-07

Решение — ПМИ ЕПГУ: эталон, вес 90% (А.М., 2026-09-07, переформулировано)

  • Второй документ очереди: /mnt/d/a/pki/examples/language/ГКР_ИЭП_2025_5_ЕПГУ_ОП2_ПМИ_предв_исп.html — «Программа и методика предварительных испытаний ЕПГУ», эталон ПМИ, вес 90%. Работа напрямую с источником, цель — обогащение RAG-базы.

  • Текст извлечён серверным python: 9 806 абзацев, 240 заголовков → /opt/pki/examples/language/ГКР_ИЭП_2025_5_ЕПГУ_ОП2_ПМИ_предв_исп_текст.txt (id pNNN).

  • Разбор ПМИ — в очереди за разбором ЧТЗ (двум агентам одновременно писать в RAG.md нельзя).

Решение — ЧТЗ ЕПГУ: эталон, вес 95%; работа напрямую с источником (А.М., 2026-09-07, переформулировано)

  • Новый документ-пример: /mnt/d/a/pki/examples/language/ГКР_ИЭП-2025-5_ЕПГУ_ОП2_ЧТЗ.html (ЧТЗ ЕПГУ, шифр ИЭП-2025-5.ЕПГУ.2ОП.ЧТЗ; 113 МБ Word-HTML, 326 картинок, текст ~643 тыс. знаков). Работать напрямую с источником (не копировать в /opt/pki); цель — обогащение RAG-базы языка.

  • Документ — эталон по текстовке и структуре для будущего ЧТЗ (по PKI), вес 95% — самый ценный пример жанра.

  • А.М. готовит эталон ПМИ (программа и методика испытаний) — связанный документ; поступит позже.

Событие — из ЧТЗ ЕПГУ извлечён текст; разбор поручен docs-analyst

  • Серверным python из HTML извлечён текст: 13 497 абзацев, 468 заголовков (эвристика: нумерация/прописные), формат строк pNNN<TAB>[## ]текст[<TAB>[таблица]] — файл /opt/pki/examples/language/ГКР_ИЭП-2025-5_ЕПГУ_ОП2_ЧТЗ_текст.txt (821 КБ), доступен агенту (newuser) и серверу. Абзацные id pNNN — для цитирования в RAG.md.

  • Запущен разбор docs-analyst: пополнение RAG.md (разделы 1–5 + правила 6, дословные цитаты с pNNN, источник — файл текста) и отчёт work/corpus/chtz-epgu-analiz.md. После — пересинхронизация pki.db (documents += ЧТЗ, weight 0.95).

Событие — этап 6 завершён: документы-примеры проиндексированы, эмбеддинги doc_chunks восстановлены

  • Веса (подтверждены А.М.): 1443 = 0.8 (жанр постановления — не ТЗ/ПМИ), ТЗ АИС КУП = 0.4, Концепции РР (обе редакции) = 0.6; ТЗ индексируются только содержательные разделы (Приложение No1: 1.4–10.4; Приложение No3: атрибуты карточки закупки; No2 — отдельный файл регламента, в примерах отсутствует).

  • 150 чанков doc_chunks (1443=35, ТЗ=28+7, Концепции=47+33) переэмбеддированы рабочим способом. Контроль: запрос по Т01 (сертификаты/УЦ) → топ-1 Концепция ред. 2, d=0.251 (rank с весом 0.418); «борщ» → d≥0.65; порог отсечения d<0.6 подтверждён.

  • Уточнение к обходному пути: vec_f32(:v) с JSON-текстом в binding тоже не работает в этой сборке («SQLite JSON parsing error»). Окончательный рабочий способ — work/pki-db-embed.py: батч qwen_embedding_0_6b через python-мост → struct.pack('<1024f') → BLOB-литерал X'…' (проверено: vec_length/vec_distance_cosine считают корректно). При пересинхронизации запускать в паре: pki-db-sync.py (тексты) + pki-db-embed.py (эмбеддинги).

Событие — статус pki.db: чанки загружены, эмбеддинги ждут перегенерации; MCP-подключение пропало

  • Векторная база /mnt/d/mcp/rag/pki.db в актуальном состоянии: entries (58, эмбеддинги рабочие), rules (36, рабочие), doc_chunks (150, эмбеддинги NULL — сброшены для перегенерации).

  • Выявлен дефект сервера mcp-link: generate_embedding() внутри SQL-запроса возвращает мусор вместо float32-вектора (воспроизводится прямым вызовом; причины не установлены). Рабочий обходной путь — генерация через инструмент qwen_embedding_0_6b (батч texts) и запись через vec_f32(:v) с JSON-текстом массива в binding; скрипт готов: work/pki-db-embed.py (embed_table('doc_chunks', 'chunk_text')), запускается python-инструментом сервера. Первая попытка упала на типе binding (list → нужен json.dumps), после исправления серверные инструменты стали недоступны из сессии.

  • Статус на 2026-09-07: процесс сервера жив (PID 65883, sander), но сессия Claude потеряла MCP-подключение (все инструменты mcp__mcp-link__* недоступны). Для продолжения нужно восстановить MCP-конфигурацию сессии и выполнить pki-db-embed.py.

2026-09-05

Событие — векторная база pki.db создана и загружена; контрольные поиски пройдены

  • База /mnt/d/mcp/rag/pki.db: таблицы documents/doc_chunks/entries/rules/meta; загружены 58 записей и 36 правил из RAG.md (парсинг и загрузка — python-инструментом сервера mcp-link, без прогонки данных через контекст), сгенерировано 94 эмбеддинга локальной моделью.

  • Контрольные поиски (отчёт exchange/pki-db-kontrolnyj-otchet.md): по языковым запросам точность высокая (d=0.35–0.46), «пустой» запрос отделяется (d≥0.67); предложен порог отсечения d<0.6. Тематики сертификатов УЦ в базе нет (документы-примеры не про УЦ) — ожидаемо.

  • Осталось: подтверждение весов документов и индексация самих документов-примеров (doc_chunks, этап 6 плана exchange/pki-rag-db-plan.md).

Решение — ответы А.М. на вопросы плана pki.db (2026-09-05, переформулировано)

  • База размещается в /mnt/d/mcp/rag/pki.db (каталог rag/ создан А.М.; проверен: пуст, серверу доступен); имя файла — pki.db.

  • FTS5-гибрид пока не делать (векторного поиска достаточно).

  • Индексировать и сами документы-примеры (не только RAG.md): «разные документы имеют разный вес (некоторые — откровенно слабые примеры жанра), поэтому RAG должен улавливать, что более ценно» — в схеме documents (вес) и doc_chunks (фрагменты); вес наследуется записями и участвует в ранжировании (d / weight).

Событие — подготовлен план векторной базы pki-rag.db (семантический поиск по RAG-базе)

  • В сессии изучены MCP-инструменты сервера mcp-link: qwen_embedding_0_6b (локальная модель Qwen3-Embedding-0.6B, 1024-мерные эмбеддинги; модель уже в кэше HuggingFace пользователя sander, ревизия совпадает с закреплённой — скачивание не требуется; загружена в видеопамять GPU MX150, ~60% из 2 ГБ — штатно) и sqlite (SQLite с векторными функциями vec_f32/vec_distance_cosine и встроенной генерацией эмбеддингов generate_embedding).

  • Составлен план exchange/pki-rag-db-plan.md (статус: на согласовании): схема таблиц entries/rules/meta под записи RAG.md, порядок загрузки (bulk_insert + UPDATE generate_embedding), правила пересинхронизации при пополнении RAG.md, контрольные поиски, изоляция проекта отдельным файлом БД. Открытые вопросы к А.М. — в разделе 9 плана (каталог, имя файла, FTS5, индексация документов-примеров).

2026-09-03

Событие — разбор второго документа-примера: ТЗ АИС КУП (вес 40%)

  • В examples/language/ предоставлен ТЗ АИС КУП_NEW.md (3123 строки) — техническое задание на услуги по созданию автоматизированной информационной системы (заказчик — ПАО «Ростелеком»), вес примера 40%. Анализ — агент docs-analyst (глубина=детальная).

  • Отчёт work/corpus/tz-ais-kup-analiz.md: сводка + разбор приёмов построения описаний предметной области (композиция ТЗ, конструкции «что система должна», взаимодействия с внешними системами, акторы/статусные модели/правила, объекты предметной области, табличные приёмы, выводы «что перенимать / чего избегать» для целевого документа по PKI) + замечания о дефектах документа (битые перекрёстные ссылки, нумерационные дефекты, дублирование нормативного содержания, пробелы трассируемости).

  • RAG-база examples/language/RAG.md пополнена: +10 записей (1.10, 2.15–2.20, 3.8, 4.9, 5.11–5.12), +8 правил (29–36), итого 58 записей и 36 правил; список источников в разделе 0 дополнен.

Событие — шаг 2 стартовал: анализ Постановления № 1443, создана RAG-база языка

  • В examples/language/ предоставлены: 20250922_Постановление_1443.pdf (11 стр., текстового слоя нет — только изображения) и локальная копия страницы официального опубликования 250919_1443.html + 250919_1443_files/content.html. Документ: Постановление Правительства РФ от 19.09.2025 № 1443 о применении мобильного приложения Единого портала госуслуг для представления сведений из документов, удостоверяющих личность.

  • Первая попытка анализа через OCR остановлена пользователем (нужен анализ текста, а не распознавание). Сеть из среды не пускает к pravo.gov.ru (WebFetch отклонён, curl — HTTP:000), поэтому текст взят из локальной HTML-копии опубликования.

  • Создана examples/language/RAG.md — база лексических приёмов и правил (первый документ): 7 разделов (0 — назначение и правила ведения, 1–5 — приёмы по категориям, 6 — 28 правил-выводов), 48 записей по шаблону «Формула → Примеры (дословные цитаты с пунктами) → Источник → Употребление». Анализ выполнял агент docs-analyst.

Решение — порядок пополнения RAG-базы языка

examples/language/RAG.md — пополняемая база знаний о языке нормативных документов (RAG-принцип: retrieval по шаблону записей + генерация по формулам). При каждом новом документе-примере (шаг 2) docs-analyst получает её через параметр примеры=/opt/pki/examples/language/, добавляет записи и новые источники к существующим, базу не переписывает. Приёмы и правила разделены; чего в документе нет — в базу не включается (в отчёте агента — блок «Замечания»).

Событие — заведён реестр требований и внесено требование Т01

Создан requirements.md — реестр требований к конечному результату работ (цели конечной работы), в отличие от history.md — журнала текущих шагов, проб и достижений. Внесено требование Т01 (источник: Д.С.) — см. requirements.md.

2026-09-02

Требование — сравнение редакций Концепции и приоритеты в INDEX (А.М., 2026-09-02)

Исходный текст (дословно): «сравнить оба файла и выделить — чем именно характерно отличается второй документ от первого. Этот анализ положить в базу знаний, как пример — так в целевой среде развиваются и обогащаются тексты. после сравнения можно обогатить INDEX — второй документ является более высокоприоритетным приоритет=50 (но элементы первого документа должны в Индексе быть упомянуты, с атрибутом "приоритет", например = 15)»

Решение — значения приоритетов (переформулировано из требования)

  • редакция 2 (Концепция_создания_РР_23_10_2025x.html, утверждённая) — приоритет 50;

  • редакция 1 (Концепция_создания_РР_17_07_25_f+МЧ.html, рабочая) — элементы упомянуты с приоритетом 15.

Событие — материал для шага 1: вторая редакция Концепции

В examples/ предоставлен файл Концепция_создания_РР_23_10_2025x.html (23.10.2025, гриф «УТВЕРЖДЕНО», Москва, 2025 г.) — «Концепция совершенствования пространства взаимного доверия в сфере использования усиленной электронной подписи». В файле осталась одна аннотация А.М. от 27.03.2026.

Событие — созданы артефакты шага 1

  • work/corpus/koncepciya-rr-17-07-25-vs-23-10-2025.md — сравнительный анализ редакций: таблица соответствия разделов, 10 характерных отличий, вывод о приёмах эволюции текста (по требованию — «в базу знаний, как пример»);

  • work/index/INDEX.md — INDEX по обеим редакциям: дерево разделов с якорями на HTML, карты сущностей/акторов/процессов, выжимка ключевых положений, блок замечаний, трассируемость; все элементы с атрибутом «приоритет» (50/15);

  • work/glossary.md — единый глоссарий: термины раздела 2 редакции 2 (приоритет 50) и заменённые термины редакции 1 (приоритет 15).

Проверено: 48 ссылок-якорей INDEX на HTML-файлы валидны. Следующий шаг — рецензия А.М. на INDEX (контрольная точка после шага 1).

Требование — план работ по теме PKI (утверждён А.М. 2026-09-02)

Исходный план (дословно):

  1. сделать анализ документа Концепция_создания_РР_17_07_25_f+МЧ и сформировать по нему INDEX (этот документ будет отправным для развития темы pki)

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

  3. изучение и индексация целевого формата: А) Требований Б) ПМИ (программы и методики испытаний)

  4. пробные формирования (фрагментов) требований и ПМИ по pki

  5. получение целевого документа

Согласованные дополнения (предложены Claude, приняты А.М. 2026-09-02):

  • шаг 1 — INDEX: дерево разделов с якорями на исходный HTML, карта сущностей/акторов/процессов, выжимка ключевых положений, блок замечаний;

  • точки рецензии А.М.: после INDEX (шаг 1), после утверждения формата (шаг 3), после пробных фрагментов (шаг 4), финальная (шаг 5);

  • контрольная точка: материалы для шагов 2–3 (документы схожих областей, образцы формата требований и ПМИ) предоставляет А.М. поэтапно;

  • сквозные правила: трассируемость «пункт целевого документа → раздел INDEX/Концепции»; единый глоссарий work/glossary.md; все решения и события фиксировать в этом журнале.

Решение — структура каталогов артефактов

  • work/index/ — INDEX по Концепции (шаг 1);

  • work/corpus/ — разборы документов-примеров (шаг 2);

  • work/formats/ — описания целевого формата: требования, ПМИ (шаг 3);

  • work/drafts/ — пробные фрагменты требований и ПМИ (шаг 4);

  • work/target/ — целевой документ (шаг 5);

  • work/glossary.md — единый глоссарий.

Решение — порядок предоставления материалов

Материалы для шагов 2–3 (документы схожих областей, образцы формата требований и ПМИ) предоставляет А.М. поэтапно. Шаги 2–3 не начинаются до получения соответствующих материалов.

Событие — получено описание решения PS-01; анализ и структуры ЧТЗ/ПМИ (2026-09-08)

  • А.М. передал описание решения по работе «Функция регистрации в распределённых реестрах данных об аккредитации УЦ»: PS-01_RegisterOfAccreditation.html (2,2 МБ — 27 PNG встроены в HTML) + PS-01_RegisterOfAccreditation_Diagrams_01.md (PlantUML-диаграммы). Текст извлечён в work/ps01/PS-01_описание_решения_текст.txt (65 323 знака). Снимок r1/ (02.09) меньше нового экспорта — за эталон принят переданный файл.

  • Решения А.М. 2026-09-08 (через опрос): ЧТЗ — «второй уровень» как эталон ЕПГУ (общие разделы делегируются базовому ТЗ, ядро — 4.2); критерий проверок ПМИ — только столбец «Ожидаемый результат»; внутренние противоречия решения — реестр замечаний с решениями А.М. до начала наполнения.

  • Артефакты: work/ps01/analiz-opisaniya-resheniya.md (4 модели данных, 10 REST-методов, статусная модель, сервисный чейнкод, 16 замечаний); work/ps01/reestr-zamechaniy.md (реестр с колонкой решений А.М.); work/ps01/struktury-chtz-pmi.md (согласованные структуры: 13 блоков 4.2 ↔ методики А.1–А.13, шаблоны блоков и методик).

  • Правило проекта: описание решения — 100 % источник истины; ЧТЗ/ПМИ соответствуют ему полностью, ничего не добавляют и не противоречат. Трассировка: пункт решения → блок ЧТЗ 4.2.N → методика ПМИ А.N → сценарий → шаг → ожидаемый результат.

  • Доступ: /home/sander и /mnt/d для сессии закрыты (sander:mussel_colony); файлы достаются через MCP-инструменты (fs/python от sander) и кладутся в /opt/pki.

Событие — приняты документы ИБ; сформирована полная ПМИ по ИБ (2026-09-08)

  • Уточнение А.М. по структуре ЧТЗ: идеальная цепочка документов — ТЗ → Описание решения → ПМИ; на момент создания описания решения ТЗ отсутствовало и составляется методом реверс-инжиниринга. Поэтому формула блока ЧТЗ — не ссылка на описание решения, а «Работы выполняются в соответствии с <пунктом ИЭП-1/4.2.1.1/АКК Заявки>» (пример для ЧТЗ по реестру аккредитации). Внесено в work/ps01/struktury-chtz-pmi.md (решение № 5, шаблон блока, трассировка).

  • Приняты документы ИБ: examples/language/00_infobez.html — ТЗ на инфобез (Приложение № 3 к Соглашению, АО «РТ Лабс»; эскиз; веса: 30 % язык / 60 % смысл); r1/ARCHIVES-133.html — описание решения по ИБ (выгрузка трекера, тикет от 25.05.2026, 22 функции/задачи; веса: 15 % язык / 90 % смысл).

  • Решения А.М. 2026-09-08 (опрос): нумерация НФТ — по разделам документа (раздел 1 — пп. 1.1–1.11; раздел 2 — пп. 2.1–2.27, CSRF = 2.15, HPP = 2.17; раздел 3 — пп. 3.1–3.8 с подпунктами); ПМИ — 5 методик по темам (CSRF, HPP, регистрация событий, состав полей, хранение), 22 проверки по функциям; индексация pki.db — отложена (работаем только с файлами).

  • Артефакты work/ib/: извлечения (00_infobez_нумерация.txt, ARCHIVES-133_структура.txt, ARCHIVES-133_детально.txt) и полная ПМИ ПМИ_ИБ_приёмочные_испытания.md: разделы 1–7 + Приложения А–В; Таблица 1 — индекс НФТ; Таблица 2 — трассировка «методика ↔ функции описания решения ↔ НФТ»; каждый шаг сценария помечен «НФТ п. N» либо «Служебный»; имена сотрудников из «Активности» трекера в ПМИ не включались.

Событие — «Описание решений по ИБ» собрано, оба документа экспортированы в Word (2026-09-08)

  • Из ARCHIVES-133 собрано «Описание решений по ИБ» (work/ib/Описание_решений_по_ИБ.md): удалены все атрибуты трекера (Активность/переписка, фамилии, даты, история, блоки «Связанные задачи» с таблицами ARCHIVES-XXX, служебные страницы экспорта 134/144/153/158), сохранён индекс задач — 22 блока в 5 тематических разделах (нумерация 1.1–5.2, соответствует методикам ПМИ А.1–А.5), включая «Требование», «Описание проблемы», «Контекст кода», «Задачи» с «Как решает проблему»/«Что делать» и код-блоками. Контроль: 0 вхождений ARCHIVES / «Активность» / фамилий.

  • В ПМИ_ИБ_приёмочные_испытания.md все вхождения ARCHIVES-133 заменены на «Описание решений по ИБ» (аннотация, термины, руководящие документы, формулы методик, формы).

  • Экспорт в MS Word (.docx) конвертером work/ib/md2docx.py (python-docx 1.2.0, установлен в сервер): Описание_решений_по_ИБ.docx (317 абзацев, 46 заголовков) и ПМИ_ИБ_приёмочные_испытания.docx (130 абзацев, 30 таблиц) в work/ib/.

Событие — решения по реестру замечаний PS-01 получены; начато наполнение ЧТЗ (2026-09-08)

  • А.М. заполнил реестр: work/ps01/reestr-zamechaniy_answers.md — решения по всем 16 пунктам + уточнённая схема UUID (3+3+1+1+3+13+24+80 = 128 бит, сходится).

  • Ключевые решения: ERR-0204 остаётся за accreditationValidUntil, для accreditationID — ERR-0304; Табл. 7 — набор subjectSite/subjectMail/subjectPhone/hSC; коды hSC — ERR-1102–1104; ERR-1001 включить в таблицу update-info; истина — статусная модель; статус на дату — boolean (True: актуальное событие с типом изменения 1 или 4; False: 2, 3, 5); ИНН — алгоритм ИНН; тип status — string (по OpenAPI), integer — только version; UUID — новая схема 128 бит; нормативен раздел 2 моделей (раздел 1 — логический); авторизация ГУЦ не регламентируется.

  • Начато наполнение ЧТЗ (work/ps01/ЧТЗ_реестр_аккредитации_УЦ.md): каркас (титул, аннотация, глоссарий-заготовка, делегирование разделов 1–3, 4.1, 4.3, 5–8 базовому ТЗ) + блок 4.2.1 «Структуры данных реестра аккредитованных УЦ» (4 записи, таблицы полей). Порядок: итерационная сверка с А.М. по блокам.

  • Конвертер work/ib/md2docx.py: добавлен язык документа ru-RU (w:lang на всех стилях); docx ИБ переэкспортированы с RU.

Событие — уточнение жанра: ЧТЗ первично; шаблоны ФТ/СТ из эталонов (2026-09-08)

  • Уточнение А.М.: ЧТЗ ставит задачи, а «Описание решения» на них отвечает; автор ЧТЗ не знает содержания будущего решения и не ссылается на него (обратное верно только для ПМИ/СТ). «Заявка» — отдельный документ, приложение к головному ТЗ; номер — ИЭП-1, текст по главе 2: «Функция регистрации в распределённых реестрах данных об аккредитации удостоверяющих центров».

  • Артефакт work/ps01/shablony-ft-st.md: (1) шаблон ФТ по ЧТЗ ЕПГУ 4.2.4 «Сервис семейных связей» (заявка → целевая модель → границы → требования к функциям → требования к реализации с таблицами атрибутов); (2) шаблон СТ по ПМИ ЕПГУ А.4 (методика → сценарий → предварительные условия → шаги «тип/актор/действие/ожидаемый результат» с альтернативными ветками «NА.1»); (3) корреляция ФТ↔СТ (1:1 заявка, функция↔сценарий, операция↔шаг, негатив↔альтернативный шаг, таблицы БД↔шаги проверки БД); (4) набор СТ-2.1…2.4 для проверки главы 2 Описания решения (со ссылками на пп. 2.1–2.4); (5) первичная формулировка задачи ЧТЗ для главы 2.

  • Блок 4.2.1 ЧТЗ переписан в первичной постановке: заголовок «Ведение сведений об удостоверяющих центрах и их аккредитации», привязка к заявке ИЭП-1, целевая модель, границы (сертификаты КПЭП не входят), 6 требований (записи УЦ/истории/аккредитации/истории аккредитации, контроли форматов, единый механизм идентификаторов) — без единой ссылки на Описание решения/ПМИ. Детальные таблицы полей из блока убраны.

  • Уточнения А.М. (опрос 2026-09-08): формула заявки — «ИЭП-1 + текст» (подтверждено); в блок 4.2.1 добавлен подраздел «Назначение работ» из Концепции РР 23.10.2025 (активы ИОК, проверка статуса аккредитации на любой момент в прошлом, признание действительности квалифицированных сертификатов/ЭП); СТ-2.1…2.4 переведены на «только наблюдение» БД — инструмент (например, DBeaver) и credentials в предусловиях, проверки а) структуры БД и б) выборки примера записи; вызовы методов глав 3–8 из СТ убраны.

Событие — устное требование Заказчика (ISO 8601 UTC); блок 4.2.2 (вторая заявка) наполнен (2026-09-09)

  • Устное требование Заказчика: «дат в формате ISO 8601» → «даты и времени в формате ISO 8601 UTC» — внесено в ЧТЗ (глоссарий, блок 4.2.1, блок 4.2.2) и СТ-2.2/2.3.

  • Структура заявок уточнена А.М.: блок 4.2.2 — заявка № ИЭП-1/4.2.1.11/АКК «Функция взаимодействия с внешними информационными системами в части получения и передачи данных об аккредитации удостоверяющих центров» (методы 3–8 решения + статусная модель 6.1); блок 4.2.3 — заявка № ИЭП-1/4.2.1.5/АКК «Функция формирования представления данных об аккредитации удостоверяющих центров» (к наполнению после проверки 4.2.2).

  • Блок 4.2.2 наполнен в первичной постановке (по шаблону ФТ): целевая модель (приём сведений от ГУЦ через REST API, контроли, защита от повторов), границы, 6 требований к функциям (регистрация, изменение, дополнение, создание аккредитации, изменение статуса, отмена события) и статусная модель (5 состояний, допустимые переходы, отклонение недопустимых). Без ссылок на Описание решения/ПМИ.

  • Образец качества ответа (формулировки первичной постановки + шаблоны ФТ/СТ) одобрен А.М. («это было супер») — сохранён в память как эталон для последующих блоков.

Событие — блок 4.2.2 дополнен «Назначением работ» и обоснованиями методов (2026-09-09)

  • По замечанию А.М. в блок 4.2.2 добавлены: «Назначение работ» (4 строки из Концепции РР 23.10.2025 и 63-ФЗ: оператор ИС ГУЦ — ФОИВ, статусы аккредитации — активы ИОК, фиксация событий жизненного цикла, ст. 11 63-ФЗ, контроль (надзор) и выявление нарушений процессов изменения статуса) и «Обоснование:» по 1–2 строки на каждый из 6 методов (сценарии: постановка на учёт, изменение реквизитов, дополнение сведений, предоставление аккредитации → КСКПЭП, приостановление/возобновление/прекращение/аннулирование, отмена ошибочного события).

  • Шаблон ФТ (shablony-ft-st.md) дополнен элементами «Назначение работ» и «Обоснование:» — все последующие блоки пишутся с ними.

  • Правки А.М. по 4.2.2 (2026-09-09): из «Назначения работ» убрано «включая выявление нарушений процессов изменения статуса»; обоснование метода регистрации дополнено «Допускается первичная постановка УЦ на учёт в реестре, с неполными данными и их последующим обогащением»; перед каждым «Обоснование:» — пустая строка (md); введён термин «форматно-логический контроль поступающих данных» (применён в 4.2.1 п. 5 и 4.2.2 п. 1; внесён в память).

Событие — стандарт дат уточнён (RFC 3339); блок 4.2.3 (третья заявка) наполнен (2026-09-09)

  • Уточнение Заказчика: даты и время — RFC 3339, UTC, без долей секунды (ISO 8601 — ошибочно). Внесено в ЧТЗ (глоссарий, 4.2.1 п. 5), шаблоны СТ-2.2/2.3, ПМИ ИБ (А.4.1), память.

  • Блок 4.2.3 «Функция формирования представления данных об аккредитации удостоверяющих центров» (заявка № ИЭП-1/4.2.1.5/АКК) наполнен в первичной постановке: назначение работ (ст. 11 63-ФЗ, контроль (надзор)), целевая модель (REST API представления), границы (только чтение; сертификаты КПЭП не входят), 4 требования с обоснованиями (история, периоды действия, статус на дату — признак действует/не действует, выборка по фильтрам с открытыми границами). Сервисный чейнкод исключён — будет описан в другом ЧТЗ (решение А.М.).

  • Правило работы (А.М.): при отклонении от задания — уточнять, не решать молча; текст в кавычках задания — не модифицировать; нескладный текст — уточнять, молча не менять. Внесено в память.

Событие — ПМИ по реестру аккредитации УЦ сформирована (2026-09-09)

  • Документ work/ps01/ПМИ_реестр_аккредитации_УЦ.md: разделы 1–7 + Приложения А–В. Таблица 1 — трассировка «методика ↔ пункт ЧТЗ ↔ заявка»: А.1 ↔ 4.2.1 / № ИЭП-1; А.2 ↔ 4.2.2 / № ИЭП-1/4.2.1.11/АКК; А.3 ↔ 4.2.3 / № ИЭП-1/4.2.1.5/АКК.

  • А.1 — 4 проверки моделей данных (наблюдение БД: DBeaver, credentials; перенос СТ-2.1…2.4); А.2 — 7 проверок заявки 4.2.1.11/АКК (регистрация, изменение, дополнение, создание аккредитации, изменение статуса, статусная модель — все допустимые и недопустимые переходы, отмена события; негативы по кодам ошибок решения с учётом реестра замечаний); А.3 — 4 проверки заявки 4.2.1.5/АКК (история с упорядочением, периоды с учётом отмен, статус на дату «действует/не действует», фильтры с открытыми границами).

  • Критерий — столбец «Ожидаемый результат» (решение А.М.); даты — RFC 3339 (UTC, без долей секунды); формы протокола и акта — по эталону ЕПГУ.

Событие — уточнения А.М. по ЧТЗ/ПМИ и индексация ТЗ (2026-09-10)

  • Заявки: документ № ИЭП-1; индексы работ: ИЭП-1/4.2.1.1/АКК, ИЭП-1/4.2.1.5/АКК, ИЭП-1/4.2.1.11/АКК (↔ ТЗ пп. 4.2.1.1, 4.2.1.5, 4.2.1.11). Формулы блоков ЧТЗ и методик ПМИ переведены на «пункт ИЭП-1/4.2.1.N/АКК Заявки № ИЭП-1 …»; Таблица 1 ПМИ обновлена.

  • ЧТЗ: шифр темы — ИЭП-2025-5; аннотация — «создание новой функции регистрации»; п. 1.7 «Соответствие видов работ» (ОКПД 2: 62.01.11.000 и п. ТЗ 1.7); глоссарий — термин «ТЗ» (полное наименование) и «Ведение данных (сопровождение данных)»; в 4.2.1 «Назначение работ» формальная отсылка на Концепцию заменена ссылкой на ТЗ (раздел 2, п. 4.2.1.1) + цитата из паспорта ВПЦТ Минцифры 2026–2028 (раздел 4.7 ИС ГУЦ, результат 30.11.2026); целевая модель — «регистрацию в распределённых реестрах данных»; в 4.2.2/4.2.3 добавлены ссылки на пп. 4.2.1.11/4.2.1.5 ТЗ.

  • ТЗ проиндексирован в pki.db: документ tz-infra (веса язык 0.97 / смысл 0.97), 43 чанка, 43 эмбеддинга (747 чанков всего, NULL = 0). В documents добавлены колонки weight_lang/weight_sem (бэкфилл для прежних документов). Инцидент: embed-скрипт падал на JSONDecodeError при пустом ответе qwen — qwen_one/store укреплены try/except; два раздутых табличных чанка разрезаны на части.

  • ЧТЗ и ПМИ переэкспортированы в .docx (RU).

  • Обозначение документа ЧТЗ: ПроКСи_ИЭП-2025-5_РРОИОК_АКК_ЧТЗ_01 (01 — версия; решение А.М.). Экспорт в exchange/ под этим именем.

Событие — синхронизация ЧТЗ с дошлифовкой А.М. (02) и стили заголовков (2026-09-10)

  • А.М. дошлифовал ЧТЗ: exchange/ПроКСи_ИЭП-2025-5_РРОИОК_АКК_ЧТЗ_02.docx. Исходник work/ps01/ЧТЗ_реестр_аккредитации_УЦ.md синхронизирован: титул в два Title-абзаца («по развитию функции регистрации»); Предмет работ — «Функции распределённых реестров аккредитации УЦ»; обозначение — «…ЧТЗ (версия 02)»; Содержание — без списка; глоссарий: СКПЭП/УКЭП вместо КСКПЭП/НСКПЭП, ГУЦ без ОГРН, «глобальное состояние — (world state)…»; «Соответствие видов работ» без «1.7»; из 4.2.1 удалены ВПЦТ-цитата и «выполнение работ предусмотрено п. 4.2.1.1 ТЗ», признание действительности — «…квалифицированных сертификатов, выданных аккредитованными УЦ, а также связанных усиленных электронных подписей»; «пунктов 1–5 настоящего раздела»; приложения А/Б удалены.

  • Стили 02 изучены и внедрены в work/ib/md2docx.py (режим numbered=True): Title; Heading 1/2/3 с многоуровневой автонумерацией «1., 1.1., 1.1.1.» (свой numbering part, numId 7); «Аннотация»/«Содержание» — TOC Heading с numId 0; «Термины и сокращения» — Heading 1 с numId 0; уровень Word определяется по глубине литерального номера в md-заголовке (4.2.1 → Heading 3); добавлена поддержка курсива. ЧТЗ перегенерирован (work/ps01), файл А.М. в exchange не тронут; ПМИ перегенерирована без автонумерации (numbered=False) до утверждения её стилей.

Событие — выполнение Postman-коллекции ПМИ_АКК на стенде (2026-09-10)

  • Коллекция r1/ПМИ_АКК.postman_collection.json (34 запроса) выполнена на стенде http://45.131.40.89:8080 (переменные и auth_token предоставлены А.М.; авторизация — x-api-key, как в примере А.М., вместо Authorization Bearer из коллекции; добавлен Content-Type: application/json — без него сервер отвечал «Пустой запрос»).

  • Результат в work/ps01/ПМИ_АКК_выполнение.md (формат: заголовок → curl → ответ): 12 успешных (все GET: периоды ×3, статус на дату ×9), 22 отказа. Причины: состояние стенда (ERR-0004/0208/1001 — идемпотентность работает); переменные accreditationID_1..3 не существуют в реестре (ERR-0303); дефекты коллекции (registry/set без assetType; cancel без accreditationID/canceledAt; в 7.2 незакодированный «+» — ERR-0106).

  • Наблюдения для реестра замечаний PS-01: код ERR-0602 («Нет действительных записей аккредитации до указанной даты») есть в реальном чейнкоде, но отсутствует в Описании решения; в недействующем периоде by-date возвращает ошибку вместо признака «не действует»; ошибки GET — HTTP 500 в поле error. Исполнитель коллекции: work/ps01/run_pmi_akk.py.

Событие — чистый прогон коллекции ПМИ_АКК (2026-09-10)

  • ОГРН УЦ: сначала 1027700067320 — отклонён стендом (ERR-0002, контрольная цифра должна быть 8); по выбору А.М. — 1027700067339, затем (после двойного прогона-инцидента) чистый прогон на 1027700067340.

  • Инцидент: guard __main__ + явный вызов main() давали двойной прогон (второй — по «грязному» состоянию); guard из исполнителя убран.

  • Авто-захват accreditationID из ответов create (CA_<ОГРН>_ACCR_1/2/3) реализован и работает.

  • Чистый прогон: 23 успешных / 11 отказов. Прошли: регистрация УЦ; создание аккредитаций 1–3; изменение статусов 6.1–6.5; аннулирование (9); add-info (16/17); все GET периодов и 9 проверок статуса на дату. Отказы: registry/set — 500 без assetType (дефект коллекции); повторное добавление — ERR-0208 (ожидаемый негатив); 01.12.2019 — ERR-0601 (негатив); 01.12.2024 и 30.10.2023 после аннулирования — ERR-0602; 7.2 — ERR-0106 (незакодированный «+» в коллекции); cancel — 400 (нет accreditationID/canceledAt в теле коллекции); update-info ×2 — ERR-1001 для нового УЦ (наблюдение: контроль повторов сработал — требует анализа, кэш ли глобальный).

  • Документ: work/ps01/ПМИ_АКК_выполнение.md (заголовок → curl → ответ; 34 запроса); резюме прогона вынесено в начало документа (и генерируется исполнителем автоматически).

Событие — минимизированная ПМИ v2 (2026-09-11)

  • Решение А.М.: сократить шаги ПМИ — доказывать существенные функции; детальные переборы (алгоритм ОГРН, все переходы, все фильтры, дубли демонстрации) не выполнять.

  • Принципы минимизации: «одна успешная проверка + один негатив на функцию»; статусная модель — одной сквозной цепочкой (3→4→2→5 + один недопустимый переход); темпоральность — одним шагом («статус на прошлую дату не изменился после отмены»).

  • work/ps01/ПМИ_реестр_аккредитации_УЦ_v2_минимизированная.md (+docx): 10 проверок / ~22 шага вместо 15 проверок / ~64 шагов. Шаги содержат реальные вызовы API (POST /ca/create, POST /ca/{ogrn}/update-info, add-info, accreditation/create, accreditation/update, event/cancel, GET …/valid, …/by-date?date=…, GET /ca/list?status=…) — проверенные на стенде. Перед разделами А.2/А.3 (функции по IP) и в п. 3.5 внесено пояснение: IP-адрес может требовать уточнения в зависимости от развертывания инфраструктурного окружения тестируемых функций.

  • Замечание А.М. (2026-09-13): из ПМИ v2 убраны мета-комментарии о процессе создания («Версия 02 — минимизированная…», примечание про ERR-0602/стенд) — в эталонах таких сообщений нет; версия указывается только в обозначении документа. Правило внесено в память (п. 18).

Событие — правки оформления ПМИ v2 и шаблон чтз.ott (2026-09-13)

  • Из шагов ПМИ v2 убраны «Основной.» и «Демонстрирующий.» (роль единственная — сообщается один раз в описании испытаний рядом с IP-пояснением); альтернативные шаги помечаются «(альтернативный для шага N)».

  • Предоставлен шаблон formats/чтз.ott (сконвертирован в formats/чтз.docx): заголовки Heading 1/2/3 с автонумерацией (numId 8, формат без точек), TOC Heading без номера. Конвертер md2docx.py переведён на шаблон: convert(..., numbered=True, template='formats/чтз.docx'); приложения/Термины — Heading с numId 0; тело шаблона очищается при сборке.

  • Таблицы шагов «№ | Шаг | Ожидаемый результат»: ширины столбцов 1,10 / 9,06 / 5,08 см (фиксированная раскладка, gridCol + tcW).

  • Пересобраны: ПМИ v2 и ЧТЗ (work/ps01) на шаблоне чтз.

Событие — новый шаблон чтз&пми.ott и RT_-стили (2026-09-13)

  • А.М. обновил шаблон: formats/чтз&пми.ott (72 стиля RT_*). Разобрано устройство: RT_Заголовок_1..3 — numId 11 («1», «1.1», «1.1.1»); RT_Заголовок_6 — без номера; RT_Заголовок1..3_прил — numId 12 («Приложение А» russianUpper, «А.1», «А.1.1» — префиксы авто, в текст заголовков не вносятся); RT_ТекстОсн, RT__ПМИ_Предварит_услов, RT_НазваниеТаблицы, списки RT_СписокМарк1/2, RT_Табл_НазвСтолбца/RT_Табл_Текст, RT_Code, титульные RT_документ_название/номер.

  • Конвертер переведён на RT_-стили (только стили шаблона); ЧТЗ и ПМИ v2 пересобраны. Роль в шагах ПМИ: «демонстрирующий соответствие функции требованиям» (формулировка А.М.).

  • В CLAUDE.md добавлен раздел «Чистота официальных документов» — признаки недопустимой «рабочей кухни» (мета-комментарии о версиях/сокращениях, примечания о стенде, отсылки к журналу/реестру).

Событие — парадигма «1 ТЗ / 1 Заявка / 3 вида работ», RT-стили, пересборка (2026-09-13)

  • Решение А.М.: не три ЧТЗ/три ПМИ, а одно ЧТЗ с четырьмя позициями в 4.2: 4.2.1 аккредитация УЦ (подпункты 4.2.1.1 ведение / 4.2.1.2 взаимодействие / 4.2.1.3 представления — по заявкам ИЭП-1/4.2.1.1, /4.2.1.11, /4.2.1.5/АКК), 4.2.2 УКЭП, 4.2.3 УНЭП, 4.2.4 маршрутизация (заголовки без наполнения). Вводная фраза 4.2 — дословно от А.М. Раздел 4 ЧТЗ переименован в «Требования к Системам» (по ТЗ).

  • ПМИ: ПМИ_реестр_аккредитации_УЦ_v2.md (без «минимизированная»; старые файлы удалены): А.1 — 10 проверок А.1.1–А.1.10, А.2–А.4 — заголовки; объект испытаний — пп. 4.2.1–4.2.4 ЧТЗ; Таблица 1 — 4 строки.

  • Стили: Аннотация/Содержание/Термины → RT_ЗаголовокАбзаца (не в оглавлении); списки → RT_ListMarked-; таблицы → ячейки RT_Tab01.1 (шапка) / RT_Tab01.2 + tblBorders (RT_Tab02 в сохранённом ott отсутствует — лок LibreOffice висит, вероятно, не сохранено); уровни заголовков до 4 (RT_Заголовок_4). Все абзацы — только RT_-стили.

Событие — v02: имена РР_ОИОК, RT_Header_Num, коллекция Postman в ПМИ (2026-09-14)

  • Имена файлов: ЧТЗ_РР_ОИОК_v02.md/docx, ПМИ_РР_ОИОК_v02.md/docx (старые удалены). Заголовки: ЧТЗ — «на выполнение работ по созданию функций распределённых реестров объектов инфраструктуры открытых ключей»; ПМИ — «…испытаний функций распределённых реестров объектов инфраструктуры открытых ключей».

  • Стили (замечания А.М. 1–3): нумерация заголовков переведена с LibreOffice-WWNum11 на RT_Header_Num (воспроизведён из ott: « %1 », « %1.%2 », « %1.%2.%3 », « %1.%2.%3.%4 », отступы 1,27/1,905/2,54/3,175 см, hanging 0,635 см) — RT_Заголовок_1..4 → numId 100; RT_Заголовок_4 приведён к ott (TNR 12pt bold, spacing 240, keepNext; Заголовок_1 — с новой страницы). RT_Tab02 в ott нет (только RT_Tab01.1–16) — используются RT_Tab01.1/01.2.

  • ПМИ: ТЗ добавлен в термины; А.1 переструктурирована под три вида работ (порядок: ИЭП-1/4.2.1.11 → А.1.1–А.1.5; ИЭП-1/4.2.1.5 → А.1.6–А.1.8; ИЭП-1/4.2.1.1 → введение от агента-писателя + А.1.9–А.1.10). Введение 4.2.1.1 — литературное, по RAG-языку.

  • Коллекция Postman: ПМИ_РР_ОИОК_коллекция_v02.json (18 запросов, 2 папки по видам работ; Tests-скрипты — pm.expect deep.include/deep.equal по значимым параметрам: id, subjectOGRN, коды ERR-0004/0208/1001/0402, status true, темпоральность через сравнение с сохранённым ответом). В ПМИ — Приложение Б (RT_Code, 937 строк с нумерацией; шаги А.1.1–А.1.8 адресуют строки-якоря). Протокол → Приложение В, акт → Приложение Г.

  • Автооглавление и перекрёстные ссылки (2026-09-14): в «Содержание» обоих документов вставляется поле TOC (\o "1-3" \h \z \u) — обновление по F9, ручная сборка оглавления не нужна; заголовкам RT_Заголовок_1..4 и _прил заданы outlineLvl. Ссылки «(строка N коллекции, Приложение Б)» заменены на поля REF \w \h к закладкам на строках-якорях коллекции (кликабельные, показывают номер строки).

Событие — ПМИ в ODT на базе ott; правки 260914 (2026-09-14)

  • Решение А.М.: ПМИ выпускать в ODT (только odt), опираясь на актуальный чтз&пми.ott с его стилями, включая table-template RT_Tab01. Написан work/ib/md2odt.py: content.xml собирается из md, упаковка — стили/манифест из ott; таблицы — table:style-name="RT_Tab01" (шапка RT_Tab01.1/ячейки RT_Tab01.2, колонки RT_Tab01.3/.4/.9, ширины шагов 1,10/9,06/5,08 см); оглавление — text:table-of-content со стилем RT_Contents1-2-3-4 (в шаблоне он один, на все уровни); перекрёстные ссылки «см. <Приложение Б>, поз. <N> коллекции» — text:bookmark-ref (reference-format=number) к закладкам prilB и line_N (N — номер строки в нумерации RT_Code); маркеры в md: [[ref:prilB]], [[ref:line:N]].

  • Правки 260914: аннотация ЧТЗ приведена к названию («создание функций РР ОИОК»); термин «Описание решения» — без даты, «документы… каждой группы функций п. 4.2 ЧТЗ»; заголовки приложений 4-го уровня — RT_Заголовок4_прил из ott (в ODT стиль шаблона родной); в шагах — формула «см. <Б>, поз. <N> коллекции» с кросс-ссылками.

  • Результат: work/ps01/ПМИ_РР_ОИОК_v02.odt (19 уникальных ссылок ↔ 22 закладки, несвязанных нет). ЧТЗ-аннотация обновлена в md (docx по запросу).

  • Правки по замечаниям (2026-09-14, вторая итерация ODT): имена стилей в content.xml — закодированные style:name (RT_5f_…; ранее использовались display-name — LO не находил стили: «файл повреждён», нумерация заголовков не отображалась); закладки теперь обёртывают текст абзаца (были нулевой длины — ссылки давали «Error: Reference source not found»); после «см.» и «поз.» — неразрывные пробелы ( ); макросы шаблона (Basic/, Scripts/) удалены из архива и манифеста.

Ответ № 06 (2026-09-15) — фильтрация черновиков реестров сертификатов; преамбула ЧТЗ 4.2.3

  • Задание А.М.: (1) отфильтровать черновики ЧТЗ 4.2.2/4.2.3 и ПМИ А.2/А.3 — без «А.М.» и вопросительных моментов, только принятые решения; (2) tech-writer — преамбула ЧТЗ 4.2.3 (один абзац 20–50 строк): сборник отличий ведения сертификатов УНЭП от УКЭП с обоснованием целесообразности раздельных каналов и рисков общих (приказ ФСБ от 27.12.2011 № 795 — жёстко, редко меняется; УНЭП по постановлению № 2152 — слабо урегулированы, меняются часто и непредсказуемо → чейнкод должен допускать гибкость, как и структуры данных); (3) вопросительные моменты — в /opt/pki/work/OQ.md и дублировать в чате.

  • Фильтрация: из ПМИ А.2 удалено 4 маркера *[Место для уточнений — согласуется с А.М.: …]*, из ПМИ А.3 — 6 маркеров; в черновиках остались только плейсхолдеры ___ номера Заявки (вопрос В01). Файл work/r2+3_Certificates/реестры_сертификатов_замечания.md удалён — замечания перенесены в OQ.md.

  • Создан /opt/pki/work/OQ.md — реестр открытых вопросов: правила ведения (идентификаторы, решения → history.md/requirements.md), В01–В15 (вопросы по черновикам), И01–И24 (замечания к источнику: противоречия, дефекты оформления, не описано).

  • Tech-writer подготовил преамбулу ЧТЗ 4.2.3 (один абзац ~30 строк): каналы Госключ, идентификация издателя по CN без ОГРН (issuerOGRN пусто), типы ROOT_CA/SUB_CA/END_ENTITY вместо ownerType, проверки UNQCERT_* без жёстких проверок критичности, без проверок аккредитации/полномочности по ОГРН (поиск цепочки — по реестру издателей Госключ, accreditationStatus не формируется); обоснование — приказ ФСБ № 795 (жёстко, редко) против постановления № 2152 (слабо, часто и непредсказуемо); чейнкод должен допускать гибкость в проверках и структурах данных; риски общих каналов. Преамбула вставлена в ЧТЗ 4.2.3 после строки Заявки, перед «Назначение работ».

  • Итог каталога: 4 черновика (ЧТЗ 4.2.2, ЧТЗ 4.2.3 с преамбулой, ПМИ А.2, ПМИ А.3) + OQ.md.

Ответ № 07 (2026-09-15) — формат ссылок на Заявку ИЭП-1; вопросы ротации в OQ.md

  • Замечания А.М. по ответу 06: (1) строка Заявки — формат «Работы выполняются в соответствии с пунктами /4.2.2.1, 4.2.2.5, 4.2.2.11 Заявки № ИЭП-1»; (2) по замечаниям частично прошёлся сам, уточнил формат OQ.md (шапка, колонка «дата / Где возник / статус (автор)», решение по В01 — номенклатура функций Заявки: 4.2.1.1 «Создание новой функции (без взаимодействия с внешними ИС)», 4.2.1.5 «Создание новой функции обработки данных», 4.2.1.11 «Создание функции взаимодействия с внешними ИС»); (3) вопросы по документу «Ротация каналов_260714» — перенести в OQ.md в новом формате.

  • Строки Заявки приведены к формату А.М.: ЧТЗ 4.2.2 (убран задвоенный зачин), ПМИ А.2, ПМИ А.3; ЧТЗ 4.2.3 А.М. поправил сам. В ЧТЗ 4.2.4 / ПМИ А.4 плейсхолдеры остались — вопрос В17.

  • OQ.md: таблица В-вопросов реестров приведена к 3-колоночному формату (В02–В15 — добавлены дата/статус); добавлены разделы: «Вопросы по черновикам «Ротация каналов»» (В16–В20) и «Замечания к источнику «Ротация каналов_260714.html»» (И25–И38); файл work/r4_serviceChainCode/ротация_каналов_замечания.md удалён (перенесён в OQ.md).