0x80070005

Разделите li на два блока: иконку и текст. Для текста задайте бордер:

У вас будет 3 компонента, секция, чекбокс и дропдаун. Последние 2 в зависимости от вида списка вы передаете в качестве детей в секцию. Например

<Section>
   <Checkbox>Тут подпись к чекбоксу</Checkbox>
   <Dropdown>Тут наверно опции к дропдауну</Dropdown>
</Section>

Скорее всего вам будет полезно узнать о Compound components. Что-то такое:

<List>
  <List.Item>
     <List.Checkbox ...> Some text
  </List.Item>
  <List.Item>
     Some text <List.Checkbox ...> 
  </List.Item>
  <List.Item>
     <List.Dropdown ...>
  </List.Item>
</List>

Вот реальный пример из chakra ui:

import { List } from "@chakra-ui/react"
import { LuCheckCircle, LuCircleDashed } from "react-icons/lu"

const Demo = () => {
  return (
    <List.Root gap="2" variant="plain" align="center">
      <List.Item>
        <List.Indicator asChild color="green.500">
          <LuCheckCircle />
        </List.Indicator>
        Lorem ipsum dolor sit amet, consectetur adipisicing elit
      </List.Item>
      <List.Item>
        <List.Indicator asChild color="green.500">
          <LuCheckCircle />
        </List.Indicator>
        Assumenda, quia temporibus eveniet a libero incidunt suscipit
      </List.Item>
      <List.Item>
        <List.Indicator asChild color="green.500">
          <LuCircleDashed />
        </List.Indicator>
        Quidem, ipsam illum quis sed voluptatum quae eum fugit earum
      </List.Item>
    </List.Root>
  )
}

что тут не так? Не могу понять, что не правильно :/

Ну там же написанно...

Error at property 'operation': Value must be one of append, remove, set.

// operation: "removeHeaders",
operation: "remove",

// operation: "setHeaders",
operation: "set",

Использовать правильное значение опции. Там же прям в ошибке написано - вы её хотя бы читали?

Да, конечно можно проверить работу каждой фичи и функции ручками. Это если у тебя три-пять фич/функций, ну десяток еще можно, а изменения - раз в неделю. А если это надо делать на каждый коммит? Десять коммитов в день? А как проверять, если там 100 экранов, на каждом экране по сотне графических элементов, у которых по пять состояний в различных вариантах, два десятка эндпоинтов в бэкэнде, а в коде паутина из 10-100к функций и хрен знает сколько зависимостей? Итого 100 x 100 x 5 x 20 - уже миллион вариантов. Ой, а у нас там еще есть отдельная админка для этого вот всего, биллинг, мониторинг, отчеты, интеграция с тремя десятками платёжных систем и бакнов, почта, интеграции с мессенджерами, кэширование, резервирование, бэкапы и еще пара сотен зависимостей и интеграций с другими системами. Сколько месяцев или даже лет ручного труда потребуется для ручной проверки работы такого проекта в каждом коммите за время работы команды из десяти разработчиков в течении хотя бы одной недели?

Возьмём для примера обычный виндовый калькулятор: 4 варианта - 40 элементов интерфейса только в одном только обычном варианте, в статистике - примерно 50, в инженерном чуть больше сотни, в режиме программиста - все две сотни. И у каждого элемента в среднем от одного до десяти состояний, плюс еще связи с другими элементами, а так же разное поведение, зависящее от других элементов. И работу каждого элемента надо проверить с учетом всех возможных вариантов его работы. Сотни и тысячи фич/функций, десятки и, вероятно даже сотни, тысяч вариантов. Да, конечно, большая часть всего этого перекрывается более высокоуровневыми тестами и переиспользованием уже написанного кода (что, кстати, как раз и создаёт все эти зависимости) и тестировать под сто раз одно и то же нет необходимости. Но вот так, вручную, без конкретного списка конкертных фич и автоматизации - как проверить правильность работы хотя бы вот такого обычного калькулятора?

Вот тут и приходят на помощь автоматизация тестирования - один раз пишешь тест на фичу и дальше одной командой проверяешь, что всё работает как надо. В любом проекте есть зависимости и чем больше и сложнее проект - тем больше зависимостей и тем сложнее их отслеживать. Особенно, если в проекте больше одного разработчика: бывает, что меняешь что-то совсем маленькое и незначительное в одной части проекта - а в результате ломается вообще весь проект и всё перестаёт работать полностью, ибо вот эта маленькая и незначительная часть подпирала вон ту большую балку, которая поддерживала фундамент от опрокидывания на бок. А на крышу он не перевернется - он там с другой стороны привязан веревкой к колышку декоративной веревочкой.

А еще есть такая методика, как TDD: разработка через тестирование - сначала создаётся тест на фичу, а уже только потом создаётся сама фича.

Тесты пишут, чтобы при изменениях в коде их прогонять и проверять, что определённое в тестах поведение не ломается. Да, можно каждый раз всё вручную прогонять, но вот для примера, у нас в проекте тысячи две автотестов, каждый раз всё это вручную прогонять ни у кого возможности нет

А в чем проблема проверить тогда без этого теста?

Проверить - это уже тест. И ты имеешь ввиду ручной, а спрашиваешь "зачем пишут". Т.е. суть вопроса: "зачем пишут автотесты".
Так вот, приближённая аналогия этого вопроса - "в чём проблема дойти из Москвы до Магадана пешком, зачем автомобили и самолёты?"

Количество тестируемых точек может достигать нескольких тысяч, а то и десятков тысяч. Чтобы проверить их вручную нужно задействовать армию тестировшиков (которым нужно платить з/п, на сек) и массу человеко-часов.

Итого: автотесты снижают стоимость и сокращают время.

Раз у нас:
1. Клиенты read-only
2. Для всех клиентов данные одни и те же
3. Нет аутентификации/авторизации
4. Не нужно уведомлять клиентов об изменениях на горячую

То тогда можно тупо статичный json где-нибудь на гитхабе создать.

Есть несколько классных сервисов для хранения данных с доступом через API. Например, попробуй Firestore от Google — там можно хранить данные в формате JSON, доступ к ним удобный через REST API. Плюс у них есть бесплатный тариф для небольших проектов. Еще вариант — Airtable, у него удобный интерфейс и тоже API для интеграции. Оба этих сервиса дают возможность долгосрочного хранения данных, а не временного, как jsonbin.io.

Используйте пользовательский скрипт - расширения типа TemperMonkey и прочие обезьянки.
UPD: Для расширения в хроме следует использовать его АПИ: https://developer.chrome.com/docs/extensions/devel...
UPD2: в итоге оказалось, что ТС пишет расширение и ему надо запустить код в iframe/webview. Спасибо
телепатии Aetae - помогли следующие опции в конфиге:

{
    "content_scripts": [ 
        { 
            "match_about_blank": true,
            "all_frames": true
        } 
    ] 
}

Может это?
Браузер в браузере
https://hub.docker.com/r/kasmweb/chrome

Demo

manifest.json

{
  "manifest_version": 3,
  "name": "Request Header Logger",
  "version": "1.0",
  "permissions": [
    "webRequest"
  ],
  "background": {
    "service_worker": "background.js"
  },
  "host_permissions": [
    "*://*/*"
  ]
}

В host_permissions лучше указать только нужные хосты

background.js

chrome.webRequest.onSendHeaders.addListener(
    function(details) {
        console.log("URL: " + details.url); // Тут будет url запроса
        console.log("Request Headers: ", details.requestHeaders); // Тут будут заголовки запросов
    },
    { urls: ["<all_urls>"] },
    ["extraHeaders", "requestHeaders"]
);

bip39 стандарт, из сид фразы можно сделать сколько угодно кошельков

Есть как готовые платежные решения, которые генерируют уникальный кошельки, так и свои собственные кошельки, но там значительно больше разработки. Один из доступных вариантов - westwallet