Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

​

План модернізації застосунку

​

Мета

​

Принципи

• Зберігати поточну архітектуру, якщо тільки не доведено, що певна межа спричиняє нестабільність, витрати продуктивності або видимі для користувача помилки.
• Для кожної проблеми віддавати перевагу найменшому правильному виправленню, а потім повторювати підхід.
• Відокремлювати обов’язкові виправлення від необов’язкового полірування, щоб супроводжувачі могли впроваджувати висококорисну роботу без очікування суб’єктивних рішень.
• Підтримувати задокументовану та зворотно сумісну поведінку для Plugin.
• Перевіряти поведінку в релізі, контракти залежностей і тести, перш ніж стверджувати, що регресію виправлено.
• Спочатку покращувати основний шлях користувача: онбординг, автентифікацію, чат, налаштування провайдера, керування Plugin і діагностику.

​

Етап 1: Базовий аудит

• Визначте основні користувацькі сценарії та кодові поверхні, які ними керують.
• Перелічіть мертві елементи інтерфейсу, дубльовані налаштування, неясні стани помилок і витратні шляхи рендерингу.
• Зафіксуйте поточні команди валідації для кожної поверхні.
• Позначте проблеми як обов’язкові, рекомендовані або необов’язкові.
• Задокументуйте відомі блокери, які потребують рев’ю від власника, особливо зміни API, безпеки, релізів і контрактів Plugin.

• Один список проблем із посиланнями на файли від кореня репозиторію.
• Для кожної проблеми вказано критичність, поверхню-власника, очікуваний вплив на користувача та запропонований шлях валідації.
• Жодні спекулятивні елементи прибирання не змішані з обов’язковими виправленнями.

​

Етап 2: Очищення продукту та UX

• Уточніть текст онбордингу та порожні стани навколо автентифікації моделі, стану Gateway і налаштування Plugin.
• Видаліть або вимкніть мертві елементи інтерфейсу там, де жодна дія неможлива.
• Зберігайте важливі дії видимими на різних адаптивних ширинах замість того, щоб ховати їх за крихкими припущеннями макета.
• Уніфікуйте повторювані формулювання статусу, щоб помилки мали єдине джерело істини.
• Додайте поступове розкриття для розширених налаштувань, зберігаючи швидке базове налаштування.

• Ручна перевірка щасливого шляху для першого запуску та запуску для наявного користувача.
• Точкові тести для будь-якої логіки маршрутизації, збереження конфігурації або виведення статусу.
• Знімки екрана в браузері для змінених адаптивних поверхонь.

​

Етап 3: Уточнення архітектури фронтенду

• Перенесіть повторювані перетворення стану UI у вузькі типізовані допоміжні функції.
• Чітко розділяйте відповідальність за отримання даних, збереження та представлення.
• Віддавайте перевагу наявним хукам, сховищам і шаблонам компонентів замість нових абстракцій.
• Розділяйте надто великі компоненти лише тоді, коли це зменшує зв’язність або прояснює тести.
• Уникайте впровадження широкого глобального стану для локальних взаємодій у панелях.

• Не змінюйте публічну поведінку як побічний ефект поділу файлів.
• Зберігайте незмінною поведінку доступності для меню, діалогів, вкладок і клавіатурної навігації.
• Перевіряйте, що стани завантаження, порожнього вмісту, помилки та оптимістичного оновлення як і раніше відображаються.

​

Етап 4: Продуктивність і надійність

• Вимірюйте витрати запуску, переходів між маршрутами, великих списків і транскрипту чату.
• Замінюйте повторювані дорогі похідні дані на мемоізовані селектори або кешовані допоміжні функції там, де профілювання доводить користь.
• Зменшуйте зайві сканування мережі або файлової системи на гарячих шляхах.
• Зберігайте детермінований порядок для введень prompt, реєстру, файлів, Plugin і мережі перед побудовою payload моделі.
• Додавайте легкі регресійні тести для гарячих допоміжних функцій і меж контрактів.

• Для кожної зміни продуктивності зафіксовано базовий рівень, очікуваний вплив, фактичний вплив і залишковий розрив.
• Жоден патч продуктивності не впроваджується лише на інтуїції, якщо доступне дешеве вимірювання.

​

Етап 5: Посилення типів, контрактів і тестів

• Замінюйте вільні рядки часу виконання на дискриміновані об’єднання або закриті списки кодів.
• Валідуйте зовнішні входи наявними допоміжними засобами схем або zod.
• Додавайте контрактні тести навколо маніфестів Plugin, каталогів провайдерів, повідомлень протоколу Gateway і поведінки міграції конфігурації.
• Зберігайте шляхи сумісності у потоках doctor або repair замість прихованих міграцій під час запуску.
• Уникайте зв’язування тестів із внутрішніми деталями Plugin; використовуйте фасади SDK і задокументовані barrel-експорти.

• pnpm check:changed
• Цільові тести для кожної зміненої межі.
• pnpm build, коли змінюються ліниві межі, пакування або опубліковані поверхні.

​

Етап 6: Документація та готовність до релізу

• Оновлюйте документацію разом зі змінами поведінки, API, конфігурації, онбордингу або Plugin.
• Додавайте записи до changelog лише для змін, видимих користувачу.
• Зберігайте термінологію Plugin у користувацькому формулюванні; використовуйте внутрішні назви пакетів лише там, де це потрібно для контриб’юторів.
• Підтверджуйте, що інструкції з релізу та встановлення все ще відповідають поточній поверхні команд.

• Відповідну документацію оновлено в тій самій гілці, що й зміни поведінки.
• Перевірки згенерованої документації або розбіжностей API проходять, якщо ці поверхні зачеплено.
• У передачі роботи вказано, яку валідацію було пропущено і чому.

​

Рекомендований перший зріз

• Проведіть аудит першого налаштування, готовності автентифікації провайдера, статусу Gateway і поверхонь налаштування Plugin.
• Приберіть мертві дії та проясніть стани збоїв.
• Додайте або оновіть точкові тести для виведення статусу та збереження конфігурації.
• Запустіть pnpm check:changed.

​

Оновлення навички фронтенду

# Стандарти доставки фронтенду

Використовуйте цю навичку під час реалізації або рев’ю користувацької роботи з React, Next.js,
desktop webview або UI застосунку.

## Операційні правила

- Виходьте з наявного продуктового сценарію та кодових конвенцій.
- Віддавайте перевагу найменшому правильному патчу, який покращує поточний користувацький шлях.
- Відокремлюйте обов’язкові виправлення від необов’язкового полірування в передачі роботи.
- Не створюйте маркетингові сторінки, якщо запит стосується поверхні застосунку.
- Зберігайте дії видимими й придатними до використання на підтримуваних розмірах viewport.
- Прибирайте мертві елементи інтерфейсу замість того, щоб залишати контролери, які не можуть виконати дію.
- Зберігайте стани завантаження, порожнього вмісту, помилки, успіху та дозволів.
- Використовуйте наявні компоненти дизайн-системи, хуки, сховища та іконки, перш ніж додавати
  нові примітиви.

## Контрольний список реалізації

1. Визначте основне завдання користувача та компонент або маршрут, який ним керує.
2. Прочитайте локальні шаблони компонентів перед редагуванням.
3. Внесіть патч у найвужчу поверхню, яка розв’язує проблему.
4. Додайте адаптивні обмеження для контролерів із фіксованим форматом, панелей інструментів, сіток і
   лічильників, щоб текст і стани наведення не могли неочікувано змінювати розмір макета.
5. Зберігайте чіткий розподіл відповідальності між завантаженням даних, виведенням стану та рендерингом.
6. Додавайте тести, коли змінюються логіка, збереження, маршрутизація, дозволи або спільні допоміжні функції.
7. Перевіряйте основний щасливий шлях і найрелевантніший крайовий випадок.

## Ворота візуальної якості

- Текст має вміщуватися в межах свого контейнера на мобільних і настільних пристроях.
- Панелі інструментів можуть переноситися, але контролери мають залишатися доступними.
- Кнопки повинні використовувати знайомі іконки, коли іконка зрозуміліша за текст.
- Картки слід використовувати для повторюваних елементів, модальних вікон і інструментів у рамці, а не
  для кожного розділу сторінки.
- Уникайте одноманітних колірних палітр і декоративних фонів, які конкурують з
  операційним контентом.
- Щільні продуктові поверхні мають бути оптимізовані для швидкого перегляду, порівняння та
  повторного використання.

## Формат передачі роботи

Повідомляйте:

- Що змінилося.
- Яка поведінка користувача змінилася.
- Яка обов’язкова валідація пройшла.
- Яку валідацію було пропущено і з якої конкретної причини.
- Необов’язкову подальшу роботу, чітко відокремлену від обов’язкових виправлень.