Ресурси й можливості

Обсяг версії: Ця сторінка переказує чотири нормативні документи поточного стандарту DWP 7.0.0 у релізі v7.9.0: V6_CONTEXT.md, V6_RESOURCES.md, CONFIG.md і V7_ABILITIES.md. Якщо ця сторінка й ці файли розходяться, перевагу мають файли.

Статус: стабільний (контекст і ресурси — з 6.0.0; конфігурація й можливості — з 7.0.0). Ці правила обовʼязкові для планів лінії v6 (Шар записів); стандарт v5 не змінюється. Ключові слова MUST, MUST NOT, SHOULD, SHOULD NOT та MAY тлумачаться згідно з RFC 2119.

Маніфест контексту для кожного завдання

Перед кожним завданням агент виводить маніфест контексту з контракту й повного журналу (context_manifest.py). Це похідне представлення, яке ніколи не зберігається як стан: дворазове виведення з тих самих записів MUST давати ідентичні байти, а маніфест MUST NOT читати щось поза планом і його репозиторієм. Його форму опубліковано як context-manifest/v6.

authorization, repository_rules і acceptance є обовʼязковими: обрізання контексту ніколи не може приховати межу приймання чи авторизації. Драбина наступних дій упорядкована (схвалення, старт, повноваження, контроль, докази, завершення) і ніколи не подає звичайний успішний gate як такий, що закриває контрольований критерій.

Глухі кути зберігаються. Запис залишає дайджест лише на підставі доведених фактів записів (той самий відбиток пізніше пройшов, новіша дубльована відмова його замінила, або ревізія контракту його застарила); сама лише зміна поверхні MUST NOT його прибирати. Свіжість перевіряється: підсумок, чий зафіксований відбиток входів більше не збігається, є застарілим, а підсумок без відбитка застарілий за побудовою. Історія завантажується лише за тригером — зафіксована передача роботи або поправка, що стосується завдання; інакше контекстом завдання є лише маніфест.

Облік чотирьох величин

Інструкційне навантаження й вартість звітуються як чотири окремі величини: статичні байти інструкцій, токени провайдера (лише там, де їх зафіксував лічильник хоста), грошова вартість (лише з зафіксованих вибірок за реальними тарифами) і реальний час (з міток часу подій). Відсутня величина звітується як відсутня з причиною, ніколи не підставляється, а байти ніколи не перетворюються на токени чи гроші.

Можливості хоста

Хост виконання заявляє свої можливості із замкненого набору: stop_agent, meter_spend, meter_tokens, meter_wall_clock, cancel_children, model_routing, subagents, telemetry. Невідома можливість MUST бути відхилена, а незаявлена можливість дорівнює false. Мінімальний хост — без перемикання моделей, без субагентів, без телеметрії, без зупинки — є підтримуваною конфігурацією, а не помилкою; кожне обмеження, якому потрібна відсутня можливість, знижується до рекомендаційного із зазначенням цієї можливості.

Можливості не є дозволами. Дозвіл у контракті — це повноваження; можливість — це те, що середовище справді вміє робити. Кожна конфігурація, якій потрібна можливість, однаково потребує свого дозволу.

Ресурсний конверт

Контракт MAY оголошувати ліміти у своєму ресурсному конверті. Ліміт примусовий лише тоді, коли він називає реальне джерело вимірювання; інакше він рекомендаційний, і паритет примусу між хостами ніколи не заявляється.

• Джерела лічильників. Лічильники, видимі з журналу (тривалість у реальному часі, повтори gate, виклики диспетчеризації), обчислюються з власних записів плану. Лічильники лише хоста (витрати, токени провайдера) потребують відповідної можливості вимірювання й спостереженої вибірки від адаптера хоста; відсутній лічильник не означає безплатного використання.
• Резерви. Ліміт MAY оголошувати reserve, щоб звичайна робота не могла позбавити ресурсів перевірку, повтори й відновлення: диспетчеризація відхиляється, коли витрачене плюс очікуване перевищило б ліміт мінус резерв.
• Вичерпання. Досягнення ліміту зберігає незавершену контрольну точку, фіксує LIMIT: exhausted <id>: <detail> і утримує диспетчеризацію до явного запису LIMIT: recovered <id>. Вичерпання ніколи не може задовольнити критерій приймання.
• Розрахунок при скасуванні. Резервування в процесі розраховується рівно один раз — як звільнене або зафіксоване; суперечливий другий розрахунок відхиляється, а не арбітрується.
• Конфігурація маршрутизації. За замовчуванням використовується фіксована модель. Перемикання рівня моделі потребує і дозволу model_routing, і однойменної можливості; паралельна диспетчеризація потребує і дозволу agent_delegation, і можливості subagents. Конфігурація маршрутизації — це заява про дозвіл, а не твердження про ефективність.

Файл конфігурації й реєстр аддонів

.dwp/config.json (репозиторій) і ~/.dwp/config.json (користувач) мають одну форму, опубліковану як dwp-config/v1, і один парсер (config.py). Методологія працює без файлу конфігурації й без жодного аддона; ніщо у файлі не може зробити план, потік чи відповідність залежними від аддона.

• Відстежується за замовчуванням. Файл репозиторію містить рішення, а не секрети, і відстежується, щоб колеги й CI читали той самий реєстр: онбординг записує в .gitignore правило .dwp/* разом із !.dwp/config.json. Плани й записи бенчмарків залишаються ігнорованими.
• Пріоритет. Файл репозиторію має перевагу над файлом користувача, а відсутній файл означає, що все вимкнено. Ключ addons розвʼязується за кожним ключем аддона; ключ benchmark — цілком.
• Ключі реєстру — це назви директорій аддонів у пакеті: ai-diff-reviewer, agentkit, dailybot, dependency-upgrade, design-system, devcontainer, herdr, vim. Кожен запис має enabled (вмикає лише true), необовʼязковий version і необовʼязковий однорядковий note. Невідомий ключ ігнорується з одним попередженням.
• Відсутній означає невімкнений. Вмикати щось можуть лише онбординг зі згоди розробника, власний крок встановлення аддона або людина. Увімкнений аддон, який не виявлено і який має нотатку, звітується як відкладений.
• Читання з відмовою в закритий стан. Нечитабельний файл або некоректне значення нічого не додають і дають рівно одне попередження; читач ніколи не перериває потік і ніколи не мовчить про те, що відкинув. Записувач узгоджує атомарно й відмовляється перезаписувати файл, який не може розібрати.
• Запис хоста. Необовʼязковий ключ host фіксує заявлені можливості машини (булеві значення із замкненого набору). telemetry: true однаково потребує згоди розробника.
• Базовий рівень не змінюється. Локальна рецензія AI Diff Reviewer залишається частиною кожного Final Review незалежно від того, чи згадує її реєстр.

Можливості від аддонів

Починаючи з 7.0.0, увімкнені аддони можуть додавати можливості під час виконання:

effective abilities = host-declared abilities ∪ abilities provided by every addon that is enabled, described by a valid addon.json, detected, and on a compatible interface version

• Дескриптори. Кожен аддон у пакеті постачається з addon.json (addon-descriptor/v1), який оголошує його ключ, що він надає і як його виявляти.
• Виявлення лише для читання. Команда виявлення запускається без оболонки, із закритим stdin і тайм-аутом 10 секунд, і ніщо з її виводу не виконується. Продукт, чия заявлена мажорна версія інтерфейсу відрізняється від зафіксованої, вважається недоступним з одним попередженням.
• Невімкнений означає неопитаний. Дескриптор вимкненого аддона не відкривається, а його команда виявлення не запускається. Обʼєднання монотонне: увімкнення аддона може лише додати можливості.
• Ніколи не зберігаються. Ефективні можливості переобчислюються під час кожного виклику й MUST NOT записуватися в план. План фіксує те, що використав, — подія делегування називає свій транспорт і аддон, — а не те, що було доступно.
• Можливості не є повноваженнями. Аддон agentkit може надавати subagents, cancel_children і model_routing; аддон Herdr може надавати subagents і cancel_children. Делегування однаково потребує дозволу контракту agent_delegation (Делегування).

resources.py abilities виводить ефективний набір і походження кожної можливості; команда лише для читання.

Повʼязане

• Шар записів — контракт, журнал і докази.
• Делегування — як план використовує можливість subagents.
• Додатки — самі необовʼязкові аддони.