Meta Harness

Агентите за програмиране пишат бързо, но трудно се връщат от грешна посока. Анализ на собствените ми записи на сесии откри грешката, която срещах най-често: агент твърди, че е свършил работа, която не е проверил. Claude Code и Codex идват всеки със своя обща среда за работа на модела, а общата среда не познава моите правила, моите проекти и какво отказвам да позволя. Правилата, поставени ръчно във всяко хранилище, се разминаваха, а правило, което нищо не проверява, е само предложение. Работя в много хранилища на Windows, затова настройката трябваше да се инсталира с една команда, без пароли и ключове.

Правилата започнаха като лични файлове. Превърнах ги в платформа, моя плъгин Valox: каталог (marketplace) с плъгини за Claude Code, който доставя skills за работния процес, проверяващ агент и защитни hooks, регистър с постоянно активни правила и няколко малки инструмента за командния ред, които инсталират, проверяват и синхронизират всичко това. Всеки проект работи под него и записва точната версия, от която е синхронизиран. Позицията е записана в ADR (запис на архитектурно решение): когато изборът е между повече текст с инструкции и проверка, която пада, добавям проверката. Работата минава през задача (issue), план (blueprint), изграждане (build) и pull request, с две точки за одобрение от човек: одобрение на плана и pull request, който етапът на изграждане никога не отваря сам. Същата платформа е основата на моята настройка за агенти Orca, която пренася правилата и защитите между доставчици на модели.

1. 01

   Три слоя, по едно място за всяко правило

   Всяко правило, skill, hook или скрипт живее в точно един слой: L1 платформа за всичките ми проекти, L2 проект за едно хранилище, L3 машина за неща, които никога не бива да се записват в Git. Причината е бюджетът на контекста. Правило от L1 се зарежда във всяка сесия на всеки проект, така че инвариант, специфичен за един проект, поставен на L1, товари несвързана работа. Повишаването е видимо преместване на файл от consumers/<project>/rules/ към shared/rules/, щом втори проект поиска правилото, а понижаването не струва нищо.

2. 02

   Един източник, закрепен към версия, пренесен във всеки инструмент

   Skills, проверяващият агент и hooks се доставят като плъгин на Claude Code от локален каталог (marketplace) в папка. Правилата се инсталират като отделни файлове, следени от манифести, така че оттеглено правило се премахва, а написано на ръка в същата папка остава недокоснато. Малки скриптове за генериране пренасят същите правила и skills в Codex, Cursor и Grok. Всяко свързано хранилище записва в .valox.json пълния 40-символен commit, от който е синхронизирано, а CI му проверява съответствието спрямо този закрепен commit, а не спрямо движещия се main на платформата. В началото на сесията инструмент за диагностика (doctor) отпечатва по един ред за всяко разминаване, а първият отговор на агента трябва да го спомене.

3. 03

   Защити, които могат да откажат

   Hooks от типа PreToolUse блокират четири вида действия: принудително изпращане (force-push), което пренаписва публикуваната история, рекурсивно изтриване, насочено към корена, домашната или работната папка, четене на файл с пароли или ключове в записа на сесията и слепо добавяне за commit с git add -A. Защитата за команди разбира командите с shlex на Python, защото обединяването с AND на регулярни изрази върху целия низ караше безопасни команди да изглеждат опасни, а защита, която вдига фалшива тревога, се изключва. Самопроверката ѝ подава обратно през скрипта 90 случая от таблица като истински данни за hook. Локално hook за commit-msg отхвърля приписване на AI като съавтор, а hook за pre-commit отказва директни commit в основния клон и добавени за commit тайни.

4. 04

   Един проверяващ агент със строго заключение

   Единственият собствен субагент е проверяващ агент само за четене, със свеж контекст, така че да оценява резултата без разговора, който е направил плана да звучи убедително. Той трябва да отговаря в строга форма: VERDICT със стойност PASS, REVISE или BLOCK, находки с посочени файл и ред, таблица VERIFICATION, която изброява всяка команда като PASS, FAIL или NOT RUN, оставащ риск и препоръка. NOT RUN е допустим отговор, а свободният текст би го оставил да изчезне.

5. 05

   Профилите взвеждат възможности, а действието все пак пита

   Всеки профил изброява проектите, които може да докосва, и опасните възможности, взведени за него: търговия на живо, пускане в продукция, имейл, управление на работния плот, платено генериране и разрушителни операции върху база данни. Двата списъка започват празни и се вграждат в правилата на самата сесия, така че агентът може да заяви преди действие, че дадена възможност не е взведена. Взвеждането премахва общия отказ и запазва проверката в момента на действието: поръчка на живо пак изисква потвърждение, което назовава пазара и размера.

6. 06

   Една основа под няколко доставчици на модели

   Orca, външен инструмент с MIT лиценз, който пуска и координира терминали на агенти, работи на моя компютър в собствена WSL дистрибуция и се стартира с една команда. Плащам за най-високия план при всеки доставчик: четири абонамента Claude Max, два абонамента ChatGPT Pro за Codex и SuperGrok Heavy, около 1 500 USD месечно, с по един вход за акаунт. Доставчиците определят цената на тези планове много под това, което същата употреба струва през API, затова настройката разпределя работата между акаунтите на Claude и Codex и изразходва квотата на всеки акаунт, преди прозорецът ѝ да се нулира. Инструменти за отчитане на квотите съобщават идентичността и прозорците на ползване на всеки акаунт, а една команда за състояние показва услугите, средата за изпълнение и всеки влязъл акаунт. Платформата е основата, върху която е изградена тази настройка.

Всеки мой проект работи под него: 12 постоянно активни правила, 11 skills за работния процес и набори правила на проектния слой за 8 хранилища, а той е основата на моята настройка Orca. Първата версия беше атакувана от независими агенти за преглед в три кръга. В първия кръг се оказа, че всеки проект би получил тихо нула правила, докато всяка проверка показва зелено; следващите кръгове откриха скенер, който сканира нула файла, и невидим управляващ байт, който изключваше регулярен израз. Защитите издържат в употреба: в други сесии Codex отказа да разшири собствения си списък с разрешени проекти, дори с моето съгласие в чата, а проверяващ агент отказа да пипа хранилище, което липсва в профила му. Ограниченията са записани в хранилището. Защитата на клоновете от страна на сървъра връща HTTP 403 при моя план, така че локалният hook за pre-commit е единственият слой, който може да откаже, а --no-verify го заобикаля. ADR-0003 приема, че нищо не измерва дали работният процес се подобрява. ADR за топологията ограничава агентите, които пишат паралелно, до трима плюс собственика, а екипите ми от агенти в други хранилища работят много по-широко; още не съм съгласувал двете. Известно ограничение на настройката Orca: сигналите за завършване, които събуждат координатора, стигат до координатор, работещ вътре в WSL, но не и до Windows Codex Desktop или сесия на Claude под Windows, а този път не е изграден.

• 

  Правилата са кратки нарочно: линтерът предупреждава над 80 реда.