Провести тикет по жизненному циклу с проверкой на каждом шагеMove a ticket through the lifecycle with a gate at every stepПровести тікет життєвим циклом із перевіркою на кожному кроці

Когда это нужноWhen to reach for itКоли це потрібно

В работе есть настоящие неизвестные или настоящий риск, и вы хотите согласовать, что и зачем, до того как решать, как, а после сборки провести аудит. Для опечатки или известного бага цикл пропускают намеренно.The work carries real unknowns or real risk, and you want the what and why agreed before the how, with an audit after the build. For a typo or a known bug the lifecycle is skipped on purpose.У роботі є справжні невідомі чи справжній ризик, і ви хочете погодити, що й навіщо, до того як вирішувати, як, а після збірки провести аудит. Для одруківки чи відомого багу цикл пропускають свідомо.

ТребованияRequirementsВимоги

Где доступноAvailable inДе доступно

Каждая загрузка kitEvery download of the kitКожне завантаження kit

К чему обращаетсяWhat it touchesДо чого звертається

• Читает файлы проектаReads the files of your projectЧитає файли проєкту
• Правит файлы проектаEdits files in your projectЗмінює файли проєкту

Работает сWorks withПрацює з

Любой агент, который читает и пишет ваши файлыAny agent that reads and writes your filesБудь-який агент, що читає й пише ваші файли

Где выполняются шагиWhere the steps happenДе виконуються кроки

Чат вашего агента и ваши собственные файлы. Ни то ни другое не интерфейс этого сайта, поэтому шаги описаны текстом, а не скриншотами.Your agent's chat and your own files. Neither is an interface of this site, so the steps are text and not screenshots.Чат вашого агента і ваші власні файли. Ні те, ні інше не є інтерфейсом цього сайту, тому кроки описано текстом, а не скриншотами.

Где это лежит в kitWhere it lives in the kitДе це лежить у kit

docs/SPEC_LIFECYCLE.md

СоветыTipsПоради

• Идентификатор в прозе - упоминание, идентификатор в токене Blocked-by или Carried-to - утверждение. Прозу оставьте людям и не давайте навыку ходить по ней. Токены окупаются лишь там, где тикеты читает машина; если вы читаете каждый тикет руками, их можно убрать.An id in prose is a mention, an id in the Blocked-by or Carried-to token is a claim. Keep the prose for people and never let a skill route on it. The tokens pay off only where something machine-reads the tickets; if you read every ticket by hand, you can drop them.Ідентифікатор у прозі - згадка, ідентифікатор у токені Blocked-by чи Carried-to - твердження. Прозу залиште людям і не давайте навичці ходити по ній. Токени окуповуються лише там, де тікети читає машина; якщо ви читаєте кожен тікет руками, їх можна прибрати.
• Чтобы снять BlockQuestions: выделите решения, которые мешают следующему переходу, молча закройте те, что уже определены кодовой базой или прежним исследованием, владельцу задайте только настоящие вопросы суждения и сначала предложите проверенный вариант по умолчанию, запишите ответы в тикет, продвиньте его на один уровень и остановитесь. Ответ за владельца не придумывайте.To clear BlockQuestions: isolate the decisions that block the next transition, settle silently any that the codebase or earlier research already determines, put only the genuine judgment calls to the owner with a researched default first, record the answers in the ticket and advance one level, then stop. Never invent an owner's answer.Щоб зняти BlockQuestions: виділіть рішення, що заважають наступному переходу, мовчки закрийте ті, які вже визначені кодовою базою чи попереднім дослідженням, власникові ставте лише справжні питання судження й спершу запропонуйте перевірений варіант за замовчуванням, запишіть відповіді в тікет, просуньте його на один рівень і зупиніться. Відповідь за власника не вигадуйте.
• Статус блокировки сохраняет каждый навык, пока не снята его причина. В частности, /spec-check никогда не затирает BlockQuestions и BlockExternal оценкой аудита: именно такая перезапись заставляет аудит и его исправление вечно передавать друг другу одни и те же неустранимые пункты.A block status is kept by every skill until its condition is removed. In particular /spec-check never overwrites BlockQuestions or BlockExternal with an audit score: that overwrite is what lets an audit and its fix-up hand the same unfixable items back and forth forever.Статус блокування зберігає кожна навичка, доки не знято його причину. Зокрема, /spec-check ніколи не затирає BlockQuestions і BlockExternal оцінкою аудиту: саме такий перезапис змушує аудит і його виправлення вічно передавати одне одному одні й ті самі невиправні пункти.
• Проверка, которую может сделать только человек, живёт в разделе ## Manual checks стратегической спеки: по строке [ ] на каждое, что нужно увидеть, а [x] ставит сам человек с датой и увиденным. Раздел пишется один раз и не перезаписывается, ведь блок аудита переписывается при каждом запуске. Агенты отметок не ставят: /prove может дать доказательство, а отметку ставит человек.A check only a human can make lives in its own ## Manual checks section of the strategic spec: one [ ] line per thing a person must see, ticked [x] by that person with a date and what they observed. It is written once and never overwritten, because the audit's own block is rewritten on every run. Agents never tick a box; /prove can supply evidence, the human supplies the tick.Перевірка, яку може зробити лише людина, живе в розділі ## Manual checks стратегічної спеки: по рядку [ ] на кожне, що треба побачити, а [x] ставить сама людина з датою та побаченим. Розділ пишеться один раз і не перезаписується, адже блок аудиту переписується під час кожного запуску. Агенти позначок не ставлять: /prove може дати доказ, а позначку ставить людина.
• Два правила входа легко перепутать. /spec принимает либо новое описание, либо идентификатор существующего Draft (заглушки от /park) и разворачивает его на месте под тем же идентификатором. /spec-tech принимает Approved или дальше и отказывает Draft, а не повышает его: планирование по однострочному симптому обходит проверку, которую /spec проводит при утверждении.Two entry rules are easy to misremember. /spec takes either a new description or the id of an existing Draft (a /park stub), which it expands in place under the same id. /spec-tech takes Approved or later and refuses a Draft instead of promoting it, because planning from a one-line symptom skips the gate /spec runs at approval.Два правила входу легко переплутати. /spec приймає або новий опис, або ідентифікатор наявного Draft (заглушки від /park) і розгортає його на місці під тим самим ідентифікатором. /spec-tech приймає Approved або далі й відмовляє Draft, а не підвищує його: планування за однорядковим симптомом оминає перевірку, яку /spec проводить при затвердженні.
• Теги проверки необязательны и нужны там, где есть трасса, по которой можно искать grep, например лог. Тег существует тогда и только тогда, когда тикет на BlockNeedUserTest: его вставляют последней правкой кода перед финальной сборкой, а аудит удаляет, когда тикет покидает этот статус.Verification tags are optional and need a trace you can grep, such as a log. A tag exists if and only if the ticket is at BlockNeedUserTest: insert it as the last code edit before the final build, and the audit deletes it when the ticket leaves that status.Теги перевірки необов'язкові й потрібні там, де є слід, який можна шукати через grep, наприклад лог. Тег існує тоді й лише тоді, коли тікет на BlockNeedUserTest: його вставляють останньою правкою коду перед фінальною збіркою, а аудит видаляє, коли тікет полишає цей статус.
• Адаптируйте свободно: впишите в плейсхолдер <ID_SCHEME> свою схему идентификаторов (T0042, JIRA-123, дата со слагом); <ID> в навыках и шаблонах тогда означает идентификатор одного тикета. Состояния блокировки и Archived можно убрать; при внешнем трекере файл остаётся спекой. Любой инструмент поверх должен отказывать в переходе, если не выполнено его условие.Adapt it freely: fill the placeholder <ID_SCHEME> with your id scheme (T0042, JIRA-123, a date-slug); <ID> in the skills and templates is then one ticket's id. Drop the block states or Archived if you do not want them; with an external tracker, keep the file as the spec. Tooling you add should refuse a transition whose precondition is missing.Адаптуйте вільно: впишіть у плейсхолдер <ID_SCHEME> свою схему ідентифікаторів (T0042, JIRA-123, дата зі слагом); <ID> у навичках та шаблонах тоді означає ідентифікатор одного тікета. Стани блокування й Archived можна прибрати; за зовнішнього трекера файл лишається спекою. Будь-який інструмент поверх має відмовляти в переході, якщо не виконано його умову.
• Статус - это первая строка Status: в файле, и читатель берёт её первое слово как статус. Заметка о блокировке идёт после дефиса на той же строке, например BlockExternal - waiting for the vendor's test key, и уходит, когда блокировка снята. Статус верен потому, что его делает верным работа, а не потому, что так говорит название файла или желание.The status is the first Status: line in the file, and a reader takes its first word as the status. A block note follows a hyphen on that same line, for example BlockExternal - waiting for the vendor's test key, and goes when the block lifts. A status is true because the work makes it true, never because a filename or a wish says so.Статус - це перший рядок Status: у файлі, і читач бере його перше слово як статус. Нотатка про блокування йде після дефіса на тому самому рядку, наприклад BlockExternal - waiting for the vendor's test key, і зникає, коли блокування знято. Статус правдивий тому, що його робить правдивим робота, а не тому, що так каже назва файлу чи бажання.
• Тикет входит в Implemented или BlockNeedUserTest только когда его главное видимое пользователю поведение уже работает от начала до конца. Созданные классы, подключённые контракты и успешная компиляция - вехи: не зовите человека проверять, пока заявленное действие всё ещё только пишет в лог, показывает заглушку или ничего не делает.A ticket enters Implemented or BlockNeedUserTest only when its headline user-visible behaviour already works end to end. Created classes, wired contracts and a passing compile are milestones: never invite a human to test while the advertised action still only logs, shows a placeholder or does nothing.Тікет входить в Implemented або BlockNeedUserTest лише коли його головна видима користувачеві поведінка вже працює від початку до кінця. Створені класи, підключені контракти й успішна компіляція - віхи: не кличте людину перевіряти, доки заявлена дія досі лише пише в лог, показує заглушку чи нічого не робить.

Связанные функцииRelated functionsПов'язані функції

• Превратить описание фичи в утверждённую стратегическую спекуTurn a feature description into an approved strategic specПеретворити опис фічі на затверджену стратегічну спеку/spec пишет, что и зачем нужно в фиче, без имён классов и путей к файлам, утверждает и передаёт /spec-tech. Мелкую задачу делает на месте./spec writes the what and why of a feature with no class names or file paths, approves it and passes it to /spec-tech. A small task is built in place./spec пише, що й навіщо потрібно у фічі, без назв класів і шляхів до файлів, затверджує та передає /spec-tech. Дрібну задачу робить на місці.
• Разбить утверждённую спеку на поэтапный план с проверкой каждого шагаTurn an approved spec into a phased plan with a check on every stepРозбити затверджену спеку на поетапний план із перевіркою кожного кроку/spec-tech пишет тактический план: индекс и файлы фаз, каждый шаг кончается статической проверкой, а порядок фаз сам проверяется до смены статуса./spec-tech writes the tactical plan: an index and phase files, each step ending in a static check, with the phase order self-reviewed before the status flips./spec-tech пише тактичний план: індекс і файли фаз, кожен крок закінчується статичною перевіркою, а порядок фаз сам перевіряється до зміни статусу.
• Выполнить тактический план по одному проверенному шагуImplement a tactical plan one verified step at a timeВиконати тактичний план по одному перевіреному кроку/spec-dev идёт по плану шаг за шагом, проверяет каждый шаг до отметки о готовности и жёстко останавливается на первом сбое или неоднозначности, не угадывая./spec-dev runs the plan step by step, checks each step before marking it done and hard-stops on the first failure or ambiguity instead of guessing forward./spec-dev іде за планом крок за кроком, перевіряє кожен крок до позначки про готовність і жорстко зупиняється на першому збої чи неоднозначності, не вгадуючи.
• Проверить реализацию по спеке и выставить статус тикета по фактуAudit a build against its spec and set the ticket status from realityПеревірити реалізацію за спекою й виставити статус тікета за фактомСверяет тикет с тем, что реально лежит в файлах, и выставляет статус: Verified, Partial или Broken, а пока открыта ручная проверка, BlockNeedUserTest.Audits a ticket against what the files really contain and sets its status: Verified, Partial or Broken, or BlockNeedUserTest while a manual check is open.Звіряє тікет із тим, що справді лежить у файлах, і виставляє статус: Verified, Partial чи Broken, а поки відкрита ручна перевірка, BlockNeedUserTest.
• Разобрать очередь тикетов без вашего участия и получить один отчёт в концеDrain the ticket queue unattended and get one report at the endРозібрати чергу тікетів без вашої участі й отримати один звіт наприкінціБерёт тикет с наивысшим приоритетом из тех, что агент может двигать сам, прогоняет конвейер, повторяет, а всё, что требует человека, откладывает в один отчёт.Picks the highest-priority ticket the agent can move alone, runs the pipeline on it, repeats, and defers everything that needs a human to one report.Бере тікет із найвищим пріоритетом серед тих, що агент може рухати сам, проганяє конвеєр, повторює, а все, що потребує людини, відкладає в один звіт.