namespace: v2_docs_update

prompts:
  plan_change_units: |
    Ты классифицируешь units системной аналитики для построения плана изменений документации.

    Верни только JSON:
    {
      "items": [
        {
          "index": 0,
          "doc_type": "api_method",
          "id": "ufs.contacts_dgr.api.create",
          "application": "coverage",
          "platform": "ufs",
          "page_type": "api",
          "path": "docs/coverage/ufs/api/ufs.contacts_dgr.api.create.md",
          "reason": "..."
        }
      ]
    }

    Правила:
    - Используй только doc_type из allowed_doc_types.
    - Не пропускай item, даже если не уверен: выбери наиболее близкий тип.
    - Ориентируйся на heading и snippet.
    - path — это служебное поле плана изменений, не поле frontmatter.
    - id:
      - брать из metadata unit, если задан;
      - если id нет, сгенерировать стабильный id по смыслу unit и по аналогии с существующей документацией.
    - имя файла всегда формировать строго как <id>.md.
    - для существующего документа (если это видно из контекста и индекса) путь не менять.
    - для нового документа путь формировать строго как docs/<application>/<platform>/<page_type>/<id>.md.
    - platform использовать только из допустимых значений: web, ufs, pprb.
    - page_type выбирать по doc_type (например ui_page -> ui, api_method -> api, logic_block -> logic).
    - последний сегмент path обязан совпадать с <id>.md.
    - Никакого markdown и текста вне JSON.

  build_doc_changeset: |
    Ты формируешь один item changeset для документации на основе системной аналитики и правил doc_rules.

    Верни только один JSON-объект (RFC8259) формата:
    {
      "op": "create|update|delete",
      "path": "docs/...",
      "reason": "краткая причина",
      "proposed_content": "полный markdown документа для create/update"
    }

    Схема и ограничения:
    - Обязательные поля всегда: op, path, reason.
    - Для op=create/update поле proposed_content обязательно и содержит полный markdown документа:
      1) frontmatter между --- и ---,
      2) затем body согласно doc_rules.
    - Для op=delete поле proposed_content запрещено.
    - В JSON используй двойные кавычки, без trailing commas.
    - Никаких code fences (```), комментариев и текста до/после JSON.

    Правила:
    - Строго соблюдай структуру и ограничения из doc_rules_context.
    - Для create/update верни полный итоговый markdown (frontmatter + body).
    - Для update не используй placeholder-тексты; возвращай пригодный к сохранению документ.
    - reason обязателен, короткий, по сути изменения.
    - Никакого markdown и текста вне JSON.

  repair_doc_changeset_json: |
    Ты ремонтируешь невалидный ответ модели и должен вернуть строго валидный JSON changeset.

    Вход содержит:
    - expected_contract: ожидаемые поля и ограничения.
    - raw_llm_output: исходный (возможно невалидный) ответ.

    Задача:
    - Извлеки максимально полный смысл из raw_llm_output.
    - Верни ровно один JSON-объект, соответствующий expected_contract.
    - Если часть данных отсутствует, используй безопасные значения по умолчанию:
      - reason: "generated by repair"
      - proposed_content: только если op=create/update, иначе не добавляй.

    Ограничения вывода:
    - Только JSON-объект, без markdown/code fences/комментариев.
    - Двойные кавычки, без trailing commas.
    - Внутри строк (особенно proposed_content) все переносы строк должны быть экранированы как \\n, не literal newline.
